Skip to content

Commit d7664d3

Browse files
AnynomoussAnynomouss
authored
Merge pull request #75 from marekyggdrasil/master
Documented the block body for the GRIN wiki website
2 parents cb642fd + 210e886 commit d7664d3

File tree

2 files changed

+88
-0
lines changed

2 files changed

+88
-0
lines changed

‎docs/wiki/blocks/block-body.md‎

Lines changed: 3 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,3 @@
1+
# Block Body
2+
3+
The block body contains transactions. They are aggregated into one single transaction and follow the description of a [transaction body](../transactions/transaction-body.md).

‎docs/wiki/transactions/transaction-body.md‎

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
# Transaction Body
2+
3+
General format of a **Transaction Body** in a Mimblewimble/Grin is basically a Mimblewimble transaction which consists of a list of **Inputs**, **Outputs** and **Kernels**.
4+
5+
| Field | Description | Size |
6+
|:--------------|:----------------------|:---------------------|
7+
| # inputs | Number of inputs | 8 bytes |
8+
| # outputs | Number of outputs | 8 bytes |
9+
| # kernels | Number of kernels | 8 bytes |
10+
| inputs | Serialized inputs | 34 bytes per input |
11+
| outputs | Serialized outputs | 42 bytes per output |
12+
| kernels | Serialized kernels | x bytes per kernel |
13+
14+
The kernel size **x** depends on the kernel type. More details in its dedicated section below.
15+
16+
## Inputs
17+
18+
Each of the inputs consists of **Feature** and a **Commitment**.
19+
20+
| Field | Description | Size |
21+
|:--------------|:----------------------------------------|:--------------------|
22+
| Feature | **Plain** (0x00) or **Coinbase** (0x01) | 1 byte |
23+
| Commitment | Pedersen commitment | 33 bytes |
24+
25+
## Outputs
26+
27+
Just as in case of the inputs, the outputs consist of **Feature** and a **Commitment** but in addition they also hold **Range proofs**
28+
29+
| Field | Description | Size |
30+
|:-----------------------|:----------------------------------------|:--------------------|
31+
| Feature | **Plain** (0x00) or **Coinbase** (0x01) | 1 byte |
32+
| Commitment | Pedersen commitment | 33 bytes |
33+
| Range proof size **x** | Proves the transaction is net positive | 8 bytes |
34+
| Range proof | Proves the transaction is net positive | **x** bytes |
35+
36+
Note that the **range proof** is of a variable size which is indicated by its first 8 bytes.
37+
38+
## Kernels
39+
40+
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
41+
42+
### Coinbase kernel
43+
44+
This kernel is used for coinbase outputs that collect both the fixed block subsidy of 60 Grin and all the transaction fees in the block.
45+
46+
| Field | Description | Size |
47+
|:------------------|:--------------------------------------------------------------------------------------------------|:--------------------|
48+
| Feature | **Plain** (0x00), **Coinbase** (0x01), **Height Locked** (0x02) or **No recent duplicate** (0x03) | 1 byte |
49+
| Excess commitment | Pedersen commitment | 33 bytes |
50+
| Excess signature | Schnorr signature | 64 bytes |
51+
52+
### Plain kernel
53+
54+
A kernel resulting from a transaction, unlike **Coinbase** kernel it also includes **Fee** billed for the transaction.
55+
56+
| Field | Description | Size |
57+
|:------------------|:--------------------------------------------------------------------------------------------------|:--------------------|
58+
| Feature | **Plain** (0x00), **Coinbase** (0x01), **Height Locked** (0x02) or **No recent duplicate** (0x03) | 1 byte |
59+
| Fee | Transaction fee | 8 bytes |
60+
| Excess commitment | Pedersen commitment | 33 bytes |
61+
| Excess signature | Schnorr signature | 64 bytes |
62+
63+
### Height locked kernels
64+
65+
The first protocol **kernel** would always consist of **Feature**, **Fee**, **Lock height** and standard **Excess commitment** and **Signature**. Starting from the V2 protocol a specific type of kernel - **height locked** kernel supports the **lock height**.
66+
67+
| Field | Description | Size |
68+
|:------------------|:--------------------------------------------------------------------------------------------------|:--------------------|
69+
| Feature | **Plain** (0x00), **Coinbase** (0x01), **Height Locked** (0x02) or **No recent duplicate** (0x03) | 1 byte |
70+
| Fee | Transaction fee | 8 bytes |
71+
| Lock height | Block height starting from which the kernel becomes valid | 8 bytes |
72+
| Excess commitment | Pedersen commitment | 33 bytes |
73+
| Excess signature | Schnorr signature | 64 bytes |
74+
75+
### NRD (No Recent Duplicate) kernels
76+
77+
An NRD kernel is only valid in the absence of an identical instance existing within the last relative-height blocks. More information is available in the [NRD kernel RFC](../../grin-rfcs/text/0013-nrd-kernels.md) as well as in the [mailing list archive](https://lists.launchpad.net/mimblewimble/msg00636.html).
78+
79+
| Field | Description | Size |
80+
|:---------------------|:--------------------------------------------------------------------------------------------------|:--------------------|
81+
| Feature | **Plain** (0x00), **Coinbase** (0x01), **Height Locked** (0x02) or **No recent duplicate** (0x03) | 1 byte |
82+
| Fee | Transaction fee | 8 bytes |
83+
| Relative lock height | Number of most recent blocks in which the same NRD must be absent | 8 bytes |
84+
| Excess commitment | Pedersen commitment | 33 bytes |
85+
| Excess signature | Schnorr signature | 64 bytes |

0 commit comments

Comments
 (0)