search

harmony-one / horizon

Horizon - a trustless harmony to ethereum bridge
MIT License
36 stars 29 forks source link

Limiting the storage of headers on both light clients #22

Closed gupadhyaya closed 2 years ago

gupadhyaya commented 2 years ago

Currently, both light clients are configured to store header data forever. This could easily grow the storage and make the lightclient unusable. There needs to be limits on how many days/months of header data is stored.

hashmesan commented 2 years ago

The rainbow bridge implementation trims at 7 days worth of blocks. That's trivial. One issue I might see is the user who didn't have a chance to validate their proof with a tx 7 or more days ago. It could be for a number of reasons including, congestion, bridge down time, or technical issues that we need to help manually run. Any thoughts? investigating a few more bridges..

hashmesan commented 2 years ago

Rainbow bridge uses a DAG Merkle tree to keep entire history root hashes

    /// DAG merkle roots for the next several years.
    dags_merkle_roots: Vec<H128>,
hashmesan commented 2 years ago

SSTORE costs 20,000 gas to store each 32-byte word of data, while CREATE2 costs 32,000 gas (with a little extra for the cost of hashing the contract initialization code), plus 200 gas for each byte stored to the runtime code of the contract, which comes out to 6,400 gas for each stored word

Considering the storage and gas usage even with trimming, I recommend implement full patrcia merkle tree/proof/verify. There are enough examples out there to port, and validate.

This is a good client side/relayer side to generate the proof with good reference code to ethashproof golang repo: https://github.com/aurora-is-near/rainbow-bridge/blob/master/eth2near/ethashproof/cmd/relayer/main.go

brucdarc commented 2 years ago

So essentially, we should store a merkle root of past blocks, and then if someone really needs to verify a past block, they can submit a merkle proof for that block, which we loop through and verify?

Which would mean also we need to either recompute the merkle root each time blocks are garbage collected, have a different merkle roots for different time periods (ex. every month), or use a merkle mountain range yes?

Verifying a merkle root is something I've already done in solidity, but we need to hash out the details of what this root actually represents, and if we recompute it periodically, or have multiple