Skip to content
Snippets Groups Projects
Commit 469273e4 authored by nanocryk's avatar nanocryk
Browse files

introduction, numering, typo

parent 338eb7f1
No related branches found
No related tags found
1 merge request!6WIP: RFC 5 : New Scalable Blockchain Protocol
This commit is part of merge request !6. Comments created here will be created in the context of that merge request.
Hide whitespace changes
Inline Side-by-side
rfc/0005 Duniter Protocol Rework.md
+ 35
− 17
Edit View file @ 469273e4
...@@ -22,25 +22,43 @@ If this RFC is accepted, this document could be used as documentation with no or ...@@ -22,25 +22,43 @@ If this RFC is accepted, this document could be used as documentation with no or
## Summary ## Summary
1. [Conventions and common rules](#1-conventions-and-common-rules) 1. [Introduction](#1-introduction)
1. [General document format](#2-general-document-format) 1. [Conventions](#2-conventions)
1. [Transaction document](#3-transaction-document) 1. [General document format](#3-general-document-format)
1. [Transaction document](#4-transaction-document)
1. Identity, Membership and Certification documents 1. Identity, Membership and Certification documents
1. Block document 1. Block document
## 1. Conventions and common rules ## 1. Introduction
### 1.1. Endianness The Duniter software aims to provide *Universal Dividend*-based crypto-currency.
The name is made from `DU + unit + er`, as "*a tool for creating UD units*".
> *DU* stands for "Dividende Universel", "Universal Dividend" in french.
It's based on Stephane Laborde's [Relative Theory of Money] which aim to provide equality
to money creation between all users, in space [of users] and time.
The currency is based on a **blockchain** composed of **blocks**, linked together with
*cryptographic hashes*; containing *documents* for *transactions* and management of the
**Web of Trust** : a structure used to associate a human being with only one account, which is
needed to avoid a user to have multiple UD.
[Relative Theory of Money]: http://en.trm.creationmonetaire.info/
## 2. Conventions
### 2.1. Endianness
All data fields are big-endian unless otherwise specified. All data fields are big-endian unless otherwise specified.
### 1.2. Hashes ### 2.2. Hashes
All *cryptographic hashes* are done with *SHA256* algorithm unless otherwise specified. All *cryptographic hashes* are done with *SHA256* algorithm unless otherwise specified.
They are stored as raw bytes arrays and should be displayed in hexadecimal format. They are stored as raw bytes arrays and should be displayed in hexadecimal format.
### 1.3. Bases ### 2.3. Bases
Some specific data is stored or displayed using these bases : Some specific data is stored or displayed using these bases :
...@@ -53,13 +71,13 @@ Some specific data is stored or displayed using these bases : ...@@ -53,13 +71,13 @@ Some specific data is stored or displayed using these bases :
Each character is stored on 6bits, and remove any invalid characters. Each character is stored on 6bits, and remove any invalid characters.
The alphabet is `ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-`. The alphabet is `ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789_-`.
### 1.4. Bytes alignments ### 2.4. Bytes alignments
Data should be aligned in 4 bytes blocks to improve memory speed. Data should be aligned in 4 bytes blocks to improve memory speed.
Large values should be aligned, small values packed together to form 4 bytes Large values should be aligned, small values packed together to form 4 bytes
blocks and padding be used if alignement is not directly possible. blocks and padding be used if alignement is not directly possible.
### 1.5. Block identifiers ### 2.5. Block identifiers
Each block is indexed by 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`. The ***genesis block*** *ID* is `0`, and each following block have a *block ID* incremented by `1`.
...@@ -72,7 +90,7 @@ Since hashes are stored on 32 bytes, a *blockstamp* is stored on a 36 bytes valu ...@@ -72,7 +90,7 @@ Since hashes are stored on 32 bytes, a *blockstamp* is stored on a 36 bytes valu
> Note that is says "might be" because the hash is not known in advence. > Note that is says "might be" because the hash is not known in advence.
### 1.6. Dates ### 2.6. Dates
All dates are stored in [UNIX timestamp format][unix-timestamp], as the number of seconds All dates are stored in [UNIX timestamp format][unix-timestamp], as the number of seconds
since 00:00:00 UTC on January 1, 1970. They are stored in a 64bit format to since 00:00:00 UTC on January 1, 1970. They are stored in a 64bit format to
...@@ -90,7 +108,7 @@ It should be preferred to use *blockstamps* since its independent of any externa ...@@ -90,7 +108,7 @@ It should be preferred to use *blockstamps* since its independent of any externa
[unix-timestamp]: https://en.wikipedia.org/wiki/Unix_time [unix-timestamp]: https://en.wikipedia.org/wiki/Unix_time
[year-2038-problem]: https://en.wikipedia.org/wiki/Unix_time#Representing_the_number [year-2038-problem]: https://en.wikipedia.org/wiki/Unix_time#Representing_the_number
## 1.7. Keys ## 2.7. Keys
The new key format allow user to choose which *cryptographic system* he wants to use. The new key format allow user to choose which *cryptographic system* he wants to use.
Currently only Ed25519 is supported, but others like [Schnorr signature] could be added. Currently only Ed25519 is supported, but others like [Schnorr signature] could be added.
...@@ -125,7 +143,7 @@ The complete *checksum* (hash of all other fields) of a *public key* is known as ...@@ -125,7 +143,7 @@ The complete *checksum* (hash of all other fields) of a *public key* is known as
and can be used to designate any public key in a fixed size value. and can be used to designate any public key in a fixed size value.
When a *complete public key* is used, it can be hashed and compared with the *compact key*. When a *complete public key* is used, it can be hashed and compared with the *compact key*.
### 1.8. Identities ### 2.8. Identities
Each identity can be referred as its **identity hash** (or **indentity UID**) computed from the username, Each identity can be referred as its **identity hash** (or **indentity UID**) computed from the username,
the hash of its associated *compact key* and the *blockstamp* of the identity creation document. the hash of its associated *compact key* and the *blockstamp* of the identity creation document.
...@@ -136,7 +154,7 @@ IdentityHash = SHA256(Username + CompactKey + Blockstamp) ...@@ -136,7 +154,7 @@ IdentityHash = SHA256(Username + CompactKey + Blockstamp)
> The `+` operation is a raw byte concatenation. > The `+` operation is a raw byte concatenation.
## 2. General document format ## 3. General document format
Each document is composed of an header, a payload and one or more signatures. Each document is composed of an header, a payload and one or more signatures.
The tuple `(magic value, currency code, document type)` is used for network propagation, The tuple `(magic value, currency code, document type)` is used for network propagation,
...@@ -159,13 +177,13 @@ The header is composed of : ...@@ -159,13 +177,13 @@ The header is composed of :
Payload and each signatures have alignement padding. Payload and each signatures have alignement padding.
Signatures cryptographic types are not defined and use the matching public key types. Cryptographic systems of signatures are not provided and matching public key types are used.
A document is valid if each public key can match a signature (with 0 bytes left and no overflows) A document is valid if each public key can match a signature (with 0 bytes left and no overflows)
and each signature is valid for the document content. and each signature is valid for the document content and the public key.
## 3. Transaction document ## 4. Transaction document
### 3.1. Document structure ### 4.1. Document structure
A **transaction document** describes the consumption of **sources** and the creation of **outputs**. A **transaction document** describes the consumption of **sources** and the creation of **outputs**.
Since we're dealing with *Universal Dividend*s, it's possible to provide a list of UDs to spend. Since we're dealing with *Universal Dividend*s, it's possible to provide a list of UDs to spend.
......
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment