Modular architecture with full account abstraction

[damip]

Modular architecture with full account abstraction

Intro

In this concept architecture, the concept of native Massa token is removed and only ERC-20 like tokens exist, with full native account abstraction. The architecture is split in three main parts:

• the Service Provider that can be asked to perform some tasks such as adding an Operation to the consensus in exchange for some rewards coming either from the outer world, or from within the execution of the operation itself.
• the Consensus module takes blocks as input and outputs a list of timestamped items such as block creation, operation to execute etc... It manages a roll registry matching addresses to the number of rolls they have.
• the Execution module consumes the timestamped items produced by Consensus and takes them into account into the smart contract realm. When the smart contracts are executed, they can emit events that are sent to the Service Provider. This module also executes autonomous SCs and manages a ledger associating each account name to a key-value datastore.

Architecture elements

The Service Provider

The Service Provider exposes an API and has multiple plugins. Someone can ask the Service Provider to perform a given task in exchange for a payment in the outside world or through an internal mechanism.

One of the requests that can be sent to the Service Provider is to execute an Operation in the smart contract realm.

An Operation is a vector of bytes. It is not signed.

When the Consensus modules notifies the Service Provider of an opportunity to include Operations in a block being created, the Service Provider sends the Operations it desires to include.

If a Service Provider misbehaves, users will avoid that Service Provider in the future (local reputation).

The Consensus module

The Consensus module handles block production, and exchanges blocks with other nodes using a P2P system. When consensus is achieved, the module emits a history of timestamped items using a standardized format:

• (timestamp1, item1)
• (timestamp2, item2)
• ...
  Those items can be block creation, operations to execute, roll changes.

Consensus uses simple bitcoin-style addresses based on digital dignature keypairs, and does not interpret the content of Operations, except the RollTransfer operation.

The consensus module handles the Roll Registry associating addresses (hash of pubkey) to how many rolls that address has.
All rolls are always in the possession of staking addresses. There are no RollBuy/RollSell operations but only signed RollTransfer operations allowing one address to sign the transfer of some of its rolls to another address. When a staker doesn't produce blocks when selected to do so, its rolls are progressively randomly redistributed to other stakers.

The Execution module

The Execution module handles a ledger that associates an account name string (eg. "myaccount") to:

• its binary key-value datastore where each entry has the following:
  • key: a 0 to 256-byte binary key
  • value: a binary vector of arbitrary size
• a list of bytecode hashes that are allowed to be executed within the context of that account

The Execution module runs a VM that executes Operations that are meant for it.

An Operation is anonymous: it has no signature nor owner but only contains a max_gas field and bytecode to execute.

Account creation/deletion is a smart contract ABI.

There is no Call ABI but there is an "ExecuteAs" ABI that takes bytecode to execute, an account name in which context we want to execute, a function name of that bytecode to call, and arguments to be passed to this function, and attempts to execute the bytecode in the context of the target account. This only works if the bytecode is in the list of bytecode hashes allowed for execution by the target account, or any bytecode if called in the context of the target itself.

The Execution module runs on its own time and can execute things without necessarily following the consensus slots.

Modularity

Note that because of this modular architecture and standardized interface, the Consensus module can be replaced by any other system allowing to inject arbitrary bytes and output them in a deterministic consensual orderly and timestamped fashion (the module can be Bitcoin itself !). One or multiple consensus modules can feed one or multiple Execution modules.

Recreating existing concepts

Examples that give an intuituion on how existing concepts can be recreated in this alternative architecture without ever being hardcoded in the consensus. Everything is done in the smart contract realm !

Externally owned accounts

There is no concept of externally owned account in the SC realm.

The only way to interact with an account is through exported functions of the bytecodes allowed for execution by that account.

To emulate an EOA, let's say that one of the bytecodes allowed by the damir account (and stored in its datastore under the name proxy_eoa) has a generic execute_bytecode_with_auth(bytecode, func, params, nonce, signature) exported function that allows its owner to execute arbitrary instructions in its name:

export function execute_bytecode_with_auth(bytecode, func, params, nonce, signature) {
  // check nonce to prevent operation reuse
  if get_current_account().datastore.get("nonce") + 1 != nonce {
    abort("incorrect nonce");
  }
  // check signature
  if not verify_signature(bytecode + func + params + nonce, signature, get_current_account().datastore.get("public_key")) {
    abort("incorrect signature");
  }
  // execute
  result = ExecuteAs(get_current_account().name, bytecode, func, params)
  // update nonce
  get_current_account().datastore.set("nonce", nonce);
  return result;
}

Thanks to this approach, the owner of the account damir can call something by executing an Operation (remember that operations are not signed and they are anonymous) with the following code:

bytecode = /* bytecode to execute as damir */;
func = /* function of that bytecode to call */;
params = /* parameters of the call */;
nonce = /* nonce of the call */
signature = /* signature of the previous variables by the private key of the EOA */
ExecuteAs(
  "damir",
  get_account("damir").datastore.get("proxy_eoa"),
  "execute_bytecode_with_auth",
  [bytecode, func, params, nonce, signature]
);

Note that thanks to the ExecuteAs concept, the accounts using the proxy_eoa bytecode don't necessarily need to store it, it can just be stored once elsewhere and simply hash-authorized by all accounts that want to support it.

The ERC20 smart contract for the massa token

There is no native token. But the Massa token is an ERC20-like in the smart contract realm.

The token holds a map of account names to the amount of tokens they have.
It exposes a transfer function that allows the account at the top of the call stack (if any) to transfer its tokens to any other account.

Block rewards

The Massa ERC20 token exposes a mint function that allows an arbitrary amount of tokens to be minted by anyone and transferred to an arbitrary account with a limit of X tokens per 500 millisecond timeslot. This function can be called by the block producers at the top of their block to mint new block rewards and distribute them to their accounts.

Paying fees to block producers

Every operation that a user asks a Service Provider to execute should also atomically credit the Service Provider with some reward, typically an ERC20 token. If the block producer is not satisfied with the results of simulating the execution of the operation, they won't execute the Operation.

Buying/selling rolls

Since the Consensus realm is separate from the smart contract realm, buying rolls from someone that can be done in the following way:

• the buyer deposits 100 Massa ERC20 tokens in a contract that is time locked for 5 minutes and sends the coins to the account of the seller if it can read that the buyer's consensus address now has the desired number rolls
• the seller sees that the SC is enabled and does the following two steps in the same block:
  • transfers some of its rolls to the buyer
  • claims the tokens locked in the smart contract

Paying for storage

Storage is limited to 1TB (any further writes will fail). However storage is free in this architecture.

To emulate storage fees, a storage smart contract can be created that does the following:

• it initially occupies almost 1 terabyte with random data (minus the space used by the initial accounts). This is also nice because it forces all node runners to have 1TB of disk space right away
• when the SC receives Massa ERC20 tokens, it locks them and frees space proportionally
• when it is asked for locked Massa ERC20 tokens, it reallocates space in its datastore and sends the tokens to the claimer

[dr-chain]

@damip The features explained above seem very desirable! Have we decided something on it yet?

[damip]

Too late for mainnet, we'll look into it later