EthDenver Technical Preparation

[MaksymZavershynskyi]

@kcole16 is going to be presenting on February 13. So the deadline is February 12.

We will be using testnet for the EthDenver, because all our online documentation is pointing to the testnet and was not updated to support stagingnet.

Here is the list of items that we want to have for the EthDenver:

• Working eth-bridge that people can use for the development.
  • Since eth-bridge needs certain features that are not available in testnet (master branch) we need to cherry-pick them into master:
    • Allow floats;
    • Add keccak function.
  • Eth bridge needs to support verifying Eth events on Near side and Near events on Eth side.
    • Add Eth events verifier;
    • Add Near events verifier;
      • Add feature to near-bindgen that allows storing events in a single key-value.
  • Eth bridge needs to be fast and use less gas. Currently relayer takes ~5 seconds to compute Eth header that it submits to near-bridge, add it takes ~10 seconds to run the Near smart contract, 80% of which is deserializing JSON. This puts us in total 15 seconds which is slower than the block production rate by Ethereum. Also, we need smart contract to run under 0.2 seconds to pass our limiters.
    • We need to replace JSON with Borsh serialization of arguments in near-bindgen;
    • We need to optimize smart contract to use env::collections::*
• We will be running EthDenver of the testnet therefore we want to practice starting/restarting testnet;

[ilblackdragon]

@nearmax @k06a for Eth Bridge events needs, given we don't have events - what kind of support is actually needed? Why not store whatever value is needed in specified by contract key?

[MaksymZavershynskyi]

@nearmax @k06a for Eth Bridge events needs, given we don't have events - what kind of support is actually needed? Why not store whatever value is needed in specified by contract key?

@ilblackdragon
There is a terminology collision. Let's call this "changes": #1910 , because they are not verifiable (we cannot construct individual proofs to them). And let's call whatever corresponds to Ethereum events "events". "Events" have proofs and can be emulated either by:

• Writing logs directly to state trie -- that's what you suggest.
• Returning logs as part of the function result.

[bowenwang1996]

Is #2045 done? @k06a

[k06a]

Is #2045 done? @k06a

Yep, we need this PR to get merged before merging depending PRs in other repos.

[ilblackdragon]

Closing, as Denver is long in the past.