Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
This PR introduces the faucet-pallet, that can be used to get locked PLMC tokens for account with a valid credential.
Why?
To enable initial user growth on the Polimec network, we allow a certain amount of users to claim tokens.
How?
The pallet has an pallet account that can be funded to distribute tokens. The token amount that can be claimed in specified in the
ClaimAmount
storage item and can be set by an admin account using theset_claiming_amount
extrinsic. The initial amount is determined by the InitialClaimAmount.A user can call the
claim
extrinsic to claim tokens. There are a couple of checks to see if the user is able to claim.First we check if the user has a valid credential and then we check if the Did in the credential has already claimed tokens. We also check if the funding wallet still has tokens to distribute.
Signed Extensions for free execution
How do Signed Extensions work?
Every extrinsic that is submitted to a node, is first validated before its added to the transaction pool and broadcasted to other nodes. The validation logic is written in Signed Extensions. If an extrinsic is valid, is being broadcasted to all other nodes. The validity of extrinsics is being tracked while its in the transaction pool (it can get invalid by passing its mortality time for example). Once a collator starts building a block with this extrinsic, it first executes the pre_dispatch check, that should have similar logic as the validation check.
How to use SignedExtensions for free execution (in theory)?
Parity introduced the new SkipCheckIfFeeless signed extrinsic which is a wrapper around other signed extensions. A call can be marked as potentially free using
feeless_if
(see claim extrinsic). The feeless_if implementation has some logic attached to see if the call is actually free. If feeless_if returns true, SkipCheckIfFeeless skips the inner signed extension check. This can be used to skip theChargeTransactionPayment
extension, that is responsible for charging fees. So in Theory, just wrapping thisChargeTransactionPayment
extension withSkipCheckIfFeeless
and correctly implementing feeless_if, should make the call free.Free execution in practice?
SkipCheckIfFeeless doesn't work out of the box. There were two problems we ran into:
SkipCheckIfFeeless did not implement the validate function, which would skip the validation logic for fee payment for every transaction. So transaction were only checked for fee payment in the pre_dispatch function, which opens up a transaction pool DoS attack vector. We fixed this by implementing this Signed Extension ourselves with the validate function. Parity also implements it now: Fixes validation for
SkipCheckIfFeeless
extension paritytech/polkadot-sdk#3993.The CheckNonce extension has a check that the user paid for the Nonce storage by checking if the accounts providers and sufficients are non zero. For new account these are zero, so we had to skip this check for the claim call. So I implemented the CheckNonce signed extension myself, with this extra logic. Parity acknowledged this problem and are discussing a general solution in
CheckNonce
should not enforce the account creation requirement for feeless calls paritytech/polkadot-sdk#3991. I think we are fine with our current implementation, as users actually receive tokens that will be locked/vested over a period of 4 years and the accounts able to get the tokens are limited by the credentials.Testing?
Normal unit tests + a test to check the Signed extensions in the integration tests.
Screenshots (optional)
Anything Else?
Todo: