# Avalanche について
###### tags: `Research`

# リンク集
- [JP Twitter](https://twitter.com/avalanchejp)
- [公式HP（日本語対応）](https://www.avalabs.org/)
- [JP Medium](https://medium.com/@AVALabsJP)
- [JP dev向けサイト](https://docs.avax.network/v/japanese/)
- [３分で読めるAvalancheプラットフォームホワイトペーパーの概要](https://medium.com/ava-labs-jp/%EF%BC%93%E5%88%86%E3%81%A7%E8%AA%AD%E3%82%81%E3%82%8Bavalanche%E3%83%97%E3%83%A9%E3%83%83%E3%83%88%E3%83%95%E3%82%A9%E3%83%BC%E3%83%A0%E3%83%9B%E3%83%AF%E3%82%A4%E3%83%88%E3%83%9A%E3%83%BC%E3%83%91%E3%83%BC%E3%81%AE%E6%A6%82%E8%A6%81-36b275460fe8)
- [Whitepaper](https://www.avalabs.org/whitepapers)

# 雑書

- OSSプラットフォーム
- 高度に分散化されたアプリケーション
- 金融プリミティブと相互運用可能なブロックチェーン
- をローンチするプラットフォーム
- 全てのブロックチェーンプラットフォームを一つの相互運用可能なエコシステムに橋渡しする
- オリジナルのBCを構築したり、複雑なルール設定した資産をデジタル化する
- プライベート・パブリックのBCをローンチできる
- デジタル試算の作成や取引が出来る
- スケールのあるスマートコントラクトの構築ができる
- 数千 tps
- 一般PCでノードに参加可能
- 個々

# Solutions
## 独自のブロックチェーンを構築
- パブリックとプライベートのブロックチェーンを、単体の相互運用可能なネットワークでブリッジする
- 新規・既存のブロックチェーンを直接Avalancheに展開し、優れたパフォーマンス・セキュリティ性を活用できる
- GOAL: 特定のルールセットとプライバシー要件を備えたブロックチェーンの導入
- 新規のSubnet・既存のSubnetどちらも使用可能
- EVM・WASM・BTC Script等、任意のものを選択して独自の構築が可能
- ゼロ知識証明など、追加機能をインポートできる
- バリデーターのセットを選択・オープン参加型などにできる
- スマートコントラクトの実装も可能

## 資産の発行
- 問題： 流動性のある新たな資産を生み出すのは非常に困難で、大半の既存資産は効率的に取引されていない
- 解決： Avalancheのスマートアセットプリミティブを通じて資産のデジタル化及びデプロイを新規・既存市場で促進させる
- Ethereumなどとは異なり、Avalanche上の資産は特定の法規に対応できる

# hoge
- 二つのコンセンサス
- Avalanche： DAGに最適化したコンセンサスプロトコル
- Snowman： チェーンに最適化されたコンセンサスプロトコル
- Go言語での実装
- Avalanche上の仮想マシンAPIと対話するためのJSON RPC
- AvalancheJS: Avalanche API と対話するためのjsライブラリ
- Avash: Avalanche上でテスト目的のためにローカルネットワークを迅速に作成できるようにすることを目的としている
- Avalanche Wallet and Faucet: ウォレットとフォーセットサーバがOOS化された

既存プロトコルとの比較
（議論からの推定値。** 理論上数百万人の参加者に対応可能）

51％攻撃耐性

# whitepaper memo
- snowmanは、全参加ノードを把握しない
- しかし、任意の二つのノード間に不一致があっても、高い安全性を維持する
- Snowプロトコルは完全なメンバー（ノード）の知識がなくとも、検証できる能力を享受している
- 参加ノード上限なし
- コア部分はPoSで動く。独自の各チェーン（サブネットの設定次第ではという表現のが正しい？）はPoWとかを選択することも可能
- 51％を超えても教護な安全性を維持する
- Avalancheコンセンサス(Snowman？)は古典的なコンセンサスとナカモトコンセンサスの両方の長所を引き継いだもの
- Snowmanはネットワークの繰り返しサンプリングによって動作する
- TXを承認する代表バリデータがTXの賛否を判断する
- その判断の賛否を一部バリデータが判断する
- さらにその判断を他の一部バリデータが判断
- 以下収束するまでループ
- なおこの処理は早い
- 同一のTXを承認してしまわないかはノード毎に確認しあう？的なことで防ぐ
- Snowmanは安全な動作のために同規性を必要としない。したがって、ネットワークの分割が発生しても二重支払いを防げる
- サブネット： バリデータの動的なセット
- 各チェーンには１つのサブネットが存在
- 1つのサブネットは任意の数のチェーンを検証
- バリデータは任意の数のサブネットのメンバーになれる
- サブネットは誰がサブネットに入るかを決定し、厚生するバリデータに特定の特性を持たせられる
- ネイティブトークン： AVAX
- プライベートなサブネットも作れる
- 各バリデータは特定のプロパティを持つサブネットを作れる
- 特定地域の人専用のサブネット
- 実世界の契約とリンクしたサブネット
- など
- デフォルトサブネットと呼ばれる特別なサブネットもある
- このサブネットは全てのバリデータによって検証される
- つまり、どのサブネットも検証をするにはデフォルトサブネットを同様に検証する必要がある
- デフォルトサブネットはAVAXが存在し、取引されているチェーンを含む、事前に定義したチェーンのセットを検証する
- シードアンカー： まだよくわからない
- EVM互換
- Solidity++という改良版言語
- WASMやDAMLなどほかのVMも対応したサブネットを作れる（設定できる？）
- ３つのクライアントタイプ
- アーカイブ
- フル
- ライト
- フルクライアントは過去全てのデータ・履歴を保持し続けない
- アーカイブクライアントが過去のデータを持つ
- フルクライアントはアクティブな（現在必要になる未使用TXなど）を保持
- 履歴を同期することなく、あるTXがコミットされたことを証明する
- ライトクライアントはネットワーク全体のコンセンサスを保証するための、プロトコルの繰り返しサンプリングに関与する
- したがって、ライトとフルは同じセキュリティ保証を提供する
- 量子コンピュータなどへの対策としては、新しい暗号化プロトコルなどを実装可能に設計することで対応していく？
- コアとして機能し、元から存在する３つのチェーンがある（これがデフォルトサブネット？）
- Platform Chain（P-Chain）
- Exchange Chain（X-Chain）
- Contracts Chain（C-Chain）

# プロトコル Whitepaper
## 1. はじめに
- Snowプロトコル
- SnowファミリーはSnowプロトコルを使ったコンセンサスの一つのバージョン？（Snowが基盤、それを使う上で改良した様々な形のようなイメージか？）
- Snowはゴシップ・アルゴリズムにヒントを得た
- ゴシップアルゴリズムとは
- システム参加者間で繰り返し確率的に情報を交換する手法。システムの参加者を把握できない状況や、一時的に通信できない場合でも情報を伝搬できる。
- Snowはナカモトコンセンサスと同様に、確率論的ファイナリティを持たせる
- PoWに依存せず、エネルギーを消費しない
- 高TPS、低遅延
- 定足数ベースのサブサンプル投票メカニズムでは、事前に設定した閾値fを超えると即破綻する
- Snowはビザンチン参加者がfを超えるとスムーズに劣化する
- AvalancheはこのSnowインスタンスをDAGの助け借りて実行するもの
- 本論文の主な貢献は、ランダム化サンプリングと準安定決定に基づいた、新しいコンセンサス・プロトコル群を紹介すること

## 2. モデルと目標
- 確率論的な安全保障は実はハードウェアの失敗確率より凄い
- 
- Snowflake（Snowファミリーの中の一つ）はk=10, β=150で構成される
- Snowflake-7,8はそれぞれa=7,a=8
- 
- 

## 3. プロトコル設計
- Slushという非BFTプロトコルから始まり、Snowflake、Snowballと段階的に構築（紹介？）していく
- これらは全て共通の多数決ベースの準安定投票メカニズムに基づいている
- これらのプロトコルは単一決定権を持つコンセンサスプロトコル

### Slush
- 挙動
- 前提条件？
- ノードは最初、無色からスタートする
- トランザクション（クエリ）には色がある
- 無色ノードがTXを受け取ったらその色に変化
- 既に色を持つノードは色の変化なし。
- 更新後、問い合わせ（クエリ？）を開始する
1. ノードはネットワークの一定サイズ（k）のサンプルを一様に無作為に選び、クエリメッセージを送信
2. 受信したノードは前提条件に基づき色の変化を行う
3. 問い合わせを行ったノードがkこの応答を収集すると、 a > b の割合でa個の応答が同じ色であるかをチェックする
- このとき、a > bk/2c はプロトコルパラメータである
4. もしaの閾値が満たされ、サンプルされた色がノード自身の色と異なる場合、ノードはその色に反転する
5. その後問い合わせステップに戻り、照会ステップに戻り、次のラウンドの紹介を開始する
6. 合計でmラウンド行う
7. 最終的に時刻mで得られた色を決定する
8. mを十分に大きくすると、全てののーおは高確率で同じ色になる。

### Snowflake:BFT
-