diff --git a/CHANGELOG.md b/CHANGELOG.md index f031d17f9..a3f4a881e 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -863,7 +863,7 @@ and a validator address plus a timestamp. Note we may remove the validator address & timestamp fields in the future (see ADR-25). `lite2` package has been added to solve `lite` issues and introduce weak -subjectivity interface. Refer to the [spec](https://github.com/tendermint/tendermint/blob/main/spec/consensus/light-client.md) for complete details. +subjectivity interface. Refer to the [spec](https://github.com/tendermint/tendermint/tree/main/spec/consensus/light-client) for complete details. `lite` package is now deprecated and will be removed in v0.34 release. ### BREAKING CHANGES: @@ -1223,8 +1223,8 @@ Special thanks to external contributors on this release: @jon-certik, @gracenoah *August 28, 2019* -@climber73 wrote the [Writing a Tendermint Core application in Java -(gRPC)](https://github.com/tendermint/tendermint/blob/main/docs/guides/java.md) +@climber73 wrote the [Writing a Tendermint Core application in Java +(gRPC)](https://docs.tendermint.com/v0.34/tutorials/java.html) guide. Special thanks to external contributors on this release: @@ -2614,7 +2614,7 @@ are affected by a change. A few more breaking changes are in the works - each will come with a clear Architecture Decision Record (ADR) explaining the change. You can review ADRs -[here](https://github.com/tendermint/tendermint/tree/develop/docs/architecture) +[here](https://github.com/tendermint/tendermint/tree/main/docs/architecture) or in the [open Pull Requests](https://github.com/tendermint/tendermint/pulls). You can also check in on the [issues marked as breaking](https://github.com/tendermint/tendermint/issues?q=is%3Aopen+is%3Aissue+label%3Abreaking). @@ -2893,7 +2893,7 @@ BREAKING CHANGES: FEATURES - [cmd] Added metrics (served under `/metrics` using a Prometheus client; disabled by default). See the new `instrumentation` section in the config and - [metrics](https://tendermint.readthedocs.io/projects/tools/en/develop/metrics.html) + [metrics](https://github.com/tendermint/tendermint/blob/main/docs/tendermint-core/metrics.md) guide. - [p2p] Add IPv6 support to peering. - [p2p] Add `external_address` to config to allow specifying the address for @@ -3007,7 +3007,7 @@ BREAKING: FEATURES -- [rpc] the RPC documentation is now published to https://tendermint.github.io/slate +- [rpc] the RPC documentation is now published to https://github.com/tendermint/tendermint/tree/main/spec/rpc - [p2p] AllowDuplicateIP config option to refuse connections from same IP. - true by default for now, false by default in next breaking release - [docs] Add docs for query, tx indexing, events, pubsub @@ -3486,7 +3486,7 @@ containing substructs: `BaseConfig`, `P2PConfig`, `MempoolConfig`, `ConsensusCon - Logger - Replace static `log15` logger with a simple interface, and provide a new implementation using `go-kit`. -See our new [logging library](https://github.com/tendermint/tmlibs/log) and [blog post](https://tendermint.com/blog/abstracting-the-logger-interface-in-go) for more details +See our new [logging library](https://github.com/tendermint/tendermint/blob/main/libs/log/logger.go) and [blog post](https://blog.cosmos.network/abstracting-the-logger-interface-in-go-4cf96bf90bb7) for more details - Levels `warn` and `notice` are removed (you may need to change them in your `config.toml`!) - Change some [function and method signatures](https://gist.github.com/ebuchman/640d5fc6c2605f73497992fe107ebe0b) to accept a logger diff --git a/DOCKER/README.md b/DOCKER/README.md index 56944793d..763c043b5 100644 --- a/DOCKER/README.md +++ b/DOCKER/README.md @@ -8,7 +8,7 @@ Official releases can be found [here](https://github.com/tendermint/tendermint/r The Dockerfile for Tendermint is not expected to change in the near future. The main file used for all builds can be found [here](https://raw.githubusercontent.com/tendermint/tendermint/main/DOCKER/Dockerfile). -Respective versioned files can be found (replace the Xs with the version number). +Respective versioned files can be found at `https://raw.githubusercontent.com/tendermint/tendermint/vX.XX.XX/DOCKER/Dockerfile` (replace the Xs with the version number). ## Quick reference diff --git a/README.md b/README.md index 56eae4ba9..6c255cc7b 100644 --- a/README.md +++ b/README.md @@ -70,8 +70,8 @@ See the [install instructions](./docs/introduction/install.md). ### Quick Start - [Single node](./docs/introduction/quick-start.md) -- [Local cluster using docker-compose](./docs/tools/docker-compose.md) -- [Remote cluster using Terraform and Ansible](./docs/tools/terraform-and-ansible.md) +- [Local cluster using docker-compose](./docs/networks/docker-compose.md) +- [Remote cluster using Terraform and Ansible](./docs/networks/terraform-and-ansible.md) ## Contributing @@ -145,7 +145,7 @@ Upgrading instructions can be found in [UPGRADING.md](./UPGRADING.md). ## Join us! -Tendermint Core is maintained by [Interchain GmbH](https://interchain.berlin). +Tendermint Core is maintained by [Interchain GmbH](https://interchain.io). If you'd like to work full-time on Tendermint Core, [we're hiring](https://interchain-gmbh.breezy.hr/)! diff --git a/RELEASES.md b/RELEASES.md index ae6650e67..d17ac467c 100644 --- a/RELEASES.md +++ b/RELEASES.md @@ -45,7 +45,7 @@ the 0.38.x line. 1. Start on `main` 2. Ensure that there is a [branch protection - rule](https://github.com/tendermint/tendermint/settings/branches) for the + rule](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule) for the branch you are about to create (you will need admin access to the repository in order to do this). diff --git a/UPGRADING.md b/UPGRADING.md index 45b948330..001f1b7eb 100644 --- a/UPGRADING.md +++ b/UPGRADING.md @@ -12,7 +12,7 @@ Tendermint Core. * Added new ABCI methods `PrepareProposal` and `ProcessProposal`. For details, please see the [spec](spec/abci/README.md). Applications upgrading to v0.37.0 must implement these methods, at the very minimum, as described - [here](spec/abci/apps.md) + [here](./spec/abci/abci++_app_requirements.md) * Deduplicated `ConsensusParams` and `BlockParams`. In the v0.34 branch they are defined both in `abci/types.proto` and `types/params.proto`. The definitions in `abci/types.proto` have been removed. diff --git a/abci/README.md b/abci/README.md index 025b467a7..b4e3ed04c 100644 --- a/abci/README.md +++ b/abci/README.md @@ -19,8 +19,8 @@ To get up and running quickly, see the [getting started guide](../docs/app-dev/g A detailed description of the ABCI methods and message types is contained in: -- [The main spec](https://github.com/tendermint/tendermint/blob/main/spec/abci/abci.md) -- [A protobuf file](./types/types.proto) +- [The main spec](https://github.com/tendermint/tendermint/blob/main/spec/abci/README.md) +- [A protobuf file](../proto/tendermint/types/types.proto) - [A Go interface](./types/application.go) ## Protocol Buffers diff --git a/consensus/README.md b/consensus/README.md index 666abb6af..eb173d6ef 100644 --- a/consensus/README.md +++ b/consensus/README.md @@ -1,3 +1,3 @@ # Consensus -See the [consensus spec](https://github.com/tendermint/tendermint/tree/main/spec/consensus) and the [reactor consensus spec](https://github.com/tendermint/tendermint/tree/main/spec/reactors/consensus) for more information. +See the [consensus spec](https://github.com/tendermint/tendermint/tree/main/spec/consensus) for more information. \ No newline at end of file diff --git a/docs/app-dev/abci-cli.md b/docs/app-dev/abci-cli.md index e5486ee87..eed169ec7 100644 --- a/docs/app-dev/abci-cli.md +++ b/docs/app-dev/abci-cli.md @@ -253,14 +253,13 @@ Similarly, you could put the commands in a file and run 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. +[Interchain Foundation](https://interchain.io) for implementations in new languages and more. The `abci-cli` is designed strictly for testing and debugging. In a real deployment, the role of sending messages is taken by Tendermint, which connects to the app using three separate connections, each with its own pattern of messages. -For more information, see the [application developers -guide](./app-development.md). For examples of running an ABCI app with +For examples of running an ABCI app with Tendermint, see the [getting started guide](./getting-started.md). Next is the ABCI specification. diff --git a/docs/app-dev/indexing-transactions.md b/docs/app-dev/indexing-transactions.md index c9b5d106a..0aba61583 100644 --- a/docs/app-dev/indexing-transactions.md +++ b/docs/app-dev/indexing-transactions.md @@ -15,7 +15,7 @@ the block itself is never stored. Each event contains a type and a list of attributes, which are key-value pairs denoting something about what happened during the method's execution. For more details on `Events`, see the -[ABCI](https://github.com/tendermint/tendermint/blob/main/spec/abci/abci.md#events) +[ABCI](https://github.com/tendermint/tendermint/blob/main/spec/abci/abci++_basic_concepts.md#events) documentation. An `Event` has a composite key associated with it. A `compositeKey` is diff --git a/docs/architecture/adr-056-light-client-amnesia-attacks.md b/docs/architecture/adr-056-light-client-amnesia-attacks.md index 8c5abfdb1..dcd8d2e40 100644 --- a/docs/architecture/adr-056-light-client-amnesia-attacks.md +++ b/docs/architecture/adr-056-light-client-amnesia-attacks.md @@ -63,7 +63,7 @@ Light clients where all witnesses are faulty can be subject to an amnesia attack ## References - + - [Fork accountability algorithm](https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit) - [Fork accountability spec](https://github.com/tendermint/tendermint/blob/main/spec/consensus/light-client/accountability.md) diff --git a/docs/architecture/adr-076-combine-spec-repo.md b/docs/architecture/adr-076-combine-spec-repo.md index a6365da5b..0b413c8df 100644 --- a/docs/architecture/adr-076-combine-spec-repo.md +++ b/docs/architecture/adr-076-combine-spec-repo.md @@ -108,5 +108,5 @@ N/A ## References -- https://github.com/tendermint/spec +- https://github.com/tendermint/tendermint/tree/main/spec - https://github.com/tendermint/tendermint diff --git a/docs/introduction/what-is-tendermint.md b/docs/introduction/what-is-tendermint.md index a7d3f655e..b22ca38ba 100644 --- a/docs/introduction/what-is-tendermint.md +++ b/docs/introduction/what-is-tendermint.md @@ -106,7 +106,7 @@ docker containers, modules it calls "chaincode". It uses an implementation of [PBFT](http://pmg.csail.mit.edu/papers/osdi99.pdf). from a team at IBM that is [augmented to handle potentially non-deterministic -chaincode](https://www.zurich.ibm.com/~cca/papers/sieve.pdf) It is +chaincode](https://drops.dagstuhl.de/opus/volltexte/2017/7093/pdf/LIPIcs-OPODIS-2016-24.pdf) It is possible to implement this docker-based behavior as a ABCI app in Tendermint, though extending Tendermint to handle non-determinism remains for future work. diff --git a/docs/rfc/rfc-002-ipc-ecosystem.md b/docs/rfc/rfc-002-ipc-ecosystem.md index 182c921f0..8a15ae463 100644 --- a/docs/rfc/rfc-002-ipc-ecosystem.md +++ b/docs/rfc/rfc-002-ipc-ecosystem.md @@ -416,5 +416,5 @@ discussed. [socket-server]: https://github.com/tendermint/tendermint/blob/main/abci/server/socket_server.go [sdk-grpc]: https://pkg.go.dev/github.com/cosmos/cosmos-sdk/types/tx#ServiceServer [json-rpc]: https://www.jsonrpc.org/specification -[abci-conn]: https://github.com/tendermint/tendermint/blob/main/spec/abci/apps.md#state +[abci-conn]: https://github.com/tendermint/tendermint/blob/main/spec/abci/abci++_basic_concepts.md [adr-57]: https://github.com/tendermint/tendermint/blob/main/docs/architecture/adr-057-RPC.md diff --git a/docs/rfc/rfc-003-performance-questions.md b/docs/rfc/rfc-003-performance-questions.md index d141eb7d2..cb1d986e8 100644 --- a/docs/rfc/rfc-003-performance-questions.md +++ b/docs/rfc/rfc-003-performance-questions.md @@ -272,7 +272,7 @@ event sends. The following metrics would be a good start for tracking this perfo [rfc-002]: https://github.com/tendermint/tendermint/pull/6913 [adr-57]: https://github.com/tendermint/tendermint/blob/main/docs/architecture/adr-057-RPC.md [issue-1319]: https://github.com/tendermint/tendermint/issues/1319 -[abci-commit-description]: https://github.com/tendermint/tendermint/blob/main/spec/abci/apps.md#commit +[abci-commit-description]: https://github.com/tendermint/tendermint/blob/main/spec/abci/abci++_methods.md#commit [abci-local-client-code]: https://github.com/tendermint/tendermint/blob/511bd3eb7f037855a793a27ff4c53c12f085b570/abci/client/local_client.go#L84 [hub-signature]: https://github.com/cosmos/gaia/blob/0ecb6ed8a244d835807f1ced49217d54a9ca2070/docs/resources/genesis.md#consensus-parameters [ed25519-bench]: https://github.com/oasisprotocol/curve25519-voi/blob/d2e7fc59fe38c18ca990c84c4186cba2cc45b1f9/PERFORMANCE.md diff --git a/docs/rfc/rfc-006-event-subscription.md b/docs/rfc/rfc-006-event-subscription.md index f4d694adf..0e03c1191 100644 --- a/docs/rfc/rfc-006-event-subscription.md +++ b/docs/rfc/rfc-006-event-subscription.md @@ -195,7 +195,7 @@ mutually exclusive. - [JSON-RPC 2.0 Specification](https://www.jsonrpc.org/specification) [rpc-service]: https://docs.tendermint.com/v0.34/rpc/ -[rpc-methods]: https://github.com/tendermint/tendermint/blob/main/internal/rpc/core/routes.go#L12 +[rpc-methods]: https://github.com/tendermint/tendermint/blob/main/rpc/core/routes.go#L12 [events]: ./rfc-005-event-system.rst [rpc-transport]: ./rfc-002-ipc-ecosystem.md#rpc-transport [ws]: https://datatracker.ietf.org/doc/html/rfc6455 diff --git a/docs/rfc/rfc-012-custom-indexing.md b/docs/rfc/rfc-012-custom-indexing.md index 1a7708175..64f9fc94b 100644 --- a/docs/rfc/rfc-012-custom-indexing.md +++ b/docs/rfc/rfc-012-custom-indexing.md @@ -343,10 +343,10 @@ something like this (subject to refinement): [i1161]: https://github.com/tendermint/tendermint/issues/1161 [i7135]: https://github.com/tendermint/tendermint/issues/7135 [i7247]: https://github.com/tendermint/tendermint/issues/7247 -[kv-index]: https://github.com/tendermint/tendermint/blob/main/internal/state/indexer/tx/kv +[kv-index]: https://github.com/tendermint/tendermint/blob/main/state/indexer/block/kv [postgres]: https://postgresql.org/ -[psql]: https://github.com/tendermint/tendermint/blob/main/internal/state/indexer/sink/psql -[psql]: https://github.com/tendermint/tendermint/blob/main/internal/state/indexer/sink/psql +[psql]: https://github.com/tendermint/tendermint/tree/main/state/indexer/sink/psql +[psql]: https://github.com/tendermint/tendermint/tree/main/state/indexer/sink/psql [query]: https://pkg.go.dev/github.com/tendermint/tendermint/internal/pubsub/query/syntax [sdk]: https://github.com/cosmos/cosmos-sdk [tmdb]: https://pkg.go.dev/github.com/tendermint/tm-db#DB diff --git a/docs/rfc/rfc-019-config-version.md b/docs/rfc/rfc-019-config-version.md index a4cdcc4b3..5bf0c104a 100644 --- a/docs/rfc/rfc-019-config-version.md +++ b/docs/rfc/rfc-019-config-version.md @@ -1,3 +1,4 @@ + # RFC 019: Configuration File Versioning ## Changelog diff --git a/docs/tendermint-core/block-structure.md b/docs/tendermint-core/block-structure.md index 4563084a6..35ed69bd4 100644 --- a/docs/tendermint-core/block-structure.md +++ b/docs/tendermint-core/block-structure.md @@ -11,6 +11,6 @@ nodes. This blockchain is accessible via various RPC endpoints, mainly `/blockchain?minHeight=_&maxHeight=_` to get a list of headers. But what exactly is stored in these blocks? -The [specification](https://github.com/tendermint/spec/blob/8dd2ed4c6fe12459edeb9b783bdaaaeb590ec15c/spec/core/data_structures.md) contains a detailed description of each component - that's the best place to get started. +The [specification](https://github.com/tendermint/tendermint/blob/main/spec/core/data_structures.md) contains a detailed description of each component - that's the best place to get started. To dig deeper, check out the [types package documentation](https://godoc.org/github.com/tendermint/tendermint/types). diff --git a/docs/tendermint-core/how-to-read-logs.md b/docs/tendermint-core/how-to-read-logs.md index caad53df2..964e0457a 100644 --- a/docs/tendermint-core/how-to-read-logs.md +++ b/docs/tendermint-core/how-to-read-logs.md @@ -115,7 +115,7 @@ I[10-04|13:54:30.410] Recheck txs module=mempoo Here is the list of modules you may encounter in Tendermint's log and a little overview what they do. -- `abci-client` As mentioned in [Application Development Guide](../app-dev/app-development.md), Tendermint acts as an ABCI +- `abci-client` As mentioned in [Application Development Guide](../app-dev/abci-cli.md), Tendermint acts as an ABCI client with respect to the application and maintains 3 connections: mempool, consensus and query. The code used by Tendermint Core can be found [here](https://github.com/tendermint/tendermint/blob/v0.34.x/abci/client). diff --git a/docs/tendermint-core/running-in-production.md b/docs/tendermint-core/running-in-production.md index 85b3e8357..8da4b65a2 100644 --- a/docs/tendermint-core/running-in-production.md +++ b/docs/tendermint-core/running-in-production.md @@ -101,7 +101,7 @@ for more information. Rate-limiting and authentication are another key aspects to help protect against DOS attacks. Validators are supposed to use external tools like [NGINX](https://www.nginx.com/blog/rate-limiting-nginx/) or -[traefik](https://docs.traefik.io/middlewares/ratelimit/) +[traefik](https://doc.traefik.io/traefik/middlewares/http/ratelimit/) to achieve the same things. ## Debugging Tendermint @@ -332,7 +332,7 @@ We want `skip_timeout_commit=false` when there is economics on the line because proposers should wait to hear for more votes. But if you don't care about that and want the fastest consensus, you can skip it. It will be kept false by default for public deployments (e.g. [Cosmos -Hub](https://cosmos.network/intro/hub)) while for enterprise +Hub](https://hub.cosmos.network/)) while for enterprise applications, setting it to true is not a problem. - `consensus.peer_gossip_sleep_duration` diff --git a/docs/tendermint-core/subscription.md b/docs/tendermint-core/subscription.md index c03e850e7..31de9b16c 100644 --- a/docs/tendermint-core/subscription.md +++ b/docs/tendermint-core/subscription.md @@ -36,14 +36,14 @@ more information on query syntax and other options. You can also use tags, given you had included them into DeliverTx response, to query transaction results. See [Indexing -transactions](./indexing-transactions.md) for details. +transactions](../app-dev/indexing-transactions.md) for details. ## ValidatorSetUpdates When validator set changes, ValidatorSetUpdates event is published. The event carries a list of pubkey/power pairs. The list is the same Tendermint receives from ABCI application (see [EndBlock -section](https://github.com/tendermint/tendermint/blob/main/spec/abci/abci.md#endblock) in +section](https://github.com/tendermint/tendermint/blob/main/spec/abci/abci++_methods.md#endblock) in the ABCI spec). Response: diff --git a/docs/tendermint-core/using-tendermint.md b/docs/tendermint-core/using-tendermint.md index f3884a58a..91421854d 100644 --- a/docs/tendermint-core/using-tendermint.md +++ b/docs/tendermint-core/using-tendermint.md @@ -555,7 +555,7 @@ failing, you need at least four validator nodes (e.g., 2/3). Updating validators in a live network is supported but must be explicitly programmed by the application developer. See the [application -developers guide](../app-dev/app-development.md) for more details. +developers guide](../app-dev/abci-cli.md) for more details. ### Local Network diff --git a/docs/tendermint-core/validators.md b/docs/tendermint-core/validators.md index 084fe27fa..003474821 100644 --- a/docs/tendermint-core/validators.md +++ b/docs/tendermint-core/validators.md @@ -97,7 +97,7 @@ More Information can be found at these links: ### Validator keys -Protecting a validator's consensus key is the most important factor to take in when designing your setup. The key that a validator is given upon creation of the node is called a consensus key, it has to be online at all times in order to vote on blocks. It is **not recommended** to merely hold your private key in the default json file (`priv_validator_key.json`). Fortunately, the [Interchain Foundation](https://interchain.io/) has worked with a team to build a key management server for validators. You can find documentation on how to use it [here](https://github.com/iqlusioninc/tmkms), it is used extensively in production. You are not limited to using this tool, there are also [HSMs](https://safenet.gemalto.com/data-encryption/hardware-security-modules-hsms/), there is not a recommended HSM. +Protecting a validator's consensus key is the most important factor to take in when designing your setup. The key that a validator is given upon creation of the node is called a consensus key, it has to be online at all times in order to vote on blocks. It is **not recommended** to merely hold your private key in the default json file (`priv_validator_key.json`). Fortunately, the [Interchain Foundation](https://interchain.io) has worked with a team to build a key management server for validators. You can find documentation on how to use it [here](https://github.com/iqlusioninc/tmkms), it is used extensively in production. You are not limited to using this tool, there are also [HSMs](https://safenet.gemalto.com/data-encryption/hardware-security-modules-hsms/), there is not a recommended HSM. Currently Tendermint uses [Ed25519](https://ed25519.cr.yp.to/) keys which are widely supported across the security sector and HSMs. diff --git a/docs/tutorials/go-built-in.md b/docs/tutorials/go-built-in.md index d81668377..46a61c33b 100644 --- a/docs/tutorials/go-built-in.md +++ b/docs/tutorials/go-built-in.md @@ -214,7 +214,7 @@ etc.) by Tendermint Core. Valid transactions will eventually be committed given they are not too big and have enough gas. To learn more about gas, check out ["the -specification"](https://github.com/tendermint/tendermint/blob/main/spec/abci/apps.md#gas). +specification"](https://github.com/tendermint/tendermint/blob/main/spec/abci/abci++_app_requirements.md#gas). For the underlying key-value store we'll use [badger](https://github.com/dgraph-io/badger), which is an embeddable, diff --git a/docs/tutorials/go.md b/docs/tutorials/go.md index e0ba98589..1af809a1b 100644 --- a/docs/tutorials/go.md +++ b/docs/tutorials/go.md @@ -216,7 +216,7 @@ etc.) by Tendermint Core. Valid transactions will eventually be committed given they are not too big and have enough gas. To learn more about gas, check out ["the -specification"](https://github.com/tendermint/tendermint/blob/main/spec/abci/apps.md#gas). +specification"](https://github.com/tendermint/tendermint/blob/main/spec/abci/abci++_app_requirements.md#gas). For the underlying key-value store we'll use [badger](https://github.com/dgraph-io/badger), which is an embeddable, diff --git a/libs/events/README.md b/libs/events/README.md index 9c4d7dc55..836e9c72e 100644 --- a/libs/events/README.md +++ b/libs/events/README.md @@ -4,37 +4,30 @@ `import "github.com/tendermint/tendermint/libs/events"` -* [Overview](#pkg-overview) -* [Index](#pkg-index) - ## Overview Pub-Sub in go with event caching ## Index -* [type EventCache](#EventCache) - * [func NewEventCache(evsw Fireable) *EventCache](#NewEventCache) - * [func (evc *EventCache) FireEvent(event string, data EventData)](#EventCache.FireEvent) - * [func (evc *EventCache) Flush()](#EventCache.Flush) -* [type EventCallback](#EventCallback) -* [type EventData](#EventData) -* [type EventSwitch](#EventSwitch) - * [func NewEventSwitch() EventSwitch](#NewEventSwitch) -* [type Eventable](#Eventable) -* [type Fireable](#Fireable) +* [type EventCache](#type-eventcache) + * [func NewEventCache(evsw Fireable) *EventCache](#func-neweventcache) + * [func (evc *EventCache) FireEvent(event string, data EventData)](#func-eventcache-fireevent) + * [func (evc *EventCache) Flush()](#func-eventcache-flush) +* [type EventCallback](#type-eventcallback) +* [type EventData](#type-eventdata) +* [type EventSwitch](#type-eventswitch) + * [func NewEventSwitch() EventSwitch](#func-neweventswitch) +* [type Eventable](#type-eventable) +* [type Fireable](#type-fireable) ### Package files -[event_cache.go](/src/github.com/tendermint/tendermint/libs/events/event_cache.go) [events.go](/src/github.com/tendermint/tendermint/libs/events/events.go) +[event_cache.go](./event_cache.go) [events.go](./events.go) - - - - -## Type [EventCache](/src/target/event_cache.go?s=116:179#L5) +## Type [EventCache](./event_cache.go?s=116:179#L5) ``` go type EventCache struct { @@ -51,7 +44,7 @@ All events are cached. Filtering happens on Flush -### func [NewEventCache](/src/target/event_cache.go?s=239:284#L11) +### func [NewEventCache](./event_cache.go?s=239:284#L11) ``` go func NewEventCache(evsw Fireable) *EventCache @@ -63,7 +56,7 @@ Create a new EventCache with an EventSwitch as backend -### func (\*EventCache) [FireEvent](/src/target/event_cache.go?s=449:511#L24) +### func (\*EventCache) [FireEvent](./event_cache.go?s=449:511#L24) ``` go func (evc *EventCache) FireEvent(event string, data EventData) @@ -74,7 +67,7 @@ Cache an event to be fired upon finality. -### func (\*EventCache) [Flush](/src/target/event_cache.go?s=735:765#L31) +### func (\*EventCache) [Flush](./event_cache.go?s=735:765#L31) ``` go func (evc *EventCache) Flush() @@ -86,7 +79,7 @@ Clears cached events -## Type [EventCallback](/src/target/events.go?s=4201:4240#L185) +## Type [EventCallback](./events.go?s=4201:4240#L185) ``` go type EventCallback func(data EventData) @@ -100,7 +93,7 @@ type EventCallback func(data EventData) -## Type [EventData](/src/target/events.go?s=243:294#L14) +## Type [EventData](./events.go?s=243:294#L14) ``` go type EventData interface { @@ -119,7 +112,7 @@ via concrete implementation of this interface -## Type [EventSwitch](/src/target/events.go?s=560:771#L29) +## Type [EventSwitch](./events.go?s=560:771#L29) ``` go type EventSwitch interface { @@ -137,7 +130,7 @@ type EventSwitch interface { -### func [NewEventSwitch](/src/target/events.go?s=917:950#L46) +### func [NewEventSwitch](./events.go?s=917:950#L46) ``` go func NewEventSwitch() EventSwitch @@ -146,7 +139,7 @@ func NewEventSwitch() EventSwitch -## Type [Eventable](/src/target/events.go?s=378:440#L20) +## Type [Eventable](./events.go?s=378:440#L20) ``` go type Eventable interface { @@ -166,7 +159,7 @@ this interface to become eventable -## Type [Fireable](/src/target/events.go?s=490:558#L25) +## Type [Fireable](./events.go?s=490:558#L25) ``` go type Fireable interface { diff --git a/proto/README.md b/proto/README.md index ebecd82d1..a9e96a751 100644 --- a/proto/README.md +++ b/proto/README.md @@ -9,10 +9,10 @@ The `.proto` files within this section are core to the protocol and updates must ### Steps 1. Make an issue with the proposed change. - - Within in the issue members from both the Tendermint-go and Tendermint-rs team will leave comments. If there is not consensus on the change an [RFC](../rfc/README.md) may be requested. + - Within in the issue members from both the Tendermint-go and Tendermint-rs team will leave comments. If there is not consensus on the change an [RFC](../docs/rfc/README.md) may be requested. 1a. Submission of an RFC as a pull request should be made to facilitate further discussion. 1b. Merge the RFC. -2. Make the necessary changes to the `.proto` file(s), [core data structures](../spec/core/data_structures.md) and/or [ABCI protocol](../spec/abci/apps.md). +2. Make the necessary changes to the `.proto` file(s), [core data structures](../spec/core/data_structures.md) and/or [ABCI protocol](../spec/abci). 3. Open issues within Tendermint-go and Tendermint-rs repos. This is used to notify the teams that a change occurred in the spec. 1. Tag the issue with a spec version label. This will notify the team the changed has been made on master but has not entered a release. diff --git a/spec/consensus/light-client/accountability.md b/spec/consensus/light-client/accountability.md index 5cf46b0b4..73a33f9cf 100644 --- a/spec/consensus/light-client/accountability.md +++ b/spec/consensus/light-client/accountability.md @@ -1,3 +1,3 @@ # Fork accountability -Deprecated, please see [light-client/accountability](../../light-client/accountability.md). +Deprecated, please see [light-client/accountability](https://github.com/tendermint/tendermint/blob/main/spec/consensus/light-client/accountability.md). diff --git a/spec/consensus/light-client/detection.md b/spec/consensus/light-client/detection.md index 5c87562ba..1f6aa8b95 100644 --- a/spec/consensus/light-client/detection.md +++ b/spec/consensus/light-client/detection.md @@ -1,3 +1,3 @@ # Detection -Deprecated, please see [light-client/detection](../../light-client/detection.md). +Deprecated, please see [light-client/detection](https://github.com/tendermint/tendermint/blob/main/spec/consensus/light-client/accountability.md). \ No newline at end of file diff --git a/spec/consensus/light-client/verification.md b/spec/consensus/light-client/verification.md index 1f0104a40..fdd544b83 100644 --- a/spec/consensus/light-client/verification.md +++ b/spec/consensus/light-client/verification.md @@ -1,3 +1,3 @@ # Core Verification -Deprecated, please see [light-client/accountability](../../light-client/verification.md). +Deprecated, please see [light-client/accountability](https://github.com/tendermint/tendermint/blob/main/spec/consensus/light-client/verification.md). diff --git a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md index 2eb32bc7d..ea9fdd563 100644 --- a/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md +++ b/spec/consensus/proposer-based-timestamp/pbts-sysmodel_001_draft.md @@ -73,7 +73,7 @@ Finally, observe that the agreement ([Agreement] and [Time-Agreement]) propertie ### SAFETY -Here we will provide specifications that relate local time to block time. However, since we do not assume (by now) that local time is linked to real-time, these specifications also do not provide a relation between block time and real-time. Such properties are given [later](#REAL-TIME-SAFETY). +Here we will provide specifications that relate local time to block time. However, since we do not assume (by now) that local time is linked to real-time, these specifications also do not provide a relation between block time and real-time. Such properties are given [later](#real-time-safety). For a correct validator `V`, let `beginConsensus(V,k)` be the local time when it sets its height to `k`, and let `endConsensus(V,k)` be the time when it sets its height to `k + 1`. diff --git a/spec/consensus/readme.md b/spec/consensus/readme.md index aa79ba192..02e89727c 100644 --- a/spec/consensus/readme.md +++ b/spec/consensus/readme.md @@ -25,8 +25,5 @@ Specification of the Tendermint consensus protocol. - [Write Ahead Log](./wal.md) - Write ahead log used by the consensus state machine to recover from crashes. -The protocol used to gossip consensus messages between peers, which is critical -for liveness, is described in the [reactors section](../reactors/consensus/consensus.md). - There is also a [stale markdown description](consensus.md) of the consensus state machine (TODO update this). diff --git a/spec/core/data_structures.md b/spec/core/data_structures.md index d273bfde7..a3d1a4de7 100644 --- a/spec/core/data_structures.md +++ b/spec/core/data_structures.md @@ -47,8 +47,8 @@ and a list of evidence of malfeasance (ie. signing conflicting votes). | Name | Type | Description | Validation | |--------|-------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------| | Header | [Header](#header) | Header corresponding to the block. This field contains information used throughout consensus and other areas of the protocol. To find out what it contains, visit [header] (#header) | Must adhere to the validation rules of [header](#header) | -| Data | [Data](#data) | Data contains a list of transactions. The contents of the transaction is unknown to Tendermint. | This field can be empty or populated, but no validation is performed. Applications can perform validation on individual transactions prior to block creation using [checkTx](../abci/abci.md#checktx). -| Evidence | [EvidenceList](#evidence_list) | Evidence contains a list of infractions committed by validators. | Can be empty, but when populated the validations rules from [evidenceList](#evidence_list) apply | +| Data | [Data](#data) | Data contains a list of transactions. The contents of the transaction is unknown to Tendermint. | This field can be empty or populated, but no validation is performed. Applications can perform validation on individual transactions prior to block creation using [checkTx](https://github.com/tendermint/tendermint/blob/main/spec/abci/abci++_methods.md#checktx). +| Evidence | [EvidenceList](#evidencelist) | Evidence contains a list of infractions committed by validators. | Can be empty, but when populated the validations rules from [evidenceList](#evidencelist) apply | | LastCommit | [Commit](#commit) | `LastCommit` includes one vote for every validator. All votes must either be for the previous block, nil or absent. If a vote is for the previous block it must have a valid signature from the corresponding validator. The sum of the voting power of the validators that voted must be greater than 2/3 of the total voting power of the complete validator set. The number of votes in a commit is limited to 10000 (see `types.MaxVotesCount`). | Must be empty for the initial height and must adhere to the validation rules of [commit](#commit). | ## Execution @@ -142,7 +142,7 @@ versioning that this can refer to) | Name | type | Description | Validation | |-------|--------|-----------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------| | Block | uint64 | This number represents the version of the block protocol and must be the same throughout an operational network | Must be equal to protocol version being used in a network (`block.Version.Block == state.Version.Consensus.Block`) | -| App | uint64 | App version is decided on by the application. Read [here](../abci/abci.md#info) | `block.Version.App == state.Version.Consensus.App` | +| App | uint64 | App version is decided on by the application. Read [here](https://github.com/tendermint/tendermint/blob/main/spec/abci/abci++_app_requirements.md) | `block.Version.App == state.Version.Consensus.App` | ## BlockID @@ -151,7 +151,7 @@ The `BlockID` contains two distinct Merkle roots of the block. The `BlockID` inc | Name | Type | Description | Validation | |---------------|---------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------| | Hash | slice of bytes (`[]byte`) | MerkleRoot of all the fields in the header (ie. `MerkleRoot(header)`. | hash must be of length 32 | -| PartSetHeader | [PartSetHeader](#PartSetHeader) | Used for secure gossiping of the block during consensus, is the MerkleRoot of the complete serialized block cut into parts (ie. `MerkleRoot(MakeParts(block))`). | Must adhere to the validation rules of [PartSetHeader](#PartSetHeader) | +| PartSetHeader | [PartSetHeader](#partsetheader) | Used for secure gossiping of the block during consensus, is the MerkleRoot of the complete serialized block cut into parts (ie. `MerkleRoot(MakeParts(block))`). | Must adhere to the validation rules of [PartSetHeader](#partsetheader) | See [MerkleRoot](./encoding.md#MerkleRoot) for details. @@ -236,7 +236,7 @@ The vote includes information about the validator signing it. When stored in the | Height | uint64 | Height for which this vote was created for | Must be > 0 | | Round | int32 | Round that the commit corresponds to. | Must be > 0 | | BlockID | [BlockID](#blockid) | The blockID of the corresponding block. | [BlockID](#blockid) | -| Timestamp | [Time](#Time) | Timestamp represents the time at which a validator signed. | [Time](#time) | +| Timestamp | [Time](#time) | Timestamp represents the time at which a validator signed. | [Time](#time) | | ValidatorAddress | slice of bytes (`[]byte`) | Address of the validator | Length must be equal to 20 | | ValidatorIndex | int32 | Index at a specific block height that corresponds to the Index of the validator in the set. | must be > 0 | | Signature | slice of bytes (`[]byte`) | Signature by the validator if they participated in consensus for the associated bock. | Length of signature must be > 0 and < 64 | @@ -291,7 +291,7 @@ is locked in POLRound. The message is signed by the validator private key. | Round | int32 | Round that the commit corresponds to. | Must be > 0 | | POLRound | int64 | Proof of lock | Must be > 0 | | BlockID | [BlockID](#blockid) | The blockID of the corresponding block. | [BlockID](#blockid) | -| Timestamp | [Time](#Time) | Timestamp represents the time at which a validator signed. | [Time](#time) | +| Timestamp | [Time](#time) | Timestamp represents the time at which a validator signed. | [Time](#time) | | Signature | slice of bytes (`[]byte`) | Signature by the validator if they participated in consensus for the associated bock. | Length of signature must be > 0 and < 64 | ## SignedMsgType @@ -342,7 +342,7 @@ in the same round of the same height. Votes are lexicographically sorted on `Blo | VoteB | [Vote](#vote) | The second vote submitted by a validator when they equivocated | VoteB must adhere to [Vote](#vote) validation rules | | TotalVotingPower | int64 | The total power of the validator set at the height of equivocation | Must be equal to nodes own copy of the data | | ValidatorPower | int64 | Power of the equivocating validator at the height | Must be equal to the nodes own copy of the data | -| Timestamp | [Time](#Time) | Time of the block where the equivocation occurred | Must be equal to the nodes own copy of the data | +| Timestamp | [Time](#time) | Time of the block where the equivocation occurred | Must be equal to the nodes own copy of the data | ### LightClientAttackEvidence @@ -353,11 +353,11 @@ and Amnesia. These attacks are exhaustive. You can find a more detailed overview | Name | Type | Description | Validation | |----------------------|------------------------------------|----------------------------------------------------------------------|------------------------------------------------------------------| -| ConflictingBlock | [LightBlock](#LightBlock) | Read Below | Must adhere to the validation rules of [lightBlock](#lightblock) | +| ConflictingBlock | [LightBlock](#lightblock) | Read Below | Must adhere to the validation rules of [lightBlock](#lightblock) | | CommonHeight | int64 | Read Below | must be > 0 | -| Byzantine Validators | Array of [Validators](#Validators) | validators that acted maliciously | Read Below | +| Byzantine Validators | Array of [Validators](#validator) | validators that acted maliciously | Read Below | | TotalVotingPower | int64 | The total power of the validator set at the height of the infraction | Must be equal to the nodes own copy of the data | -| Timestamp | [Time](#Time) | Time of the block where the infraction occurred | Must be equal to the nodes own copy of the data | +| Timestamp | [Time](#time) | Time of the block where the infraction occurred | Must be equal to the nodes own copy of the data | ## LightBlock @@ -376,7 +376,7 @@ The SignedhHeader is the [header](#header) accompanied by the commit to prove it | Name | Type | Description | Validation | |--------|-------------------|-------------------|-----------------------------------------------------------------------------------| -| Header | [Header](#Header) | [Header](#header) | Header cannot be nil and must adhere to the [Header](#Header) validation criteria | +| Header | [Header](#header) | [Header](#header) | Header cannot be nil and must adhere to the [Header](#header) validation criteria | | Commit | [Commit](#commit) | [Commit](#commit) | Commit cannot be nil and must adhere to the [Commit](#commit) criteria | ## ValidatorSet diff --git a/spec/light-client/README.md b/spec/light-client/README.md index 1699a33d1..fb93188cf 100644 --- a/spec/light-client/README.md +++ b/spec/light-client/README.md @@ -19,20 +19,20 @@ verifying a minimal set of data from a network of full nodes (at least one of wh The light client is decomposed into two main components: -- [Commit Verification](#Commit-Verification) - verify signed headers and associated validator +- [Commit Verification](#commit-verification) - verify signed headers and associated validator set changes from a single full node, called primary -- [Attack Detection](#Attack-Detection) - verify commits across multiple full nodes (called secondaries) and detect conflicts (ie. the existence of a lightclient attack) +- [Attack Detection](#attack-detection) - verify commits across multiple full nodes (called secondaries) and detect conflicts (ie. the existence of a lightclient attack) In case a lightclient attack is detected, the lightclient submits evidence to a full node which is responsible for "accountability", that is, punishing attackers: -- [Accountability](#Accountability) - given evidence for an attack, compute a set of validators that are responsible for it. +- [Accountability](#accountability) - given evidence for an attack, compute a set of validators that are responsible for it. ## Commit Verification The [English specification](verification/verification_001_published.md) describes the light client commit verification problem in terms of the temporal properties -[LCV-DIST-SAFE.1](https://github.com/informalsystems/tendermint-rs/blob/master/docs/spec/lightclient/verification/verification_001_published.md#lcv-dist-safe1) and -[LCV-DIST-LIVE.1](https://github.com/informalsystems/tendermint-rs/blob/master/docs/spec/lightclient/verification/verification_001_published.md#lcv-dist-live1). +[LCV-DIST-SAFE.1](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-safe1) and +[LCV-DIST-LIVE.1](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-live1). Commit verification is assumed to operate within the Tendermint Failure Model, where +2/3 of validators are correct for some time period and validator sets can change arbitrarily at each height. @@ -136,7 +136,7 @@ termination, which can be model checked with Apalache. The `LCD_MC*.tla` files contain concrete parameters for the [TLA+ specification](detection/LCDetector_003_draft.tla), in order to run the model checker. -For instance, [LCD_MC4_4_faulty.tla](detection/MC4_4_faulty.tla) +For instance, [LCD_MC4_4_faulty.tla](./verification/MC4_4_faulty.tla) contains the following parameters for the nodes, heights, the trusting period, the clock drifts, correctness of the nodes, and the ratio of the faulty processes: diff --git a/spec/light-client/accountability/README.md b/spec/light-client/accountability/README.md index a6eda7e67..fb541dd1e 100644 --- a/spec/light-client/accountability/README.md +++ b/spec/light-client/accountability/README.md @@ -207,7 +207,9 @@ Execution: *Remark.* In this case, the more than 1/3 of faulty validators do not need to commit an equivocation (F1) as they only vote once per round in the execution. -Detecting faulty validators in the case of such an attack can be done by the fork accountability mechanism described in: . +Detecting faulty validators in the case of such an attack can be done by the fork accountability mechanism described in: + +. If a light client is attacked using this attack with 1/3 or more of voting power (and less than 2/3), the attacker cannot change the application state arbitrarily. Rather, the attacker is limited to a state a correct validator finds acceptable: In the execution above, correct validators still find the value acceptable, however, the block the light client trusts deviates from the one on the main chain. @@ -231,7 +233,7 @@ Consequences: * The validators in F1 will be detectable by the the fork accountability mechanisms. * The validators in F2 cannot be detected using this mechanism. -Only in case they signed something which conflicts with the application this can be used against them. Otherwise they do not do anything incorrect. +Only in case they signed something which conflicts with the application this can be used against them. Otherwise they do not do anything incorrect. * This case is not covered by the report as it only assumes at most 2/3 of faulty validators. **Q:** do we need to define a special kind of attack for the case where a validator sign arbitrarily state? It seems that detecting such attack requires a different mechanism that would require as an evidence a sequence of blocks that led to that state. This might be very tricky to implement. diff --git a/spec/light-client/attacks/isolate-attackers_001_draft.md b/spec/light-client/attacks/isolate-attackers_001_draft.md index e4f585f4a..eb6cdde5d 100644 --- a/spec/light-client/attacks/isolate-attackers_001_draft.md +++ b/spec/light-client/attacks/isolate-attackers_001_draft.md @@ -1,4 +1,4 @@ - + # Lightclient Attackers Isolation > Warning: This is the beginning of an unfinished draft. Don't continue reading! @@ -200,12 +200,12 @@ First observe that the first checking in `isolateMisbehavingProcesses` is `viola [[detection]] The specification of the light client attack detection mechanism. [supervisor]: -https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/supervisor/supervisor_001_draft.md +https://github.com/tendermint/tendermint/tree/main/spec/light-client/supervisor -[verification]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/verification/verification_002_draft.md +[verification]: https://github.com/tendermint/tendermint/tree/main/spec/light-client/verification [detection]: -https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md +https://github.com/tendermint/tendermint/tree/main/spec/light-client/detection [LC-DATA-EVIDENCE-link]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_003_reviewed.md#lc-data-evidence1 diff --git a/spec/light-client/attacks/isolate-attackers_002_reviewed.md b/spec/light-client/attacks/isolate-attackers_002_reviewed.md index febcc10a8..927c81bd6 100644 --- a/spec/light-client/attacks/isolate-attackers_002_reviewed.md +++ b/spec/light-client/attacks/isolate-attackers_002_reviewed.md @@ -1,3 +1,4 @@ + # Lightclient Attackers Isolation Adversarial nodes may have the incentive to lie to a lightclient about the state of a Tendermint blockchain. An attempt to do so is called attack. Light client [verification][verification] checks incoming data by checking a so-called "commit", which is a forwarded set of signed messages that is (supposedly) produced during executing Tendermint consensus. Thus, an attack boils down to creating and signing Tendermint consensus messages in deviation from the Tendermint consensus algorithm rules. @@ -65,7 +66,7 @@ Here we discuss how to solve the problem of isolating misbehaving processes. We ### Outline -We first check whether the conflicting block can indeed be verified from the common height. We then first check whether it was a lunatic attack (violating validity). If this is not the case, we check for equivocation. If this also is not the case, we start the on-chain [accountability protocol](https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit). +We first check whether the conflicting block can indeed be verified from the common height. We then first check whether it was a lunatic attack (violating validity). If this is not the case, we check for equivocation. If this also is not the case, we start the on-chain [accountability protocol](https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit). #### **[LCAI-FUNC-MAIN.1]** @@ -144,7 +145,7 @@ func violatesTMValidity(ref Header, ev Header) boolean func IsolateAmnesiaAttacker(ev LightClientAttackEvidence, bc Blockchain) []ValidatorAddress ``` -- Implementation remarks +- Implementation remarks - This triggers the [query/response protocol](https://docs.google.com/document/d/11ZhMsCj3y7zIZz4udO9l25xqb0kl7gmWqNpGVRzOeyY/edit). - Expected postcondition - returns attackers according to [LCAI-INV-Output.1]. diff --git a/spec/light-client/detection/README.md b/spec/light-client/detection/README.md index 50d8ab6fe..e70fc1391 100644 --- a/spec/light-client/detection/README.md +++ b/spec/light-client/detection/README.md @@ -14,7 +14,7 @@ This directory captures the ongoing work and discussion on fork detection both in the context of a Tendermint light node and in the context of IBC. It contains the following files -### [detection.md](./detection.md) +### [detection.md](./detection_003_reviewed.md) a draft of the light node fork detection including "proof of fork" definition, that is, the data structure to submit evidence to full diff --git a/spec/light-client/detection/detection_001_reviewed.md b/spec/light-client/detection/detection_001_reviewed.md index db8c29a14..bcd2c54bb 100644 --- a/spec/light-client/detection/detection_001_reviewed.md +++ b/spec/light-client/detection/detection_001_reviewed.md @@ -1,3 +1,4 @@ + # ***This an unfinished draft. Comments are welcome!*** **TODO:** We will need to do small adaptations to the verification diff --git a/spec/light-client/detection/detection_003_reviewed.md b/spec/light-client/detection/detection_003_reviewed.md index 13f6e9716..a300e403f 100644 --- a/spec/light-client/detection/detection_003_reviewed.md +++ b/spec/light-client/detection/detection_003_reviewed.md @@ -1,3 +1,4 @@ + # Light Client Attack Detector In this specification, we strengthen the light client to be resistant diff --git a/spec/light-client/detection/draft-functions.md b/spec/light-client/detection/draft-functions.md index 6512d733f..09480b751 100644 --- a/spec/light-client/detection/draft-functions.md +++ b/spec/light-client/detection/draft-functions.md @@ -3,7 +3,7 @@ This document collects drafts of function for generating and submitting proof of fork in the IBC context -- [IBC](#on---chain-ibc-component) +- [IBC](#on-chain-ibc-component) - [Relayer](#relayer) diff --git a/spec/light-client/detection/req-ibc-detection.md b/spec/light-client/detection/req-ibc-detection.md index 9d82a279b..84f747520 100644 --- a/spec/light-client/detection/req-ibc-detection.md +++ b/spec/light-client/detection/req-ibc-detection.md @@ -4,7 +4,7 @@ In the following, I distilled what I considered relevant from - + ### Components and their interface diff --git a/spec/light-client/supervisor/supervisor_001_draft.md b/spec/light-client/supervisor/supervisor_001_draft.md index 0a270a7f8..b3be48881 100644 --- a/spec/light-client/supervisor/supervisor_001_draft.md +++ b/spec/light-client/supervisor/supervisor_001_draft.md @@ -7,7 +7,7 @@ verification specification. So some hyperlinks have to be placed to the correct files eventually. # Light Client Sequential Supervisor - + The light client implements a read operation of a [header](TMBC-HEADER-link) from the [blockchain](TMBC-SEQ-link), by communicating with full nodes, a so-called primary and several diff --git a/spec/light-client/verification/README.md b/spec/light-client/verification/README.md index dd9e0bb21..ec02b6dcf 100644 --- a/spec/light-client/verification/README.md +++ b/spec/light-client/verification/README.md @@ -27,7 +27,7 @@ Given a known bound `TRUSTED_PERIOD`, and a block `b` with header `h` generated in `validators(b.Header.NextValidatorsHash)` is correct until time `b.Header.Time + TRUSTED_PERIOD`. *Assumption*: "correct" is defined w.r.t. realtime (some Newtonian global notion of time, i.e., wall time), -while `Header.Time` corresponds to the [BFT time](../consensus/bft-time.md). In this note, we assume that clocks of correct processes +while `Header.Time` corresponds to the [BFT time](../../consensus/bft-time.md). In this note, we assume that clocks of correct processes are synchronized (for example using NTP), and therefore there is bounded clock drift (`CLOCK_DRIFT`) between local clocks and BFT time. More precisely, for every correct light client process and every `header.Time` (i.e. BFT Time, for a header correctly generated by the Tendermint consensus), the following inequality holds: `Header.Time < now + CLOCK_DRIFT`, @@ -47,7 +47,7 @@ Mechanisms like `fork accountability` and `evidence submission` are defined in t they incentivize validators to follow the protocol specification defined in this document. If they don't, and we have 1/3 (or more) faulty validators, safety may be violated. Our approach then is to *detect* these cases (after the fact), and take suitable repair actions (automatic and social). -This is discussed in document on [Fork accountability](./accountability.md). +This is discussed in document on [Fork accountability](../../consensus/light-client/accountability.md). The term "trusted" above indicates that the correctness of the protocol depends on this assumption. It is in the responsibility of the user that runs the light client to make sure that the risk diff --git a/spec/light-client/verification/verification_001_published.md b/spec/light-client/verification/verification_001_published.md index 3777a3b8b..f446dda02 100644 --- a/spec/light-client/verification/verification_001_published.md +++ b/spec/light-client/verification/verification_001_published.md @@ -1,14 +1,14 @@ # Light Client Verification The light client implements a read operation of a -[header][TMBC-HEADER-link] from the [blockchain][TMBC-SEQ-link], by +[header][#tmbc-header1] from the [blockchain][tmbc-seq1], by communicating with full nodes. As some full nodes may be faulty, this functionality must be implemented in a fault-tolerant way. In the Tendermint blockchain, the validator set may change with every new block. The staking and unbonding mechanism induces a [security model][TMBC-FM-2THIRDS-link]: starting at time *Time* of the -[header][TMBC-HEADER-link], +[header][#tmbc-header1], more than two-thirds of the next validators of a new block are correct for the duration of *TrustedPeriod*. The fault-tolerant read operation is designed for this security model. @@ -19,7 +19,7 @@ greater than *h1*. Checking all headers of heights from *h1* to *h2* might be too costly (e.g., in terms of energy for mobile devices). This specification tries to reduce the number of intermediate blocks that need to be checked, by exploiting the guarantees provided by the -[security model][TMBC-FM-2THIRDS-link]. +[security model][tmbc-fm-2thirds1]. # Status @@ -46,10 +46,10 @@ blockchain. - [Part II](#part-ii---sequential-definition-of-the-verification-problem): Introduction of the problem addressed by the Lightclient Verification protocol. - [Verification Informal Problem - statement](#Verification-Informal-Problem-statement): For the general + statement](#verification-informal-problem-statement): For the general audience, that is, engineers who want to get an overview over what the component is doing from a bird's eye view. - - [Sequential Problem statement](#Sequential-Problem-statement): + - [Sequential Problem statement](#sequential-problem-statement): Provides a mathematical definition of the problem statement in its sequential form, that is, ignoring the distributed aspect of the implementation of the blockchain. @@ -61,17 +61,17 @@ of the problem addressed by the Lightclient Verification protocol. - [Incentives](#incentives): how faulty full nodes may benefit from misbehaving and how correct full nodes benefit from cooperating. - - [Computational Model](#Computational-Model): + - [Computational Model](#computational-model): timing and correctness assumptions. - - [Distributed Problem Statement](#Distributed-Problem-Statement): + - [Distributed Problem Statement](#distributed-problem-statement): temporal properties that formalize safety and liveness properties in the distributed setting. - [Part IV](#part-iv---light-client-verification-protocol): Specification of the protocols. - - [Definitions](#Definitions): Describes inputs, outputs, + - [Definitions](#definitions): Describes inputs, outputs, variables used by the protocol, auxiliary functions - [Core Verification](#core-verification): gives an outline of the solution, @@ -406,9 +406,9 @@ Each instance must eventually terminate. > These definitions imply that if the primary is faulty, a header may or > may not be added to *LightStore*. In any case, -> [**[LCV-DIST-SAFE.1]**](#lcv-vc-inv) must hold. -> The invariant [**[LCV-DIST-SAFE.1]**](#lcv-dist-safe) and the liveness -> requirement [**[LCV-DIST-LIVE.1]**](#lcv-dist-life) +> [**[LCV-DIST-SAFE.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-safe1) must hold. +> The invariant [**[LCV-DIST-SAFE.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-safe1) and the liveness +> requirement [**[LCV-DIST-LIVE.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-life1) > allow that verified headers are added to *LightStore* whose > height was not passed > to the verifier (e.g., intermediate headers used in bisection; see below). @@ -425,16 +425,16 @@ Each instance must eventually terminate. This specification provides a partial solution to the sequential specification. The *Verifier* solves the invariant of the sequential part -[**[LCV-DIST-SAFE.1]**](#lcv-vc-inv) => [**[LCV-SEQ-SAFE.1]**](#lcv-seq-inv) +[**[LCV-DIST-SAFE.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-safe1) => [**[LCV-SEQ-SAFE.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-seq-inv) In the case the primary is correct, and there is a recent header in *LightStore*, the verifier satisfies the liveness requirements. ⋀ *primary is correct* ⋀ always ∃ verified header in LightStore. *header.Time* > *now* - *trustingPeriod* -⋀ [**[LCV-A-Comm.1]**](#lcv-a-comm) ⋀ ( +⋀ [**[LCV-A-Comm.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-a-comm) ⋀ ( ( [**[TMBC-CorrFull.1]**][TMBC-CorrFull-link] ⋀ - [**[LCV-DIST-LIVE.1]**](#lcv-vc-live) ) - ⟹ [**[LCV-SEQ-LIVE.1]**](#lcv-seq-live) + [**[LCV-DIST-LIVE.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-live1) ) + ⟹ [**[LCV-SEQ-LIVE.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-seq-live1) ) # Part IV - Light Client Verification Protocol @@ -767,7 +767,7 @@ func VerifyToTarget(primary PeerID, lightStore LightStore, - Error conditions - if the precondition is violated - if `ValidAndVerified` or `FetchLightBlock` report an error - - if [**[LCV-INV-TP.1]**](#LCV-INV-TP.1) is violated + - if [**[LCV-INV-TP.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-inv-tp1) is violated ### Details of the Functions @@ -854,7 +854,7 @@ func Schedule(lightStore, nextHeight, targetHeight) Height *trustedStore* is implemented by the light blocks in lightStore that have the state *StateVerified*. -#### Argument for [**[LCV-DIST-SAFE.1]**](#lcv-dist-safe) +#### Argument for [**[LCV-DIST-SAFE.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-safe) - `ValidAndVerified` implements the soundness checks and the checks [**[TMBC-VAL-CONTAINS-CORR.1]**][TMBC-VAL-CONTAINS-CORR-link] and @@ -863,7 +863,7 @@ have the state *StateVerified*. - Only if `ValidAndVerified` returns with `SUCCESS`, the state of a light block is set to *StateVerified*. -#### Argument for [**[LCV-DIST-LIVE.1]**](#lcv-dist-life) +#### Argument for [**[LCV-DIST-LIVE.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-life) - If *primary* is correct, - `FetchLightBlock` will always return a light block consistent @@ -871,7 +871,7 @@ have the state *StateVerified*. - `ValidAndVerified` either verifies the header using the trusting period or falls back to sequential verification - - If [**[LCV-INV-TP.1]**](#LCV-INV-TP.1) holds, eventually every + - If [**[LCV-INV-TP.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-inv-tp1) holds, eventually every header will be verified and core verification **terminates successfully**. - successful termination depends on the age of *lightStore.LatestVerified* (for instance, initially on the age of *trustedHeader*) and the @@ -887,7 +887,7 @@ have the state *StateVerified*. ## Liveness Scenarios -The liveness argument above assumes [**[LCV-INV-TP.1]**](#LCV-INV-TP.1) +The liveness argument above assumes [**[LCV-INV-TP.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-inv-tp1) which requires that there is a header that does not expire before the target height is reached. Here we discuss scenarios to ensure this. @@ -1163,16 +1163,12 @@ func Main (primary PeerID, lightStore LightStore, targetHeight Height) [TMBC-SOUND-DISTR-POSS-COMMIT-link]: #tmbc-sound-distr-poss-commit1 [lightclient]: https://github.com/interchainio/tendermint-rs/blob/e2cb9aca0b95430fca2eac154edddc9588038982/docs/architecture/adr-002-lite-client.md -[fork-detector]: https://github.com/informalsystems/tendermint-rs/blob/master/docs/spec/lightclient/detection.md -[fullnode]: https://github.com/tendermint/tendermint/blob/main/spec/blockchain/fullnode.md +[fork-detector]: https://github.com/tendermint/tendermint/tree/main/spec/light-client/detection +[fullnode]: https://github.com/tendermint/tendermint/blob/main/spec/blockchain [ibc-rs]:https://github.com/informalsystems/ibc-rs -[FN-LuckyCase-link]: https://github.com/tendermint/tendermint/blob/main/spec/blockchain/fullnode.md#fn-luckycase - -[blockchain-validator-set]: https://github.com/tendermint/tendermint/blob/main/spec/blockchain/blockchain.md#data-structures -[fullnode-data-structures]: https://github.com/tendermint/tendermint/blob/main/spec/blockchain/fullnode.md#data-structures - -[FN-ManifestFaulty-link]: https://github.com/tendermint/tendermint/blob/main/spec/blockchain/fullnode.md#fn-manifestfaulty +[blockchain-validator-set]: https://github.com/tendermint/tendermint/blob/main/spec/core/data_structures.md#validatorset +[fullnode-data-structures]: https://github.com/tendermint/tendermint/blob/main/spec/core/data_structures.md [arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/light-client/verification/verification_002_draft.md b/spec/light-client/verification/verification_002_draft.md index 3685b05fc..5082c5870 100644 --- a/spec/light-client/verification/verification_002_draft.md +++ b/spec/light-client/verification/verification_002_draft.md @@ -63,10 +63,10 @@ blockchain. - [Part II](#part-ii---sequential-definition-of-the-verification-problem): Introduction of the problem addressed by the Lightclient Verification protocol. - [Verification Informal Problem - statement](#Verification-Informal-Problem-statement): For the general + statement](#verification-informal-problem-statement): For the general audience, that is, engineers who want to get an overview over what the component is doing from a bird's eye view. - - [Sequential Problem statement](#Sequential-Problem-statement): + - [Sequential Problem statement](#sequential-problem-statement): Provides a mathematical definition of the problem statement in its sequential form, that is, ignoring the distributed aspect of the implementation of the blockchain. @@ -78,17 +78,17 @@ of the problem addressed by the Lightclient Verification protocol. - [Incentives](#incentives): how faulty full nodes may benefit from misbehaving and how correct full nodes benefit from cooperating. - - [Computational Model](#Computational-Model): + - [Computational Model](#computational-model): timing and correctness assumptions. - - [Distributed Problem Statement](#Distributed-Problem-Statement): + - [Distributed Problem Statement](#distributed-problem-statement): temporal properties that formalize safety and liveness properties in the distributed setting. - [Part IV](#part-iv---light-client-verification-protocol): Specification of the protocols. - - [Definitions](#Definitions): Describes inputs, outputs, + - [Definitions](#definitions): Describes inputs, outputs, variables used by the protocol, auxiliary functions - [Core Verification](#core-verification): gives an outline of the solution, @@ -420,9 +420,9 @@ must eventually terminate. > These definitions imply that if the primary is faulty, a header may or > may not be added to *LightStore*. In any case, -> [**[LCV-DIST-SAFE.2]**](#lcv-dist-safe2) must hold. -> The invariant [**[LCV-DIST-SAFE.2]**](#lcv-dist-safe2) and the liveness -> requirement [**[LCV-DIST-LIVE.2]**](#lcv-dist-life) +> [**[LCV-DIST-SAFE.2]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-safe2) must hold. +> The invariant [**[LCV-DIST-SAFE.2]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-safe2) and the liveness +> requirement [**[LCV-DIST-LIVE.2]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-life) > allow that verified headers are added to *LightStore* whose > height was not passed > to the verifier (e.g., intermediate headers used in bisection; see below). @@ -439,16 +439,16 @@ must eventually terminate. This specification provides a partial solution to the sequential specification. The *Verifier* solves the invariant of the sequential part -[**[LCV-DIST-SAFE.2]**](#lcv-dist-safe2) => [**[LCV-SEQ-SAFE.1]**](#lcv-seq-safe1) +[**[LCV-DIST-SAFE.2]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-safe2) => [**[LCV-SEQ-SAFE.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-safe1) In the case the primary is correct, and *root* is a recent header in *LightStore*, the verifier satisfies the liveness requirements. ⋀ *primary is correct* ⋀ *root.header.Time* > *now* - *trustingPeriod* -⋀ [**[LCV-A-Comm.1]**](#lcv-a-comm) ⋀ ( +⋀ [**[LCV-A-Comm.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-a-comm) ⋀ ( ( [**[TMBC-CorrFull.1]**][TMBC-CorrFull-link] ⋀ - [**[LCV-DIST-LIVE.2]**](#lcv-dist-live2) ) - ⟹ [**[LCV-SEQ-LIVE.1]**](#lcv-seq-live1) + [**[LCV-DIST-LIVE.2]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-live2) ) + ⟹ [**[LCV-SEQ-LIVE.1]**](https://github.com/tendermint/tendermint/blob/main/spec/light-client/verification/verification_001_published.md#lcv-dist-live1) ) # Part IV - Light Client Verification Protocol @@ -612,7 +612,7 @@ func (ls LightStore) TraceTo(lightBlock LightBlock) (LightBlock, LightStore) - returns a **trusted** lightblock `root` from the lightstore with a height less than `lightBlock` - returns a lightstore that contains lightblocks that constitute a - [verification trace](TODOlinkToDetectorSpecOnceThere) from + [verification trace](https://github.com/tendermint/tendermint/tree/main/spec/light-client/detection) from `root` to `lightBlock` (including `lightBlock`) ### Inputs @@ -823,7 +823,7 @@ func VerifyToTarget(primary PeerID, root LightBlock, - Error conditions - if the precondition is violated - if `ValidAndVerified` or `FetchLightBlock` report an error - - if [**[LCV-INV-TP.1]**](#LCV-INV-TP.1) is violated + - if [**[LCV-INV-TP.1]**](#lcv-inv-tp1) is violated ### Details of the Functions @@ -927,14 +927,14 @@ For [IBC][ibc-rs] there are two additional challenges: 1. it might be that some "older" header is needed, that is, *targetHeight < lightStore.LatestVerified()*. The -[supervisor](../supervisor/supervisor.md) checks whether it is in this +[supervisor](../supervisor/supervisor_002_draft.md) checks whether it is in this case by calling `LatestPrevious` and `MinVerified` and if so it calls `Backwards`. All these functions are specified below. 2. In order to submit proof of a light client attack, a relayer may need to submit a verification trace. This it is important to compute such a trace efficiently. That it can be done is based on - the invariant [[LCV-INV-LS-ROOT.2]](#LCV-INV-LS-ROOT2) that needs + the invariant [[LCV-INV-LS-ROOT.2]](#lcv-inv-ls-root2) that needs to be maintained by the light client. In particular `VerifyToTarget` and `Backwards` need to take care of setting `verification-root`. @@ -1048,14 +1048,12 @@ func Backwards (primary PeerID, root LightBlock, targetHeight Height) [TMBC-SOUND-DISTR-POSS-COMMIT-link]: #tmbc-sound-distr-poss-commit1 [lightclient]: https://github.com/interchainio/tendermint-rs/blob/e2cb9aca0b95430fca2eac154edddc9588038982/docs/architecture/adr-002-lite-client.md -[attack-detector]: https://github.com/tendermint/spec/blob/master/rust-spec/lightclient/detection/detection_001_reviewed.md -[fullnode]: https://github.com/tendermint/tendermint/blob/main/spec/blockchain/fullnode.md +[attack-detector]: https://github.com/tendermint/tendermint/blob/main/spec/light-client/detection/detection_001_reviewed.md +[fullnode]: https://github.com/tendermint/tendermint/tree/main/spec/core [ibc-rs]:https://github.com/informalsystems/ibc-rs [blockchain-validator-set]: https://github.com/tendermint/tendermint/blob/main/spec/blockchain/blockchain.md#data-structures -[fullnode-data-structures]: https://github.com/tendermint/tendermint/blob/main/spec/blockchain/fullnode.md#data-structures - -[FN-ManifestFaulty-link]: https://github.com/tendermint/tendermint/blob/main/spec/blockchain/fullnode.md#fn-manifestfaulty +[fullnode-data-structures]: https://github.com/tendermint/tendermint/blob/main/spec/core/data_structures.md [arXiv]: https://arxiv.org/abs/1807.04938 diff --git a/spec/p2p/messages/consensus.md b/spec/p2p/messages/consensus.md index 57422c7cf..c858db765 100644 --- a/spec/p2p/messages/consensus.md +++ b/spec/p2p/messages/consensus.md @@ -144,6 +144,6 @@ Message is a [`oneof` protobuf type](https://developers.google.com/protocol-buff | proposal_pol | [ProposalPOL](#proposalpol) | | 4 | | block_part | [BlockPart](#blockpart) | | 5 | | vote | [Vote](#vote) | | 6 | -| received_vote | [ReceivedVote](#ReceivedVote) | | 7 | +| received_vote | [ReceivedVote](#receivedvote) | | 7 | | vote_set_maj23 | [VoteSetMaj23](#votesetmaj23) | | 8 | | vote_set_bits | [VoteSetBits](#votesetbits) | | 9 | diff --git a/spec/p2p/messages/pex.md b/spec/p2p/messages/pex.md index e12a076e5..24215fd01 100644 --- a/spec/p2p/messages/pex.md +++ b/spec/p2p/messages/pex.md @@ -29,7 +29,7 @@ PexResponse is an list of net addresses provided to a peer to dial. | Name | Type | Description | Field Number | |-------|------------------------------------|------------------------------------------|--------------| -| addresses | repeated [PexAddress](#PexAddress) | List of peer addresses available to dial | 1 | +| addresses | repeated [PexAddress](#pexaddress) | List of peer addresses available to dial | 1 | ### PexAddress @@ -54,7 +54,7 @@ PexResponse is an list of net addresses provided to a peer to dial. | Name | Type | Description | Field Number | |-------|------------------------------------|------------------------------------------|--------------| -| addresses | repeated [PexAddressV2](#PexAddressV2) | List of peer addresses available to dial | 1 | +| addresses | repeated [PexAddressV2](#pexresponsev2) | List of peer addresses available to dial | 1 | ### PexAddressV2 @@ -70,7 +70,7 @@ Message is a [`oneof` protobuf type](https://developers.google.com/protocol-buff | Name | Type | Description | Field Number | |--------------|---------------------------|------------------------------------------------------|--------------| -| pex_request | [PexRequest](#PexRequest) | Empty request asking for a list of addresses to dial | 1 | -| pex_response | [PexResponse](#PexResponse) | List of addresses to dial | 2 | -| pex_request_v2 | [PexRequestV2](#PexRequestV2) | Empty request asking for a list of addresses to dial | 3 | -| pex_response_v2 | [PexRespinseV2](#PexResponseV2) | List of addresses to dial | 4 | +| pex_request | [PexRequest](#pexrequest) | Empty request asking for a list of addresses to dial | 1 | +| pex_response | [PexResponse](#pexresponse)| List of addresses to dial | 2 | +| pex_request_v2| [PexRequestV2](#pexrequestv2)| Empty request asking for a list of addresses to dial| 3 | +| pex_response_v2| [PexRespinseV2](#pexresponsev2)| List of addresses to dial | 4 | diff --git a/spec/p2p/messages/state-sync.md b/spec/p2p/messages/state-sync.md index 283b0c490..b2e9e2b28 100644 --- a/spec/p2p/messages/state-sync.md +++ b/spec/p2p/messages/state-sync.md @@ -91,10 +91,9 @@ if necessary. The light block at the height of the snapshot will be used to veri |---------------|---------------------------------------------------------|--------------------------------------|--------------| | light_block | [LightBlock](../../core/data_structures.md#lightblock) | Light block at the height requested | 1 | -State sync will use [light client verification](../../light-client/verification/README.md) to verify +State sync will use [light client verification](../../../spec/light-client/verification/README.md) to verify the light blocks. - If no state sync is in progress (i.e. during normal operation), any unsolicited response messages are discarded. diff --git a/tools/tm-signer-harness/README.md b/tools/tm-signer-harness/README.md index d0d1a235d..ec062c525 100644 --- a/tools/tm-signer-harness/README.md +++ b/tools/tm-signer-harness/README.md @@ -1,5 +1,4 @@ # tm-signer-harness -See the [`tm-signer-harness` -documentation](https://docs.tendermint.com/main/tools/remote-signer-validation.html) +See the [`tm-signer-harness`documentation](https://github.com/tendermint/tendermint/blob/main/docs/tools/remote-signer-validation.md) for more details.