Clarify Execution call stack

[adrien-zinger]

Introduction to the interface

When executing a byte code with the runtime, the massa-execution module keep a trace of a kind of call stack in his context. With this discussion, I want to prepare a specification of how the node work with the call stack.

First, here is a presentation of the current interface with the runtime:

    fn get_module(&self, address: &String) -> Result<Vec<u8>> {}
    fn create_module(&self, module: &Bytecode) -> Result<assembly_simulator::Address> {}
    fn get_data_for(&self, address: &assembly_simulator::Address, key: &str) -> Result<Bytecode> {}
    fn set_data_for(
        &self,
        address: &assembly_simulator::Address,
        key: &str,
        value: &Bytecode,
    ) -> Result<()> {}
    fn get_data(&self, _key: &str) -> Result<Bytecode> {}
    fn set_data(&self, _key: &str, _value: &Bytecode) -> Result<()> {}

We bound these 6 functions with the runtime module, and the function's names are currently explicit enough to understand when it's called. Now, we all know the current status of the interface implementation and I can make a supposition of how the context would work. Before the implementation, it would be nice for all the team to be aware of that.

The call stack 👜

Call and pop the call stack
The call stack has a new entry for each call of call abi and is pop after the execution.

For developers:
As implemented now, the call stack is managed in massa-execution module. So we push at a call of get_module and we pop with a call of exit_success function to implement in the interface. In a next version, the call stack will be managed directly inside the runtime.

Read and write accesses

The get and the set
A user has access through an ABI to the ledger and can get a module. On calling set_data and get_data the massa-execution module should know where it has to look and never fail to look. For example, imagine a smart contract who grant the access to his own data. It can be an open source Pokédex where all user can add and update an entry:

The getter and setter function represented and implemented in the interface in massa-execution module should always look at the last address in the call stack. The smart contract developer will define itself if the data is public or not with his own development.

// pokedex.ts
import { JSON } from "json-as";
import { Pokemon } from "./pokemon_lib";
import { get, set } from "./massa";

export function get_pokemon(name: string): string {
  return JSON.stringify<Pokemon>({name, type: get(name)});
}

export function add_pokemon(pokemon: string): string {
  let p = JSON.parse<Pokemon>(pokemon);
  set(p.name, p.type);
  return `A Pokemon type ${p.type} added... ${p.name}!`;
}

In the current smart contract, the call of get and set can have access to the smart contract database. Developing a smart contract, you may be careful because you can give access to the users to write on your own private data.

⚠️ How to limit access to some user addresses?
Normally, the call stack would allow you to know the operation sender address. Hypothetically, we could create a new ABI for the user >to get this address whats_my_address() which may return a string formatted base58 address.

export function give_access(address: string): string {
 if (whats_my_address() == '5G5KEdvHqn') {
    // In a next version we could provide some tools to append, pop and parse entries
    let admins = JSON.parse<string[]>(get('admins'));
    admins.push(address);
    set('admins', JSON.stringify<string[]>(admins));
 }
 return 'Cannot add an access';
}

export function add_pokemon(pokemon: string): string {
 let admins = JSON.parse<string[]>(get('admins'));
 let addr = whats_my_address();
 if (admins.contains(addr)) {
   let p = JSON.parse<Pokemon>(pokemon);
   set(pokemon, p.name, p.type);
   return `A Pokemon type ${p.type} added... ${p.name}!`;
 }
 return `Sorry you can't write here with the address ${addr}`;
}

---

The get_for and set_for behavior

The getter with a given address get_data_for can see everywhere. The nature of the publicity in the blockchain allow everyone to look at the data at a given address in the ledger. But when we execute set_data_for we need to understand in the context of execution if the sender is currently an owner of the address.

The sender is by definition the owner of his own address. For example, you can define a smart contract that feed with information to a private database.

// write_hello_smart_contract.ts
export function hello(name: string): string {
  let address = whats_my_address();
  set_for(whats_my_address(), 'hello', `hello ${address}`);
  return 'hello writen in the \'hello\' entry';
}

Calling this smart contract will cause changes on your own database. If you call this smart contract, the context understand that you're the sender and the owner of your own database. Then, whats_my_address function will return the sender address. Finally, the set_for will attempt to write on the current sender address database. This last operation will successfully write because the context understand that you have the access to the DB as owner.

The other way to be the owner of an address is to create a smart contract. During the execution, the context will keep the new addresses created in a set.

struct context {
  owner: [`sender_address`, `smart_contract_1`, `...` ],
}

The set_data_for function of the interface should look first if this list contains the target address before writing, or return an access error. You'll be able to set up your smart contract, like in this example:

//create_zoo.ts
import { set_for, call, include_base64, create_sc, print } from "./massa";
import { JSON } from "json-as";
import { Animal } from "./animal_lib";

export function main(_arg: string) {
    let bytecode = include_base64("./zoo.wasm");
    let addr = create_sc(bytecode).address;
    for (let i = 0; i < 50; ++i) {
        let animal = JSON.parse<Animal>(call("animal_randomizer", "generate", ""));
        set_for(addr, animal.name, animal.sound);
    }
    print(`Just created my new zoo: ${addr}`);
    return 0;
}

Call a module with a context
I would like to make a proposal, as well as a smart contract can be added and modified, the execution should be able to call a module with a given context. We can define these:

// Interface with the runtime in rust
/// Change the context since a pop of the module get 
fn get_module_with_context(&self, context: &String, address: &String) -> Result<> {}
/// Change the context since a pop of any module in the callstack
fn bind(&self, context: &String) -> Result<> {}

And give this ABI to the user:

default export function call_module_with_context(
  context_address: string,
  module_address: string,
  function_name: string,
  parameters: string
);
default export function bind(address: string);