abci Documentation

Technical Documentation: tendermint/abci

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (`README.md`) Copy Section

Application BlockChain Interface (ABCI)

Blockchains are systems for multi-master state machine replication.
ABCI is an interface that defines the boundary between the replication engine (the blockchain),
and the state machine (the application).
Using a socket protocol, a consensus engine running in one process
can manage an application state running in another.

Previously, the ABCI was referred to as TMSP.

The community has provided a number of addtional implementations, see the Tendermint Ecosystem

Specification Copy Chapter

A detailed description of the ABCI methods and message types is contained in:

• A prose specification
• A protobuf file
• A Go interface.

For more background information on ABCI, motivations, and tendermint, please visit the documentation.
The two guides to focus on are the Application Development Guide and Using ABCI-CLI.

Protocl Buffers Copy Chapter

To compile the protobuf file, run:

make protoc

See protoc --help and the Protocol Buffers site
for details on compiling for other languages. Note we also include a GRPC
service definition.

Install ABCI-CLI Copy Chapter

The abci-cli is a simple tool for debugging ABCI servers and running some
example apps. To install it:

go get github.com/tendermint/abci
cd $GOPATH/src/github.com/tendermint/abci
make get_vendor_deps
make install

Implementation Copy Chapter

We provide three implementations of the ABCI in Go:

• Golang in-process
• ABCI-socket
• GRPC

Note the GRPC version is maintained primarily to simplify onboarding and prototyping and is not receiving the same
attention to security and performance as the others

In Process Copy Section

The simplest implementation just uses function calls within Go.
This means ABCI applications written in Golang can be compiled with TendermintCore and run as a single binary.

See the examples below for more information.

Socket (TSP) Copy Section

ABCI is best implemented as a streaming protocol.
The socket implementation provides for asynchronous, ordered message passing over unix or tcp.
Messages are serialized using Protobuf3 and length-prefixed with a signed Varint

For example, if the Protobuf3 encoded ABCI message is 0xDEADBEEF (4 bytes), the length-prefixed message is 0x08DEADBEEF, since 0x08 is the signed varint
encoding of 4. If the Protobuf3 encoded ABCI message is 65535 bytes long, the length-prefixed message would be like 0xFEFF07....

Note the benefit of using this varint encoding over the old version (where integers were encoded as <len of len> is that
it is the standard way to encode integers in Protobuf. It is also generally shorter.

GRPC Copy Section

GRPC is an rpc framework native to Protocol Buffers with support in many languages.
Implementing the ABCI using GRPC can allow for faster prototyping, but is expected to be much slower than
the ordered, asynchronous socket protocol. The implementation has also not received as much testing or review.

Note the length-prefixing used in the socket implementation does not apply for GRPC.

Usage Copy Chapter

The abci-cli tool wraps an ABCI client and can be used for probing/testing an ABCI server.
For instance, abci-cli test will run a test sequence against a listening server running the Counter application (see below).
It can also be used to run some example applications.
See the documentation for more details.

Examples Copy Section

Check out the variety of example applications in the example directory.
It also contains the code refered to by the counter and kvstore apps; these apps come
built into the abci-cli binary.

Counter

The abci-cli counter application illustrates nonce checking in transactions. It's code looks like:

func cmdCounter(cmd *cobra.Command, args []string) error {

	app := counter.NewCounterApplication(flagSerial)

	logger := log.NewTMLogger(log.NewSyncWriter(os.Stdout))

	// Start the listener
	srv, err := server.NewServer(flagAddrC, flagAbci, app)
	if err != nil {
		return err
	}
	srv.SetLogger(logger.With("module", "abci-server"))
	if err := srv.Start(); err != nil {
		return err
	}

	// Wait forever
	cmn.TrapSignal(func() {
		// Cleanup
		srv.Stop()
	})
	return nil
}

and can be found in this file.

kvstore

The abci-cli kvstore application, which illustrates a simple key-value Merkle tree

func cmdKVStore(cmd *cobra.Command, args []string) error {
	logger := log.NewTMLogger(log.NewSyncWriter(os.Stdout))

	// Create the application - in memory or persisted to disk
	var app types.Application
	if flagPersist == "" {
		app = kvstore.NewKVStoreApplication()
	} else {
		app = kvstore.NewPersistentKVStoreApplication(flagPersist)
		app.(*kvstore.PersistentKVStoreApplication).SetLogger(logger.With("module", "kvstore"))
	}

	// Start the listener
	srv, err := server.NewServer(flagAddrD, flagAbci, app)
	if err != nil {
		return err
	}
	srv.SetLogger(logger.With("module", "abci-server"))
	if err := srv.Start(); err != nil {
		return err
	}

	// Wait forever
	cmn.TrapSignal(func() {
		// Cleanup
		srv.Stop()
	})
	return nil
}

Overview (`example/js/README.md`) Copy Section

This example has been moved here: https://github.com/tendermint/js-abci/tree/master/example

Overview (`example/kvstore/README.md`) Copy Section

KVStore

There are two app's here: the KVStoreApplication and the PersistentKVStoreApplication.

KVStoreApplication Copy Chapter

The KVStoreApplication is a simple merkle key-value store.
Transactions of the form key=value are stored as key-value pairs in the tree.
Transactions without an = sign set the value to the key.
The app has no replay protection (other than what the mempool provides).

PersistentKVStoreApplication Copy Chapter

The PersistentKVStoreApplication wraps the KVStoreApplication
and provides two additional features:

1. persistence of state across app restarts (using Tendermint's ABCI-Handshake mechanism)
2. validator set changes

The state is persisted in leveldb along with the last block committed,
and the Handshake allows any necessary blocks to be replayed.
Validator set changes are effected using the following transaction format:

val:pubkey1/power1,addr2/power2,addr3/power3"

where power1 is the new voting power for the validator with pubkey1 (possibly a new one).
There is no sybil protection against new validators joining.
Validators can be removed by setting their power to 0.

--- METRICS ---

• Files Extracted: 3
• Estimated Token Budget: ~1734 tokens
• Canonical Reference: https://codewiki.google/github.com/tendermint/abci