Skip to content
Snippets Groups Projects

WIP: RFC 5 : New Scalable Blockchain Protocol

Closed nanocryk requested to merge rfc5-duniter-protocol-rework into master
1 file
+ 6
6
Compare changes
  • Side-by-side
  • Inline
@@ -42,15 +42,15 @@ They are stored as raw bytes arrays and should be displayed in hexadecimal forma
### 1.3. Bases
Some specific data is stored or displayed using specific bases :
Some specific data is stored or displayed using these bases :
- Base58 (Display) : Mainly used for public keys, it avoids using close looking
- Base58 (for display) : Mainly used for keys, it avoids using close looking
characters and allow whole content selection with double-clicking.
The alphabet is `123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz`.
- Base64 (Display) : Data format used for non error-prone data such as signatures.
- Base64 (for display) : Data format used for non user-friendly data such as signatures.
The alphabet is `ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/`.
- Name64 (Storage) : Allow to store names in a more compact way that raw ASCII/UTF-8 text.
Each character is stored on 6bits, and remove any invalid or non displayable characters.
- Name64 (for storage) : Allow to store names in a more compact way that raw ASCII/UTF-8 text.
Each character is stored on 6bits, and remove any invalid characters.
The alphabet is `ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-`.
### 1.4. Bytes alignments
@@ -61,7 +61,7 @@ blocks and padding be used if alignement is not directly possible.
### 1.5. Block identifiers
Each block is indexed bu its **block ID** stored as a *4 bytes unsigned integer*.
Each block is indexed by its **block ID** stored as a *4 bytes unsigned integer*.
The ***genesis block*** *ID* is `0`, and each following block have a *block ID* incremented by `1`.
To refeer a *block*, we use it's **blockstamp** made of its *block ID* and its *hash*. The *blockstamp*
Loading