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

Decentralizing the faucet #12

Open
drortirosh opened this issue Feb 26, 2023 · 8 comments
Open

Decentralizing the faucet #12

drortirosh opened this issue Feb 26, 2023 · 8 comments

Comments

@drortirosh
Copy link

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..)

function claim(uint timestamp, bytes32 nonce) {
   require(timestamp<block.timestamp && timestamp > block.timestamp-3600*2);
   require(!claims[nonce], "already claimed");
   claimed[nonce]=true;
   uint result = uint(keccak256(abi.encode(msg.sender,timestamp,)nonce);
   require(result<requiredDifficulty, "didn't spend enough");
   msg.sender.call{value: payValue}("");
}
@pk910
Copy link
Owner

pk910 commented Feb 26, 2023

Heya @drortirosh

Thanks for your suggestion :)
I totally agree the core faucet functionality could be implemented in a contract.

Unfortunately there is a fundamental problem with that: Gas fees.
The faucet is intended to give developers, that have not interacted with the chain in any way yet, the chance to gather some funds.
It's kind of a hen and egg problem: you can't interact with a contract without some funds to pay the gas fees ;)
So you'd need to already own funds to be able to use the faucet contract...

@drortirosh
Copy link
Author

You can look at opengsn, as a project that let you (a dapp owner) sponsor the gas fees for a calling user.

@pk910
Copy link
Owner

pk910 commented Feb 28, 2023

That's a pretty cool project. I didn't know about it.
I'll take a closer look into it. It seems definitely very useful for other project too ;)

But I still don't think this faucet can be completely moved to the chain.
There are actually a lot more protection mechanisms in the background that fight against automated & bot requests...
They're mostly based on IP & analysis of UserAgent/Target Address etc.
Without these additional layers of protection I'd need to make mining a lot harder to prevent it from being drained.

Due to the funding situation on goerli, I'm bound to limitations in regards of daily payouts too.
For goerli that currently means a daily limit of 1k GöETH. Other networks are much less strict.

Besides of that the mining algorithm in the current implementation is set to be quite simple.
There are a lot of hashes found which are rewarded by a small portion each.
That way there is a relatively "stable" reward rate (~1-2min per hash) and a steady growing balance that can be claimed anytime.
The amount of transactions to this on-chain would be way to much - especially when there are about 1000 users mining concurrently (like right now on the goerli faucet).

The way to do this on-chain would rather be a big drop size, but an extremely high difficulty instead to keep it protected.
That's not really user friendly and will eventually take a really long time for unlucky/low performance users...

Anyway I'll keep that Idea in mind, as it might be useful for upcoming testnets like Holešovice.
Such an decentralized contract based faucet sounds great for automated workflows where you don't want to fiddle around with captchas or so ;)

@drortirosh
Copy link
Author

  1. You're right in that you can't be totally on-chain.
  2. Still, even your server can use an on-chain contract for actual validation and payout for the pow
  3. my sample handles a single hash. but it can receive an array of nonces, validate them all and pay the total.
  4. The server sends the transaction, so it pays for this validation (the cost for the server is 5000 gas per hash - 3000 to validate, and another 2000 to store it in a map to prevent re-use)

@Mitchtriz

This comment was marked as off-topic.

@Mitchtriz

This comment was marked as off-topic.

@Mitchtriz

This comment was marked as off-topic.

@pk910
Copy link
Owner

pk910 commented May 25, 2023

I'm locking this issue due to spam.
I'm not sure what's the actual reason for hijacking github issues for dumb question.
Just because there is an input field it does not mean everyone has to enter his non-related non-sense comments there...

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.

Repository owner locked as spam and limited conversation to collaborators May 25, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants