This is a living document. Everything in this document is made in good faith of being accurate, but like I just said; we don't yet know everything about what's going on.
Update: I've disabled comments as of 2025-01-26 to avoid everyone having notifications for something a year on if someone wants to suggest a correction. Folks are free to email to suggest corrections still, of course.
| # Hardware Specs: https://www.ovhcloud.com/en-ca/bare-metal/advance/adv-1/ | |
| [stages.headers] | |
| downloader_max_concurrent_requests = 100 | |
| downloader_min_concurrent_requests = 5 | |
| downloader_max_buffered_responses = 100 | |
| downloader_request_limit = 1000 | |
| commit_threshold = 10000 | |
| [stages.total_difficulty] | |
| commit_threshold = 200000 |
| # main | |
| llama-index | |
| langchain |
This doc has been replaced by the official Ordinals Handbook - https://docs.ordinals.com/guides/collecting/sparrow-wallet.html
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. For simplicity, this page treats IOPS as a proxy for/predictor of latency.
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 the pre-merge history expiry scheduled for Ma
| ########### | |
| # Imports # | |
| ########### | |
| # the RPCs file should include RPC URLs and Etherscan API Keys for relevant networks | |
| # (in a separate file so they don't get committed) | |
| source "$(dirname "$0")/rpcs.sh" | |
| # any useful addresses for various networks for easy reference | |
| source "$(dirname "$0")/addresses.sh" | |
| # any useful functions and definitions for interacting with Seaport |
| /** | |
| *Submitted for verification at Etherscan.io on 2021-04-22 | |
| */ | |
| // File: @openzeppelin/contracts/utils/Context.sol | |
| // SPDX-License-Identifier: MIT | |
| pragma solidity >=0.6.0 <0.8.0; |
If you would like to persist data from your ECS containers, i.e. hosting databases like MySQL or MongoDB with Docker, you need to ensure that you can mount the data directory of the database in the container to volume that's not going to dissappear when your container or worse yet, the EC2 instance that hosts your containers, is restarted or scaled up or down for any reason.
Don't know how to create your own AWS ECS Cluster? Go here!
Sadly the EC2 provisioning process doesn't allow you to configure EFS during the initial config. After your create your cluster, follow the guide below.
If you're using an Alpine-based Node server like duluca/minimal-node-web-server follow this guide: