Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CometBFT specification #23

Open
6 of 40 tasks
Tracked by #42
lasarojc opened this issue Dec 23, 2022 · 0 comments
Open
6 of 40 tasks
Tracked by #42

CometBFT specification #23

lasarojc opened this issue Dec 23, 2022 · 0 comments
Labels
major-priority A major, long-running priority for the team P:tech-debt Priority: Technical debt that needs to be paid off to enable us to move faster, reliably spec Specification-related tracking A complex issue broken down into sub-problems

Comments

@lasarojc
Copy link
Contributor

lasarojc commented Dec 23, 2022

Was tendermint/tendermint#9321

CometBFT consists of many protocols and interfaces that need to be very well understood. Currently, not all protocols are clearly specified. This issue is designed to track the current state of the specification of CometBFT protocols and provide a clear overview of the remaining work in that respect.

Definition of done

This issue will be considered done when each sub-issue (corresponding to individual protocols and interfaces) is completed.
For a sub-issue to be considered completed it needs to provide the following:

  • (1) What properties does the protocol provide (externally visible variables, events, together with safety, liveness, "best effort" properties)
  • (2) What does the protocol expect from other protocols: shared state, timing, transition properties (when the node transitions from blocksync to consensus it should be at most x heights behind the current height of the chain)
  • (3) How is the protocol operating (protocol description)
  • (4) Observations/shortcomings/potential issues (I guess when we do this work, we will find problems that eventually should be addressed. We might note them down here together with the version of the software they apply to)

Satisfaction criteria

For 1) and 2): The protocol team and the engineering team are confident that we have a complete list, and we understand the properties well enough to be sure that they can be formalized.

For 3) protocol team and engineering team agree that the description and the code are well aligned, and captures worst case scenarios / corner cases

For 4) we should provide some evaluation of the current state. Written constructively so that we can infer future steps. (perhaps describing scenarios where the implemented protocol behaves differently from what people think it might do).

CometBFT protocols

Here we provide a list of protocols that exist in CometBFT along with the existing documentation and its status.

Consensus

  • Algorithm in arXiv: OK (except separation of proposal and block)
  • PBTS extension
  • Port from retired 0.36 to main
  • Detection of equivocation: missing
  • Formal specification of the Gossip layer #15
  • Interface between consensus and other CometBFT modules.
  • Develop onboarding material explaining/answering some crucial parts of the Tendermint consensus algorithm (e.g., innovative Tendermint termination mechanism)
  • Specification of the WAL and the replay mechanism

Accountability

  • Detection of misbehavior - Amnesia: missing
  • Light client detection: OK (perhaps re-organize lightclient)
  • Evidence handling: missing
  • Evidence gossiping: missing

Mempool

Peer exchange (PEX) and p2p :

Block sync:

State sync

Light client

  • Documentation adequate and exists here.

CometBFT interfaces

ABCI

  • ABCI is well specified and understood. Ongoing issue.
  • Tutorials
    • Old ABCI version
    • ABCI ++

Peer management

  • API + network properties are currently not clearly specified. Under this we can cover as well any related information on cryptography, encryption, authentication

Client facing

  • Mempool (missing for non SDK users)
  • RPC (missing for non SDK users)
  • config.toml revisit parameters and find out why they are not consensus params
    • Does it depend on the node? (operator knows best)
    • Does it need to be protected by agreement?
    • Does it have an "agreed" component and an "operator-based" component?

Private key storage and use

  • Spec of API? Secure?

Persistence, Data Availability

  • Database
  • Data availability implications of pruning, statesync, retain_height. What are the network-wide properties that we need?

Core data types

@thanethomson thanethomson added the tracking A complex issue broken down into sub-problems label Jan 12, 2023
@josef-widder josef-widder changed the title Tendermint specification CometBFT specification Jan 27, 2023
@josef-widder josef-widder added the spec Specification-related label Jan 27, 2023
@thanethomson thanethomson added the P:tech-debt Priority: Technical debt that needs to be paid off to enable us to move faster, reliably label Jun 20, 2023
Raneet10 pushed a commit to 0xPolygon/cometbft that referenced this issue Nov 20, 2023
…ersion

Update bor version and include vitwit changes from March
@adizere adizere added the major-priority A major, long-running priority for the team label Jan 12, 2024
cometcrafter pushed a commit to graphprotocol/cometbft that referenced this issue May 1, 2024
…v0.37.4/pr-22

perf: TxSearch pagination (backport cometbft#22)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
major-priority A major, long-running priority for the team P:tech-debt Priority: Technical debt that needs to be paid off to enable us to move faster, reliably spec Specification-related tracking A complex issue broken down into sub-problems
Projects
Status: Todo
Status: Todo
Development

No branches or pull requests

4 participants