Skip to content
Snippets Groups Projects
Commit 985bfaa9 authored by nanocryk's avatar nanocryk
Browse files

formatting and precisions

parent 29efc813
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
+ 80
− 19
Edit View file @ 985bfaa9
...@@ -23,9 +23,8 @@ If this RFC is accepted, this document could be used as documentation with no or ...@@ -23,9 +23,8 @@ 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. [Conventions and common rules](#1-conventions-and-common-rules)
1. [Keys formats](#2-keys-format) 1. [General document format](#2-general-document-format)
1. General document format 1. [Transaction document](#3-transaction-document)
1. Transaction document
1. Identity, Membership and Certification documents 1. Identity, Membership and Certification documents
1. Block document 1. Block document
...@@ -37,7 +36,7 @@ All data fields are big-endian unless otherwise specified. ...@@ -37,7 +36,7 @@ All data fields are big-endian unless otherwise specified.
### 1.2. Hashes ### 1.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.
...@@ -62,14 +61,14 @@ blocks and padding be used if alignement is not directly possible. ...@@ -62,14 +61,14 @@ blocks and padding be used if alignement is not directly possible.
### 1.5. Block identifiers ### 1.5. Block identifiers
Each block is indexed bu its `BlockID` stored as a 4 bytes unsigned integer. Each block is indexed bu its **block ID** stored as a *4 bytes unsigned integer*.
The genesis block `BlockID` is `0`, and each following block have a `BlockID` incremented by `1`. 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 `BlockID` and its `Hash`. The `Blockstamp` To refeer a *block*, we use it's **blockstamp** made of its *block ID* and its *hash*. The *blockstamp*
of the genesis block *might be* `0-883228A23F8A75B342E912DF439738450AE94F5D` and the `Blockstamp` of the genesis block *might be* `0-883228A23F8A75B342E912DF439738450AE94F5D` and the *blockstamp*
of block `443` *might be* `433-FB11681FC1B3E36C9B7A74F4DDE2D07EC2637957`. of block `443` *might be* `433-FB11681FC1B3E36C9B7A74F4DDE2D07EC2637957`.
Since hashes are stored on 32 bytes, a blockstamp is stored on a 36 bytes value. Since hashes are stored on 32 bytes, a *blockstamp* is stored on a 36 bytes value.
> 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.
...@@ -80,20 +79,20 @@ since 00:00:00 UTC on January 1, 1970. They are stored in a 64bit format to ...@@ -80,20 +79,20 @@ since 00:00:00 UTC on January 1, 1970. They are stored in a 64bit format to
avoid [year 2038 problem][year-2038-problem]. In this format the counter will overflow avoid [year 2038 problem][year-2038-problem]. In this format the counter will overflow
in approximately 293 billion years. in approximately 293 billion years.
Durations are expressed in eleapsed time between 2 timestamps. Durations are expressed in eleapsed time between 2 *timestamps*.
Another way to provide dates is to reference a `Blockstamp`. Another way to provide dates is to reference a *blockstamp*.
Dates in the blockchain are calculated as the average time provided in a window of `MedianTimeBlocks` blocks. Dates in the *blockchain* are calculated as the average time provided in a window of `MedianTimeBlocks` blocks.
It should be preferred to use blockstamps since its independent of any external influences. It should be preferred to use *blockstamps* since its independent of any external influences.
> `Param.MedianTimeBlocks = 24` in Ǧ1 currency. > `Param.MedianTimeBlocks = 24` in Ǧ1 currency.
[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
## 2. Keys format ## 1.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.
[Schnorr signature]: https://en.wikipedia.org/wiki/Schnorr_signature [Schnorr signature]: https://en.wikipedia.org/wiki/Schnorr_signature
...@@ -102,13 +101,13 @@ Public and private keys have this format : ...@@ -102,13 +101,13 @@ Public and private keys have this format :
| Size | Data | | Size | Data |
|:----:|:-----| |:----:|:-----|
| *4 bytes* | Checksum (4 first bytes of hash the following fields) | *4 bytes* | Checksum (4 first bytes of hash the following fields without the padding)
| *2 bytes* | Cryptographic system (determine `size` of payload) | *2 bytes* | Cryptographic system (determine `size` of payload)
| *2 bytes* | Currency code | *2 bytes* | Currency code
| *`size` bytes* | Payload | *`size` bytes* | Payload
| *`4 - (size % 4)` bytes* | Padding | *`4 - (size % 4)` bytes* | Padding
Depending of the context `size` will be the size of the public or private key. Depending of the context, `size` will be the size of the public or private key.
Private keys are never stored in the blockchain, but can be used in clients or other protocols. Private keys are never stored in the blockchain, but can be used in clients or other protocols.
For now only `Ed25519` is defined for type `0`, with For now only `Ed25519` is defined for type `0`, with
...@@ -118,6 +117,68 @@ For now only `Ed25519` is defined for type `0`, with ...@@ -118,6 +117,68 @@ For now only `Ed25519` is defined for type `0`, with
| *32 bytes* | Public key | *32 bytes* | Public key
| *64 bytes* | Private key | *64 bytes* | Private key
The whole blob above is then formated in Base58 and displayed to the user. The whole *blob* above is then formated in Base58 and displayed to the user.
With this format it will be very unlikely someone send to an unwanted address. > With this format it will be very unlikely someone send to an unwanted address.
\ No newline at end of file
The complete *checksum* (hash of all other fields) of a *public key* is known as a **compact public key** (or **compact key**)
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*.
### 1.8. Identities
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.
```txt
IdentityHash = SHA256(Username + CompactKey + Blockstamp)
```
> The `+` operation is a raw byte concatenation.
## 2. General document format
Each document is composed of an header, a list of issuers, a payload and one or more signatures.
The header is used for network propagation, but is ellided when written into a
block since they can be deduced from block data and context.
The *header* and *payload* are then hashed to optain a **document ID**.
This *document ID* is unique and is used in *Merkle Trees*. This can allow many optimisations,
such as storing only the *Merkle Tree* and being able to prove a given document is included in
it or not. Then *signatures* are made on this **document ID**.
Since the *document ID* is not affected by *signatures*, they are not affected by *signature malleability*.
> See the block structure for more information about Merkle Trees usage.
The header is composed of :
| Size | Data |
|:----:|:-----|
| *4 bytes* | Magic value : `0xDAE2D598`
| *2 bytes* | Currency code
| *2 bytes* | Document type
> The magic value has been choosed randomly and contains data with low probability to find in UTF-8 text.
The issuer part is composed of :
| Size | Data |
|:----:|:-----|
| *2 bytes* | Number of issuers
| ... | Issuers *complete public keys* with alignement padding for each
Signature cryptographic types are not defined and use the matching public key types.
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.
## 3. Transaction document
### 3.1. Document structure
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.
Each source or UD can be spent only once, and the **sum of *inputs* values must equal the sum of *output* values**.
Each *output* describes spending conditions using a **script**. This *script* is defined as an
**Abstract Syntaxic Tree** of operations which returns a boolean : can this output be used as an input of a new transaction.
This format will be describe further in this document.
\ No newline at end of file
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