|
| 1 | +# Ledger: Blocks |
| 2 | + |
| 3 | +Blocks are a fundamental component of all blockchains and represent one of two |
| 4 | +basic units of exchange between nodes (the other being [transactions](./transactions.md)). |
| 5 | + |
| 6 | +A block can itself be broken down into multiple parts: |
| 7 | + |
| 8 | +```mermaid |
| 9 | +
|
| 10 | +block-beta |
| 11 | +block |
| 12 | + columns 1 |
| 13 | + H["Header"] |
| 14 | + block |
| 15 | + columns 2 |
| 16 | + BB["Transactions"] |
| 17 | + BW["Witnesses"] |
| 18 | + BA["Auxiliary Data"] |
| 19 | + BV["Transaction Validity"] |
| 20 | + end |
| 21 | +end |
| 22 | +
|
| 23 | +``` |
| 24 | + |
| 25 | +See also the [Block CDDL](https://github.com/IntersectMBO/cardano-ledger/blob/master/eras/conway/impl/cddl-files/conway.cddl#L8) |
| 26 | +for the Conway era (the latest era at the time of writing). |
| 27 | + |
| 28 | +## The header/body split |
| 29 | + |
| 30 | +The most important distinction in the above diagram is that there is a split |
| 31 | +between the header of the block and the body. The general guiding principle |
| 32 | +behind this is the following: |
| 33 | + |
| 34 | +- The *header* contains the parts of the block relevant to the consensus |
| 35 | + protocol. |
| 36 | +- The *body* contains the parts of the block relevant to the ledger. |
| 37 | + |
| 38 | +The full details and implications of this split are covered in |
| 39 | +[Implications of the Header/Body Split](../constraints/header-body-split.md). |
| 40 | +For now, we can assume that the contents of the header are not important for |
| 41 | +the ledger processing. |
| 42 | + |
| 43 | +The block body itself is split into four parts. This division is not conceptually |
| 44 | +necessary but is helpful for efficient processing: |
| 45 | + |
| 46 | +1. The 'Transactions' section contains the bodies of all transactions. This is |
| 47 | + the only part of the block body necessary to compute the resulting ledger |
| 48 | + state (see [The ledger state transition](../state-transition.md)) - that is, |
| 49 | + provided that the block is _valid_ with regard to some _ledger state_, the |
| 50 | + resulting new state can be computed using only the data in this section. |
| 51 | + |
| 52 | +2. The 'Witnesses' section contains the cryptographic witnessing necessary to |
| 53 | + evaluate the _validity_ of the transactions contained in the block. For |
| 54 | + more details on _validity_, please see the [Validity](../state-transition/validity.md) |
| 55 | + section. |
| 56 | + |
| 57 | +3. The 'AuxData' section contains "auxiliary data" which is not processed |
| 58 | + as part of the ledger state. It instead contains data which may be of use |
| 59 | + to either users directly or other software interfacing with the chain. In |
| 60 | + Shelley, this was limited to "metadata', which were indeed simply binary |
| 61 | + blobs. In the Mary and Alonzo eras slightly more structure was provided to |
| 62 | + allow including native and Plutus scripts respectively. |
| 63 | + |
| 64 | +4. The transaction validity contains a list of transactions in this block which |
| 65 | + are [phase-2 invalid](../state-transition/validity.md). This is held |
| 66 | + separately since this map is provided, effectively, by the node which |
| 67 | + created the block, rather than by the creators of the transactions. |
0 commit comments