Titolo originale: "Introduzione al meccanismo di inclusione forzata di Rollup"
Autore: NIC Lin, capo del Taipei Ethereum Meetup
Proprio ieri è successo qualcosa che ha scioccato innumerevoli persone: Linea, il secondo strato di Ethereum lanciato dalla società madre di Metamask Consensys, ha chiuso in modo proattivo. I funzionari hanno affermato che lo scopo di ciò era quello di ridurre l'impatto dell'incidente di hacking di Velocore. E questo non può fare a meno di ricordare alla gente la precedente chiusura della BSC Chain (BNB Chain) sotto coordinamento ufficiale al fine di ridurre le perdite derivanti dagli attacchi degli hacker. Ogni volta che le persone parlano di questo genere di cose, dubitano del valore decentralizzato sostenuto dal Web3.
Naturalmente il motivo principale degli incidenti sopra menzionati risiede piuttosto nell’imperfezione dell’infrastruttura stessa, cioè nella decentralizzazione insufficiente: se una catena è sufficientemente decentralizzata, non dovrebbe fermarsi di colpo. A causa della struttura unica del secondo strato di Ethereum, la maggior parte del livello 2 si basa sul sequenziatore centralizzato Anche se negli ultimi anni ci sono stati sempre più argomenti a favore dei sequenziatori decentralizzati, considerando lo scopo del secondo strato e la sua struttura, probabilmente lo siamo. Si può considerare che il selezionatore di livello 2 molto probabilmente non sarà molto decentralizzato e alla fine potrebbe non essere così decentralizzato come la catena BSC. Se davvero è così, cosa dovremmo fare?
Infatti, per il secondo livello, il danno più diretto causato dalla mancata decentralizzazione dello smistatore risiede nella sua resistenza e attività alla censura. Se ci sono solo poche entità (Sequencer) che elaborano le transazioni, allora ha il potere assoluto di servirti: può rifiutarti se vuole, e potresti non avere scelta. Come risolvere il problema anti-censura del Layer 2 è ovviamente un argomento importante.
Negli ultimi anni, i principali second layer di Ethereum hanno proposto varie soluzioni ai problemi di anti-censura, come Loopring e Degate, le funzioni di ritiro forzato e di escape hatch di StarkEx e Arbitrum e altre funzioni Force Inclusion di OP Rollup, questi metodi possono creare controlli e saldi sul Sequencer a determinate condizioni per evitare che rifiuti qualsiasi richiesta di transazione dell'utente senza motivo.
Nell'articolo di oggi, NIC Lin della Taipei Ethereum Association fornisce il proprio resoconto, ha sperimentato personalmente le funzioni di transazione anti-censura di quattro Rollup tradizionali e ha analizzato profondamente la progettazione del meccanismo di Force Inclusion da aspetti come il flusso di lavoro e i metodi operativi, che è molto importante per Ethereum È particolarmente prezioso per la comunità e i grandi investitori con ingenti risorse.
Revisione delle transazioni e inclusione forzata
La resistenza alla censura delle transazioni (Censorship Resistance) è molto importante per una blockchain Se la blockchain può rivedere e rifiutare arbitrariamente le transazioni avviate dagli utenti, non sarà diversa da un server Web2. L'attuale resistenza delle transazioni di Ethereum alla censura deriva dal suo gran numero di validatori Se qualcuno vuole rivedere le transazioni di Bob e impedire che le sue transazioni vengano caricate nella catena, deve provare a corrompere la maggior parte dei validatori nella rete o inviare spam all'intera rete. rete. Invia continuamente transazioni spazzatura con commissioni di gestione più elevate rispetto a Bob per occupare spazio sui blocchi. In ogni caso, il costo sarà molto alto.
Nota: nell'attuale struttura PBS di Ethereum, il costo di revisione delle transazioni sarà notevolmente ridotto. Puoi fare riferimento alla proporzione di blocchi che collaborano con OFAC per rivedere le transazioni Tornado Cash. L’attuale resistenza alla censura si basa su verificatori e relè indipendenti al di fuori dell’OFAC e della giurisdizione governativa.
Ma che dire del Rollup? Rollup non richiede un gran numero di validatori per garantire la sicurezza Anche se Rollup ha un solo ruolo centralizzato (Sequencer) per generare blocchi, è sicuro come L1. Ma la sicurezza e la resistenza alla censura sono due cose diverse. Anche se un Rollup è sicuro come Ethereum, con un solo sequenziatore centralizzato, le transazioni di qualsiasi utente possono essere censurate.
Il sequenziatore può rifiutarsi di elaborare la transazione dell'utente, causando la trattenuta dei fondi dell'utente e l'impossibilità di lasciare il Rollup.
Meccanismo di inclusione della forza
Piuttosto che richiedere a Rollup di avere un gran numero di sequenziatori decentralizzati, è meglio utilizzare direttamente le capacità anti-censura di L1:
Originariamente, Sequencer deve impacchettare i dati delle transazioni e inviarli al contratto Rollup L1. È meglio aggiungere un design al contratto in modo che gli utenti possano inserire da soli le transazioni nel contratto Rollup. Questo meccanismo è chiamato "Inclusione forzata". Finché Sequencer non può censurare gli utenti a livello L1, non può impedire agli utenti di inserire forzatamente transazioni a L1. In questo modo Rollup può ereditare la resistenza alla censura di L1.
Il sequenziatore non può rivedere le transazioni L1 dell'utente senza pagare un costo elevato
Come dovrebbero avere effetto le transazioni forzate?
Se è possibile scrivere le transazioni direttamente nel contratto Rollup tramite l'inclusione forzata (ovvero, con effetto immediato), lo stato del rollup cambierà immediatamente. Ad esempio, Bob inserisce una transazione di "trasferimento di 1000 DAI a Carol" tramite l'inclusione forzata Se la transazione ha effetto immediato, il saldo di Bob nell'ultimo stato sarà di 1.000 DAI in meno e il saldo di Carol sarà di 1.000 DAI in più.
Se l'inclusione forzata può scrivere direttamente la transazione nel contratto Rollup e avere effetto immediato, lo stato cambierà immediatamente.
Se in questo momento il sequenziatore sta anche raccogliendo transazioni off-chain e invia il successivo batch di transazioni al contratto Rollup, potrebbe essere influenzato dalle transazioni che Bob inserisce forzatamente e avere effetto immediato. Questo tipo di problema deve essere evitato il più possibile, quindi Rollup generalmente non rende effettiva la transazione di inclusione forzata, ma consente prima all'utente di inserire la transazione nella coda di attesa su L1 e di entrare nello stato di "preparazione". .
Quando Sequencer impacchetta le transazioni fuori catena e le invia al contratto Rollup, sceglie se inserire le suddette transazioni nella sequenza delle transazioni. Se Sequencer ha ignorato queste transazioni nello stato di "preparazione", al termine del periodo finestra, l'utente. può forzare queste transazioni. Inserisci nel contratto Rollup.
Il sequenziatore può decidere quando "ricevere incidentalmente" le transazioni in attesa in coda
Il sequenziatore può comunque rifiutarsi di elaborare le transazioni nella coda di attesa.
Se il Sequencer rifiuta per un lungo periodo, dopo un certo periodo di tempo chiunque può forzare la transazione nel contratto Rollup attraverso la funzione Force Inclusion.
Successivamente, introdurremo in ordine l'implementazione del meccanismo di Force Inclusion di quattro noti Rollup, tra cui Optimism, Arbitrum, StarkNet e zkSync.
Il meccanismo di inclusione della forza dell’ottimismo
Innanzitutto, introdurremo il processo di deposito di Optimism. Questo deposito non si riferisce solo al deposito di denaro in Optimism, ma include anche "l'invio di informazioni inviate dagli utenti a L2" a L2. Dopo aver ricevuto il messaggio appena depositato, il nodo L2 convertirà il messaggio in una transazione L2 per l'esecuzione e lo invierà al destinatario designato del messaggio.
Messaggio dell'utente dal deposito L1 a L2
Contratto L1CrossDomainMessenger
Quando un utente desidera depositare token ETH o ERC-20 su Optimism, interagirà con il contratto L1StandardBridge su L1 attraverso la pagina web front-end, specificando quanto depositare e quale indirizzo L2 per ricevere questi asset.
Il contratto L1StandardBridge passerà il messaggio al contratto L1CrossDomainMessenger di livello successivo. Questo contratto viene utilizzato principalmente come componente per la comunicazione reciproca tra L1 e L2. L1StandardBridge comunica con L2StandardBridge su L2 attraverso questo componente di comunicazione generale per decidere chi può lanciare il token. in monete L2 o chi può sbloccare gettoni da L1.
Se uno sviluppatore ha bisogno di sviluppare un contratto che comunichi e sincronizzi lo stato tra L1 e L2, può crearlo sul contratto L1CrossDomainMessenger.
Il messaggio dell'utente viene passato da L1 a L2 tramite il contratto CrossDomainMessenger
Nota: in alcune immagini di questo articolo, CrossDomainMessager è scritto come CrossChainMessager
Contratto del Portale Ottimismo
Il contratto L1CrossDomainMessenger invierà quindi il messaggio al contratto OptimismPortal di livello inferiore. Dopo l'elaborazione, il contratto OptimismPortal genererà un evento chiamato TransactionDeposited. I parametri includono "la persona che ha inviato il messaggio", "la persona che ha ricevuto il messaggio". e relativi parametri di esecuzione.
Quindi il nodo Optimism L2 ascolterà l'evento Transaction Deposited generato dal contratto OptimismPortal e convertirà i parametri nell'evento in una transazione L2. L'iniziatore di questa transazione sarà il "mittente del messaggio" specificato nel parametro dell'evento Transaction Deposited il destinatario della transazione è la "persona che riceve il messaggio" nei parametri dell'evento e anche altri parametri della transazione derivano dai parametri negli eventi di cui sopra.
Il nodo L2 convertirà il parametro dell'evento Transaction Deposited di OptimismPortalemit in una transazione L2
Ad esempio, questa è una transazione in cui un utente deposita 0,01 ETH tramite il contratto L1StandardBridge. Questo messaggio e gli ETH vengono trasmessi fino al contratto OptimismPortal (l'indirizzo è 0xbEb5...06Ed) e quindi convertiti in un L2. transazione pochi minuti dopo:
L'iniziatore del messaggio è il contratto L1CrossDomainMessenger; il destinatario è il contratto L2CrossDomainMessenger su L2; il contenuto del messaggio è che L1StandardBridge ha ricevuto il deposito di 0,01ETH di BoB; Successivamente verranno attivati alcuni processi, come l’emissione di ulteriori 0,01 ETH su L2StandardBridge, che verranno poi trasferiti a Bob.
Come attivarlo nello specifico
Quando desideri forzare una transazione nel contratto Rollup di Optimism, l'effetto che desideri ottenere è consentire che una "transazione avviata ed eseguita su L2 dal tuo indirizzo L2" venga eseguita senza intoppi. In questo momento, dovresti utilizzare il tuo indirizzo L2 invia il messaggio direttamente al contratto OptimismPortal (nota che il contratto OptimismPortal è in realtà su L1, ma il formato dell'indirizzo dell'OP è lo stesso del formato dell'indirizzo L1. Puoi chiamare direttamente il contratto di cui sopra utilizzando l'account L1 con lo stesso indirizzo del Conto L2).
L'"iniziatore" della transazione L2 convertita dall'evento Transazione depositata generato dal contratto sarà il tuo conto L2. Al momento, il formato della transazione è coerente con la normale transazione L2.
Nella transazione L2 convertita dall'evento Transaction Deposited, l'iniziatore sarà Bob stesso il destinatario è il contratto Uniswap e sarà accompagnato dall'ETH specificato, proprio come Bob stesso ha avviato la transazione L2;
Se vuoi chiamare la funzione Force Inclusion di Optimism, devi chiamare direttamente la funzione depositTransaction del contratto OptimismPortal e inserire i parametri della transazione che vuoi eseguire in L2.
Ho fatto un semplice esperimento di inclusione forzata Questa transazione voleva realizzare una cosa: utilizzare il mio indirizzo per l'auto-trasferimento su L2 (0xeDc1...6909) e allegato un messaggio di testo di "inclusione forzata".
Questa è la transazione L1 in cui eseguo la funzione depositTransaction tramite il contratto OptimismPortal. Puoi vedere che nell'evento Transaction Deposited genera sia from che to are me stesso.
I valori nella restante colonna opaca Dati codificano "quanto ETH arriva con la persona che chiama la funzione di transazione di deposito", "quanto ETH l'iniziatore della transazione L2 vuole inviare al destinatario", "Transazione L2 GasLimit" e " ai dati del ricevitore L2" e altre informazioni.
Dopo aver decodificato le informazioni di cui sopra, otterrai:
"Quanti ETH sono stati allegati dalla persona che ha chiamato la transazione di deposito": 0, perché non ho depositato ETH da L1 a L2;
"Quanti ETH vuole inviare l'iniziatore della transazione L2 al destinatario": 5566 (wei)
"GasLimit per transazioni L2": 50000
"Dati per ricevitore L2": 0x666f72636520696e636c7573696f6e, che è la codifica esadecimale della stringa "force inclusion"
Non molto tempo dopo, è apparsa la transazione L2 convertita: una transazione L2 in cui ho trasferito denaro a me stesso, l'importo era 5566 wei e i dati erano la stringa "force inclusion". E puoi notare che il TxnType (tipo di transazione) in Altri attributi nella penultima riga nell'immagine mostra la transazione di sistema 126 (Sistema), il che significa che questa transazione non è stata avviata da me in L2, ma è stata depositata dalla transazione L1 Convertito dagli eventi.
Transazione L2 convertita
Se desideri chiamare il contratto L2 e inviare dati diversi tramite Force Inclusion, non è altro che compilare i parametri uno per uno nella precedente funzione di transazione di deposito. Ricordati solo di utilizzare lo stesso indirizzo L1 del tuo conto L2 per chiamare funzione di transazione di deposito, in modo che quando l'evento depositato viene convertito in una transazione L2, l'iniziatore è il tuo conto L2.
Finestra sequenziatore
Il nodo Optimism L2 menzionato in precedenza converte l'evento Transaction Deposited in una transazione L2. Infatti, questo nodo Optimism si riferisce al Sequencer. Dopotutto, questo è correlato alla sequenza delle transazioni, quindi solo il Sequencer può decidere quando convertire l'evento di cui sopra una transazione L2.
Durante l'ascolto dell'evento TransactionDeposited, il Sequencer non converte necessariamente immediatamente l'evento in una transazione L2. Può verificarsi un ritardo. Il valore massimo di questo periodo è chiamato SequencerWindow.
L'attuale finestra del sequenziatore sulla rete principale di Optimism è di 24 ore, ovvero, quando un utente deposita una somma di denaro da L1 o Forza include una transazione, lo scenario peggiore è che verrà inclusa nella cronologia delle transazioni L2 dopo 24 ore.
Meccanismo di inclusione della forza di Arbitrum
In Optimism, l'operazione Deposit di L1 genererà un evento Transaction Deposited, e il resto è attendere che il Sequencer raccolga le operazioni di cui sopra, ma in Arbitrum, le operazioni che si verificano in L1 (risparmio di denaro o invio di messaggi a L2, ecc.); .) verrà archiviato in L1 In una coda, anziché semplicemente lanciare un evento.
Al sequenziatore verrà concesso un periodo di tempo per includere le transazioni nella coda sopra nella cronologia delle transazioni L2. Se il sequenziatore non fa nulla allo scadere del tempo, chiunque può completarlo per il sequenziatore.
Arbitrum manterrà una coda nel contratto L1 Se il sequenziatore non elabora attivamente le transazioni nella coda, allo scadere del tempo, chiunque può forzare l'inclusione delle transazioni nella coda nella cronologia delle transazioni L2.
Nella progettazione di Arbitrum, le operazioni come i depositi che avvengono su L1 devono passare attraverso il contratto Delayed Inbox, come suggerisce il nome, le operazioni qui verranno ritardate per avere effetto; Il sequenziatore carica le transazioni L2 su L1. Ogni volta che il Sequencer carica una transazione L2, può estrarre alcune transazioni in sospeso dalla Posta in arrivo ritardata e scriverle nella cronologia delle transazioni.
Quando Sequencer scrive una nuova transazione, può estrarre la transazione da DelayedInbox e scriverla insieme.
Disegni complessi e materiali di riferimento eccellenti
Se i lettori fanno riferimento direttamente al capitolo ufficiale di Arbitrum su Sequencer e Force Inclusion, vedranno che menziona come funziona approssimativamente Force Inclusion, così come alcuni nomi di parametri e nomi di funzioni:
L'utente va prima al contratto DelayedInbox per chiamare la funzione sendUnsignedTransaction. Se Sequencer non viene incluso entro circa 24 ore, l'utente può chiamare la funzione forceInclusion del contratto SequencerInbox. Quindi il funzionario Arbitrum non ha allegato il collegamento della funzione al documento del sito Web ufficiale, quindi puoi solo guardare tu stesso la funzione corrispondente nel codice del contratto.
Quando trovi la funzione sendUnsignedTransaction, scopri che devi inserire tu stesso il valore nonce e il valore maxFeePerGas. Quale indirizzo è il nonce? Su quale rete è maxFeePerGas? Qual è il modo migliore per compilarlo? Non c'è alcun riferimento al file, nemmeno a Natpsec. Quindi troverai anche una serie di funzioni simili nel contratto Arbitrum:
SendL1FundedUnsignedTransaction, sendUnsignedTransactionToFork, sendContractTransaction, sendL1FundedContractTransaction, non c'è nessun documento che ti dica la differenza tra queste funzioni, come usarle, come compilare i parametri, nemmeno Natpsec.
Provi a compilare i parametri e inviare la transazione con la mentalità di provarla. Vuoi utilizzare tentativi ed errori per vedere se riesci a trovare l'utilizzo corretto, ma scopri che tutte queste funzioni eseguono AddressAliasing sul tuo indirizzo L1. , con conseguente errore finale su L2. Il mittente all'avvio della transazione è semplicemente un indirizzo diverso, quindi il tuo indirizzo L2 rimane immobile.
invia messaggio L2
Successivamente, ho cliccato accidentalmente su Ricerca Google e ho scoperto che Arbitrum ha una libreria Tutorial, che contiene script che dimostrano come inviare transazioni L2 da L1 (che è ciò che significa Force Inclusion), e le funzioni elencate in essa non sono nessuna delle funzioni menzionato sopra, ma una funzione chiamata sendL2Message e il parametro message è in realtà una transazione firmata con l'account L2?
Chi avrebbe mai saputo che il "messaggio inviato a L2 tramite Force Inclusion" sarebbe in realtà una "transazione L2 firmata"? E non c'è documentazione o Natspec che spieghi quando e come utilizzare questa funzione.
Conclusione: è problematico generare manualmente una transazione forzata Arbitrum. Si consiglia di seguire il Tutorial ufficiale ed eseguire l'SDK Arbitrum. A differenza di altri rollup, Arbitrum dispone di una chiara documentazione per gli sviluppatori e di note sul codice. Lo scopo e i parametri di molte funzioni mancano di spiegazioni, costringendo gli sviluppatori a dedicare più tempo del previsto per accedervi e utilizzarli. Ho anche chiesto al personale di Arbitrum su Arbitrum Discord ma non ho ottenuto una risposta soddisfacente.
Quando ho chiesto su Discord, l'altra parte mi ha detto solo di guardare sendL2Message. Non volevano spiegare le funzioni di altre funzioni (nemmeno sendUnsignedTransaction menzionata nel documento Force Inclusion), a cosa servono, come usarle. e quando utilizzarli.
Il meccanismo ForceInclusion di StarkNet
Sfortunatamente, StarkNet attualmente non dispone di un meccanismo ForceInclusion. Ci sono solo due articoli che parlano di censura e ForceInclusion sul forum ufficiale.
Impossibile dimostrare la transazione non riuscita
Il motivo di cui sopra è in realtà dovuto al fatto che il sistema di prova a conoscenza zero di StarkNet non può dimostrare una transazione fallita, quindi l'inclusione forzata non può essere consentita. Perché se qualcuno intenzionalmente (o involontariamente) forza l'inclusione di una transazione fallita che non può essere dimostrata, StarkNet verrà bloccato direttamente: perché dopo che la transazione è stata inclusa forzatamente, Prover deve dimostrare la transazione fallita, ma non ha modo di dimostrarla.
StarkNet prevede di introdurre la funzione di prova delle transazioni fallite nella versione v0.15.0, e quindi dovrebbe essere possibile implementare ulteriormente il meccanismo di inclusione forzata.
Meccanismo ForceInclusion di zkSync
La trasmissione dei messaggi L1->L2 di zkSync e il meccanismo di inclusione forzata vengono tutti eseguiti tramite la funzione requestL2Transaction del contratto MailBox. L'utente specifica l'indirizzo L2, i dati di chiamata, l'importo ETH aggiuntivo, il valore L2GasLimit, ecc. requestL2Transaction combinerà questi parametri in un L2 The. la transazione viene quindi inserita nella coda di priorità (PriorityQueue). Quando la transazione viene impacchettata e caricata su L1 (tramite la funzione commitBatches), il Sequencer indicherà quante transazioni estrarre dalla coda di priorità e le includerà nel record della transazione L2. .
zkSync è molto simile a Optimism sotto forma di Force Inclusion. Utilizza l'indirizzo L2 dell'iniziatore (coerente con l'indirizzo L1) per chiamare le funzioni correlate e inserire i dati (chiamato, calldata, ecc.), piuttosto che come Arbitrum Fill in una transazione L2 firmata; ma il design è lo stesso di Arbitrum, entrambi mantengono una coda in L1 e il sequenziatore estrae le transazioni in sospeso inviate direttamente dall'utente dalla coda e le scrive nel mezzo della cronologia delle transazioni.
Se vai a Deposit ETH tramite il bridge ufficiale di zkSync, come questa transazione, chiama la funzione requestL2Transaction del contratto MailBox. Metterà la transazione L2 di Deposit ETH nella coda di priorità e lancerà un evento NewPriorityRequest. Poiché il contratto codifica i dati della transazione L2 in una stringa di byte, è difficile da leggere. Se guardi i parametri di questa transazione L1, vedrai che il destinatario di L2 nei parametri è anche l'iniziatore della transazione (. perché è depositato su te stesso), quindi dopo un po', quando questa transazione L2 viene tolta dalla coda di priorità dal Sequencer e inclusa nella cronologia delle transazioni, verrà convertita in una transazione trasferita a se stessa su L2 e l'importo di il trasferimento è il deposito dell'iniziatore della transazione in L1 L'importo di ETH trasportato nella transazione ETH.
Nella transazione L1Deposit, l'iniziatore e il destinatario della transazione sono entrambi 0xeDc1...6909, l'importo è 0,03ETH e il calldata è vuoto.
Ci sarà una transazione di 0xeDc1...6909 che trasferisce denaro a te stesso su L2. Il tipo di transazione (TxnType) è 255, che è una transazione di sistema.
Quindi ho chiamato direttamente la funzione requestL2Transaction di zkSync e ho inviato un auto-trasferimento come ho fatto prima quando ho sperimentato la funzione di transazione forzata dell'OP: senza alcun ETH, il calldata ha portato la codifica HEX della stringa "force inclusion".
Quindi viene convertito nell'ultima transazione di L2 verso se stesso. Il calldata è la stringa esadecimale di "force inclusion": 0x666f72636520696e636c7573696f6e.
Quando il Sequencer estrae la transazione dalla PriorityQueue e la scrive nella cronologia delle transazioni, verrà convertita nella corrispondente transazione L2 su L2.
Attraverso la funzione requestL2Transaction, gli utenti possono utilizzare l'account L1 con lo stesso indirizzo L2 per inviare informazioni in L1, specificando il destinatario L2, l'importo ETH associato e i dati della chiamata. Se l'utente vuole richiamare altri contratti con Dati diversi, lo stesso si fa compilando uno per uno i parametri nella funzione requestL2Transaction.
Non esiste alcuna funzione che consenta agli utenti di forzare l'inclusione
Sebbene dopo che la transazione L2 sia stata inserita nella coda di priorità, il periodo di attesa per l'inclusione della transazione L2 nel sequenziatore verrà calcolato incidentalmente. Tuttavia, l'attuale progettazione di zkSync non dispone di una funzione di inclusione forzata che gli utenti possano applicare, ovvero equivalente a solo mezzo set. Vale a dire, anche se esiste un "periodo di attesa per l'inclusione", in realtà si tratta ancora di "vedere se il Sequencer vuole ricevere entrate": il Sequencer può attendere fino alla scadenza prima di ricevere la transazione, oppure non potrà mai ricevere alcuna transazione nella coda di priorità.
In futuro, zkSync dovrebbe aggiungere funzioni correlate in modo che gli utenti possano forzare l'inclusione della transazione nella cronologia delle transazioni L2 quando il periodo di validità del reddito è trascorso ma non è stato incluso nel Sequencer. Questo è un meccanismo di inclusione forzata veramente efficace.
Riassumere
L1 fa affidamento su un gran numero di validatori per garantire la "sicurezza" e la "resistenza alla censura" della rete. Rollup utilizza un numero limitato o addirittura un singolo sequenziatore per scrivere le transazioni e la sua resistenza alla censura è ancora più debole. Pertanto, Rollup necessita di un meccanismo di inclusione forzata per consentire agli utenti di bypassare il Sequencer e scrivere transazioni nella cronologia per evitare di essere revisionati dal Sequencer e rendere impossibile l'utilizzo e il prelievo di fondi dal Rollup.
L'inclusione forzata consente agli utenti di forzare la scrittura delle transazioni nella cronologia, ma nella progettazione devono scegliere se la transazione può essere immediatamente inserita nella cronologia e avere effetto immediato. Se si consente alle transazioni di avere effetto immediato, ciò avrà un impatto negativo sul sequenziatore, poiché le transazioni in attesa di essere ricevute su L2 potrebbero essere influenzate dalle transazioni ricevute forzatamente da L1.
Pertanto, l’attuale meccanismo di Force Inclusion del Rollup metterà innanzitutto le transazioni inserite su L1 in uno stato di attesa, e darà al Sequencer un periodo di tempo per reagire e scegliere se includere queste transazioni in sospeso.
Sia zkSync che Arbitrum mantengono una coda in L1 per gestire le transazioni L2 inviate dagli utenti da L1 o i messaggi a L2. Arbitrum si chiama DelayedInbox; zkSync si chiama PriorityQueue
Tuttavia, il modo in cui zkSync invia le transazioni L2 è simile a quello di Optimism. Utilizza l'indirizzo L2 per inviare messaggi a L1. Dopo la conversione in una transazione L2, l'iniziatore sarà l'indirizzo L2. La funzione di Optimism per inviare transazioni L2 si chiama depositTransaction; zkSync si chiama requestL2Transaction; Arbitrum genera e firma una transazione L2 completa, quindi la invia tramite la funzione sendL2Message Arbitrum ripristinerà il firmatario tramite la firma su L2 come iniziatore della transazione L2.
StarkNet attualmente non dispone di un meccanismo di inclusione forzata; zkSync è come un mezzo set di inclusione forzata: c'è una PriorityQueue e ogni transazione L2 nella coda ha un periodo di validità di inclusione, ma questo periodo di validità è attualmente solo per la decorazione. Il sequenziatore può scegliere di non includere alcuna transazione L2 nella PriorityQueue
