A unified ledger for transactions and SC operations

[massa-bot]

In GitLab by @sebf

Here is a possible way of implementing the smart contract ledger, the main ideas are the following:

• The Blockclique Consensus module is processing new blocks to output a blockclique and final blocks
• The Virtual Machine module is processing the operations in the blockclique to update a ledger
• The PoS Selection module is selecting block and endorsement producers based on the ledger of the VM
• One single ledger, for all entries: Address -> balances, rolls, code, data.
• A notion of sequential finality: when a block is final, other blocks before it can still change, so the block is said "sequentially final" when no other blocks can be included before.
• Two types of balances: a 'sequential' balance (b--) that cannot be spent in parallel, and one 'parallel' balance (b||) that can
• When creating a block, we check that the inclusion fees and gaz fees can be for sure debited from the sequential balance of the address (based on the sequential finality)
• A block can be valid even if some of its operations are not: when the virtual machine processes them, each operation is executed if it is valid (enough inclusion fees, good signature etc).

Context: a smart contract engine on a multithreaded block graph

The main constraint of the multithreaded architecture, making it difficult to copy-paste e.g. the EVM, comes from the parallel block structure and the transaction sharding mechanism. Transaction sharding allows an address to spend coins only in blocks of a single thread. This is here so that an address cannot spend its same coins multiple times in parallel blocks - the double-spending problem - most importantly the fees, so that a creator of a block can be sure that the transactions included will bring fees.

In our first iterations of the testnet without smart contracts, we implemented a ledger that keeps track of the balance of each address at each particular block (after the execution of the block and all its ancestors).
This ledger allows the creator of a future block to decide which transaction can be included in the block and be sure that the (inclusion) fees will be paid to itself. For each transaction, the creator of block B basically looks in the ledger if the sender has enough coins in the ledger of the parent of B in the same thread as B to pay the amount and fees, and that those coins have not been used before in other transactions in B.

Keeping track of a ledger after the execution of each block (and its own ancestry) seems not to be the only way to allow the block creator to be sure to get the fees paid.
A ledger associated to a blockclique instead of a block seems to be also a valid way.
This approach allows to update a unified ledger with the virtual machine from both classical transactions and smart contracts operations.
The machine can process all operations in a sequential order irrespective of block parents, but depending on the block slots: operations in a later slot will be processed after operations of an earlier slot, and operations late in a given block will be processed after transactions earlier in the block.

Blockclique Consensus

This module computes the best clique of compatible blocks (the blockclique) and the final blocks.
It needs the block headers that are valid for all concerns other than graph-related.
It does not need the operations as a block can be valid even if some operations are not.
It gets the block headers from the Communication module or the Store (question of implementation).

Virtual Machine

The virtual machine sequentially processes the operations and updates a ledger.

The updated ledger is composed of those entries: (address, sequential balance, parallel balance, rolls, code, data).

This module provides a view of:

• the sequentially-final ledger and its timestamp: the ledger that for sure cannot be reversed,
• the active ledger: the ledger computed with all the latest received blocks, but that can be reversed.

The processing of operations for the active ledger can go back in time.
In the next figure, block red is received and processed after block blue, so the VM goes back to before block blue, processes the operations of block red and then blue again.

If a node has not enough CPU to always compute the latest ledger, it can compute only the final ledger which cannot go back, or something in between.

PoS Selection

Staking

[massa-bot]

In GitLab by @AureliaDolo

@sebf you can use mermaid for you diagrams :)

[AureliaDolo]

@sebastien-forestier @qdrn @damip have you made some progress on that ?

[damip]

yes, there is a new vision on it that we will discuss for the refactoring of episode 7

[AureliaDolo]

By of episode 7, you mean that should be ready for testnet 7 release or that we will start after that release ?

Is there a roadmap somewhere ?

[damip]

we'll try to have it for the launch of ep7

[AureliaDolo]

The roadmap or the vision ?