diff --git a/CHANGELOG.md b/CHANGELOG.md index da0545de..681be0d7 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -13,6 +13,24 @@ ### Changed +- **Bitcoin**: switched the recommended and sample instance types from x86 `r7i` to Graviton4. + - Mainnet single-node and HA samples now use `r8g.2xlarge`; testnet uses `r8g.xlarge`. All samples set `CPU_TYPE="ARM_64"`. + - In side-by-side mainnet tests (Bitcoin Core v31.1), `r8g.2xlarge` beat `r7i.2xlarge` on every measure while costing 11% less per hour: + - 4–14% faster sync from block 400k to tip (two syncs) + - 1.5–1.7× RPC throughput under concurrent load (full blocks, transaction lookups and a mixed workload) + - with a single client: 4% faster full-block `getblock` and 2.8× transaction-lookup throughput + - The README adds a "Choosing an instance type" guide: `r8g` primary; `r7g.2xlarge` secondary, for regions without r8g or the lowest hourly price, covering all tested workloads; `r7i` for hosts that need x86, including where it beats r7g. + - It explains that r7i's slower light-RPC results come from its default C6 idle state, with tuning guidance. + - It also updates the measured IBD time (about 8–10 h). + - No `node.sh` changes are needed: it already installs the aarch64 Bitcoin Core build when `CPU_TYPE="ARM_64"`. + - Existing `.env` files are unaffected. To move a deployed node to Graviton, deploy a new stack: redeploying an existing single-node stack with a new `CPU_TYPE` replaces the instance, and the stack rolls back because the data volume is still attached to the old instance. + - The README adds an "Under concurrent load" section: peak throughput and latency for 2xlarge and xlarge on both architectures, and the network-baseline limit on sustained full-block serving. + - The README adds post-sync right-sizing guidance: `r8g.xlarge` matched `r8g.2xlarge` on single-client RPC after sync, and reaches about half its throughput under load. It also explains how to resize in place by changing `INSTANCE_TYPE` and running `cdk deploy`, which stops and starts the same instance and keeps the chain data (verified on mainnet). + - It corrects the mainnet size and growth rate (~970 GB total; ~100 GB/year, measured from the last year of blocks). + - It corrects the HA `cdk destroy` stack name, warns that `cdk destroy` deletes the data volume, and documents deleting the RPC credentials secret, which `cdk destroy` leaves behind (both verified on teardown). + - It corrects the RPC credentials secret name in the RPC Authentication and Troubleshooting sections: `node.sh` stores it as `/bitcoin_rpc_credentials`, not `bitcoin_rpc_credentials`. + - It adds a troubleshooting entry for a node that crash-loops after an interrupted first boot (re-run `node.sh`). + - It corrects "Upgrading Client Versions". Redeploying a single-node stack with a new `CLIENT_CONFIG` stops and starts the same instance without re-running node setup, so the node stays on the previous version; the README previously said the instance is replaced and upgraded (tracked in #340). - **Ethereum**: upgraded Nethermind `1.39.3` → `2.0.0` in the Nethermind + Teku configuration (`nethermind-2.0.0-teku-26.8.0-full.yml`). New nodes sync into the flat state database, the 2.0 default. Upstream benchmarks show higher, more consistent block-processing throughput at chain tip and 15–27% faster `eth_call` than `1.39.3`, with the largest throughput gain (+36%) on arm64, the architecture of the blueprint's default Graviton instances. The configuration now also pins HTTP RPC to `8545` and WebSocket to `8546` (matching the blueprint's declared ports; Nethermind previously served WebSocket on `8545`), enables the `debug` and `admin` RPC modules to match the other execution clients, turns on the `/health` endpoint (usable as the HA ALB health-check path) and Prometheus metrics on the internal IP (`6060`), and binds the Engine API to `127.0.0.1` instead of `0.0.0.0`. Upstream 2.0 breaking changes that do not affect this blueprint's flags: `Db.FlushOnExit` became an enum and numeric config keys are now unsigned. Behaviour changes to note: `eth_getLogs` is limited to a 1,000-block range by default (`Receipt.MaxBlockDepth`), and fresh nodes serve snap data to peers (`Sync.SnapServingEnabled`). Added a `samples/.env-mainnet-nethermind-teku-full` sample and documented the configuration in the blueprint README. Smoke-tested on Sepolia with Teku `26.8.0`: Engine API handshake, RPC modules, WebSocket upgrade, `/health`, and metrics verified. Per the replace-the-instance upgrade model, upgrading means deploying a new node, which syncs from scratch. - **Ethereum**: bumped Reth `2.4.1` → `2.5.2` (Reth + Lighthouse archive), Besu `26.7.1` → `26.8.1`, and Teku `26.7.1` → `26.8.0` (Besu + Teku and Nethermind + Teku). Besu `26.8.1` carries breaking changes (a 1000-address cap on `eth_newFilter`/`eth_subscribe`, a 128 KiB tx-pool admission limit, removal of already-deprecated flags, and an `eth_estimateGas` result change) — none of the removed flags are used by the blueprint, and a mainnet smoke test confirmed it starts and syncs with the existing flag set. Teku `26.8.0` removes the long-deprecated `GetDepositSnapshot` Beacon API endpoint, which does not affect node operation. Configuration file names and matching `samples/` were updated accordingly. - **Solana**: bumped the default Agave configuration `4.2.1` → `4.2.2` (same stable `4.2.x` mainnet-beta line) and Frankendancer `0.1105.40200` → `0.1106.40201` (latest Frankendancer **Mainnet** release on the `0.x` line; bundled Agave submodule updated to `v4.2.1`, adds v1-transaction support). The `3.1.14`, `4.0.3`, and `4.1.2` Agave configurations remain available for pinning. Both clients build from source at the tag parsed from the configuration file name; both were smoke-tested on mainnet-beta. @@ -32,6 +50,9 @@ ### Fixed +- **Bitcoin**: aligned the documented mainnet data volume with the shipped samples. The README (architecture diagram, instance and storage tables, cost notes) and the blueprint's `defaultDataVolumes` in `package.json` said 1 TB / 1000 GiB, while every mainnet `samples/` file provisions 1500 GiB; they now all say 1.5 TB / 1500 GiB. +- **AI deploy workflow**: `docs/ageai-deploy-prompt.md` omitted `bitcoin` from the built-in blueprint list in Step 2.5, so an assistant following it would demand an external-blueprint security review for the built-in Bitcoin blueprint. Bitcoin is now listed, matching `docs/ageai-blueprint-security-review.md`. + - **BNB Chain**: corrected the BSC Reth snapshot type. The `bsc-reth` sample (`.env-mainnet-bsc-reth-full`) set `BNB_SNAPSHOT_TYPE="local"` (a geth-only type) and the config script defaulted to `"full"`, but 48Club now publishes only `reth.fast` for the reth client — so a deploy silently fell back to a genesis sync. The sample now sets `BNB_SNAPSHOT_TYPE="fast"` and the script defaults to `"fast"`; the staging volume was right-sized `10000` → `600` GiB to match the ~458 GiB `reth.fast` archive. Verified on mainnet (snapshot downloads, extracts, and loads). - **Solana**: corrected the Frankendancer entry in the README "Client Release Channels" table. `releases/latest` for `firedancer-io/firedancer` resolves to the full **Firedancer** product (calendar `v26.x`), not Frankendancer; the table now instructs querying `/releases` for the highest non-prerelease named `Frankendancer Mainnet` on the `0.x` line, with a note explaining the two products share one release feed. - **BNB Chain**: the `bsc-reth` config script sourced the Rust environment via `"$HOME/.cargo/env"`, but cloud-init runs user-data as `root` with `HOME` unset, so it resolved to `/.cargo/env` and aborted the build (`No such file or directory`) before `reth-bsc` could compile. The script now pins `HOME` (`export HOME="${HOME:-/root}"`) before installing the Rust toolchain. Without this, the BSC Reth node never builds. diff --git a/blueprints/bitcoin/README.md b/blueprints/bitcoin/README.md index 0b746662..0f3ba669 100644 --- a/blueprints/bitcoin/README.md +++ b/blueprints/bitcoin/README.md @@ -18,7 +18,7 @@ This protocol implementation provides support for running Bitcoin Core nodes on | | | | RPC: Port 8332 | P2P: Port 8333 | | | | | | +--------------------------------------------------+ | | | | | +--------------------------------------------------+ | | -| | | | EBS Volume (/data) - 1 TB gp3 | | | +| | | | EBS Volume (/data) - 1.5 TB gp3 | | | | | | +--------------------------------------------------+ | | | | +------------------------------------------------------+ | | +----------------------------------------------------------+ @@ -65,17 +65,100 @@ Note: HA nodes do not share state (wallet, mempool). The ALB uses session sticki | Network | Deployment | Instance Type | vCPUs | Memory | Storage | |---------|-----------|---------------|-------|--------|---------| -| Mainnet | Single Node | r7i.2xlarge | 8 | 64 GB | 1 TB gp3 | -| Mainnet | HA (2 nodes) | r7i.2xlarge | 8 each | 64 GB each | 1 TB gp3 each | -| Testnet | Single Node | r7i.xlarge | 4 | 32 GB | 200 GB gp3 | +| Mainnet | Single Node | r8g.2xlarge (ARM) | 8 | 64 GB | 1.5 TB gp3 | +| Mainnet | HA (2 nodes) | r8g.2xlarge (ARM) | 8 each | 64 GB each | 1.5 TB gp3 each | +| Testnet | Single Node | r8g.xlarge (ARM) | 4 | 32 GB | 200 GB gp3 | + +The samples use Graviton (`CPU_TYPE="ARM_64"`). Blueprint `node.sh` detects the architecture and installs the matching official Bitcoin Core build, so switching between ARM and x86 only changes `INSTANCE_TYPE` and `CPU_TYPE` in `.env`. + +#### Choosing an instance type + +These results come from side-by-side mainnet tests in 2026-09/10: +- Bitcoin Core v31.1, `txindex=1`, 1.5 TB gp3 at 6,000 IOPS, us-east-1 on-demand pricing. +- Sync time is from block 400,000 to tip. Ranges are two separate syncs; r7g was synced once. +- Single-client RPC is one sequential client on the node. +- "Under load" is the peak throughput from a separate load-generator instance with 1–64 concurrent clients; see [Under concurrent load](#under-concurrent-load). + +| | **r8g.2xlarge** (primary) | **r7g.2xlarge** (secondary) | **r7i.2xlarge** (x86) | +|---|---|---|---| +| Processor | Graviton4, 8 cores | Graviton3, 8 cores | Sapphire Rapids, 4 cores / 8 threads | +| Hourly price vs r7i | -11% | -19% | — | +| Initial sync time | **7.8–8.5 h** | 8.5 h | 8.9–9.1 h | +| Initial sync compute cost | $3.68–3.99 | **$3.62** | $4.68–4.80 | +| Full-block RPC (`getblock` verbosity 2), single client | **7.7/s** | 6.3/s | 7.4/s | +| Full-block RPC, under load | **81/s** | not tested | 50/s | +| Transaction lookup (`getrawtransaction` verbose), single client | **2,806/s** | 1,812/s | 1,003/s (2,261/s with C6 disabled) | +| Transaction lookup, under load | **25,000/s** | not tested | 17,000/s | + +- **r8g.2xlarge (primary):** the best choice for most nodes. + - Fastest initial sync and catch-up after downtime: 4–14% faster than r7i across two syncs, and about 30% faster on the multithreaded final stretch. + - Fastest RPC in every test. Under concurrent load it served 1.5–1.7× r7i's throughput, because it has 8 physical cores where r7i.2xlarge has 4 cores with hyperthreading. + - 11% cheaper per hour than r7i. +- **r7g.2xlarge (secondary):** the best choice where r8g isn't available in your region or Availability Zone, or when the lowest hourly price matters most. + - It handles every workload tested, including heavy full-block serving. + - Versus r7i: r7g syncs faster, costs 19% less per hour and has the lowest total sync cost. + - r7i is better at two things: + - about 16% faster on full-block RPC (`getblock` verbosity 2) + - faster on light RPC once r7i's C-states are tuned (see below) +- **r7i.2xlarge (x86):** choose this when you need x86 on the host, such as x86-only sidecars or tooling, or an x86 fleet standard. + - Among the three, it's second only to r8g on full-block RPC, and it's the slowest and most expensive at initial sync. + - With default settings, small RPC requests are slower on r7i because the vCPUs enter the deep C6 idle state (190 µs exit latency) between requests. + - For latency-sensitive light RPC on r7i, consider limiting C-states, for example the kernel boot parameter `intel_idle.max_cstate=1`. This trades Turbo Boost headroom for lower wakeup latency; see [Processor state control](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/processor_state_control.html). + - Graviton instances don't expose C-states to the OS, so they don't have this issue. + +Initial sync spends most of its time on one CPU thread (block validation below the `assumevalid` height), so single-core performance matters more than vCPU count. The final stretch above `assumevalid` verifies signatures on multiple threads, where physical core count helps. + +#### Under concurrent load + +The concurrency test used: +- a separate load-generator instance in the same Availability Zone +- 1–64 concurrent clients, 45 s per level +- the default Bitcoin Core RPC settings (16 RPC threads) + +Peak throughput: + +| Workload | r8g.2xlarge | r7i.2xlarge | r8g.xlarge | r7i.xlarge | +|---|---|---|---|---| +| Full blocks (`getblock` verbosity 2) | **81/s** | 50/s | 41/s | 25/s | +| Transaction lookups (`getrawtransaction` verbose) | **25,000/s** | 17,000/s | 15,300/s | 9,800/s | +| Mixed, 90% lookups / 10% full blocks | **812/s** | 490/s | 400/s | 252/s | +| Full-block p99 latency at 16 clients | **363 ms** | 625 ms | 793 ms | 1,193 ms | + +- **Full-block and mixed workloads are CPU-bound.** Throughput levels off once the number of clients reaches about the number of physical cores, and the host is then at 100% CPU. Beyond that, extra clients only add latency. + - r8g.2xlarge peaks at about 16 clients, and r7i.2xlarge at about 8. + - Each xlarge reaches half its 2xlarge's throughput, at half the price. +- **Transaction lookups level off below full CPU.** r8g.2xlarge peaked at 74% CPU, which points to a limit inside Bitcoin Core rather than the instance. + - Going from xlarge to 2xlarge gives 1.6–1.7× the throughput here, not 2×. +- **Network can limit sustained full-block serving.** Full decoded blocks are large (about 8.5 MB of JSON each on average). At peak, r8g.2xlarge sent about 680 MB/s, above its 3.75 Gbit/s (about 470 MB/s) baseline network bandwidth. Short bursts are covered by burst bandwidth. + - For sustained full-block serving to remote clients, size for the baseline: roughly 55 full blocks/s on r8g.2xlarge, and about 28/s on r8g.xlarge (1.875 Gbit/s baseline). + +#### After initial sync + +A synced node can run on a smaller instance. +- **Tested:** `r8g.xlarge` (4 vCPU, 32 GB) kept up with the chain tip. On the single-client RPC benchmark it performed the same as `r8g.2xlarge` (`getblock` verbosity 2: 7.7/s; transaction lookups: 2,799/s) at half the hourly price. +- **Memory:** bitcoind used about 6.4 GB of the 32 GB. +- **Keep the 2xlarge for initial sync.** The xlarge's EBS baseline throughput (156 MB/s) is below the gp3 volume's 400 MB/s, and it has half the cores for signature checks. Also keep it for catching up after long downtime. +- **Under load,** `r8g.xlarge` peaked at about 41 full blocks/s and about 15,300 transaction lookups/s, roughly half the 2xlarge's full-block throughput (see [Under concurrent load](#under-concurrent-load)). + - Stay on the xlarge if your peak load fits within that. + - Choose the 2xlarge if you regularly run more than about 4 concurrent full-block clients or need lower tail latency. + +To resize a single-node deployment within the same architecture, change `INSTANCE_TYPE` in `.env` (for example `r8g.2xlarge` → `r8g.xlarge`) and redeploy: -**ARM Alternative**: Use `r8g.2xlarge` for ~10% cost savings on mainnet. +```bash +npx cdk deploy --json --outputs-file deploy-output-bitcoin-mainnet.json +``` + +- CloudFormation stops and starts the same instance with the new type. It isn't replaced, the data volume stays attached, and the node resumes from its chain data with no re-sync. +- In testing, the node was offline for about a minute and back at the chain tip right after restart. +- Resize through `cdk deploy` rather than changing the instance type in the EC2 console, so the stack and `.env` stay in sync. + +> **Note:** Don't change `CPU_TYPE` on an existing single-node stack with `cdk deploy`. The new architecture needs a new AMI, so CloudFormation replaces the instance. The replacement then fails because the data volume is still attached to the old instance, and the stack rolls back with the node unchanged. To move a node to a different architecture (for example x86 to Graviton), deploy a new stack and let it sync. ### Storage Requirements | Network | Current Size | Growth Rate | Recommended | Type | IOPS | |---------|-------------|-------------|-------------|------|------| -| Mainnet | ~650 GB (with txindex) | ~80 GB/year | 1 TB | gp3 | 6,000 | +| Mainnet | ~970 GB (blocks 880 GB, txindex 74 GB, chainstate 14 GB; block 969,306) | ~100 GB/year | 1.5 TB | gp3 | 6,000 | | Testnet | ~50 GB | ~10 GB/year | 200 GB | gp3 | 3,000 | > Running multiple protocols? Each deployment creates an independent CloudFormation stack. Total costs are additive — use the tables above per protocol. @@ -123,7 +206,7 @@ For advanced options (HA mode, multiple stacks, maintenance), see the [Deploymen #### Step 3: Monitor Synchronization -Initial Block Download (IBD) takes 12-48 hours depending on instance type and IOPS. +Initial Block Download (IBD) from genesis took about 8–10 hours on the recommended 8-vCPU instances with 6,000 IOPS gp3 (measured with Bitcoin Core v31.1; `r8g.2xlarge` was fastest). Smaller instances, lower IOPS, or poor peers take longer. ```bash DASHBOARD=$(cat deploy-output-bitcoin-mainnet.json | jq -r '..|.DashboardName? | select(. != null)') @@ -196,7 +279,7 @@ Bitcoin Core uses `rpcauth` for secure remote RPC access. This blueprint automat 1. Generates a random username, password, and salt during node setup 2. Computes `HMAC-SHA256(key=salt, message=password)` to create the hash 3. Writes `rpcauth=username:salt$hash` to `bitcoin.conf` -4. Stores `username:password` in AWS Secrets Manager as `bitcoin_rpc_credentials` +4. Stores `username:password` in AWS Secrets Manager as `/bitcoin_rpc_credentials` (for example `bitcoin-mainnet-bitcoin-core-v-full/bitcoin_rpc_credentials`). In HA mode, all nodes share this secret. 5. Saves credentials locally to `/data/.rpc-credentials` as a fallback The final `rpcauth` line in `bitcoin.conf` looks like this: @@ -216,8 +299,9 @@ For a client to securely interact with the Bitcoin Core RPC endpoint from within From your CloudShell terminal: ```bash +STACK_NAME=$(jq -r 'keys[0]' deploy-output-bitcoin-mainnet.json) export BTC_RPC_AUTH=$(aws secretsmanager get-secret-value \ - --secret-id bitcoin_rpc_credentials \ + --secret-id "$STACK_NAME/bitcoin_rpc_credentials" \ --query SecretString --output text --region $AWS_REGION) echo "BTC_RPC_AUTH=$BTC_RPC_AUTH" ``` @@ -389,17 +473,32 @@ Common causes: - Insufficient disk space - Invalid bitcoin.conf syntax +### Node Crash-Loops After an Interrupted First Boot + +**Symptom:** `journalctl -u node.service` repeats `specified config file "/data/bitcoin.conf" could not be opened`, and `/data/init-completed` doesn't exist. + +**Cause:** node setup runs only once, on the instance's first boot. If the instance is stopped or rebooted before setup finishes, it doesn't resume. The service is left without `bitcoin.conf`. + +Re-run the blueprint's setup script from an SSM session. It reuses the existing RPC credentials in Secrets Manager, then starts the service: + +```bash +sudo systemctl stop node.service +sudo /opt/blueprints/user-data/node.sh +sudo systemctl start syncchecker.timer net-rules.service +test -f /data/init-completed && echo "setup complete" +``` + ### Slow Initial Sync - Increase `dbcache` (requires more RAM) - Ensure gp3 IOPS are sufficient (6,000+ recommended) -- Bitcoin IBD is CPU-intensive — larger instance helps +- Bitcoin IBD is mostly limited by one CPU thread (block validation). A faster core helps more than more vCPUs; `r8g.2xlarge` synced fastest in testing ### RPC Not Responding 1. Confirm service is running: `sudo systemctl status node` 2. Check bitcoin.conf: `cat /data/bitcoin.conf` -3. Verify RPC credentials: `aws secretsmanager get-secret-value --secret-id bitcoin_rpc_credentials` +3. Verify RPC credentials: `aws secretsmanager get-secret-value --secret-id /bitcoin_rpc_credentials` 4. Ensure security group allows port 8332 from your VPC CIDR ### Monitoring Logs @@ -422,7 +521,10 @@ See the [Troubleshooting Guide](/docs/guides/troubleshooting) for detailed diagn 2. Update `CLIENT_CONFIG` in `.env` to the new filename 3. Redeploy: `npx cdk deploy --json --outputs-file deploy-output-bitcoin-mainnet.json` -Note: The instance will be replaced and Bitcoin Core will resume from the existing chain data on the EBS volume (no full re-sync required). +> **Note (single-node):** Redeploying a single-node stack with a new `CLIENT_CONFIG` doesn't upgrade the running node. +> - CloudFormation applies the new user data by stopping and starting the same instance; it isn't replaced. Node setup runs only on first boot, so it doesn't run again, and the node keeps running the previous Bitcoin Core version on the same chain data. +> - To move to a new client version, deploy a new stack with the new configuration and let it sync. +> - Changing `CPU_TYPE` on an existing stack fails and rolls back (see [After initial sync](#after-initial-sync)). ### Rolling Updates (HA Only) @@ -432,11 +534,12 @@ HA deployments perform rolling updates automatically, ensuring no RPC downtime d ### Storage - gp3 is sufficient for Bitcoin (10-minute block time, low write pressure) -- 1 TB provides ~4 years of growth headroom with txindex +- 1.5 TB leaves about 5 years of headroom at the current ~100 GB/year growth. Monitor `disk_used_percent` and [expand the volume](/docs/guides/deployment-guide) before it fills. ### Compute -- ARM instances (`r8g.2xlarge`) save ~10% vs x86 -- Bitcoin IBD is the most compute-intensive phase; after sync, a smaller instance suffices +- Graviton instances cost less per hour than x86: `r8g.2xlarge` is 11% cheaper than `r7i.2xlarge`, and `r7g.2xlarge` is 19% cheaper. Graviton is also as fast or faster for Bitcoin Core; see [Choosing an instance type](#choosing-an-instance-type). +- `r7g.2xlarge` has the lowest total compute cost for the initial sync ($3.62 vs $4.80 on `r7i.2xlarge`, us-east-1 on-demand). +- Bitcoin IBD is the most compute-intensive phase. After sync, `r8g.xlarge` handled single-client RPC as well as `r8g.2xlarge` at half the price; see [After initial sync](#after-initial-sync) See the [Deployment Guide](/docs/guides/deployment-guide) for detailed cost optimization strategies. @@ -457,9 +560,21 @@ See the [Deployment Guide](/docs/guides/deployment-guide) for detailed cost opti npx cdk destroy bitcoin-mainnet-bitcoin-core-v-full # Delete HA Node -npx cdk destroy bitcoin-mainnet-bitcoin-core-v-full-ha +npx cdk destroy bitcoin-mainnet-bitcoin-core-v-full ``` +> **Warning:** `cdk destroy` also deletes the data volume and all synced chain data (about 970 GB on mainnet). This applies to both single-node and HA stacks. A new deployment starts Initial Block Download from scratch. To keep the chain data, create an EBS snapshot of the `/data` volume before destroying the stack. + +The RPC credentials secret is created by the node at first boot, not by CloudFormation, so `cdk destroy` leaves it behind. Delete it after destroying the stack: + +```bash +aws secretsmanager delete-secret --region $AWS_REGION \ + --secret-id bitcoin-mainnet-bitcoin-core-v-full/bitcoin_rpc_credentials \ + --force-delete-without-recovery +``` + +The secret name is `/bitcoin_rpc_credentials`. + ## FAQ **Q: Does upgrading or redeploying require a full re-sync?** @@ -468,7 +583,7 @@ A: No. Bitcoin Core resumes from the existing chain data on the `/data` EBS volu **Q: How long does the initial sync take?** -A: Initial Block Download (IBD) takes 12-48 hours on mainnet depending on instance type and IOPS. IBD is CPU- and I/O-intensive — a larger instance and 6,000+ IOPS speed it up. +A: About 8–10 hours on mainnet with the recommended 8-vCPU instances and 6,000 IOPS gp3 (measured with Bitcoin Core v31.1). Most of IBD is limited by a single CPU thread, so single-core performance (`r8g.2xlarge` was fastest) matters more than adding vCPUs. **Q: Do I need RPC credentials to use the node locally?** diff --git a/blueprints/bitcoin/package.json b/blueprints/bitcoin/package.json index 4e722822..12424f29 100644 --- a/blueprints/bitcoin/package.json +++ b/blueprints/bitcoin/package.json @@ -60,7 +60,7 @@ "defaultDataVolumes": [ { "name": "data", - "sizeGiB": 1000, + "sizeGiB": 1500, "type": "gp3", "iops": 6000, "throughput": 400, diff --git a/blueprints/bitcoin/samples/.env-mainnet-bitcoin-core-full b/blueprints/bitcoin/samples/.env-mainnet-bitcoin-core-full index 1816ceec..f25c2e9d 100644 --- a/blueprints/bitcoin/samples/.env-mainnet-bitcoin-core-full +++ b/blueprints/bitcoin/samples/.env-mainnet-bitcoin-core-full @@ -16,8 +16,8 @@ BC_NETWORK="mainnet" CLIENT_CONFIG="bitcoin-core-v31.1-full.yml" # Instance Configuration -INSTANCE_TYPE="r7i.2xlarge" -CPU_TYPE="x86_64" +INSTANCE_TYPE="r8g.2xlarge" +CPU_TYPE="ARM_64" # Storage Configuration DATA_VOLUMES_COUNT="1" diff --git a/blueprints/bitcoin/samples/.env-mainnet-bitcoin-core-full-ha b/blueprints/bitcoin/samples/.env-mainnet-bitcoin-core-full-ha index 919cf6e9..2db783d9 100644 --- a/blueprints/bitcoin/samples/.env-mainnet-bitcoin-core-full-ha +++ b/blueprints/bitcoin/samples/.env-mainnet-bitcoin-core-full-ha @@ -16,8 +16,8 @@ BC_NETWORK="mainnet" CLIENT_CONFIG="bitcoin-core-v31.1-full.yml" # Instance Configuration -INSTANCE_TYPE="r7i.2xlarge" -CPU_TYPE="x86_64" +INSTANCE_TYPE="r8g.2xlarge" +CPU_TYPE="ARM_64" # Storage Configuration DATA_VOLUMES_COUNT="1" diff --git a/blueprints/bitcoin/samples/.env-testnet-bitcoin-core-full b/blueprints/bitcoin/samples/.env-testnet-bitcoin-core-full index eb355bf6..a6018942 100644 --- a/blueprints/bitcoin/samples/.env-testnet-bitcoin-core-full +++ b/blueprints/bitcoin/samples/.env-testnet-bitcoin-core-full @@ -16,8 +16,8 @@ BC_NETWORK="testnet" CLIENT_CONFIG="bitcoin-core-v31.1-full.yml" # Instance Configuration -INSTANCE_TYPE="r7i.xlarge" -CPU_TYPE="x86_64" +INSTANCE_TYPE="r8g.xlarge" +CPU_TYPE="ARM_64" # Storage Configuration DATA_VOLUMES_COUNT="1" diff --git a/docs/ageai-deploy-prompt.md b/docs/ageai-deploy-prompt.md index 56e3fda4..879e6a7e 100644 --- a/docs/ageai-deploy-prompt.md +++ b/docs/ageai-deploy-prompt.md @@ -50,12 +50,12 @@ Before making recommendations, read these files: ## STEP 2.5: SECURITY REVIEW FOR EXTERNAL BLUEPRINTS -IMPORTANT: If the selected protocol is from an EXTERNAL blueprint (not ethereum, solana, bnb, base, or dummy), you MUST perform a security review before proceeding: +IMPORTANT: If the selected protocol is from an EXTERNAL blueprint (not ethereum, solana, bnb, base, bitcoin, or dummy), you MUST perform a security review before proceeding: 1. Read `docs/ageai-blueprint-security-review.md` 2. Follow the complete security review workflow 3. Do NOT proceed to Step 3 until the user acknowledges the review -Built-in blueprints (ethereum, solana, bnb, base, dummy) skip this step. +Built-in blueprints (ethereum, solana, bnb, base, bitcoin, dummy) skip this step. ## STEP 3: ANALYZE AND RECOMMEND