Modularization of the ecalls

[bigspider]

In the current architecture, all the ecalls are in the same group, and they are only identified by a platform_id and api_level.
Using this approach is quite standard in many platforms and VMs.

I proposed to separate ecalls in different modules, each identified by a module_id and module_version.

• the VM would support a list of (module_id, module_version)
• each app's manifest would specify the required modules, and the minimal required version for that module.

The discussion was here − no consensus reached so far on an approach.

I think it's important to decide before there are many implemented and deployed apps, as adding this feature later will not be possible without breaking compatibility.

[bigspider]

Possible initial minimal specs:

The manifest would add a (possibly merkleized) list of (module_id, module_version, module_config),

Before running an app, the VM you would iterate over all elements and check if you have the module_id , with version >= module_version. Ignore module_config for now, it's a 32-byte hash which is reserved for future use.

module_id is limited to 16 bits, and within each module, each ecall would have a 16 bit ecall_id. In this way, (module_id << 16) + ecall_id is a unique 32-bit identifier for the each ecall, as long as there are no module_id collisions. This would keep changes to the ecall mechanism (generated ecall and Risc-V interpreter) minimal.