Massa / wasm execution interface

[adrien-zinger]

We want to be flexible about the choice of the engine and furthermore split the R&D about wasm execution / memory sharing between engines.

So we can develop in modules / crate or repository several solutions that respect an interface.

For the moment I plugged this interface that I defined in cautious_bassoon, note that this interface is not the ABI but it should be called by. For example, the get_module is called by the call abi (go to impl). We can discuss about the naming of these function keeping in mind that it's too easy to be confuse while we're speaking of ABI..Interface..Syscall.

pub struct Interface {
    pub get_module: fn(address: &Address) -> Result<Bytecode>,
    pub update_module: fn(address: &Address, module: &Bytecode) -> Result<()>,
    pub create_module: fn(module: &Bytecode) -> Result<Address>,
    pub get_data: fn(address: &Address, key: &str) -> Result<Bytecode>,
    pub set_data: fn(address: &Address, key: &str, value: &Bytecode) -> Result<()>,
    pub get_time: fn() -> Result<Instant>,
    pub get_random: fn() -> Result<u64>,
    // ... etc.
}

(go to implementation example in massa)

I think it's to much but we could have a get_module_for_call function and a get_module_for_something_else to track in massa what's happening.

The function in the interface should be implemented in massa and called by the external module.

To run the smart contract, I choose to provide a simple entry point called run for each operation. As well as the VM object in massa track the context and let the execution running and calling the interface if needed.

let run_result = assembly_simulator::run(module_wasm, operations_limit, interface);

(go to usage example in massa)

The run_result is a Result object that contain the remaining points after the operation. We can also talk about the entry point if needed.

[adrien-zinger]

@gterzian @damip @AureliaDolo @yvan-sraka

[yvan-sraka]

I think that's neat ✨! Maybe a doc comment on each fn pointer required could be nice :)

[gterzian]

The main concept that I would like to introduce is to merge the current ExecutionContext with the proposed Interface, where the context would be the data used by the interface.

Then both assembly_simulator and VM can own a shared ref to this interface/context, and call methods on it that would mutate it's state/read state in a thread-safe way.

Also, have you considered making Interface a trait, one that would be implemented by a struct in massa, that way we can actually hide the use of the ExecutionContext from assembly_simulator?

I have a few more comments which I'll make on the PR directly.

[adrien-zinger]

The main concept that I would like to introduce is to merge the current ExecutionContext with the proposed Interface, where the context would be the data used by the interface.

The ExecutionContext is a concept that is own by massa node, which we prefer to not define in runtime-sc, but used in the implementation of the functions defined in the library:

massa/massa-execution/src/interface_impl.rs

Lines 11 to 25 in 53d26b7

	lazy_static::lazy_static! {
	pub(crate) static ref INTERFACE: Interface = Interface {
	get_module: |address| {
	let bytecode = Runtime::new().unwrap().block_on(async move {
	let context = CONTEXT.lock().unwrap();
	context.ledger_step.get_module(&Address::from_str(address).unwrap())
	});
	match bytecode {
	Some(bytecode) => Ok(bytecode),
	_ => bail!("Error bytecode not found")
	}
	},
	..Default::default()
	};
	}

Then both assembly_simulator and VM can own a shared ref to this interface/context, and call methods on it that would mutate it's state/read state in a thread-safe way.

We thought that a context isn't easy to share between executable. @damip what do we want?
The purpose of another repository is to create a simulator/boilerplate 🍝 for users to play with a fake ledger that doesn't share any contexts. A read-only execution can always be processed in massa.

Also, have you considered making Interface a trait, one that would be implemented by a struct in massa, that way we can actually hide the use of the ExecutionContext from assembly_simulator?

Yes we tried to use traits first but we had a lot of lifetime conflicts. It was a real hard problem and we were resigned to choose this design 😄

[damip]

The execution context needs to be available to the "syscalls" when they are executed... It needs to also be emulated in some way in the simulator. Example: if the smart contract wants to know the call stack.

[adrien-zinger]

The execution context needs to be available to the "syscalls" when they are executed... It needs to also be emulated in some way in the simulator. Example: if the smart contract wants to know the call stack.

It's obviously possible with a "get_callstack" function in the interface

[gterzian]

Ok, I will open a PR on @adrien-zinger's one to make my proposal clearer.