onchain dev
onchain dev
Subscribe to posaune0423
Subscribe to posaune0423
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
「なぜ早いのか」 => 「どういう仕組で71000TPS (from Solana Docs)をさばいているのか？」※ VISAのTPS = 4000万
大きく分けて以下の３つ。
合意形成アルゴリズムにPoH(Proof oh History)を採用している
これにより合意形成時にノードの同期が必要なく非同期にtransactionを処理できる。 ⇒ Turbin
バリデータノードのマシンスペック要求が高い
Gas Auctionがない
SolanaはPoHを採用しているというのはPoHのみで動いているというわけではない。以下の図のようにPoH生成者がただ一人存在しており、このPoH生成者はPoSバリデータの投票により選出される。Solanaの合意形成においてはノードの2/3以上のバリデータの支持により最終的に合意形成が完了される。したがって攻撃者は少なくともtotalSupplyの1/3以上の通貨を保持しなければこの投票を覆すことはできない。
Proof of Historyと呼ばれるSolanaが採用している合意形成アルゴリズムのこと。具体的には任意の２つのイベントの時系列を暗号学的に検証するためのスキームである。
Solanaでは他の主要なブロックチェーン(Ethereum, Bitcoin)などと異なり、トランザクションの承認処理を待たずに次のトランザクションの承認に次々に進んでいき、この時ノード間では完全な同期は取らない。そうすることで各ノードは非同期にVerify作業が行なえ、TPSの向上につながっている。
ここで問題なのは、バリデータの承認を待たずに次のトランザクションを捌くということは、バリデータAとバリデータBが同時に新しいブロックを提案する可能性もある。この時他のバリデータはブロックA、ブロックBの両ブランチに投票することで利得が最大化されるが、これはシステムのセキュリティを低下させる(Nothing at Stake問題)ため、これを防ぐのがTower BFTというサブプロトコルになっている。
分散システムでは、ノード数を増やすと、すべてのノードにすべてのデータを伝搬するのに必要な時間が長くなることがあります。Turbineはこの問題を解決することを目的としたブロック伝搬プロトコルです。あるノードが非常に大きなメッセージを1,000人のピアに伝搬する場合、1,000回伝搬するのではなく、メッセージを小さなパケットに分割して、それぞれのパケットを異なるノードに送信します。
各バリデーターはネイバーと呼ばれるピアのグループにパケットを順番に再送します。各ネイバーは、データの一部を隣接する各ネイバーに送信する責任があり、仮に各ネイバーが200ノードで構成されている場合、ルートに1人のリーダーがいる3レベルのネットワークでは、2ホップで40,000人のバリデータをカバーすることができます。
またデータを再ブロードキャストしないことを選択する可能性のある敵対ノードを処理するために、つまり障害に対して耐性を持たせるためにバリデーターはReed-Solomon Erasure コードを使用してデータを符号化し、ある程度の障害耐性を提供することが可能になります。
Tower-BFTは、ソラナのPoH（Proof of History）上で実行しています。これはPoHに最適化されたPBFTに類似したコンセンサスアルゴリズムであり、通信のオーバーヘッドとレイテンシーを削減します。
ネットワーク上のノードが特定のフォークに投票するたびに、投票はスロットと呼ばれる一定期間のハッシュに制限されます。現在のネットワークの設定では、1つのスロットに約400ミリ秒の時間が設定されています。400ミリ秒ごとにネットワークはロールバックポイントを持っていますが、それ以降の投票を行うたびに、その投票をアンロールするまでにネットワークが停止しなければならない時間が2倍になります。
例えば、各バリデータは過去12秒の間に32回投票しています。12秒前の投票では、タイムアウト時間は2³²スロット、つまり約54年ですので実質的に、この投票はネットワークによってロールバックされることはありません。一方、直近の投票は2スロット、約800msのタイムアウトとなります。新しいブロックが台帳に追加されると、古いブロックはますます確定される可能性が高くなります。なぜなら、古い投票がコミットされているスロットの数がスロットごとに、または400msごとに倍増するからです。
ソラナのメインネットは、Delegated-Proof-of-Stake （DPoS）で運営される予定で、トークン保有者はブロックの生産プロセスに参加して報酬を得ることができ、トークンをステークして自らバリデータになるか、信頼するバリデータにトークンを委任することができます。
CPU
12 cores / 24 threads, or more
2.8GHz, or faster
AVX2 instruction support (to use official release binaries, self-compile otherwise)
Support for AVX512f and/or SHA-NI instructions is helpful
The AMD Zen3 series is popular with the validator community
RAM
128GB, or more
Motherboard with 256GB capacity suggested
Disk
PCIe Gen3 x4 NVME SSD, or better
Accounts: 500GB, or larger. High TBW (Total Bytes Written)
Ledger: 1TB or larger. High TBW suggested
OS: (Optional) 500GB, or larger. SATA OK
The OS may be installed on the ledger disk, though testing has shown better performance with the ledger on its own disk
Accounts and ledger can be stored on the same disk, however due to high IOPS, this is not recommended
The Samsung 970 and 980 Pro series SSDs are popular with the validator community
GPUs
Not strictly necessary at this time
Motherboard and power supply speced to add one or more high-end GPUs in the future suggested
The hardware recommendations above should be considered bare minimums if the validator is intended to be employed as an RPC node. To provide full functionality and improved reliability, the following adjustments should be made.
CPU
16 cores / 32 threads, or more
RAM
256 GB, or more
Disk
Consider a larger ledger disk if longer transaction history is required
Accounts and ledger should not be stored on the same disk
他のブロックチェーンの合意形成でよく見られる、メモリプールに未承認のトランザクションをプールし、トランザクションに優先度をつけるといったことをSolanaでは行いません。まずプーリングをするとトランザクションがプール上にたまり渋滞を起こします。バリデータが自分の利益のためにGas代の高いものから順にトランザクションを承認しようとするGas Auctionが始まってしまいます。そうすると、トランザクションを優先して通したいClient側はさらにGas代を上乗せするといった悪循環からGas代の高騰などが起きてしまいます。
これを解決するためにSolanaではプールを行わず優先度を恣意的に決められるような設計は採用しておらず、トランザクションがプールされることもないことも処理速度の高速化につながっていると考えられます。
https://docs.solana.com/introduction
https://github.com/solana-labs/whitepaper/blob/master/solana-whitepaper-en.pdf
https://coinchoice.net/8-innovation-of-solnaa-towerbft-turibne_202006/
「なぜ早いのか」 => 「どういう仕組で71000TPS (from Solana Docs)をさばいているのか？」※ VISAのTPS = 4000万
大きく分けて以下の３つ。
合意形成アルゴリズムにPoH(Proof oh History)を採用している
これにより合意形成時にノードの同期が必要なく非同期にtransactionを処理できる。 ⇒ Turbin
バリデータノードのマシンスペック要求が高い
Gas Auctionがない
SolanaはPoHを採用しているというのはPoHのみで動いているというわけではない。以下の図のようにPoH生成者がただ一人存在しており、このPoH生成者はPoSバリデータの投票により選出される。Solanaの合意形成においてはノードの2/3以上のバリデータの支持により最終的に合意形成が完了される。したがって攻撃者は少なくともtotalSupplyの1/3以上の通貨を保持しなければこの投票を覆すことはできない。
Proof of Historyと呼ばれるSolanaが採用している合意形成アルゴリズムのこと。具体的には任意の２つのイベントの時系列を暗号学的に検証するためのスキームである。
Solanaでは他の主要なブロックチェーン(Ethereum, Bitcoin)などと異なり、トランザクションの承認処理を待たずに次のトランザクションの承認に次々に進んでいき、この時ノード間では完全な同期は取らない。そうすることで各ノードは非同期にVerify作業が行なえ、TPSの向上につながっている。
ここで問題なのは、バリデータの承認を待たずに次のトランザクションを捌くということは、バリデータAとバリデータBが同時に新しいブロックを提案する可能性もある。この時他のバリデータはブロックA、ブロックBの両ブランチに投票することで利得が最大化されるが、これはシステムのセキュリティを低下させる(Nothing at Stake問題)ため、これを防ぐのがTower BFTというサブプロトコルになっている。
分散システムでは、ノード数を増やすと、すべてのノードにすべてのデータを伝搬するのに必要な時間が長くなることがあります。Turbineはこの問題を解決することを目的としたブロック伝搬プロトコルです。あるノードが非常に大きなメッセージを1,000人のピアに伝搬する場合、1,000回伝搬するのではなく、メッセージを小さなパケットに分割して、それぞれのパケットを異なるノードに送信します。
各バリデーターはネイバーと呼ばれるピアのグループにパケットを順番に再送します。各ネイバーは、データの一部を隣接する各ネイバーに送信する責任があり、仮に各ネイバーが200ノードで構成されている場合、ルートに1人のリーダーがいる3レベルのネットワークでは、2ホップで40,000人のバリデータをカバーすることができます。
またデータを再ブロードキャストしないことを選択する可能性のある敵対ノードを処理するために、つまり障害に対して耐性を持たせるためにバリデーターはReed-Solomon Erasure コードを使用してデータを符号化し、ある程度の障害耐性を提供することが可能になります。
Tower-BFTは、ソラナのPoH（Proof of History）上で実行しています。これはPoHに最適化されたPBFTに類似したコンセンサスアルゴリズムであり、通信のオーバーヘッドとレイテンシーを削減します。
ネットワーク上のノードが特定のフォークに投票するたびに、投票はスロットと呼ばれる一定期間のハッシュに制限されます。現在のネットワークの設定では、1つのスロットに約400ミリ秒の時間が設定されています。400ミリ秒ごとにネットワークはロールバックポイントを持っていますが、それ以降の投票を行うたびに、その投票をアンロールするまでにネットワークが停止しなければならない時間が2倍になります。
例えば、各バリデータは過去12秒の間に32回投票しています。12秒前の投票では、タイムアウト時間は2³²スロット、つまり約54年ですので実質的に、この投票はネットワークによってロールバックされることはありません。一方、直近の投票は2スロット、約800msのタイムアウトとなります。新しいブロックが台帳に追加されると、古いブロックはますます確定される可能性が高くなります。なぜなら、古い投票がコミットされているスロットの数がスロットごとに、または400msごとに倍増するからです。
ソラナのメインネットは、Delegated-Proof-of-Stake （DPoS）で運営される予定で、トークン保有者はブロックの生産プロセスに参加して報酬を得ることができ、トークンをステークして自らバリデータになるか、信頼するバリデータにトークンを委任することができます。
CPU
12 cores / 24 threads, or more
2.8GHz, or faster
AVX2 instruction support (to use official release binaries, self-compile otherwise)
Support for AVX512f and/or SHA-NI instructions is helpful
The AMD Zen3 series is popular with the validator community
RAM
128GB, or more
Motherboard with 256GB capacity suggested
Disk
PCIe Gen3 x4 NVME SSD, or better
Accounts: 500GB, or larger. High TBW (Total Bytes Written)
Ledger: 1TB or larger. High TBW suggested
OS: (Optional) 500GB, or larger. SATA OK
The OS may be installed on the ledger disk, though testing has shown better performance with the ledger on its own disk
Accounts and ledger can be stored on the same disk, however due to high IOPS, this is not recommended
The Samsung 970 and 980 Pro series SSDs are popular with the validator community
GPUs
Not strictly necessary at this time
Motherboard and power supply speced to add one or more high-end GPUs in the future suggested
The hardware recommendations above should be considered bare minimums if the validator is intended to be employed as an RPC node. To provide full functionality and improved reliability, the following adjustments should be made.
CPU
16 cores / 32 threads, or more
RAM
256 GB, or more
Disk
Consider a larger ledger disk if longer transaction history is required
Accounts and ledger should not be stored on the same disk
他のブロックチェーンの合意形成でよく見られる、メモリプールに未承認のトランザクションをプールし、トランザクションに優先度をつけるといったことをSolanaでは行いません。まずプーリングをするとトランザクションがプール上にたまり渋滞を起こします。バリデータが自分の利益のためにGas代の高いものから順にトランザクションを承認しようとするGas Auctionが始まってしまいます。そうすると、トランザクションを優先して通したいClient側はさらにGas代を上乗せするといった悪循環からGas代の高騰などが起きてしまいます。
これを解決するためにSolanaではプールを行わず優先度を恣意的に決められるような設計は採用しておらず、トランザクションがプールされることもないことも処理速度の高速化につながっていると考えられます。
https://docs.solana.com/introduction
https://github.com/solana-labs/whitepaper/blob/master/solana-whitepaper-en.pdf
https://coinchoice.net/8-innovation-of-solnaa-towerbft-turibne_202006/
No activity yet