Architecture
Ditto Network Architecture
This document provides a comprehensive overview of the Ditto Network architecture, its components, and relationships.
Core Components
Ditto Network is a decentralized network designed to execute custom automations with high availability and scalability.
Shared-security protocols that create a set of validators to ensure data security and integrity. They synchronize the list of validators from the L1 (Ethereum) network.
Currently, we use Symbiotic and Eigenlayer
Shared-security protocols that create a set of validators to ensure data security and integrity. They synchronize the list of validators from the L1 (Ethereum) network.
Currently, we use Symbiotic and Eigenlayer
Validators are the main participants in our protocol and perform the following functions:
- Participation in validator committee formation through RANDAO + Commit / Reveal
- Ensuring transaction security and block formation
- Executing automations within their committee
The main Ditto Network chain, which is responsible for:
- Storage and management of automations
- Setting up and controlling the validator set
- Forming the validator committee
- Ensuring transaction security
- Distribution of rewards and penalties
Chain is built on top of the Cosmos SDK, leveraging its robust and battle-tested infrastructure. While built on it, Ditto Network introduces several custom modules and features:
- Restaking module: We use it instead of the default staking module. It allows us to integrate restaking protocols directly into Kepler, enabling L1 operators to become validators. More details.
- Genutil module: Enables the creation of genesis transactions for proper restaking functionality
A distributed network of executors (runners) that:
- Executes automations within its runner
- Works similarly to the Github Runner system
- Provides scalable task execution
Consensus protocol: pBFT
No aggregators are needed, which could become bottlenecks and negate decentralization.
Any EVM compatible blockchain network on which you can implement:
Currently supported networks:
- Ethereum
- Base
- Ton App Chain
- Arbitrum
Ditto Network architecture is not tied to any specific blockchain network, which allows for easy execution of automations on any blockchain platform.
System Relations
Committee Formation
Committee Formation Process:
Commit Phase
Every validator commits a random hash of private key.
Reveal Phase
Validators reveal their private keys and submit their votes.
Committee Creation
As a result, we get a seed that is used for random selection of the TESS leader. The leader will act as an aggregator of signatures from other committee members. The leader receives more rewards, as they perform more work. More about rewards will be covered in the Rewards section.
Participation Rules
If a validator who participated in the commit phase refuses to participate in the reveal phase, they will not be included in the committee.
Committee Responsibilities:
- Execution of automations
- Updating the validator set
- Updating information about the next committee in Execution Chains
- Updating information about automation execution statuses
Restaking Integration
Ditto Network uses a shared-security model with integration of multiple restaking networks to provide maximum protection.
Symbiotic
A shared-security network using a set of validators to ensure data security and integrity.
Eigenlayer
A restaking platform that enhances Ditto Network security through distributed validation.
In order to synchronize the list of validators from the L1 network, we developed a Restaking module on our network and abandoned the use of native Staking. This could have been avoided, but this path was chosen to simplify the architecture and reduce the number of components in the network.
Validator Types
Default Validators
Default validators without additional conditions
Emergency Validators
Validators with enhanced conditions for emergency situations
Emergency protocol
In case there are not enough validators to form a committee or insufficient votes, validators from the Emergency protocol are escalated. Such validators typically have the lowest voting power so as not to interfere with other validators, but can be used in emergency situations.
Escalation Conditions
- Insufficient number of validators to form a committee
- Insufficient votes to form a committee
- Non-fulfillment of obligations by the previous committee
Validator Update Mechanism
Report Formation
TESS participants (Active committee) form a multisig Report by quorum which contains messages for Kepler. One such message may contain information about validator updates. This approach resembles the multicall mechanism in EVM together with multisig.
Processing
When the message reaches Kepler, it goes to the x/committee module, which accepts reports. Within this module, a check for quorum and legitimacy of participants is performed.
Routing
If all checks are passed, the committee module sends messages through MessageRouter to the appropriate modules.
Validator Updates
Using the example of a validator update message, when it reaches the MessageRouter, it is sent to the x/restaking module, which takes a list of operators as input and updates the set of validators in the network.
Only the committee can update the validator set.
Full flow from Operator to Validator
L1 Restaking Protocol Registration
The operator first registers on one of the supported L1 restaking protocols (Symbiotic or Eigenlayer). This involves staking tokens and completing the protocol’s registration process.
Kepler Node Setup
The operator sets up a Kepler node by:
- Installing and configuring the Kepler node software
- Setting up the necessary infrastructure (server, networking, etc.)
- Syncing with the Kepler network
TESS Bridge Update
The TESS network detects the new operator registration. This information is then propagated to the Kepler chain through the committee.
BondValidator Transaction
Once the node is operational, the operator creates and submits a BondValidator transaction to Kepler. This transaction:
- Links the L1 operator address with the Kepler validator address
- Initiates the process of becoming a validator
Validator Activation
After the BondValidator transaction is processed:
- The operator is added to the validator set
- They can participate in committee formation
- They become eligible for rewards and penalties
Important Requirements
- The operator must maintain sufficient stake in the L1 restaking protocol
- The Kepler node must meet minimum hardware and network requirements
- The operator must maintain high uptime and proper node operation