Dynamic Validation Network (DVN)
2.1. Overview of a DVN
A Dynamic Validation Network (DVN) on Kernel is a decentralized service leveraging economic security from assets staked on Kernel.
A DVN is composed of the following:
on-chain contracts (DVNCoordinator, DVNGateway optionally)
off-chain Task Aggregator which leverages the network of Operators
Operators execute tasks off-chain on behalf of the DVN and then send their responses to the DVN, which satisfies the DVN’s end users' requests.
Operators and DVNs are expected to keep track of completed tasks and to store proofs of work on their own infrastructures, which could be used in a dispute on rewards.
To increase transparency a DVN can implement custom logic inside their smart contracts to store Tasks execution proofs on-chain, if required by the DVN’s business logic.
To join the list of those working for a DVN, an Operator must opt-in and the DVN must accept or refuse. The requests are handled in a Kernel contract, and optionally pass through the DVNGateway if some custom registration logic is necessary.
The DVN assigns rewards to Operators performing tasks properly and penalizes the ones performing tasks maliciously. The DVN can slash the Operator’s delegated stake, and can also eventually decide to exclude that Operator from executing future Tasks.
2.2. Register to Kernel
Registration to Kernel is a permissioned procedure. It’s the first, mandatory step a DVN performs when onboarding into Kernel.
Determine an EOA (or a contract, like a Safe account) to use as DVN Owner (can be changed later)
the DVN Owner can also be a contract called “DVNGateway”, developed by the DVN and containing custom logic e.g. about adding Operators
Get in touch with Kernel team and provide:
the DVN Owner address
a “Metadata URI” url pointing to a json file respecting the following structure: { "name": "Hello World DVN", "website": "https://www.example.com", "description": "I do stuff", "logo": "https://example.com/logo.png" }
Kernel completes the registration:
the DVN is now officially part of Kernel and can start onboarding Operators
the DVN obtains the DVNCoordinator address, used as universal identifier
During the registration a contract called DVNCoordinator is automatically deployed by Kernel. It has the following properties:
the address is immutable and identifies a DVN in Kernel Protocol
it’s a Beacon Proxy and can be upgraded by Kernel
it is owned by the address specified as DVN Owner
the owner address can be changed, for example a DVN started using an EOA but later decides to deploy a DVNGateway contract and transfer ownership to it
2.3. How to build your DVN
Design Tasks A Task is intended as any unit of work that responds to DVN’s business logic, whose resolution logic is provided by the DVN in any language and performed off-chain by Operators. Using Tasks as design model is the suggested mechanism to represent DVN business logic.
Ideally the Operators execute the same Tasks, so designing them for scalability is crucial.
Design how Operators execute Tasks The recommended way to organize Operators’ Tasks execution is through an off-chain Task Aggregator, which is a tool developed and maintained by the DVN responsible for:
Assigning tasks to Operators
Collecting Operators’ responses
Determining the validity of each response
Determining if the Operator behaved properly or maliciously
Provide a Long-Running Executable (LRE) to Operators DVNs are responsible for providing Operators with a long running executable in a way that is easy for them to launch and keep running (eg. via binary, docker container, or similar).
Once configured, the executable should:
Receive new Tasks from Task Aggregator
Process Task and generate a response
Send response to Task Aggregator
Implement Smart Contract(s) Kernel does not require a DVN to deploy any smart contract to operate.
The DVN can interact with its dedicated DVNCoordinator contract by executing calls with an EOA, but can also deploy a contract called DVNGateway and transfer the DVNCoordinator ownership to it.
The DVNGateway contract is not mandatory, but can be helpful for:
Implementing a finer roles-based access
Interacting with Kernel Core (Operator registration, metadata URI update)
Implementing custom business logic
Handling Tasks and Tasks execution/validation proofs on-chain
Provide documentation Sharing extensive documentation addressed to Operators is highly important and should cover the following:
Trust Modeling Illustrate trust assumptions in your architecture to end users, specifying the components that are trusted (e.g. centralized) and untrusted (e.g. decentralized or trustless)
Operator instructions How to install and update the Long Running Executable, register and deregister to DVN
Official communication channels
Describe the operator monitoring tooling available Such as Grafana, log files, or something similar
Assign Rewards DVN is responsible for establishing the rules to assign rewards to Operators upon correctly completing Tasks. Distribution will happen with ERC-20 tokens through Kernel with a frequency decided by DVN.
Distribution flow:
DVN assigns Tasks to Operators for a given period
The DVN computes the amounts of Rewards to give to each Operator
Kernel verifies data and stores it on-chain with Merkle-tree technology
Rewards and made available for Operators and Delegators through claiming
A dispute mechanism is available for those disagreeing with the assigned reward amount
2.4. Interacting elements
This section illustrates the elements that a DVN is required to develop, the decisions it is required to make, and the tools it gets in contact with, when leveraging Kernel’s Operators Network.
Developed or decided by the DVN:
Long Running Executable (LRE)
A Task Aggregator to assign Tasks to each LRE and collect responses
Logic to allocate rewards upon completed tasks
Logic to penalize bad behaviors
Monitoring tools made available to Operators
Kernel’s core components and tools provided to DVNs:
DVNs Registry and Operators Registry
SDK for DVN builders
Rewards Distribution system
Last updated