🇮🇹 "L2: Arbitrum su Ethereum vs Hydra su Cardano"

:it: Traduzione italiana di " L2: Arbitrum en Ethereum vs Hydra en Cardano" scritto da @arielfavio


La scalabilità nella blockchain è determinata dalla velocità di elaborazione delle transazioni al secondo (TPS) e dal costo delle transazioni (tassa di rete).

L’elaborazione delle transazioni del primo livello (L1) è limitata dalla quantità di risorse scarse, cioè la sua scalabilità, impedendo la crescita dell’ecosistema.

Il primo livello è quello che chiamiamo blockchain, che è la rete più sicura e decentralizzata, ma con prestazioni inferiori.

Se la decentralizzazione non sarà sacrificata, le prestazioni non saranno mai sufficienti per permettere a un gran numero di persone di utilizzare una rete distribuita consensuale.

L2 è progettato per scalare, rendendo le transazioni veloci e poco costose. È quasi come una rete parallela.

Cos’è Arbitrum?

Arbitrum, con il suo protocollo ArbOS in esecuzione sulla blockchain di Ethereum, permette di spostare l’esecuzione dei contratti intelligenti fuori dalla L1, in modo che i partecipanti possano fidarsi di pochi validatori scelti (noti anche come manager).

In una rete come Ethereum, che è basata su PoW, questo è estremamente importante perché l’esecuzione dei contratti è costosa e richiede molte risorse. Questo significa meno risorse per estrarre i blocchi. Pertanto, i validatori non sono incentivati a convalidare transazioni costose a spese della produzione dei blocchi.

Spostando i calcoli costosi fuori dalla catena principale e mantenendo solo le transizioni di stato economiche sulla L1, Arbitrum può alleggerire la rete di un fattore importante: riconvalida solo le transazioni di base.

Per approfittare delle transazioni veloci e delle basse commissioni di Arbitrum, un utente Ethereum deve presentare il proprio token ETH o ERC20 al contratto di deposito di Arbitrum. Una volta che la transazione di deposito è confermata, l’utente può accedere alle sue monete dall’ecosistema Arbitrum.

È importante distinguere tra l’ecosistema Arbitrum ed Ethereum. I progetti attualmente in esecuzione su Ethereum non sono automaticamente inclusi in Arbitrum. Gli sviluppatori devono costruire la loro applicazione su Arbitrum se vogliono che funzioni lì.

Lo fa anche incentivando i manager di Arbitrum a comportarsi onestamente in modo che sia sufficiente avere almeno un manager onesto (e disponibile!) perché un contratto progredisca legittimamente.

Si noti che Arbitrum non libera realmente la rete dal traffico giornaliero di per sé, poiché ogni transizione di contratti deve ancora essere pubblicata sulla catena, e anche la creazione di una macchina virtuale Arbitrum (A-VM) richiede transazioni.

Tuttavia, raggiunge il suo scopo, poiché riduce drasticamente la complessità della rete L1 senza comprometterla troppo.

Cos’è Hydra?

Hydra usa i canali di stato, che estende il concetto di canali a pagamento, poiché ha funzionalità di programmazione. Le parti mantengono canali di stato, che possono essere concordati senza interazione con il primo strato.

Hydra quindi si occupa non solo del trasferimento di fondi, ma anche dell’esecuzione di contratti intelligenti. Per esempio, è possibile creare un contratto intelligente nel primo livello, e trasferirlo alla testa Hydra dove può essere eseguito.

Con Hydra, il canale è multi-party, isomorfo e dotato di grande sicurezza.

Il canale multiparty è una relazione tra 2 o più partecipanti.

Isomorfismo" significa che le transazioni in esecuzione su una testa possono essere mappate su transazioni L1 e viceversa.

Questo è diverso da Arbitrum, in quanto richiede che i contratti Solidity siano ricompilati nel bytecode della macchina virtuale Arbitrum. E una tale VM è “solo” in grado di eseguire contratti.

Una testa Hydra, al contrario, può elaborare transazioni Cardano complete, con asset nativi, metadati, script e così via.

Significa che le teste di Hydra possono sfruttare regole di ledger provate su L1, il che fornisce forti garanzie di correttezza. Rende anche molto più facile l’interoperabilità e la manutenzione di L2 quando L1 cambia.

Una testa è come una mini blockchain, con un consenso più veloce.

Con una macchina virtuale dedicata e un compilatore costruito da zero, Arbitrum affronta una sfida rischiosa per un sistema finanziario. Sicuramente il team ha testato esaustivamente i suoi componenti, ma data la storia dei precedenti fallimenti dei contratti intelligenti nello spazio, la probabilità di errori rimane.

In realtà, Arbitrum sposta solo le esecuzioni dei contratti su L2 (ma non il traffico), mentre Hydra sposta il traffico effettivo su L1. L’esecuzione del contratto su Arbitrum non sarà più veloce che su L1, e le transizioni sono ancora soggette ai tempi di liquidazione di L1.

Su una testa Hydra, le transazioni si risolvono molto più velocemente che sulla sottostante L1.

I canali statici sono generalmente cattivi per le piattaforme con stato globale come Ethereum, perché in caso di controversia, l’intero stato del canale deve essere on-chain per la verifica. Questo non è il caso di Hydra.

Prima di tutto, grazie al modello eUTxO, non c’è uno stato globale mutabile che modifica i contratti. In Cardano, ci sono solo validatori statici che operano in eUTxO, il che significa che gli script di Cardano possono essere validati in isolamento.

In secondo luogo, una testa dell’Idra si muove in avanti solo se tutti i partecipanti hanno esplicitamente accettato di progredire, non è possibile spostare denaro che non si è concordato di spostare. Le controversie in Hydra possono essere risolte in modo completamente automatico e non c’è bisogno di gonfiare la L1 con grandi dump di stato.

In Arbitrum, la risoluzione delle controversie è più coinvolta. Poiché lo stato della VM può essere avanzato da uno qualsiasi degli amministratori della VM, una controversia richiede una mediazione di livello 1 e diversi passaggi per determinare chi è onesto.

Sul lato positivo, una VM può progredire con un solo nodo onesto.

Come ho detto, l’obiettivo principale di Arbitrum è quello di sollevare L1 dalla costosa applicazione dei contratti. Questo viene ad aggirare un problema noto come “The Verifier’s Dilemma”: la verifica dei contratti richiede molte risorse e i validatori potrebbero non avere un forte incentivo a verificare i contratti. Pertanto, questo può portare ad attacchi in cui gli attaccanti inviano transazioni contrattuali arbitrariamente complesse per mantenere gli altri validatori inutilmente occupati e, nel frattempo, ottenere un vantaggio nel mining dei blocchi.

Come fa Cardano a gestirlo?

  • Proof of stake
  • Collaterale

Alonzo estende le transazioni per includere un nuovo componente chiamato “input collaterale” (o semplicemente, collaterale). Questi sono input speciali che i pool possono raccogliere nel caso in cui gli venga fornita una transazione scriptata che non convalida per compensare le risorse coinvolte.

Anche se questo può sembrare un po’ spaventoso, ricordate che gli script Cardano possono essere completamente convalidati staticamente, anche prima di essere inviati alla rete. Quindi, in pratica, i portafogli ben progettati non pubblicheranno transazioni con script difettosi e gli attaccanti saranno puniti finanziariamente.

Osservazioni conclusive

Per concludere, le due soluzioni sono abbastanza diverse perché affrontano anche problemi diversi.

Hydra è una buona opzione per le transazioni off-net a buon mercato, mentre Arbitrum è davvero un modo per spostare l’esecuzione del contratto fuori dal livello 1.

Mentre i canali stateful sono pesantemente criticati nello spazio PoW, i loro trade-off nei terreni PoS sono abbastanza diversi, e con Hydra, i ricercatori hanno trovato un punto ottimale tra semplicità, efficienza e forti garanzie di sicurezza, e si adatta molto bene al modello UTXO.

Le teste Hydra sono solo un primo passo nella roadmap della scalabilità di Cardano, che è necessaria se vogliamo far crescere l’ecosistema.

Fonti: Offchain Labs Dev Center , Hydra: Fast Isomorphic State Channels, Interhead Hydra: Two Heads are Better than One

1 Like

Grazie per la traduzione

1 Like