Make Evm a part of the supported virtual machines. #3386

MathieuDutSik · 2025-02-21T11:50:00Z

Motivation

We extend here the support for EVM. This requires no longer making the virtual machine
a feature of the storage but instead a part of the BytecodeId.

Proposal

The following changes have been done:

A type VmRuntime has been introduced that covers both Wasm (Native linera) and Evm.
The VmRuntime is added to the BytecodeId. This is a reasonable way to make the VM a part of the type description.
We cannot put the VmRuntime in the UserApplicationDescription since this forces the create_application to have a VmRuntime type. While innocent, this changes is not adequate since the create_application is used in smart contract code and we want to avoid this part to seep into the smart contract code.
The VmRuntime, does not depend on any feature. This is because they have to pass the wit barrier and the wit-types cannot depend on features.
The VmRuntime has been added to the linera-base. This is unavoidable because BytecodeId depends on it.
The load_contract/load_service is simplified into one single code that panics when relevant features have not been installed.
The --vm-runtime is added to the function calls like publish_application. When missing it defaults to VmRuntime::Wasm.
The default_with_stabilizer is eliminated since it is not used.
A typo in contract_runtime_apis.rs for ApplicationDescription is corrected.

Test Plan

The CI. No test has been added to test the functionality.

Release Plan

Normal release plan.

Links

None.

Integrate the VM type to the BytecodeId.

CLI.md

linera-base/src/vm.rs

…execution.

ma2bd · 2025-02-23T17:31:38Z

linera-execution/src/test_utils/mod.rs

@@ -47,9 +48,14 @@ pub fn create_dummy_user_application_description(
        compressed_bytes: b"service".to_vec(),
    });

+    let vm_runtime = VmRuntime::default();


nit: just inline the value

ma2bd · 2025-02-23T17:35:21Z

linera-base/src/identifiers.rs

@@ -350,6 +351,8 @@ pub struct BytecodeId<Abi = (), Parameters = (), InstantiationArgument = ()> {
    pub contract_blob_hash: CryptoHash,
    /// The hash of the blob containing the service bytecode.
    pub service_blob_hash: CryptoHash,


@afck @jvff Should we make the service blob optional?

Maybe, if so it would have to be in a separate PR I think.

Yes, I think that makes sense. Or even something like:

pub enum BytecodeId { Wasm { contract_blob_hash: CryptoHash, service_blob_hash: CryptoHash, }, Evm { bytecode_hash: CryptoHash, }, }

Or even just have one blob per bytecode, which for Wasm could either be:

a tar archive with the contract and the service together,

a blob index listing which blobs make up the contract and which ones make the service

The latter would allow for larger applications, and could store the VM runtime inside the blob itself 🤔

We can discuss to decide on an alternative and implement it in a separate PR.

I like this approach ^^, even if this may create bit more boilerplate. @afck What do you think?

I like the tar idea; except I wonder whether it creates a lot of overhead if we have to always load both bytecode modules even if we use only one.

ma2bd · 2025-02-23T17:45:02Z

linera-sdk/wit/service-system-api.wit

    record bytecode-id {
        contract-blob-hash: crypto-hash,
        service-blob-hash: crypto-hash,
+        vm-runtime: vm-runtime,


@afck @jvff I'm worried that we expose too much detail about BytecodeID (and generally applications) to the SDK. Then, we will have to maintain them for ever.

Perhaps, this BytecodeID could be a hexadecimal string. Alternatively, we could also remove create_application for now.

Maybe we could change. But in another PR.

I agree that it's not ideal and will make adding new runtimes harder because it will always require changing the WIT interface.

I'm starting to lean more towards having a single bytecode blob with metadata including the VM runtime and pointing to the actual blobs to form the bytecode.

But yeah, it doesn't have to be done in this PR.

ma2bd · 2025-02-23T17:45:55Z

linera-client/src/client_options.rs

@@ -773,6 +774,10 @@ pub enum ClientCommand {
        /// Path to the Wasm file for the application "service" bytecode.
        service: PathBuf,

+        /// The virtual machine runtime to use.
+        #[arg(long)]
+        vm_runtime: Option<VmRuntime>,


nit: We could also handle the default here.

You are correct, thank you.

ma2bd · 2025-02-23T17:48:42Z

linera-execution/src/lib.rs

@@ -1344,19 +1344,6 @@ pub trait WithWasmDefault {
 }

 impl WasmRuntime {
-    #[cfg(with_wasm_runtime)]
-    pub fn default_with_sanitizer() -> Self {


Why? Is this unused?

ma2bd · 2025-02-23T17:54:06Z

@MathieuDutSik LGTM. I believe you need to update the summary. Letting someone else accept for good

jvff · 2025-02-25T13:42:59Z

linera-base/src/identifiers.rs

@@ -350,6 +351,8 @@ pub struct BytecodeId<Abi = (), Parameters = (), InstantiationArgument = ()> {
    pub contract_blob_hash: CryptoHash,
    /// The hash of the blob containing the service bytecode.
    pub service_blob_hash: CryptoHash,


Yes, I think that makes sense. Or even something like:

pub enum BytecodeId { Wasm { contract_blob_hash: CryptoHash, service_blob_hash: CryptoHash, }, Evm { bytecode_hash: CryptoHash, }, }

Or even just have one blob per bytecode, which for Wasm could either be:

a tar archive with the contract and the service together,

a blob index listing which blobs make up the contract and which ones make the service

The latter would allow for larger applications, and could store the VM runtime inside the blob itself 🤔

We can discuss to decide on an alternative and implement it in a separate PR.

jvff · 2025-02-25T13:45:57Z

linera-base/src/identifiers.rs

@@ -674,10 +690,15 @@ impl<'de, Abi, Parameters, InstantiationArgument> Deserialize<'de>

 impl BytecodeId {
    /// Creates a bytecode ID from contract/service hashes.
-    pub fn new(contract_blob_hash: CryptoHash, service_blob_hash: CryptoHash) -> Self {
+    pub fn new(


Nit: Also need to update the documentation above, maybe with:

Creates a bytecode ID from contract/service hashes and the VM runtime to use.

jvff · 2025-02-25T13:47:14Z

linera-base/src/vm.rs

+    fn from_str(string: &str) -> Result<Self, Self::Err> {
+        match string {
+            "wasm" => Ok(VmRuntime::Wasm),
+            "revm" => Ok(VmRuntime::Evm),


Nit: I think this should be "evm", because if I understood correctly revm is an implementation of the Evm (like Wasmer is an implementation of Wasm) 🤔

Suggested change

"revm" => Ok(VmRuntime::Evm),

"evm" => Ok(VmRuntime::Evm),

jvff · 2025-02-25T14:07:21Z

linera-sdk/wit/service-system-api.wit

    record bytecode-id {
        contract-blob-hash: crypto-hash,
        service-blob-hash: crypto-hash,
+        vm-runtime: vm-runtime,


I agree that it's not ideal and will make adding new runtimes harder because it will always require changing the WIT interface.

I'm starting to lean more towards having a single bytecode blob with metadata including the VM runtime and pointing to the actual blobs to form the bytecode.

But yeah, it doesn't have to be done in this PR.

jvff · 2025-02-25T14:07:52Z

linera-storage/src/lib.rs

+                    } else {
+                        panic!(
+                            "An Evm runtime is required to load user applications. \
+                             Please enable the `revm` feature flags \


Nit: typo

Suggested change

Please enable the `revm` feature flags \

Please enable the `revm` feature flag \

jvff · 2025-02-25T14:09:36Z

linera-storage/src/lib.rs

+                        let evm_runtime = EvmRuntime::Revm;
+                        Ok(EvmServiceModule::new(_service_bytecode, evm_runtime)
+                           .await?
+                           .into())


I'm not really sure what it means to have an Evm service. We could either return an error saying Evm services are not supported, or figure out a way to query the Evm state, either exposing some read-only entrypoints or a single generic service to inspect the state.

jvff · 2025-02-25T14:09:58Z

linera-storage/src/lib.rs

+                    } else {
+                        panic!(
+                            "An Evm runtime is required to load user applications. \
+                             Please enable the `revm` feature flags \


Nit: typo

Suggested change

Please enable the `revm` feature flags \

Please enable the `revm` feature flag \

jvff · 2025-02-25T14:23:51Z

linera-storage/src/lib.rs

@@ -278,41 +280,57 @@ pub trait Storage: Sized {
        let compressed_contract_bytecode = CompressedBytecode {
            compressed_bytes: contract_blob.into_bytes().to_vec(),
        };
-        let contract_bytecode =
+        let _contract_bytecode =


Could we add an attribute instead of the underscore. The pattern is to add the underscore to unused bindings, but in this case it might be used.

Suggested change

let _contract_bytecode =

#[cfg_attr(not(any(with_wasm_runtime, with_revm)), allow(unused_variables))]

let contract_bytecode =

jvff · 2025-02-25T14:24:05Z

linera-storage/src/lib.rs

-            Please enable the `wasmer` or the `wasmtime` feature flags \
-            when compiling `linera-storage`."
-        );
+        let _service_bytecode =


Same here:

Suggested change

let _service_bytecode =

#[cfg_attr(not(any(with_wasm_runtime, with_revm)), allow(unused_variables))]

let service_bytecode =

MathieuDutSik added 11 commits February 21, 2025 12:37

Introduce the VmRuntime.

4ee42ae

Remove unused types.

237b077

Several correction from the CI runs.

a53da6e

Move the WasmRuntime / VmRuntime, etc. to linera-base.

9570014

Integrate the VM type to the BytecodeId.

Some corrections from the CI.

a931341

Two corrections from the CI.

9ac4250

Further corrections based on CI.

fadb489

Two easy corrections for the CI.

070fd17

Split the VmRuntime into blocks.

14a4e65

Change to the standard fixed by the "wit-generator".

6928d0a

Some further corrections.

f9cafb8

MathieuDutSik marked this pull request as ready for review February 22, 2025 20:41

ma2bd reviewed Feb 22, 2025

View reviewed changes

CLI.md Outdated Show resolved Hide resolved

ma2bd reviewed Feb 22, 2025

View reviewed changes

linera-base/src/vm.rs Outdated Show resolved Hide resolved

MathieuDutSik added 3 commits February 23, 2025 09:11

More back the UserApplicationDescription.

8f6a561

Revert several changes, make WasmRuntime / EvmRuntime back to linera_…

276a03f

…execution.

Correction after commit.

945287a

ma2bd reviewed Feb 23, 2025

View reviewed changes

ma2bd requested review from afck and jvff February 23, 2025 17:52

MathieuDutSik added 2 commits February 23, 2025 19:32

Changes from the Reviewing process.

30c363b

Update to the CLI.md

f51454b

jvff approved these changes Feb 25, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Make Evm a part of the supported virtual machines. #3386

Make Evm a part of the supported virtual machines. #3386

MathieuDutSik commented Feb 21, 2025 •

edited

Loading

ma2bd Feb 23, 2025

MathieuDutSik Feb 23, 2025

ma2bd Feb 23, 2025

MathieuDutSik Feb 23, 2025

jvff Feb 25, 2025

ma2bd Feb 25, 2025

afck Feb 25, 2025

ma2bd Feb 23, 2025

MathieuDutSik Feb 23, 2025

jvff Feb 25, 2025

ma2bd Feb 23, 2025

MathieuDutSik Feb 23, 2025

ma2bd Feb 23, 2025

MathieuDutSik Feb 23, 2025

ma2bd commented Feb 23, 2025 •

edited

Loading

jvff Feb 25, 2025

jvff Feb 25, 2025

jvff Feb 25, 2025

jvff Feb 25, 2025

jvff Feb 25, 2025

jvff Feb 25, 2025

jvff Feb 25, 2025

jvff Feb 25, 2025

jvff Feb 25, 2025

	Please enable the `revm` feature flags \
	Please enable the `revm` feature flag \

	let _contract_bytecode =
	#[cfg_attr(not(any(with_wasm_runtime, with_revm)), allow(unused_variables))]
	let contract_bytecode =

	let _service_bytecode =
	#[cfg_attr(not(any(with_wasm_runtime, with_revm)), allow(unused_variables))]
	let service_bytecode =

Make Evm a part of the supported virtual machines. #3386

Are you sure you want to change the base?

Make Evm a part of the supported virtual machines. #3386

Conversation

MathieuDutSik commented Feb 21, 2025 • edited Loading

Motivation

Proposal

Test Plan

Release Plan

Links

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ma2bd commented Feb 23, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

MathieuDutSik commented Feb 21, 2025 •

edited

Loading

ma2bd commented Feb 23, 2025 •

edited

Loading