ncitron.eth

@ncitron.eth

447 Following

2777 Followers

EulerLagrangodamus pfp

EulerLagrangodamus

Helios and @ncitron.eth really came in clutch for us when we under the gun. Stay tuned for updates. Severely under utilized tech. In future of protocol design Helios will certainly play a key role. Great place to earn some github cred if you’re brave enough to work at Noah’s pace.

0 reply

1 recast

5 reactions

polymutex pfp

The code for integrating a light client in a TypeScript wallet literally fits in a screenshot.

2 replies

2 recasts

5 reactions

ncitron.eth pfp

Light clients are getting better and better!

1 reply

2 recasts

13 reactions

ncitron.eth pfp

Helios 0.9.0 continues to make running an Ethereum light client more accessible. Full release notes and documentation available at https://github.com/a16z/helios

0 reply

0 recast

2 reactions

ncitron.eth pfp

Network support expanded with Hoodi testnet. This allows developers to run Helios on the new testnet.

1 reply

0 recast

1 reaction

ncitron.eth pfp

Infrastructure update: Helios now uses Alloy v1.0, marking a significant milestone as the library reaches its stable 1.0 release. All related dependencies have been updated accordingly.

1 reply

0 recast

1 reaction

ncitron.eth pfp

Custom Virtual Machine support has been added. The refactored architecture allows for different execution environments beyond standard Ethereum execution.

1 reply

0 recast

1 reaction

ncitron.eth pfp

JavaScript tooling has moved from Webpack to Vite. This provides a better developer experience with faster builds and support for both ESM and UMD module formats. We've also published an NPM package for easy use.

1 reply

0 recast

1 reaction

ncitron.eth pfp

We have published TypeScript bindings to NPM. JavaScript and TypeScript developers can now easily integrate Helios light client functionality into their applications with full light client support.

1 reply

1 recast

3 reactions

ncitron.eth pfp

Transaction processing now runs in parallel, reducing latency across the board. Operations that previously ran sequentially now utilize multiple CPU cores for better performance.

1 reply

0 recast

2 reactions

ncitron.eth pfp

Historical block access is now available through a new pluggable provider system. Previously, Helios couldn't access historical blocks. Now it can retrieve old blocks while maintaining security through full light client verification across all supported networks.

1 reply

0 recast

2 reactions

ncitron.eth pfp

New Terminal Interface: Run Helios with --tui to monitor your node in real-time. View current blocks, sync status, and recent block history in a clean interface that updates automatically.

1 reply

0 recast

3 reactions

ncitron.eth pfp

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

4 replies

8 recasts

71 reactions

ncitron.eth pfp

Well as long as you run Helios every so often you don't need to worry about this at all. As for the scheme you described, how would you know someone else had faithfully run Helios actually at the previous time? The invariant you need to maintain is that at least ever week subjectivity period, someone actually ran it *at that time*. In other words any system that timestamps that a checkpoint existed at or around the time its from works. This is why schemes like submitting checkpoints on bitcoin make sense, since PoW is a great timestamping system. For what it's worth, I don't think we need to worry to much about these "long range attacks" on Helios. They aren't particularly realistic especially compared to the light clients existing security model. These attacks are basically predicated on the idea that once a validator withdraws its stake, it's easy to get its key and sign a malicious fake block with it. I think it's just as easy (so pretty hard) to bribe a more recent such committee to sign a bad block.

0 reply

0 recast

2 reactions

polymutex pfp

Walletbeat now automatically deploys to IPFS via @orbiterhost, then updates ENS records. Yes, it uses Helios as a light client when interacting with the chain. Imagine 𝘯𝘰𝘵 using a light client in 2025. Utterly inconceivable, especially for wallets, right?

5 replies

4 recasts

25 reactions

ncitron.eth pfp

Well there's the storage unit system as well. But you're right that the existing protocol doesn't really charge for usage during bursty periods. Using some identity system for priority during these periods is actually a good idea.

2 replies

0 recast

1 reaction

ncitron.eth pfp

I suspect a combination of things like WorldID and zkTLS could achieve a decent spam metric, but the bigger question is should these systems actually be built at the protocol level. Honestly don't know the answer. Dan seems to get the risks though of popular clients having defacto control of what gets reached in a non-protocol based spam detection. But if we did it at the protocol level, would we be buying anything of use? Clients can still put their own filtering on top of that, so arguably a protocol level spam filtering solution would only provide a base level of filtering and doesn't enforce what subset of the post-protocol-filtered content is shown. What does protocolizing that actually buy us then? It doesn't enforce any notion of censorship resistance (because clients can still filter you). I don't see the benefit of buying this "base filtering" from a company vs protocol.

1 reply

0 recast

3 reactions

ncitron.eth pfp

New and improved Helios demo showing off Helios running on four separate networks all in the browser. https://helios.a16zcrypto.com/demo

1 reply

4 recasts

14 reactions

ncitron.eth pfp

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

0 reply

7 recasts

48 reactions

ncitron.eth pfp

RISC-V being the semi-canonical zkVM target makes this nice, but tbh R5 is not the best VM target out there for native execution. It was designed for physical chips so isn't actually optimized for virtualization as much as something like wasm is (although wasm has its own problems like high performance deterministic execution). I'm broadly in favor though.

0 reply

0 recast

1 reaction