Well before @vitalik.eth was posting about social blobs, I was already seeing what would be the most optimal route to prove data on the network and interop with ethereum – that is why our bridge contract is structured the way it is:
- We don't use verkle trees due to lack of precompile support
- Blobs are structurally not PQ resistant due to ECC usage (which hardly matters, ethereum isn't really PQ resistant either, but it is something to be aware of as future tech debt)
We don't commit network roots to ethereum on a rolling basis, we instead shift that commitment burden to time-of-bridge, where whomever bridges to Ethereum is actively posting the new root as confirmed by validators: this way, we address the security benefit of L1 settlement while avoiding all the drawbacks of a social blobs approach.
1 Reply
{no channel}
- hash
- e38608f58ae4e8506d289ebfa17adfa45a5c1393
- timestamp
- 2026-08-25T03:46:03.000Z
- fid
- 1325
- parent_fid
- 1325
- parent_hash
- 69a9cce5f108484c38953ce20604e216149fc659