ChainSafe/chainbridge-solidity

Combine vote and execute

ansermino opened this issue · 3 comments

To reduce the number of tx's relayers have to submit and the overall gas consumption we can allow automatic execution of a proposal once it reaches the voting threshold.
https://github.com/ChainSafe/chainbridge-solidity/blob/master/contracts/Bridge.sol#L369

Implementation details

Do not remoe Passed status and event
https://github.com/ChainSafe/chainbridge-solidity/blob/master/contracts/Bridge.sol#L372
And also executeProposal function should be left available from outside, this is done for next useCase:

Proposal voted by last relayer and trashHold met, proposal marked Passed,but execution failed (in any reason, for example not enough balance). So then we need to leave Passed status and function executeProposal so stuck proposal could be pushed through. In case if proposal is Passed, then we should not check for proposal _expiry for reason that then we will be able to revert currentBlock of not voted relayer so it will be able to vote for it and Process to execute. Or other words, in case of vote if proposal is passed then it should be executed without _expiry checks.

Testing details

Update all existing tests to interact with the new flow. We should make sure to verify the gas benchmarks to validate our assumption that this will cost less.

Acceptance Criteria

  • Proposals are executed automatically without a relayer calling executeProposal directly
  • Proposal could be executed by vote in case its expired
  • Proposal could be executed by outside cal to executeProposal funciton (in case its Passed)
  1. Currently retries are allowed. In case of failed autoexecution vote will be reverted too, though we can wrap it in another call to not revert the vote.
  2. Failed execution is by itself an extrodinary situation that suggests the issue with the offchain(or other chain) processing. Probably a failed execution could never be successful, unless the underlying ERC20 has some custom logic.

We need to save the voting results even in case of unsuccessful execution cause otherwise proposal will timeout eventually and it will be not clear in retrospect if the last vote never happened or reverted with execution.

Need to make an assumption on the possible size of input needed for execution (in other bridge integrations as well), to calculate if it is viable to submit plain proposal data (intead of datahash) with every vote.