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
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.