Open Stebalien opened 2 years ago
I am surely lacking some context so please bear with me :pray:
The goal here is to make it possible to validate the chain without having to "update" every client for every new precompile. For most clients (i.e., not miners) slightly slower chain verification is fine.
Isn't it a problem if you allow to have different implementations that can be 10x slower with respect to gas ? Like a tx should pay less gas with an optimized assembly operations (i'm thinking cryptographic operations here, like verifying a SNARK)
The network would specify the gas costs based on the optimized (assembly) "reference" implementation.
Some operations (again, cryptographic operations) may only make sense with optimized assembly operations, and will likely just be "too slow" to run on wasm.
For the lowest-level building blocks, yes, for now. But I also expect WASM extensions like SIMD and improved compilers to reduce the need for this over time.
Do i understand right that if that is the case, the whole network will agree on using those assembly implementations ?
No. The network would agree on a WASM module implementing the algorithm and on "standard" gas price for the operation based on some "reference" assembly implementation for some reference hardware.
The EVM has two features to allow extension with native code, usually for performance:
In Wasm, we have two options:
Given that we're planning on allowing deployed Wasm modules to import other deployed Wasm modules, option 1 likely makes the most sense.
However, we can take this even further. Given that LLVM can compile Wasm to native code, we can:
Importantly, this means promoting a library to "native" doesn't require a full network upgrade. At worst, some implementations may start syncing more slowly if they don't follow steps 3 & 4. However, even an implementation running 10x slower should be able to stay in sync.