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.

Restaking Protocols

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

Validator Set

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

Kepler

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

Tess

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.

Execution Chains

Any EVM compatible blockchain network on which you can implement:

• ERC-4337
• ERC-7579
• ERC-4626
• EIP-7702

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:

1. Commit Phase

   Every validator commits a random hash of private key.

2. Reveal Phase

   Validators reveal their private keys and submit their votes.

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

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

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

3. Routing

   If all checks are passed, the committee module sends messages through MessageRouter to the appropriate modules.

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

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

2. 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
3. TESS Bridge Update

   The TESS network detects the new operator registration. This information is then propagated to the Kepler chain through the committee.

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