Skip to content

ikepe/MobS

Repository files navigation

Geth PoS Blockchain Network Development

License: MIT Testnet Only

プロジェクト概要

このプロジェクトは、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

クイックスタート

1. 環境起動(自動)

# 全環境を自動セットアップ
bash scripts/start-environment.sh

# クリーンアップしてから起動
bash scripts/start-environment.sh --clean

2. コントラクトデプロイ

# 全コントラクトをデプロイ(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

3. ドメインチェーン登録

# BC-XにBC-A/B/Cを登録
bash scripts/register-chains-to-bc-x.sh

4. SBOM データ生成・登録

# 一括実行(生成 → 登録)
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      # 統計表示

5. 状態確認

# 全システム確認
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   # テストデータ投入

6. クロスチェーン依存検証

# 依存パス検証・可視化
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

手動起動(詳細手順)

1. 環境準備

# Kurtosis CLIのインストール確認
kurtosis version

# Docker環境確認
docker --version

# Node.js依存関係のインストール
cd api-server && npm install

# 環境変数の確認
cat .env | grep -E "PRIVATE_KEY|RPC_URL"

2. 単一ノードでのテスト

# Stage 1: 単一ノード起動
kurtosis run --enclave testnet-single \
  github.com/ethpandaops/ethereum-package \
  --args-file ./kurtosis/single-node.yaml

3. クロスチェーン環境のデプロイ

4つの独立したブロックチェーンを同時に稼働させる:

# 環境をクリーンアップ(既存の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

4. APIサーバーの起動

各ブロックチェーンの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}}'

5. クロスチェーン動作確認

全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

5. 複数ノードでのテスト

# Stage 2: 複数ノード起動
kurtosis run --enclave testnet-multi \
  github.com/ethpandaops/ethereum-package \
  --args-file ./kurtosis/multi-node.yaml

6. 本格的なマルチクライアント環境

# 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)

単一ノード設定 (single-node.yaml)

  • 1つのgeth + lighthouseノード
  • 最小設定(minimal preset)
  • 開発・テスト用

複数ノード設定 (multi-node.yaml)

  • 3つのgeth + lighthouseノード
  • ピアリング確認用
  • ネットワーク安定性テスト用

本格運用設定 (production.yaml)

  • 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

詳細はアーキテクチャドキュメントを参照してください。

スマートコントラクト

DomainChainRegistry(BC-X)

BC-Xにデプロイされた、ドメインチェーン(BC-A/B/C)の登録・管理を行うコントラクト。

主な機能:

  • ドメインチェーンの登録(エンドポイント、公開鍵、genesis hashなど)
  • チェーンステータスの更新(ACTIVE, DEGRADED, SUSPENDED, REVOKED)
  • エンドポイントの更新(primary/backup)
  • チェーン情報の取得

デプロイ:

node scripts/deploy.js registry

SoftwareVerification(BC-A/B/C)

各ドメインチェーンにデプロイされた、ソフトウェア検証情報を管理するコントラクト。

主な機能:

  • 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エラーの解決

初期のLighthouseコンセンサスクライアントで発生していた "Head block not found in store" エラーは、設定の最適化により解決しました。

次のステップ

  1. 完了: PoSネットワークの基本動作確認
  2. 完了: 複数ノードネットワークでのテスト
  3. 完了: 4ブロックチェーンクロスチェーン環境の構築と検証
  4. 完了: SBOM統合ツール作成
  5. 完了: スクリプト統合・整理(30→8コアスクリプト)
  6. 完了: DomainChainRegistryからkey_id削除(pkg_type+timestampで一意識別)
  7. Kubernetes環境での展開
  8. 監視・アラート設定の強化

参考資料


⚠️ 注意: このプロジェクトはテスト・開発環境専用です。本番環境では使用しないでください。

About

Blockchain-based Software Supply Chain Verification System (TESTNET ONLY)

Resources

License

Contributing

Security policy

Stars

Watchers

Forks

Packages

 
 
 

Contributors