designated verifier
for any slashing. It therefore doesn’t matter how many middleware instances are running for an SBP because only a known entity identified by an ECDSA can represent an SBP in the verification of a network fault (liveness or corruption) which would lead to the slashing of earnings for restaked economic security.
Architecture

- Reconnaissance (gathering current network configuration and state)
- Attestation of detected violation (reporting faults and getting paid in ETH)
- Lean
- Application agnostic
- Modular
- Customizable
Middleware Micro-services
Before going further, we need to address the important microservices behind the middleware that enables the custom slashing logic. Note, the middleware is designed to work out of the box without any adjustments. However, the following components (given as templates in folders that are pre-pended withexample-
) are expected to take on their own logic specific to the restaking application. These components are:
- Liveness API
- Corruption API
- Corruption Verification API
- Identifier API
- For PoN (https://pon.network), liveness is defined as a proposer being online and ready to sign a block header for the highest bid. If the proposer requests a header and does not sign, this is a liveness fault that is recorded inside the PoN network at that slot and can be queried historically and flagged as a liveness issue from a PoN relayer
- ZK validator software could define liveness issues as a validator that does not validate proofs sent to it
- etc.
- In PoN, a missed slot or invalid payment deviating from the credible commitment is a protocol violation and this corruption commands a higher penalty.
5
:
5
as a nonce, many reporters could curate the same liveness fault report but only one report will be accepted by the smart contract
since once a nonce (for a given service provider) is consumed by the K2 smart contracts, it will not be accepted again.
Therefore, if you imagine more complex definition of liveness events or more than one liveness events, you will need to generate
appropriate nonces.
It is possible to generate and use nonces on-chain to avoid having to build complex systems to generate them off chain.
In order to do this one needs to take advantage of a K2 contract feature for SBP positions: hooks. Hooks allow an SBP
position to define a hook that will receive notifications after certain events have taken place related to an SBP. One
of those events could be for example slashing
where notification of a slashing could cause a nonce to be incremented
as per the following diagram:

Bearer authentication
Microservices such as the identifier API use HTTP bearer authentication due to the sensitivity of some of these services. For example, the identifier API could be generating nonces on the fly and accidentally exposing this to the outside world could lead to some DoS attacks. To counter this, bearer authentication is used to authenticate the middleware to the identifier API. To ensure this is configured correctly, simply use the same bearer token in theenv/
of the middleware and the env/
of the individual service.
Getting started
K2 Middleware is aserverless
project that aims to make spinning up the software locally or hosting on AWS as simple
and as straightforward as possible even going as far as to provide Github actions that instantiate the lambdas. The
provided Dockerfile(s) help serverless but also allow a non-serverless approach to be taken by using simpler docker
containers.
The root of the repository contains the core middleware logic. All the example microservices (in directories pre-pended
with example-
) and the core middleware can be spun up in the same way following the steps below.
Installing dependencies
Yarn is the package manager of choice and the dependencies can be installed with the following command:Updating the environment variables
Depending on the network you are deploying the software, you can update the appropriate environment file. For example, if running locally, you can update theconfig.local.json
file.
Running locally
You can run the software locally by simply executing the command:Deploying automatically with Github actions
The.github
folder contains the actions that will use serverless
to deploy to AWS.