Helios 0.9.0 is now available! This release is packed with new features and improvements:
• A functional TUI
• Historical block access support
• Parallel transaction processing
• TypeScript bindings on NPM
• A new interface for custom VM integrations
New Helios release!
Version 0.8.6 enables pectra on Ethereum mainnet.
This is a required upgrade and most be installed by the fork on May 7th.
Upgrading is as simple as running heliosup in your terminal.
https://github.com/a16z/helios/releases/tag/0.8.6
We've added @linea support to Helios!
This makes Linea our second supported L2 with more to come soon.
Huge shoutout to the @mendifinance team for building the implementation!
Head over to our GitHub to get started using Helios on Ethereum, Linea, or the Optimism Superchain!
https://github.com/a16z/helios
Helios is becoming a multichain light client for Ethereum.
Light clients are fundamental to Ethereum scaling. A future with thousands of rollups doesn’t feel far away, and the closer we get, the more critical rollup interoperability will become.
🧵👇
The proliferation of light clients will drive the costs of RPCs down.
Without light clients there is a strong centralizing pressure on RPCs since their most valuable asset is reputation. This should in theory lead to high prices.
With light clients, trust is no longer a factor, allowing more competition and lower prices.
Be stingy, run a light client.
Should Farcaster decouple clients from algorithms and moderation?
We could design a common api specification that allows algorithm providers to be plugged in to any existing client.
The main thing against this I think is that it's not clear to me whether the algorithm is actually the main product a client provides.
Came up with a new NYC route.
I tried running over the Williamsburg Bridge into Brooklyn and followed under the elevated J/M line for the rest. Took the train back when I was done.
There's a stop every quarter mile or so and most importantly you don't have to run over the bridge twice.
Why are people proposing switching the state to a starked binary merkle tree instead of a ternary merkle tree?
The total amount of hashed data should be proportional to log_a(n)*a where a is the arity of the tree. This function has a minimum at e, which is closer to 3 than 2.
This correlates to a ~5% savings in amount of hashed data by using ternary over binary.
