Disposable Parachains (for Airdrops and other ideas)

I had some unorganized thoughts I wanted to share, especially with all the talk about $DED, and what an efficient airdrop might look like on Polkadot.

I want to start by saying that I truly believe most airdrops are just ponzinomics. I don’t necessarily support or like the airdrop culture or think it is healthy for an ecosystem. That being said, it is an interesting technical problem.

For context, doing an Airdrop on Polkadot is inherently harder than other chains. This is because, unlike many other blockchains, Polkadot takes care to ensure that its state properly scales. It does this through things like the existential deposit and other storage deposits, which is also often the blocker for people to make large scale airdrops work.

I want to make clear, this is by design, and it seems it is working well.

But let’s brainstorm, given these constraints, how you could make the largest and most efficient airdrop possible on Polkadot.

My current answer is: Disposable Parachains.


A disposable parachain is a parachain with a short lifetime.

This means that after some relatively short period, the entire parachain, its state, and everything else can be completely dropped.

This is quite the opposite in thinking to most blockchains which are expected to live forever. If we look back to why Polkadot has these limitations on storage, it is precisely because we are constantly concerned with the long term scalability of the chain.

But a disposable parachain does not have this problem. A disposable parachain can be extremely “inefficient”, for example:

  • having no existential deposit
  • having lots of items in storage (like the airdrop information for a 1M accounts)
  • fixed fees / weights, to simplify development
  • etc…

So what does this look like in the context of an airdrop?


Let’s imagine we wanted to create an airdrop for DOT2, which is exactly 1:1 for DOT to all existing DOT holders. At the time of writing, this needs to support 1.2M users.

The Assets Parachain / Assets Pallet is just not set up for this kind of task. Each user who wants to recieve the airdrop on the Assets Parachain needs to have an existential deposit on that parachain, and perhaps other deposits needed to hold the storage of that asset. For the person who is executing the airdrop, this is a massive up-front cost that would prevent the airdrop all together.

The more scalable solution would be to create some kind of merkle trie which contains all of the claims for tokens into a single merkle root, and then individual claimants could provide proof of their claims and mint the tokens themselves paying their own fees.

In this case, everyone has the “opportunity” to claim their DOT2, but not everyone will do it. Some users have such a little amount, it is not worth it for them to go through the process. Some users are not active, so they won’t claim. Some users don’t see value in the token, so they won’t claim.

IMO, this is all good. All the different ways users can filter themselves from an airdrop that they dont find valuable is better for the whole system and bloat. Having a “reactive” airdrop is much better than a “proactive” one, and is much easier to scale. Most airdrops do this through a claims process.

But now we would need to create and launch some custom Airdrop pallet on the Assets parachain. More than that, we will need to keep track of all claims from users for the lifetime of the airdrop to prevent someone from double claiming. In the case where 500K people claim the airdrop, we would still need to manage those 500k storage entries, which will bloat the chain and the chain history, especially if there will be multiple airdrops in the future.

This is where the disposable parachain comes in.

Polkadot is already designed to shard data and logic to parachains. The entire state of a parachain is boiled down to a single root hash, and that root hash is stored on chain. That means we could have a parachain, handling billions of airdrops, and the impact onto Polkadot is the same as any other parachain.

So imagine, for DOT2, we launch a disposable parachain, which holds all the data about the airdrop for DOT holders. We can store all the data we need on this parachain to make the airdrop work. Users could even pre-trade the token on the parachain, allowing small holders to sell their bags to those who are actually interested in claiming the token.

The parachain would be set up so that it is the owner of an asset on the Assets Parachain. Users would be able to trigger a claim on the Airdrop Disposable Parachain, which will send an XCM to mint the appropriate asset on the Assets Parachain. All fees required to do this need to be covered by the claimant, and can be included in the XCM message. Users who are interested in claiming their token go through this process, and ultimately get their final tokens minted on the Assets Parachain where the tokens are now officially in the Polkadot ecosystem, and should be well supported.

After some period of time, let’s say 6 months, the disposable parachain will “kill itself”, or just let the community decide how long they want to keep it around. But the idea is that once the parachain is no longer needed, it can just be “forgotten” and all of the state and bloat can disappear with it. The only impact it leaves on Polkadot is its state root, which can also be cleaned up if needed.

In this case, we offload the decision making of the airdrop to the users, and do so in a way which leaves no historical debt to Polkadot or any long term parachain.

I apologize if this post is poorly written, but I just wanted to get the ideas down and start a discussion.

16 Likes

Very nice “pull” concept @shawntabrizi!

How can the owner of the Airdrop Disposable Parachain estimate their CoreTime costs over N=6 months? With CoreTime, under what conditions can it be guaranteed to be upper bounded to be less than the “push” method costs?

This “pull” method, whether from the Airdrop Disposable Parachain or some centralized web site, does not guarantee a 1:1 “fair” distribution at the end of the process unless 100% of the DOT token holders go through process during the claim window. With a full commitment to having a fair 1:1 DOT:DOT2 distribution where the power having DOT2 is the same as DOT, the “pull” method is a non-starter. Only the “push” method can guarantee a fair distribution. With the .1 DOT ED on AssetHub it was expensive (125K DOT), and now it can be 10x less expensive (.01 DOT ED => 12.5K DOT). So with the cost of 125 utility batches of 10K asset.mint or asset.transfer operations, it totals out to less than 20K DOT, closer to 15K DOT if you don’t pay anyone.

But lets say 100% of the DOT token holders go through the “pull” process somehow, can you estimate the monthly costs over 6 months to:
(a) subsidize all 1.25MM end users for the XCM operation
(b) subsidize the airdrop operator to buy CoreTime
(c) pay the engineers who have to build the Disposable Airdrop parachain
(d) pay operational costs of running the Disposable Airdrop parachain
(e) pay support people to run the Disposable Airdrop parachain

Would you think a Treasury proposal to do an Airdrop Disposable Parachain with (a)-(e) be reasonable? If not, why not? Is the cost of (a)-(e) is greater than 16K DOT, is it worth it relative to the “push” method?

If you can do it for less than 20K DOT, can you submit a Treasury proposal for this and share your github link for your Disposable Airdrop parachain? I think you can run it on Rococo which has CoreTime sales like this week, which is super exciting and can enable you to follow up and demonstrate the “pull method” in practice this month.

@decentration is running through snapshot+distribution tests on Rococo this week:

Here is the $DED technical chat:

It would be wonderful to have both the push solution (which is mature) and this kind of pull solution (which is a great tutorial for CoreTime, and can be made mature this year usefully).

1 Like

Thanks for your reply @sourabhniyogi

First noting “fair distribution”:

I think a fair distribution is giving everyone the opportunity to claim DOT, not necessarily putting it directly in their hand, especially if it involves needing to give them DOT for an ED.

Afaik, most airdrops require a claims process and some fee to complete that process. If a user does not recieve enough in the airdrop to justify paying the fees, they will not claim. Similarly, if a user does not receive enough DOT2 to justify transferring the ED and XCM fees, thats their issue imo.


Next let’s chat about fees:

I don’t really have any estimates on this process, and there are some unknowns since on-demand parachain stuff isn’t live yet and we don’t know the market, but I think we could approach this from a theoretical perspective.

Fees are proportional to the resources consumed on the blockchain. If we can find a process which uses less resources, it should ultimately lead to less fees.

In the case of airdrops, there are lots of “noise” which leads to the high fees you mentioned:

  • some users will not claim
    • because they did not get enough
    • because they are not active
    • because they do not care
    • etc…
  • some users will claim only to instantly sell to someone else

Using the disposable parachain, all of this noise could be done on this diispoable shard, and then dropped after the claim process is done. In this case, all of the crazy activity, and unused data leaves no long term impact onto important chains like Polkadot or Assets Hub. So from a resource perspective, this process should consume far less resources than a “push” method, and thus should be cheaper.


Other considerations:

For the sake of argument, let’s say the disposable parachain method is more expensive, I would still argue it is the better process to follow if you care about Polkadot. The disposable parachain process minimizes the waste and footprint on long term chains, and this makes archive nodes smaller, reduces transaction bloat and tx fees.

Also, it is possible to configure the Disposable Parachain in many ways which make approaching the airdrop much more friendly for users. For example, you could create systems which fix the transaction fees, ED requirements, and more. Normally these would be “bad practices”, but in the context of a parachain that has a short lifetime, we might be able to ignore these things.


Items missing in your estimate:

  • During the process of an airdrop, you should expect the transaction fees on the chain to shoot up due to the activity. Not to mention that if multiple airdrops are happening, you will not be able to scale on just a single parachain.

  • You are not taking into account the storage deposit needed to support keeping in storage the information about the 1.2 million users airdrop amount.

  • You are not taking into account the transaction fees for cleaning up the data after the airdrop is done. Likely there will be hundreds of thousands of accounts who never claim their token for many reasons.

  • Ideally, a disposable airdrop parachain template would only need to be created one time, and so there is not long term costs here for engineering.

  • Platforms like Tanssi could make launching these disposable parachains super easy, and maybe even a feature they support out of the box.


In any case, I am not saying that the “push” method doesn’t work, I am just theorizing what would be the most sustainable and scalable way to do airdrops in the Polkadot ecosystem.

Polkadot is unique in the fact that it already has infinite scaling through the use of data and execution sharding. It seems natural that we take advantage of these scaling features to enable these kinds of high throughput activities.

Finally, as an engineering in the Polkadot ecosystem, we are always thinking about long term sustainability, and have built frameworks with this in mind. This same thinking usually comes at a cost of user experience. However, if we shifted the thinking to something like a disposable parachain, we could also shift our thinking about these best practices, and make decisions which prioritize only the user experience.

3 Likes

That’s an interesting technical concept but I can not help but think it’s kind of a telescope to look at a bacteria.
Why: an airdrop to the exhaustive list of addresses of a blockchain doesn’t really make any sense, airdrops are popular because they reward certain past actions.
It wouldn’t make sense to replicate the security level of a blockchain for a temporary application to check an airdrop eligibility. That application would anyway have been filled without this security level. Unless you’d fork entirely Polkadot.

As we don’t have (yet) possibility to read storage from XCM, lower security level solutions that fit these kind of actions imo:

  • a smart contract with an oracle, self claimable
  • a smart contract token distributed by the issuer
    , this is costly for the issuer but less than maintaining a temp blockchain and the smart contract supports the storage
  • a smart contract with mapping of addresses/balances, containing both asset creation (one time) and minting (on call) through pallet XCM on AssetHub
  • a very simple hosted app minting token from a connected wallet and a Polkadot storageAt RPC call (mind your server security, it contains the pk of the asset issuer)

Side topic it makes me think about (doesn’t solve the storage problem): system parachains should have a way to identify an ED on Polkadot as self sufficient for an address to be considered existent in storage, this would be so much easier for many kind of adoptions (much beyond ponzi coins).

I think this is a great idea. Would you want to build this disposable parachain template and get a Treasury proposal going (on Kusama, with CoreTime arriving there)? Its an excellent way to teach us Coretime and best practices of AssetHub XCM.

[Many would probably buy into “a fair distribution is giving everyone the opportunity to claim DOT”. Some would not, and say the pull method leads to the same kind of usual ponzinomics whereas the push method leads to actual 1:1 outcomes that have DOT2 power matching DOT power exactly, to the point where DOT2 governance can literally be done by OpenGov.]

For fees shooting up, the december 20-24 dotordinals activity shows that its unlikely to happen with this single airdrop, but we’ll check on Rococo.

https://twitter.com/XiliangChen/status/1737752114020192502

I must be misunderstanding something – do you mean in the disposable parachain? After 6 months the whole parachain is disposed of, so why clean it up. I should think the disposable parachains just has the “fair” amounts in the genesis block, and there is nothing to clean up. The whole solution is a more secure way to have the disposable parachain represent the DOT snapshot and the only storage to be managed is a storage map of “did this user do their claim”. You shut it down after 6 months. What did I miss?

@bLd

My consideration for using a disposable parachain is not about security, but about the fact that the footprint is leaves behind is small and fixed size.

For any airdrop to work, somewhere there needs to exist the potentially millions of data points for the snapshot of what tokens will be distributed. My main consideration is that most of this data is probably wasteful, as there might be a lot of “dust accounts” or consolidation of tokens directly after the airdrop.

Smart contract chains should NOT be a good home for this kind of activity because they should be designed to be resilient to spam and other DDOS attacks. IMO, a chain is either priced correctly and does not support airdrops well, or priced poorly, and is vulnerable to such attacks. Many chains which are currently the home to lots of airdrops basically have no consideration for the long term sustainability of their network.

The use of a disposable parachain takes advantage of Polkadot’s scaling solution to shard the data and early execution logic of the token off to a parachain. Since this parachain is temporary, we will ultimately need to mint the tokens onto a permanent home like the Assets Hub, but this can be done via XCM. Finally, at the end of life for the disposable parachain, collators just shut down and all of the “wasteful” data is also disposed of.

This lifecycle is kind of a unique to Polkadot because it is designed to be able to spin up new blockchains very quickly. We just haven’t really considered what we could do if we spin them down quickly too.

@sourabhniyogi

I must be misunderstanding something – do you mean in the disposable parachain?

No, those points I was taking about estimate costs of doing a “push” distribution.

2 Likes

I agree that storing this amount of information on-chain permanently is definitely not sustainable.
My 2 cents are just that even a disposable chain is way overkill for this kind of trivial usage.
So the viable solutions I see would be off chain:

  • an hosted app with wallet connection and RPC call
  • a smart contract with oracle calling RPC (only querying Oracle and minting from callback through XCM)
1 Like

Ok

With a push distribution, the .1 => 0.01 ED of AssetHub is supposed to model the storage costs, correct? No one can do this with precision, so this seems to be the appropriate logic: Underestimates mean that state grows faster, although not unbounded - effectively an economic subsidy on activity. Overestimates mean that the state grows slower - effectively an economic depressant on activity. Check?

In the push method, there is no cleanup because there is no claiming and nothing to clean up – all 1.25MM accounts get the ED and the fair coin.

@decentration may or may not have managed to slow AssetHub for Rococo to a crawl around 3,640,390 to 3,640,393 through the push method

Not sure if Is this related, it might reveal a bottleneck somewhere.

parachain collators can often stop working, any number of things could stop it persisting and producing blocks, hard to tell unless you can see the logs and look at the error message. if there is only 1 collator then the block production stops. but because its based on aura, it is fine to not produced blocks for any period of time. It can then just be restarted. so its not a “bricked chain” situation.

1 Like

Hey shawn, interesting ideas, which i resonate with in regards to storage efficiency.

I am a technical steward (and midwife) of this DED baby. here are some values for the DED experiment:

  • fair distribution
  • promoting polkadot
  • keeping in alignment with polkadot (being as close to DOT governance as possible.)
  • community driven (similar to above, initially)
  • exact replication of DOT distribution.
  • bringing life to asset hub

some of these values crossover, some more concrete, and some more of a priority than others. such as fair distribution, community driven, promoting polkadot, high priortiy, perhaps bringing life to asset hub is least concrete, but exact replication of DOT is also a core value, because if we made it a ‘pull method’, then “for alive, active and able people, claim your DED now.” This is fine, but it is not as fair as leaving it for everyone. Also DOT does not have this value. People that are dead, inactive and unable over x period of time, can also be sure that their DOT will persist.

As perhaps heuristic this approach is, its aiming to be values driven, i hope you can see how this is being considered to filter some decisions in a community driven way.

Suppose the decision to not tinker with DOT distribution has been made where we shall do 1:1 because we believe it falls within the values and purpose of the project, more than other ideas.

If its on AssetHub, the EDs would have to be paid and cost of minting the asset in every account. to fulfill the core value, then that must be done. fine. The trade off is it adds to storage.

Given this, where storage efficiency is not the priority, what is another viable, and perhaps more elegant solution for distributing, where it remains close to polkadot and fulfills the criteria?

re: launching a parachain off the bat, we felt was moving away from polkadot core community, so therefore a token on AH was the nearest to polkadot we could be. however if we left the governance of this parachain to DOT holders only, that could bring it closer to polkadot.

re: lauching on moonbeam, same idea, it becomes less polkadot.

Nice idea!

However, I am wondering how does the disposal take care of the following comment raised by you earlier.

If we don’t need this data in case of the disposable parachain, can’t we remove it from the Assets Parachain as well?

Maybe I am missing something, but won’t a smart contract on the Assets Parachain handle this use-case better?

The smart contract data, even after it is “deleted” will exist in the blockchain history, and affect archive nodes, full nodes (with data in the blocks), etc…

A disposable parachain does not have this issue since its only footprint on history are state roots.

Perhaps i am concerned about something which is not an issue, but this is considered state bloat to me too.

Given this, where storage efficiency is not the priority, what is another viable, and perhaps more elegant solution for distributing, where it remains close to polkadot and fulfills the criteria?

I think that you can make any decisions for one-off airdrops.

My thoughts here are about how many future airdrops could work.

I assume most teams will not get approved for 12,000 DOT to airdrop their token.

Beyond something like what I have described, the next best answer is to have a parachain dedicated for all the degenerate blockchain stuff you want, again with no ED, no storage limits, low fees, but “permanent”.

Its not really viable for a long term strategy, but has not stopped it from working in other places.

Otherwise, a custom pallet with these features in mind and deployed onto the asset hub about an airdrop could probably improve the ergonomics.

Or yeah, a smart contract platform itself on the asset hub.

1 Like

Kindly share your thoughts on this

Re-reading most of this thread, I think the above is the single most compelling argument to rethink how we do airdrops going forward. DED had to make a choice on short notice, and it is fair and good for them that it got approved, but I also worry that no every airdrop can and should expect an arbitrary amount of support from the treasury to fund ED on AH. Even if the treasury is happy to spend all of this money, we can do better.

Possibly a solution to at least the ED issue is to build a mechanism whereby AH can let an account exist through the virtue of having DOT on the relay (or ideally any other system) chain. It would be quite complicated (esp. taking things like Crowdloan and NominationPools and such into account), but at a conceptual level, this statement makes sense to me: “one ED should be enough across all system chains”.

Even if the ED issue is solved though, a disposable parachain is likely needed as a PoC for general degenerate experimentation.

3 Likes

I appreciate the idea of “Disposable Parachains” and believe it may have broader applications. Factors such as complexity and setup costs are significant considerations. Perhaps there’s potential for improvement if these parachains could remain idle instead of being completely terminated.

What if we could have a storage item/child tree marked as “disposable,” signaling to archive nodes to forget deleted data associated with it. I am not sure though if this conceptually right. For airdrop pallet, for example, we could have a maximum lifetime for each airdrop and even incentivize actions like transfers within the pallet through transfer-out fees or transaction fee.

1 Like

I don’t think the parachain needs to be “explicitly” terminated.

If we can make the disposable parachain has an open and permissionless collator set, then the chain will continue to exist as long as there is at least one collator with the necessary data to produce a new block.

Hey, so I have been giving some thought to this post as I had to work on an airdrop that encountered a significant cost through ED.

So this discussion makes sense so far to me and I can imagine some nice use cases, therefore I would like to get your thoughts on two particular areas:

  • Would it not make sense to dump all the data (for example: airdrop accounts and balances to be airdropped) directly on storage and just search for that map for verification instead of going for a merkle approach?

This would be of course, really inefficient storage related (which we might not really care that much since it will be eventually wiped) but it would make the verification really simple while the merkle solution would imply at least an on chain verification making the claim itself more expensive to the user. This is assuming that we move the root and proof calculation off chain, otherwise it would be even more expensive because of the proof.

If this somehow makes sense, do you have any thoughts on an efficient way to dump all this data into storage? I would like to potentially avoid batch calls (because of tooling) or genesis (to keep the chain generic and be able to handle multiple airdrops).

  • Also, would like to get your thoughts on how a “elegant” way of killing the parachain would look like. I asume it would imply pausing txs, the downgrade of it, killing or leaving idle the collators but I am sure that I am missing some possible interesting operations to be performed (and ideally automated at “disposal” time)

Thanks!

1 Like

@metricaez

I think using a merkle trie is the efficient way of putting all this data into storage.

A merkle trie allows all airdrop data to be represented on chain with just a single hash. If you want to allow other users to initiate airdrops on a disposable parachain, this has to be the best way forward, otherwise, an airdrop for 1M accounts, would require 1M accounts worth of data being sent to the chain.

Of course there are some minor ways you can optimize that, for example uploading airdrop data in chunks:

fn insert_airdrop_data(input: Vec<(T::AccountId, BalanceOf<T>)>) { ... }

But this doesn’t solve the problem of making thousands of transactions for the airdropper. You could do this option as a quick proof of concept of the ideas, but i doubt that this approach will last long.

I have some code on a proving trie here: Create a Generic Proving Trie by shawntabrizi · Pull Request #3881 · paritytech/polkadot-sdk · GitHub

I am def changing my stance on this chain needing to be “explicitly” killed.

I have more thoughts on lifetime here: Lifetime | DropIt

I think the best thing is to let the chain have an open collator set, where anyone could produce a block. Then the chain “dies” once everyone in the world chooses to stop producing blocks. And even in that case, as long as someone has the latest block state, they could come back and produce a new block. At that point, the whole lifetime of a disposable parachain is left to economics of the value it brings vs the cost it takes to maintain.

I think with agile coretime, the whole concept of a chain spinning up and down becomes a reality, and I think that is really what I am trying to capture in this experiment.

2 Likes

Yes.

I do think O(1) parachain forks make sense: 10 new node become semi-full nodes of parachain X and parachain Y, after which they abandon those chains, and start parachain Z whose state contains the state of X and of Y as subtrees. This sort of thing becomes easier if you can “mount” multiple storages into a namespace, or just handle the storage directly without all the silly namespace stuff.

Anyways even if this extremely optimized case, if your goal was merely to have users voluntarily copy some data from X and Y into some other parts of the state of Z, then you’re better off doing that on the user’s side. Those accesses into X and Y as subtrees of Z need Merkle proofs too, and those Merkle proofs are almost the same size as the Merkle proofs into X or Y as independent chains, if you fixed a specific block for the proofs.

Anyways…

We’ll presumably want to run validator ellections on chains forked off from the staking chain.