Remove external eth_calls by using a JS-based EVM interpreter

counterfactual / monorepo

Home for all packages related to the Counterfactual project

https://counterfactual.com

MIT License

187 stars 44 forks source link

Remove external eth_calls by using a JS-based EVM interpreter #950

Open snario opened 5 years ago

snario commented 5 years ago

Calling eth_call for every applyAction and resolve sucks. It is slow.

We can use a JS-based EVM interpreter instead. https://github.com/ethereumjs/ethereumjs-vm offers a runCode method we could use.

There is a subtle problem which is that for some specific apps we allow view functions (e.g., ETHBalanceRefundApp to observe address(multisigAddress).balance). So, those ones need to use eth_call. Maybe you can observe the ABI of the contract and conditionally use eth_call for those.

snario commented 5 years ago

@ricmoo how's this coming along with ethers? @pkieltyka any ideas?

ricmoo commented 5 years ago

Still trying to get v5 into public beta, then I’ll start making the EVM public through its experimental package.

snario commented 5 years ago

Sweet.

gitcoinbot commented 5 years ago

Issue Status: 1. Open 2. Started 3. Submitted 4. Done

This issue now has a funding of 750.0 DAI (750.0 USD @ $1.0/DAI) attached to it.

If you would like to work on this issue you can 'start work' on the Gitcoin Issue Details page.
- Want to chip in? Add your own contribution here.
- Questions? Checkout Gitcoin Help or the Gitcoin Slack
- $41,591.17 more funded OSS Work available on the Gitcoin Issue Explorer

vyomshm commented 5 years ago

@snario Is this open?

If so, I'd like to take this up.

snario commented 5 years ago

Yeah, I'd like to specify it better though. Our ideal scenario is that we can take an ethers.Contract and call .functions.<blah> on that object and if blah is a pure function then compute the result locally. @ricmoo mentioned he was working on this, though.

sounak98 commented 5 years ago

@snario It shows open on Gitcoin. Is it actually open? If it is, I'd like to take it up.

spm32 commented 5 years ago

Hey @ricmoo can you apply for work on this one since you're already working on it :)

ricmoo commented 5 years ago

What is the desired timeline for this task? Keep in mind the ABI would require a runtime bytecode in it to use this feature; I’ve been trying to think of a way to integrate pure functions into the ABI for a while.

One other concern I have is any bug in the VM can result in consensus forks between a channel and the chain. What type of operations will be marked pure?

snario commented 5 years ago

@ricmoo It is non-blocking for us but a big win for the entire Layer 2 ecosystem.

I think a bug in the VM would be just that, a software error that would cause the state channel states to have been signed incorrectly. I think this is the same problem as a a software error in geth or parity VMs right?

Specifically the interface we care most about is function foo(bytes memory, bytes memory) pure returns (bytes memory) however this feature should support function foo(<anything>...) pure returns (<anything>...).

spm32 commented 5 years ago

Hey @ricmoo are you still up for taking this one?

snario commented 5 years ago

Potentially useful: https://github.com/armaniferrante/pure-evm