github.com/badrootd/celestia-core@v0.0.0-20240305091328-aa4207a4b25d/docs/celestia-architecture/README.md (about)

     1  ---
     2  order: 1
     3  parent:
     4    order: false
     5  ---
     6  
     7  # Tendermint and Celestia
     8  
     9  celestia-core is not meant to be used as a general purpose framework.
    10  Instead, its main purpose is to provide certain components (mainly consensus but also a p2p layer for Tx gossiping) for the Celestia main chain.
    11  Hence, we do not provide any extensive documentation here.
    12  
    13  Instead of keeping a copy of the Tendermint documentation, we refer to the existing extensive and maintained documentation and specification:
    14  
    15  - <https://docs.tendermint.com/>
    16  - <https://github.com/cometbft/cometbft/tree/master/docs/>
    17  - <https://github.com/tendermint/spec>
    18  
    19  Reading these will give you a lot of background and context on Tendermint which will also help you understand how celestia-core and [celestia-app](https://github.com/celestiaorg/celestia-app) interact with each other.
    20  
    21  ## Celestia
    22  
    23  As mentioned above, celestia-core aims to be more focused on the Celestia use-case than vanilla Tendermint.
    24  Moving forward we might provide a clear overview on the changes we incorporated.
    25  For now, we refer to the Celestia specific ADRs in this repository as well as to the Celestia specification:
    26  
    27  - [celestia-specs](https://github.com/celestiaorg/celestia-specs)
    28  
    29  ## Architecture Decision Records (ADR)
    30  
    31  This is a location to record all high-level architecture decisions in this repository.
    32  
    33  You can read more about the ADR concept in this [blog post](https://product.reverb.com/documenting-architecture-decisions-the-reverb-way-a3563bb24bd0#.78xhdix6t).
    34  
    35  An ADR should provide:
    36  
    37  - Context on the relevant goals and the current state
    38  - Proposed changes to achieve the goals
    39  - Summary of pros and cons
    40  - References
    41  - Changelog
    42  
    43  Note the distinction between an ADR and a spec. The ADR provides the context, intuition, reasoning, and
    44  justification for a change in architecture, or for the architecture of something
    45  new. The spec is much more compressed and streamlined summary of everything as
    46  it stands today.
    47  
    48  If recorded decisions turned out to be lacking, convene a discussion, record the new decisions here, and then modify the code to match.
    49  
    50  Note the context/background should be written in the present tense.
    51  
    52  To start a new ADR, you can use this template: [adr-template.md](./adr-template.md)
    53  
    54  ### Table of Contents
    55  
    56  - [ADR 001: Erasure Coding Block Propagation](./adr-001-block-propagation.md)
    57  - [ADR 002: Sampling erasure coded Block chunks](./adr-002-ipld-da-sampling.md)
    58  - [ADR 003: Retrieving Application messages](./adr-003-application-data-retrieval.md)
    59  - [ADR 004: Data Availability Sampling Light Client](./adr-004-mvp-light-client.md)
    60  - [ADR 005: Decouple BlockID and PartSetHeader](./adr-005-decouple-blockid-and-partsetheader.md)
    61  - [ADR 006: Row Propagation](./adr-006-row-propagation.md)
    62  - [ADR 007: Minimal Changes to Tendermint](./adr-007-minimal-changes-to-tendermint.md)
    63  - [ADR 008: Updating to Tendermint v0.35.x](./adr-008-updating-to-tendermint-v0.35.x.md)
    64  - [ADR 009: CAT pool](./adr-009-cat-pool.md)