WIP: RFC 5 : New Scalable Blockchain Protocol

This document provides specifications of a new blockchain protocol which will be used power future versions of Duniter currencies. It is however a generalist protocol and could be used by other projects outside of Duniter and with little or no modifications.

rfc/0005 Duniter Protocol Rework.md

@@ -25,8 +25,11 @@ If this RFC is accepted, this document could be used as documentation with no or
 1. [Introduction](#1-introduction)
 1. [Conventions](#2-conventions)
 1. [General document format](#3-general-document-format)
-1. [Transaction document](#4-transaction-document)
-1. Identity, Membership and Certification documents
+1. Identity document
+1. Membership document
+1. Certification document
+1. Revocation document
+1. [Transaction document](#8-transaction-document)
 1. Block document
 
 ## 1. Introduction
@@ -108,7 +111,7 @@ It should be preferred to use *blockstamps* since its independent of any externa
 [unix-timestamp]: https://en.wikipedia.org/wiki/Unix_time
 [year-2038-problem]: https://en.wikipedia.org/wiki/Unix_time#Representing_the_number
 
-## 2.7. Keys
+### 2.7. Keys
 
 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.
@@ -156,10 +159,14 @@ IdentityHash = SHA256(Username + CompactKey + Blockstamp)
 
 ## 3. General document format
 
-Each document is composed of an header, a payload and one or more signatures.
+Each *document* is composed of a **header**, a **payload** and one or more **signatures**.
 The tuple `(magic value, currency code, document type)` is used for network propagation,
 but is ellided when written into a block since they can be deduced from block data and context.
 
+An **extention field** is provided to allow future protocol extensions without modifying this document
+structure. It can contain any data but should have some sort of standard format to target specific extensions.
+This format is not yet defined and will be in a future RFC, for now this extension field should be empty (size of 0).
+
 The *header* and *payload* are hashed to optain a **document ID**, then *signatures* are made from it.
 
 The header is composed of :
@@ -170,10 +177,22 @@ The header is composed of :
 | *2 bytes* | Currency code
 | *2 bytes* | Document type
 | *2 bytes* | Payload size in bytes
+| *1 byte* | Extension field size in bytes (0 to 255)
+| ... | Extension field with alignement padding
 | *2 bytes* | Number of issuers
-| ... | Issuers *complete public keys* with alignement padding for each
+| ... | List of issuers *complete public keys* with alignement padding for each
 
 > The magic value has been choosed randomly and contains data with low probability to find in UTF-8 text.
+>
+> ### Need review
+>
+> Blockstamp has been removed from common header, and is now included only in documents
+> needing a "non-block-insertion-time" date.
+>
+> For exemple, a transaction document don't seems to make use of this blockstamp. In the script, it can target
+> a fixed date with a timestamp, and a relative date based on the transaction insertion or another date.
+> With this primitives it should be possible to express any time requirements, so a document blockstamp
+> seems unnecessary.
 
 Payload and each signatures have alignement padding.
 
@@ -181,9 +200,39 @@ Cryptographic systems of signatures are not provided and matching public key typ
 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 the public key.
 
-## 4. Transaction document
+The document types are the following :
+
+| Name | Code |
+|:-----|:----:|
+| Block | `0x00` |
+| Transaction | `0x10` |
+| Identity | `0x20` |
+| Membership | `0x21` |
+| Certification | `0x22` |
+| Revocation | `0x23` |
+| RevocationV10 | `0x24` |
+
+## 4. Identity document
+
+TODO
+
+## 5. Membership document
+
+TODO
+
+## 6. Certification document
 
-### 4.1. Document structure
+TODO
+
+## 7. Revocation document
+
+TODO
+
+## 8. Transaction document
+
+TODO
+
+### 8.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.
@@ -191,4 +240,8 @@ Each source or UD can be spent only once, and the **sum of *inputs* values must
 
 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
+This format will be describe further in this document.
+
+### 8.X Script system
+
+TODO
\ No newline at end of file