-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Decentralizing the faucet #12
Comments
Heya @drortirosh Thanks for your suggestion :) Unfortunately there is a fundamental problem with that: Gas fees. |
You can look at opengsn, as a project that let you (a dapp owner) sponsor the gas fees for a calling user. |
That's a pretty cool project. I didn't know about it. But I still don't think this faucet can be completely moved to the chain. Due to the funding situation on goerli, I'm bound to limitations in regards of daily payouts too. Besides of that the mining algorithm in the current implementation is set to be quite simple. The way to do this on-chain would rather be a big drop size, but an extremely high difficulty instead to keep it protected. Anyway I'll keep that Idea in mind, as it might be useful for upcoming testnets like Holešovice. |
|
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
I'm locking this issue due to spam. Please feel free to open another issue if anyone wants to reply to the decentralization topic. I generally still like the idea to decentralize the faucet, I've even tried implementing a PoC, but unfortunately I see some heavy performance problems when sending in nonces from ~2-3k concurrently mining sessions on-chain. |
I just love this idea!
This is the true spirit of blockchain - Proof-of-X, even for testnets (and proof-of-work is the simplest of them all)
But why stop here - why should it have a server except the blockchain itself ?
All you need is a contract that can verify the PoW, and send the claimed eth to the calling user.
in the following code, the client is expected to find a keccak on (addr,timestamp,nonce) that is small enough.
The proof is bound to this specific user's address, at a specific timeslot (in the past 2 hours, in this example)
This sample gives a fixed payback for a single pow proof, but it can be easily expanded to accept multiple "proofs".
The faucet owner may modify the required difficulty if the demand seems too high, or faucet balance too low
(can even increase the difficulty exponentially as the faucet "liquidity" drops..)
The text was updated successfully, but these errors were encountered: