Multicall context manager

[iamdefinitelyahuman]

Overview

Brownie should offer first-class support for multicall via a context manager:

with multicall:
    a = foo.bar()
    b = foo.barfoo()
    c = bar.foobar(a)
    d = bar.otherbar()

Specification

While the context manager is open, a middleware intercepts all eth_call requests and returns objects which represent the result of the call once it completes. When the context manager closes, or there is an attempt to use one of the pending call objects, a single multicall is made to get the actual values.

In the above example a and b would end up joined as a single multicall that executes when a is needed for c. Then c and d would happen as a multicall when the context manager exits.

We can bundle the MultiCall2 implementation as used by yearn, which uses try/catch to prevent calls from failing. Attempting to interact with object for the specific result that failed in the multicall should raise a ValueError. (Or possibly the object simply returns None? Maybe this behavior is determined via a kwarg in the context manager?)

It is important to consider thread safety during the implementation. The context manager must introspect to be aware of which thread it is running on, and not also batch eth_call operations coming from unrelated threads.

To ensure consistent behaviour across network, we can use Geth's state override feature to simulate the existence of a multicall contract for the purposes of the call. This is badass in so many ways I'm not even sure where to begin 😈 For dev networks where this isn't possible, deploy multicall silently the first time it's required.

[banteg]

This is an amazing idea! A few caveats:

• ganache-cli doesn't expect a third argument
• as does web3py eth_call formatter breaks when supplying third argument ethereum/web3.py#1921

[omarish]

I've been thinking about this over the past couple days and wanted to float an idea. Would we definitely want it to automatically resolve calls (i.e know to evaluate a and b before getting c)?

One possible design alternative, just to be exhaustive:

# (A) This works
with multicall:
    a = foo.bar()
    b = foo.barfoo()

# (B) This raises an error
with multicall:
    a = foo.bar()
    b = foo.barfoo()
    c = bar.foobar(a)

# (C) This is how we'd want to write (B)
with multicall:
    a = foo.bar()
    b = foo.barfoo()
with multicall:
    c = bar.foobar(a)
    d = bar.otherbar()

(C) Has the advantage of being more explicit, but I agree, is sort of annoying to have to think about re-opening the context manager.

[iamdefinitelyahuman]

I agree that the automatic execution mid-context manager is a bit magical, but when I think about how I personally would feel writing this code, it'd drive me mad having to endlessly close and reopen it.

A middleground here might be a kwarg to enable or disable this behavior?

[omarish]

For sure.

I think a clean implementation would have at least two pieces: a private function to commit a single transaction block (like scenario A above), and then something higher level (probably public) that calls that function every time (1) the multicall needs to be executed, and (2) when the context manager __exit__s.

Perhaps something like this:

def _exec_multicall(*args, **kwargs):
   # used to run a series of calls and will error out 

@contextmanager
def multicall(*args, **kwargs):
   # this is the actual context manager that's exposed, it has some logic and uses `_exec_multicall` for batches.

We could start with the simplest thing, which would be the context manager as initially proposed, then we could see how it feels and go from there. How does that sound?

[skellet0r]

Battle of the Mulitcalls !!!

[iamdefinitelyahuman]

Implemented in #1125