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

Feat/faucet attach 2 #269

Merged
merged 14 commits into from
Jan 4, 2021
Merged

Feat/faucet attach 2 #269

merged 14 commits into from
Jan 4, 2021

Conversation

meowsbits
Copy link
Contributor

@meowsbits meowsbits commented Dec 28, 2020

Supersedes #259.

  • Creates -attach flag allowing the faucet program to not run it's own client, instead attaching to an existing one via JSONRPC. Target client API needs to have eth and net API modules exposed.

  • (c99ed45) Disables NoDiscovery setting for managed client P2P configuration. Allowing discovery allows the faucet to not rely exclusively on manually configured bootnodes. Left commented because this differs from upstream... and I'm not sure at this point what the rationale was for disabling p2p discovery in the first place.

Rel #258

This begins implementation of the ref'd feature proposal.

Currently 'ethstats' support is removed because
that package relies heavily on access to a *node.Node.
Eventually I want to move that packages demands to
something that can be satisfied by an API instead.

Date: 2020-12-21 12:16:33-06:00
Signed-off-by: meows <[email protected]>
Conflicts:
	cmd/faucet/faucet.go
I'm reverting the HeaderAuthorGetter interface
solely to reduce diff size and complexity, both
for this PR and in general.

It doesn't mean I like it.

Date: 2020-12-28 07:47:24-06:00
Signed-off-by: meows <[email protected]>
Work was pending resolution of ethstats reporting
in conjunction with node attaching.

This has been resolved conceptually by
make them exclusive; you cannot activate ethstats
for the faucet's target attach node (since that
node can handle ethstats reporting all by itself).

Date: 2020-12-28 08:05:24-06:00
Signed-off-by: meows <[email protected]>
Date: 2020-12-28 08:08:25-06:00
Signed-off-by: meows <[email protected]>
Make sure flags aren't used in impossible ways.

Date: 2020-12-28 08:17:13-06:00
Signed-off-by: meows <[email protected]>
Date: 2020-12-28 08:24:18-06:00
Signed-off-by: meows <[email protected]>
Date: 2020-12-28 08:25:09-06:00
Signed-off-by: meows <[email protected]>
Date: 2020-12-28 08:37:41-06:00
Signed-off-by: meows <[email protected]>
Date: 2020-12-28 10:10:51-06:00
Signed-off-by: meows <[email protected]>
Faucet behavior previously effectively demanded
user configuration of bootnodes manually
to enable peering.

This disables NoDiscovery, thus
enabling discovery.

Date: 2020-12-28 10:19:05-06:00
Signed-off-by: meows <[email protected]>
Date: 2020-12-28 10:22:20-06:00
Signed-off-by: meows <[email protected]>
As noted in the comment on line 310, when
attaching to a remote client it may be that the
API says that chain id is 0 when the client
is not yet synced past the EIP155 activation
block height.

Requesting and switching on the genesis block
hash fixes this issue except for the foundation/classic
corner case (same genesis, different chain ids).

Date: 2020-12-29 05:14:04-06:00
Signed-off-by: meows <[email protected]>
This value would be useful and necessary only if
the target client were unsynced past the EIP155
activation height.

ChainID is used to disambiguate ETH/ETC chains.

Date: 2020-12-29 05:30:04-06:00
Signed-off-by: meows <[email protected]>
@iquidus iquidus self-requested a review December 29, 2020 18:50
@@ -629,7 +725,15 @@ func (f *faucet) apiHandler(w http.ResponseWriter, r *http.Request) {
amount = new(big.Int).Div(amount, new(big.Int).Exp(big.NewInt(2), big.NewInt(int64(msg.Tier)), nil))

tx := types.NewTransaction(f.nonce+uint64(len(f.reqs)), address, amount, 21000, f.price, nil)
signed, err := f.keystore.SignTx(f.account, tx, f.config.GetChainID())

// FIXME(meowsbits): Getting the chain id more than once is redundant and can be optimized.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is there a solution for this in mind?

Copy link
Contributor Author

@meowsbits meowsbits Dec 30, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably there are at least a few ways of handling it. One that comes first to mind is to add a field on faucet, eg. faucet.chainID since we know that once it's set to a nonzero value it won't change, and the faucet is only designed to handle a single network. But IMO this is a nice-to-have optimization since the request will only be made for each faucet transaction... which isn't more than can be expected for a "standard" transaction-making program (at least it's not getting called at every block or anything like that). Because of this I'm OK pushing to a later optimization if need/desire calls for it.

@meowsbits meowsbits merged commit b16e492 into master Jan 4, 2021
@meowsbits meowsbits deleted the feat/faucet-attach-2 branch January 4, 2021 12:56
@meowsbits meowsbits mentioned this pull request Jan 4, 2021
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.

3 participants