Core/grin
0
0
Fork 0
mirror of https://github.com/mimblewimble/grin.git synced 2025-02-01 08:51:08 +03:00
Code Issues Projects Releases Packages Wiki Activity Actions

Intro to pruning doc, just some facts and size data.

Browse source
This commit is contained in:
Ignotus Peverell 2016-11-08 09:50:13 -08:00
parent 632e3af8ee
commit 2e23c64448
No known key found for this signature in database
GPG key ID: 99CD25F39F8F8211
1 changed files with 43 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

43
doc/pruning.md Normal file
View file

@ -0,0 +1,43 @@
# Pruning Blockchain Data
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).
2. A range proof (over 5KB at this time).
2. Transaction inputs which are just output references (32 bytes).
3. Transaction "proofs", which include for each transaction:
1. The excess commitment sum for the transaction (33 bytes).
2. A signature generated with the excess (71 bytes average).
4. 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 do full validation and
hence 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.