sbarratt

import pandas as pd
import time
import requests
import time
import hmac
from requests import Request
import sys
import json
import os

buffalu

About

This contains a CoreOS Ignition file that automatically configures a Solana RPC server on both private and public IPs.

Setup Instructions

1. Go to Equinix Metal and choose a good machine. (Can also go through Solana Foundation Server Program).
2. Create your server.
3. For OS, choose iPXE.
4. For URL, type in: https://stable.release.flatcar-linux.net/amd64-usr/current/flatcar_production_packet.ipxe
5. Click add user data. Run cat rpc-{private|public}.yaml | docker run --rm -i quay.io/coreos/ct:latest-dev --platform=custom. Copy and paste that (removing the last % if present).
6. Let it deploy.

yorickdowne

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.

fiveoutofnine

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.14;

contract Math {
    uint256 private constant MAGIC = 0x3F79C6D30BACA89;
    uint256 private constant LUT_ONE
        = 0x3E040B2811171A2E20262C32341D3A363D0310161F2531393C02152438012300;
    uint256 private constant LUT_DIFF
        = 0x100FADEFAF10EDEF1E2EBF7E6F0F4DCE40717030E0601E2F90D090C03131422;

0xperp

zsfelfoldi

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

brockelmore

// SPDX-License-Identifier: Unlicense
pragma solidity 0.8.11;


type PushArrayPtr is bytes32;

library PushArray {
    function newArray(uint8 len) internal pure returns (PushArrayPtr s) {
        assembly {
            // grab free mem ptr, accounting for annoying return adjustment 

hrkrshnn

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

yorickdowne

Note: PBSS in Geth >=1.13.0 removes the need to prune manually.

---

Old content for reference

Overview

Geth (Go-Ethereum) as of July 2022 takes about 650 GiB of space on a fast/snap sync, and then grows by ~ 14 GiB/week with default cache, ~ 8 GiB/week with more cache.

recmo

contract MerkleVerifier {

    function hash_leaf(uint256 value)
        internal pure
        returns (bytes32 hash)
    {
        return bytes32(value);
    }

    function hash_node(bytes32 left, bytes32 right)