こんにちは。BOOSTRY CTO の麻生です。
BOOSTRYではこれまで ibet for Fin を中心にしたコンソーシアムブロックチェーン上でのシステム開発を主に行ってきました。しかし、今年度からはパブリックチェーン上でのプロトコル開発にも力を入れています。
その一環として、Avalanche（アバランチ）の技術調査を実施しました。本記事では、その調査内容の一部を共有いたします。
本調査は B.O.O.S.T. Lab の活動の一環として行ったものです。調査内容は2025年10月7日時点の情報となります。記事内の外部リンクなどは今後変更になる可能性がありますので、あらかじめご了承ください。
また、事業目線でのセキュリティトークンにおけるパブリックチェーンの活用の可能性や課題については以下のブログにまとまっていますので併せてご参照ください。
1. 主な特徴
Avalancheは、高速かつスケーラブルなスマートコントラクト対応のブロックチェーンプラットフォームです。主な特徴は以下の通りです。
- 独自のコンセンサスメカニズムによる高いスループットと低レイテンシ
- Snowball コンセンサスを採用し、高いトランザクション処理性能と低遅延を実現しています。
- Avalancheでは明確なファイナリティがあり、取引が数秒以内に確定します。
- 比較的安価な手数料
- マルチL1チェーン
- X-Chain（Exchange Chain）
- C-Chain（Contract Chain）
- P-Chain（Platform Chain）
- 独自L1チェーンも構築可能です。
- 安全性と分散性
- Avalancheのバリデータ選定はPoSで行われており、バリデータの集中化を防ぎ、高いセキュリティを実現しています。
2. コンセンサスアルゴリズム
参考：https://build.avax.network/docs/quick-start/avalanche-consensus
2-1. 簡単なイメージ
Avalancheのコンセンサスアルゴリズムの基本ルールは、「各ノードが周囲のノードの大多数の意見に合わせる」というものです。
例えば、64人がいる部屋でランチのメニューを決めるとします。選択肢は中華かカレーの二択で、最終的には全員が同じものを注文しなければならないとします。この場合、以下のような流れで意思決定が進みます。
- それぞれの人がランダムに選んだ5人に「中華とカレー、どちらが良いですか？」と尋ねます。
- 最初に中華を選んだAさんが、半数以上から「中華」と返答された場合はそのまま中華を選びます。半数以上が「カレー」と答えた場合はカレーに変更します。
- 他の人も同様にこの質問プロセスを同時並行で繰り返します。
- ラウンドを重ねるごとに多数派の意見が広がり、全員が徐々に同じ意見に収束していきます。多数派の答えが変わらなくなった時点でプロセスを終了します。
この仕組みをブロックチェーンに置き換えると、64人がノード、部屋がネットワーク、中華またはカレーの選択がトランザクションの承認・拒否に相当します。
Avalancheコンセンサスでは、
としてパラメータ調整が可能です。トランザクションに競合がなければ、合意形成は非常に迅速に進みます。
2-2. Snowball アルゴリズム
Avalanche で採用されているコンセンサスアルゴリズムは Snowball アルゴリズムと呼ばれます（雪玉→雪崩）。以下で、Snowball アルゴリズムの詳しい仕様について説明します。
⚙️ パラメータ
🔁 アルゴリズム
preference := pizza
consecutiveSuccesses := 0
while not decided:
ask k random people their preference
if >= α give the same response:
preference := response with >= α
if preference == old preference:
consecutiveSuccesses++
else:
consecutiveSuccesses = 1
else:
consecutiveSuccesses = 0
if consecutiveSuccesses > β:
decide(preference)
- 各ノードは初期の選択（例：ピザ）を持つ。
- 決定が確定するまで、ノードはランダムに
k人へ好みを問い合わせる。 - クォーラムサイズ
α人以上が同じ回答をした場合、その回答を自分の新しい好みに採用する。 - 新しい好みが以前と同じなら「連続成功カウンター」を
+1。違っていればカウンターは1にリセット。 - クォーラムサイズを満たせなかった場合はカウンターを
0にリセット。 - 連続成功カウンター が
βを超えたら、その選択を最終決定とする。
💡 特徴
- 確率的合意形成：ランダムサンプリングによって、ネットワーク全体が自然と特定の選択肢に集約されていきます。
- 多値対応：選択肢は2つに限らず、複数の選択肢にも対応可能です。
- 安全性と応答性の調整：
αを大きくすると安全性が向上し（悪意のあるノードへの耐性UP）、βを調整することで最終決定までの速度を制御できます。
🔥 Avalanche ネットワークの実際のパラメータ
k= 20（20ノードへ問い合わせ）α= 14（14ノード以上が同意すれば採用）β= 20（同じ結果を20回連続で得たら決定）
Avalancheでは、これらのパラメータを採用することで、悪意のあるノードへの耐性を持たせているとともに、β を採用することで、明確なファイナリティを持たせています。この点は、BitcoinなどのPoWチェーンとは明確に異なる点です。現状では、数秒で β の水準に達するようにコントロールされているようです。
2-3. Validator
Avalanche における Validator の選任には、PoS が採用されています。後述するネイティブトークン AVAX をステークすることにより Validator になることが可能です。後述する Primary Network の Validator になるための最低ステーク量は 2000 AVAX で、ステーク量によるコンセンサス参加の重みづけが存在します。
2-4. その他 FAQ
Q: ゼロブロックは存在するか？
→ A：存在しません。1ブロックには必ず1つ以上のトランザクションが含まれます。
Q: 実際どれくらいのレイテンシーでトランザクションに取り込まれるか？
→ A：トランザクションの負荷やノードの接続状況によりますが、通常は1〜2秒以内にファイナライズされます。ただし、状況によっては時間がかかる場合もあるため、トランザクション送信から結果確認まで非同期で設計することをおすすめします。
3. ネイティブトークン（AVAX）
AvalancheにはネイティブトークンAVAXが存在します。
- 最小単位
- 1nAVAX = 0.000000001 AVAX
- 発行上限
- 7億2000万枚に設定されています。*1
- 利用用途
- PoS *2
- トランザクション手数料（Gas）*3
*1: 初期に3億6千万枚が発行され、その後徐々に発行されています。発行は一定のルールに従って行われます。
*2: 参考 - Validator 報酬の計算式
*3: Avalancheではトランザクションで利用されたAVAXの一部がBurnされる仕様となっており、AVAXの希少性を高めています。
4. Avalanche L1s
参考：https://build.avax.network/docs/quick-start/avalanche-l1s
4-1. Avalanche ネットワークの基本構成
Avalanche のネットワークは、複数のネットワークが並行して運用される構成がとられています。Avalanche ネットワークは、以下の要素によって構成されます。
- Primary Network
- Avalanche L1s
- ICM（Interchain Messaging）
以降で、それぞれについて説明していきます。
4-2. Primary Network
⛓️ P-Chain
- 「Platform VM」と呼ばれる VM が動くネットワークです。
- 各 Avalanche L1 （後述）の Validator のセットと、各ネットワークにおけるステーク量、Validatorの公開鍵（BLS公開鍵）の情報を管理します。各 L1 ごとにチェーンが存在します。
- 新しいブロックチェーンと Avalanche L1 の作成、Avalanche L1へのバリデータの追加、ステーキングなどのオペレーションが行われます。
⛓️ C-Chain
- Snowball コンセンサスで動く Ethereum 仮想マシン（EVM）です。
- Ethereum クライアントである Geth のフォークで、コンセンサスレイヤーが置き換わっています。GethのAPIをサポートしています。
- スマートコントラクトは Solidity で記述することができます。
- 実装：ava-labs/coreth
⛓️ X-Chain
- Snowball コンセンサスで動く独自の Avalanche 仮想マシン（AVM）が動くネットワークです。
- X-Chain 上では、Avalanche 上で流通されるネイティブトークンの発行と他のトークンとの交換が可能です。
4-3. Avalanche L1s
Primary Networkのほか、独自L1の実装も可能です。各L1は「Avalanche L1」という単位で管理されます。
- Avalanche L1ごとにValidatorのグループが存在します。
- 1つのAvalanche L1で複数のブロックチェーンをホストできます。
独自ネットワークは以前は「Subnet」と呼ばれていましたが、2024年12月16日のEtnaアップデートにおいて採用された提案（ACP-77 *1）によって、「Avalanche L1s」あるいは簡易的には「L1s」と呼ばれるようになっています。
*1: 参考：ACP-77 （ACP: Avalanche Community Proposals）
また、各 Avalanche L1 のValidator については、以下のように管理されます。
- Primary Network の P-Chain によって管理されている。
- Primary Network の Validator は 2000 AVAX のステーキングが必要であったが、ACP-77 採用以降、各Avalanche L1のValidatorについてはステーキングは必要ない。しかしながら、後述するメンテナンス料は発生する。
- Avalanche L1 のすべての Validator は、相互運用性を確保するために Primary Networkの P-Chain を同期する必要がある。
各 L1 は他の L1 から分離されているため、ある L1 での負荷が上がったとしても、別の L1 のパフォーマンスに影響を与えることはありません。
L1 Validator の運用コスト
ACP-77では、各L1 ValidatorがP-Chainに対して継続的に手数料を支払う仕組みが導入されました。手数料はバリデーターがP-Chain上でアクティブな時間に応じて課金され、P-Chainのリソース使用量に基づいています。手数料率はネットワーク全体のバリデーター数やP-Chainの負荷状況に応じて動的に調整されます。バリデーターが最低限いる状況下では、1人のL1バリデーターがP-Chainに支払う手数料は月額約1.33 AVAXとされています。支払い方法と運用方法は以下の通りです。
- 残高の管理：各L1バリデーターはP-Chain上にAVAXの残高を保持し、手数料がこの残高から継続的に差し引かれます。
- 残高がゼロになった場合：残高がゼロになるとValidatorは「非アクティブ」となり、P-Chain上でのValidation活動が停止されます。
- 再アクティブ化：残高を補充することで、Validatorは再びアクティブな状態に戻ることができます。
独自 L1 を実装する
L1実装のアプローチとしては2つ存在します。
4-4. ICM（Interchain Messaging）
参考：https://build.avax.network/docs/cross-chain/avalanche-warp-messaging/deep-dive
Avalanche はネイティブでチェーン間のメッセージングの仕組みをサポートしています。ICMを利用することで、以下のようなことが実現できます。
ICMは以下の流れで実現されます。
<STEP-1> 送信元 L1 でメッセージに署名する
Avalancheネットワーク上のすべての Validator は、メッセージに署名するための秘密鍵と、他のユーザーが署名を検証するために使用できる公開鍵で構成されるBLS鍵ペアを保持しています。これらは Validator がネットワークに参加する際に、P-Chain に記録されます。送信元の Validator は L1間で送信したいメッセージに対して、BLS 署名を行います。未署名のメッセージフォーマットは以下の通りです。
+---------------+----------+--------------------------+
| codecID : uint16 | 2 bytes |
+---------------+----------+--------------------------+
| networkID : uint32 | 4 bytes |
+---------------+----------+--------------------------+
| sourceChainId : [32]byte | 32 bytes |
+---------------+----------+--------------------------+
| payload : []byte | 4 + size(payload) |
+---------------+----------+--------------------------+
| 42 + size(payload) bytes|
+--------------------------+
codecID：ペイロードをシリアル化するために使用されるコーデックのバージョンであり、現状では0x0000でハードコードされています。networkID：Avalancheネットワーク（メインネット/テストネット）の一意のIDであり、異なるAvalancheネットワーク間でのリプレイアタックを防ぎます。sourceChainID：P-Chain に L1 チェーンを登録した際のトランザクションハッシュ。Avalancheネットワーク全体でブロックチェーンの一意の識別子として機能し、各ブロックチェーンは自身のIDでのみメッセージに署名できる。- payloadメッセージの内容を含む任意のバイト配列。VMは独自のメッセージタイプを payload 内に定義する。
<STEP-2> 署名集約→送信
送信元 L1 でBLS署名集約が行われます。署名の集約方法は任意です。署名自体の改ざんは不可能なので、署名集約は誰が行なっても良いです。集約＆送信を行うことだけを担う Relayer を個別に置くことも可能です。その場合、Relayerは送信元L1のValidatorから署名を受け入れ、それを集約します。
集約された署名は以下のような構造になります。
+-----------+----------+---------------------------+
| type_id : uint32 | 4 bytes |
+-----------+----------+---------------------------+
| signers : []byte | 4 + len(signers) |
+-----------+----------+---------------------------+
| signature : [96]byte | 96 bytes |
+-----------+----------+---------------------------+
| 104 + size(signers) bytes |
+---------------------------+
- typeID：この署名タイプの ID で、0x00000000 で固定。
- signers：署名者は、検証者の署名が含まれるビットセットをエンコードします。
- signature：集約された BLS署名。
集約された署名が、送信先 L1 に送信されます。送信元 L1 の Validator から送信先 L1 の Validator にデータをどのように転送するか、また転送の報酬を設定するかどうかは、各L1 とそのユーザーによって任意に決められます。
<STEP-3> メッセージ検証
送信先で送信元のメッセージを処理する際に、P-Chain に登録されている Validator の BLS公開鍵と送信元L1 でのステーク量を参照します。署名の有効性の水準は各通信の個別の要件に応じて設定することが可能です。例えば、送信先のL1-A では、送信元全ステーク量の「70%以上」となるValidatorからの署名があればそのメッセージを受け付けるなど、受け入れの水準は要件に応じて決めることができます。
具体的な実装としては、スマートコントラクトとして実装された ICM コントラクトが存在します。
C-Chain上には既にデプロイされているものが存在するため、追加で以下の手順を踏むことによって ICM の利用が可能になります。
5. ネットワーク接続
5-1. ネットワークの選択
Avalanche上でDappsを開発する場合、独自ブロックチェーン（Avalanche L1）を構築するケースは少なく、通常はPrimary NetworkのC-Chainを利用することが多いと思われます。主な理由は以下の通りです。
- 既存 C-Chain アセットとの統合
- 既存のC-Chainアセットやコントラクトと統合を行うことができます。
- C-Chain 上に既に大きな流動性プールが存在しており、知名度の高いアセット間の効率的な交換が可能です。
- 例：USDC - Blockchain explorer for Avalanche L1s
- 低いコスト
- 高いセキュリティ
- Avalanche Primary NetworkはPoSによる分権的なValidatorにより長期間安定運用されています。2020年9月のメインネットローンチ以降、コンセンサスに関する重大な問題は発生していません。*1
*1: ソフトウェア関連のバグによる障害として、過去に2度ほどブロック生成が数時間停止した事例があります（2023年3月、2024年2月）
以下では、C-Chain 利用を前提とした Dapps 開発に関連する情報を説明していきます。
5-2. ネットワークの分類
他のブロックチェーンプラットフォームと同様、メインネットの他にテストネットが存在します。また、開発用途では、ローカルネットワークも容易に構築が可能です。
(1) メインネット
本番ネットワークです。実際の$AVAX（現実の金銭的価値を持つ）が利用できます。
- 公式 RPC URL：https://api.avax.network/ext/bc/C/rpc
- 公式 WebSocket URL：wss://api.avax.network/ext/bc/C/ws
- ChainID：43114
- シンボル：AVAX
- エクスプローラ：https://subnets.avax.network/c-chain
(2) テストネット（Fuji testnet）
テスト用のネットワークです。テスト用の$AVAX（金銭的価値はない）が利用できます。
- 公式 RPC URL：https://api.avax-test.network/ext/bc/C/rpc
- 公式 WebSocket URL：wss://api.avax-test.network/ext/bc/C/ws
- ChainID：43113
- シンボル：AVAX
- エクスプローラ：https://subnets-test.avax.network/c-chain
(3) ローカルネット
ローカル環境に構築するネットワークです（5-3で後述）。
(4) その他：Hardhat
C-Chain自体はEVMフォークのチェーンであるため、EthereumのDapps開発と同様、コントラクト層の開発においては、Hardhatの利用が可能です。Mock ネットワークの設定については、以下のURLが詳しいです。
Hardhatの設定例：Hardhat | Avalanche Builder Hub
5-3. ローカルネットの構築方法
上述の通り、C-Chainにはテストネットが存在しますが、開発現場ではテストネット接続前の開発環境としてローカルネットが必要になる場合も多いです。ここではC-Chainのローカルネット構築手順を補足します。以下はmacOS環境を前提としています。
1. avalanche-cli をインストールする
最新版をインストールします。
curl -sSfL https://raw.githubusercontent.com/ava-labs/avalanche-cli/main/scripts/install.sh | sh -s
上記コマンドを実行すると、bash-completion のインストールを求められて、エラーになる場合があります。その場合は、homebrew でインストールを行います。
bash-completion — Homebrew Formulae
.bashrc などのシェル初期化スクリプトにPATHを定義することで avalanche コマンドを実行できるようになります。
export PATH=~/bin:$PATH
動作確認
$ avalanche --version avalanche version 1.8.10
2. ネットワーク起動
ローカル環境で、Primary Network を起動する方法は以下の通りです。
$ avalanche network start （途中省略。以下は出力例。） +------------------------------------------------------------------+ | PRIMARY NODES | +------------------------------------------+-----------------------+ | NODE ID | LOCALHOST ENDPOINT | +------------------------------------------+-----------------------+ | NodeID-7Xhw2mDxuDS44j42TCB6U5579esbSt3Lg | http://127.0.0.1:9650 | +------------------------------------------+-----------------------+ | NodeID-MFrZFVCXPv5iCn6M9K6XduxGTYp891xXZ | http://127.0.0.1:9652 | +------------------------------------------+-----------------------+
ネットワークの状態を確認してみます。
$ avalanche network status （以下は出力例） Network is Up: Number of Nodes: 2 Number of Blockchains: 0 Network Healthy: true Blockchains Healthy: true +------------------------------------------------------------------+ | PRIMARY NODES | +------------------------------------------+-----------------------+ | NODE ID | LOCALHOST ENDPOINT | +------------------------------------------+-----------------------+ | NodeID-7Xhw2mDxuDS44j42TCB6U5579esbSt3Lg | http://127.0.0.1:9650 | +------------------------------------------+-----------------------+ | NodeID-MFrZFVCXPv5iCn6M9K6XduxGTYp891xXZ | http://127.0.0.1:9652 | +------------------------------------------+-----------------------+
これだけで、ノード2台で構成されるローカルネットが構築されます。なお、ここでは詳細は割愛しますが、avalanche cli を利用して Avalanche L1 の設定も簡単に行うことができます。
3. C-Chain 設定情報の確認
ローカルネットの C-Chain の基本情報は以下のようにして確認することができます。初期状態で、テスト用アドレス（以下であれば0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC） に、1,000,000,000,000 AVAX がチャージされた状態になります。
$ avalanche primary describe
✔ Local Network
_____ _____ _ _ _____
/ ____| / ____| | (_) | __ \
| | ______| | | |__ __ _ _ _ __ | |__) |_ _ _ __ __ _ _ __ ___ ___
| | |______| | | '_ \ / _ | | '_ \ | ___/ _ | '__/ _ | '_ _ \/ __|
| |____ | |____| | | | (_| | | | | | | | | (_| | | | (_| | | | | | \__ \
\_____| \_____|_| |_|\__,_|_|_| |_| |_| \__,_|_| \__,_|_| |_| |_|___/
+---------------------+--------------------------------------------------------------------+
| PARAMETER | VALUE |
+---------------------+--------------------------------------------------------------------+
| RPC URL | http://127.0.0.1:9650/ext/bc/C/rpc |
+---------------------+--------------------------------------------------------------------+
| EVM Chain ID | 1337 |
+---------------------+--------------------------------------------------------------------+
| TOKEN SYMBOL | AVAX |
+---------------------+--------------------------------------------------------------------+
| Address | 0x8db97C7cEcE249c2b98bDC0226Cc4C2A57BF52FC |
+---------------------+--------------------------------------------------------------------+
| Balance | 3875820019.312888622 |
+---------------------+--------------------------------------------------------------------+
| Private Key | {private_key} |
+---------------------+--------------------------------------------------------------------+
| BlockchainID (CB58) | 5T24nSPnQ4WWiW5uC3SLYovGVRTNK9GRxXdHH5AoShGp1bR71 |
+---------------------+--------------------------------------------------------------------+
| BlockchainID (HEX) | 0x0a19dff4513d7c6dae8a199295fa48ec5c07b6b8cd4ca169cec4c930bb024060 |
+---------------------+--------------------------------------------------------------------+
6. ノード運用
公式ノード実装としてavalanchegoが提供されています。avalanchegoのFull Nodeを立ち上げると、Primary Networkの全てのネットワークノードクライアント（VM）が起動し、チェーンデータが同期されます。
6-1. ノードの種類
- Full Node
- Validator Node
- RPC node
- Full Node のインターフェイスとして機能します。
6-2. システム要件
Avalanche Go ノードを実行させるための実行させるための要件としては、公式ドキュメント上では以下の通り示されています。
参考：https://build.avax.network/docs/nodes/system-requirements
サーバー要件
通信要件
6-3. Docker イメージの利用
システムの実運用においては、Docker イメージを用いてノード運用を行うことが想定されます。公式の docker イメージが提供されており、簡単にノードの起動を行うことが可能です。
https://hub.docker.com/r/avaplatform/avalanchego
🚀 Mainnet の場合
docker run --rm --name avalanche-mainnet -d -v /host/avalanche:/root/.avalanchego -p 9650:9650 -p 9651:9651 -e AVAGO_HTTP_HOST=0.0.0.0 avaplatform/avalanchego:v1.13.0 /avalanchego/build/avalanchego
🚀 Testnet の場合
docker run --rm --name avalanche-testnet -d -v /host/avalanche:/root/.avalanchego -p 9650:9650 -p 9651:9651 -e AVAGO_HTTP_HOST=0.0.0.0 avaplatform/avalanchego:v1.13.0 /avalanchego/build/avalanchego --network-id=fuji
6-4. その他参考情報
Bootstrap
ブロックチェーンの同期においては、ブロックデータの同期と共に、そのデータの検証、データの再構成が必要になってきます。この処理は「Bootstrap」と呼ばれるもので、Bootstrap中はノードのRPCサービスは利用できない状態に制御されます。
ノード起動オプション
他のノード起動オプションについては、以下のリンクを参照してください。
ノードを Validator へ昇格
FullNode から Validator への昇格手順は以下のドキュメントを参照してください。
7. まとめ
本記事では、Avalancheの基本的な仕組みについて解説しました。AvalancheはSnowballアルゴリズムによる独自コンセンサスを採用し、非常に高速かつ安全にトランザクションを処理できるプラットフォームです。Avalanche L1sの仕組みにより、柔軟に独自ブロックチェーンを構築できる点も大きな特徴です。C-ChainはEVMフォークであるため、Ethereumのエコシステムを活用しつつ、低コストで高速なトランザクション処理が可能です。日本国内でも金融分野でAvalancheの採用を検討する事例が増えており、今後の動向が注目されます。
最後に、本記事は社内勉強会資料をもとに再整理したものです。BOOSTRYでは毎週、社内で技術勉強会を開催し、ブロックチェーンをはじめとする先端技術の知見をメンバー間で共有しています。この記事を通じて、BOOSTRYの技術への取り組みやブロックチェーン技術の可能性に少しでもご興味を持っていただければ幸いです。今後も研究開発およびプロダクト開発を通じて、より効率的で機能性の高い先進的な金融市場の実現に向けて取り組んでまいります。引き続きBOOSTRYの活動にご注目ください。
ご興味のある方は、ぜひ採用情報もご覧ください。私たちは、金融×ブロックチェーンという難しくもやりがいのある領域で、新しい市場を共に創る仲間をいつでも歓迎しています。
