add some notes about JIT compilation issues #99
Conversation
cdetrio
changed the title
|
Wasm is of course designed such that reasonably optimized machine code can be generated in n log n time. And it can be generated with a simpler compiler than usual. So I don't think it's too much of a stretch for high-performance clients to provide at least a minimal compiler. Wasm's design also makes high-speed interpreters possible in system-level languages like C and Rust, so compilers aren't the only option. |
|
|
||
| * adopting any of these JIT engines would be easy -- just pull one off-the-shelf and it will work out of the box. But they're super complex machines, with massive codebases, so unless you are an expert in how JIT compilers work, they're essentially black boxes. | ||
|
|
||
| * the problem is, what if wasm JIT engines are vulnerable to DoS attacks? Running most contracts is fine because the JIT compilation happens very fast (e.g. a few milliseconds), then execution happens fast (say 100 milliseconds). But some contracts could be exploits which take the JIT engine a very long time to compile: "compiler bombs" or "JIT bombs". |
There was a problem hiding this comment.
When designing the gas cost, I think I would ask "what is the gas cost we should use for the most efficient (theoretically) way to execute the code?". I think this disincentivizes using less-performant ways of implementing. Surely will be some error in figuring out the mos theoretically efficient way though.
|
|
||
| * adopting any of these JIT engines would be easy -- just pull one off-the-shelf and it will work out of the box. But they're super complex machines, with massive codebases, so unless you are an expert in how JIT compilers work, they're essentially black boxes. | ||
|
|
||
| * the problem is, what if wasm JIT engines are vulnerable to DoS attacks? Running most contracts is fine because the JIT compilation happens very fast (e.g. a few milliseconds), then execution happens fast (say 100 milliseconds). But some contracts could be exploits which take the JIT engine a very long time to compile: "compiler bombs" or "JIT bombs". |
There was a problem hiding this comment.
Not sure the solution is a "bomb sniffing contract", as much as a "general way of specifying protocol level details as system contracts". Either way, it would be something that needs to have consensus on it (as all the software/hardware evolves around it), so would be good to be able to modularly insert such contracts.
There was a problem hiding this comment.
Sorry, bad at github (not sure how to promote this to top-level comment).
JIT_compilation_issues.md
Outdated
|
|
||
| * Some people's opinion is that a system based on metered AOT would be a big PITA. It would require implementing a new wasm AOT compiler, or adapting an existing wasm engine, adding metering, and then requiring clients to maintain a directory of compiled binaries. From the point of view of a compiler expert, this may not sound like such a big deal. But from the point of view of an average Ethereum client developer, it sounds like a lot of development effort. | ||
|
|
||
| * one way to explain to an average Ethereum client developer how metered AOT might work, is to say: take something like WAVM, and adapt it to do AOT compilation rather than JIT (we'll just call this WAVM). Then take WAVM and compile it to wasm (call it WAVM-as-wasm), and inject metering into that wasm (i.e. inject metering into WAVM-as-wasm). Then the Ethereum client will run this "WAVM-AOT-metered-compiler" whenever a user deploys a new wasm contract. |
There was a problem hiding this comment.
I'm not sure I'm following...
What output this compiler will provide? I guess it should provide machine code for the native platform. But that means at least one part of the compiler will be executed differently for different platforms. Thus the gas usage will be platform dependent, right?
|
|
||
| * Some people's opinion is that a system based on metered AOT would be a big PITA. It would require implementing a new wasm AOT compiler, or adapting an existing wasm engine, adding metering, and then requiring clients to maintain a directory of compiled binaries. From the point of view of a compiler expert, this may not sound like such a big deal. But from the point of view of an average Ethereum client developer, it sounds like a lot of development effort. | ||
|
|
||
| * one way to explain to an average Ethereum client developer how metered AOT might work, is to say: take something like WAVM, and adapt it to do AOT compilation rather than JIT (we'll just call this WAVM). Then take WAVM and compile it to wasm (call it WAVM.wasm), and inject metering into that wasm. Then the Ethereum client will run this "WAVM-AOT-metered-compiler" whenever a user deploys a new wasm contract. |
There was a problem hiding this comment.
Duplicating my comment here since it seems like might get lost with previous commit:
I'm not sure I'm following...
What output this compiler will provide? I guess it should provide machine code for the native platform. But that means at least one part of the compiler will be executed differently for different platforms. Thus the gas usage will be platform dependent, right?
There was a problem hiding this comment.
Just to clarify:
- This AOT compiler should emit native code (otherwise it wouldn't be useful).
- I'm assuming that the ethereum node can be run on different platforms (e.g Aarch64 and x86-64).
- I'm assuming that AOT compiler will execute different code path in order to produce native code for Aarch64 and x86-64.
4.So it will spend different amount of gas to produce native code depending on the platform, thus it's not deterministic.
There was a problem hiding this comment.
I think one of the discussion points were that the AOT would generate bytecode for all supported architectures at the same time and as such it would be deterministic. It is super inefficient though.
There was a problem hiding this comment.
or just meter the generation of machine code for one target "reference architecture" (eg. x86-64). Then if a client is running on a different architecture (i.e. Aarch64) it would be 2x less efficient, but that's fine. The point isn't to have actual execution costs perfectly match the calibrated gas costs. Just to be "good enough" to prevent DoS attacks.
There was a problem hiding this comment.
Wouldn't it be possible to devise architecture-specific bombs? i.e. a contract that passes the test for x86-64, but would explode on Aarch64?
No description provided.