@skilesare Stage 3 is now complete.
1 Like
@timk11 has now completed Stage 4 and 5!
Feel free to make a community review and weāll finalize those stages. Just two more groups of functions to complete all the op codes!
1 Like
@skilesare Stages 4 & 5 are now complete.
@timk11 has finished Phase 6! Only phase 7 remains.
If you have a chance, please give it a review:
1 Like
@v1ctor Iām currently working on the EVM OpCodes bounty and hoping you can help me out with something.
Iāve utilised libsecp256k1 in the ecRecover precompile function. Here is my version of the function and the corresponding test. When I test it it runs for up to 3 minutes and then exits with unknown exit code: null like so:
Itās obviously a long and complex computation and perhaps Iām running into a memory issue, but have you been able to run a version of this code yourself in a shorter time with a good result? Does anything stand out as out of place in my adaptation of your code?
@skilesare Any other thoughts on this?
Not sure why tests and stateTransition are async.
If I remove async and run tests with mops test --mode wasi it only takes ~15s on my laptop.
When Iāve used it in the past I have not had any timing or cycle usage issues with ecrecover. I remember a bunch of fussing over things, especially how to deal with v, but I think it generally worked.
Thank you both.
@ZenVoich I tried taking all the asyncs out of tests and stateTransition, ran mops test -mode wasi and got this:
I then switched from mo:test/async to just mo:test, tried the same thing and got this, irrespective of which functions I tested:
I then tried just mops test and got the same result as before:
At some point early in development I found I needed to use async in order get the whole thing running error-free. I started off using an actor and switched it to a module early on, so it might have even been because of that.
I suspect thereās probably something wrong with my use of the libsecp256k1 library. In particular, Iāve used
let context = Ecmult.ECMultContext(null);
here but I donāt know if thatās correct.
@skilesare When youāve used this did it also take 15 seconds or was it much faster? The evm.codes playground runs ecRecover very fast so I suspect that this library should probably do likewise if I implement it correctly.
As it says, you need to install wasmtime:
mops toolchain use wasmtime 27.0.0
1 Like
@timk11 All the tests at evm-txs.mo/test at main Ā· av1ctor/evm-txs.mo Ā· GitHub run without problem, including the ecrecover, but some are really slow to finish due the complexity.
Thanks @v1ctor . Iāve tried using libsecp256k1 directly in order to maximise efficiency. Have I applied it properly, including context? Or would you recommend I really just use evm-txs instead?
I have
import PreG "preg";
import Ecmult "mo:libsecp256k1/core/ecmult";
public let ecCtx = Ecmult.ECMultContext(?Ecmult.loadPreG(PreG.pre_g));
I think I pulled PreG from a test file somewhere? @VictorG any issue doing this?
They are not in the src folder so I had to pull it in manuallyā¦also maybe had to do prec.mo?
The pre-calculated arrays were needed, IIRC, because the tests used to take ages to finish if the tables were generated at runtime.
The prec table is only needed when creating or signing using libsecp256k1/Ecdsa, but generated at runtime should cause no problem - unlike preg, that takes too much resources to be created.
@timk11 calling libsecp256k1 directly should be fine
Thanks guys. That all helped and itās working now!
I used pre_g from where @skilesare said and this allowed the code to produce a result, albeit not the right one. I tried a few things and then switched over to using evm-txs, and this gave the right answer for the address. The new function is here.
Any idea what was going wrong with pre_g? Iām using that so it would be good to know if it is wrong. 
I think pre_g is fine. When I was calling libsecp256k1 directly there was undoubtably some logic that I had inadvertently skipped over, hence the incorrect result. Once I changed the code to call evm-txs it gave the correct result without needing to do anything differently with pre_g.
Tim has finished the bounty and brought the op codes up through the Shainghai upgrade!
There are four more to bring it up to Paris which Iāll try to get in soon, but we should be able to run a number of existing smartcontracts through the system now. It is just a mater of actually building the execution engine.
If you are interested in continuing or picking up this work, please reach out.
2 Likes
Really amazing work by @timk11!
Iāve added the last Paris Op codes and we should be up to par: GitHub - icdevsorg/evm.mo: EVM Based Libraries for Motoko
I started poking around on an execution pipeline and I think it is going to take a bit more TLC than I can give it this week, so alas, weāll head to ethDenver with just the opcodesā¦but this is a big accomplishment!
If you are interested in helping out to extend this and push the project forward, please reach out!
The first step will likely be a bunch of refactoring:
- I want to break out the op codes into individual files so that main.mo is a bit more manageable.
- Looks like we need a real M-Patricia tree for accounts and I think that exists somewhere, just need to implement it.
- Some utility functions can be refactored.
- There are a bunch of places that Bytes are converted to Nats and I think we can utilitize that and shorten a bunch of functions.
- We need to put together a shareable and stable state of a evm as a precursor to an actual pipeline.
- There are likely some edge cases we need to add to the test suite. I think someone with an LLM and a some test suites from ether.js or one of the other libraries could make some hay.(We might need the execution pipeline for this if they donāt have opcode-specific tests.
If you want to know more about evms, how they work, learn motoko, and get some commits on the board, these are great places to start.
3 Likes
Definitely would like to play around with evms more, Iāve got a baseline understanding of how it works but i havenāt do much work with it could be interesting. i think the M-Patricia tree, might be up my ally because i am working on a merkle tree like standard. The codebase is well formatted but definitely not digestible for solo devs. would love to get involved
We have one! GitHub - f0i/merkle-patricia-trie.mo: A Merkle Patricia Trie implementation in Motoko
It may need an overhaul, but hopefully most of it is there.
It does need to be integrated until the evm.mo library as I think it currently just has a trie standing in for the memory.
Most of what is needed at this point is the ālifecycleā part where we wire up the memory, trees, etc to the transaction loop.
GG23 kicks off later this month and Iām hoping to raise a bit more for a new bounty. Ongoing work will likely help, but traditional the GGs have been poor for fundraising. Weāll see how this one goes.
(We will certainly have some bounties soon even if they are just in ICDV)
1 Like