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.
On March 29th, 2024, a backdoor was discovered in xz-utils, a suite of software that
| # 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 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. The Portal team aim to make 2TB [last forever with EIP-4444](https://
| ########### | |
| # 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: