tendermint VS lighthouse

Tendermint Core / CometBFT — a state machine replication engine (written in Go);

There are good use-cases, but to much focus on cryptocurrencies. Frameworks are not well designed to be used in other use-cases. Best that I have found that doesn't forces you to a specific architecture is Tendermint, but is not even close to state-of-the-art performance and scalability. Everything else is designed around cryptocurrency and smart contracts.

BFT is an algorithm that ensures that the whole network works well even if a few members are acting fraudulently. As long as these fraudulent members are less than 33% of those who have voting power, the network will work fine. Those with voting power are those with something at stake. Cosmos uses a type of BFT consensus engine known as Tendermint. Cosmos uses Tendermint because it provides the best support for building POS blockchains.

Relevant Github ticket showing chains are now scrambling to decide which fork to use: https://github.com/tendermint/tendermint/issues/9972

BlockX is based on Tendermint Core, which relies on a set of validators that are responsible for committing new blocks in the blockchain. These validators participate in the consensus protocol by broadcasting votes which contain cryptographic signatures signed by each validator's private key.

Built with Cosmos and Tendermint.

Haqq is a scalable, high-throughput Proof-of-Stake blockchain that is fully compatible and interoperable with Ethereum. It's built using the Cosmos SDK which runs on top of Tendermint Core consensus engine.Haqq allows for running vanilla Ethereum as a Cosmos application-specific blockchain. This allows developers to have all the desired features of Ethereum, while at the same time, benefit from Tendermint’s PoS implementation. Also, because it is built on top of the Cosmos SDK, it will be able to exchange value with the rest of the Cosmos Ecosystem through the Inter Blockchain Communication Protocol (IBC)Features

Tendermint

Lighthouse — an Ethereum consensus client (written in Rust);

Daily Goerli: A whole lot more detail on the lighthouse db corruption issue I posted about previously. There's a warning that's been quite frequent on my erigon nodes for a while that doesn't seem to have any impact on its performance. I asked if it should be downgraded to INFO here.

According to lighthouse team, the root cause was beacon node waited too long before requesting the payload header. All details here : https://github.com/sigp/lighthouse/issues/4312

Update LH to 4.0.2-rc.0 More info here https://github.com/sigp/lighthouse/releases/tag/v4.0.2-rc.0

Which is not true... full nodes are consuming a lot of CPU now... hot-fix was released, but didn't solve the problem completely: https://github.com/sigp/lighthouse/releases/tag/v4.0.2-rc.0 ... more hot-fixes will be needed

https://github.com/sigp/lighthouse 142 contributors