Argomenti di tendenza
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Lei Yang Σ:
Responsabile dell'alimentazione dei coniglietti presso @megaeth_labs. Recente dottorato di ricerca presso il MIT CSAIL. Lavorare su reti di calcolatori e sistemi distribuiti (per blockchain).
Lei Yang Σ: ha ripubblicato
Non abbiamo mai chiesto ricavi o quote di consulenza a nessun team di @0xMegaMafia.
L'unica volta in cui sono stati menzionati i riacquisti di token è stata quando i team hanno chiesto vantaggi strutturali come la co-locazione anticipata e l'emissione di asset, il che sarebbe stato ingiusto per altri costruttori nell'ecosistema.
In questa situazione, il riacquisto di token è giustificato perché la comunità deve beneficiare dal fatto che diamo questi vantaggi ai progetti.
Tutti possono costruire su MegaETH.
43,96K
Aggiornare la radice di stato è incredibilmente lento e causa un rallentamento fino a 10 volte durante la costruzione dei blocchi EVM. SALT è la soluzione di MegaETH a questo problema.
SALT è un nuovissimo archivio chiave-valore autenticato che sostituisce (anziché essere una mera reimplementazione di) il Merkle Patricia Trie (MPT) dell'EVM. È ottimizzato per una sola cosa: occupare il minor spazio possibile per adattarsi alla RAM dei computer.
Questo obiettivo dovrebbe essere facile da raggiungere ottimizzando l'MPT e rendendolo ampio e poco profondo, ma a pensarla in questo modo si trascura un problema chiave: la scarsità delle chiavi. La nostra teoria + esperimenti (molti dettagli nella presentazione) mostrano che la scarsità gonfia le dimensioni dell'MPT e dei suoi simili (come i venerabili Verkle Tries, purtroppo) di centinaia di volte. Di conseguenza, devono traboccare su dischi rigidi lenti e ingombranti, il che uccide le prestazioni. (Ricordi il rallentamento di 10 volte?)
Domando la scarsità, SALT è in grado di avvicinarsi infinitamente all'ottimalità. Infatti, è ottimale in termini di spazio e utilizzo di IO! Il collo di bottiglia nell'aggiornamento delle radici di stato è stato risolto una volta per tutte.
Guarda la registrazione della presentazione! La presentazione è stata effettuata al workshop sulla Scienza e Ingegneria del Consenso durante il SBC 25. Un enorme grazie al Tse Lab della Stanford University per aver organizzato l'evento e agli sponsor dell'evento @babylonlabs_io e @poddotnetwork!
50,15K
Questi sono alcuni risultati interessanti. È sempre bello vedere MegaETH in cima : )
Per contestualizzare i dati, la latenza end-to-end di una richiesta RPC è composta da tre componenti: (1) la latenza di propagazione della velocità della luce da/per l'osservatore al/server, (2) il tempo necessario al server per acquisire e post-elaborare i dati richiesti, (3) il tempo necessario all'osservatore per scaricare la risposta. Come hai menzionato, i metodi RPC testati sono più leggeri, sia in termini di costo computazionale che di dimensione dei dati. Questo significa che gli esperimenti hanno principalmente testato (1), cioè la latenza di propagazione tra gli osservatori e i server RPC. Non fraintendermi: gli RPC di MegaETH sono anche piuttosto forti su (2) e (3) e sarebbe interessante vedere esperimenti che li mettano alla prova!
Quindi, come possiamo ottimizzare la latenza di propagazione? In realtà, non ci sono molte leve. Prima di tutto, possiamo distribuire i server RPC in più regioni geografiche e instradare automaticamente le richieste al server più vicino. È come se le catene di fast food aprissero negozi ovunque: c'è sempre un ramo nelle vicinanze! Più precisamente, avere server geo-distribuiti riduce la distanza fisica tra utenti e server.
In secondo luogo, possiamo ottimizzare la topologia di rete. Anche se si tratta della stessa coppia di mittente e destinatario, la latenza di propagazione varia in base al percorso di rete effettivamente percorso. Ad esempio, tra la costa est degli Stati Uniti e l'Asia, la latenza può variare di 2x a seconda che i pacchetti di dati passino attraverso il Pacifico o attraverso l'Europa. A volte, ci sono anche più percorsi di rete che seguono la stessa rotta geografica; alcuni sono più congestionati di altri, il che induce una latenza più alta. È come avere più autostrade tra il punto A e il punto B. I vantaggi di latenza che hai osservato sono probabilmente derivati dall'ottimizzazione del percorso da parte nostra.
15 ago, 21:38
MegaETH Official RPC vs Thirdweb RPC – Latenza del Testnet
Volevo estrarre dati direttamente da MegaEth senza dover gestire alcuna infrastruttura e stavo cercando il modo più veloce per farlo.
Ho utilizzato "" per eseguire un semplice benchmark per vedere come l'RPC ufficiale di MegaETH si confronta con un RPC di terze parti (Thirdweb). L'obiettivo era verificare quale dei due avrebbe estratto dati freschi dall'explorer più velocemente da diverse parti del mondo.
Il test ha utilizzato la chiamata RPC `eth_blockNumber` e `eth_getBalance` sulla testnet di MegaETH. Ha colpito 27 regioni AWS in 6 continenti, inviando richieste una dopo l'altra con un intervallo di un secondo. Ha tracciato la latenza media, i fallimenti, gli errori 429, le richieste riuscite e la durata totale delle richieste.
Ecco i risultati
Tutti i risultati hanno mostrato che l'RPC ufficiale di MegaETH era più veloce in tutti e sei i continenti e in tutte le 27 regioni. La latenza per MegaETH variava da circa 126 ms a 238 ms secondo questo test. Per Thirdweb, la latenza variava da circa 170 ms a 381 ms. Entrambi avevano tassi di fallimento bassi, ma MegaETH ne aveva leggermente meno, e la durata totale delle richieste era costantemente inferiore per MegaETH.
Per contesto, tipicamente le reti hanno almeno alcune regioni in cui un RPC di terze parti è più veloce. Avalanche, Optimism ed Ethereum hanno tutti esempi di questo in benchmark pubblici. Vedi i
- Risultati di Avalanche C-Chain
- Risultati di Optimism
- Risultati di Ethereum
MegaETH che supera Thirdweb ovunque non è tipico.
La mia tesi sul perché l'RPC ufficiale di MegaETH risulti il migliore è che la rete è ben sintonizzata architettonicamente e utilizza un singolo sequencer alla volta.
Invito @NamikMuduroglu @yangl1996 @0xSami_M a condividere i loro pensieri
Questo è un testnet, quindi i numeri potrebbero cambiare su mainnet quando il traffico è più intenso. Tuttavia, per ora, se hai bisogno del modo più veloce e affidabile per estrarre dati dall'explorer di MegaETH, l'RPC ufficiale è la scelta chiara.
NB: Non sono un esperto, questo è solo teorico e potrebbe non essere 100% accurato poiché i dati testati erano chiamate leggere, inoltre questi risultati sono stati snapshot, i risultati potrebbero variare se sono coinvolti dati più grandi in momenti diversi, infine ho utilizzato un RPC pubblico di thirdweb, potrebbero esserci altri più veloci.
12,61K
Batti batti, il momento Robinhood per le criptovalute sta arrivando!
8 ago, 00:43
100 delle menti più brillanti nel crypto hanno appena fatto la stessa scommessa.
Abbiamo assemblato una coalizione selezionata di costruttori, trader e utenti esperti per sostenere l'app consumer innovativa che la nostra industria stava aspettando.
Ciò che Robinhood ha fatto per il tradfi, Euphoria lo farà per il crypto.
Tap Trading sta arrivando 👇🧵
2,58K
Ho avuto un volo molto produttivo di ritorno da Copenaghen (grazie al fatto che il posto accanto a me era vuoto)!
Sono riuscito a elaborare un modello matematico che spiega perché la nuova struttura dati trie di stato di MegaETH è scalabile mentre MPT e le sue varianti non lo sono, indipendentemente da quanto siano ottimizzate le loro implementazioni. Questo include i Verkle tries, che avevano suscitato molte speranze per accelerare l'aggiornamento della radice di stato, così come i vari DB ottimizzati per MPT.
Ho appreso la tecnica utilizzata nell'analisi – approssimare un processo casuale con uno spazio di stato esplosivo usando un processo senza memoria – mentre lavoravo sul documento IBLT senza rateo. È una tecnica elementare, ma è molto gratificante riuscire a utilizzare la tecnica in un altro contesto!
Introdurrò la nuova struttura dati al workshop Science and Engineering of Consensus (durante SBC). Sarà la prima volta che ne parleremo in dettaglio, anche se è in produzione sulla testnet sin dal primo giorno : ) Ci vediamo lì!
31,64K
Principali
Ranking
Preferiti