This section is for those looking to implement their own ABCI Server, perhaps in a new programming language.
You are expected to have read all previous sections of ABCI++ specification, namely Basic Concepts, Methods, Application Requirements, and Expected Behavior.
The message protocol consists of pairs of requests and responses defined in the protobuf file.
Some messages have no fields, while others may include byte-arrays, strings, integers, or custom protobuf types.
For more details on protobuf, see the documentation.
To use ABCI in your programming language of choice, there must be an ABCI server in that language. CometBFT supports four implementations of the ABCI server:
The implementations in CometBFT’s repository can be tested using
abci-cli by setting
--abci flag appropriately.
The simplest implementation uses function calls in Golang. This means ABCI applications written in Golang can be linked with CometBFT and run as a single binary.
If you are not using Golang, but GRPC is available in your language, this is the easiest approach, though it will have significant performance overhead.
Please check GRPC’s documentation to know to set up the Application as an ABCI GRPC server.
The CometBFT Socket Protocol is an asynchronous, raw socket server protocol which provides ordered message passing over Unix or TCP sockets. Messages are serialized using Protobuf3 and length-prefixed with an unsigned varint
If gRPC is not available in your language, or you require higher performance, or
otherwise enjoy programming, you may implement your own ABCI server using the
CometBFT Socket Protocol. The first step is still to auto-generate the
relevant data types and codec in your language using
protoc, and then you need to
ensure you handle the unsigned
varint-based message length encoding scheme
when reading and writing messages to the socket.
Note that our length prefixing scheme does not apply to gRPC.
Also note that your ABCI server must be able to handle multiple connections, as CometBFT uses four connections.
There are currently two use-cases for an ABCI client. One is testing
tools that allow ABCI requests to be sent to the actual application via
command line. An example of this is
abci-cli, which accepts CLI commands
to send corresponding ABCI requests.
The other is a consensus engine, such as CometBFT,
which makes ABCI requests to the application as prescribed by the consensus