Why is NEAR using Singlepass compiler

[MaksymZavershynskyi]

Reposting from @bowenwang1996 's message in Slack:

Why exactly did we choose to use wasmer singlepass backend? iirc there were two reasons:

• Singlepass is faster than other backends that loop through the code multiple times
• There are certain “compiler bombs” that we would like to avoid.

However, given that we have now moved compilation to deployment time, the first one wouldn’t really be a concern since we only do it once for a contract. For the second issue, I wonder whether we can come up with some approximate way of measuring compilation cost. It doesn’t have to be precise but needs to be deterministic. If we can do that, we can abort the compilation if the cost exceeds some threshold. Then it seems to me that we can just move to llvm backend and get a 5-10x performance boost. What do you think?

[bowenwang1996]

Thanks @nearmax for reposting this. cc @olonho

[MaksymZavershynskyi]

The 2nd one is the real problem. We want our protocol to be implementation- and platform-independent. If we find a way to introduce a hook/callback into LLVM and deduct certain fixed fee every time this hook/callback is called, then we will basically encode the specifics of LLVM compiler into our protocol. We want be able to move to other compilers, like Cranelift, because hooks/callbacks in Cranelift will correspond to different types of operations with different CPU costs. There is no compiler-agnostic way of measuring the steps that compiler takes and therefore we don't want them to be encoded in our protocol.

There are also other arguments:

• We want blockchain code to be as simple as possible, and LLVM is very complex and low-level, so it is going to be harder to have a guarantee that it is somehow not exploitable. E.g. is it possible to trick LLVM to crash a node or to eliminate gas_counter calls making the contract virtually free? Compared to LLVM, Singlepass is orders of magnitude simpler. Some blockchains take a more radical approach and say that any compiler is too complex for them. E.g. that was the reason why Substrate was using Wasmi (interpreter) and is still using as a default for trustless execution.
• There are certain benefits of single-pass or streaming compilers. E.g. it might be technically possible to execute signlepass compiler in parallel with gas counting code injection, instead of doing it sequentially like we are doing it right now. That's how Wasmer's gas counting implementation works, but we are not using it.

[MaksymZavershynskyi]

LLVM however can be used for Wasm code that is not gas metered at all. E.g. if we whitelist EVM contract and remove gas counting from it entirely, then we will be able to run it with LLVM. However that will require a protocol change where we would introduce a set of EVM-specific fees into Runtime config. Fees are in general laborious to calibrate correctly so we should stay away from this option.

In general, my understanding of why we have part of EVM in Wasm is the following:

• It allows us to easily iterate on EVM without protocol change or node upgrades;
• We can hide stuff like JSON parsing in it.

At some point EVM is going to be sufficiently stable, once it is the case, we can move out large part of EVM functionality outside Wasm and only leave things like JSON parsing in it.

[olonho]

Probably to understand the real performance implications of LLVM vs Single pass we need to measure it. At the first glimpse it seems that actually execution is dominated by various bootstrap factors (fetching/deserialization of contracts, VM start and such). Once near/nearcore#3985 will get into shape we'll see how it works when we preload all block contracts before execution.

[MaksymZavershynskyi]

I suggest to not invest too much time into LLVM. Switching from Singlepass to LLVM will not decrease gas cost of the contract call and so it will not increase TPS. The reason why LLVM will not decrease regular_op_cost is because it should correspond to the worst case scenario, i.e. the one where LLVM optimizations do not help it to be faster than Singlepass.

[evgenykuzyakov]

I think the original problem was the time to compile. We can issue a common transaction (e.g. for lockup contract) that includes account creation, deposit, contract deployment and later function call to initialize.

If contract deployment doesn't complete fast enough, then we can't initialize the contract because it's blocked by the compilation.

Let's say we fist compile with singlepass and later compile with LLVM in a background (as an optimization). The protocol fees will still have to reflect singlepass compilation costs and also function call costs of running a singlepass contract. This means we'll not get nominal TPS increase on the chain, but instead only will get nodes with less load.

[MaksymZavershynskyi]

I agree, the protocol fees will correlate with Singlepass compiler even if LLVM was fast to compile, because we need to charge per Wasm operation. So if LLVM finds a way to collapse and optimize out some Wasm operations it won't reflect on the fees.

[bowenwang1996]

Good point re. protocol fees. I think there is still value in making things faster without changing the fees, although this is much less important comparatively.