Civicpower
Rechercher
K

Blockchain

Civicpower garantit l'intégrité des opérations de vote grâce à l'utilisation d'une technologie blockchain
L'article ci-dessous détaille le fonctionnement de cette technologie.

Sustainable Blockchain Tech

inBlocks has been developing "Precedence" since 2018, a data oriented Layer 2, compatible with all level 1 existing blockchain.
After a three years shadow development phase, an academic validation confirmed our end-to-end "proof of assets":
InBlocks Precedence offers the same level of assurance as Ethereum as to the proof of existence of each piece of stored data.

Introduction to a new type of L2

Precedence allows structuring information using the same paradigm as in blockchain technologies. Each record is an arbitrary set of binary information that can be cryptographically linked to one or more previous records. A record is persisted in a block. A block is a set of records and can contain one or more records. Each block is cryptographically linked to the previous block (except for the first block which is explicitly identifiable as the first block).
The set of records that constitute a block is structured in the form of a Patricia Merkle Trie (strictly identical to those used in Ethereum). This structuring allows the calculation of a number (called root hash), often represented in hexadecimal form, which represents all the records of the block; each modification, however minor, of a record impacts the value of this number in such a way that (i) it is not possible to impact a record without impacting the value of the root hash and (ii) it is not possible to determine, from this number, the set of records that allows its calculation (this class of functions is called one-way functions).
This data format makes it possible to extract a cryptographic proof of existence from each record in a block. This means that it is possible to mathematically prove that a record is part of a block and that this proof is irrefutable because it cannot be forged from other records.
The L2 inBlocks layer aims to demonstrate the continuity of existence of a data by relying on the decentralisation of L1 blockchains.
EVM oriented L2 like ZK rollups or optimistic rollups allowing to scale the number of transactions within this type of blockchain.
The implementation of L2 inBlocks for EVM type L1s is based on a primitive smartcontract allowing to certify the data linked to a digital asset of the L1 blockchain. The costs and speed of writing are then drastically reduced, the security risks limited, the scalability of the data model facilitated while maintaining the decentralisation of the proof.
These characteristics are demonstrated in the CYP operation through the oracle of the vaults, the evolution of the game cards, the life cycle of the CYP, the in-game currency.

inBlocks Platform

As seen previously, precedence allows to build proofs of existence of records inside blocks whose set of elements which constitutes it is summarizable to a simple number (of 256 bits). The demonstration of the knowledge, the existence of this number at a given moment allows to demonstrate the existence of the set of records which allowed its calculation. In order to demonstrate to any third party the value of this timestamp, it is necessary to use a trusted third party accepted by all. inBlocks uses Ethereum as a support for the recording of these root hashes. The immutable nature of the records (called transactions) of the Ethereum blocks makes it possible to make irrefutable the date on which this number (root hash) was calculated and thus the date on which the linked records could be created. In order to optimize the writing in the Ethereum blockchain, the inBlocks platform proposes a two-level model in which the writings realized in a private precedence blockchain allow to constitute blocks and to calculate for each one the root hash which is then automatically integrated in the form of recording in a shared precedence instance (and thus multi private blockchain) which is the one used as source of information for the writing of root hash in the Ethereum blockchain. This architecture allows a very high volume of writing per second compared to what can be recorded by level 1 blockchains such as Ethereum.
General operation of an existence proof built by the inBlocks platform.
When creating a Precedence record from a D data, the following information is calculated and recorded:
  • id: record identifier (provided or randomly generated),
  • seed*: randomly defined data obfuscation seed,
  • hash*: hash of the data D,
  • chains*: set of sub-strings of the record (possibly empty),
  • previous*: list of the identifier(s) of the records representing the same asset (possibly empty),
  • address: public key corresponding to the private key used to sign the hash of document D (optional),
  • signature: signature of the hash of document D (optional).
All information marked with an asterisk is calculated from the source of the indicated information and a 256-bit random number (called seed) so that each record, even if duplicated in Precedence, is unique. Only the value of the id cannot be identical between two records. This information, represented in JSON format, constitutes a document that we call E. From this information, a Precedence record is created whose key is the identifier (id) and whose value is the hash (SHA-256) of E.
The proof of existence of this document allows to prove all the information listed above; including the existence of the hash of the document D and thus the document D (one-way hash function).

General operation of an existence proof built by the inBlocks platform

When creating a Precedence record from a D data, the following information is calculated and recorded:
  • id: record identifier (provided or randomly generated),
  • seed*: randomly defined data obfuscation seed,
  • hash*: hash of the data D,
  • chains*: set of sub-strings of the record (possibly empty),
  • previous*: list of the identifier(s) of the records representing the same asset (possibly empty),
  • address: public key corresponding to the private key used to sign the hash of document D (optional),
  • signature: signature of the hash of document D (optional).
All the information marked with an asterisk is calculated from the source of the indicated information and a 256-bit random number (called seed) so that each record, even if duplicated in Precedence, is unique. Only the value of the id cannot be identical between two records.
This information, represented in JSON format, constitutes a document that we call E. From this information, a Precedence record is created whose key is the identifier (id) and whose value is the hash (SHA-256) of E.
The proof of existence of this document allows to prove all the information listed above ; including the existence of the hash of the document D and thus the document D (one-way hash function).

Creating a record in Precedence

Here we assume the creation of a record for document D and whose id is I.
Let H1 = sha256(D) and H2 = sha256(id) and seed a large random number (0 < seed < 2²⁵⁶)
Precedence builds the following E-key/value document (in JSON format): { “id”: H2, “seed”: sha256(SEED, SEED) “hash”: sha256(SEED, H1), “chains”: {}, “previous”: [], }
Example result: { “id”: “5c89750b07bced2dbaa5d16eb46826fe3f06297cf5f930defe7169158b24fd9d”, “seed”: “bdec0dd5015e69d32ec8fd8a868ac44e0962ea64320e109ab48d789eab6b4421”, “hash”: “3de8d12c829a8e06ffeabac575aa3852f90d57160767832d6bdfde44bb3cc116”, “chains”: {}, “previous”: [], }
The seed value is stored in order to prove the value of H1 (the provable value is sha256(SEED, H1).
All the information contained in this document is demonstrable, it would have been the same for the chains and previous fields if they had been filled in.
Once this record is created, it is integrated into a Merkle Patricia Trie with the key id and the value sha256(E).
The construction of this block allows the calculation of the root hash of the Merkle Patricia Trie containing the previous record. We call R1 this number.
Precedence then creates an E2 record in a Precedence instance common to all private blockchains. This record has the following format:
Let SEED2 be a random number. We call F the following document constructed and computed by precedence : F = { “id”: ID1,“seed”: sha256(SEED2, SEED2) “hash”: sha256(SEED2, sha256(E)), “chains”: {}, “previous”: [], }
Finally, a new block on this common blockchain is created and thus the Merkle Patricia Trie which includes ID1, sha256(F) and thus the root hash of it which we call H3.
The H3 information is directly dependent on all the records of the block it represents. However, each record corresponds to the root hash of a block of the blockchain of lower level. Thus, there is a multi-level proof of existence between the initial record of document D and the immutable and irrefutable time-stamped writing of H3 in the Ethereum blockchain.
Dernière mise à jour 3mo ago