"require" helper in assembly

[axic]

It would be nice to start introducing helper functions in assembly. This was previously discussed in #474 and #1319.

A lot of contracts/libraries deal with calling precompiles directly to avoid cost overheads. They do this with if iszero(staticcall(..)) { revert(0, 0) }. It would be nice to support require and/or assert:

• require(expr) -> if iszero(expr) { revert(0, 0) }
• assert(expr) -> if iszero(expr) { invalid }

[chriseth]

Same argument I always give: Hidden library functions are hard to debug or verify. It would be much better to support importing assembly functions by source. Then it is easier to check what actually happens.

[ekpyron]

I actually think require and assert might be an exception here, though, and it might be beneficial to have them as primitive - that way we or someone could implement something like the SMTChecker for Yul that just uses them as assumptions and verification targets (ping @leonardoalt), right? We would translate require to require and assert to assert and change our reverts on a case-by-case basis, e.g. ABI decoding reverts would be require...

[ekpyron]

So for these particular two it might actually make verifying easier, if we add them...

[chriseth]

I don't see the difference to checking whether invalid is reachable or not.

[ekpyron]

As verification target maybe, yes, but for assumptions?
I'm not sure revert is used only in places where it's conceptually a require...

[chriseth]

The (one?) purpose of require/assert is that you can do bytecode-level verification.

[ekpyron]

@MicahZoltu brought this up in the chat again and there is actually another good argument for having this for requires with message.

The argument so far was that one can always just define a function, but for reverts with reason this becomes a problem. Say we define

function require(condition, message, length) {
  if iszero(condition) {
    mstore(0, <sig>)
    mstore(4, 0x20)
    mstore(0x24, length)
    mstore(0x44, message)
    revert(0, add(0x44, length))
  }
}

And then use it several times, the optimizer likely won't inline this. This results in the message being pushed on the stack needlessly when the condition is true.

Since we need builtins with mixed "required literal" and arbitrary arguments anyways for the immutables, this might be quite a good reason to introduce a require builtin...
So far I suggested to just use if condition { revertWithReason("msg", 3) } with a custom defined function revertWithReason, but that's (1) less readable and (2) inconvenient and error prone in that it requires the length to be explicitly stated.
A builtin require(condition, <requiredLiteralReasonString>) would solve those problems and could potentially conveniently allow reason strings longer than 32-bytes transparently.

[chriseth]

I don't think we should introduce a builtin function only to save 3 gas.

[ekpyron]

Hm, true - for some reason I was thinking about the data gas being expensive, but that's paid either way...
But there's still the difference between jumping to the function and back or not, since if it isn't inlined the condition is only checked after the call, not inside... but that actually sounds much more like something we could fine-tune the optimizer for...