Feature ask: support custom Solidity code to do multicall

[macaujack]

I've read the reply here and got the basic idea of how the multicall magic is done.

At present, the multicall.sol in this repo is a general-purpose contract that does multicall. I'm wondering if we can run custom Solidity code (to be more precisely, compiled bytecode). This is useful when the multiple calls are dependent.

Here's a theoretical example which is meaning less is real world. I want to get the owner of an NFT. After I get the owner of the NFT, I'll check whether the owner address is an odd or even integer. If it's odd, then I want to get the owner's USDC balance. Otherwise (i.e., it's even), I want to get the owner's USDT balance.

I don't think the current general-purpose multicall contract can handle this case. I'm wondering if we can let users write custom logic in Solidity and manually compile it into EVM bytecode. And this piece of bytecode will be run, and we can get the return values.

[ricmoo]

The current multicall provider doesn’t offer that, but I did have a hackathon project I was working on that could achieve this; rather than solidity it used custom high-level language that would compile to EVM. It’s something I’m still considering working on, if there was demand.

The hackathon project was called gremlins which is largely unfinished, but that I’ve migrated much of the grammar to a new project fables, which I should be making public soon. Fables is currently designed to target embedded devices backends, but I’m planning an EVM backend too.

Any interest or ideas are appreciated though. The main reason for a custom language is one that is focused on compiling (including codegen) in a small JavaScript compiler, as Solidity is an 8.5 MB emscripten wasm blob. I can certainly use any extra help, especially for those interested in compilers, VMs and simulators.

Fables currently has a compiler (to an AST), an IR (similar to YUL), a simulator (runs Fable code as an interpreter) but still needs codegen (for the custom arduino VM and for EVM). That is all on npm, but I’ll open up the repo soon. :)

Of course, there is an option to write a much simpler solution to your immediate problem, which could be similar to the current contract, with a nop method, which the constructor calls. Then you could subclass it, replacing that method. This goes back to requiring Solidity though, which may be fine for cases where you can compile it once and ship it with your application.