Repository navigation
Commitee-based security for optimint rollups without BFT #220
Description
We may want to implement functionality to allow optimint rollups to have committee-based security, whilst at the same time avoiding the need to use a full-fledged BFT protocol such as Tendermint BFT, because optimint already uses an underlying data availability layer such as Celestia for ordering of blocks.
Suppose a rollup has (a) a set of block producers, and (b) a leader selection algorithm that picks one block producer from the set, to produce block n.
After block n is created, all of the other block producers check the validity of block n and sign the block if they attest that all the transactions in the block are valid. If there are enough signatures (e.g. say 2/3), then the block is considered approved by the committee.
These signatures could be broadcast over the P2P network, rather than being posted on-chain, thus the committee-based confirmation could be immediate. If the committee double signs conflicting block headers of a same height, then this ought to cause clients to abort and revert back to social consensus, similar to Tendermint. Alternatively, the signatures could be posted on-chain in rollup block n+1, thus creating a canonical chain in the case of conflicting block headers (thanks to the total ordering provided by the data availability layer), with no need to revert back to social consensus.
This design has similarities to Narwhal, except that validators sign to attest to the validity of the block, not just the availability.
Activity
liamsi commentedon Jun 30, 2022
This would be very much like the tendermint blocks/headers look like. If the goal here is to have compatibility with tendermint IBC clients. this appraoch would be favourable. The signatures materialize in the next block as LastCommit:
https://github.com/tendermint/tendermint/blob/60881f1d06cf69bfc1fb2a27c18d0e4061fc19d7/types/block.go#L47
and they are committed to in the header here:
https://github.com/tendermint/tendermint/blob/60881f1d06cf69bfc1fb2a27c18d0e4061fc19d7/types/block.go#L343
nashqueue commentedon Mar 17, 2023
Why does it have to be n+1 and not n?
Could it be both to have the benefit of both?
musalbas commentedon Mar 27, 2023
I think it could be n.
(I'm wrong about the committee-based confirmation having immediate finality btw--I believe that'd require BFT.)
Manav-Aggarwal commentedon Jun 27, 2024
Closing since committee-based approaches aren't a priority.
musalbas commentedon Jul 7, 2025
AFAIK this is now being worked on again. @Manav-Aggarwal can you link the new issue?
tac0turtle commentedon Jul 9, 2025
the issue needs to be updated but this was the original #2308