Skip to content

Instantly share code, notes, and snippets.

View jsvisa's full-sized avatar
🏠
Working from home

Delweng jsvisa

🏠
Working from home
View GitHub Profile
@y0ngb1n
y0ngb1n / docker-registry-mirrors.md
Last active February 6, 2026 05:41
国内的 Docker Hub 镜像加速器,由国内教育机构与各大云服务商提供的镜像加速服务 | Dockerized 实践 https://github.com/y0ngb1n/dockerized
@kf106
kf106 / ropsten-peers.txt
Last active November 21, 2022 07:26
List of active Ropsten peers found as of 30.4.2021
// 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.

Proposal for a light client friendly log event search data structure

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

@yorickdowne
yorickdowne / HallOfBlame.md
Last active February 4, 2026 08:59
Great and less great SSDs for Ethereum nodes

Overview

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