# <svg class="" fill="#e6007a" width="23" height="25" viewBox="0 -5 50 45" xmlns="http://www.w3.org/2000/svg"><path d="m21.1695 9.42485c4.4769 0 8.1062-2.10983 8.1062-4.71243s-3.6293-4.71242-8.1062-4.71242c-4.477 0-8.1063 2.10982-8.1063 4.71242s3.6293 4.71243 8.1063 4.71243z"></path><path d="m40.6292 24.3756c-2.3277-1.3674-5.9251.8139-8.1063 4.6636-2.23 3.8497-2.3277 8.0575 0 9.376 2.3277 1.3673 5.8763-.8139 8.1063-4.7125 2.23-3.8008 2.3277-8.0086 0-9.3271z"></path><path d="m21.1695 45c4.4769 0 8.1062-2.1098 8.1062-4.7124s-3.6293-4.7124-8.1062-4.7124c-4.477 0-8.1063 2.1098-8.1063 4.7124s3.6293 4.7124 8.1063 4.7124z"></path><path d="m1.70935 24.3756c-2.327703 1.3185-2.230038 5.5263 0 9.3271 2.23003 3.8986 5.77854 6.0798 8.10624 4.7125 2.32771-1.3185 2.23001-5.5263 0-9.376-2.1812-3.8497-5.77855-6.031-8.10624-4.6636z"></path><path d="m9.82353 6.58455c-2.3277-1.36734-5.87622.81389-8.10625 4.66355-2.230032 3.8497-2.327698 8.0575 0 9.376 2.32769 1.3674 5.92505-.8138 8.10625-4.7124 2.23007-3.8008 2.32767-8.00865 0-9.32715z"></path><path d="m32.5229 6.58455c-2.3277 1.3185-2.23 5.52635 0 9.32715 2.1812 3.8986 5.7786 6.0798 8.1063 4.7124 2.3277-1.3185 2.23-5.5263 0-9.376-2.23-3.84966-5.7786-6.03089-8.1063-4.66355z"></path></svg> Plaza IDE & Remix/Hardhat Plugins - [Plaza IDE (forum post 8657)](https://forum.polkadot.network/t/polkavm-solidity-ide-project-proposal/8657) - [Plaza IDE (proposal 903)](https://polkadot.polkassembly.io/referenda/903) ------------------------------------------------------------------- <h3>Introduction</h3> <p> After initially reaching out to many potential partners in the Polkadot ecosystem and getting very positive feedback, we assumed the alignment of our proposal with other projects and the overall Plaza vision would be self-evident and sufficient. In hindsight, based on your feedback, the questions and concerns voiced here and in private communication channels, we realised we made a mistake by not including our research work into the initial proposal and should have laid out a lot more details right away. </p> <p> <b>As always</b>, <a href="https://playproject.io">Playproject</a> takes community feedback (made both publicly and via private channels) very seriously and adapting the proposal to feedback requires to properly research the implications, which is one reason why it took a bit longer to come back. </p><p> We have been working to include our research and context, the landscape and technical details to the new version of our proposal as well. <b>We are neither new to Web3, nor Polkadot.</b> <b><a href="https://www.youtube.com/watch?v=VeNVFvCOg3I&t=800s">We have been actively participating in Polkadot specifically, since our Web3 summit talk in 2019</a></b> and over the years have received funding from the Web3 foundation, Bounties and Treasury for various projects. By now, our UX research company accumulated almost a decade of Web3 work experience and contributed to numerous projects. We staff based on project needs and have an extensive network of top talent industry professionals we can source from. </p> <p> Below we will lay out our updated proposal section by section, starting with an executive summary for each section and the option to dive deeper into the details as well. </p> <p> We would kindly ask everyone who voted NAY to familiarize themselves with our proposal amendment and eventually reconsider their vote. <b>Thank you very much in advance.</b> </p> **The major areas of the proposal improvement are:** - **TEAM:** lays out the background of our team in great detail, including in the Polkadot ecosystem since 2019. - **CONTEXT:** illuminates the bigger picture around Web3, Polkadot and the "Plaza" vision for everyone not yet familiar. - **VISION:** expands upon specifics of our proposal and how it aligns with "Plaza" and the overall vision for Polkadot and Web3 - **PROPOSAL:** includes all the community feedback into our adapted and re-prioritized proposal with updated deliverables as well. - **PARTNERS:** describes how our proposal integrates synergetically with other Polkadot projects and partners to maximize impact. ------------------------------------------------------------------- ## TEAM <h3> Who we are </h3> <p> We are neither new to web3, nor to Polkadot. We have been actively participating and working in the Polkadot ecosystem since 2019.<br> We worked for many years with the Ethereum Foundation on solidity smart contract tooling and spoke during the first Web3 summit.<br> <a href="https://www.youtube.com/watch?v=VeNVFvCOg3I&t=800s"><img src="https://i.imgur.com/BGfcXzY.jpeg" style="width: 600px;"></a> <a href="https://x.com/SmartContractC3/status/1609193172046938117"><img src="https://i.imgur.com/3YMWD0L.jpeg" style="width: 600px;"></a> </p> <hr> <h5>up to 2013: Bitcoin Ecosystem</h5> <p> We have been following Bitcoin from the very early cypherpunk days and our primary background is in bittorrent like peer-to-peer (P2P) technology. </p> <hr> <h5>2013: Dat Ecosystem</h5> <p> Since 2013, we have been focusing on and working with <b>Dat</b>, a decentralized storage and data replication technology, which also inspired the launch of IPFS in 2014, as used in Filecoin and Polkadot Crust. </p> <hr> <h5>2014-2015: Web3 Ecosystem</h5> <p> Over a decade ago, in 2014, we founded the <b>WizardAmigos</b> Cypherpunk Community of P2P developers and crypto/web3 nomads to exchange and advance crypto visions. During one of our early WizardAmigos meetups in Berlin, we introduced Christian Reitwiessner to Ethereum, who then went on to create Solidity and still maintains it with his team. Another of our long-time WizardAmigos members, Jannis Redmann, also contributed to Parity in its earliest days. And WizardAmigos Alice Kohn established herself as a Web3 Analyst at Glassnode. </p> <hr> <h5>2016-2018: Ethereum Ecosystem</h5> <p> From 2016 to 2019, we worked with the Ethereum Foundation on various special projects and helped to launch the <a href="https://github.com/ethereum/remix-ide/graphs/contributors">Remix IDE</a> among other initiatives. In parallel, we founded the <a href="https://github.com/ethereum/play">"Play Project"</a>, a Web3 infrastructure and UX research company focused on work revolving around developer UX, smart contracts, and decentralized P2P storage solutions.<br> We <a href="https://github.com/search?q=org%3Aethereum+author%3Aninabreznik&type=commits">architected</a> and <a href="https://github.com/search?q=org%3Aethereum+author%3Aserapath&type=commits">implemented</a> many parts of the Remix IDE core components (including file explorer, the terminal, the basic tiling window manager as well as the <b>Remix plugin system</b> to allow other ecosystem projects to better integrate with the IDE.<br> Over the years, we also hosted numerous Solidity workshops and listened to the experience and struggle of new developers in-person. We also gave many talks about smart contracts and other topics at numerous Web3 conferences worldwide, such as: <ul> <li><a href="https://www.youtube.com/watch?v=nAI_Cr5Y8JY&t=752s">ETHToronto</a></li> <li><a href="https://www.youtube.com/watch?v=GLCpykkb7Oc&t=6s">ETH Taipei</a></li> <li><a href="https://www.youtube.com/watch?v=VeNVFvCOg3I&t=684s">Web3 summit</a></li> <li>multiple <a href="https://www.youtube.com/watch?v=NEhpPRFbTAQ">Ethereum Devcons</a></li> <li><b>ETHCC</b>, <b>ETHGlobal Sydney</b>, and many more...</li> </ul> </p> <hr> <h5>2019: Polkadot Ecosystem</h5> <p> One relevant highlight is an <a href="https://www.youtube.com/watch?v=NEhpPRFbTAQ&t=238s">event during the Ethereum 2019 Devcon in Osaka, organized by us to talk with the Core Solidity Team, tooling creators and many audititing companies about how to improve the state of contract verification</a>.<br> During another conference around the same time related to <b>Dat</b> (a p2p data replication technology), we met Joshua Mir (jam10o), an early member of the Kusama Council and a Kappa Sigma Mu member, and discussed how the Polkadot architecture is such a good fit in the European context and shortly after, while we were mentoring hackathon participants during the EthBerlin Zwei event, we sat down with him to flesh out the idea for the DatDot parachain — a peer-to-peer data availability parachain bridging the Polkadot and Dat ecosystems, similar to Filecoin or todays Polkadot Crust, but for Dat instead of IPFS. <br><br> <b>This was the turning point for us at PlayProject</b> that shifted our attention from Ethereum towards Kusama/Polkadot and we joined the <b>Polkadot ecosystem</b> by giving a <a href="https://www.youtube.com/watch?v=VeNVFvCOg3I&t=684s">talk at the web3 summit in Berlin</a> about the vision to combine the DatDot parachain with a verfiable smart contract search engine.<br> It included ideas for storing verified Solidity source codes in a decentralised version control system built on Dat, utilising the DatDot parchhain to guarantee data availability, but it was quite a bit ahead of its time.<br> <a href="https://x.com/ninabreznik/status/1170132016504946688">(see smartcontract.codes screencast)</a> </p> <hr> <h5>2020-2023: DatDot parachain</h5> <p> The DatDot parachain project received a grant from the Web3 foundation and allowed us to start the work on DatDot as a crucial component of the idea presented during the first Web3 Summit as a parachain bridge project between the Polkadot Ecosystem, Ethereum and the Dat Ecosystem.</p> <p> For the next years our company worked on various projects, but one of them included the DatDot parachain research project. In parallel we have also continued to run the WizardAmigos cypherpunk community events annually, enabling bright minds to have interdisciplinary cross-ecosystem exchange, most notably are the successful Code Camps in <a href="https://wizardamigos.com/codecamp2022/">2022</a> and <a href="https://wizardamigos.com/codecamp2023/">2023</a>, which attracted participants from Dat, Polkadot, and Ethereum, including the Ethereum Metamask wallet's co-founder as a Speaker. </p> <p> After achieving the milestones, we received additional treasury funding from the treasury (still in its Gov 1 phase) to continue working on DatDot and advance the parachain, which is now nearing readiness in 2024. </p> <hr> <h5>2024: DX funnel for Plaza and JAM</h5> <p> While many of our company's projects continue, the current stage of Polkadot development and the Web3 ecosystem finally prompts us to revisit <a href="https://www.youtube.com/watch?v=VeNVFvCOg3I&t=684s">our original Web3 summit talk from 2019</a>.<br> Our team believes the timing is right, and Polkadot is ready for Plaza, as laid out <a href="https://www.rob.tech/blog/plaza/">by Rob Habermeier in his recent visionary article</a>.<br><br> We want to leverage the timing and finally also focus on the (solidity) smart contracts as a core feature to help complete the Web3 funnel towards Polkadot and prioritize onboarding the masses with our open gov proposal <b>The DX funnel for Plaza and JAM: PolkaVM Smart Contract IDE & Remix/Hardhat Plugins</b> as described below. </p> ------------------------------------------------------------------- ## CONTEXT <h3><a href="https://www.rob.tech/blog/plaza/">Codename "Plaza"</a></h3> <blockquote> The city needs to grow outwards from the center, and that center should be the Plaza (= the New York City, Dubai, London, or Shenzhen of the Polkadot continent, the first megacity of many and a precursor to greater expansion) </blockquote> <a href="https://www.rob.tech/blog/plaza/">www.rob.tech/blog/plaza</a> <hr> <h3>The State of Polkadot</h3> <ol> <li><span class="marker">1. </span> Scalability Groundwork has been laid for Polkadot's scalable multi chain world</li> <li><span class="marker">2. </span>Polkadot has so-far relatively uncoordinated actions and is fragmented into many chains which create the need for users, apps & wallets to coordinate</li> <li><span class="marker">3. </span>While many projects currently benefit from having their own chain, and despite the hard work of Wallet and Frontend Developers, the long tail of contract developers and users must spend a lot of time, money & effort to coordinate difficult async interaction, juggling composability of assets, accounts and state across a complex multi chain landscape. Developers also have high time & money costs for building chains, like for example coordinating collator sets and handling block explorers, indexing, bridging, exchange integrations and other overhead.</li> <li><span class="marker">4. </span>Those costs are worthwhile and necessary once scaling capabilities are needed</li> <li><span class="marker">5. </span>Even a single chain can use a large number of cores to process transactions, logically sequential, synchronously composable and validated in parallel across many cores utilizing <a href="https://wiki.polkadot.network/docs/learn-elastic-scaling">elastic scaling</a>. It scales to thousands of TPS today and much further over time. Conservatively, even a single chain scales up to tens of millions of daily users.</li> <li><span class="marker">6. </span>But for lack of real users, there is no scaling pressure currently to merit the level of ecosystem fragmentation.</li> <li><span class="marker">7. </span>Ethereum has the largest user base and those could be funneled to Polkadot by migrating beloved and popular ethereum dapps onto polkadot. This can be achieved by giving them the same interfaces and UX while providing cheaper and faster execution layer with additional functionality from polkadot's unique cross-chain interactions like XCM and bridges. Migrating ethereum dapps means migrating their users to the polkadot ecosystem. The biggest problem is user inertia, so the less changes for a users basic journey experience, the better for winning them over.</li> <li><span class="marker">8. </span>As an ecosystem we should work together and use this to our advantage to build a batteries-included single chain "hub" and focus on scaling it up until this single chain system hits its scaling limits. This is helped by providing most value and lowest switching costs for ethereum builders.</li> <li><span class="marker">9. </span>Only when organic pressure reaches the point of bursting, we should relieve the pressure by utilizing multi chain capabilities and spinning out apps, users, and system functionality, which is enabled by easy migration of contracts to dedicated chains in order to save costs. This behavior can already be observed by ethereum dapps migrating to Ethereums Layer 2 solutions today.</li> </ol> <hr> <h3>Crucial Missing Feature: "Smart Contract Capabilities"</h3> <p> Polkadots core features are asset issuance (currently on AssetHub), staking (currently on RelayChain), bridging and apps. They would all benefit from simple generalizable programmability, but smart contracts are currently mostly lacking from the polkadot landscape and often live in different chains altogether from the assets or systems they aim to interact with. Additionally over time, tightening integration with assets, integrating polkadot identity and adding polkadot governance functionality can enhance polkadot by making scripting and automation primitives more powerful and broadening the usage. For example, leveraging smart contract capabilities to allow custom rewards in restaking protocols and permissionless programmable opengov (potentially enabled by tornado core protocol inspired private voting) is one of the many ideas that could turbocharge innovation. <a href="https://www.youtube.com/live/MU7tCyhBU7g?t=2089s"><img src="https://i.imgur.com/roSuozH.jpeg"></a> </p> <hr> <h3>The Plaza</h3> <p> Starting today, the ecosystem should coordinate behind building one single batteries-included highly-scalable Polkadot system chain, to serve as a "hub" for users, developers, liquidity and apps by focusing 100% of resources and energy on strategically concentrating developer efforts to integrate all of Polkadot's core features with: <uL> <li><b>new "Smart Contract Capabilities"</b></li> <li>and <b>exceptional UX and overall usability</b></li> </uL> </p> <p> The long tail of users and developers are both better served by smart contract platforms, but Polkadot actually has enough cores to support both: smart contract builders and chain builders. </p> <hr> <h3>The Plan</h3> <ol> <li><span class="marker">1. </span>Change the name of AssetHub to reflect the broader purpose as an ecosystem hub, as it already has wallet, bridging and tooling integrations</li><br> <li><span class="marker">2. </span>Make this new "Plaza System Chain" (=former AssetHub) a key focus of marketing, developer relations and developer education programs</li><br> <li><span class="marker">3. </span>Add synchronous smart contract scripting and execution capabilities (enabled by Rust and EVM via RISC-V/PolkaVM) to the "Plaza System Chain" to gain support for new languages like ink! as well as interpreted EVM languages like solidity and more in the future to turbo charge Polkadots core features via: <ul> <li><a href="https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811">polkaVM (forum post 3811)</a></li> <li><a href="https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949">solidity revive compiler based on polkaVM (forum post 6949)</a></li> <li><a href="https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375">EthRPC (forum post 7375)</a></li> <li><a href="https://polkadot.polkassembly.io/referenda/723">EthRPC (proposal 723)</a></li> <li><a href="https://polkadot.polkassembly.io/referenda/885">evm compatible contracts on AssetHub (proposal 885)</a></li> </ul> </li><br> <li><span class="marker">4. </span>Create exceptional tooling for supporting existing and new smart contract developers to build on "Plaza System Chain" utilizing all new capabilities </li><br> <li><span class="marker">5. </span>Reduce "Plaza System Chain" fees to minimum posssible sustainable quantity</li><br> <li><span class="marker">6. </span> Introduce priority-fee mechanism to "Plaza System Chain" as route to capture value</li><br> <li><span class="marker">7. </span> Focus on scaling "Plaza System Chain" as far as possible using polkadot cores without compromising full node capabilities</li><br> </ol> <b>This plan can be implement eagerly, knowing that when the Plaza is saturated, Polkadot (or JAM) has the raw validated compute power needed to handle that expansion.</b> ------------------------------------------------------------------- ## VISION <h3>Developer Experience for Plaza and Jam</h3> <blockquote> <b>Lets Integrate Polkadot into the web3 ecosystem marketing funnel.</b><br><br> From a developer experience perspective, we have been in the shadows of Ethereum, Solana and others for too long. Ethereum because they are older and Solana because they have better tooling and UX. Now that we have figured out how to make tech scale, it is time to step out of that shadow and finally up our game and stop piggy backing on outdated tooling from our competitors and build the lighthouses on our shores to begin onramping people to Polkadot, <b>focusing on the Plaza</b>. </blockquote> <hr> <h3>The web3 ecosystem marketing funnel</h3> <p> Over the past decade, web3 has expanded into a vast ecosystem with various blockchain platforms catering to different audiences. Polkadot stands out as the most technically advanced, occupying a crucial position towards the end of the web3 funnel. </p> <p> Sadly, so far the gap between smart contracts and parachains has been too wide, which might have contributed to the many layer 2 solutions around Ethereum. Also smart contract parachains, such as Moonbeam, Astar and others, maybe because the lack of polkadot native tooling or being hidden behind the main Polkadot brand, could not change that trend yet. Ethereum and the EVM is now widely used in the web3 ecosystem and Solidity is the industry standard and widely adopted and supported as the main smart contract language. </p> <p> Smart contract platforms are easier to get started with and cheaper to build & deploy than a parachain, thus Ethereum and other smart contract-based dapp platforms naturally precede Polkadot in the web3 funnel, therefor it is sensible to bridge to Ethereum by adding smart contracts as a first class citizen on Polkadot to attract the large pool of projects for which contracts suffice. </p> <p> Focusing on the "Plaza System Chain" to feature solidity smart contracts will create a place most similar to Ethereum, but with all the upsides of Polkadot and no downside. The PolkaVM integration and EVM/YUL to PolkaVM recompiler (revive) can provide a significant performance improvements over Ethereum or existing Polkadot smart contract execution environments (like Frontier and pallet-contracts) at much lower transaction costs. The revive compiler can also be re-used on top of JAM, which formally defines Layer-0 sync execution at the protocol level via <a href="https://graypaper.com/">JAM graypaper</a>. </p> <p> This could finally open the floodgates and unclog the funnel for users to be able to flood into Polkadot where they can start to leverage the advanced tech stack. It also allows Polkadot to leverage the vast knowledge and tooling around Solidity and the EVM as a starting point to populate the "Plaza System Chain". </p> <p> If built right the light of Polkadot-first developer tooling can serve as a lighthouse on the shore of Polkadot to shine so bright, it will be visible to developers in blockchain ecosystems outside of Polkadot in the web3 funnel, such as Ethereum or Solana. The first light visible in other ecosystems can come from marketing stunts such as integrating Polkadot technology into EVM based tooling like Remix or Hardhat and with this allowing users and developers to familiarize with the benefits of Polkadot from the comfort of their familiar environments. </p> <p> The next logical step for developers from there is to explore the shores of Polkadot and the many additional advanced features and capabilities PolkaVM offers and which didn't exist or weren't feasible on Ethereum. It is therfore important to have exceptional Polkadot first tooling ready to serve as lighthouses and guide users and developers to our shores. </p> ------------------------------------------------------------------- ## PROPOSAL <h3>PolkaVM IDE & Remix/Hardhat Plugins</h3> <p> In order to overcome Polkadot's lack of real users, we support the vision of the "Plaza system chain" and propose a flexible & themable, modular & extensible Polkadot first smart contract tooling, focusing on unlocking all of the new capabilities enabled by PolkaVM, EthRPC and the revive compiler. </p> <p> As a by-product, this approach will allow us to retrofit existing tooling, utilizing the modules and components built for the Polkadot-first IDE. Initially we propose to focus on retrofitting solidity tooling, such as Ethereum Remix and Hardhat via plugins to teaser Polkadot's performance gains and lower costs to the existing solidity developer community. This marketing stunt will enable migration towards "Plaza System Chain" and our native tooling. </p><p> In addition we plan to focus on modularity and extensibility to enable partner projects in the ecosystem to leverage the new Polkadot native tooling permissionlessly and offer their functionality to smart contract developers. Finally, legacy tooling can be ported to the new polkadot-first tools via adapter extensions as well if needed. </p> <hr> <h3>Introduction</h3> <p> Solidity is a high-level programming language specifically designed for writing smart contracts. Solidity enables developers to create decentralised applications (DApps) and various other blockchain-based solutions. It is the most widely used language for smart contract development and is pivotal in the creation of decentralised finance (DeFi) applications, non-fungible tokens (NFTs), decentralised autonomous organisations (DAO), and various other blockchain-based innovations. </p> <p> Polkadot is advancing its smart contract capabilities with the development of PolkaVM (PVM), a new virtual machine replacing WebAssembly that makes just in time compiled contracts on Polkadot possible for the first time. Historically, Polkadot has supported the Ethereum Virtual Machine (EVM) through the EVM emulation layer, but PVM aims to enhance performance by compiling Solidity to RISC-V instead of EVM bytecode. This will also allow contracts to be written in other languages (not only in Solidity). </p> <p> A single Polkadot "Plaza" system parachain with smart contract capabilities can create a technically superior but otherwise similar environment to what users and developers of other blockchain ecosystems are used to, which can facilitate onboarding users and their liquidity by attracting the Ethereum smart contract based dapps with the most users and the developers behind those dapps to migrate to the Polkadot "Plaza System Chain", which offers all the same features at faster performance, lower costs and additionally offers new advanced features on top. </p> <hr> <h3>Objectives</h3> <p> <ol> <li><span class="marker">1. </span>Leverage Polkadot’s Unique Features: Develop native tooling that fully utilizes Polkadot’s advanced capabilities.</li> <li><span class="marker">2. </span>Bridge the Gap between Smart Contracts and Parachains: Facilitate easier onboarding and transition for developers from Ethereum to Polkadot.</li> <li><span class="marker">3. </span>Elevate Polkadot’s Developer Experience: Create tools and resources that position Polkadot as a leading platform in the Web3 ecosystem.</li> </ol> </p> <hr> <h3>Problem</h3> <p> The web3 ecosystem at large is a funnel where each projects serves and optimizes for different audiences at different stages of their development. While Polkadot has the most advanced ready to scale tech, there is a significant lack of adoption. The issue is, most dapp developers are firmly embedded into their current ecosystems and not aware of the opportunities a Polkadot "Plaza" can offer. From a polkadot perspective, their existing tooling comes with inherent limitations and also different needs and priorities to serve the audience those tools were designed for, so Polkadot technology, even though engineered to allow retrofitting existing tools and make them be re-usable, can at best make Polkadot a second class citizen despite the superior capabilities. Even if Ethereum users learn about Polkadot eventually, retrofitting Ethereum tools for Polkadot is like converting a gasoline car into an electric one: it limits the full potential of the technology. <p> Additionally, even with retrofitted tools to showcase some of Polkadot's benefits, migrating to a new ecosystem comes with many uncertainties and unknowns, which make migration again less likely. As new developers try to join and migrate their dapps over to the Polkadot ecosystem, they encounter significant barriers due to the lack of streamlined tooling, no one-click smart-contract deployment solution and a lack of Polkadot community support to guide and welcome "foreign" dApp projects and re-assure them along their migration journey. There is no optimized developer experience to unlock all of Polkadot's capabilities. This gap hinders rapid prototyping, testing and exploration of advanced features, which would be crucial for developers to migrate their project and also also makes it harder for auditors to verify or educators to teach smart contract coding with Polkadot's advanced functionality effectively. </p> <hr> <h3>Solution & Benefits</h3> <p> <b>We propose</b> to drive adoption & growth, expand the developer base and foster a more vibrant ecosystem by addressing the tooling gap and highlighting Polkadot's unique features to elevate the developer experience and draw projects to the new Polkadot "Plaza System Chain", where existing AssetHub liquidity is available to contracts and can attract interest and hence additional liquidity. In order to achieve this goal, we plan to create new modular componentized and extensible Polkadot native smart contract tooling that can fully leverage the new advanced technology and deliver exceptional user and developer experience to those building on top of this new Polkadot "Plaza" which will be powered by <a href="https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949#a-new-solidity-compiler-1">polkaVM</a>, <a href="#">EthRPC (for Ethereum Metamask & web3js tooling compatibility)</a> and <a href="#">recompiler frontends</a> (once Paseo/Kusama/Polkadot receive the new contracts-pallet on AssetHub, which will enventually allow "standard" RPC calls, logs/receipts & traces as well). </p> <p> This will also allow us to re-use components and modules to retrofit existing tooling (such as IDE's, cli's, block explorers, etc...) with 70-80% less effort, so smart contract and dapp developers can initially explore Polkadot's new capabilities from the comfort of their known tools, which solves the vast majority of their current use cases. This of course provides us with the unique opportunity to leverage existing tools as stepping stones to build a streamlined funnel that attracts users to try the new Polkadot capabilities, which in turn bridges the developer experience for Ethereum and other ecosystems to Polkadot in a more seamless manner and fully closes the gap for a gradual transition of existing Ethereum developers over to Polkadot's more powerful and advanced native tooling. As the first tools to retrofit, we plan to focus on upgrading solidity tooling like Ethereum Remix and HardHat via their plugin systems in parallel to developing the first draft of the new modular componentized and extensible Polkadot native smart contract tooling, so we can get the attention of solidity developers to showcase the power of Polkadot, the performance gains, cost savings, and advertize advanced features enabled by Polkadot plaza to Ethereum users who are ready to transition. All of that would allow users and devs to still use EthWallets like MetaMask leveraging EthRPC. Upgrading Remix and HardHat via plugins as the same time as building Polkadot native tooling, leverages synergy effects and avoids the risk of duplicated efforts. </p><p> Once transition starts, the Polkadot-first tooling allows developers to better leverage Polkadot’s full potential, which in the long run will result in more innovative and efficient dApps as well. For eth/solidity users, who want to keep using their Ethereum accounts and are interested in Polkadot staking or governance, a switch to maybe SubWallet or a MetaMask snap plugin could be the solution. Those wallets can inject eth accounts into polkadot.js dApps to support the additional transaction format and allow transaction signing re-using the Ethereum private key despite Polkadot native RPC. On the other hand Polkadot natives who want to use solidity dapps, even though they use web3.js and require eth private keys, can use SubWallet which could inject Polkadot keys for web3.js dapps that would look like eth address to the dApp, but SubWallet signs eth transaction with Polkadot keys. </p> <p> One core ingredient we envision for the future is also to architect an advanced widget and extensions add-on system based on the latest cutting-edge secure sandboxing technology (similar to what is used by Endo, MetaMask, and Agoric) leveraging the <a href="https://tc39.es/">TC39 Standard Body</a>'s latest proposals for <a href="https://github.com/tc39/proposal-compartments">Compartments</a>, <a href="https://github.com/tc39/proposal-shadowrealm">Shadow Realms</a> and <a href="https://github.com/tc39/proposal-ses">SES</a> which are also polyfillable for the most part. This will allow seamless and secure integration of partner projects into the new Polkadot native tooling and provide greater freedom and flexibility for developers to build interoperable applications and widget extensions, which integrate permissionlessly and securely into the Polkadot native tooling to enhance features and overall capabilities. Additionally, it also enables us to port and re-use older Remix plugins and other existing tools inside the new Polkadot tooling via generic adapter extensions, which allows us to leverage contributors to existing tooling and avoid splitting developer efforts unnecessarily.</p> <p> In the long run, the Polkadot native tooling: <ul> <li>will provide mobile-first responsiveness, premium developer and user experience</li> <li>will focus on self explanatory customizable and extendable minimalism over fully feature packed defaults which require external guidance to use</li> <li>will be embedable and re-usable as components by other projects in the ecosystem and for retrofitting legacy tools to leverage the new capabilities</li> <li>will be themable, to enable all Polkadot projects to adapt the experience to the specific needs of their primary audiences</li> <li>will include all browser based tooling required for building, testing, compiling and deploying solidity based smart contracts on Polkadot (PVM)</li> <li>will feature an editor with compiler integration and **one click deploy** quick prototyping and experimentation in the Polkadot ecosystem</li> <li>will feature a live, interactive frontend generated from the Solidity ABI, allowing users to seamlessly interact with their contracts.</li> <li>will include a presentation mode for agencies, auditors and educators to easily showcase PVM based smart contracts and their functionality to clients</li> <li>will make it easy for other Polkadot projects to securely and permissionlessly extend Polkadot first tooling by adding their functionality so developers can learn and leverage the full power of the Polkadot ecosytem</li> <li>will have an architecture designed for a future that supports a multi language smart contract ecosystem enabled by polkaVM, which includes langauges such as ink!</li> </ul> </p> <p> Lastly we propose to set up a polkaVM related smart contract community server on Discord to allow existing and new smart contract developers to find other professionals within the field to share best practices, tutorials and support each other. It will also serves as a place to discuss where Polkadot still lacks compatibility with other smart contract ecosystems and facilitate communication between core developers and builders to find which pieces are missing and where improvement is needed. Such a Discord community of builders centered around Polkadot first tooling captures mindshare by keeping the focus on Polkadot, which will bring more fundamental value to the ecosystem in the long run and therefore to dot token holders as well, because a community of successful builders will onboard new users and liquidity into Polkadot. The community server combined with developer experience focused tooling can be a place where the community can answer questions and support each other, but also a place to empower educators to teach Polkadot through Polkadot first tooling and influencers to make tutorials using the native tooling and skip advertising Ethereum tools and the likes in the process. It is also an ideal place to advertise upcoming events, such as smart contract focused bootcamps or conference talks or workshops related to Polkadot and smart contracts. Letting this opportunity slip just means we don't truly leverage the overall web3 funnel and instead let various other Ethereum layer 2 solutions take advantage of that situation. </p> --------------------------------------------------------------- ## COMMUNITY PARTNERS <h3>Collaboration & Dependencies</h3> <p> This proposal has been shared with many community members and we would like to thank them for their contributions and feedback. ![cyrill testimonial](https://hackmd.io/_uploads/HJJt2IG80.png) ![rob-testimonial](https://hackmd.io/_uploads/S1hF3UfIR.png) <b>Special thanks to:</b><br> <ul> <li>Alex (SmartContract Team Lead / Parity)</li> <li>Cyrill (PVM Compiler / Parity)</li> <li>Peter (ink!/Pop network)</li> <li>Kukabi (Helicon Labs)</li> <li>Tommi & Jeeper (OpenGov.watch)</li> <li>Shawn (Fellowship)</li> <li>David & Keegan (Web3 Foundation)</li> </ul> </p> <p> If the proposal passes, we are looking forward to closely collaborate with the <b>Parity's Smart Contract Team</b> and in the future the <b>Pop Network Team</b> and are looking for other Polkadot project partners and are open and appreciate additional contributions from the community. </p> <hr> <h3>Our existing partners</h3> <p> <b>This Proposal integrates with and depends on the "Plaza" vision and related Projects/Partners/Proposals:</b><br><br> It's worth mentioning we discussed our proposal with the PVM smart contract and compiler team at Parity and Pop Network (stewards of ink! smart contracts) and both agreed that this is a good project and confirmed they are very much open to collaborate with us on it. Beyond that, we have reached out to additional Polkadot projects, among them DappForge, and the UX Bounty Guild and they registered their interest in collaborating and providing input to be integrated into Polkadot first smart contract tooling. </p> <h3>Parity Smart Contract & Compiler Team (core partner)</h3> <p> Our main focus is to start with onboarding Solidity developers, hence this team is our most important partner and will deliver crucial inputs we absolutely depend on and without which we cannot deliver our project. </p> <ol> <li><a href="https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949">revive-solweb compiler</a></li> <li><a href="https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811">browser pVM (polkaVM runtime)</a></li> <li><a href="https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375">EthRPC pVM adapter</a></li> <li><a href="https://polkadot.polkassembly.io/referenda/885">polkaVM on AssetHub { Paseo, Polkadot, Kusama }</a></li> </ol> <p> The Parity smart contract team has been working on those deliverables for some time now and progressed quite far, so we are expecting the first deliverables in Q3 and Q4 within 2024.<br> <a href="https://www.youtube.com/watch?v=ahtBhzwmjY4"><img src="https://imgur.com/BZtu15R.png" style="width:95%"></a> </p> <hr> <h3> 1. Solc-revive web compiler </h3> <b>first alpha version expected at end of Q3 2024 (audit ready)</b><br> <ul> <li><a href="https://forum.polkadot.network/t/contracts-update-solidity-on-polkavm/6949">Forum - solrevive - solidity on polkaVM</a></li> </ul> <p> The initial release will only compile a subset of existing contracts, but in a few months after more testing & refinements, will compile all of them. The Parity Compiler Team plans to combine the pvm compiler with with a solc to YUL frontend to enable compiling solidity smart contracts. Having solc web compile to YUL and then revive wasm recompile to polkaVM in the browser (evm/wasm) avoids scaling server costs later on. The compiler pipeline is: >solidity source === solc compiler ===> YUL IR === revive compiler ===> RISC-V => polkaVM-linker => PolkaVM (uploaded on-chain for execution) This approach was used by zksync for zksolc and helps with re-using existing tooling and avoids creating a solidity dialect. The YUL to polkaVM revive recompiler can be combined with many compiler frontends in the future to support more smart contract languages. This is preferable over a complete solidity compiler for lack of docs and complete solidity specs and many never finished half baked solidity features. The alternative would be to re-implement and keep up with solc, the single source of truth reference implementation, which is hard and more work. Lastly, it will enable deterministic output, which is needed for source code verification, by comparing compiler output with onchain contract bytecode. </p> <hr> <h3> 2. browser pVM (polkaVM runtime) </h3> <b>first alpha version expected at end of Q3 2024 (audit ready)</b><br> <ul> <li><a href="https://forum.polkadot.network/t/announcing-polkavm-a-new-risc-v-based-vm-for-smart-contracts-and-possibly-more/3811">Forum - polkaVM</a></li> </ul> <p>This is the contract execution engine implemented as a runtime module. The execution environment (a pallet with required host functions) is targeted by the revive compiler. The engines execution layer needs to allow contracts to implenent the same business logic as EVM contracts and keep the same calling conventions between caller and callee.</p> <p> The polkaVM itself is a Risc-V based contracts runtime and in comprehensive benchmarks shows much better performance than WASM and EVM runtimes. It has very competitive startup and compilation times, much better than pallet-contracts or pallet-evm. Additionally, for polkadot native tooling we are counting on the wasm runtime based on polkaVM, which will be able to run ink! as well as solidity and cross-validation against other EVM and WASM interpreters or even eBPF as a bonus will be possible too. The Parity smart contract team assured us a "pallet-contracts" version running in the browser will be feasible and allow gas estimation. It will initially come with very limited debugging support, no step by step debugging, but will be able to run contracts and estimate gas. It will also enable the tooling to see when calls pass or fail and allow printing to the console. A stepping debugger will only become feasible in Q2/Q3 of 2025 when polkaVM will offer execution traces. </p> <hr> <h3> 3. EthRPC pVM adapter</h3> <b>first alpha version expected at end of Q3 2024 (audit ready)</b><br> <ul> <li><a href="https://forum.polkadot.network/t/ethereum-rpc-compatibility-for-polkadot-smart-contracts/7375">Forum - EthRPC</a></li> <li><a href="https://polkadot.polkassembly.io/referenda/723">Proposal - EthRPC</a></li> </ul> <p> RPC exposed by a chain node speaks to the node's runtime via the runtime API. EthRPC is a compatibility layer to translate Ethereum RPC calls to Polkadot RPCs (similar to Frontier) and exposes endpoints in compliance with <a href="https://ethereum.github.io/execution-apis/api-documentation/">Ethereum RPC</a> for the UI to speak to. All EhtRPC compliant tooling, wallets (like MetaMask), etc... will just work. Our tooling will enable web3.js based Metamask to deploy utilizing a node's EthRPC adapter layer. In the future, a Metamask snaps plugin might even enable client side compatibility without the EthRPC adapter layer. The Parity smart contract team will need to add aditional features for deleting contract code via special endpoints so custom web3.js based libraries can utlize those as well. This only requires changing endpoints and the node will use the web3js RPC adapter. </p> <hr> <h3> 4. polkaVM on AssetHub { Paseo, Polkadot, Kusama } </h3> <b>first alpha version expected at end of Q3 2024 (audit ready)</b><br> <b>integration into AssetHub at end of Q4 2024 (audit ready)</b><br> <ul> <li><a href="https://polkadot.polkassembly.io/referenda/885">polkaVM on AssetHub { Paseo, Polkadot, Kusama } (proposal 885)</a></li> <li><a href="https://forum.polkadot.network/t/hybrid-system-chains-make-polkadot-permissionless/7089">Hybrid System Chains (forum post 7089)</a></li> </ul> <p>Having polkaVM integrated into AssetHub on Polkadot (and Kusama) and initially on <a href="https://faucet.polkadot.io/paseo">Paseo</a> will allow us to iterate quickly. Especially if a contract, next to its input and output, might offer dapps to rely on underlying chain protocol data, such as block and transaction data, gas prices, storage state, etc..., which can be supported once the protocol logic is implemented in other runtime modules. All it requires for RPC to provide such data is the runtime to have logic translating substrate chain data to Ethereum chain data. </p> <p> <b>Deployment</b> to AssetHub powered by polkaVM instead of of a chain powered by pallet_evm will enable us to deploy init code. Until ready, we plan to work against Moonbeam or simply eth/web3 without running contracts in browsers, but once available, compiling and deploying to polkaVM powered Paseo testnet allows us to refine the developer experience for this as well. Even though polkadot.js will enable the entire process natively, the EthABI needs a helper library. Initial prototypes could use polkadot.js for node communication and use web3.js to encode/decode contract inputs. It is annoying to have both dependencies, but might be okay for an early prototype. </p> <p> Finally, deployment deviation only affects the developer side and we will try to support it with tooling. The <a href="https://docs.zksync.io/build/developer-reference/ethereum-differences/evm-instructions">new transaction for deployment</a> allows to instantiate a contract via hash instead of code. Contract deployment follows <a href="https://eips.ethereum.org/EIPS/eip-712">EIP-712</a>. The needed bytecode can be provided via "factory dependencies". It will upload the code without instantiating it and then exist as "onchain constructor", allowing anyone to just supply the hash of the code in a custom EIP-712 transaction type to instantiate new contract instances, once this custom functionality is exposed via a web3.js based library. </p> <hr> <summary> <h3>Pop Network for ink!</h3> Pop Network is a vital partner as well to help us support ink! smart contracts on Polkadot native tooling. We have many plans in the backlog which involve to support ink! just as well as solidity and also to support <a href="https://popnetwork.xyz/">pop network tooling</a> and integrate their future service api's. <ul> <li><a href="https://forum.polkadot.network/t/a-new-era-for-ink/8803">new era for ink (forum post 8803)</a></li> </ul> <hr> <p> Some things, like using rust syntax highlighting for ink! are low hanging fruits, but before we can really support ink!, we need to either wait until ink! can be compiled in browsers or until Pop Network will offer ink! compilation as a service, which is more feasible. The Pop Network Team told us cloud hosting a compiler server running <b>`cargo contract`</b> is on their roadmap, for which they might be able to re-use code used by <a href="https://github.com/ink-analyzer">ink-analyzer</a>. Of course, <a href="https://github.com/use-ink/cargo-contract?tab=readme-ov-file#verifiable-builds">contract verification</a> is vital as well and is <a href="https://use.ink/basics/verification/contract-verification">leveraged</a> by the <a href="https://use.ink/basics/verification/sirato/">sirato</a> tool. It requires running <b>`cargo contract`</b> in determinisic mode. We are planning to take inspiration from <a href="https://contractwizard.xyz/">contract wizard</a> and have already studied their <a href="https://docs.contractwizard.xyz/">docs</a>. Still, at the end of the day, a hosted compiler is suboptimal for verification because it requires trust and also makes scaling more expensive, so in the long run we will definitely need to get to a wasm based in-browser compiler for ink. </p> <p> To start, we can get the deployed bytecode from the chain, <a href="https://github.com/use-ink/ink-examples">offer some example ink! source codes</a> and also think about storing ink! source codes written inside the Polkadot tooling in a database potentially maintained by Pop Network, so it can be searched, edited, recompiled, redepolyed. In the long run this is also an opportunity to team up with other Polkadot decentralized storage related projects, such as Crust or DatDot. </p> <p> Lastly, in the future, something similar to <a href="https://github.com/inkdevhub/drink">drink</a>, but in the browser, or compiling a substrate node with ink! pallet to wasm is necessary to offer an in-browser ink! VM, similar to what will soon be available for solidity. Until then we can offer to utilize <a href="https://faucet.polkadot.io/paseo">Paseo</a> to deploy and test contracts, connect to and interact with deployed contract instances via a generated SCALE based UI widget. </p> <hr> <h3>DappForge</h3> Registered interest to work with us on AI integration into Polkadot native tooling. To really start leveraging out permissionless widget extension and provide everything needed to help smart contract developers to build, <a href="https://forum.polkadot.network/t/dappforge-ai-powered-plugin-for-polkadot-developers-that-reduces-development-time/6166">DappForge</a> is an ideal early parter to provide AI powered development and targeted education <hr> The result would be an AI widget for ink! or solidity development, one language at a time, to ask that AI for help, autocomplete code and learn while developing. Each language could benefit from specialized models, but given how many solidity source codes exist, it might be the best path forward to start with solidity. <hr> <h3>UX Bounty & UX Guild Members</h3> Are our partners when it comes to developer experience research questions, such as: <ul> <li>Block Explorer ABI visualization UX</li> <li>Debugger UX</li> <li>Disassembler and Decompiler UX</li> <li>... and many more ...</li> </ul> <hr> The UX Bounty is in its early stage at this moment and the best way to reach out to them is to join their <a href="https://t.me/polkadot_ux_guild/473">telegram channel</a>. One of the first projects we hope to collaborate on, is adding support for Ethereum centric block explorer and substrate centric ones like Polkaholic, which do not decode inputs to contracts yet. They generally need to show source code and decode inputs to a contract. The UX side of this is a good candidate to work with UX Bounty as soon as the Polkadot smart contract team adds support for it to PolkaVM. <hr> <h3> Additional Partnerships </h3> <p> We will continue reaching out to existing parachain teams (especially EVM based ones), compatible tooling (Multix, Wallets, ...), Polkadot ambassadors and the community at large, to look for more partners as soon as our tooling will support advanced widget extension mechanisms to allow permissionless integration. We are also looking for collaboration and partnerships in other core fields. </p> <hr> <b>Tooling & Integration</b><br><br> <p> Speaking as the original architect of the Remix plugin mechanism, our polkaVM IDE will lay the foundation for a more flexible and secure alternative for that offers an outstanding developer UX. This will enable others to build Widget extensions for the IDE permissionlessly, but making sure all Polkadot projects will actually leverage this and build their own custom widget extensions with a good developer UX is another story. Somebody needs to make sure existing Polkadot projects will actually create those widgets/apps/plugins via our mechanism to enable anyone to leverage those in what they will build. A collaboration between the newly established <b>UX bounty</b> guild and the various polkadot ecosystem projects can help. </p> <b>Marketing</b><br><br> <p> We need people to spread the word and bring new users into the Polkadot ecosystem and with Polkadot first UX unlocking advanced features this becomes a much simpler sales pitch. Additionally, key features like embedability and themeability will allow Polkadot to be easily integrated into blog posts, tutorials, and other websites. </p> <b>Communication</b><br><br> <p> We plan to create and maintain a community Discord chat for our IDE to support users with Polkadot-specific questions. This community will involve core developers, builders, and experts in Polkadot and its technical aspects to help newcomers utilize advanced Polkadot features. Additionally, we need moderators and developer relations personnel to manage and nurture this community. </p> <b>Education</b><br><br> <p> We have extensive experience organizing code camps and educating people, but we welcome additional support. We also need contributors to write tutorials and answer questions. </p> ------------------------------------------------------------------- ## MILESTONES <blockquote>All deliverables will be 100% open sourced under the MIT license.</blockquote> ### Milestone I: Eth Remix/Hardhat Plugins & Editor <style scoped> table { font-size: 11px; } </style> |Prerequisites| |-------------| |pre-alpha-rc Solc-revive web compiler - by Parity smart contract team| |pre-alpha-rc browser pVM (polkaVM runtime) - by Parity smart contract team| |Tasks|Research|Design|Frontend|Backend & DevOps|Project lead|QA|Total (hours)| |-----|--------|------|--------|----------------|------------|--|-------------| | Create basic editor for writing and displaying Solidity contracts|40|60|80||80|80|340| | Integrate the compiler to translate Solidity into EVM-compatible bytecode|80|20|80||80|80|340| | integrate web3js libraries, which talk to a node via RPC, to enable interaction with smart contracts on EVM Chains|40|20|60||80|80|280| | Remix Plugins Research, Planning & basic scaffold implementation |40|40|80||40|40|240| | HardHat Plugins Research, Planning & basic scaffold implementation |80|||120|40|40|280| | Make the editor responsive & themable and add a light and dark theme |40|120|120||80|80|440| | Develop a ABI-based UI widget generator to preview and interact with deployed contracts|80|80|160||120|120|560| | Enable one-click deployment to EVM based networks and display the contract address (e.g. Moonbeam)|40|80|40||80|80|320| | **Total (hours)** |**440**|**420**|**620**|**120**|**600**|**600**|**2800**| ### Milestone II: pVM Remix/Hardhat Plugins & Editor |Prerequisites| |-------------| |alpha Solc-revive web compiler based on pallet-contracts - by Parity smart contract team| |alpha browser pVM (polkaVM runtime) in unoptimized form - by Parity smart contract team| |EthRPC pVM adapter - by Parity smart contract team| |polkaVM on Paseo AssetHub - by Parity smart contract team| |web3.js & polkadot.js libraries - by Parity PolkadotJS & smart contract team| |Tasks|Research|Design|Frontend|Backend & DevOps|Project lead|QA|Total (hours)| |-----|--------|------|--------|----------------|------------|--|-------------| | Add convenience features to the editor to improve developer experience|80|100|120||120|120|540| | Integrate the compiler to translate Solidity into PVM-compatible bytecode|40|40|120||40|80|320| | Implement revive compiler and pvm deployment logic into Remix and HardHat Plugins|40|80|160||80|80|440| | custom web3js based libraries to help with EIP-712 deployments |80||120||60|60|320| | integrate web3js libraries, which talk to a node via RPC, to enable interaction with smart contracts on PVM Chains |40|40|40|40|40|40|240| | Enable one-click deployment to PVM based network(s) and display the contract address|160|80|160|160|160|160|880| | Improve a basic ABI-based UI widget generator to preview and interact with deployed contracts by address|80|80|160||120|120|560| | **Total (hours)** |**520**|**420**|**880**|**200**|**620**|**660**|**3300**| ### Milestone III: pVM Deployment & Debugging |Prerequisites| |-------------| |RPC deployment support for polkaVM on Paseo AssetHub - by Parity smart contract team| |EthRPC pVM web3js & polkajs helper libraries - by Parity smart contract team| |Tasks|Research|Design|Frontend|Backend & DevOps|Project lead|QA|Total (hours)| |-----|--------|------|--------|----------------|------------|--|-------------| | Integrate a browser PVM for local deployment and testing|160|160|160||80|160|720| | Add a console for transaction logs and debugging|40|120|160|160|80|120|680| | Display raw compiler output such as matadata.json|20|40|40||40|40|180| | Support deployment to all available PVM chains (Paseo, Kusama, Polkadot)|120|40|120|60|80|80|500| | Integrate Solidity syntax highlighting within the editor|20|80|40||40|40|220| | **Total (hours)** |**360**|**440**|**520**|**220**|**320**|**440**|**2300**| ### Future Plans |Backlog tasks (for future Milestones)| Description | |-------------|-------------| |secure widget extension system|first draft of secure widget extension kernel based on TC39 standards track proposals: compartments, shadow realm, SES to enable an object capabilities security model similar to Metamask Snaps (who presented it during WizardAmigos Codecamps 2022) (see <a href="https://www.youtube.com/watch?v=dV7zf3qTg68&list=PLubqJ-IuY27C6crYh0UzjGL3_GrmaabL_&index=24">here</a> and <a href="https://www.youtube.com/watch?v=LmoiCv88yTI&list=PLubqJ-IuY27C6crYh0UzjGL3_GrmaabL_&index=11">here</a>) to allow custom widgets from the community permissionlessly| |ink! support|Integrate support for the Ink! language (and other languages), expanding |the editor's versatility. |ink! syntax highlighting|Integrate Solidity syntax highlighting within the editor| |ink! compiler | Develop a robust server to host the ink! compiler| |integrate 3rd parties|Work with 3rd party tooling developers for further enhancing the development experience, (e.g. DappForge) | |transaction debuggung|basic transaction debugging for in-browser pVM| |EIP-712 helper libraries|custom web3js based libraries to support EIP-712 deployments| |classic browser EVM | integrate javacsriptVM (local testing)| |compiler output UX | parsing matadata.json and other detailed compiler outputs in order to visualize it in a user friendly way| |signature database |work on code signature database to navigate code more easily| |time travel debugger|integrate time travel debugger interactive UI| |source code database UX|collect source codes in collaboration with Polkadot decentralized storage partners (e.g. Crust, DatDot,...) and create extension for it | |source code search engine|Add first draft of smart contract search engine and display source codes| | tiling window manager | allows to split the screen to work with many files in parallel | |terminal | upgrade editor console to a terminal | |file explorer | support file explorer to mange contract files and folders | |IDE JAM compatibility|upgrade into "JAM IDE" with general purpose widget extension mechanism so polkaVM will enable many languages, thus JAM IDE should exist to support that| |Lastic support|integrate support for Lastic services| |disassembler | research UX and create disassembler extension| |decompiler | research UX and create decompiler extension| |debugger | research UX and create debugger extension| |contract verification |research UX and create contract verification tooling extension| |contract state visualizer | research UX and create contract state visualizer extension| |block explorer |use polkadot native tooling components to ensure block explorers work, especially etherscan support would set a strong signal for Ethereum Solidity Developers | --------------------------------------------------------------- ## BUDGET The funds allocated to the PolkaVM Solidity IDE development team would be utilized strategically to maximize and strengthen the development capabilities and optimize project management processes. **Total research & development time:** - Milestones I, II and III deliverables: 8,400 development hours (8-month execution from August 2024 to including March 2025) - Hourly rate: 95 USD (87.7 EUR) - Total development costs: 798,000 USD - DOT price: 6.11 USD (based on Subscan EMA7 on July 01, 2024) - Treasury ask: 139,470.90 DOT (with volatility buffer included)\*\* **Total Costs (USD): 852,167.2** (based on Subscan EMA7 on July 01, 2024) --------------------------------------------------------------- ## FAQ <h3>Frequently Asked Questions</h3> <ol> <li> Why focus on solidity over ink!? </li> <li> Why is the ask so high and not broken down into multiple stages? </li> <li> Do you plan to fork Remix and adapt it to Polkadot? </li> <li> Why do we need an IDE, wouldn't a Remix and Hardhat plugin be enough? </li> <li> Isn't POP Network already working on smart contracts in this ecosystem? </li> <li>Isn't a new IDE project a massive undertaking? </li> </ol> <hr> <h3> Why focus on solidity over ink!? </h3> <p> There are many more rust than solidity developers, that is why ink! was marketed in the past as a better choice. We go against that narrative, because for polkaVM, the smart contract team at Parity decided to first focus on solidity, to be able to onboard existing solidity devs from other ecosystems to Polkadot. PolkaVM though will support many languages, which includes ink! and will be added at a later stage. </p> <hr> <h3> Why is the ask so high and not broken down into multiple stages? </h3> <p> We are thankful for the suggestion to split the proposal into multiple payments using <b>utility.batch</b> functionality, but we are afraid this could cause problems with recruiting the needed talent and we believe the timing is crucial as well to get started right away to make immediate use of the deliverables other teams will produce in the coming weeks. If we did use <b>utility.batch</b>, to split work into milestones like { remix plugin, hardhat plugin, the big refactor, JAM IDE } over Q3/Q4/Q1/Q2 and ask for USDT or DOT quarterly with the process <a href="https://wiki.polkadot.network/docs/learn-guides-treasury#creating-a-multistage-payout-proposal-with-validfrom">here</a> or alternatively we just asked for the first phase of our milestone and then re-apply in the next quarter we might not be able to secure the needed talent right away and it might also delay the entire process. </p> <p> We are not new to the crypto, web3, or Polkadot. We are contributing to the Web3 ecosystem for almost a decade now and continuously to the Polkadot ecosystem since our Web3 summit talk in 2019. Over the years, we have received funding from the Web3 foundation, Events Bounty and Treasury for various projects. Our UX research company accumulated almost a decade of Web3 project work experience by now. We staff based on projects and have an extensive network of top talent industry professionals we can source from and who command standard industry rates. We understand this entails an associated cost. </p> <p> Recently, we have received feedback expressing surprise at the low price point of our current proposal and some doubt it can actually be delivered at the proposed cost. Our unique background and extensive experience enable us to offer such competitive pricing. Therefore, we would prefer the entire funding amount upfront to provide guarantees to our collaborators and avoid additional overhead. </p> <p> Receiving full funding in advance will allow us to focus on the project without the need to re-apply for funds. It also enables us to secure long-term contracts for top talent, essential for fulfilling our commitments. Many professionals are reluctant to accept short-term engagements due to better opportunities. </p> <hr> <h3> Do you plan to fork Remix and adapt it to Polkadot? </h3> <p> We don't plan to retrofit existing EVM based IDE tooling onto Polkadot, but leverage the new upcoming capabilities polkaVM will enable, by combining it with solc to compile solidity to YUL as an intermediate representation and then use the revive compiler to take it from there so solidity smart contracts can run on Polkadot. In fact we plan a fundamental redesign of an IDE at every level to <a href="https://polkadot.subsquare.io/referenda/885"> unlock all advanced features</a> beyond what is possible with EVM tooling to enable this. The Remix IDE plugin system for example does not support secure and advanced permissionless extension in the same way we envision, is not embeddable, is not responsive or mobile friendly and is in fact also optimized for the Ethereum community in many subtle ways. Adapting the Remix IDE would require such a fundamental refactoring, that it is much smarter to build a new one. At most we can take some inspiration from the experience we accumulated over the years, but forking the actual Remix is not a viable option in our opinion. </p> <hr> <h3> Isn't POP Network already working on smart contracts in this ecosystem? </h3> <hr> <p> Pop Network empowers smart contracts through the accesible Pop API. The Pop API abstracts the complexity of Polkadot, and directly interfaces with powerful use-cases, pallets, and cross-chain messaging.Their focus is creating a robust CLI, but they don't focus on the smart contract tooling in the browser. This makes them an excellent partner for Plaza IDE. Pop Network is a vital partner that will help us support ink! smart contracts on Polkadot native tooling. We have many plans in the backlog which involve to support ink! just as well as solidity and also to support Pop network tooling and integrate their future service APIs into our product. </p> <h3> Why do we need an IDE, wouldn't a Remix and Hardhat plugin be enough? </h3> <p> Adding Remix and Hardhat plugins as part of our deliverables is a great idea and we decided to restructure our milestones to do so. It is a smart approach since we can re-use 70-80% of the effort needed for the IDE backend logic anyway. Additionally, having plugins in the existing Ehereum tooling will also help with marketing when onboarding and gradually transitioning developers onto Polkadot's tech and tooling. </p><p>As explained in greater detail in the Proposal section above, retrofitting Remix or Hardhat for Polkadot is like converting a gasoline car into an electric one: it limits the full potential of the technology. </p><p> We have been personally working with the Ethereum foundation in the past to help bring Remix to where it is today. This includes the architecture of the plugin system and we have plenty of ideas how to bring that architecture to the next level (technically similar to Metamask snaps), but would love to unlock developer UX and various features that would need serious changes to the core infrastructure of Remix. Our past experience shows there is quite a lot of intertia and it is questionable if the Remix project under the Ethereum foundation umbrella would even be willing to accept another backend into their codebase. Forking and refactoring is a substantial effort and upstreaming those changes would even be more cumbersome and is realistically not feasible in our opinion. In general, integrating a fully featured Polkadot-first experience into Remix is unrealistic. At best Polkadot can become a second class citizen in Remix and would always compete with the needs of Remix to optimize for an Ethereum-first experience. </p><p> Skipping the Polkadot native tooling means languages like ink! and the ability to leverage the full potential of polkaVM's features will be lacking. Polkadot ecosystem projects, such as DappForge and others will have a harder time of advertising their features to the new smart contract developer community we are trying to onboard to the Polkadot "Plaza" system chain as well. It also means, there is no place to send new smart contract developers to other than the Remix Ethereum domain, where they might get pulled back into Ethereum or other Ethereum layer 2 solutions instead of keeping them focused on Polkadot. </p><p> Finally, having Polkadot-first tooling, means we can leverage the UX bounty and Polkadot UX Guild and partnerships with other Polkadot ecosystem projects and the Polkadot community in general to tackle UX challenges unique to Polkadot and provide a Polkadot-first place to create the best developer and user experience. This is important if we want to follow through with the "Plaza" vision, which puts UX and overall usability first. </p> <hr> <h3>Isn't a new IDE project a massive undertaking? </h3> <p> Our company is specialized in Developer UX and we have almost a decade of experience and a very clear plan of what we can accomplish and how we want to get there. This can speed things up dramatically. We don't plan to create another Remix. The goal is to aim for radical minimalism, but enable powerful modular extensibility paired with flexible theming capabilities. This way, it becomes trivial to customize to one's needs and to re-use and rebrand in different contexts as well. </p><p> The Remix project for example has a team of ~5-6 people working on it full time, on and off with changing members over time. While some groundwork has been laid initially by <b>Gavin Wood</b>, our <b>WizardAmigos friend Christian Reitwiessner</b> took over and the first commit was published to Github in July 2015. A lot of the core components were added in the first two years, and our team essentialy upgraded Remix into a fully fledged IDE by contributing in 2017-2019. Looking back, the Remix Project didn't have a strong plan what it wants to become and has therfore drifted back and forth to find its identity. The implementation was refactored from React to Vanilla DOM, then back to React and also transition from JavaScript to Typescript. Many parts of Remix were added and removed and then re-added and overall, the majority of time went into research what Remix should actually be, which is expected when pioneering the field of smart contracts. Lately, this included a standalone desktop version of Remix as well. </p> <hr> <ul> <li> <b>first commit (Jul 2015) - uses emscripten transpiled compiler to compile solidity from editor</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/ed6f3caf55f95d90a0f546c52b53522b5ee268aa">create basic editor + transpiled compiler</a></li> </ul> </li> <li>next commits optimize compiler API and structure output in frontend and outputs json and show formatted assembly in dom</li> <li> <b>added ethereujs-vm transpiled to execute compiled solidity</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/b09870d6d9220bba2cfc50f7e9c1fd9067e6ce92">add browser evm</a></li> </ul> </li> <li> <b>added first udapp version + map compiler output ABI to web3js</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/dc166a2bee346871b5b05462980f8004baa69588">udapp + web3js</a></li> </ul> </li> <li> <b>deploy from browser to testnet using geth</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/b82177eaaf76b84205d1ca98c55af53924ac5eb8">geth deploy</a></li> </ul> </li> <li>next commits improve udapp, editor and general UX</li> <li>show runtime bytecode</li> <li> <b>start versioning compiler (Sep 2015)</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/2ed2a1c0fec4e901f6cf3b3ab4facecc24ec4121">compiler version</a></li> <li><a href="https://github.com/ethereum/remix-ide/commit/3f881d9dbe9c4432c13fbeb215273fb477c59b43">version list</a></li> </ul> </li> <li> <b>highlight errors in editor</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/1581a4c74efaff963b8107a347cd1d5500e454fc">editor errors</a></li> <li><a href="https://github.com/ethereum/remix-ide/commit/3f881d9dbe9c4432c13fbeb215273fb477c59b43">october 2015 - multiple file tabs</a></li> </ul> </li> <li> <b>allow compiler hook for solidity imports</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/9a3352aa34a027597f2459c84e087beef7e46a16">recursive import hooks</a></li> </ul> </li> <li> <b>autodeploy and link bytecode (Oct 2015)</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/c6062c5355e3daec6cc9730c675d2f424c4ebf4e">deploy+link</a></li> </ul> </li> <li> <b>use webworkers (Oct 2015)</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/2b6b02a769062351fb1b18697ebce3e6fd31495c">webworker</a></li> </ul> </li> <li> <b>update compiler import callback (Jan 2016)</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/3e834239158a117086936e8e9ecdea1ea96a49af">compiler callback</a></li> </ul> </li> <li> <b>add multi account to compiler</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/2d8ed0b5d52a308be485e379da1f5d7b89a94661">multiaccount</a></li> </ul> </li> <li> <b>add transaction browser (april 2016)</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/6490717a980cc92aad5e54aa6a9ca4af55c68cb2">txbrowser</a></li> </ul> </li> <li> <b>start debugger development (april 2016)</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/6490717a980cc92aad5e54aa6a9ca4af55c68cb2">debugger panels</a></li> </ul> </li> <li> <b>add some tests (jun 2016)</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/f81756a44ccc926183410b58e3e72365aa7410bb">tape tests</a></li> </ul> </li> <li> <b>add first debugger (july 2016)</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/f81756a44ccc926183410b58e3e72365aa7410bb">initial debugger</a></li> </ul> </li> <li> <b>start formal verification of solidity (july 2016)</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/519dbe2d4a1536568b98df8b4cd9f9763dc7687f">formal verify</a></li> </ul> </li> <li>many commits to turn editor into IDE with communicating components</li> <li>many commits to improve debugger and other details and testing</li> <li> <b>add dissassembler (Oct 2016)</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/64b8bbf4b822f83285326c125415af46ff690958">disassembler</a></li> </ul> </li> <li> <b>start static analysis module (Nov 2016)</b> <ul> <li><a href="https://github.com/ethereum/remix-ide/commit/88df6c9f59f64ce7429f3fedfa897ef6531a9f47">staticAnalysis</a></li> </ul> </li> <li>many commits to refactor/improve/refine debugger and other modules</li> <li>many commits to improve debugger</li> </ul> <style> /* Use https://unbounded.polkadot.network/ */ #doc, body { --brightpink: hsla(328, 100%, 55%, 1); --background: #181a1b; --boxes: hsla(328, 100%, 20%, 1); --titles: #e6007a; --text: #ddd; --tablehead: hsla(328, 100%, 30%, 1); --tablecells: hsla(328, 100%, 10%, 1); --tablecells: var(--background); --links: hsla(328, 100%, 55%, 1); --listnumbers: var(--titles); --quotes: #999; } #doc blockquote, .ui-content blockquote { color: var(--quotes) !important; } #doc h1, #doc h2, #doc h3, #doc strong, .ui-content h1, .ui-content h2, .ui-content h3, .ui-content strong { color: var(--titles) !important; letter-spacing: -.02em !important; } body, .ui-view-area, .ui-content, #meta-title-tags > div { background-color: var(--background) !important; } #doc, .ui-content { color: var(--text) !important; } /* #doc summary, .ui-content summary { cursor: default !important; margin: 0 !important; padding: 0 !important; } #doc details, .ui-content details { background-color: var(--boxes) !important; background-color: var(--background) !important; border-radius: 10px !important; padding-left: 30px; padding-right: 30px; padding-top: 0px; padding-bottom: 0px; margin-top: 0px; margin-bottom: 0px; } #doc summary::marker, .ui-content summary::marker { content: ''; } */ #doc a, #doc a:hover, .ui-content a, .ui-content a:hover { color: var(--links) !important; } #doc table, .ui-content table { border: 0 !important; background-color: var(--background) !important; } #doc thead { border: 2px solid var(--brightpink) !important; border-radius: 10px !important; border-bottom: 1px solid black !important; } #doc tbody, .ui-content tbody { border: 2px solid var(--brightpink) !important; border-top: 1px solid black !important; } #doc th, .ui-content th { border: 1px solid black !important; background-color: var(--tablehead) !important; } #doc td, .ui-content td { border: 1px solid black !important; background-color: var(--tablecells) !important; } #doc ul, #doc ol, .ui-content ul, .ui-content ol { list-style: none !important; } #doc .marker, .ui-content .marker { color: var(--listnumbers) !important; } #doc ul li::before, .ui-content ul li::before { content: "•"; color: white; display: inline-block; width: 1em; margin-left: -1em } </style>