Narwhal and Bullshark / Mysticeti consensus

[kimurayu45z]

This topic might be moved to the more proper place because this is actually not the matter of Cosmos SDK but the matter of ABCI ecosystem.

In the past date, Paradigm tried to create Narwhal & Bullshark consensus with ABCI.
https://www.paradigm.xyz/2022/07/experiment-narwhal-bullshark-cosmos-stack

To be honest, Tendermint (and its fork, CometBFT) technology is mature technology. It is stable but there is no innovation anymore.
To introduce the new excitement of new technologies, the latest consensus like Narwhal & Bullshark should be introduced to ABCI ecosystem and Cosmos SDK support that.

However I think almost all team can't build such a public good only with their capital.
We a community should discuss about this to make Cosmos SDK ecosystem much greater.

[kimurayu45z]

Now Mysticeti is better
https://github.com/MystenLabs/mysticeti

[tac0turtle]

Hey, we are working on making the Cosmos SDK agnostic to consensus and network. We would love to explore how to best integrate this

[kimurayu45z]

In my understanding, the biggest problem to make Cosmos SDK consensus agnostic is that ABCI possesses the block height as int64 field.

https://github.com/cosmos/cosmos-sdk/blob/main/proto/cosmos/base/abci/v1beta1/abci.proto#L18

This structure makes us unable to expand the usage of Cosmos SDK into DAG based consensus like Bullshark, Mysticeti etc.
It means it requires a mechanism to linearize the DAG into linear chain. This is what Snowman protocol does in Avalanche EVM where naked Avalanche consensus is DAG based consensus.

Consensus agnostic requires being DAG friendly recently because almost all recent breakthrough in consensus level include DAG structure. To make Cosmos SDK DAG friendly, I think we need many modifications including making block height string.

[tac0turtle]

in the work we have been doing we break from being dependent on abci as well. We can make changes freely without needing to create a large fork of the Cosmos SDK. We would need to dive deeper into needed changes but this would be a good test of the work we have been doing

[kimurayu45z]

I am very glad to hear that.

Sui is doing a kind of abstraction for Execution layer to make an upgrade of Move VM easy,
https://github.com/MystenLabs/sui/tree/main/sui-execution
so I think the toughness of making Sui's consensus adopt to Cosmos SDK execution layer, is mitigated, hence there is a possibility of us @sunriselayer to try doing it.

Let me investigate more to convince me that it is possible.

[adizere]

I'm curious, what is the product or technical problem you're trying to solve by replacing the Tendermint consensus algorithm with another one?

To be honest, Tendermint (and its fork, CometBFT) technology is mature technology. It is stable but there is no innovation anymore.
To introduce the new excitement of new technologies, the latest consensus like Narwhal & Bullshark should be introduced to ABCI ecosystem and Cosmos SDK support that.

I agree, and working hard to improve this alongside the SDK team. Innovation in CometBFT in particular tends to happen "on top" (eg PBTS, ABCI v2), or in improving modularity and efficiency. This is not "core consensus innovation" as in adopting an entirely new consensus protocol. We are following a long-term goal in Comet to modularize the consensus engine and allow pluggability, but a lot of technical debt has to be paid (on the order of 1-2 years) before this is entirely finished.

Do you ideas about your use-case? The resources for developing public goods are very limited, and adopting another consensus algorithm is very expensive, so I want to make sure I understand how would you use Narwhal/Bullshark differently? Any insights appreciated!

[kimurayu45z]

Actually if we look at the business demands for the consensus level innovation, a performance competition that hits every corner of the box tends to be non-profitable.
However, I think we also need to consider the case like:

• Cosmos SDK loses the competitiveness due to the old consensus
• Hence Cosmos SDK loses the opportunity to expand the community, and fails to serve an opportunity of growth to Cosmos SDK community

In this case, Cosmos SDK community will pay an opportunity cost. Paying costs to avoid this opportunity cost might be able to be justified in the perspective of "Beneficiary burden"