Design
3.1 Principi
Rollup Optimistic con finalità su Ethereum. La sicurezza deriva da L1: lo stato è impegnato (commit) e finalizzato su Ethereum, mantenendo la fiducia minima del modello rollup.
Data Availability (DA) esterna per performance. I dati delle transazioni sono pubblicati su un livello DA ad alta velocità (Avail), riducendo drasticamente il costo/byte rispetto alla sola pubblicazione su L1 e migliorando la scalabilità.
EVM-compatibilità tramite OP Stack. L’esecuzione è basata sullo stack Optimism (OP Stack), garantendo compatibilità con tool e smart contract esistenti.
Nota progettuale. Nei materiali condivisi è indicato Avail come DA effettivo. L’uso di Celestia è da considerare un’alternativa possibile, non documentata come integrazione corrente (“Non in the current knowledge” finché non alleghi fonti).
3.2 Architettura ibrida (sicurezza + performance)
Execution / OP Stack. Esecuzione EVM, con compatibilità piena agli smart contract e agli strumenti Ethereum.
Sequencer & osservabilità. Il sequencer ordina le transazioni; uptime e segnali critici (incluse “prove di frode”) sono monitorati in tempo reale.
Batching & Settlement. Le transazioni sono raggruppate (batch), impegnate e finalizzate su Ethereum; la logica di commitment è progettata per mantenere gas basso e sicurezza alta.
Data Availability su Avail. I dati dei batch sono pubblicati su Avail per disponibilità rapida e conveniente; lo stato resta sigillato su L1.
SEED RPC (operatività). Strato RPC a bassa latenza, protetto da rate-limit e meccanismi anti-abuso, bilanciato e scalabile per ambienti di produzione.
Explorer & Developer UX. Block explorer con aggiornamenti real-time, verifica dei contratti, API e indicizzazione per interazione fluida con la chain.
Metrics & Alerting. Stack di osservabilità basato su Grafana, Prometheus e Monitorism, con statistiche live, report 7-giorni e notifiche multi-canale (Slack, Email, Telegram).
Bridging operativo. Percorso di bridge “istantaneo” documentato per trasferimenti (es. Sepolia ↔ Colichain).
3.3 Percorso dati (tx lifecycle)
Sottomissione. L’utente invia una transazione al SEED RPC; il sequencer la include rapidamente nel prossimo blocco (target ~2s).
Batching & DA. Le transazioni confermate sono batchate e i dati pubblicati su Avail per garantire disponibilità; i metadati di impegno (commit) sono preparati per L1.
Settlement su L1. Il batch è finalizzato su Ethereum, ancorando lo stato L2 alla sicurezza di L1.
Osservabilità end-to-end. Explorer e dashboard espongono blocchi, tx, calldata e stato dei contratti; metriche e alert reagiscono a eventi chiave della rete.
3.4 Modello di sicurezza (in sintesi)
Eredità della sicurezza L1. La finalità su Ethereum garantisce che ogni cambiamento di stato L2 sia sigillato su L1.
Disponibilità dei dati. Pubblicando i dati su Avail, i nodi possono ricostruire lo stato; l’efficienza del DA contribuisce a ridurre le fee senza intaccare la capacità di verifica.
Rilevazione e monitoraggio. Meccanismi di monitoraggio includono segnali relativi a integrità del sequencer e alla pipeline di prove (fraud-related signals).
Chiarezza terminologica. I materiali menzionano il monitoraggio di “prove di frode”, coerente con rollup ottimistico; i dettagli implementativi (challenge window, attori, esecuzione delle prove) non sono specificati nei file condivisi e andranno referenziati nelle Technical Docs.
3.5 Parametri operativi (attesi)
Tempo blocco target: ~2 secondi (≈ 6× più rapido dei 12s tipici di Ethereum).
Fee effettive: ~0,1× rispetto alla base fee di Ethereum Mainnet.
Efficienza operativa: ~10× meno costosa rispetto a piattaforme come Caldera e Conduit (stima del deck).
3.6 Interfacce operative (tooling “essenziali”)
SEED RPC: ingressi ad alta capacità con protezioni anti-abuso.
Explorer: real-time blocks/tx, verifica contratti, API/indicizzazione.
Monitoring: Grafana/Prometheus/Monitorism con alert multi-canale e report 7-giorni.
Onboarding rapido: flusso “connetti al network” via explorer e percorso di bridge operativo per l’utente.
Last updated