harmony-one / horizon

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

Refactor v2 #48

Open johnwhitton opened 2 years ago

johnwhitton commented 2 years ago

I’ve been looking at a problem with the deploy of the LightClient and narrowed it down to this line in RLPReader.sol uint mask = 256 ** (WORD_SIZE - len) - 1; When we are creating the rlpHeader the logsBloom is "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000”, which has a length of 256 (this is for Ropsten, and localgeth) Thus we were trying to go to a power of a negative number (which just failed without reverting or giving any error). I put in a workaround of

            if (len >= WORD_SIZE) {
                len = WORD_SIZE - 1;
            }

And the deploy is now working I noticed that the version of RLPReader we have was updated by Tuan Vu I’m assuming it was copied originally from here https://github.com/hamdiallam/Solidity-RLP/blob/master/contracts/RLPReader.sol#L351 This codebase was last modified on Jun 7 2021 and contracts have pragma solidity >=0.5.0 <0.7.0; we are using pragma solidity ^0.8.0; Also the code from hamdiallam has some additional error handling which may have been applied after we made the original copy. So there may be more cleanup work enhancements needed. Currently the relay is still failing with Error: Transaction has been reverted by the EVM: latest log is here Fix was applied here.

johnwhitton commented 2 years ago

Error calculating the seal when relaying blocks Here is the current error when relaying a block after putting some logging in EthereumLightClient.sol It is having trouble calling Analysis The block header for localgeth is as follows you can see sample blockHeaders from ropsten and ethereum here

header: {
    "parentHash": "0xdb9e3369509518820f176b86afc312ecafc54a4bc324491bd261df3614b55735",
    "uncleHash": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
    "coinbase": "0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266",
    "stateRoot": "0xadfd9a8868580138c975dcaed43c6f56035eb9e89bd63cb5ac67651b32075733",
    "transactionsTrie": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "receiptTrie": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "difficulty": "0x20000",
    "number": "0x2",
    "gasLimit": "0x7a4f0e",
    "gasUsed": "0x0",
    "timestamp": "0x62a8d530",
    "extraData": "0xd983010a12846765746888676f312e31382e328664617277696e",
    "mixHash": "0x233714ae9205bb1305214026b9335b113203dc51d4e68a876400c8936795f8d4",
    "nonce": "0x76a1124da977aa93",
    "bloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}

EthereumParser.sol iterates through the header fields to calculate the sealRlpData

        bytes[] memory rlpFields = new bytes[](14);
        RLPReader.Iterator memory it = _rlpHeader.toRlpItem().iterator();
        uint256 idx = 0;
        while (it.hasNext() && idx < 14) {
            console.log("idx: ", idx);
            if (idx == 13) {
                it.next();
                it.next();
            }
            rlpFields[idx] = it.next().toRlpBytes();
            idx++;
        }

The goal of the logic above is to ignore the following lines in the header file

    "baseFeePerGas": "0x7",
    "baseFee": "0x7",

However for localgeth those lines are omitted (as with some of the earlier blocks in Ropsten. The logic should be modified to conditionally skip the lines above only if they are populated. This could be done by calculating the length of the header rows and replacing the hardocded skipping on idx ==13 The other option is to modify localgeth genesis.json to force it to add in the baseFee information.

Command yarn cli ethRelay relay http://localhost:8645 http://localhost:8545 0x017f8C7d1Cb04dE974B8aC1a6B8d3d74bC74E7E1 -d ./src/cli/.dag Error

console.log:
    calling _pruneBlocks
    checking blockExists
    Parsing BlockHeader
    checking Parentblock
    checking block height
    checking timestamp
    checking difficulty
    verifying block POW

  Error: Transaction reverted without a reason string
      at EthereumLightClient.next (contracts/lib/RLPReader.sol:33)
      at EthereumLightClient.calcBlockSealHash (contracts/EthereumParser.sol:98)
      at EthereumLightClient.addBlockHeader (contracts/EthereumLightClient.sol:178)
johnwhitton commented 2 years ago

Error validating Epoch After resolving the above we now get Error: VM Exception while processing transaction: reverted with reason string 'epoch out of range!'

Analysis For local testing epoch 0 is being used. When verifying the EthHash in ethhash.sol we call bytes32 rootHash = getRootHash(uint64(epoch)); Which calls getRootHash in MerkleRoot.sol which has hardcoded these values


contract MerkelRoots {
    uint64 constant epochStart = 411;
    uint64 constant epochEnd = 411;
    bytes constant ROOTS = "\xf8\x7d\x60\x5d\xd4\xbd\xaf\xc3\x9b\x13\xb4\x5b\x6a\xbf\x6b\x92\x11\x96\xb0\xf3\xb5\xd7\xc5\x1b\x31\x82\x06\x64\x10\x4a\x69\x7d";

   function getRootHash(uint64 epoch) internal pure returns(bytes32 hash) {
       bytes memory roots = ROOTS;
       require(epoch >= epochStart && epoch <= epochEnd, "epoch out of range!");
       uint256 index = epoch - epochStart + 1; // skip length
       assembly{
           hash := mload(add(roots, mul(index, 0x20)))
       }
   }
}
**Workaround was to change `uint64 constant epochStart = 0;`**
Needs further analysis as hot `ROOTS` is generated
`root: "0x2c2fcc0735c171e57f5fa49f0d3b30f777fa2eea3531f418797af14b1a98d9b8"`
so we can make the following change
// Test data for Ropsten
// uint64 constant epochStart = 0;
// uint64 constant epochEnd = 411;
// bytes constant ROOTS =
//     "\xf8\x7d\x60\x5d\xd4\xbd\xaf\xc3\x9b\x13\xb4\x5b\x6a\xbf\x6b\x92\x11\x96\xb0\xf3\xb5\xd7\xc5\x1b\x31\x82\x06\x64\x10\x4a\x69\x7d";
// Configuration for LocalGeth
uint64 constant epochStart = 0;
uint64 constant epochEnd = 411;
bytes constant ROOTS =
    "\x2c\x2f\xcc\x07\x35\xc1\x71\xe5\x7f\x5f\xa4\x9f\x0d\x3b\x30\xf7\x77\xfa\x2e\xea\x35\x31\xf4\x18\x79\x7a\xf1\x4b\x1a\x98\xd9\xb8";


After changing this we then received an error using `hashimoto` analsyis below

**Command**
yarn cli ethRelay relay http://localhost:8645 http://localhost:8545 0x6a754B8573195AA9Dfea97eEe704C981eCf2c1FF -d ./src/cli/.dag

**Log**
Error: VM Exception while processing transaction: reverted with reason string 'epoch out of range!'
      at EthereumLightClient.whenNotPaused (@openzeppelin/contracts-upgradeable/security/PausableUpgradeable.sol:57)
      at EthereumLightClient.getRootHash (contracts/ethash/MerkelRoot.sol:11)
      at EthereumLightClient.verifyEthash (contracts/ethash/ethash.sol:493)
      at EthereumLightClient.addBlockHeader (contracts/EthereumLightClient.sol:179)
      at async HardhatNode.runCall (/Users/john/one-wallet/horizon/node_modules/hardhat/src/internal/hardhat-network/provider/node.ts:616:20)
      at async EthModule._callAction (/Users/john/one-wallet/horizon/node_modules/hardhat/src/internal/hardhat-network/provider/modules/eth.ts:354:9)
johnwhitton commented 2 years ago

Error with hashimoto calculation

Analysis The error occurs when generating the header hash and nonce using the hashimoto algorithm. It occurs here return (a * 0x01000193) ^ b; And is passed these values return (3789160042 * 0x01000193) ^ 3789160042 The error occurs on this line uint32 parent = fnv(i ^ seedHead, mix[i % mix.length]) % rows; Below are the Logged Values

    hashimoto i:  0
    mix.length:  32
    rows:  8388607
    seedHead:  3789160042
    a:  3789160042
    b:  3789160042

Command

 yarn cli ethRelay relay http://localhost:8645 http://localhost:8545 0x6a754B8573195AA9Dfea97eEe704C981eCf2c1FF -d ./src/cli/.dag

Log

 Error: VM Exception while processing transaction: reverted with panic code 0x11 (Arithmetic operation underflowed or overflowed outside of an unchecked block)
      at EthereumLightClient.fnv (contracts/ethash/ethash.sol:44)
      at EthereumLightClient.hashimoto (contracts/ethash/ethash.sol:438)
      at EthereumLightClient.verifyEthash (contracts/ethash/ethash.sol:495)
      at EthereumLightClient.addBlockHeader (contracts/EthereumLightClient.sol:183)

References

johnwhitton commented 2 years ago

Am currently looking at whether the root cause of all the above is related to the fact that the codebase has been built specifically to align with the current ethereum mainnet.

To replicate this I have modified the genesis json to include additional configuration parameters related to london as mentioned here and here.

By modifying genesis.config as follows (the key line "londonBlock": 0,)

{
    "config": {
        "chainId": 8788,
        "homesteadBlock": 0,
        "eip150Block": 0,
        "eip155Block": 0,
        "eip158Block": 0,
        "byzantiumBlock": 0,
        "constantinopleBlock": 0,
        "petersburgBlock": 0,
        "istanbulBlock": 0,
        "muirGlacierBlock": 0,
        "berlinBlock": 0,
        "londonBlock": 0,
        "arrowGlacierBlock": 0,
        "grayGlacierBlock": 0,
        "mergeNetsplitBlock": 0,
        "ethash": {}
    },
    "difficulty": "1",
    "gasLimit": "8000000",
    "alloc": {
        "9Cf3000a2f555607Ce330Bf70B0f67c7cBcd3be8": {
            "balance": "300000"
        }
    }
}

we now get our block headers including basFee and baseFeePerGas.

 {
    "parentHash": "0x73736e2208cff63f17f5a0af53e78b16df24dbb439633f137300cfc002a468a1",
    "uncleHash": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
    "coinbase": "0xf39fd6e51aad88f6f4ce6ab8827279cfffb92266",
    "stateRoot": "0x3fad6519e1f95df7fe10feb4eeab0c49c8edde320338ecc0000184b563299dcb",
    "transactionsTrie": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "receiptTrie": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
    "logsBloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
    "difficulty": "0x231a8",
    "number": "0xc8",
    "gasLimit": "0x94616f",
    "gasUsed": "0x0",
    "timestamp": "0x62abc5ae",
    "extraData": "0xd983010a12846765746888676f312e31382e328664617277696e",
    "mixHash": "0x0a40a3c6f22e86feb2b3d72af550959669c76a0001b3f907ae14d868ce0f8daa",
    "nonce": "0x113fb9eda7492a17",
    "baseFeePerGas": "0x7",
    "baseFee": "0x7",
    "bloom": "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"
}

Currently have begun creating the DAG for the new chain, then will update the initData to reflect the new configuration. Will also update "MerkleRoot.sol` to have the corrrect root for localgeth and epochStart and epochEnd set to 0.

johnwhitton commented 2 years ago

Have updated genesis.json and initData and we now generate the headers similar to that of Ethereum mainnet. Also updated 'MerkleRoot.sol' to use epoch 0 and placed in the encode root retrieved from proofs.root. This resolved the issues with calculating the seal and validating the epoch. However the issue with the hashimota calculation still exists. Will review further tomorrow.

johnwhitton commented 2 years ago

Latest log from debugging verifyEthHash callling hashimoto in ethhash.sol console.log: sealHash: 74390009781685601618541290251960722186319639099107416850618130334421248486748 header.nonce: 1840997502332555572 header.number: 1001 header.difficulty: 210447 header.mixHash: 46150766055922273093573656953585866175828334889140758841637818972486362424218 hash: 0xa47740e251bacf5ebec2ae7083b98b0c6781b5957d4c550ff3fc043dcf2dad5c nonce: 1840997502332555572 number: 1001 difficulty: 210447 mixHash: 46150766055922273093573656953585866175828334889140758841637818972486362424218 epoch: 0 rootHash: 0x2c2fcc0735c171e57f5fa49f0d3b30f777fa2eea3531f418797af14b1a98d9b8 size: 1073741696 //calculated using getFullSize size: 1073741696 mixBytes: 128 //constant rows: 8388607. //size divided by mixBytes seedBeforeSha: 0xa47740e251bacf5ebec2ae7083b98b0c6781b5957d4c550ff3fc043dcf2dad5c34d1e96e79898c19 //seed first 32 bytes is the hash and then nonce seed: 0x4dee06e420c1601d8ffd84a241e87833bdf5ffa42c379816e91139ff1e28958ee13fce99bc8156f8116233d1de5f9ee8e0d24eb1f69a12253b3a09e35d6ae58f // seedBeforeSha.sha3_512(); seedHead: 3825659469 // uint32 seedHead = seed.Uint32(0); mix i: 0 mix[i]: 3825659469 mix i: 1 mix[i]: 492880160 mix i: 2 mix[i]: 2726624655 mix i: 3 mix[i]: 863561793 mix i: 4 mix[i]: 2768238013 mix i: 5 mix[i]: 379074348 mix i: 6 mix[i]: 4281930217 mix i: 7 mix[i]: 2392139806 mix i: 8 mix[i]: 2580430817 mix i: 9 mix[i]: 4166418876 mix i: 10 mix[i]: 3509805585 mix i: 11 mix[i]: 3902693342 mix i: 12 mix[i]: 2974733024 mix i: 13 mix[i]: 621976310 mix i: 14 mix[i]: 3809032763 mix i: 15 mix[i]: 2414176861 mix i: 16 mix[i]: 3825659469 mix i: 17 mix[i]: 492880160 mix i: 18 mix[i]: 2726624655 mix i: 19 mix[i]: 863561793 mix i: 20 mix[i]: 2768238013 mix i: 21 mix[i]: 379074348 mix i: 22 mix[i]: 4281930217 mix i: 23 mix[i]: 2392139806 mix i: 24 mix[i]: 2580430817 mix i: 25 mix[i]: 4166418876 mix i: 26 mix[i]: 3509805585 mix i: 27 mix[i]: 3902693342 mix i: 28 mix[i]: 2974733024 mix i: 29 mix[i]: 621976310 mix i: 30 mix[i]: 3809032763 mix i: 31 mix[i]: 2414176861 mix.length: 32

rootHash: 0x2c2fcc0735c171e57f5fa49f0d3b30f777fa2eea3531f418797af14b1a98d9b8
loopAccess i 0
Calling fnv
iseedHead:  3825659469
mixer:  3825659469
a:  3825659469
b:  3825659469

Error: VM Exception while processing transaction: reverted with panic code 0x11 (Arithmetic operation underflowed or overflowed outside of an unchecked block) at EthereumLightClient.fnv (contracts/ethash/ethash.sol:48) at EthereumLightClient.hashimoto (contracts/ethash/ethash.sol:457) at EthereumLightClient.verifyEthash (contracts/ethash/ethash.sol:524) at EthereumLightClient.addBlockHeader (contracts/EthereumLightClient.sol:177)

johnwhitton commented 2 years ago

Relayer is now working Summary of changes

Working Log

johnlaptop horizon (refactorV2) $ yarn cli ethRelay relay http://localhost:8645 http://localhost:8545 0x76420bfC35CD4841C5dd3920f3a0f0aC4831208A -d ./src/cli/.dag
yarn run v1.22.18
warning ../../package.json: No license field
$ node src/cli/index.js ethRelay relay http://localhost:8645 http://localhost:8545 0x76420bfC35CD4841C5dd3920f3a0f0aC4831208A -d ./src/cli/.dag
ELC last block number: 1000
block to relay: 1001
header hash 0x479a245019d7bed120b30e6dd40e75d34f8cad600138ed9d16432daa981cd4b2
headerHash:  a47740e251bacf5ebec2ae7083b98b0c6781b5957d4c550ff3fc043dcf2dad5c
proofs.root: 0x2c2fcc0735c171e57f5fa49f0d3b30f777fa2eea3531f418797af14b1a98d9b8
new block number: 1001
ELC last block number: 1001
block to relay: 1002
header hash 0xbed2ffb165399c77a9e702d5424e76fc1b93d629dc03f9b843d154264715b965
headerHash:  86143fe67e6c3bdbc2a8aa3bd4cd9f42fa7474215c51cb5b1a7c1803eb4d69a2
proofs.root: 0x2c2fcc0735c171e57f5fa49f0d3b30f777fa2eea3531f418797af14b1a98d9b8
new block number: 1002
ELC last block number: 1002
block to relay: 1003
header hash 0xc91f5e6f1b9928d501b7d7a20db4d36bf9163095f88537dde630c5a5fe1ed4eb
headerHash:  76ca9edc1982ed7007f2fdd0ab82589bb2104f43fef79ad53846bc1b6802e759
proofs.root: 0x2c2fcc0735c171e57f5fa49f0d3b30f777fa2eea3531f418797af14b1a98d9b8
new block number: 1003
ELC last block number: 1003
block to relay: 1004
header hash 0xf14df3dd0d891613d636a9a9233ce6f77f1760e716bdc660b43d24cc3d4d7664
headerHash:  5407f3453605a015bcd6a37869a05956e56289e96ee9e247efacbfae0d34f60a
proofs.root: 0x2c2fcc0735c171e57f5fa49f0d3b30f777fa2eea3531f418797af14b1a98d9b8
new block number: 1004
ELC last block number: 1004
johnwhitton commented 2 years ago

Relayer is now working locally and have streamlined the use of private keys and funding, fixed issue with faucetTokens and minting and added in setting of lightClients for Tokenlockers on deployment.

Currently have an error with mapping the tokens which will need further debugging/logging.

yarn cli Bridge map http://localhost:8645 0x3Ceb74A902dc5fc11cF6337F68d04cB834AE6A22 http://localhost:9500 0x3Ceb74A902dc5fc11cF6337F68d04cB834AE6A22 0x4e59AeD3aCbb0cb66AF94E893BEE7df8B414dAB1
johnwhitton commented 2 years ago

Here is the Logic (call execution overview) when Mapping Tokens across Chains

  1. Bridge Map is called in src.cli.index.js and it calls tokenMap which
  2. Get srcBridge Contract (on Ethereum)
  3. Get destBridge Contract (on Hamony)
  4. Call IssueTokenMapReq (on the Ethreum Locker)
  5. Send the IssueTokenMapReq.hash to Harmony (CrossRelay first call) 5.1. This gets the proof of the transaction on Ethereum via prover.ReceiptProof 5.2 Then validateAndExecuteProof on Harmony via ExecProof which calls the HarmonyTokenLocker.ExecProof
  6. We then prove the Harmony mapping acknowledgment on Ethereum (Cross Relay second call) 6.1 This gets the proof of the acknowledgement transaction on Harmony via prover.ReceiptProof 6.2 Then validateAndExecuteProof on Ethereum via ExecProof which calls the EthereumTokenLocker.ExecProof
  7. Upon completion of tokenMap control is passed back to Bridge Map which
  8. Calls TokenPair on Ethereum
  9. Calls ethTokenInfo to get the status of the ERC20
  10. Calls hmyTokenInfo to get the tokenStatus on Harmony

Note: validateAndExecuteProof is responsible for creation of the BridgeTokens on the destination chain it does this by calling execute call in TokenLockerLocker.sol which then calls the function onTokenMapReqEvent in TokenRegistry.sol which creates a new Bridge Token BridgedToken mintAddress = new BridgedToken{salt: salt}(); and then initializes it.

Note: The shims in ethWeb3.js provide simplified functions for ContractAt, ContractDeploy, sendTx and addPrivateKey and have a constructor which uses process.env.PRIVATE_KEY.

Further Debugging of tokenMapping shows three issues (logs are here)

  1. An error with isomorphic-rpc which is used by eth-proof
  2. Transaction is being reverted when calling validateAndExecuteProof
  3. Problem with Getting the Proof of the Mapping Request from Harmony

For the first issue validateAndExecuteProof There is a recommendation here to run geth with the following flags geth --syncmode full --gcmode archive which I have done however we may need to regenerate initData as those flags were not set when creating the original 2172 blocks we are using, this would also mean regeneration of the DAG 0 data for localgeth.

Also eth-proof is two years old and uses an older version of isomorphic-rpc isomorphic-rpc "^1.2.1"there apears to be a later version1.2.2` published here.

Using ethers getBlock which supports getting blocks by hashes see here is another alternative.

For the evm execution reversion Initial Problem was with GAS Calculation not working when calling ExecProof for mapAck on Harmony Resolving this we now have a problem with getProof on the second call to CrossRelay which is getting the proof from Harmony the second error is (node:67697) UnhandledPromiseRejectionWarning: Error: {"jsonrpc":"2.0","id":1,"error":{"code":-32602,"message":"invalid argument 0: json: cannot unmarshal non-string into Go value of type common.Hash"}}

There is a shim in src/cli/lib/ethWeb3.js to calculate gas which does not appear to be working for the Hamony Side

    async sendTx (tx, gas) {
        if (!gas) {
            gas = await tx.estimateGas()
        }
        console.log(`gas: ${JSON.stringify(gas)}`)
        return tx.send({ gas })

Hardcoding the value for debugging purposes resolved some reverts return tx.send({ gasLimit: process.env.GAS_LIMIT })

Here is a workaround using ethers.js

    const options = {
        gasLimit: process.env.GAS_LIMIT,
        gasPrice: process.env.GAS_PRICE
     }
     const hmyProvider = await new ethers.providers.JsonRpcProvider(process.env.HMY_URL)
     const hmySigner = await new ethers.Wallet(process.env.PRIVATE_KEY, hmyProvider)
     const hmyTokenLockerABI = require('../../../build/contracts/TokenLockerOnHarmony.sol/TokenLockerOnHarmony.json')
     const hmyTokenLocker = await new ethers.Contract(process.env.HMY_TOKEN_LOCKER, hmyTokenLockerABI.abi, hmySigner)
        const tx = await hmyTokenLocker.validateAndExecuteProof(hash, root, key, proof, options)

For the Problem getting the Proof from Harmony Have tried hardcoding gas values which did not resolve the issue. (logs are here ). Current thoughts it may be due to the problem with EthProof above, will try and resolve and if not do further analysis.

Summary Need to evaluate the following options a. Fix the evm_reverts by addressing the gas issues and ensuring that there are no other blockers with proofs or mapping creations b. Determine whether the error with isomorphic-rpc is a blocker (it may just be informational).

Some opinions I think ethers way of interacting with contracts is cleaner than web3 In ethers once you have instantiated your contract with the Signer you then can use the methods fairly cleanly e.g with ethers const tx = await hmyTokenLocker.validateAndExecuteProof(hash, root, key, proof, options) vs web3

 const tx = this.contract.methods.validateAndExecuteProof(hash, root, key, proof )
  const txResult = await this.web3.sendTx(tx, process.env.GAS_LIMIT)

Also setting additional options e.g. for GAS_LIMIT may be a little cleaner (also see here)

johnwhitton commented 2 years ago

Planned development work can be found in tasks.md

Below are the completed tasks at time of writing

Completed

johnwhitton commented 2 years ago

Completed these tasks

For more on the deployment approach and use of plugins see here

johnwhitton commented 2 years ago

Completed these tasks

Next task is here