Add cometbft v0.38

cometbft/v0.38/docs/DOCS_README.md

@@ -0,0 +1,13 @@
+# Docs Build Workflow
+
+The documentation for CometBFT is hosted at:
+
+- <https://docs.cometbft.com>
+
+built from the files in these (`/docs` and `/spec`) directories.
+
+Content modified and merged to these folders will be deployed to the `https://docs.cometbft.com` website using workflow logic from the [cometbft-docs](https://github.com/cometbft/cometbft-docs) repository
+
+### Building locally
+
+For information on how to build the documentation and view it locally, please visit the [cometbft-docs](https://github.com/cometbft/cometbft-docs) Github repository.

cometbft/v0.38/docs/README.md

@@ -0,0 +1,43 @@
+---
+title: CometBFT Documentation
+description: CometBFT is a blockchain application platform.
+footer:
+  newsletter: false
+---
+
+# CometBFT
+
+Welcome to the CometBFT documentation!
+
+CometBFT is a blockchain application platform; it provides the equivalent
+of a web-server, database, and supporting libraries for blockchain applications
+written in any programming language. Like a web-server serving web applications,
+CometBFT serves blockchain applications.
+
+More formally, CometBFT performs Byzantine Fault Tolerant (BFT)
+State Machine Replication (SMR) for arbitrary deterministic, finite state machines.
+For more background, see [What is CometBFT?](./introduction/README.md#what-is-cometbft).
+
+To get started quickly with an example application, see the [quick start guide](guides/quick-start.md).
+
+To learn about application development on CometBFT, see the [Application Blockchain Interface](https://github.com/cometbft/cometbft/tree/v0.38.x/spec/abci).
+
+For more details on using CometBFT, see the respective documentation for
+[CometBFT internals](core/), [benchmarking and monitoring](tools/), and [network deployments](networks/).
+
+## Contribute
+
+To recommend a change to the documentation, please submit a PR. Each major
+release's documentation is housed on the corresponding release branch, e.g. for
+the v0.34 release series, the documentation is housed on the `v0.34.x` branch.
+
+When submitting changes that affect all releases, please start by submitting a
+PR to the docs on `main` - this will be backported to the relevant release
+branches. If a change is exclusively relevant to a specific release, please
+target that release branch with your PR.
+
+Changes to the documentation will be reviewed by the team and, if accepted and
+merged, published to (https://docs.cometbft.com) for the respective version(s).
+
+The build process for the documentation is housed in the [CometBFT documentation
+repository](https://github.com/cometbft/cometbft-docs).

cometbft/v0.38/docs/app-dev/README.md

@@ -0,0 +1,12 @@
+---
+order: false
+parent:
+  order: 3
+---
+
+# Apps
+
+- [Using ABCI-CLI](./abci-cli.md)
+- [Getting Started](./getting-started.md)
+- [Indexing transactions](./indexing-transactions.md)
+- [Application Architecture Guide](./app-architecture.md)

cometbft/v0.38/docs/app-dev/abci-cli.md

@@ -0,0 +1,213 @@
+---
+order: 3
+---
+
+# Using ABCI-CLI
+
+To facilitate testing and debugging of ABCI servers and simple apps, we
+built a CLI, the `abci-cli`, for sending ABCI messages from the command
+line.
+
+## Install
+
+Make sure you [have Go installed](https://golang.org/doc/install).
+
+Next, install the `abci-cli` tool and example applications:
+
+```sh
+git clone https://github.com/cometbft/cometbft.git
+cd cometbft
+make install_abci
+```
+
+Now run `abci-cli` to see the list of commands:
+
+```sh
+Usage:
+  abci-cli [command]
+
+Available Commands:
+  batch            run a batch of abci commands against an application
+  check_tx         validate a transaction
+  commit           commit the application state and return the Merkle root hash
+  completion       Generate the autocompletion script for the specified shell
+  console          start an interactive ABCI console for multiple commands
+  echo             have the application echo a message
+  finalize_block   deliver a block of transactions to the application
+  help             Help about any command
+  info             get some info about the application
+  kvstore          ABCI demo example
+  prepare_proposal prepare proposal
+  process_proposal process proposal
+  query            query the application state
+  test             run integration tests
+  version          print ABCI console version
+
+Flags:
+      --abci string        either socket or grpc (default "socket")
+      --address string     address of application socket (default "tcp://0.0.0.0:26658")
+  -h, --help               help for abci-cli
+      --log_level string   set the logger level (default "debug")
+  -v, --verbose            print the command and results as if it were a console session
+
+Use "abci-cli [command] --help" for more information about a command.
+```
+
+## KVStore - First Example
+
+The `abci-cli` tool lets us send ABCI messages to our application, to
+help build and debug them.
+
+The most important messages are `deliver_tx`, `check_tx`, and `commit`,
+but there are others for convenience, configuration, and information
+purposes.
+
+We'll start a kvstore application, which was installed at the same time as
+`abci-cli` above. The kvstore just stores transactions in a Merkle tree. Its
+code can be found
+[here](https://github.com/cometbft/cometbft/blob/v0.38.x/abci/example/kvstore/kvstore.go).
+
+Start the application by running:
+
+```sh
+abci-cli kvstore
+```
+
+And in another terminal, run
+
+```sh
+abci-cli echo hello
+abci-cli info
+```
+
+You'll see something like:
+
+```sh
+-> data: hello
+-> data.hex: 68656C6C6F
+```
+
+and:
+
+```sh
+-> data: {"size":0}
+-> data.hex: 7B2273697A65223A307D
+```
+
+An ABCI application must provide two things:
+
+- a socket server
+- a handler for ABCI messages
+
+When we run the `abci-cli` tool we open a new connection to the
+application's socket server, send the given ABCI message, and wait for a
+response.
+
+The server may be generic for a particular language, and we provide a
+[reference implementation in
+Golang](https://github.com/cometbft/cometbft/tree/v0.38.x/abci/server). See the
+[list of other ABCI implementations](https://github.com/tendermint/awesome#ecosystem) for servers in
+other languages.
+
+The handler is specific to the application, and may be arbitrary, so
+long as it is deterministic and conforms to the ABCI interface
+specification.
+
+So when we run `abci-cli info`, we open a new connection to the ABCI
+server, which calls the `Info()` method on the application, which tells
+us the number of transactions in our Merkle tree.
+
+Now, since every command opens a new connection, we provide the
+`abci-cli console` and `abci-cli batch` commands, to allow multiple ABCI
+messages to be sent over a single connection.
+
+Running `abci-cli console` should drop you in an interactive console for
+speaking ABCI messages to your application.
+
+Try running these commands:
+
+```sh
+> echo hello
+-> code: OK
+-> data: hello
+-> data.hex: 0x68656C6C6F
+
+> info
+-> code: OK
+-> data: {"size":0}
+-> data.hex: 0x7B2273697A65223A307D
+
+> prepare_proposal "abc=123"
+-> code: OK
+-> log: Succeeded. Tx: abc=123
+
+> process_proposal "abc==456"
+-> code: OK
+-> status: REJECT
+
+> process_proposal "abc=123"
+-> code: OK
+-> status: ACCEPT
+
+> finalize_block "abc=123"
+-> code: OK
+-> code: OK
+-> data.hex: 0x0200000000000000
+
+> commit
+-> code: OK
+
+> info
+-> code: OK
+-> data: {"size":1}
+-> data.hex: 0x7B2273697A65223A317D
+
+> query "abc"
+-> code: OK
+-> log: exists
+-> height: 0
+-> key: abc
+-> key.hex: 616263
+-> value: 123
+-> value.hex: 313233
+
+> finalize_block "def=xyz" "ghi=123"
+-> code: OK
+-> code: OK
+-> code: OK
+-> data.hex: 0x0600000000000000
+
+> commit
+-> code: OK
+
+> query "def"
+-> code: OK
+-> log: exists
+-> height: 0
+-> key: def
+-> key.hex: 646566
+-> value: xyz
+-> value.hex: 78797A
+```
+
+Note that if we do `finalize_block "abc" ...` it will store `(abc, abc)`, but if
+we do `finalize_block "abc=efg" ...` it will store `(abc, efg)`.
+
+You could put the commands in a file and run
+`abci-cli --verbose batch < myfile`.
+
+
+Note that the `abci-cli` is designed strictly for testing and debugging. In a real
+deployment, the role of sending messages is taken by CometBFT, which
+connects to the app using four separate connections, each with its own
+pattern of messages.
+
+For examples of running an ABCI app with CometBFT, see the
+[getting started guide](./getting-started.md).
+
+## Bounties
+
+Want to write an app in your favorite language?! We'd be happy
+to add you to our [ecosystem](https://github.com/tendermint/awesome#ecosystem)!
+See [funding](https://github.com/interchainio/funding) opportunities from the
+[Interchain Foundation](https://interchain.io) for implementations in new languages and more.

cometbft/v0.38/docs/app-dev/app-architecture.md

@@ -0,0 +1,55 @@
+---
+order: 4
+---
+
+# Application Architecture Guide
+
+Here we provide a brief guide on the recommended architecture of a
+CometBFT blockchain application.
+
+We distinguish here between two forms of "application". The first is the
+end-user application, like a desktop-based wallet app that a user downloads,
+which is where the user actually interacts with the system. The other is the
+ABCI application, which is the logic that actually runs on the blockchain.
+Transactions sent by an end-user application are ultimately processed by the ABCI
+application after being committed by CometBFT.
+
+The end-user application communicates with a REST API exposed by the application.
+The application runs CometBFT nodes and verifies CometBFT light-client proofs
+through the CometBFT RPC. The CometBFT process communicates with
+a local ABCI application, where the user query or transaction is actually
+processed.
+
+The ABCI application must be a deterministic result of the CometBFT
+consensus - any external influence on the application state that didn't
+come through CometBFT could cause a consensus failure. Thus _nothing_
+should communicate with the ABCI application except CometBFT via ABCI.
+
+If the ABCI application is written in Go, it can be compiled into the
+CometBFT binary. Otherwise, it should use a unix socket to communicate
+with CometBFT. If it's necessary to use TCP, extra care must be taken
+to encrypt and authenticate the connection.
+
+All reads from the ABCI application happen through the CometBFT `/abci_query`
+endpoint. All writes to the ABCI application happen through the CometBFT
+`/broadcast_tx_*` endpoints.
+
+The Light-Client Daemon is what provides light clients (end users) with
+nearly all the security of a full node. It formats and broadcasts
+transactions, and verifies proofs of queries and transaction results.
+Note that it need not be a daemon - the Light-Client logic could instead
+be implemented in the same process as the end-user application.
+
+Note for those ABCI applications with weaker security requirements, the
+functionality of the Light-Client Daemon can be moved into the ABCI
+application process itself. That said, exposing the ABCI application process
+to anything besides CometBFT over ABCI requires extreme caution, as
+all transactions, and possibly all queries, should still pass through
+CometBFT.
+
+See the following for more extensive documentation:
+
+- [Interchain Standard for the Light-Client REST API](https://github.com/cosmos/cosmos-sdk/pull/1617) (legacy/deprecated)
+- [CometBFT RPC Docs](../rpc)
+- [CometBFT in Production](../core/running-in-production.md)
+- [ABCI spec](../spec/abci)