informalsystems/tendermint

A temporary fork of the original Tendermint Core repository (please use CometBFT instead)

Tendermint

Byzantine-Fault Tolerant State Machine Replication. Or Blockchain, for short.

Branch	Tests	Linting
main

Tendermint Core is a Byzantine Fault Tolerant (BFT) middleware that takes a state transition machine - written in any programming language - and securely replicates it on many machines.

For protocol details, refer to the Tendermint Specification.

For detailed analysis of the consensus protocol, including safety and liveness proofs, read our paper, "The latest gossip on BFT consensus".

Documentation

Complete documentation can be found on the website.

Releases

Please do not depend on main as your production branch. Use releases instead.

Tendermint has been in the production of private and public environments, most notably the blockchains of the Cosmos Network. we haven't released v1.0 yet since we are making breaking changes to the protocol and the APIs. See below for more details about versioning.

In any case, if you intend to run Tendermint in production, we're happy to help. You can contact us over email or join the chat.

More on how releases are conducted can be found here.

Security

To report a security vulnerability, see our bug bounty program. For examples of the kinds of bugs we're looking for, see our security policy.

We also maintain a dedicated mailing list for security updates. We will only ever use this mailing list to notify you of vulnerabilities and fixes in Tendermint Core. You can subscribe here.

Minimum requirements

Requirement	Notes
Go version	Go 1.18 or higher

Install

See the install instructions.

Quick Start

• Single node
• Local cluster using docker-compose
• Remote cluster using Terraform and Ansible

Contributing

Please abide by the Code of Conduct in all interactions.

Before contributing to the project, please take a look at the contributing guidelines and the style guide. You may also find it helpful to read the specifications, and familiarize yourself with our Architectural Decision Records (ADRs) and Request For Comments (RFCs).

Versioning

Semantic Versioning

Tendermint uses Semantic Versioning to determine when and how the version changes. According to SemVer, anything in the public API can change at any time before version 1.0.0

To provide some stability to users of 0.X.X versions of Tendermint, the MINOR version is used to signal breaking changes across Tendermint's API. This API includes all publicly exposed types, functions, and methods in non-internal Go packages as well as the types and methods accessible via the Tendermint RPC interface.

Breaking changes to these public APIs will be documented in the CHANGELOG.

Upgrades

In an effort to avoid accumulating technical debt prior to 1.0.0, we do not guarantee that breaking changes (ie. bumps in the MINOR version) will work with existing Tendermint blockchains. In these cases you will have to start a new blockchain, or write something custom to get the old data into the new chain. However, any bump in the PATCH version should be compatible with existing blockchain histories.

For more information on upgrading, see UPGRADING.md.

Supported Versions

Because we are a small core team, we have limited capacity to ship patch updates, including security updates. Consequently, we strongly recommend keeping Tendermint up-to-date. Upgrading instructions can be found in UPGRADING.md.

Currently supported versions include:

• v0.34.x
• v0.37.x (release candidate)

Resources

Libraries

• Cosmos SDK; A framework for building applications in Golang
• Tendermint in Rust
• ABCI Tower

Applications

• Cosmos Hub
• Terra
• Celestia
• Anoma
• Vocdoni

Research

• The latest gossip on BFT consensus
• Master's Thesis on Tendermint
• Original Whitepaper: "Tendermint: Consensus Without Mining"
• Tendermint Core Blog
• Cosmos Blog

Join us

Tendermint Core is maintained by Interchain GmbH. If you'd like to work full-time on Tendermint Core, we're hiring!

Funding for Tendermint Core development comes primarily from the Interchain Foundation, a Swiss non-profit. The Tendermint trademark is owned by Tendermint Inc., the for-profit entity that also maintains tendermint.com.

tendermint's Issues

http_json_handler: Don't have err failed to write response log entire error

Summary

There are many causes of failed to write response errors in this file: https://github.com/tendermint/tendermint/blob/v0.34.24/rpc/jsonrpc/server/http_json_handler.go#L19-L129

One of these frequently leads to massive "log bombs", that spans thousands of characters and crowds out all content in the CLI logs (and looks quite concerning)

 Nov 17 01:49:48 <node_name> cosmovisor[1541013]: 1:49AM ERR failed to write responses err="write tcp 127.0.0.1:26657->127.0.0.1:34266: i/o timeout" module=rpc-server res=[{"id":998254319713,"jsonrpc":"2.0","result":{"total_count":"329048","txs":$MASSIVE_AMOUNT_OF_TEXT

There are some \n characters in this output that end up breaking into multiple lines as well, and breaking parsing formats.

Can we make a smaller result serialization here, that just has a truncated / trimmed amount of data, that gets output to the CLI?

This would significantly reduce the size of logs, and the amount of information that can be easily gleaned by scrolling through them.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

Move log "rejected bad transaction" to debug level

Summary

repost issue from tendermint#9981

the mempool V0 uses DEBUG but V1 uses INFO which might create a lot of noise in the log.

Consensus error reported from validator using Gaia v9.0.x

Validator reported the following consensus error. Currently waiting for additional infomation/logs.

Tendermint version:
0.34.26

Gaia version:
9.0.x waiting for exact version, therefore this is v9.0.0 or v9.0.1.

Environment:

• OS (e.g. from /etc/os-release):
• Install tools:
• Others:

What happened:
Application stopped validating blocks. Validator jailed.

What you expected to happen:
No error.

Have you tried the latest version: yes/no
no

How to reproduce it (as minimally and precisely as possible):
Unknown

Logs (paste a small part showing an error (< 10 lines) or link a pastebin, gist, etc. containing more of the log file):
https://pastebin.com/AjJZUrVP

Config (you can paste only the changes you've made):
Waiting for more information.

node command runtime flags:
Waiting for more information.

Please provide the output from the http://<ip>:<port>/dump_consensus_state RPC endpoint for consensus bugs
Asked, waiting for more information.

Anything else we need to know:

Gossip data to a peer without valid channel increases cpu usage

Tendermint version (use tendermint version or git rev-parse --verify HEAD if installed from source):
0.34.23

ABCI app (name for built-in, URL for self-written if it's publicly available):
https://github.com/public-awesome/stargaze

Environment:

• OS ubuntu 20.04+

What happened:
Currently stargaze mainnet network have multiple reports of increased cpu usage without any meaningful change in our current stack.

After digging a bit we were able to find that gossipDataRoutine and specifically the gossipDataForCatchup method was causing this increase in.

In the following snippet if SendEnvelopeShim fails, it just immediately retries to gossip the same block part until the peer state changes (different round etc), but it generates more work because is loading block meta and block part from disk.

tendermint/consensus/reactor.go

Lines 698 to 710 in e0f68fe

	if p2p.SendEnvelopeShim(peer, p2p.Envelope{ //nolint: staticcheck
	ChannelID: DataChannel,
	Message: &tmcons.BlockPart{
	Height: prs.Height, // Not our height, so it doesn't matter.
	Round: prs.Round, // Not our height, so it doesn't matter.
	Part: *pp,
	},
	}, logger) {
	ps.SetHasProposalBlockPart(prs.Height, prs.Round, index)
	} else {
	logger.Debug("Sending block part for catchup failed")
	}
	return

adding a small sleep like in other error checks fixes the problem, like in our fork public-awesome@da5a32f which seemed to reduce the cpu usage.
time.Sleep(conR.conS.config.PeerGossipSleepDuration)

Currently there is no way to know from this method if the peer is valid for sending the packet, hasChannel is a private method, but ideally we could save loading from disk if we could check first peer.IsValid() then execute the remaining logic.

What you expected to happen:
To add a delay or a check that prevents sending to info to a peer with an invalid state

Have you tried the latest version: yes/no
Yes

How to reproduce it (as minimally and precisely as possible):
Hard to replicate current network conditions as it seems there is some invalid peers in the network causing this issue, but joining the network with a new node will replicate it.

Logs (paste a small part showing an error (< 10 lines) or link a pastebin, gist, etc. containing more of the log file):

Config (you can paste only the changes you've made):

node command runtime flags:

Please provide the output from the http://<ip>:<port>/dump_consensus_state RPC endpoint for consensus bugs

Anything else we need to know: