-
Notifications
You must be signed in to change notification settings - Fork 20
Description
When Mithril replays blocks, it propagates changes immediately to the same AccountsDB that is used by the RPC server. Therefore, the RPC server will provide data from blocks that have been successfully replayed by Mithril. Though as explained in https://github.com/runtimeverification/_audits_Overclock-Validator_mithril/issues/131, Mithril should only use data from blocks for which it could confirm finality.
This is impossible for Mithril to confirm by replaying blocks individually and propagating changes to AccountsDB immediately. Therefore, Mithril currently relies on potentially untrusted RPC servers to provide solely blocks that have reached finality. In practice, these RPC nodes could instead provide blocks from forks that do not reach finality, yet execute successfully on Mithril. This would eventually also cause a bankhash mismatch since blocks would eventually stop being proposed for such a fork that won't reach consensus.
Here, a block is considered to have reached finality when it has at least 31 descendant blocks that have reached a supermajority of votes, i.e., two-thirds of votes weighted by stake. In turn, a block is considered being voted on when a descendant block contains a vote for this block. This implies that Mithril might need to replay multiple descendant blocks before confirming that a given block has achieved a supermajority of votes weighted by stake.
Recommendation
We recommend to not rely on the assumption that untrusted RPC servers only provide blocks that have achieved finality. Instead, recommend to optimistically execute blocks for which finality is assumed and to only commit changes to the AccountsDB that is used by Mithril's RPC server backend once finality of the respective block has been confirmed. Likewise, Mithril must be able to roll back replay of blocks if it turns out that the blocks that were optimistically executed cause a bankhash mismatch or never reach finality.