repository·main·Indexed 18 days ago
https://github.com/evstack/ev-nodeFoundational framework for the Evolve Stack, enabling the launch of sovereign, customizable blockchains. It provides core primitives for Data Availability (DA) layers, P2P networking, and sequencing. Includes documentation for running EVM sequencers and full nodes, the Force Inclusion API for direct DA submission, the ev-loadgen stress-testing tool, and a KV Executor for node testing.
The Solo Sequencer is a minimal, single-leader sequencer implementation designed for simplicity. It is best suited for trusted single-operator setups where low overhead is prioritized over durability.
Key Characteristics:
VerifyBatch method always returns true unconditionally.The Single Sequencer is a component of the Evolve framework responsible for transaction ordering and batch submission to a Data Availability (DA) layer. It acts as a reliable node that receives transactions from clients, batches them, and submits them to the DA layer.
Key responsibilities include:
The Evolve Rust client is split into two primary crates designed for interacting with Evolve nodes via gRPC:
ev-types: Provides the low-level protobuf-generated types and service definitions. These are automatically generated from the source proto files located in /proto/evnode/v1/.ev-client: A high-level library built on top of the types. It provides type-safe interfaces, connection management with configurable timeouts, and wrappers around gRPC services to simplify interaction with the node.For specific implementation details and code examples, refer to the ev-client documentation in crates/client/README.md.
The Evolve documentation is organized into several key areas to help you navigate the ecosystem:
| Section | Content |
|---|---|
| Learn | Core concepts including DA (Data Availability), sequencing, execution, and specifications. |
| How-To Guides | Tutorials for building, deploying, and operating chains. |
| EVM Integration | Specific instructions for running an EVM chain with Reth. |
| DA Layers | Instructions for connecting to Celestia or running a local DA. |
| Deploy | Guidance on local, testnet, and mainnet deployment. |
| API Docs | Full gRPC and JSON-RPC endpoint reference. |
A Full Node is a top-level service that encapsulates and manages the various components of the Evolve network. Unlike a light node, which only syncs and stores block headers via the P2P layer, a Full Node syncs and stores full blocks from both the P2P network and the Data Availability (DA) layer. These full blocks include all transactions published as part of the block.
To ensure compatibility with cometBFT RPC calls from the SignClient interface, the Full Node includes TxIndexer, BlockIndexer, and IndexerService components.
Evolve is a modular launch stack for Layer 1 (L1) networks designed to provide L1-level control with L2-level performance. Instead of managing a full consensus network with validator overhead and token inflation, Evolve allows you to deploy a chain that inherits security from a Data Availability (DA) layer (like Celestia) by posting blocks to it.
Core Architecture:
ev-node: The central modular node that exposes an Execution interface.The batching_strategy determines how blocks are grouped before being submitted to the DA layer. This allows you to balance latency, cost, and throughput.
| Strategy | Description | Best Use Case |
| :--- | :--- | : |
| immediate | Submits as soon as any items are available. | Low-latency requirements where cost is not a concern. |
| size | Waits until the batch reaches a batch_size_threshold (fraction of max blob size). | Maximizing blob utilization and minimizing costs. |
| time | Waits for a batch_max_delay interval before submitting. | Predictable submission timing aligned with DA block times. |
| adaptive | Submits when either the size threshold is reached OR the max delay expires. | Recommended for production; optimizes both cost and latency. |
batch_size_threshold: (Used by size and adaptive) A float between 0.0 and 1.0 representing the fraction of the maximum blob size. Default is 0.8.batch_max_delay: (Used by time and adaptive) The maximum duration to wait. If set to 0, it defaults to the block_time value.batch_min_items: The minimum number of items (headers or data) required before a submission is considered. All strategies respect this.da:
batching_strategy: "adaptive"
batch_size_threshold: 0.8
batch_max_delay: "6s"
batch_min_items: 1The Validator Network provides an extra security layer and soft confirmation for the rollup, allowing it to move faster than the underlying Data Availability (DA) layer. Instead of a full consensus protocol, it uses a set of validators to verify execution and ordering.
BlockBundle(h) (containing the header, transactions, and state root) to all active attesters via gRPC or WebSocket.SubmissionWindow.EpochLength) during which attestations must be submitted. Missing this window results in forfeited rewards for that epoch but does not trigger slashing.graph TD
SQ[Sequencer] -- p2p --> A1[Attester 1]
SQ -- p2p --> A2[Attester 2]
SQ -- p2p --> A3[Attester N]
A1 -- SubmitSignature Tx --> SQ
A2 -- SubmitSignature Tx --> SQ
A3 -- SubmitSignature Tx --> SQWhen working with or implementing the Rollkit Minimal Header, keep the following architectural considerations in mind:
extraData: The extraData field is the designated mechanism for including additional metadata, such as sequencer information. This is critical for specific chain configurations.