You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment the only way how the bridge can be used is through CLI. CLI is intentionally abstracting complicated calls to the higher level, making bridge usage simpler. However, fails in the CLI calls execution may not be directly connected with contracts bugs, but with the CLI implementation. The absence of lower interface of interaction with the bridge automatically lead to several problems:
There's no clear way for a user to finalise the transfer if it was interrupted by the CLI bug
No separation of concerns. Execution failures may not directly lead to the level where the problem occurred.
There's no clear way how to run complicated e2e tests that are not following the CLI logic
A user is passing his private keys to some (really complex) script and is not controlling actual transactions that are signed. For some users this would be a major concern for usage of the CLI.
Though the CLI script is rather simple for ERC-20 transfers. ERC-20 -> NEP-21 transfer has multiple steps (similar logic works within transfer back):
Stages 1, 2 can be passed knowing all the inputs to CLI (contract addresses, user addresses, private keys, etc.) through geth (even in a light client mode). Stage 5 can be passed through near-cli. Stage 4 is just waiting so can be substituted to recommendations on timings & checking view calls to NEAR blockchain (or Ethereum blockchain for opposite transfer).
The only stage that can not be passed easily is 3. Within this stage CLI collects the data from Ethereum full nodes (from RPC) and does not that simple assemblin MPT proof, which cannot be simply done from shell.
The solution to all above mentioned problems is to extract proof creation scripts and make them available through the CLI of the bridge.
Note: proof creation scripts are literally the only pieces that are needed to the end users from the core bridge. All the other interfaces / methods / endpoints can be completely hidden. Perhaps, this means that proof creation should be the only calls available in bridge-cli (if we don't think we should fit in it tools for devs), other scripts should be moved to connector-cli.
Extracting proof scripts would highly simplify the understanding of way how the bridge is operating for early bridge users.
The text was updated successfully, but these errors were encountered:
At the moment the only way how the bridge can be used is through CLI. CLI is intentionally abstracting complicated calls to the higher level, making bridge usage simpler. However, fails in the CLI calls execution may not be directly connected with contracts bugs, but with the CLI implementation. The absence of lower interface of interaction with the bridge automatically lead to several problems:
Though the CLI script is rather simple for ERC-20 transfers. ERC-20 -> NEP-21 transfer has multiple steps (similar logic works within transfer back):
EthOnNearClient
.Stages 1, 2 can be passed knowing all the inputs to CLI (contract addresses, user addresses, private keys, etc.) through geth (even in a light client mode). Stage 5 can be passed through near-cli. Stage 4 is just waiting so can be substituted to recommendations on timings & checking view calls to NEAR blockchain (or Ethereum blockchain for opposite transfer).
The only stage that can not be passed easily is 3. Within this stage CLI collects the data from Ethereum full nodes (from RPC) and does not that simple assemblin MPT proof, which cannot be simply done from shell.
The solution to all above mentioned problems is to extract proof creation scripts and make them available through the CLI of the bridge.
Note: proof creation scripts are literally the only pieces that are needed to the end users from the core bridge. All the other interfaces / methods / endpoints can be completely hidden. Perhaps, this means that proof creation should be the only calls available in
bridge-cli
(if we don't think we should fit in it tools for devs), other scripts should be moved toconnector-cli
.Extracting proof scripts would highly simplify the understanding of way how the bridge is operating for early bridge users.
The text was updated successfully, but these errors were encountered: