tiablob/tiasync: update published block data to store its respective commit instead of last commit
Closed this issue · 1 comments
Tiasync currently stores well-formed, non-contiguous blocks in its custom block store with minimal checks and no validator set signature verifications. These verifications are performed later when the store has block x and block x+1. Block x+1 has the last commit used for verification of block x. Ideally, verification is performed before the block enters tiasync's block store, but blocks may not be published in sequence on Celestia.
SInce validators will always have the commit for blocks when they are published to Celestia. This proposal is to remove the last commit data from the block being published and add the respective blocks own commit, keeping the amount of data published to Celestia constant.
Tiablob will need to be updated to support this new data to publish. Instead of a single query to get the block, an additional query will be needed for the commit.
Tiasync will move block verification to being earlier, before it stores the block in its block store since it will now have the commit for the block. Ensuring only valid blocks are stored and reducing the need to store multiple blocks for the same height. Tiasync will need to re-populate the blocks last commit using the previous block's commit data. Further understanding is needed for what this may mean for the first block after genesis, state sync, or after a switch from syncing from the validator network.
Closing as won't implement.
Tiasync can still be fed non-contiguous blocks from Celestia. If a block's commit is added and its last commit removed, the block verification dependencies only shift and do not go away. The proposed change would put a requirement on tiasync having block x-1 to verify block x, instead of having block x+1 to verify the same block. Just like block x+1, we can't depend on having block x-1.
Publishing a block with its commit and last commit would fix this, but greatly increase costs of publishing to Celestia which we don't want to do.