Polkadot Common Good Apps Hub Application

[Albertpolkadot]

Project Abstract

Please replace these instructions with a brief description of your project summarising key points (1-2 paragraphs).

If your application is a follow-up to a previous grant, please mention which one in the first line of the abstract and include a link to previous pull requests if applicable.

Grant level

• Level 1: Up to $10,000, 2 approvals
• Level 2: Up to $30,000, 3 approvals
• Level 3: Unlimited, 5 approvals (for >$100k: Web3 Foundation Council approval)

Application Checklist

• The application template has been copied and aptly renamed (project_name.md).
• I have read the application guidelines.
• Payment details have been provided (bank details via email or Polkadot (USDC & USDT) or BTC address in the application).
• The software delivered for this grant will be released under an open-source license specified in the application.
• The initial PR contains only one commit (squash and force-push if needed).
• The grant will only be announced once the first milestone has been accepted (see the announcement guidelines).
• I prefer the discussion of this application to take place in a private Element/Matrix channel. My username is: @_______:matrix.org (change the homeserver if you use a different one)

[keeganquigley]

Thanks for the application @Albertpolkadot a couple of initial comments:

• We don't offer DOT as a payment. Please change to one of these payment options.
• I'm not sure the dummy randomness pallet is needed, because there is already the substrate Randomness trait as well as the insecure randomness pallet for testing. Unless you are planning to use it for production, in which case how can you guarantee security?

[keeganquigley]

I'm not sure I understand this statement, because devs don't need to create a separate pallet for ink! contracts, there is already the pallet-contracts module that any parachain can use. There is also the substrate-contracts-node for testing.

[Albertpolkadot]

Correct, that is not what that statement means to say.

What we wanted to clarify is that by offering the chance to developers to upload their applications as a smart contracts, we are not discouraging pallet development either.

Any of both are valid development paths and it's up to the developer to choose which method they want to take,

[Albertpolkadot]

I hope this comment also helps to clarify this: #2033 (comment)

[keeganquigley]

Can you explain how this concept is different from other chains that cater to app developers such as Astar or Aleph Zero?

[Albertpolkadot]

The primary distinction is that Astar or Aleph Zero offers permissionless access to block space via smart contracts. This means that once developers possess the necessary funds to cover the costs of smart contract uploads, they are free to develop any type of application for their own benefit.

For applications intended to be hosted here, the primary objective should be to serve and contribute to the Polkadot (and Kusama) network. This can be achieved by augmenting the treasury funds, encouraging governance participation, or by introducing a technical solution that other applications on different parachains can depend on, such as an oracle. If a team wishes to deploy an application that doesn't adhere to this principle, the decision rests with the DOT/KSM token holders to either approve or reject the application. Additionally, the native token for this parachain will be DOT/KSM, and all fees (100%) will be directed to the Polkadot/Kusama treasury.

As highlighted in the document, another key difference is our aspiration to emulate the functioning of system parachains. Here, the parachain will be under the governance of Polkadot/Kusama (with the native asset for the parachain being DOT/KSM).

When discussing applications, they can take on one of two forms: a new pallet or an ink! smart contract. The primary distinction between these two lies in their deployment method, setting aside the differences in their development processes.

To introduce a new application to the parachain, it must first be deliberated and approved by the DOT/KSM token holders. This discussion can take place on platforms like Polkassembly. Subsequently, the community must cast their votes on OpenGov to sanction the runtime upgrade. For instance, if the application is a pallet, once the runtime upgrade is enacted, the application may be deemed deployed.

For applications based on ink! smart contracts the deployment works as follows:

1. The referendum is approved, triggering an XCM Transact aimed at executing the 'authorize' extrinsic from the custom-contract-upload pallet, where the hash of the smart contract blob will be supplied.
2. The chain acknowledges the XCM call, and since it originates from the relay chain governance, the origin is converted to Root.
3. The hash of the approved contract is recorded in the custom-contract-upload pallet storage (this action requires Root origin).
4. With the hash registered, any account can upload the contract via the custom-contract-upload.

This procedure closely mirrors how runtime upgrades are conducted for system chains:

1. The runtime upgrade receives authorization from the relay chain governance.
2. Any entity is permitted to enact (upload) the new runtime version

[Albertpolkadot]

Thanks for the application @Albertpolkadot a couple of initial comments:

• We don't offer DOT as a payment. Please change to one of these payment options.
• I'm not sure the dummy randomness pallet is needed, because there is already the substrate Randomness trait as well as the insecure randomness pallet for testing. Unless you are planning to use it for production, in which case how can you guarantee security?

Thank you very much for your feedback @keeganquigley!

• We don't offer DOT as a payment. Please change to one of these payment options.

Ok. Payment method updated.

• I'm not sure the dummy randomness pallet is needed, because there is already the substrate Randomness trait as well as the insecure randomness pallet for testing. Unless you are planning to use it for production, in which case how can you guarantee security?

The Dummy Random Testing Pallet is a pallet designed exclusively for testing purposes and will not see deployment in a production environment. This pallet doesn't generate any random values by itself; instead, it reads the random value derived from the pallet-randomness, which is intended to be developed under this grant. The method this testing pallet uses to read the random value is by implementing the type Randomness from frame_support::traits::Randomness in its Config trait.

It's vital to underscore that this pallet won't be utilized in production. Its sole purpose is to ensure that the pallet-randomness accurately implements the Randomness trait, allowing other applications to retrieve this value.

[Albertpolkadot]

@keeganquigley: I have updated this item to reflect the purpose of this testing pallet.

[keeganquigley]

Thanks for the update @Albertpolkadot I will mark the application as ready for review so the rest of the committee can comment on it.

In the meantime, I noticed that there is no physical address or business entity listed. We will need a physical address in order to pay you; could you update to include it? Or if you'd rather it be private, you can email it to us as well at [email protected]

Thanks!

[Albertpolkadot]

Thanks for the update @Albertpolkadot I will mark the application as ready for review so the rest of the committee can comment on it.

In the meantime, I noticed that there is no physical address or business entity listed. We will need a physical address in order to pay you; could you update to include it? Or if you'd rather it be private, you can email it to us as well at [email protected]

Thanks!

Thank you very much for your answer. I will contact you by email with the details requested.

[semuelle]

Thank you for your application, @Albertpolkadot.
I have a few concerns. One, this grant is asking for USD 30k for a node with one slightly modified pallet. From a technical perspective, this is not reasonable, and as a technical program, this is what we are mainly looking at. Two, while there are concerns about the state of the treasuries, I'm wondering how efficient this approach is to improving the situation. Have you engaged with potential teams or projects to deploy on your parachain? Other than "making contributions to the network", what would be the motivation to deploy on your chain, where any smart contract needs to be approved? I agree with you that a common good apps parachain would be useful, but it would also require a lot of pull to attract developers. Third, can you specify what constitutes "a pivotal role in making contributions to the network"?

[Albertpolkadot]

Thank you for your application, @Albertpolkadot. I have a few concerns. One, this grant is asking for USD 30k for a node with one slightly modified pallet. From a technical perspective, this is not reasonable, and as a technical program, this is what we are mainly looking at. Two, while there are concerns about the state of the treasuries, I'm wondering how efficient this approach is to improving the situation. Have you engaged with potential teams or projects to deploy on your parachain? Other than "making contributions to the network", what would be the motivation to deploy on your chain, where any smart contract needs to be approved? I agree with you that a common good apps parachain would be useful, but it would also require a lot of pull to attract developers. Third, can you specify what constitutes "a pivotal role in making contributions to the network"?

Hello @semuelle ! Thanks for reaching out with your questions and concerns. We're more than happy to address them:

This grant is asking for USD 30k for a node with one slightly modified pallet.

This grant encompasses a significant amount of development effort, as outlined below:

Pallet Randomness: If you're referencing the slightly modified pallet as the insecure-randomness-collective-flip pallet, we'd like to clarify that our approach won't rely on it. This pallet isn't suitable for production use as it derives its randomness from the hashes of the last 81 blocks. Instead, our aim is to develop a new pallet where randomness is generated from the relay chain Babe epoch. Functions such as validation_data and relay_state_proof from the cumulus pallet cumulus_pallet_parachain_system return this data. Developing this pallet is complex, ensuring accurate randomness generation requires deep understanding of how cumulus and its pallets access data from the relay chain.

Custom Authorization Uploader (or Contracts Authorization module): Currently, there's no mechanism in the pallet contract to selectively authorize contract uploads. A workaround exists using the pallet-proxy and the pallet utility, but it lacks granularity. Our new pallet aims to introduce this functionality as an extension to the pallet-contracts. Another notable feature is that this pallet can only be triggered via an XCM Transact, granting authorization solely to the relay chain governance.

Destroy Asset Pallet: This pallet's primary function is to destroy pre-minted chain balances like DOT/KSM. The parachain will initially require these balances for its operations until a sufficient amount is reserved based on transfers or teleports from the relay chain.

Test Randomness Pallet: This is essentially a testing platform to ensure that the frame_support::traits::Randomness trait from our pallet-randomness is correctly implemented.

XCM: Configuring XCM to meet our needs is intricate. At a minimum, one AssetTransactor must have a specific CurrencyAdapter configuration allowing minting of the native asset upon receiving a message with the MultiLocation { parents:1, interior: Here }; structure. Debugging XCM can be demanding, and we may also craft our version of the XCM emulator currently in the Assethub repository.

Moreover, setting up a parachain runtime and its associated pallets is intricate due to the numerous configurations and settings involved.

Given the above, this grant aims to tackle challenging and substantial feature development.

While there are concerns about the state of the treasuries, I'm wondering how efficient this approach is in improving the situation.

We firmly believe that a specialized infrastructure to harness community creativity can significantly benefit the network. Currently, the treasury primarily grows from transaction fees and slashing, with other sources playing a minor role. Changing these sources is cumbersome, necessitating extended discussions and complex development, as illustrated by this example: https://forum.polkadot.network/t/kusama-treasury-follow-up-analysis-continued-budgeting-incompetence/3143

Our solution offers a platform for community-driven initiatives to augment the treasury without necessitating core protocol alterations. This concept could further extend to areas like governance incentives as well.

Have you liaised with potential teams or projects regarding deploying on your parachain? Beyond "making contributions to the network", what incentives are there to deploy on your chain, given the need for smart contract approval?

We've engaged with various stakeholders, such as developers and delegation collectives. Most concur that there's a lack of a neutral space to materialize ideas that can address specific network challenges. Deploying on existing parachains often leads to treasury contributions in native parachain tokens, rather than DOT/KSM.

This example is worth exploring:
https://app.polkadotbuilders.xyz/

The tool was designed for building a Polkadot builders DAO. However, since it was deployed on Moonbeam, the treasury funds are denominated in GLMR, rather than the expected DOT or KSM.

On the technical side, if an application requires advanced XCM interoperability, current solutions like ink! don't natively support XCM calls. Thus, developers often default to pallet development, but this necessitates having a ready-to-deploy parachain and the associated infrastructure. This complexity can discourage pallet developers to being their ideas into life.

Our chain's primary incentive is its alignment with Polkadot's core values and its dedication to benefiting the Polkadot network. It could even evolve into a common-good parachain if the community so decides. The restriction on smart contract uploads ensures that the chain remains a platform for community-approved, common-good applications.
Something we anticipate is that If we permit the upload of any smart contract without restriction, the parachain could morph into a general-purpose smart contract platform, which deviates from its original intent. However, that doesn't preclude the project from evolving in that direction. Governance for this parachain will be overseen by relay chain governance. Thus, if the community believes this approach best serves the network's objectives, it's within their purview to remove the authoring pallet used for uploading contracts (alongside the proxy pallet implementation). This restriction emphasizes our intention to engage the community in determining which applications align with the network's broader good.

Third, could you clarify what "a pivotal role in making contributions to the network" entails?

The statement wasn't meant to suggest a drastic protocol change. Rather, by providing an infrastructure for common-good apps, we're opening avenues for developers to contribute in ways currently unavailable. Reflecting on the treasury's challenges, our main inspiration, such applications could revolutionize how the community engages with app proposals and developments that run parallel to the protocol, all for the network's benefit.

Please let us know if this response adequately addresses all of your questions and concerns.

[Noc2]

Thanks for the application. As pointed out by @semuelle could update the deliverables/milestone tables in a way in which they only contain the concrete, unique technical development that you need to do as part of the grant. Feel free to include the things that you listed above and with as many details as possible. For example, "configure" could mean a lot of things, but generally, that's not something that we would support via grants as long as it's not helpful for other projects, since everyone has to configure his parachain, etc. Regarding randomness, have you looked at https://github.com/Cardinal-Cryptography/substrate/tree/randomness-beacon-m1/client/randomness-beacon as well as the other work by Aleph Zero?

[Albertpolkadot]

Hello, we appreciate all the feedback provided in this grant.

We value your insights and have decided to close this grant for now, to re-organize our development milestones and the design around our infrastructure components. We aim to resubmit a more robust proposal in the near future.