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.

Sign up for GitHub

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

Documented the block body for the GRIN wiki website #75

Merged
merged 9 commits into from
Dec 27, 2024
Merged

Documented the block body for the GRIN wiki website #75

Changes from 1 commit
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
1086975
Documented the block body for the GRIN wiki website
marekyggdrasil Aug 21, 2022
8da2005
Range proofs are of a variable size
marekyggdrasil Aug 21, 2022
4f2f29c
Splitting height locked kernels and NRD kernel descriptions
marekyggdrasil Aug 21, 2022
a8f5354
Block body is Transaction body
marekyggdrasil Aug 21, 2022
26cf56b
Briefly explained the NRD kernels
marekyggdrasil Aug 24, 2022
29a10dd
Explained that block body is just a transaction body
marekyggdrasil Aug 24, 2022
8aa233b
Explained the coinbase kernel
marekyggdrasil Aug 25, 2022
aa76270
Another iteration of the NRD kernel description
marekyggdrasil Aug 25, 2022
210e886
Time locks in NRD kernels are relative
marekyggdrasil Aug 25, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
70 changes: 70 additions & 0 deletions docs/wiki/blocks/block-body.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,70 @@
# Block Body
marekyggdrasil marked this conversation as resolved.
Show resolved Hide resolved

General format of a **Block Body** in a Mimblewimble/Grin is basically a Mimblewimble transaction which consists of a list of **Inputs**, **Outputs** and **Kernels**.
marekyggdrasil marked this conversation as resolved.
Show resolved Hide resolved

| Field | Description | Size |
|:--------------|:----------------------|:---------------------|
| # inputs | Number of inputs | 8 bytes |
| # outputs | Number of outputs | 8 bytes |
| # kernels | Number of kernels | 8 bytes |
| inputs | Serialized inputs | 34 bytes per input |
| outputs | Serialized outputs | 42 bytes per output |
| kernels | Serialized kernels | x bytes per kernel |

The kernel size **x** depends on the kernel type. More details in its dedicated section below.

## Inputs

Each of the inputs consists of **Feature** and a **Commitment**.

| Field | Description | Size |
|:--------------|:----------------------------------------|:--------------------|
| Feature | **Plain** (0x00) or **Coinbase** (0x01) | 1 byte |
| Commitment | Pedersen commitment | 33 bytes |

## Outputs

Just as in case of the inputs, the outputs consist of **Feature** and a **Commitment** but in addition they also hold **Range proofs**

| Field | Description | Size |
|:--------------|:----------------------------------------|:--------------------|
| Feature | **Plain** (0x00) or **Coinbase** (0x01) | 1 byte |
| Commitment | Pedersen commitment | 33 bytes |
| Range proof | Proves the transaction is net positive | 8 bytes |
marekyggdrasil marked this conversation as resolved.
Show resolved Hide resolved

## Kernels

Every kernel starts with **Kernel feature** which indicates how it should be deserialized. In each variant, the kernel concludes with an **Excess commitment** and a **Excess signature**. What differs them is what is in the middle. We will describe each variant separately

### Coinbase kernel

The most basic kernel that does not contain **Fee** nor **Lock height**.

| Field | Description | Size |
|:------------------|:--------------------------------------------------------------------------------------------------|:--------------------|
| Feature | **Plain** (0x00), **Coinbase** (0x01), **Height Locked** (0x02) or **No recent duplicate** (0x03) | 1 byte |
| Excess commitment | Pedersen commitment | 33 bytes |
| Excess signature | Schnorr signature | 64 bytes |

### Plain kernel

A kernel resulting from a transaction, unlike **Coinbase** kernel it also includes **Fee** billed for the transaction.

| Field | Description | Size |
|:------------------|:--------------------------------------------------------------------------------------------------|:--------------------|
| Feature | **Plain** (0x00), **Coinbase** (0x01), **Height Locked** (0x02) or **No recent duplicate** (0x03) | 1 byte |
| Fee | Transaction fee | 8 bytes |
| Excess commitment | Pedersen commitment | 33 bytes |
| Excess signature | Schnorr signature | 64 bytes |

### Height locked / no recent duplicate / V1 protocol kernel
marekyggdrasil marked this conversation as resolved.
Show resolved Hide resolved

The first protocol **kernel** would always consist of **Feature**, **Fee**, **Lock height** and standard **Excess commitment** and **Signature**. Once V2 protocol was introduced this kind of kernel becamse **Height locked** kernel or **No recent duplicate** kernel.

| Field | Description | Size |
|:------------------|:--------------------------------------------------------------------------------------------------|:--------------------|
| Feature | **Plain** (0x00), **Coinbase** (0x01), **Height Locked** (0x02) or **No recent duplicate** (0x03) | 1 byte |
| Fee | Transaction fee | 8 bytes |
| Lock height | Block height starting from which the kernel becomes valid | 8 bytes |
| Excess commitment | Pedersen commitment | 33 bytes |
| Excess signature | Schnorr signature | 64 bytes |