Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/plmc 344 Dispenser Pallet #225

Closed
wants to merge 8 commits into from
Closed

Conversation

vstam1
Copy link
Collaborator

@vstam1 vstam1 commented Apr 9, 2024

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 the set_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 the ChargeTransactionPayment extension, that is responsible for charging fees. So in Theory, just wrapping this ChargeTransactionPayment extension with SkipCheckIfFeeless 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:

  • Change the Admin account?

@vstam1 vstam1 changed the title Feature/plmc 344 faucet deploy Feature/plmc 344 Dispenser Pallet Apr 9, 2024
@vstam1 vstam1 closed this Apr 9, 2024
@JuaniRios JuaniRios deleted the feature/plmc-344-faucet-deploy branch April 9, 2024 13:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant