We would like to kindly thank everyone for taking the time to vote and/or comment on our 903 proposal We had an unexpectedly large voter turnout, with over 160 million DOT in total, which clearly shows that smart contract tooling on Polkadot is an interesting topic. The project received over 60% support; however, during the confirmation period, it was voted against and ultimately failed with 46.3% AYE and 53.7% NAY.
During the voting period, we conducted additional research to help voters understand the context and how our proposal fits into the Plaza vision.
We also received a lot of valuable feedback on how we can further improve our proposal and mitigate the risk to the DAO by splitting it into milestones and executing them sequentially.
Below, we will list all the feedback we received and the lessons learned during this process. We kindly ask you to help us review the report and ensure we have not missed any points from the extensive discussions on the Forum, Twitter, Polkassembly, ChaosDAO, Kusama Discord, and in private or smaller group chats.
Feedback
Some comments suggested we should split the proposal into milestones.
Others recommended focusing on a minimal playground rather than the IDE.
A few comments suggested building a plugin for Remix, while others preferred plugins for Hardhat and Foundry.
Some advised taking it slow because Plaza and PVM are very new concepts.
Some recommended to create tooling that can also help test the PVM and compiler before going live with it.
Some comments recommended splitting the project into smaller, verifiable deliverables due to concerns about our unfinished DatDot parachain project and receiving the full amount for all milestones at once.
A few comments supported the proposal as is but advised applying for each milestone separately.
The most frequently repeated feedback was to split the proposal into milestones and apply for each one separately. This approach would allow us to demonstrate our skills and deliver value to the ecosystem while ensuring we donāt take too large of a budget for a project where core infrastructure by Parity is still in its early stages.
The second most common feedback concerned the projectās focus. There was a discussion about which plugins to develop first and the form of the browser tooling. The community is divided on this, which is expected as the Solidity annual survey also shows a split between users who prefer CLI tooling and those who prefer browser tooling.
Next steps
Overall, our research, combined with the feedback, suggests that the best way forward is to focus on a minimalistic playground in the browser. This would help us test the Polka VM and compiler before going live with it. Subsequently, we can create a Hardhat plugin (which can also be used in Foundry, which lacks a plugin system) once all components, the compiler, and the Polkadot virtual machine are stable and ready for end users (Solidity developers).
If the community agrees with this approach, we would like to turn it into a proposal, focusing on the first step: creating a testing environment in the browser for the PolkaVM and compiler. We would first focus on the EVM and then ensure we can replace the EVM with the PVM. This approach would provide a consistent cross-platform environment for testing and debugging compiling and deploying, as well as interaction through MetaMask in the browser, which is commonly used by end users when interacting with Solidity dApps. This is also the recommendation of the Smart Contract Parity team, but if there are other experts with different perspectives, we would be happy to discuss them here before finalizing our proposal and publishing it to OpenGov.
We would be happy to hear your opinions. We have confirmed once again that multiple perspectives are valuable, and we would be very grateful for your input. Thank you once again for your time and support!
Thanks @ninabreznik for summarizing the feedback and starting a conversation on your new proposal.
I think another key feedback which was not captured in your notes was creating a project / milestone on which your team is the only factor towards success.
In DatDot and your original contract tooling proposal, there were heavy reliance on external parties for the success of your project. For example, if I remember correctly, to accomplish your goals with the contract tooling, you had expectations about Parity engineers or other low level contract VM engineers delivering certain things on their own milestones and timelines for your milestones and timelines to succeed.
I think this is also something you should aim to avoid, since there are many ways projects can get delayed when they are outside of your control, and then the scope and timeline of a project can become larger than was originally approved, leading to ātop-upsā, failed delivery milestones, etcā¦
I would be really careful to make sure your next proposal, which is smaller in scope (ideally at most 3 months of work), has a clear measurable output at the end of the project (so something the community can play with and use), and does not depend on outside factors or output from an external group.
Ideally, it should be that you and your team alone are responsible with the success of your proposal, and thus you can bring confidence to the DAO about the expected output.
Looking forward to seeing your new proposal, and happy that you recognize that ānoā to proposal 903, does not mean ānoā to your team in general or the project you want to build.
Thanks Nina for the post, and as Shawn noted, Iām very happy to read you are reflecting on the previous proposal to come out stronger. Now that Iāve delved a bit more in the subject, Iād be curious to understand what the main differences are between a web IDE, and āa minimalistic playground in the browserā? Are we talking about the scope of this IDE?
All in all, Iām questioning the usefulness of it compared to a plugin. While Remix was unique back then, and could be considered an IDE now, the context has changed and I believe it is no longer the platform of choice to develop in solidity. I may be mistaking, and itād be very important IMHO to have some kind of data backing up the direction in which things go. Unless Iām mistaking, PVM is targeting current blockchain devs. Knowing what these devs use would be amazing. I looked very quickly online, and found a survey from 4 years ago, Foundry probably didnāt exist back then, and Truffle was still a thing: Solidity Developer Survey 2020 Results | Solidity Programming Language
50% of respondents stated they are using VSCode as a preferred editor to write Solidity. The second favorite editor was Vim (12.6%), followed by Remix (9.2%), IntelliJ (8.8%) and Atom (7.1%).
Most likely the best IDE choice for your Ethereum development is the IDE you already use for traditional software development.
All in all, Iām looking forward to find out what would be the best, and most impactful tools to build, while the tech matures, rather than having a grand plan, with very uncertain outcomes.
Hey, @tbaut , thanks for taking time to look deeper into this topic. During our 903 proposal we also conducted a research to figure out what is the current landscape and what are the trends. We published the results here.
We also researched the history of Remix (we joined very early, but the idea and the first prototype was already made by the Solidity compiler team and after that our first Remix team was formed).
But we also figured out why Remix was so unique and why did it even start in this form. Most of Solidity compiler developers are not browser developers, but they still chose to build a tool in the browser instead of in the terminal. Why? The thing is that during the development of the Solidity language and the compiler, they needed a stable, cross platform testing environment that covers compiling and deployment, as well as interaction that is as close as possible to end user environment. Users usually interact with dApps in the browser so they decided to do Remix there. It has always been 2 things in one - a testing environment for the Solidity compiler team (where they test and prototype the features) and the tool for developers. Because of its nature, it was often a bit buggy and not 100% stable, so other tooling developed in parallel. These additional tools usually copied over features after theyāve been tested and introduced in Remix, but they of course also added some additional features.
We were thinking to take a similar approach and create a Playground that would serve primarily as a testing environment for the PVM and compiler team. They will need time to finish initial deliverables and the first useful milestone we can provide independently is a testing environment to ensure pVM, EthRPC and revive compiler can be turned into ideally drop-in replacement components for their EVM based counterparts to support not just development (compile & deploy solidty contracts), but also interaction with web dApps via Metamask in the browser.
Later, once features are tested and stable, we would implement them into the tooling professional solidity developers use (Foundry (through Hardhat), Hardhat, maybe Remix and VScode and any new tool that might become popular in the next months).
But having a stable tool for testing that is 100% under our control so we can fully debug errors and implement any feature without any limitations plugin systems might introduce, is in our opinion a very important tool to have.
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ā?
2. Who are the target users of this playground?
3. How is this playground going to help these users?
4. What can be done with this playground that couldnāt be done with a Remix plugin?
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ā.
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?
7. Couldnāt this also be achieved through a Remix plugin?
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.
9. Did the team request this? Will they be able to use your first delivery for this purpose?
Letās dive into the technical details because I would like to understand better how you are going to tackle this:
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-adapter and 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:
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-adapter and 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.
Its nice to see, Nina, that you are coming back with a new proposal, and as Shawn said, you understand that a āNayā is more of a āplease refine your proposalā and not a generic āNoā.
As I mentioned before in discord, to one of your team members, what I would like to see in the next proposal, is a first small milestone that will produce a small but workable tool what the deliverables will be - meaning what this tool will be and what feature it will add, the approach that you will follow, and mainly - and very importatn the members of the team that will execute this first milestone, and their expertise.
I highly trust that a plugin (or 2) of existing IDEās would be much more helpful than a playground and (honestly) sounds like a smaller milestone than a Browser App so I would prefer to see that than (yet another) browser playground.
I would also suggest, when pasting conversations with known members of the ecosystem, to also add the links to these conversations so one can follow up the responses/discussion
Hi, @wirednkod, it is nice to hear your thoughts about the refined proposal. Thanks for this. Let me try to answer your concerns:
I highly trust that a plugin (or 2) of existing IDEās would be much more helpful than a playground and (honestly) sounds like a smaller milestone than a Browser App so I would prefer to see that than (yet another) browser playground.
I tried to share with Josep in my previous comment above (see: answers 4, 5, 6 and 7) the reasoning. I would kindly ask you, if you could read these answers again and please let me know why you think plugins would be a better approach from your POV. I would honestly like to understand it, but maybe referring to my arguments would help me to do so.
As I mentioned before in discord, to one of your team members, what I would like to see in the next proposal, is a first small milestone that will produce a small but workable tool what the deliverables will be - meaning what this tool will be and what feature it will add, the approach that you will follow, and mainly
I think answers to Josepās questions 1, 2 and 3 can give the best answer to this.
ā¦ and very important the members of the team that will execute this first milestone, and their expertise.
And regarding the team, the core will be myself and @serapath. We both worked together for the Ethereum Foundation for 3 yeats and literally started and architected the Remix IDE during that time and later on worked on independent solidity tooling (you can watch our Web3 Summit Talk from 2019) so we have all the expertise needed. But we will need additional engineers. We plan to hire 2 more. Luckily we have a pool of people from working for more than a decade on various projects and for 8+ years in web3. We already worked with some of them in the past and during our first proposal we reached out to them and some are available for hire, but of course we canāt finalize the contracts before we have the scope and the budget confirmed.
I would also suggest, when pasting conversations with known members of the ecosystem, to also add the links to these conversations so one can follow up the responses/discussion
You are right, links to the original posts are definitely a smart thing to add instead of just the screenshots, so, I will post them here:
Alexās comment on our 903 proposal (sadly no direct link to the comment is available, so search Alex and 3rd hit is the comment) Plaza smart contract tooling
Thanks Nina, you reduced super heavily the ask and the scope. At this stage of the conversation I cannot assess whether this is really useful or not, and Iāll see what the users say about their needs.
This is still going, more step by step, for an IDE-like. Weāre talking about tools for future tech, and needs that arenāt ready yet, I have the feeling that this is all too early, and Iām looking forward to see those needs being voiced.
I understand that Plaza is relatively new to the public, but the technology to enable it has been in research and development for a very long time now. The Parity smart contract team lead for example already presented the benchmarks for PVM almost a year ago, during Sub0 Lisbon.
We have been researching the needs for smart contracts in the ecosystem for a few months and have had many technical discussions with Smart contract and compiler teams in Parity, with the Tooling and infrastructure team lead in Parity, with Pop network and others and they have all been working towards this vision for some time, so in end of Q3 the compiler will already exist and will be ready to be used and tested. During Q4 PVM, ethRPC adapter and the integration to the Paseo test network will be ready as well.
If we started working on our first milestone today, we would be right on time, but as you know the Open Gov process will take another month, so if everything goes smooth, we will start preparing the testing playground when compiler will already be published.
So, my question is if you maybe have some other information I am not aware of, that you could share and would help me understand why you
have the feeling that this is all too early
?
Otherwise, from talking to all the parties we plan to work with, let me reasure you that the timing is absolutely right.
Hey Nina, i would suggest to have a look at the latest post from Alex (Parity), that gives a better understanding on the roadmap and what is expected from the ecosystem: Contracts on AssetHub Roadmap
We had an unexpectedly large voter turnout, with over 160 million DOT in total, which clearly shows that smart contract tooling on Polkadot is an interesting topic. The project received over 60% support; however, during the confirmation period, it was voted against and ultimately failed with 46.3% AYE and 53.7% NAY.
