RWA銘柄へデラ(HBAR)について③くりぷと知っ得情報4月23日号
クリプトスタディ(クリスタ)の水野です。
シリーズで、RWA(Real World Assets:リアル ワールド アセット)の代表的銘柄、へデラ(HBAR)について書いています。
RWAは、株式・不動産・金・国債などの金融資産=｢現実世界の資産｣をブロックチェーン技術を使って、トークン化する技術・概念のことになります。
前回は、へデラ(HBAR)の大きな特徴の一つ、コンセンサスアルゴリズム｢Hashgraph(ハッシュグラフ)｣について書きましたが、今回もその続きを書いていきます。
🔶RWAが誕生した背景について
くりぷと知っ得情報2月26日号🔶RWAを支える技術＝オラクル(Oracle)について
くりぷと知っ得情報3月5日号🔶RWA銘柄へデラ(HBAR)=基本情報〜概要についてくりぷと知っ得情報4月9日号🔶へデラ(HBAR)のコンセンサスアルゴリズム｢Hashgraph(ハッシュグラフ)｣について〜前編
くりぷと知っ得情報4月16日号
へデラ(HBAR)のコンセンサスアルゴリズム｢Hashgraph(ハッシュグラフ)｣のコア技術の一つ、
Gossip about Gossip(ゴシップ・アバウト・ゴシップ)
について、前号で書きました。
要約すると、
Gossip about Gossip(ゴシップ・アバウト・ゴシップ)は、
イベント(取引や情報)＋｢誰が｣｢いつ｣｢誰の情報をもとに｣という履歴情報を
ノード同士でやり取りすることで、
この履歴が自動的にDAG(有向非巡回グラフ)を作る。
ということでした。
それらを踏まえ‥‥前号の続きです。
｢Hashgraph(ハッシュグラフ)｣のコア技術
早速、結論から。
｢Hashgraph(ハッシュグラフ)｣は、
Gossip about Gossip(ゴシップ・アバウト・ゴシップ)
という技術に加え、
Virtual Voting(バーチャル ボーティング)=仮想投票
さらに
aBFT(Asynchronous Byzantine Fault Tolerance:
アシンクロノス ビザンチン フォールト トレランス)=非同期ビザンチン耐性
という技術を取り入れ、めちゃ効率のいい合意形成の仕組み(コンセンサスアルゴリズム)を作っています。
ん〜、ちょっとなに言ってるかわからない。
Gossip about Gossipによって、履歴情報が時系列に整理される仕組みについては、わかった‥‥。
DAG(有向非巡回グラフ)についても、Kaspaの章で馴染みがあったので、なんとなくわかった‥‥。
けど‥‥
仮想投票って‥‥？？
非同期ビザンチン耐性って‥‥？？？？
よしっ！！
ひとつずつ、深掘りしましょう。
Virtual Voting(仮想投票)
Hashgraph/Virtual Votingから
Virtual Voting(バーチャルボーティング)=仮想投票について、具体例をもとに深掘りしていきましょう。
ー例ー
｢飲み代を誰が払ったかわからない。誰が払った？｣
ー登場人物ー
A、B、C、Dの４人(ノードの記録係)
シナリオ
4人で楽しく呑んで、最後に誰かが｢まとめてお会計｣したけど、覚えていない。
これ、よくあるやつです(笑)
ステップ１：Gossip about Gossip
翌日、ゴシップのやり取り(うわさ話)。４人で話をする。
A→B：｢Cが全部払ったって聞いたよ｣
B→D：｢Aがそう言ってた‥‥｣
D→C：｢BがCが払ったって言ってたよ｣
このやりとりの中身(内容)だけでなく、誰から誰へ、いつ話したかも全部記録してある。
💡これが｢Gossip about Gossip｣(うわさ話のうわさ話)｣
ステップ２：Virtual Voting(仮想投票)
あDはこのやりとりを見て、こう思います。
みんなCが払ったって言ってるし、
その情報が全員にちゃんと広まってるみたい。
たぶん、全員“Cが払った”って思ってるな‥‥
これが、｢仮想投票(Virtual Voting)｣。
実際には投票しないけど、“みんなの意見”を想像して、投票したのと同じ効果になるものです。
実際にはメッセージを送信しなくても、自分のDAG上の情報を見て｢他のノードがYESかNOか｣を判断できるのが、｢仮想投票(Virtual Voting)｣になります。
みんなでGossip(おしゃべり)してる中で、
｢〇〇さんがこの話を〇〇さんから聞いたのが早かった｣
｢〇〇さんがそれをさらに〇〇さんに伝えた｣
みたいな伝播の順番・履歴を見て、
｢あ、みんなこの話をこう思ってたんだな｣って、みんなが何に投票していたか、その“結果”が読み取れる感じ=｢投票が行われたはず｣というように、情報を“仮想的に再現”できるのが、｢仮想投票｣です。
💡メッセージのやり取りがないから、軽くて高速！
そして、｢Hashgraph(ハッシュグラフ)｣は、さらにaBFT(asynchronous Byzantine Fault Tolerance:非同期ビザンチン耐性)が一緒にスマートに機能します。
Asynchronous Byzantine Fault Tolerance(非同期ビザンチン耐性)
以前、くりぷと知っ得情報で、ビザンチン将軍問題(Byzantine fault tolerance)について書きましたが、
｢Hashgraph(ハッシュグラフ)｣においては、その非同期(Asynchronous)であることで真価を発揮するようです。
↓論文をのぞいてみましょう。↓
Hashgraph/Asynchronous Byzantine Fault Toleranceから
(翻訳)↓↓↓↓
｢ビザンチン将軍問題(BFT)｣は、敵都市への攻撃を調整しようとする4人のビザンチン将軍を例に挙げ、この問題を具体的に示しています。
これらの将軍とその軍隊はそれぞれ都市の異なる地域に駐留しており、互いに完全に分断されています。
そのため、直接的な連携による通信は不可能です。攻撃(あるいは撤退)を計画するには、使者を介して通信を行う必要があり、各将軍は自分の使者を他の将軍に送り、計画を共有します。
しかし、このアプローチには重大な欠陥があります。
共有されたメッセージの信頼性について疑問が生じます。
例えば、使者の誰かが捕らえられ、敵の使者と入れ替わり、その使者が意図的に虚偽の情報を提供した場合、どうなるでしょうか？将軍の1人(あるいは2人)が実は裏切り者で、危害を加える目的で使者を送り込んだ場合はどうなるでしょうか？使者の1人が裏切り者で、意図的に虚偽の情報を共有した場合はどうなるでしょうか？これらのビザンチン将軍たちが攻撃か撤退かの合意(あるいは完全な合意)を得ようとしている方法には、信頼の問題が内在していることがすぐに分かります。
解決策は、非同期ビザンチンフォールトトレランスを使用することです。
これは、一部のノード(将軍)が正常に動作していなくても分散システムが機能できるようにするシステムです。
これにより、ネットワークが公平に動作することが保証されます。
なぜ、aBFTが成立する？
整理しましょう。
｢ビザンチン将軍問題(BFT)｣は、｢嘘に強いけど、連絡がちゃんと取れないと合意できない｣(旬な情報が必要)
けど、
aBFT(非同期)は、｢嘘に強いし、ネット遅延とか、連絡が遅れてもいつかは合意できる｣。
💡BFTは｢タイミング命｣な仕組み
💡aBFTは｢タイミングバラバラでも合意できる賢いやつ｣
aBFTとVirtual Voting
へデラ(HBAR)の｢Hashgraph(ハッシュグラフ)｣は、Virtual Voting(バーチャルボーティング)を使うことで、aBFT(asynchronous Byzantine Fault Tolerance:非同期ビザンチン耐性)を実現しています。
それぞれの関係性をまとめるよ
１、Gossip about Gossip(ゴシップの履歴)
各ノードが誰から誰へ何を聞いたかの履歴を交換し、この履歴によって、全ノードが｢イベントの伝播経路(DAG)｣を同じように持ちます。
２、Virtual Voting(仮想投票)
履歴さえあれば、実際に｢投票｣しなくても、｢このノードがこの意見に賛成だった｣と仮想的に判断でき、無駄な通信がいらないので、スケーラブルで早く処理が可能になります。
その結果‥‥
３、aBFT(非同期ビザンチン耐性)が実現
投票しなくても投票したかのように合意が取れ、通信が遅延しても合意できます。(非同期）
当然、悪意ノードがいても、多数派の正直者がいればウソに騙されない、ビザンチン耐性を持っています。
分散型合意アルゴリズム｢ハッシュグラフ｣を発明したリーマン・ベアード(Leemon Baird)氏の動画です。
へデラ(HBAR)の｢Hashgraph(ハッシュグラフ)｣について、Virtual Voting(バーチャルボーティング)、についての動画です。
(⚠️音声が出ます。)
おわりに
従前のコンセンサスアルゴリズムと違い、ハイブリッドとも言える効率のいい合意方法である｢Hashgraph(ハッシュグラフ)｣は、とてもユニークな方法ですね。
今回はここまでです。
次回は、へデラ(HBAR)の優位性について、まとめたいと思います。
お読みいただきありがとうございました。