valentinmadrid
commented
1 year ago One more update on that mechanism: It can't be excluded that a malicious actor runs a virtual server with a script to grind a somewhat small vanity keypair that requests a first allotment of SOL in loop, and requests airdrops with all of their keys every time the minimum slot for a new request for a single Keypair is reached.
Maybe a good solution would really just be to have a regular POW Faucet that created receipts but in longer time intervals (like 5-10 minutes) for a bigger allocation. This would be very low usage of state compared to other programs, while being sure there's actual POW behind every request. This could also be combined with dynamic determination of the airdrop amount based on the u128 derived from the first 16 bytes of the public key and the total amount of SOL inside of the faucet. This would also mean that a user can specify a deterministic airdrop output value which he will then "mine" for.
Problem
The current Devnet POW faucet mechanism has led to an unintended consequence: the chain is inundated with a multitude of new "receipt" accounts indicating a Keypair had already been "mined", leading to unnecessary bloat of state. To address this, @t-nelson had an idea of an alternative mechanism:
This proposal introduces a revamped mechanism that not only addresses the chain spamming issue but also ensures a more equitable distribution of SOL based on computational requirements. Another goal of this new system is to deter users from leaving scripts running on servers, ensuring that such actions are not economically viable and instead are being used for short amount of times by Developers that actually need Testing network SOL.
Proposed Mechanism
Airdrop Request: A user initiates an airdrop request to a specific address, denoted as A.
Address Conversion: The program will extract the first 128 bits of address A and convert it into a u128be integer, denoted as I.
Dynamic Allotment Function: The integer I will be used as an input to a function, denoted as F(I). This function will produce two outputs:
B: The balance of SOL that the address is allotted. T: The timeout (in slots) for which the address can request SOL.
SOL Request: Address A is allowed to request SOL up to the limit of B. This request must be made before the time period defined by the original request slot (S) plus an additional duration (T).
PDA Storage: The remainder of B and the value of S + T are stored in a Program Derived Address (PDA) that is keyed off the requesting address A.
Key Feature: Dynamic Allotment
The uniqueness of this mechanism lies in the dynamic allotment of SOL based on the value of I. Addresses that map to larger integer values will receive a smaller, yet more frequent allotment of SOL. Conversely, addresses with smaller integer values will receive a larger, less frequent allotment.
For instance, if a user desires a larger allotment of SOL, they can generate a vanity key with a smaller integer value.
The value of I must have a capped maximum output to prevent individuals from generating excessive on-chain accounts and causing spam.
Potential additions
If this solution is subject to lots of spam, it would always be possible to implement a Key-ageing reputation mechanism, but let's first hope that solution works.
Who would work on this ?
I could work on the on-chain program and make a PR to interact with it via the CLI with a separate command like "pow-airdrop".
Please let me know of any comments regarding this matter.