https://drive.google.com/drive/folders/1Jx82eFFoYAwhv5W9_lGzMphKYNap-X6f?usp=drive_link
Solution overview: Create a new, additional VM with a tighter set of FFIs (host interface, i.e. WASM). Deploys that do NOT depend on CLTypes crate are sent to EE, which executes the correct VM. A new set of contract APIs (FFI wrappers in the EE interface, called by smart contracts) The existence of multiple VMs is transparent outside of EE. This is not in scope for 2.0 at the moment.
- Add (new) VM2 (non-CLTypes based FFIs)
- add a new field to deploys to identify VM target, Default to VM2, but can specify VM1
- Update EE test framework to call VM2 and run tests similar to tests for existing VM1
- Migration: lazy migration: when a deploy is sent, install the contract on the new VM and then migrate data to new (non-CL based types). Then migrate the data.
VM 1.0 will be deprecated in the next major release version, removed in major release version next+1; Contracts will be pruned from history similar to EraSummary.
CLValue: keep as is in VM1.0; VM2.0 - remove all nested all nested types (map, result, tuples). Use of nested types forces clients to be overly complicated and confusing to write.
https://drive.google.com/drive/folders/1Jx82eFFoYAwhv5W9_lGzMphKYNap-X6f?usp=drive_link
Solution overview: Create a new, additional VM with a tighter set of FFIs (host interface, i.e. WASM). Deploys that do NOT depend on CLTypes crate are sent to EE, which executes the correct VM. A new set of contract APIs (FFI wrappers in the EE interface, called by smart contracts) The existence of multiple VMs is transparent outside of EE. This is not in scope for 2.0 at the moment.
VM 1.0 will be deprecated in the next major release version, removed in major release version next+1; Contracts will be pruned from history similar to EraSummary.
CLValue: keep as is in VM1.0; VM2.0 - remove all nested all nested types (map, result, tuples). Use of nested types forces clients to be overly complicated and confusing to write.