国内从 Docker Hub 拉取镜像有时会遇到困难,此时可以配置镜像加速器。
Dockerized 实践 https://github.com/y0ngb1n/dockerized
国内从 Docker Hub 拉取镜像有时会遇到困难,此时可以配置镜像加速器。
Dockerized 实践 https://github.com/y0ngb1n/dockerized
| // For information on how to set up a Ropsten miner see https://www.linkedin.com/pulse/how-mine-ropsten-testnet-ether-keir-finlow-bates/ | |
| // For test Ropsten visit https://moonborrow.com/ | |
| // active Ropsten peer nodes found 15 Oct 2021 | |
| ["enode://05b558e4f6bb2853c80fbadd669e3e6123ad10ca08e43eccb9abcc50180a55486c8fc9f8b36d85033eca3888849920fb9d29981df85d1c3ffbea504848026716@104.248.75.151:8888", "enode://ddc869dab42ee378d9ea8f3872e0d114b2a0450c2b5e533ce899249c2cf88651bb14e7250b60765d333d3419d82c328effecbf56ddfac2cfb9c19b66682b4a09@52.72.11.115:30303", "enode://deb4a2157ec32c1837a2480d6752fc388f2fd6e9d97650c5e74bd1db11de2c2855ea6c4a62630b2292b6bf46ecc06e35a3e12d63bc145d0b810a3d0d4ea59d13@18.181.27.33:30303", "enode://fe9908781f114f1306d494610478dfa8af913e48612697113b1340133be502a4797c25e319b2609e166d77d0a1382124b5bb7b449cf29c390c4067560fc5fdd7@35.153.104.230:30303", "enode://a534ad8959940358d753e6f9155af0ff39de2e300e8bb1780fad53f3fab6757ae4d3b0e499aec14157b0c56fddeb8227405d8c5976318ed84325521ca8acc5f4@54.157.217. |
Author: Zsolt Felföldi (zsfelfoldi@ethereum.org)
Note: this is an informal write-up and the exact details of the data structure presented here might need further clarification. If there seems to be interest in this idea and no one finds any major holes in it then I want to write a proper EIP for this.
Here I attempt to solve two problems with our current bloom filter based log event search mechanism. One of them concerns both full and light clients: the bloom filter size is fixed and does not adapt to the increased number of log events per block due to increased gas limit. This leads to too many false positive matches, rendering the whole bloom filter mechanism almost ineffective. The other issue concerns light clients: even if we increase the bloom filter size, using the filters with a light client is only possible if the client syncs up the header chain. Geth light client did that until now but after the merge this practice becomes
Syncing an Ethereum node is largely reliant on latency and IOPS, I/O Per Second, of the storage. Budget SSDs will struggle to an extent, and some won't be able to sync at all. IOPS can roughly be used as proxy of / predictor for latency. Measuring latency directly is arguably better.
This document aims to snapshot some known good and known bad models.
The drive lists are ordered by interface and then by capacity and alphabetically by vendor name, not by preference. The lists are not exhaustive at all. @mwpastore linked a filterable spreadsheet in comments that has a far greater variety of drives and their characteristics. Filter it by DRAM yes, NAND Type TLC, Form Factor M.2, and desired capacity.
For size, 4TB is a conservative choice which also supports a Fusaka "supernode". The smaller 2TB drive should last an Ethereum full node until at least sometime 2026, with [pre-merge history expiry](http