tornadocontrib/bsc
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
v1.1.1
bsc/cmd/faucet
History
zjubfd 2ce00adb55
[R4R] performance improvement in many aspects (#257) 
* focus on performance improvement in many aspects.

1. Do BlockBody verification concurrently;
2. Do calculation of intermediate root concurrently;
3. Preload accounts before processing blocks;
4. Make the snapshot layers configurable.
5. Reuse some object to reduce GC.

add

* rlp: improve decoder stream implementation (#22858)

This commit makes various cleanup changes to rlp.Stream.

* rlp: shrink Stream struct

This removes a lot of unused padding space in Stream by reordering the
fields. The size of Stream changes from 120 bytes to 88 bytes. Stream
instances are internally cached and reused using sync.Pool, so this does
not improve performance.

* rlp: simplify list stack

The list stack kept track of the size of the current list context as
well as the current offset into it. The size had to be stored in the
stack in order to subtract it from the remaining bytes of any enclosing
list in ListEnd. It seems that this can be implemented in a simpler
way: just subtract the size from the enclosing list context in List instead.

* rlp: use atomic.Value for type cache (#22902)

All encoding/decoding operations read the type cache to find the
writer/decoder function responsible for a type. When analyzing CPU
profiles of geth during sync, I found that the use of sync.RWMutex in
cache lookups appears in the profiles. It seems we are running into
CPU cache contention problems when package rlp is heavily used
on all CPU cores during sync.

This change makes it use atomic.Value + a writer lock instead of
sync.RWMutex. In the common case where the typeinfo entry is present in
the cache, we simply fetch the map and lookup the type.

* rlp: optimize byte array handling (#22924)

This change improves the performance of encoding/decoding [N]byte.

    name                     old time/op    new time/op    delta
    DecodeByteArrayStruct-8     336ns ± 0%     246ns ± 0%  -26.98%  (p=0.000 n=9+10)
    EncodeByteArrayStruct-8     225ns ± 1%     148ns ± 1%  -34.12%  (p=0.000 n=10+10)

    name                     old alloc/op   new alloc/op   delta
    DecodeByteArrayStruct-8      120B ± 0%       48B ± 0%  -60.00%  (p=0.000 n=10+10)
    EncodeByteArrayStruct-8     0.00B          0.00B          ~     (all equal)

* rlp: optimize big.Int decoding for size <= 32 bytes (#22927)

This change grows the static integer buffer in Stream to 32 bytes,
making it possible to decode 256bit integers without allocating a
temporary buffer.

In the recent commit 088da24, Stream struct size decreased from 120
bytes down to 88 bytes. This commit grows the struct to 112 bytes again,
but the size change will not degrade performance because Stream
instances are internally cached in sync.Pool.

    name             old time/op    new time/op    delta
    DecodeBigInts-8    12.2µs ± 0%     8.6µs ± 4%  -29.58%  (p=0.000 n=9+10)

    name             old speed      new speed      delta
    DecodeBigInts-8   230MB/s ± 0%   326MB/s ± 4%  +42.04%  (p=0.000 n=9+10)

* eth/protocols/eth, les: avoid Raw() when decoding HashOrNumber (#22841)

Getting the raw value is not necessary to decode this type, and
decoding it directly from the stream is faster.

* fix testcase

* debug no lazy

* fix can not repair

* address comments

Co-authored-by: Felix Lange <fjl@twurst.com>
2021-07-29 17:16:53 +08:00
..
faucet.go fix conflicts 2021-05-06 09:26:06 +08:00
faucet.html upgrade to 1.10.2 2021-04-16 12:45:26 +08:00
README.md cmd: support v1.1 Twitter API in faucet, fix puppeth 2021-01-04 14:13:21 +02:00
website.go fix faucet 2021-04-16 14:10:22 +08:00

README.md

Faucet

The faucet is a simplistic web application with the goal of distributing small amounts of Ether in private and test networks.

Users need to post their Ethereum addresses to fund in a Twitter status update or public Facebook post and share the link to the faucet. The faucet will in turn deduplicate user requests and send the Ether. After a funding round, the faucet prevents the same user requesting again for a pre-configured amount of time, proportional to the amount of Ether requested.

Operation

The faucet is a single binary app (everything included) with all configurations set via command line flags and a few files.

First thing's first, the faucet needs to connect to an Ethereum network, for which it needs the necessary genesis and network infos. Each of the following flags must be set:

  • --genesis is a path to a file containin the network genesis.json
  • --network is the devp2p network id used during connection
  • --bootnodes is a list of enode:// ids to join the network through

The faucet will use the les protocol to join the configured Ethereum network and will store its data in $HOME/.faucet (currently not configurable).

Funding

To be able to distribute funds, the faucet needs access to an already funded Ethereum account. This can be configured via:

  • --account.json is a path to the Ethereum account's JSON key file
  • --account.pass is a path to a text file with the decryption passphrase

The faucet is able to distribute various amounts of Ether in exchange for various timeouts. These can be configured via:

  • --faucet.amount is the number of Ethers to send by default
  • --faucet.minutes is the time to wait before allowing a rerequest
  • --faucet.tiers is the funding tiers to support (x3 time, x2.5 funds)

Sybil protection

To prevent the same user from exhausting funds in a loop, the faucet ties requests to social networks and captcha resolvers.

Captcha protection uses Google's invisible ReCaptcha, thus the faucet needs to run on a live domain. The domain needs to be registered in Google's systems to retrieve the captcha API token and secrets. After doing so, captcha protection may be enabled via:

  • --captcha.token is the API token for ReCaptcha
  • --captcha.secret is the API secret for ReCaptcha

Sybil protection via Twitter requires an API key as of 15th December, 2020. To obtain it, a Twitter user must be upgraded to developer status and a new Twitter App deployed with it. The app's Bearer token is required by the faucet to retrieve tweet data:

  • --twitter.token is the Bearer token for v2 API access
  • --twitter.token.v1 is the Bearer token for v1 API access

Sybil protection via Facebook uses the website to directly download post data thus does not currently require an API configuration.

Miscellaneous

Beside the above - mostly essential - CLI flags, there are a number that can be used to fine tune the faucet's operation. Please see faucet --help for a full list.