mirror of
https://github.com/tendermint/tendermint.git
synced 2026-04-26 10:41:11 +00:00
docs: adr cleanup (#6489)
## Description Cleanup ADR readme and update changelogs and status of ADRs
This commit is contained in:
@@ -29,71 +29,71 @@ Note the context/background should be written in the present tense.
|
||||
|
||||
## Table of Contents
|
||||
|
||||
### Accepted
|
||||
### Implemented
|
||||
|
||||
- [ADR-001: Logging](./adr-001-logging.md)
|
||||
- [ADR-002: Event-Subscription](./adr-002-event-subscription.md)
|
||||
- [ADR-003: ABCI-APP-RPC](./adr-003-abci-app-rpc.md)
|
||||
- [ADR-004: Historical-Validators](./adr-004-historical-validators.md)
|
||||
- [ADR-006: Trust-Metric](./adr-006-trust-metric.md)
|
||||
- [ADR-005: Consensus-Params](./adr-005-consensus-params.md)
|
||||
- [ADR-008: Priv-Validator](./adr-008-priv-validator.md)
|
||||
- [ADR-009: ABCI-Design](./adr-009-ABCI-design.md)
|
||||
- [ADR-010: Crypto-Changes](./adr-010-crypto-changes.md)
|
||||
- [ADR-011: Monitoring](./adr-011-monitoring.md)
|
||||
- [ADR-014: Secp-Malleability](./adr-014-secp-malleability.md)
|
||||
- [ADR-015: Crypto-Encoding](./adr-015-crypto-encoding.md)
|
||||
- [ADR-016: Protocol-Versions](./adr-016-protocol-versions.md)
|
||||
- [ADR-017: Chain-Versions](./adr-017-chain-versions.md)
|
||||
- [ADR-018: ABCI-Validators](./adr-018-ABCI-Validators.md)
|
||||
- [ADR-019: Multisigs](./adr-019-multisigs.md)
|
||||
- [ADR-020: Block-Size](./adr-020-block-size.md)
|
||||
- [ADR-021: ABCI-Events](./adr-021-abci-events.md)
|
||||
- [ADR-025: Commit](./adr-025-commit.md)
|
||||
- [ADR-026: General-Merkle-Proof](./adr-026-general-merkle-proof.md)
|
||||
- [ADR-033: Pubsub](./adr-033-pubsub.md)
|
||||
- [ADR-034: Priv-Validator-File-Structure](./adr-034-priv-validator-file-structure.md)
|
||||
- [ADR-039: Peer-Behaviour](./adr-039-peer-behaviour.md)
|
||||
- [ADR-043: Blockchain-RiRi-Org](./adr-043-blockchain-riri-org.md)
|
||||
- [ADR-044: Lite-Client-With-Weak-Subjectivity](./adr-044-lite-client-with-weak-subjectivity.md)
|
||||
- [ADR-046: Light-Client-Implementation](./adr-046-light-client-implementation.md)
|
||||
- [ADR-047: Handling-Evidence-From-Light-Client](./adr-047-handling-evidence-from-light-client.md)
|
||||
- [ADR-051: Double-Signing-Risk-Reduction](./adr-051-double-signing-risk-reduction.md)
|
||||
- [ADR-052: Tendermint-Mode](./adr-052-tendermint-mode.md)
|
||||
- [ADR-053: State-Sync-Prototype](./adr-053-state-sync-prototype.md)
|
||||
- [ADR-054: Crypto-Encoding-2](./adr-054-crypto-encoding-2.md)
|
||||
- [ADR-055: Protobuf-Design](./adr-055-protobuf-design.md)
|
||||
- [ADR-056: Light-Client-Amnesia-Attacks](./adr-056-light-client-amnesia-attacks)
|
||||
- [ADR-059: Evidence-Composition-and-Lifecycle](./adr-059-evidence-composition-and-lifecycle.md)
|
||||
- [ADR-062: P2P-Architecture](./adr-062-p2p-architecture.md)
|
||||
- [ADR-063: Privval-gRPC](./adr-063-privval-grpc.md)
|
||||
- [ADR-066-E2E-Testing](./adr-066-e2e-testing.md)
|
||||
### Accepted
|
||||
|
||||
- [ADR-006: Trust-Metric](./adr-006-trust-metric.md)
|
||||
- [ADR-024: Sign-Bytes](./adr-024-sign-bytes.md)
|
||||
- [ADR-035: Documentation](./adr-035-documentation.md)
|
||||
- [ADR-039: Peer-Behaviour](./adr-039-peer-behaviour.md)
|
||||
- [ADR-060: Go-API-Stability](./adr-060-go-api-stability.md)
|
||||
- [ADR-061: P2P-Refactor-Scope](./adr-061-p2p-refactor-scope.md)
|
||||
- [ADR-062: P2P-Architecture](./adr-062-p2p-architecture.md)
|
||||
- [ADR-065: Custom Event Indexing](./adr-065-custom-event-indexing.md)
|
||||
- [ADR-066-E2E-Testing](./adr-066-e2e-testing.md)
|
||||
- [ADR-068: Reverse-Sync](./adr-068-reverse-sync.md)
|
||||
- [ADR-067: Mempool Refactor](./adr-067-mempool-refactor.md)
|
||||
|
||||
### Rejected
|
||||
|
||||
- [ADR-023: ABCI-Propose-tx](./adr-023-ABCI-propose-tx.md)
|
||||
- [ADR-029: Check-Tx-Consensus](./adr-029-check-tx-consensus.md)
|
||||
- [ADR-058: Event-Hashing](./adr-058-event-hashing.md)
|
||||
|
||||
|
||||
### Proposed
|
||||
|
||||
- [ADR-001: Logging](./adr-001-logging.md)
|
||||
- [ADR-002: Event-Subscription](./adr-002-event-subscription.md)
|
||||
- [ADR-005: Consensus-Params](./adr-005-consensus-params.md)
|
||||
- [ADR-007: Trust-Metric-Usage](./adr-007-trust-metric-usage.md)
|
||||
- [ADR-008: Priv-Validator](./adr-008-priv-validator.md)
|
||||
- [ADR-010: Crypto-Changes](./adr-010-crypto-changes.md)
|
||||
- [ADR-011: Monitoring](./adr-011-monitoring.md)
|
||||
- [ADR-012: Peer-Transport](./adr-012-peer-transport.md)
|
||||
- [ADR-013: Symmetric-Crypto](./adr-013-symmetric-crypto.md)
|
||||
- [ADR-016: Protocol-Versions](./adr-016-protocol-versions.md)
|
||||
- [ADR-017: Chain-Versions](./adr-017-chain-versions.md)
|
||||
- [ADR-018: ABCI-Validators](./adr-018-ABCI-Validators.md)
|
||||
- [ADR-019: Multisigs](./adr-019-multisigs.md)
|
||||
- [ADR-021: ABCI-Events](./adr-021-abci-events.md)
|
||||
- [ADR-022: ABCI-Errors](./adr-022-abci-errors.md)
|
||||
- [ADR-023: ABCI-Propose-tx](./adr-023-ABCI-propose-tx.md)
|
||||
- [ADR-024: Sign-Bytes](./adr-024-sign-bytes.md)
|
||||
- [ADR-026: General-Merkle-Proof](./adr-026-general-merkle-proof.md)
|
||||
- [ADR-028: libp2p](./adr-028-libp2p.md)
|
||||
- [ADR-030: Consensus-Refactor](./adr-030-consensus-refactor.md)
|
||||
- [ADR-030: Changelog-structure](./adr-031-changelog.md)
|
||||
- [ADR-033: Pubsub](./adr-033-pubsub.md)
|
||||
- [ADR-035: Documentation](./adr-035-documentation.md)
|
||||
- [ADR-037: Deliver-Block](./adr-037-deliver-block.md)
|
||||
- [ADR-038: Non-Zero-Start-Height](./adr-038-non-zero-start-height.md)
|
||||
- [ADR-041: Proposer-Selection-via-ABCI](./adr-041-proposer-selection-via-abci.md)
|
||||
- [ADR-043: Blockchain-RiRi-Org](./adr-043-blockchain-riri-org.md)
|
||||
- [ADR-045: ABCI-Evidence](./adr-045-abci-evidence.md)
|
||||
- [ADR-051: Double-Signing-Risk-Reduction](./adr-051-double-signing-risk-reduction.md)
|
||||
- [ADR-052: Tendermint-Mode](./adr-052-tendermint-mode.md)
|
||||
- [ADR-054: Crypto-Encoding-2](./adr-054-crypto-encoding-2.md)
|
||||
- [ADR-057: RPC](./adr-057-RPC.md)
|
||||
- [ADR-063: Privval-gRPC](./adr-063-privval-grpc.md)
|
||||
|
||||
@@ -189,7 +189,7 @@ c2.SetLogger(log.With(logger, "instance", 2))
|
||||
|
||||
## Status
|
||||
|
||||
proposed
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -71,7 +71,7 @@ For historic queries we will need a indexing storage (Postgres, SQLite, ...).
|
||||
|
||||
## Status
|
||||
|
||||
proposed
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ We dont expose an RPC server on any of our ABCI-apps.
|
||||
|
||||
## Status
|
||||
|
||||
accepted
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ and likely less efficient.
|
||||
|
||||
## Status
|
||||
|
||||
Accepted.
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -66,7 +66,7 @@ Tendermint should have hard-coded upper limits as sanity checks.
|
||||
|
||||
## Status
|
||||
|
||||
Proposed.
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -235,7 +235,7 @@ identically in ABCI and in Tendermint Core.
|
||||
|
||||
## Status
|
||||
|
||||
Accepted.
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -60,6 +60,8 @@ Make the following changes:
|
||||
|
||||
## Status
|
||||
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
@@ -99,7 +99,7 @@ will need to write interfaces ourselves.
|
||||
|
||||
## Status
|
||||
|
||||
Proposed.
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -76,7 +76,7 @@ which is just informational.
|
||||
|
||||
## Status
|
||||
|
||||
Proposal.
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -8,6 +8,8 @@
|
||||
|
||||
11-07-2018: Initial Draft
|
||||
|
||||
5-26-2021: Multisigs were moved into the Cosmos-sdk
|
||||
|
||||
## Context
|
||||
|
||||
Multisignatures, or technically _Accountable Subgroup Multisignatures_ (ASM),
|
||||
@@ -141,7 +143,7 @@ Aggregation of pubkeys / sigs in Schnorr sigs / BLS sigs is not backwards compat
|
||||
|
||||
## Status
|
||||
|
||||
Proposed.
|
||||
Implemented (moved to cosmos-sdk)
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -88,7 +88,7 @@ MaxXXX stayed the same.
|
||||
|
||||
## Status
|
||||
|
||||
Accepted.
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ TODO: describe impact on indexing and querying
|
||||
|
||||
## Status
|
||||
|
||||
Proposed
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# ADR 023: ABCI Codespaces
|
||||
# ADR 022: ABCI Errors
|
||||
|
||||
## Changelog
|
||||
|
||||
@@ -61,4 +61,3 @@ efficiently by lite clients) is left for a separate ADR.
|
||||
- Some redundancy with `code` field
|
||||
- May encourage more error/code type info to move to the `codespace` string, which
|
||||
could impact lite clients.
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# ADR 012: ABCI `ProposeTx` Method
|
||||
# ADR 023: ABCI `ProposeTx` Method
|
||||
|
||||
## Changelog
|
||||
|
||||
|
||||
@@ -208,7 +208,7 @@ func (tp *T) SignBytes() []byte {
|
||||
|
||||
## Status
|
||||
|
||||
DRAFT
|
||||
Partially Accepted
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -127,7 +127,7 @@ basis.
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -33,6 +33,8 @@ Since a proof can treat various data type, `Run()` takes `[][]byte` as the argum
|
||||
|
||||
## Status
|
||||
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive
|
||||
|
||||
@@ -1,38 +0,0 @@
|
||||
# ADR 028: : LibP2P Integration
|
||||
|
||||
## Changelog
|
||||
|
||||
- {date}: {changelog}
|
||||
|
||||
## Context
|
||||
|
||||
> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution.
|
||||
|
||||
## Decision
|
||||
|
||||
> This section explains all of the details of the proposed solution, including implementation details.
|
||||
> It should also describe affects / corollary items that may need to be changed as a part of this.
|
||||
> If the proposed change will be large, please also indicate a way to do the change to maximize ease of review.
|
||||
> (e.g. the optimal split of things to do between separate PR's)
|
||||
|
||||
## Status
|
||||
|
||||
> A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement.
|
||||
|
||||
{Deprecated|Proposed|Accepted|Declined}
|
||||
|
||||
## Consequences
|
||||
|
||||
> This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones.
|
||||
|
||||
### Positive
|
||||
|
||||
### Negative
|
||||
|
||||
### Neutral
|
||||
|
||||
## References
|
||||
|
||||
> Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here!
|
||||
|
||||
- {reference link}
|
||||
@@ -1,38 +0,0 @@
|
||||
# ADR 031: Changelog Structure
|
||||
|
||||
## Changelog
|
||||
|
||||
- {date}: {changelog}
|
||||
|
||||
## Context
|
||||
|
||||
> This section contains all the context one needs to understand the current state, and why there is a problem. It should be as succinct as possible and introduce the high level idea behind the solution.
|
||||
|
||||
## Decision
|
||||
|
||||
> This section explains all of the details of the proposed solution, including implementation details.
|
||||
> It should also describe affects / corollary items that may need to be changed as a part of this.
|
||||
> If the proposed change will be large, please also indicate a way to do the change to maximize ease of review.
|
||||
> (e.g. the optimal split of things to do between separate PR's)
|
||||
|
||||
## Status
|
||||
|
||||
> A decision may be "proposed" if it hasn't been agreed upon yet, or "accepted" once it is agreed upon. If a later ADR changes or reverses a decision, it may be marked as "deprecated" or "superseded" with a reference to its replacement.
|
||||
|
||||
{Deprecated|Proposed|Accepted|Declined}
|
||||
|
||||
## Consequences
|
||||
|
||||
> This section describes the consequences, after applying the decision. All consequences should be summarized here, not just the "positive" ones.
|
||||
|
||||
### Positive
|
||||
|
||||
### Negative
|
||||
|
||||
### Neutral
|
||||
|
||||
## References
|
||||
|
||||
> Are there any relevant PR comments, issues that led up to this, or articles referenced for why we made the given design choice? If so link them here!
|
||||
|
||||
- {reference link}
|
||||
@@ -224,7 +224,7 @@ This can be made automatically. Say we set queue size to 1000 and, when it's >=
|
||||
|
||||
## Status
|
||||
|
||||
In review
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -57,7 +57,7 @@ What we need to do next is changing the methods of `FilePV`.
|
||||
|
||||
## Status
|
||||
|
||||
Accepted and implemented in [#2870](https://github.com/tendermint/tendermint/pull/2870).
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -377,13 +377,7 @@ type Peer struct {
|
||||
|
||||
## Status
|
||||
|
||||
This design is under active development. The Implementation has been
|
||||
staged in the following PRs:
|
||||
|
||||
- [Routine](https://github.com/tendermint/tendermint/pull/3878)
|
||||
- [Processor](https://github.com/tendermint/tendermint/pull/4012)
|
||||
- [Scheduler](https://github.com/tendermint/tendermint/pull/4043)
|
||||
- [Reactor](https://github.com/tendermint/tendermint/pull/4067)
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -123,7 +123,7 @@ Check out the formal specification
|
||||
|
||||
## Status
|
||||
|
||||
Accepted.
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -150,7 +150,7 @@ Specification of the non-recursive bisection can be found
|
||||
|
||||
## Status
|
||||
|
||||
Accepted.
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -189,7 +189,7 @@ it for itself before gossiping it to peers and trying to commit it on chain. Thi
|
||||
|
||||
## Status
|
||||
|
||||
Implemented.
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -33,7 +33,7 @@ We would like to suggest a double signing risk reduction method.
|
||||
|
||||
## Status
|
||||
|
||||
Proposed
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -63,7 +63,7 @@ We would like to suggest a simple Tendermint mode abstraction. These modes will
|
||||
|
||||
## Status
|
||||
|
||||
Proposed
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -247,7 +247,7 @@ Snapshots must also be garbage collected after some configurable time, e.g. by k
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
Implemented
|
||||
|
||||
## References
|
||||
|
||||
|
||||
@@ -46,7 +46,7 @@ This work will be broken out into a few PRs, this work will be merged into a pro
|
||||
|
||||
## Status
|
||||
|
||||
Proposed
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -40,7 +40,7 @@ By going with this design we will enable future changes to types and allow for a
|
||||
|
||||
## Status
|
||||
|
||||
Completed
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -91,7 +91,8 @@ The upgrade of [tmkms](https://github.com/iqlusioninc/tmkms) will be coordinated
|
||||
|
||||
## Status
|
||||
|
||||
Proposed
|
||||
|
||||
Implemented
|
||||
|
||||
### Positive
|
||||
|
||||
|
||||
@@ -69,7 +69,7 @@ Starting out, only ed25519 will support batch verification.
|
||||
|
||||
## Status
|
||||
|
||||
Proposed
|
||||
Implemented
|
||||
|
||||
### Positive
|
||||
|
||||
|
||||
@@ -109,7 +109,7 @@ If possible, the existing `testnet` command should be extended to set up the net
|
||||
|
||||
## Status
|
||||
|
||||
Accepted
|
||||
Implemented
|
||||
|
||||
## Consequences
|
||||
|
||||
|
||||
@@ -11,7 +11,7 @@
|
||||
> "implemented". If a later ADR changes or reverses a decision, it may be marked
|
||||
> as "deprecated" or "superseded" with a reference to its replacement.
|
||||
|
||||
{Deprecated|Proposed|Accepted|Declined}
|
||||
{Deprecated|Declined|Accepted|Implemented}
|
||||
|
||||
## Context
|
||||
|
||||
|
||||
Reference in New Issue
Block a user