Trade Off
7.1 Costi/Performance ↔ Complessità Architetturale
Beneficio. Alt-DA (Avail) + batching riducono drasticamente il costo/byte, con fee ~0,1× la base fee Ethereum e blocchi ~2s (~6×) rispetto ai 12s tipici di L1; i costi operativi sono indicati ~10× inferiori a soluzioni “chiavi in mano” (Caldera/Conduit). Costo. Più componenti critici: op-geth, op-node (sequencer), op-batcher, op-proposer, da-proxy, da-light-node, infrastruttura SEED RPC, Explorer, Metrics. Ogni modulo introduce failure modes, SLO dedicati e runbook.
Sara importante ridurre MTTR (osservabilità, auto-healing) è tanto importante quanto aumentare MTBF. Mitigazione. Stack Metrics (Prometheus/Grafana/Monitorism), alert multi-canale e report settimanali; SEED RPC con rate-limit e bilanciamento.
7.2 Data Availability esterno: vantaggi e fiducia
Beneficio. Spostare i dati delle tx su Avail abbassa il costo rispetto alla pubblicazione completa su L1, lasciando su Ethereum commitment e finalità dello stato. Rischio di fiducia. La correttezza osservabile dello stato L2 dipende dalla retrievability dei dati DA. Se la rete DA degrada (liveness o retention), la ricostruzione dello stato può rallentare o fermarsi fino a ripristino. Mitigazione. Operare da-light-node e da-proxy ridondanti; definire SLO/retention del fornitore DA; piani di fallback (es. mirror/replica dei blobs). Assunzione esplicita. I materiali condivisi indicano Avail come DA in uso; l’eventuale opzione Celestia non è documentata nelle fonti attuali e va trattata come alternativa non confermata.
7.3 Optimistic Rollup: challenge period ↔ immediate finality
Beneficio. Inclusione/UX rapide (~2s target) e costi bassi; stato sigillato su L1 tramite commitment. Trade-off. La finalità economica è differita dalla challenge window (parametro non presente nei materiali). Impatto. Per casi d’uso che richiedono finalità istantanea (es. liquidation-sensitive), l’operatore deve modellare il rischio residuo durante TchalT_{\text{chal}}Tchal (es. limiti di prelievo, delay di bridge, assicurazioni/slashing). Mitigazione. Policy applicative (delay operativi), monitoraggio dei fraud-signals e canali di notifica per eventi critici.
7.4 Operatività & Tooling: visibilità ↔ overhead
Beneficio. Explorer con realtime, verifica contratti, API/indicizzazione; Metrics con statistiche live, alert multi-canale e report 7-giorni. Costo. Costi OPEX (storage serie storiche, retention log), tuning di alert (evitare alert fatigue), gestione segreti/chiavi per servizi. Mitigazione. SLO/SLI chiari (sequencer uptime, delay batch→DA, delay DA→settlement), dashboard golden signals e runbook per op-* e DA.
7.5 UX/Web2-like ↔ dipendenze esterne (AA/thirdweb) (facoltativo, se adottate)
Beneficio. Onboarding email/passkeys, gasless via Paymaster, batch-tx “one-click”, recovery—riduce drasticamente la frizione utente. Costo. Dipendenza da provider (wallet SDK/Paymaster), superfici di rischio lato integrazione. Mitigazione. Astrazioni provider-agnostic, test d’integrazione end-to-end, piani di fallback. Stato fonti. Integrazioni specifiche AA/thirdweb non sono descritte nel deck; trattarle come assunzioni finché non referenziate in repo/documenti ufficiali.
7.6 Tabella riassuntiva
AreaBeneficioCosto/RischioMitigazione
Costi/Performance
Fee ~0,1×; blocchi ~2s; OPEX ~10× in meno
Maggior numero di componenti e SRE footprint
Metrics + runbook; SEED RPC bilanciato
Data Availability
Costo/byte più basso su Avail
Liveness/retrievability DA
Ridondanza da-*, SLO DA, fallback
Finalità
Inclusione rapida; stato sigillato su L1
Finalità differita da challenge window
Policy applicative; monitor fraud-signals
Tooling
Explorer/verification/API; alert multi-canale
OPEX osservabilità; alert fatigue
SLI/SLO e tuning alert
UX (AA/thirdweb)
Onboarding web2-like; gasless
Dipendenza provider
Provider-agnostic design
Last updated