RFC: Smart Contracts Interpretor

[Eitu33]

RFC: Smart Contracts Interpretor

Introduction

The goal here is to make smart contract development easier by providing a program that acts like an interpretor and handles all the SC features handled by the node, but without having to deploy a node.

With this also comes a Visual Studio Code extension to simplify the usage of this interpretor program.

Final goal is to be able to develop smart contracts as you would develop any other classic program.

Interpretor

massa-sc-tester already implements the majority of our current SC ABI, but not everything, the following must be implemented before anything else:

1. Asynchronous messages pool
2. send_message ABI point
3. Slot range configuration for messages execution
4. Messages execution
5. Eventual minor changes to the ABI I am unaware of

Estimated work charge: 1 to 2 days

Extension

The extension allows the developper to make use of the interpretor without having to run a binary manually with multiple input arguments.

Features are:

• Run the main function with a play button that appears above its definition
• Run other functions with a play button that appears above its definition, and define the input parameters
• Define the caller address
• Define the caller coins
• Define the slot range of execution

Estimated work charge: 1 day to learn advanced code extension development, 1 day to develop the extension

Maintenance

The SC interpretor would only require an update in the following cases:

• Smart Contract ABI update (massa-sc-runtime)
• Innovation team feature request
• Builders community feature request

Discussions

Please share any features you would like to have, this is first and foremost for the smart contract end users.

[damip]

@gregLibert FYI

[sydhds]

Would be also nice to consumption metrics (per run or average cost) ?

[Eitu33]

Yeah I agree that's a great idea

[gregLibert]

It looks cool.
What is not clear to me at the moment is the advantage over using the massa-sc-std mocker library to do unit tests.

Will it be possible, not necessarily in this iteration, to :

• initialize the ledger before execution?
• recover the ledger after execution?
• duplicate the testnet/innonet/labnet ledger?
• get events ?
• do a benchmark ?
• test the autonomous SC?
• confirm that code is working in the very same Wasmer ?

[Eitu33]

@gregLibert

initialize the ledger before execution?

Yes

recover the ledger after execution?

Yes

duplicate the testnet/innonet/labnet ledger?

Not planned in the proposal, + 1 day of work

get events ?

Not planned in the proposal, + 1 day of work

do a benchmark ?

Needs another iteration

test the autonomous SC?

Needs another iteration if you are talking about unit testing

confirm that code is working in the very same Wasmer ?

Wasmer version between node and interpretor will always be the same

[qdrn]

imho it's a must have. Developing SCs is really painful otherwise.