EVM Storage proofs Fuse.io generic bridge - 4K$ worth of G$+Fuse tokens

[sirpy]

Motivation

The GoodDollar protocol needs a secure and robust bridge to the Fuse network, for scaling TXs and also Voting. Also having a generic evm bridge would make supporting other EVM based blockchains easier.

To get approved you must read the link below and contact us on our telegram channel

To get started please read about our bounty mentorship program here: https://github.com/GoodDollar/Bounties/

Details

See proposal on Fuse forum for more context:

Part 1 - Block headers registry contract - 1000$

The purpose of the contract is to store on Fuse, block headers from different blockchains signed by the Fuse validators.

• [x] Most write methods to this contract should be limited to current validators
• [x] The contract should hold validator signatures per blockhash (ie mapping blockhash -> SignedBlock)
• [x] The contract should hold mapping from blockchain+block_number -> array<blockhashes>

  SignedBlock {
  signatures:bytes[],
  cycleEnd: uint256, //just for fuse
  validators: address[],//just for fuse
  hasValidatorSigned: mapping<address> -> bool, //to prevent double signatures
  }

• [ ] the contract will hold a mapping of blockhash -> BlockHeader

  Header {
  parent_hash: bytes32
  timestamp: uint256,
  number: uint256,
  author: address,
  transactions_root: bytes32,
  uncles_hash: bytes32,
  extra_data: bytes,
  state_root: bytes32,
  receipts_root: bytes32,
  log_bloom: bytes,
  gas_used: uint256,
  gas_limit: uint256,
  difficulty: uint256,
  mixHash:bytes32,
  nonce:uint256
  }

  Block {
  header: BlockHeader,
  rlpHeader: bytes,
  signature: bytes,
  blockchainId: uint256,
  blockHash: bytes32,
  validators: address[],
  cycleEnd: uint256
  }

• [x] internal method _addSignedBlock(blockchainid,blockheader,blockhash,signature)
  • if blockhash doesnt exists yet, verify hash(blockheader) = blockhash and store header
  • verify signature is of the blockhash and by the msg.sender validator
  • verify validator didnt already submit this block (probably need another mapping for that)
  • add the validator signature for that specific blockhash
  • add blockhash to (blockchain+blocknumber) -> blockhashes mapping
• [x] view getSignedBlock(blockchain,block number):(rlpHeader, Array<signatures>, Array<validators>, cycleEnd) - returns the data for the block with most signatures
• [x] internal method `_addFuseSignedBlock(blockheader,blockhash,validators,cycleend,signature)
  • should perform the same as addSignedBlock just with added logic
  • key for blockhash mapping is defined as hash(blockhash,validators,cycleEnd)
  • signature is also expected to match digest of hash(blockhash,validators,cycleEnd)
• [x] method addSignedBlocks(Block[] blocks) - the main entry to bulk add blocks
• [x] method addBlockchain(blockchainId, rpc: string) onlyvoting - keeps a list of blockchains that validators should read blocks from
• [ ] unit tests

  Part 2 - Extend Fuse validators' nodejs app - 1500$

• [ ] read list of extra blockchains + RPCs from registry contract. By default fuse+ethereum+bsc are always enabled no matter if they are in the list or not
• [x] create provider connections and listen to new blocks (for example etherjs provider.on("block") - https://docs.ethers.io/v5/api/providers/provider/#Provider--event-methods)
• [x] on each incoming sign the blockhash and push block data (see data type Block) to an array
  • for fuse read from consensus the cycleEnd value and the current validators value
  • notice that for fuse sealFields is instead of mixhash/digest and nonce
  • notice that for different blockchains the author/mixdigest fields can be named differently, coinbase,miner etc..
• [x] set timer for every X seconds to publish the signed blocks
  • clone the blocks array
  • reset the original array
  • call addSignedBlocks
• [ ] error handling
  • listen to provider errors and try to reconnect
  • catch fuse read/write tx errors and add a retry (ie something like the package @jsier/retrier
  • [ ] unit tests

    Part 3 - Custom Bridge POC - 1500$

    Create a smart contract that is able to verify a new Fuse signed block data and also that is able to verify some other block was signed by X validators in the past using storage proofs on latest block

• [ ] initialize - initialize the contract with a given set of validators
• [ ] method to set the latest Fuse block. setLatestBlock(BlockHeader,validators,cycleEnd, signatures)
  • require that block number > last blocknumber
  • require signatures are:
    • of digest (blockhash,validators,cycleEnd)
    • signed by validator in existing validator set

    • 66% validators in set

  • if blocknumber > stored cycleEnd then update the validator set
  • store latest block, cycleEnd
• [ ] method to prove a past block was signed by X validators. provePastBlock(blockhash, validators, cycleEnd, storageProof)
  • use storage proofs to prove that last block submited contains in the SignedBlock mapping an entry for hash(blockhash,validators,cycleEnd) and that this entry signatures field length >= 66% validators
  • https://docs.soliditylang.org/en/v0.6.6/miscellaneous.html#layout-of-state-variables-in-storage
  • https://github.com/aragon/evm-storage-proofs
  • https://github.com/lidofinance/curve-merkle-oracle/blob/main/contracts/StableSwapStateOracle.sol
  • https://github.com/zmitton/eth-proof
  • https://github.com/KyberNetwork/peace-relay
  • https://github.com/PISAresearch/event-proofs

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

This issue now has a funding of 20000000.0 G$ (4000.0 USD @ $0.0/G$) attached to it as part of the GoodDollar fund.

• If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
  • Want to chip in? Add your own contribution here.
  • Questions? Checkout Gitcoin Help or the Gitcoin's Discord
  • $5,691,669.14 more funded OSS Work available on the Gitcoin Issue Explorer

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

Workers have applied to start work.

These users each claimed they can complete the work by 264 years, 11 months from now. Please review their action plans below:

1) janu939 has applied to start work _(Funders only: approve worker | reject worker)_.

Give me token please sir🥳🥳 To the moon sir

Learn more on the Gitcoin Issue Details page.

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

Work has been started.

These users each claimed they can complete the work by 264 years, 10 months from now. Please review their action plans below:

1) pmlambert has been approved to start work.

Would love to get a chance to work on these tasks. 2) sdmg15 has been approved to start work.

I’ll take over the first part and complete it

Learn more on the Gitcoin Issue Details page.

[pmlambert]

@sirpy https://github.com/pmlambert/block-header-registry

[pmlambert]

@sirpy Please begin reviewing the solidity code, all that's left ift the getter function for a signed block.

[sirpy]

@pmlambert nice. so far so good. once you get 100% coverage I can approve the first part. also the onlyValidator isnt complete

[sirpy]

@pmlambert also please touch base on telegram

[gitcoinbot]

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

---

Work for 20000000.0 G$ (4000.0 USD @ $0.0/G$) has been submitted by:

1. @pmlambert

@sirpy please take a look at the submitted work:

• PR by @pmlambert

---

• Learn more on the Gitcoin Issue Details page
• Want to chip in? Add your own contribution here.
• Questions? Checkout Gitcoin Help or the Gitcoin's Discord
• $5,885,822.89 more funded OSS Work available on the Gitcoin Issue Explorer

[sirpy]

@pmlambert thanks. due to corona and stuff i'll get to it only next week. i'd appreciate it if you can add automated github actions to run tests + show coverage

[sirpy]

@pmlambert

1. re-read the definition for how a fuse block should be added and saved specifically the hash of the blockchain should be hash(blockhash,validators, cycleend)
2. can you make tests more succint , DRY.