rakita

## HallOfBlame.md

      
              1 file
            
          
              21 forks
            
          
              66 comments
            
          
              167 stars
            
          
                yorickdowne
                / HallOfBlame.md
            
            
              Last active
              May 20, 2024 12:53
            
              
                Great and less great SSDs for Ethereum nodes
              
          
    Overview

Syncing an Ethereum node is largely reliant on IOPS, I/O Per Second. Budget SSDs will struggle to an extent, and some won't be able to sync at all.
This document aims to snapshot some known good and known bad models.
For size, 4TB comes recommended as of mid 2024. The smaller 2TB drive should last an Ethereum full node until early 2025 or thereabouts, with crystal ball uncertainty. Remy wrote a migration guide to 4TB.
High-level, QLC and DRAMless are far slower than "mainstream" SSDs. QLC has lower endurance as well. Any savings will be gone when the drive fails early and needs to be replaced.

  
## 1559 tx pool.md

      
              1 file
            
          
              1 fork
            
          
              0 comments
            
          
              4 stars
            
          
                zsfelfoldi
                / 1559 tx pool.md
            
            
              Last active
              November 26, 2022 16:27
            
          
    EIP-1559 transaction pool design improvement proposal

Author: Zsolt Felfoldi (zsfelfoldi@ethereum.org)
New difficulties introduced by EIP-1559

Transaction pools currently order transactions based on a single metric (gasPrice), fetching the highest elements when constructing a new block and discarding the lowest elements when the pool is full. With EIP-1559 transaction ordering becomes more difficult because the effective miner reward (MIN(tx.tip, tx.feeCap-headBlock.baseFee)) depends on the latest block's base fee. A new EIP-1559 compatible pool design suggested by this proposal and implemented in this pull request orders transactions primarily based on feeCap in the eviction queue while the current efferctive reward is used for block construction. This is a good first approach because inclusion chance correlates with feeCap on the low end. The only potential danger is that `feeCap