Stril4uk🛸
156 posts
Over half of total supply is reserved for KPI-based distribution Conditions → Gated to $MEGA stakers → Time staked impacts rewards (10d min, 30d max) → Unvested token can stake, but rewards share lock terms This puts rewards in the hands of those aligned with network growth
Had a very productive flight back from Copenhagen (thanks to the fact that the seat next to me was empty)! Managed to figure out a mathematical model that explains why MegaETH's new state trie data structure is scalable while MPT and its variants are not, however optimized their implementations are. This includes Verkle tries which were given quite some hope in speeding up state root update, as well as the various DBs optimized for MPT. I picked up the technique used in the analysis – approximating a random process with exploding state space using a memoryless process – when working on the rateless IBLT paper. It's an elementary technique, but it feels very fulfilling to successfully use the technique somewhere else! I will introduce the new data structure at the Science and Engineering of Consensus workshop (tselab.stanford.edu/workshop-sbc25/) during SBC. It will be the first time we talk about it in details even though it has been in prod on the testnet since day 1 : ) See you there!
MegaETH Official RPC vs Thirdweb RPC – Testnet Latency I wanted to pull direct data from the MegaEth without having to run any infra and was looking for the fastest way to do this. I used "comparenodes.com" to run a simple benchmark to see how MegaETH’s official RPC compares to a third-party RPC (Thirdweb). The goal was to check which one would pull fresh data from the explorer faster from different parts of the world. The test used the `eth_blockNumber` and the `eth_getBalance` RPC call on MegaETH testnet. It hits 27 AWS regions across 6 continents, sending requests one after the other with a one second gap. It tracked average latency, failures, 429 errors, successful requests, and total request duration. Here are the results comparenodes.com/global-node-co… comparenodes.com/global-node-co… All results showed that the official MegaETH RPC was faster in all six continents and all 27 regions. Latency for MegaETH ranged from about 126 ms to 238 ms according to this test. For Thirdweb latency ranged from about 170 ms to 381 ms. Both had low failure rates but MegaETH had slightly fewer, and the total request duration was consistently lower for MegaETH. For context, typically networks have at least a few regions where a third-party RPC is faster. Avalanche, Optimism, and Ethereum all have examples of this in public benchmarks. See the - Avalanche C-Chain results comparenodes.com/global-node-co… - Optimism results comparenodes.com/global-node-co… - Ethereum results comparenodes.com/global-node-co… MegaETH beating Thirdweb everywhere is not typical. My thesis on why MegaETH Official rpc comes out top is that the network is well tuned architecturally , and uses a single sequencer at a time. I invite @NamikMuduroglu @yangl1996 @0xSami_M to share their thoughts This is testnet so the numbers could shift on mainnet when traffic is heavier. However for now, if you need the fastest and most reliable way to pull data from the MegaETH explorer, the official RPC is the clear choice. NB: I am not an expert, tis is just theoretical and may not be 100% accurate as the data tested were lightweight calls, also these results were snapshotted, results may vary if larger data is involved at different times, lastly i used a public thirdweb rpc, there could be other faster ones.
Updating the state root is crazily slow and is responsible for an up to 10x slowdown when building EVM blocks. SALT is MegaETH's solution to this problem. SALT is a brand new authenticated key-value store that replaces (instead of being a mere reimplementation of) EVM's Merkle Patricia Trie (MPT). It is optimized for just one thing: take as little space as possible so as to fit in computers' RAM. This goal is supposedly easy to achieve by tuning the MPT and making it wide and shallow, but to think so one overlooks a key issue: key sparsity. Our theory + experiments (lots of details in the talk) show that sparsity inflates the sizes of MPT and friends (such as the venerable Verkle Tries, unfortunately) by hundreds of times. Consequently, they have to overflow to slow and clunky hard drives which kills performance. (Remember the 10x slowdown?) By taming sparsity, SALT is able to get infinitely close to optimality. In fact, it is optimal in space and IO usage! The bottleneck of updating state roots has been solved once and for all. Check out the recording of the talk! The talk was presented at the Science and Engineering of Consensus workshop during SBC 25. Huge thanks to the Tse Lab at Stanford University for organizing the event, and to event sponsors @babylonlabs_io and @poddotnetwork!
