feat: mainnet beta drip faucet

[Kouteki]

Description

As a new gno.land user with no prior GNOT token allocation ISBAT get enough tokens to use dapps, explore and participate, so that I could become an active community member.

Acceptance Criteria

• Public, permissionless drip faucet, accessed via https://faucet.gno.land/
• Dedicated address for the faucet, whitelisted for token transfers
• Fixed X GNOT amount per request
• If an address has more than Y GNOT, refuse the transfer

Misc

• The faucet token allocation will come from the GovDAO's initial token allocation
• GovDAO will have the ability to top up the faucet address via governance vote

[zivkovicmilos]

@sw360cab
We need to set up some kind of middleware that requires a GH login or something similar

[kristovatlas]

As Milos alluded to, we need to mitigate the risk of attackers draining the faucet by repeatedly creating new addresses and withdrawing to them.

This basically requires some kind of proof-of-humanity mechanism, like an account on a website that is difficult to automate, a sophisticated CAPTCHA, etc.

[kristovatlas]

Fleshing out a few more ideas, here:

Rough threat model:

There are at least 2 reasons for an "abuser" or "attacker" to hammer the faucet:

• Receive non-transferrable mainnet tokens in anticipation of future exchange value
• Grief the faucet for legitimate users, either to be annoying or to extort the project

We want to make it reasonably convenient for legitimate users to receive a "reasonable" quantity of tokens to experiment on mainnet.

To limit the damage of exploiting the faucet, the faucet account should have a limited quantity of funds in it at any given time, and be topped off by a transferability-whitelisted treasury account that is controlled by multisig humans using air-gapped devices.

Lots of blockchains are recently using a variety of methods simultaneously for users to qualify for a faucet receipt.

One is to allow a one-time or 1x/day faucet withdrawal by signing from an address of an ideologically aligned blockchain. For gno.land, this could be ATONE or or maybe ATOM.

Another is to allow faucet receivers to authenticate through an existing platform that is already resistant to bot registration and which aligns with our likely mainnet users. A lot of users will have GitHub accounts, and GitHub does take significant steps to prevent bot signups, including email verification, CAPTCHAs, IP limiting, etc. Still, the street value of GitHub accounts is estimated somewhere in the $0.50 - $2.00 range. And if dApps decide to go for mainnet beta instead of the latest testnet, some of those dApp users won't have GitHub. There are various tools that facilitate authenticating via GitHub and allow you to customize such parameters as minimum account age, activity, etc.

We could also potentially run multiple faucets -- e.g. one that sends out more funds, has more funds available, but requires higher degrees of authentication; and another that has a low bar but has low funds. (In my experience, the latter category typically gets drained quickly.) Some blockchains have recently utilized a PoW mechanism in the browser for low-barrier-to-receive faucets.

Why receive mainnet faucet funds: I'm not sure there's a lot that you can do with mainnet experimentation that couldn't be accomplished on a testnet, so I would give out mainnet faucet funds sparingly. Perhaps take the gas required by an average gno.land tutorial and multiply that by 10, as a starting quantity to send in any given day. Maybe I am not understanding exactly what kind of experimentation will take place on mainnet vs a testnet, and I'm way off. Some dApps that have been building on testnets to date may want to migrate their dApps to mainnet and thus faucet funds to their users.

[Villaquiranm]

Hello
I've added some experimentation about this feature on #3808

This pull request introduces two key features to gnofaucet:

getGithubMiddleware: A new middleware that checks for a code query parameter in the URL. It attempts to exchange this code for a GitHub token via OAuth. If the code is valid, the middleware retrieves the GitHub login associated with the token.

Cooldown Period: This feature allows for a configurable cooldown period (1 hour in this case). If the user attempts to claim tokens again before the cooldown period expires, the middleware will reject the request.

Additionally, we could enhance the functionality by implementing checks for account age, pull requests, commits, or verifying if the user belongs to a specific organization.

There are missing tests and I think the code I did on frontend is very far to be production material but I hope you consider it useful 👍