slot1024 alikonuk1

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

Upgrade to at least 0.8.4

Using newer compiler versions and the optimizer gives gas optimizations and additional safety checks for free!

The advantages of versions 0.8.* over <0.8.0 are:

Safemath by default from 0.8.0 (can be more gas efficient than some library based safemath).
Low level inliner from 0.8.2, leads to cheaper runtime gas. Especially relevant when the contract has small functions. For

	contract Renderer {
	function updateDescription(
	string memory description
	) external override returns (bytes memory callback) {
	editionMetadata[msg.sender].description = description;

	bytes4 selector = IToken.batchMetadataUpdate.selector;
	uint256 totalSupply = IToken(msg.sender).totalSupply();

	assembly {