Transaction lanes: reserved blockspace with custom lane support
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
Línea de trabajo
Comienza con EvolvePayloadBuilder en crates/node/src/builder.rs y, después, inspecciona las ubicaciones propuestas de Lane, LaneMatcher y LanePolicy en crates/common/ o crates/evolve/. Sigue las cadenas existentes de EvolveConfig chainspec extras y las rutas de receipt/RPC antes de definir los puntos de integración. Se considera terminado cuando se haya cubierto la lista de comprobación, incluidas las garantías de Lane, el overflow, las métricas, los metadatos de RPC y receipt, las pruebas de integración y la documentación.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
Implement a lane-based block construction system in the payload builder that reserves blockspace for different transaction categories, with built-in payment lanes and a pluggable interface for custom lanes.
Motivation
At 100ms block times with sequencer-controlled ordering, the scarce resource isn't confirmation speed -- it's guaranteed throughput under congestion. When block gas is fully utilized, high-value payment transactions compete with arbitrary EVM workloads (DeFi, NFT mints, contract deployments). Payment lanes guarantee that stablecoin transfers and payment-critical transactions always have access to blockspace, regardless of what else is happening on-chain.
Custom lanes extend this to any transaction category a chain operator cares about: system transactions, oracle updates, bridge operations, or domain-specific workloads.
Design
Lane model
A lane defines:
- Name / ID: identifier for the lane (e.g.,
payment,system,general) - Gas reservation: minimum gas guaranteed for this lane per block
- Gas cap: maximum gas this lane can consume (optional -- lanes can overflow into general capacity)
- Matcher: predicate that routes a transaction to a lane (by tx type, destination address, calldata selector, or custom logic)
- Priority: ordering within the lane (FIFO, fee-based, or custom)
Block structure
Block gas_limit: 30M
├── system lane: 2M reserved (system txs, L1 info, oracle updates)
├── payment lane: 15M reserved (stablecoin transfers, 0x76 payment calls)
├── general lane: 13M remainder (everything else)
└── overflow: unused lane capacity redistributed to general
Chainspec configuration
{
"evolve": {
"lanes": [
{
"id": "system",
"gas_reserved": 2000000,
"matcher": { "type": "tx_type", "values": ["system"] },
"priority": "fifo"
},
{
"id": "payment",
"gas_reserved": 15000000,
"gas_cap": 20000000,
"matcher": {
"type": "any_of",
"rules": [
{ "type": "to_address", "addresses": ["0x...USDC", "0x...USDT"] },
{ "type": "selector", "selectors": ["0xa9059cbb", "0x23b872dd"] }
]
},
"priority": "fee"
}
],
"lanes_activation_height": 0
}
}
Custom lane interface
Chain operators can define lanes via chainspec (static) or register them programmatically via a trait:
pub trait LaneMatcher: Send + Sync {
/// Returns the lane ID this transaction belongs to, or None for general lane.
fn match_tx(&self, tx: &EvTxEnvelope, state: &dyn StateProvider) -> Option<LaneId>;
}
pub trait LanePolicy: Send + Sync {
/// Orders transactions within a lane. Returns sorted transaction list.
fn order(&self, txs: Vec<&EvTxEnvelope>) -> Vec<&EvTxEnvelope>;
}
This allows customers to:
- Define lanes by contract address, function selector, tx type, sender allowlist, or arbitrary state-dependent logic
- Implement custom ordering within lanes (auction-based, priority fee, FIFO, round-robin)
- Compose matchers (
any_of,all_of,not)
Payload builder integration
EvolvePayloadBuilder in crates/node/src/builder.rs changes:
- Classify: Route each incoming transaction to a lane via matchers
- Reserve: Allocate gas budget per lane from block gas limit
- Fill: Execute transactions lane-by-lane, respecting per-lane gas reservations
- Overflow: Redistribute unused lane capacity to general lane
- Metrics: Emit per-lane utilization metrics (gas used, tx count, overflow)
Receipt / RPC extensions
eth_getTransactionReceiptincludeslanefield indicating which lane the tx was routed to- New RPC:
evolve_getLaneStatusreturns current lane utilization and available capacity - Useful for clients to estimate inclusion probability and fee dynamics per lane
Scope
- Define
Lane,LaneMatcher,LanePolicytraits incrates/common/orcrates/evolve/ - Implement built-in matchers:
tx_type,to_address,selector,sender,any_of,all_of - Add lane configuration to
EvolveConfigchainspec extras - Modify
EvolvePayloadBuilderto classify, reserve, fill, and overflow - Add per-lane metrics (gas used, tx count, overflow events)
- Extend RPC with lane status endpoint
- Extend receipts with lane metadata
- Integration tests: congested blocks with lane guarantees, overflow behavior, custom matcher registration
- Documentation: how to define custom lanes for a chain deployment
Prior art
- Tempo: payment lanes with dual gas limits --
general_gas_limitcaps non-payment gas, remaining reserved for payments - Ethereum EIP-7766: Priority lanes proposal -- similar concept for L1
- #94 (closed) -- ToB auction research; auction-based ordering becomes a
LanePolicyimplementation - #127 (closed) -- pre-confirmations; moot at 100ms blocks, lane guarantees are the actual need
- Lenguaje dominante
- Rust
- Estrellas
- 8
- Forks
- 9
- Merge medio
- 7 h 25 min
- PR fusionados (30 d)
- 2
Preparar el entorno
- Incluye un Dockerfile o un archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de evstack/ev-reth
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
Los mantenedores suelen responder en 1 día
-
Explorer integration: Blockscout and Atlas support for 0x76 transactionsQuizá libre de nuevo @pthmas la tomó hace 224 días y no hay ningún pull request abierto. Abierto
evstack/ev-reth#130 · 1 asignado ·
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
Los mantenedores suelen responder en 1 día
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 28/100
Los mantenedores suelen responder en 1 día
Todos los issues de evstack/ev-reth
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
pnpm/pnpm#16635 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
[Bug]: Bedrock request metadata forwarding does not work for /embeddingsPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertobug llm translation
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
pytest plugin: a crashed xdist worker aborts the whole session with INTERNALERRORPosiblemente ocupada @hazelxue la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
Los mantenedores suelen responder en 1 día
-
skillfs: one malformed chat-log line aborts the entire skill-usage analysis (skill_usage_from_chat_logs.py)Posiblemente ocupada @zjncs la tomó hoy. Abiertocomponent:skillfs
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
agentic-os-org/ANOLISA#6116 · 1 comentario ·
Los mantenedores suelen responder en 1 día