このプロジェクトは、Go Ethereum(geth)v1.16.7を使用してProof of Stake(PoS)ベースのプライベートブロックチェーンネットワークを構築します。Kurtosisツールを活用し、段階的に単一ノードから複数ノードへと拡張可能なテスト環境を構築します。
このリポジトリは4つの独立したブロックチェーンを同時稼働させる高度なクロスチェーン環境をサポートしています:
- BC-X(統合チェーン): ノード1-9が参加(Network ID: 20240400)
- BC-A: ノード1-3が参加(Network ID: 20240329)
- BC-B: ノード4-6が参加(Network ID: 20240330)
- BC-C: ノード7-9が参加(Network ID: 20240331)
各ブロックチェーンは完全に独立したネットワークIDを持ち、相互に干渉せずに並列動作します。詳細はアーキテクチャドキュメントを参照してください。
このプロジェクトはテスト環境専用です。
- Chain ID: 12345(mainnet=1とは異なる)
- Network ID: 20240329(mainnet=1とは異なる)
- すべての設定ファイルに "TESTNET ONLY" コメントを記載済み
- ブロックチェーン: Go Ethereum (geth) v1.16.7
- コンセンサス: Proof of Stake (PoS) - The Merge後のEthereum準拠
- 開発ツール: Kurtosis ethereum-package
- コンテナ化: Docker & Docker Compose
- Consensus Client: Lighthouse, Prysm
PoS-Kurtosis/
├── kurtosis/ # Kurtosis設定ファイル
│ ├── bc-x.yaml # BC-X(9ノード統合チェーン)
│ ├── bc-a.yaml # BC-A(3ノード)
│ ├── bc-b.yaml # BC-B(3ノード)
│ ├── bc-c.yaml # BC-C(3ノード)
│ ├── single-node.yaml # 単一ノード構成
│ ├── multi-node.yaml # マルチノード構成
│ └── production.yaml # 本番環境構成
├── contracts/ # スマートコントラクト
│ ├── DomainChainRegistry.sol # BC-X用ドメインチェーン管理
│ └── SoftwareVerification.sol # BC-A/B/C用ソフトウェア検証
├── scripts/ # 🔧 統合スクリプト
│ ├── deploy.js # デプロイ統合ツール
│ ├── check.js # 状態確認統合ツール
│ ├── sbom-tool.js # SBOM生成・登録ツール
│ ├── verify-crosschain.js # クロスチェーン依存検証
│ ├── start-environment.sh # 環境起動
│ ├── register-chains-to-bc-x.sh # BC-X登録
│ └── ...
├── deployments/ # デプロイ情報
│ ├── bc-x-DomainChainRegistry.json
│ ├── bc-a-SoftwareVerification.json
│ ├── bc-b-SoftwareVerification.json
│ └── bc-c-SoftwareVerification.json
├── api-server/ # REST APIサーバー
│ ├── index.js
│ ├── Dockerfile
│ └── package.json
└── README.md
# 全環境を自動セットアップ
bash scripts/start-environment.sh
# クリーンアップしてから起動
bash scripts/start-environment.sh --clean# 全コントラクトをデプロイ(BC-X + BC-A/B/C)
node scripts/deploy.js all
# 個別デプロイ
node scripts/deploy.js registry # BC-X Registry
node scripts/deploy.js verification # BC-A/B/C Verification# BC-XにBC-A/B/Cを登録
bash scripts/register-chains-to-bc-x.sh# 一括実行(生成 → 登録)
node scripts/sbom-tool.js all small
# 個別実行
node scripts/sbom-tool.js generate small # データ生成
node scripts/sbom-tool.js inject small # 登録
node scripts/sbom-tool.js stats small # 統計表示# 全システム確認
node scripts/check.js all
# 個別確認
node scripts/check.js registry # BC-X Registry
node scripts/check.js contract bc-a # BC-A Contract
# テスト・検証機能
node scripts/check.js verify-key-removal # key_id削除確認
node scripts/check.js cross-chain # クロスチェーン通信テスト
node scripts/check.js inject-test-data # テストデータ投入# 依存パス検証・可視化
node scripts/verify-crosschain.js \
"pkg:corp-a/service-1/module-1@1.0.0" \
"pkg:npm/package-50@3.0.0"検証結果例:
🎯 START [BC-A (corp-a)]
🟢 service-1/module-1@1.0.0
↓
🌉 チェーン横断: BC-A → BC-C
↓
🏁 TARGET [BC-C (npm)]
🟢 package-50@3.0.0
✅ 依存関係: クロスチェーン依存(6ホップ)
🌐 チェーン数: 2チェーン
⏱️ 検証時間: 2689ms
# Kurtosis CLIのインストール確認
kurtosis version
# Docker環境確認
docker --version
# Node.js依存関係のインストール
cd api-server && npm install
# 環境変数の確認
cat .env | grep -E "PRIVATE_KEY|RPC_URL"# Stage 1: 単一ノード起動
kurtosis run --enclave testnet-single \
github.com/ethpandaops/ethereum-package \
--args-file ./kurtosis/single-node.yaml4つの独立したブロックチェーンを同時に稼働させる:
# 環境をクリーンアップ(既存のenclaveがある場合)
kurtosis clean -a
# BC-X(管理チェーン、9ノード)
kurtosis run --enclave bc-x \
github.com/ethpandaops/ethereum-package \
--args-file ./kurtosis/bc-x.yaml
# BC-A(npmエコシステム、3ノード)
kurtosis run --enclave bc-a \
github.com/ethpandaops/ethereum-package \
--args-file ./kurtosis/bc-a.yaml
# BC-B(pypiエコシステム、3ノード)
kurtosis run --enclave bc-b \
github.com/ethpandaops/ethereum-package \
--args-file ./kurtosis/bc-b.yaml
# BC-C(mvnエコシステム、3ノード)
kurtosis run --enclave bc-c \
github.com/ethpandaops/ethereum-package \
--args-file ./kurtosis/bc-c.yaml各ブロックチェーンのAPIサーバーを起動(合計9プロセス):
cd api-server
# BC-A API servers (ports 3001-3003)
BC_NAME=BC-A RPC_URL=http://172.16.4.12:8545 API_PORT=3001 nohup node index.js > /tmp/api-3001.log 2>&1 &
BC_NAME=BC-A RPC_URL=http://172.16.4.14:8545 API_PORT=3002 nohup node index.js > /tmp/api-3002.log 2>&1 &
BC_NAME=BC-A RPC_URL=http://172.16.4.13:8545 API_PORT=3003 nohup node index.js > /tmp/api-3003.log 2>&1 &
# BC-B API servers (ports 3004-3006)
BC_NAME=BC-B RPC_URL=http://172.16.8.12:8545 API_PORT=3004 nohup node index.js > /tmp/api-3004.log 2>&1 &
BC_NAME=BC-B RPC_URL=http://172.16.8.14:8545 API_PORT=3005 nohup node index.js > /tmp/api-3005.log 2>&1 &
BC_NAME=BC-B RPC_URL=http://172.16.8.13:8545 API_PORT=3006 nohup node index.js > /tmp/api-3006.log 2>&1 &
# BC-C API servers (ports 3007-3009)
BC_NAME=BC-C RPC_URL=http://172.16.12.12:8545 API_PORT=3007 nohup node index.js > /tmp/api-3007.log 2>&1 &
BC_NAME=BC-C RPC_URL=http://172.16.12.13:8545 API_PORT=3008 nohup node index.js > /tmp/api-3008.log 2>&1 &
BC_NAME=BC-C RPC_URL=http://172.16.12.14:8545 API_PORT=3009 nohup node index.js > /tmp/api-3009.log 2>&1 &注意: IPアドレスはenclaveの再起動で変更される可能性があります。その場合は以下のコマンドで取得してください:
# EL container のIPアドレスを取得
docker inspect <container-name> --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'全4ブロックチェーンとAPIサーバーの状態を確認:
# Enclave状態確認
kurtosis enclave ls
# コンテナ数確認(54個のBCコンテナ)
docker ps | grep -E "el-|cl-|vc-" | wc -l
# APIサーバー確認(9プロセス)
ps aux | grep 'node index.js' | grep -v grep
# 全APIサーバーのヘルスチェック
for port in 3001 3002 3003 3004 3005 3006 3007 3008 3009; do
echo "Port $port:"
curl -s http://localhost:$port/api/v1/health | jq '.data.status, .data.bc_name, .data.chain_id'
done# Stage 2: 複数ノード起動
kurtosis run --enclave testnet-multi \
github.com/ethpandaops/ethereum-package \
--args-file ./kurtosis/multi-node.yaml# Stage 3: プロダクション様設定
kurtosis run --enclave testnet-production \
github.com/ethpandaops/ethereum-package \
--args-file ./kurtosis/production.yaml- bc-x.yaml: 9ノード統合チェーン(Network ID: 20240400、64 validators/node)
- bc-a.yaml: 3ノードサブチェーンA(Network ID: 20240329、128 validators/node)
- bc-b.yaml: 3ノードサブチェーンB(Network ID: 20240330、128 validators/node)
- bc-c.yaml: 3ノードサブチェーンC(Network ID: 20240331、128 validators/node)
- 1つのgeth + lighthouseノード
- 最小設定(minimal preset)
- 開発・テスト用
- 3つのgeth + lighthouseノード
- ピアリング確認用
- ネットワーク安定性テスト用
- 2つのgeth + lighthouse
- 2つのgeth + prysm
- Prometheus/Grafana監視付き
- 本格的なネットワーク設定
# エンクレーブ一覧確認
kurtosis enclave ls
# サービス詳細確認
kurtosis enclave inspect <enclave-name>
# ログ確認
kurtosis service logs <enclave-name> <service-name># APIサーバーを停止
pkill -f 'node.*index.js'
# 特定エンクレーブの削除
kurtosis enclave rm <enclave-name>
# 全エンクレーブの削除
kurtosis clean -a
# クロスチェーン環境のクリーンアップ(個別削除)
kurtosis enclave rm bc-x bc-a bc-b bc-c| ノード | BC-X | BC-A | BC-B | BC-C |
|---|---|---|---|---|
| Node-1 | ✓ | ✓ | ||
| Node-2 | ✓ | ✓ | ||
| Node-3 | ✓ | ✓ | ||
| Node-4 | ✓ | ✓ | ||
| Node-5 | ✓ | ✓ | ||
| Node-6 | ✓ | ✓ | ||
| Node-7 | ✓ | ✓ | ||
| Node-8 | ✓ | ✓ | ||
| Node-9 | ✓ | ✓ |
- BC-X: 27コンテナ(9 EL + 9 CL + 9 VC)
- BC-A: 9コンテナ(3 EL + 3 CL + 3 VC)
- BC-B: 9コンテナ(3 EL + 3 CL + 3 VC)
- BC-C: 9コンテナ(3 EL + 3 CL + 3 VC)
- 合計: 54 BCコンテナ + 9 APIプロセス = 63合計
APIサーバー(REST API):
- BC-A API:
http://localhost:3001-3003/api/v1/ - BC-B API:
http://localhost:3004-3006/api/v1/ - BC-C API:
http://localhost:3007-3009/api/v1/
内部RPCエンドポイント(コンテナ内部):
- BC-A:
http://172.16.4.12:8545,http://172.16.4.14:8545,http://172.16.4.13:8545 - BC-B:
http://172.16.8.12:8545,http://172.16.8.14:8545,http://172.16.8.13:8545 - BC-C:
http://172.16.12.12:8545,http://172.16.12.13:8545,http://172.16.12.14:8545
詳細はアーキテクチャドキュメントを参照してください。
BC-Xにデプロイされた、ドメインチェーン(BC-A/B/C)の登録・管理を行うコントラクト。
主な機能:
- ドメインチェーンの登録(エンドポイント、公開鍵、genesis hashなど)
- チェーンステータスの更新(ACTIVE, DEGRADED, SUSPENDED, REVOKED)
- エンドポイントの更新(primary/backup)
- チェーン情報の取得
デプロイ:
node scripts/deploy.js registry各ドメインチェーンにデプロイされた、ソフトウェア検証情報を管理するコントラクト。
主な機能:
- PURL形式でのソフトウェア登録
- 依存関係の登録・検索
- ZKP(Zero-Knowledge Proof)による検証
デプロイ:
node scripts/deploy.js verification| ファイル | 用途 | 主なオプション |
|---|---|---|
deploy.js |
コントラクトデプロイ統合ツール | all, registry, verification |
check.js |
状態確認・テスト統合ツール | all, registry, contract, verify-key-removal, cross-chain, inject-test-data |
sbom-tool.js |
SBOM生成・登録・統計 | all, generate, inject, stats |
verify-crosschain.js |
クロスチェーン依存パス検証 | - |
test-api.js |
APIサーバーテスト | - |
start-environment.sh |
Kurtosis環境起動 | --clean |
register-chains-to-bc-x.sh |
BC-Xへのチェーン登録 | - |
update-env-rpc.sh |
.env RPC URL更新 | - |
初期のLighthouseコンセンサスクライアントで発生していた "Head block not found in store" エラーは、設定の最適化により解決しました。
- ✅ 完了: PoSネットワークの基本動作確認
- ✅ 完了: 複数ノードネットワークでのテスト
- ✅ 完了: 4ブロックチェーンクロスチェーン環境の構築と検証
- ✅ 完了: SBOM統合ツール作成
- ✅ 完了: スクリプト統合・整理(30→8コアスクリプト)
- ✅ 完了: DomainChainRegistryからkey_id削除(pkg_type+timestampで一意識別)
- Kubernetes環境での展開
- 監視・アラート設定の強化