[Discussion] Transaction runtime and Contract runtime

[maxzaver]

I propose we separate our current runtime into two projects: Transaction runtime and contract runtime.

Contract runtime

Scope

Contract runtime is going to be concerned with everything about contract execution, which includes:

Wasm execution on the host

• Wasm contract execution engine. Currently it is Wasmer+singlepass. It also includes the glue code necessary to isolate the specifics of Wasmer+singlepass, e.g. Wasmer compilation and execution error handling, memory access;
• Code preparation tools, like gas injection and static checks;
• Approaches to efficient caching of compilation

Gas metering

• Gas metering is a difficult problem on its own. How do we make it work fast while keeping safe?
• Gas fees estimation for Wasm operations is also difficult. How do we make it platform independent and non-abusable?

Host-guest interfacing

• Interfacing between guest and host. How do we pass complex structures to the contract and retrieve it from the contract;
• Contract-language specific mechanisms, like Rust and AssemblyScript glue code needed to communicate across the guest-host boundary;

Rust/AS to Wasm specifics

• Hiding the above mentioned glue-code behind the high-level interfaces implemented by Rust/AS. For Rust this is done through macros, for AS this is done through compiler hooks;
• The language-specific structure of the contract, e.g. how do we allow developers to indicate which methods are contract methods, how they will indicate what is the state of the contract, how will they perform asynchronous cross-contract calls.
• Best practices and the guidelines. We want to create the guidelines describing safe and efficient practices for compiling contracts to Wasm and optimizing their performance, size. We would need to study tools like wasm-opt, wasm-snip and draft the guidelines to on how to use them safely.

Openness

In the long-run we want our contract runtime to be void of Near-specificity and be usable by other blockchains who want to run Wasm contracts. This means the following:

• Contract runtime should not have a notion of a transaction;
• It should allow injection of any host functions;
• It should have solutions both for async and sync cross-contract call;
• It should allow various contract interfaces, e.g. Cosmwasm is using actor-like model;
• It should be very fast, very well documented, and safe so that other blockchains want to use it.

For now however, we should focus on polishing it for the Near use-case, while keeping in mind the long-term goal.

Transaction runtime

Scope

Transaction runtime is concerned with everything about transaction execution, except specifically how the contracts are written and executed. It shouldn't care, in what language the contracts are written and whether it is Wasm or RISC-V virtual machine running them. It however defines the host functions that it allows the contract to access. Besides that it includes:

• How to transform transaction to receipt, what to do with each type of action;
• Routing and storage of the receipts;
• Fee economy -- when and how we charge the fees;
• Refunds;
• Conversion of tokens to gas.
• Standalone execution.
• Interface with the state.

[frol]

I like the proposed separation. I think we should have it as our goal in the long-term. Just for the reference, I want to mention a somewhat related issue of the general nearcore project structure #1881.

[olonho]

How people think, shall we have two separate repos, or just logically restructure nearcore?

[lexfrl]

If we have a stable interface already, we can separate. We can extract it at any moment, but it's easier for integration (especially on prototyping) to have it in place for a while.

[maxzaver]

+1 to what @fckt said.