Abbiamo letteralmente quel livello di prestazioni in TOOL. Utilizza un consenso non-BFT a bassa latenza per raggiungere la transizione di stato comune per tutti gli utenti che cercano di entrare nel blocco successivo. Quindi è limitato solo dalla larghezza di banda della catena sottostante. Ma se lo implementiamo su una catena con spazio per blocchi abbondante (siamo aperti a richieste 😁), sicuramente eguaglierà le prestazioni di Mega, pur essendo più flessibile rispetto al suo modello di sequencer a rotazione tz.
BREAD | ∑:
BREAD | ∑:1 nov, 23:37
Il grande contro che ogni alt-L1 porterà a Mega è "possiamo fare anche pre-confs, bro"—ma non è quello il livello superiore. Il livello superiore è che possiamo eseguire tx nello stesso tempo delle loro pre-confs MA POSSIAMO ANCHE RIFLETTERE IMMEDIATAMENTE QUESTO AGLI ALTRI UTENTI. Possiamo farlo perché offriamo garanzie del 99.999% che una volta che quella ricevuta tx viene data a loro (<10ms di tempo di esecuzione + distanza dal sequencer) è definitiva. C'è un rischio ~0 che quella transazione venga esclusa. Questa fiducia significa che altri utenti possono AGIRE IMMEDIATAMENTE su quelle informazioni senza preoccuparsi che non sia vero a causa di qualcosa al di fuori del loro controllo. Composabilità istantanea dell'ecosistema. Questo accadrà a una soglia inferiore a ciò che è letteralmente possibile per le catene con consenso. Tipo, dovrebbero ridefinire la fisica. Quindi, a meno che queste alt-chain non pianifichino di far rivivere Sir Isaac Newton per portarlo sulla fondazione, saranno per sempre svantaggiate rispetto a Mega. Ecco un esempio dello stesso team che dimostra come interagiscono 2 prospettive utente. Uno che acquista e l'altro che ottiene il proprio prezzo sulla curva immediatamente aggiornato, perché quel nuovo prezzo è il prezzo permanentemente nuovo e non "probabilmente il nuovo prezzo per i prossimi 3s." La cosa incredibile è che @problemchild non pensa che questo sia lo stato finale e c'è ancora più succo da spremere per la sua app per consumatori. Sono pronto a mettere queste cose in pubblico per ottimizzatori per vedere fino a che punto può essere portato.
La cosa interessante è che per essere il più performante, TOOL non richiede la colocalizzazione con i validatori L1, ma piuttosto una colocalizzazione dei partecipanti a TOOL, in modo che possano riassegnare dinamicamente la loro infrastruttura tra le regioni per trovarsi dove avviene la maggior parte dell'attività, mentre non è nemmeno un requisito rigoroso, quindi il sistema sarà più ridondante e aperto a diversi modelli di utilizzo che si evolveranno naturalmente.
A dire il vero, penso che il miglior scenario possibile sia molto più facile da raggiungere con il tuo modello, ma è anche un compromesso poiché costringe a modelli di utilizzo specifici. Quindi non dirò che TOOL è più performante o "molto migliore" di Mega, poiché operiamo su piani diversi dello spazio di compromesso. Ma certamente non è "peggiore" in generale haha.
Quindi, nel complesso, mi sento supportivo e curioso di vedere come si svilupperà il ciclo di adozione di Mega, e non penso che sia un concorrente molto diretto di TOOL al momento, poiché Mega è un L2 massimamente opinato, mentre TOOL è un framework neutro per L1, il cui obiettivo è essere abbastanza flessibile da rappresentare le esigenze della base utenti sottostante, senza costringerli a comportarsi in un modo particolare o a ridisegnare le app da zero.
16,06K