mirror of
https://github.com/mimblewimble/grin.git
synced 2025-01-20 19:11:08 +03:00
dfd0a649c7
* create and occupy translations dir * update translation links * add mimblewimble whitepaper * add p2p_protocol from docs * add validation_logic from docs Co-authored-by: Paouky <Paouky@users.noreply.github.com>
79 lines
3.5 KiB
Markdown
79 lines
3.5 KiB
Markdown
# Pruning Blockchain Data
|
|
|
|
*Read this in other languages: [Korean](translations/pruning_KR.md), [简体中文](translations/pruning_ZH-CN.md).*
|
|
|
|
One of the principal attractions of Mimblewimble is its theoretical space
|
|
efficiency. Indeed, a trusted or pre-validated full blockchain state only
|
|
requires unspent transaction outputs, which could be tiny.
|
|
|
|
The grin blockchain includes the following types of data (we assume prior
|
|
understanding of the Mimblewimble protocol):
|
|
|
|
1. Transaction outputs, which include for each output:
|
|
1. A Pedersen commitment (33 bytes).
|
|
1. A range proof (over 5KB at this time).
|
|
1. Transaction inputs, which are just output references (32 bytes).
|
|
1. Transaction "proofs", which include for each transaction:
|
|
1. The excess commitment sum for the transaction (33 bytes).
|
|
1. A signature generated with the excess (71 bytes average).
|
|
1. A block header includes Merkle trees and proof of work (about 250 bytes).
|
|
|
|
Assuming a blockchain of a million blocks, 10 million transactions (2 inputs, 2.5
|
|
outputs average) and 100,000 unspent outputs, we get the following approximate
|
|
sizes with a full chain (no pruning, no cut-through):
|
|
|
|
* 128GB of transaction data (inputs and outputs).
|
|
* 1 GB of transaction proof data.
|
|
* 250MB of block headers.
|
|
* Total chain size around 130GB.
|
|
* Total chain size, after cut-through (but incl. headers) of 1.8GB.
|
|
* UTXO size of 520MB.
|
|
* Total chain size, without range proofs of 4GB.
|
|
* UTXO size, without range proofs of 3.3MB.
|
|
|
|
We note that out of all that data, once the chain has been fully validated, only
|
|
the set of UTXO commitments is strictly required for a node to function.
|
|
|
|
There may be several contexts in which data can be pruned:
|
|
|
|
* A fully validating node may get rid of some data it has already validated to
|
|
free space.
|
|
* A partially validating node (similar to SPV) may not be interested in either
|
|
receiving or keeping all the data.
|
|
* When a new node joins the network, it may temporarily behave as a partially
|
|
validating node to make it available for use faster, even if it ultimately becomes
|
|
a fully validating node.
|
|
|
|
## Validation of Fully Pruned State
|
|
|
|
Pruning needs to remove as much data as possible while keeping all the
|
|
guarantees of a full Mimblewimble-style validation. This is necessary to keep
|
|
a pruning node state's sane, but also on first fast sync, where only the
|
|
minimum amount of data is sent to a new node.
|
|
|
|
The full validation of the chain state requires that:
|
|
|
|
* All kernel signatures verify against their public keys.
|
|
* The sum of all UTXO commitments, minus the supply is a valid public key (can
|
|
be used to sign the empty string).
|
|
* The sum of all kernel pubkeys equals the sum of all UTXO commitments, minus
|
|
the supply.
|
|
* The root hashes of the UTXO PMMR, the range proofs PMMR and the kernels MMR
|
|
match a block header with a valid Proof of Work chain.
|
|
* All range proofs are valid.
|
|
|
|
In addition, while not necessary to validate the full chain state, to be able
|
|
to accept and validate new blocks additional data is required:
|
|
|
|
* The output features, making the full output data necessary for all UTXOs.
|
|
|
|
At minimum, this requires the following data:
|
|
|
|
* The block headers chain.
|
|
* All kernels, in order of inclusion in the chain. This also allows the
|
|
reconstruction of the kernel MMR.
|
|
* All unspent outputs.
|
|
* The UTXO MMR and the range proof MMR (to learn the hashes of pruned data).
|
|
|
|
Note that further pruning could be obtained by requiring the validation of
|
|
only a subset of the range proofs, chosen randomly by the validating node.
|