Thanks for your questions Iker!
Is R0GUE expected to be the only maintainer of the runtime? Will runtime upgrades happen via a certain governance mechanism?
To clarify, automated runtime maintenance will be provided to dAppChains. Our pop CLI tooling will maintain a range of templates, along with some for dAppChains, which will be updated with each new Polkadot release. We will dogfood our own tooling, using it to maintain the Pop Network runtime and to improve and streamline the process over time. Most dAppChains will spin off from Pop Network’s runtime, so any update work can be leveraged and executed on the dAppChains’ runtimes. dAppChain owners will have the choice to perform those upgrades themselves or let Pop Network do it.
As for the runtime maintenance and governance model of Pop Network. Initially the chain will run with sudo and R0GUE will be the sole maintainer of the runtime. This is for the following reasons:
- We believe it’s crucial to invest our time early on in building the essential features of Pop Network and validate its value propositions. While governance is important, we’ll delay its implementation to ensure we give it the serious attention it deserves.
- Governance is extremely complicated and requires a lot of consideration.
- We want to iterate quickly, simply put; deliver, collect feedback, improve or adjust, and on to the next feature (following the lean development methodology). The priority is to deliver the core features of Pop Network with our main goal; empowering ink! smart contract development within the Polkadot Ecosystem by improving the accessibility and usability of its features (in a timely manner). We believe that running these iterations additionally through a decentralized governance model will slow down the pace of development.
Nevertheless, once Pop Network is providing true utility to the Polkadot Ecosystem (and the world), decentralizing governance and infrastructure will be our main priority. We are committed to decentralization.
If the state of a given smart contract is replicated from Pop Network dAppChains to its own chain, is the “legacy” smart contract expected to be automatically “deprecated” or is the idea to let them both versions co-exist in the ecosystem?
That is ultimately the decision of the smart contract owner/deployer. For migrating the state of a contract to its own dAppChain, we will provide something along the lines of “maintenance mode”. This will enable the filtering of calls to a given contract, so that the contract state can be locked to help ease the migration. This will be an opt-in feature and access will be limited to the contract owner. Its primary use case is around state migration, but it could also find additional usage around contract security, coupled with governance controls, enabled in the case of a contract security issue. The contract owner would then be free to terminate the source contract once a migration has been completed successfully, provided that their contract supports such a function. Ownership, upgradeability and termination are additional considerations specific to contracts.