Content pfp
Content
@
https://warpcast.com/~/channel/walletbeat
0 reply
0 recast
0 reaction

polymutex pfp
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 pfp
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 pfp
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 pfp
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 pfp
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 pfp
polymutex
@polymutex.eth
@ncitron.eth How crazy of an idea is the above?
1 reply
0 recast
0 reaction

Sebastian B眉rgel pfp
Sebastian B眉rgel
@scbuergel
That's an interesting way!
0 reply
0 recast
1 reaction