Hi, Josep, thank you for taking time and asking very good and important questions. This is exactly why we are posting here so we can have a good discussion and make sure we propose something experts agree with and support!
Following Rob and Giotto who say we don’t need more unused tools, our team suggests a creation of a tooling supported funnel to bring users to Plaza and Polkadot in multiple stages. Following the feedback from Shawn and Thibaut, we try to aim for the most minimal first milestone possible, which also does not depend on any deliverables from external teams.
I’ve read through this forum post and its comments multiple times, but I’m still unclear about the concept of the “minimalistic playground in the browser.” Here are some specific questions and concerns:
1. What is the problem you are trying to solve with the “minimalistic playground in the browser”?
In the first milestone we are trying to create a testing playground to be able to support the Parity Smart Contract Team once their deliverables (revive compiler, PVM, Paseo support with EthRPC adapter) become available. It won’t include any fancy editor or styling that would make it a smooth experience for solidity developers, because we do not target them with our first milestone.
2. Who are the target users of this playground?
In the first and probably second milestone, the target users will be internal, more specifically our team and the compiler and PVM developers.
3. How is this playground going to help these users?
For internal users, the main benefit and focus is to test the full flow of compiling, deploying and interacting with solidity based smart contracts on Plaza and to help understand and identify missing features, debug issues and to ensure everyting works as a drop-in replacement for the equivalent EVM based flow.
The benefit of the testing playground is also to allow us to effortlessly hook into every step of the process in the same web environment solidity web dapps interact with popular wallets, such as MetaMask.
4. What can be done with this playground that couldn’t be done with a Remix plugin?
When we originally developed the Remix plugin system, we did not architect it in a way that would allow to tap into any arbitrary part of Remix. It was rather designed as a system to allow some limited extensibility and to grow it over time based on feature requests.
For internal users, in theory a Remix plugin might be able to satisfy all our needs, but in order to hook into any part of the compile, deploy, interact pipeline for EVM, we would need to re-implement what Remix natively does inside a plugin and basically do the entire work we would do for the testing playground with the additional overhead of wrapping it in a Remix plugin. It would also restrict our ability to utilize the UI in arbitrary ways in order to help us test and debug once revive compiler and PVM deliverables are available. For example if we figured out we wanted to visualize compiler output or logs full screen to compare or get insights in specific parts, Remix is not designed to allow that.
5. Why is this playground a prerequisite for creating a Hardhat plugin? I understand the value of creating a Hardhat or Remix plugin, but I’m struggling to see the value of the “minimalistic playground in the browser”.
A HardHat plugin, just like any other existing tooling can only be retrofitted with stable “Plaza components” and put in front of existing solidity developers, once those components exist. The testing playground approach will help us create those minimal well tested general components to compile, deploy and interact, so we can fully control and hook into every part of the EVM pipeline in a browser environment to have access to the most commonly used MetaMask Wallet, for testing, inspecting and improving the components.
Once they become stable and ready to be re-used, we will implement them into more complex professional environments, such as Remix or HardHat or VScode plugins etc., as part of the funnel to bring existing solidity developers to Polkadot.
6. Why not create a plugin from the start? Why is there a need to create a new online editor? Past feedback suggested avoiding new tools unless there’s a strong justification. Did I miss an explanation?
Starting with the testing playground will enable us to to hook into the compile-deploy-interact pipeline to test all the capabilities and which will help us develop and test all the modules we need for retrofitting existing Solidity tooling, such as HardHat and Remix plugins, in the next milestone(s).
7. Couldn’t this also be achieved through a Remix plugin?
As mentioned above, Remix plugin system wasn’t designed to hook into any arbitrary parts of the pipeline, nor to make it scriptable. Doing a Remix plugin might still be possible but there is a risk that we would need to do things plugins don’t support which would have a significant overhead since we would have to write all the code that we would otherwise write for a testing playground plus wrapping it in the plugin. Additionally, every time we will run a test, we will also have the Remix code as an extra overhead we need to step through while debugging, which will cause more complexity and will make the milestone bigger and more expensive.
8. Are you sure that their recommendation was to create a “minimalistic playground in the browser”? The last feedback I read suggested avoiding new tools initially and focusing on plugins instead.
After sharing the research about the existing solidity tooling and discussing all the technical pros and cons with the Smart Contract Team and thinking also about the marketing funnel towards Polkadot, we agreed the best approach would be to build a minimalistic playground and the plugins. In our previous proposal we wanted to start with the playground and the plugins in parallel, but Shawn and Thibaut pointed out we should really focus on the most minimal first milestone that doesn’t depend on any other external party, therefore we suggest the execution in the following steps, where each step has solid deliverables and the value for the ecosystem:
First and second milestone - testing playground (EVM => PVM)
Next - retrofitting Solidity tooling to make existing Solidity developers try out and slowly transition to Polkadot
Lastly - bringing the developers to the Polkadot native environment where they can discover the full functionality of Plaza and interact with other ecosystem services they wouldn’t be able to inside of the existing solidity tools. This step is also useful for our native users whom we don’t want to send to another ecosystem tooling, but rather offer them the Polkadot first tooling. This step will be discussed in the future and can focus on turning the testing playground into a real develeloper facing playground and/or simply focus on Polkadot native CLI tooling.
To sum up, as we all agree building yet another tool that no one uses, is not the approach we want to take, what we would like to contribute is a tooling supported funnel strategy to transition solidity developers from other ecosystems onto Plaza/Polkadot.
After the initial comments Smart contract lead and also Rob agree a minimalist playground is a reasonable pathway forward, although we should also focus on plugins, which is exactly how we now want to procees: first testing tooling, then plugins and lastly (maybe) a real user facing playground.
9. Did the team request this? Will they be able to use your first delivery for this purpose?
Yes, the Smart contract team suggested we implement the EVM flow first because they would like to test their compiler and PVM against that setup and also make sure ethRPC works with Metamask and other wallets. We were discussing if this should be via Remix plugin or a minimal testing playground and the idea was to do both in parallel. But in order to make our first milestone smallest as possible (as Shawn suggests) we would recommend to first do the testing playground as it has the least overhead.
10. Could you elaborate on this replacement process? Which kind of node will this playground work against?
- Will it work against a Frontier-based node?
- Will you contribute to the ethink project and built on top of it?
- Will you fork the
@acala-network/eth-rpc-adapterand adapt it for your own needs?- Will you create a custom solution?
- Something else… Another solution that I don’t know about, or one that’s currently under development, perhaps?
What trade-offs have you considered, and which path will you take to replace the EVM with the PVM?
In the first milestone we plan to focus on the EVM flow, so we don’t need to work against the ethRPC adapter.Most likely we will make the deployment work on Ethereum Sepolia test net or Moonbeam.
In Q4 Paseo test node will most likely already support PVM so our plan was to use Paseo, but if it will not be ready until then, we will decide for the best option by the time we apply for the next milestone.