Content
@
https://warpcast.com/~/channel/walletbeat
0 reply
0 recast
0 reaction
polymutex
@polymutex.eth
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?
6 replies
5 recasts
25 reactions
Sebastian B眉rgel
@scbuergel
What sync committee do you use as a trust anchor in that? Merge block?
1 reply
0 recast
1 reaction
polymutex
@polymutex.eth
There is a mainnet checkpoint checked into the repo itself at `deploy/helios/data/checkpoint`, and there's a CI workflow updates it every few days: https://github.com/walletbeat/walletbeat/blob/beta/.github/workflows/helios-refresh.yaml Helios is also started with the `--strict-checkpoint-age` flag, which makes it refuse to start if that checkpoint is too old: https://github.com/walletbeat/walletbeat/blob/5ca663f98b5511caf08d5ee2bf67e466f2fd85a1/deploy/helios/helios-wrap.sh#L30-L36
1 reply
0 recast
1 reaction
Sebastian B眉rgel
@scbuergel
I'm curious what's the best way to guarantee the correctness of that trust anchor. I guess ultimately it would be reproducible builds that then get signed off by some governance mechanism (multisig would be an easy form of that) which is also in control of the ENS domain and can update once quorum has been reached?
1 reply
0 recast
1 reaction
polymutex
@polymutex.eth
I don't think you need governance here. My sense is that you could: - At time time T, load Helios with checkpoint from time T-1 and run it in a sandbox that records all the network traffic. - Look at the checkpoint for time T it produced. - Re-run Helios in a zkVM with a clock set back to time T. Block its external network access, but inject the incoming traffic you had recorded (behavior and incoming/outgoing network traffic should be exactly deterministic). - Re-verify that it produced the same checkpoint for time T. - Submit new checkpoint + proof of correct Helios execution from the zkVM. This effectively means that if you trust the checkpoint at time T-1 and that you trust Helios is correctly implemented and that the zkVM is as well, you can now also trust the checkpoint at time T.
2 replies
0 recast
1 reaction
polymutex
@polymutex.eth
@ncitron.eth How crazy of an idea is the above?
1 reply
0 recast
0 reaction
ncitron.eth
@ncitron.eth
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
