-
Notifications
You must be signed in to change notification settings - Fork 2.3k
LimeChain Application pvm_evm_compat_check.md #2564
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
CLA Assistant Lite bot All contributors have signed the CLA ✍️ ✅ |
I have read and hereby sign the Contributor License Agreement. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the application, @marius080. Sounds great. One thing that seems to be as much a blocker as the VM compatibility is the surrounding architecture, like RPC endpoints. Is this something we could explore in a possible follow-up?
Fixed company link Co-authored-by: Sebastian Müller <sebastian@web3.foundation>
@semuelle muelle
Sounds good! We were trying to keep things limited to the VM as part of this application, and could definitely apply for separate one relating to the RPC endpoint issues. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To pick your brain a bit, are you thinking of having a similar util for RPC compat, or are you interested in looking at developing the rest of the endpoints that would achieve parity?
Just testing. Let's see, perhaps by the time we're closer to launch, there will be a test suite. Happy to discuss this then.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
General comments:
-
I suggest avoiding the term "Research" => I see it more as a rapid experimentation and technical support grant, for checking the compatibility with specific smart contract implementation, that could either be considered as a standard, dependency for common use cases, or strict requirements from commonly (re)used open-source codebases (e.g. Uniswap, Aave, Pendle, Compound, as well commonly used implementations
-
I suggest talking to Parity core smart contract team to ensure qualification of a successful scope. I can facilitate that.
Questions for Limechain
-
Are there any strict requirements (e.g. tooling) for you to perform these smart contracts deployments/experimentation?
-
Does your scope or deliverables on the rapid experimentation include suggestions for Ethereum compatible tooling, and/or specific list of improvements for desired level of compatibility?
-
Can your scope and/or deliverables involve "scoring" PVM's Ethereum compatibility with the current standings and/vs the future (recommended) state according to your results/findings?
-
Can your scope involve reactive approach to testing smart contracts from Hub's (PVM) ongoing sales pipeline from BD teams (e.g. if we're talking to Uniswap, or Uniswap fork/deployments implementation partners, try and deploy their specific open-source limit order deployments, custom order types e.g. from Uni-v3, etc to check for compatibility of those?
-
Can your scope and/or deliverables involve continuous discussions (back-and-forth) with Parity's (or Velocity Labs / Papermoon teams, as BD and technical support) smart contract team(s), and improved/adapted accordingly?
Thanks for this proposal. Generally any tooling that automatically checks compatibility levels and reports issues to our tracker is very useful. I have a couple of more technical questions that are not clear to me from the proposal:
|
Hi @alexdimes We'd be very happy to reach out and try to ensure that the scope falls within the expectations of the Parity team. Regarding your questions:
We primarily would like to stick to a "traditional" tech stack. In the EVM world this would be a Hardhat, NodeJS setup. We intend to use that along with Github's Actions in order to run everything in the same environment.
At this stage, our goal is to evaluate the readiness of the PVM to handle most Solidity contracts. The goal is to include OpenZeppelin, Uniswap and Diamond contracts, and use that as a measure of "where we want to be" rather than just where we are. We are willing to work with Parity to also understand mid-to-long-term goals and figure out which contracts can be included. This could work as a "suggestion" for future improvement.
All tests have a True/False result. The scoring can be done as X of Y, where X is number of passing tests and Y is number of total tests. What I would personally like to see is whether that "score" can be tracked over time so we can get a feel for the progress both in terms of pass/fail, but also total number of tests. I'll work with my team to see how we can do this during implementation.
I would assume that the team responsible for deploying those contracts and tests would be able to also add them to the repository that we will build. They would then be able to run the same type of compatibility check as the rest of the contracts.
Absolutely! I would suggest actually that it's necessary. We would need to communicate with Parity's teams in order to also understand future needs and account for that. |
Thank you for your comments and questions. Let me try to answer them for you below.
We have built a compatibility validation tool in the past in collaboration with Hedera. In that scenario we were able to create a large list of use-cases and a large repository of open source contracts that would classify as common. These cover use-cases for OpenZeppelin base contracts, upgradeability, diamond patterns, swaps, conditional tokens, and more specific op-code tests. We will use that experience, as well as collaboration with Parity in order to set priorities, and clearly define a list at Milestone 1.
The tests are currently derived from previous test suites. We have not accounted for foundry tests at this stage, as the mechanism for testing would be completely different. Our approach is JS execution of onchain functions and validating outcomes.
The goal of this project is to have an "as close to real life" approach to the testing. While the speed of a local chain could definitely boost the activity rate, we do not expect these tests to be run with high frequency. It will also help to establish whether there are issues in live environments.
We intend to build hooks that would automatically publish issues to your tracker. When tests fail, each contract can be identified and a summary can be sent there. |
Note that just running the Open Zeppelin test suite alone on a public chain like Paseo Asset Hub (or "PassetHub") will take about six hours. For CI a local network set to execute blocks as fast as possible is more suitable. |
@TorstenStueber, |
Put on hold as discussed. |
Project Abstract
This project attempts to identify inconsistencies in the PVM runtime that would manifest themselves when running arbitrary EVM Solidity contracts.
Our goal is to deploy common use-case contracts onto a testnet (Paseo), and run the Chai Tests that would usually run locally on Hardhat, on-chain.
The results of the automated tests are to be collated and eventually published.
Grant level
Application Checklist
project_name.md
).@_______:matrix.org
(change the homeserver if you use a different one)