Composable’s Implementation of the Crowdloan Rewards Pallet
Disclaimer: Information as of Mar 7, 2022. For the most recent updates, dive into our comprehensive documentation here
The Crowdloan Rewards pallet enables those who contributed to the Composable and Piccaso Crowdloans to claim their reward. However, a key challenge for this pallet is that users need to be able to make unsigned transactions for their initial claim without any tokens for gas. However, doing so would leave Composable vulnerable to DDoS attacks. This article gives an overview of the crowdloan pallet and discusses the validation logic Composable has developed to avoid spam.
Crowdloan pallet overview
The pallet operates in two main phases: the pre-initialization population and post-initialization association and claiming phases.
Population
The population phase exists with the primary objective of populating the reward accounts of the crowdloan and eventually initializing the pallet. During this phase, the only transactions that will succeed are populate and initialize/initialize_at. For any of the transactions in this phase to succeed, they must be signed by an admin origin that is configured by the runtime. Once initialized, the pallet will move to its post-initialization phase.
Account Association and Claiming
Once in the claiming phase, the pallet’s primary objective shifts to enabling contributors to associate their reward accounts with their ETH or relay chain accounts and then allowing them to claim their reward. When contributors first associate their accounts, they will receive a percentage of their total reward. After this association, contributors can return once per vesting period to claim another portion of their reward. These vesting periods are measured in Vesting Steps, which are a number of blocks relative to the block that the pallet was initialized in. Successful calls to associate and claim will not incur a fee.
Unsigned Transactions and Spam Prevention
Generally, transactions are signed with some fee which ensures identity and prevents transaction spamming. However, in the case of the Piccaso Crowdloan, users won’t yet have PICA to sign transactions with until they associate their rewards and remote accounts. This means that the pallet must be able to accept unsigned transactions for calls to associate. Consequently, we need another method to handle the validation of our unsigned transactions.
Enabling unsigned transactions on our pallet opens the network to potential DDoS attacks. As we all know, DDoS attacks have remained an issue for Web 2 applications. These attacks are so effective on Web 2 due to the centralized nature of Web 2 projects, with the webserver often being the central point of failure.
Although Web3 offers some inherent protection through decentralization, it is, however, not immune to DDoS attacks.
In late 2021, both the Solana and Arbitrum One networks suffered from DDoS attacks. In Solana’s case, it resulted in a hard fork of the network to roll it back to the block where 80% of the validators agreed on. In the case of Arbitrum One, the network experienced a 45 minutes downtime. See here for a detailed survey from Halborn.
With the threat of DDoS attacks still existing on Web3, adequate measures must be taken to prevent such attacks in our networks. Signed transactions are typically the first line of defense. However, as discussed above, there is a need for us to have unsigned transactions for initial reward claiming, which makes the pallet vulnerable to DDoS. A malicious user could perform a DDoS attack by filling the block with their transactions and making the network unavailable to users at no cost to them.
Composable’s pallet implementation enables unsigned transactions while preventing spam.
To negate this vulnerability we otherwise ensure the validity of unsigned transactions. An easy way to accomplish this is to require proof and other relevant information in the transaction payload. With this information, it is possible to validate unsigned transactions and to prevent invalid transactions from succeeding.
To counter the possibility of a DDoS attack and to ensure the validity of transactions on the pallet, we take advantage of the ValidateUnsigned trait from the frame_support crate owned by Parity Technologies. Composable formulated an implementation of this trait to prevent spamming. Once implemented for a pallet, the ValidateUnsigned trait will execute some validation on the transaction payload before allowing it into the transaction pool.
Our implementation of ValidateUnsigned in the Crowdloan Rewards pallet ensures the following:
- The transaction payload contains the necessary information for validation (a reward account ID and proof) (#L518 in the codebase linked above)
- The pallet has been initialized (#L523)
- The reward account associated with the ID has not been associated with a remote account. If an account is already associated, their transactions should be signed (#L527)
- That a remote account can be retrieved from the valid proof (#L530)
- The reward account has a positive amount to claim (#L537)
Failing any of these will prevent the transaction from being added to the transaction pool. This means we have blocked an avenue for DDoS attacks and also ensured the identity of the user.
Summary
The Crowdloan Rewards pallet enables contributors to claim their reward and get onboarded to the network. However, coming to the network for the first time, users won’t have existing funds to sign transactions with. Consequently, extra caution is needed to validate transactions and avoid spam. We take advantage of ValidateUnsigned to prevent invalid transactions from being added to the transaction pool. This form of prevention can easily be applied to other pallets in similar scenarios.
If you have any questions on this pallet or anything else related to Composable, head over to our Discord. You can also reach out to me at connor.d@composable.finance
Citations
Yoachimik, O., & Ganti, V. (2022, January 10). DDoS Attack Trends for Q4 2021 [Review of DDoS Attack Trends for Q4 2021]. Cloudflare Blog; Cloudflare. https://blog.cloudflare.com/ddos-attack-trends-for-2021-q4/
Behnke, R. (2021, October 19). How Blockchain DDoS Attacks Work [Review of How Blockchain DDoS Attacks Work]. Halborn; Halborn. https://halborn.com/how-blockchain-ddos-attacks-work/
