Ryan Smith ryandotsmith

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 very conservative choice. The smaller 2TB drive should last an Ethereum full node until at least sometime 2026, with [pre-merge history expiry](https://hackmd.io/@hBXHLw_9Qq2va4pRtI4bI

Enable Touch ID for sudo

Thanks to this awesome Six Colors post: Quick Tip: Enable Touch ID for sudo

The short of it:

In your terminal go to cd /etc/pam.d/.
Now open the sudo file with your favorite command-line/GUI text editor.
- Note that if you open it via the command-line, you’ll need to use sudo itself to do so, since the file is (understandably) protected.
With the sudo file open, add the following command below below the first line. auth sufficient pam_tid.so

Falsehoods programmers believe about time

This is a compiled list of falsehoods programmers tend to believe about working with time.

Don't re-invent a date time library yourself. If you think you understand everything about time, you're probably doing it wrong.

Falsehoods

There are always 24 hours in a day.
February is always 28 days long.
Any 24-hour period will always begin and end in the same day (or week, or month).

Screen Quick Reference

Basic

Description	Command
Start a new session with session name	`screen -S <session_name>`
List running sessions / screens	`screen -ls`
Attach to a running session	`screen -x`
Attach to a running session with name	`screen -r`

But why gen a new id if someone passes you an id? Just use the supplied id in the called srvc.

This is certainly disputable territory, but the main motivation is that depending on service architecture, a single incoming request can balloon out into a full tree of backend requests because requests can map 1:N between any two components. Assigning every request in every component a unique ID allows any particular request to be isolated, while still allowing the any subsection of the tree to be viewed all at once.

Visually, this might look something like this:

      Component 1            Component 2            Component 3
+----------------------+----------------------+----------------------+

O(1) Block Propagation

The problem

Bitcoin miners want their newly-found blocks to propagate across the network as quickly as possible, because every millisecond of delay increases the chances that another block, found at about the same time, wins the "block race."

The @roidrage meatballs extravaganza.

The secret ingredient to this recipe is letting everything stew for a few hours. First the tomato sauce, requires at least 90 minutes to 2 hours. Then the meatballs in the sauce another 90 minutes. The longer the better.

Once the meatballs are in the sauce, the more time you give them, the more delicious flavor will seep from the meat into the sauce, and vice versa. I'd recommend giving it a total of four hours for maximum taste extraction.

The long stew ensure that the fluids have evaporated and that you're left with the tastiest meatballs you've ever had.

Ingredients (serves four hungry people):

	use std::collections::HashMap;
	use std::fmt;
	use std::io;
	use std::num::ParseFloatError;
	use std::rc::Rc;

	/*
	Types
	*/

	-- table is 'blocks'
	-- column is 'number'

	SELECT
	gap_start, gap_end FROM (
	SELECT number + 1 AS gap_start,
	next_nr - 1 AS gap_end
	FROM (
	SELECT number, lead(number) OVER (ORDER BY number) AS next_nr
	FROM blocks

	WITH weeks AS (
	SELECT distinct date_trunc('week', dates)::date AS start,
	daterange(date_trunc('week', dates)::date, (date_trunc('week', dates) + interval '7 days')::date) week
	FROM generate_series(date '2013-01-01', now(), '1 day')
	dates ORDER BY 1
	)
	SELECT weeks.start,
	count(whatever.*) as count
	FROM whatever
	JOIN weeks