Succinctness with Single Block Finality

If you are accustomed to high-performant blockchains, the following observation may seem strange, but actually single-block finality is quite rare in consensus designs. Remember that in Bitcoin, it takes about an hour before you can be sure that your transaction was properly included in a block.

Clearly, this property of Bitcoin is a huge problem for applications, especially in financial use cases, where no assumptions can be made about the execution before the TX is finalized. This makes it almost impossible to run any applications over PoW networks (even if you introduce a Turing-complete computation setup on top).

Before CometBFT (f.k.a Tendermint), the situation was about the same for PoS chains, where you actually needed hours before a TX was finalized on the chain. CometBFT changed this by introducing the concept of slashing and honest-majority of the stake distribution. By only assuming the 66% of the chain is operating honestly, CometBFT was able to provide finality over each block in the making of the next one, i.e. once enough signatures were available for the previous block. This allowed Ethereum, Solana, and many other blockchains to improve their infrastructure to a much faster setup, allowing the DeFi ecosystem that we have today.

However, CometBFT (or any single-block BFT) has a fundamental weakness, which is the fact that it is not succinct: The only way of making sure a CometBFT block is valid is to perform a synchronization over blocks from the genesis. If you are an active participant (or listener) of the network, then this is not a problem, since you always hold the most recent state. But while trying to join the network from zero, or start a light client for instant interactions, this means hours of latency before being able to get a fully trustless view of the chain.

Then, let us remember Mina, which has solved the succinct problem using a new consensus model backed with zk-SNARKs. In Mina, there is no synchronization delay, just the verification of the most recent block. But of course, Mina is not perfect either: Mina’s consensus is not single-block finality.

This means that just like in Bitcoin, you need to wait for hours before a TX is truly included in the Mina blockchain. So even if you can get the succinct proof of a block, the actual chain is very slow, making it very inconvenient for many use cases.

This is essentially the blockchain trilemma on its full: You want security, decentralization and performance, all at once, but making two of these perfect makes you lose another.

In Pulsar, this is what we solve.