Eth Relay May Fail With High Block Height

[yanganto]

Environment:

darwinia-proof-tools: master 4a6c099f860fe33248f7b35132e037c96992db34
darwinia: develop 18579118510fe6ddb9b1eead458d0551501fe640

darwinia command:

cargo run --release -- \
  --alice \
  --rpc-external \
  --rpc-port 23333 \
  --ws-external \
  --ws-port 23334 \
  --rpc-cors all \
  --port 23335 \
  --base-path /tmp/darwinia-develop/alice\
  --chain dev

darwinia-proof-tools config:

{
    "WEB3_RPC_SERVER": "https://ropsten.infura.io/v3/",
    "INFURA_KEYS": ["xxxxxxxxxxxxxx"],
    "DARWINIA_RPC_SERVER": "ws://127.0.0.1:23334",
    "KEYRING": ""
}

Summary

current block height of ropsten is about 7266202
darwinia-proof-tools with finalizedBlockNumber set as 6260059, everything looks good.
But if the finalizedBlockNumber set around 7266120, the system.ExtrinsicFailed will raise on the second transfering block.

How to reproduce

current block height of ropsten network is about 7266202
The finalizedBlockNumber set as 7266122

yarn run v1.21.1
$ npm run serve
npm WARN lifecycle The node binary used for scripts is /tmp/yarn--1580894696080-0.2714022102421969/node but npm is using /home/yanganto/.nvm/versions/node/v13.6.0/bin/node itself. Use the `--scripts-prepend-node-path` option to include the path for the node binary npm was executed with.

> [email protected] serve /home/yanganto/data/itering/darwinia-proof-tools
> node dist/server.js

{"message":"Logging initialized at debug level","level":"debug"}
  App is running at http://localhost:3006 in development mode
  Press CTRL-C to stop

{"message":"Logging initialized at debug level","level":"debug"}
{"message":"starting proof server!","level":"info"}
finalizedBlockNumber： { starter: '' }
Unknown types found, no types for KtonBalance,RingBalance
{"message":"polkadotjs init success!","level":"info"}
{"message":"start BlockChainState","level":"info"}
{"message":"start SubmitToDarwinia","level":"info"}
{"message":"start to get block number info: 7266122","level":"info"}
{"message":"Successfully acquired the block number info: 7266122","level":"info"}
{"message":"start build resetGenesisHeader extrinsic","level":"info"}
blockInChain:  7266202
Status of transfer: Ready
[Function (anonymous)]
{"message":"Successful transfer of with hash 0x0a4bb526bd01fa850870bb15798987122783227977cc77c4167a6210ca39f799 blockNumber: 7266122","level":"info"}
{"ApplyExtrinsic":2} : ethRelay.SetGenesisHeader
{"ApplyExtrinsic":2} : system.ExtrinsicSuccess
finalizedBlockNumber： { finalizedBlockNumber: 7266122 }
7266121 7266123
{"message":"start to get block number info: 7266123","level":"info"}
{"message":"Successfully acquired the block number info: 7266123","level":"info"}
{"message":"start build relayHeader extrinsic","level":"info"}
Status of transfer: Ready
[Function (anonymous)]
{"message":"Successful transfer of with hash 0x118c273de0c8a44bd8c6e7c60bb270fa94606ac99304b902fb19c5661219c21e blockNumber: 7266123","level":"info"}
{"ApplyExtrinsic":2} : system.ExtrinsicFailed

Also, the second block fails with three different finalizedBlockNumber settings, 7266121, 7266122, 7266124.

[yanganto]

Issue Update:

After upgrading to Substrate 2.0 (#218), the eth-relay correlating substrate module (srml) did not move to the new substrate module (pallet).

The reproducing method may change.

[AurevoirXavier]

chain relay will be upgrade in next week

[yanganto]

This may cause by #277.
0x6C993D => 7117117
And it is fixed not.