Min Wu: ブロックチェーンをブロックグラフに拡張する
Soteria
2020-03-17 13:51
本文约6726字,阅读全文需要约27分钟
Soteria は、BlockDAG ベースのスケーラブルなスループットやチェーン データ ストレージなど、同社が想定する分散型経済に適切な機能セットを提供しながら、パフォーマンスのボトルネック

クレア:8月8日に「DAGの過去と現在(1)」というテーマ共有を行ったところ、多くの友人から熱い注目と議論が寄せられ、同様に多くの人が【マジックパイパーコミュニティ】にも参加してくれました。本日は、ゲストスピーカーのウー・ミン氏が「DAGの過去と現在(2)」のテーマ共有を継続し、BlockDAGの技術的詳細、困難さ、解決策、ツールについてさらに説明し、誰もがBlockDAGについてより深く理解できるようにします。 、ようこそ。さらに深く掘り下げるために、後ほど Q&A セクションで質問することができます。さてウーミンさん…👏👏👏

min : 皆さんこんにちは、私は Min Wu です。今日のトピック共有は、ブロックチェーンからブロック グラフに拡張する方法を説明することです。 Github のリンクは次のとおりです: https://github.com/soteria-dag/soterd

今日の共有は主に開発者を対象としており、多くのプログラマーはスラング (俗語) しか知りません。皆様に有益となるよう、分かりやすくお伝えすることを心がけています。

郭明氏は前号で「DAG の過去と現在 (1)」について話しました。リンクはここにあります。 https://news.huoxing24.com/20190812204900103888.html 、簡単に見てみましょう。

1: Soteria は、「Self Sustainable Decentralized Economy」(SSDE - Self Sustainable Decentralized Economy) のインフラ技術です。

2: Soteria は、ブロックチェーンベースのスケーラブルなスループットなど、同社が想定する分散型経済に適切な機能セットを提供しながら、現世代のブロックチェーンの差し迫った問題のいくつかを解決するための総合的なソリューションを開発しています。

3: DAG は有向非巡回グラフと呼ばれます。

4: BlockDAG はブロック グラフと呼ばれます。 BlockDAG と TransactionDAG には大きな違いがあります。詳しくは、前回の共有のトランザクション DAG に関する部分を参照してください。

5: Soteria DAG は実際にはビットコイン ナカモト コンセンサス アルゴリズムを拡張したもので、包括的であり、セキュリティの確保に基づいて柔軟でスケーラブルな機能を提供します。

ブロック図は次のようになります。

この例では。一番下には GENESIS ブロックがあり、矢印はブロックからその親を指しています。ブロックが他のブロックの親ではない場合、そのブロックは現在のブロック グラフのチップと呼ばれます。たとえば、上の写真のチップは M、J、L です。ジェネシス、親、ヒントはすべて非常に重要な概念であり、次に繰り返し説明します。

包摂性を前提に、安全性をどう確保するか。たとえば、悪意のあるマイニングについてはどうでしょうか?ここではファントムと貪欲なファントムについて説明します。

ファントムとは何ですか?

Phantom は、Yonatan Sompolinsky と Aviv Zohar によって発明された染色/選別プロトコルです。その実装は、次の 3 つの主要な手順で行われます。

1: 適切に接続されたブロックのセットが識別されます。これを青セットと呼びます。古いブロックのみを参照しているブロックや、一定期間非表示になっているブロックなど、他のブロックは、高い確率で青色のセットから除外されます。

2: ブロックダイアグラム上でトポロジカルソートを実行し、青いセット内のブロックを優先し、青いセットにないブロックよりも遅れます。

3: 取引の分類とチェックの際には、ブロック図の分類が使用され、合法的な取引が採用され、悪質な取引は破棄されます。

このグラフィックの色が Phantom または Greedy Phantom でどのように見えるかを見てみましょう。

上の写真はPhantomで着色した結果です(Greedy Phantomも同様です)。ブロックMの観点から着色方法を見ていきます。ブロック図の中央部分には、適切に接続された一連のブロックがありますが、同時に、ブロック図の境界にあるいくつかのブロック (赤色) はあまり適切に接続されていません。

この決定にはシステム内部定数 (k) を使用しますが、k の選択方法については今後の技術共有で説明します。これは、同じレベルの赤のブロックが青のブロックの後ろに配置されることを意味しますが、すべての赤のブロックがすべての青のブロックの後ろに配置されるわけではないことに注意してください。色のないブロック (J と L) は M の「過去セット」に属さず、M の後ろにソートされます。

ソート結果 (M の観点から) は次のとおりです。

GENESIS, C, D, E, H, B, I, K, F, M, J, L

染色と選別のプロセス中に、Phantom は次のことを行う必要があります。

1: ブロックの過去と未来を分析して、うまく接続されているかどうかを判断します。

2: ブロック グラフを調べて、各ブロックに色を付けます。

3: 並べ替えます。

Aviv Yaish 著の Greedy Phantom とは何かを見てみましょう。

1: 基本的に Phantom と同じコンセプトですが、Greedy Phantom の目標は、よりシンプルかつ効果的であることです。

2: 着色部分は最も青い親から継承されます。

3: 色付けと並べ替えは増分モードです。

着色部分は、着色親とも呼ばれる最も青い親から継承されます。色付きの親のコレクションは、現在のブロックからジェネシス ブロック (ジェネシス) まで継続されます。ジェネシス ブロック (ジェネシス) は、現在のブロックのカラーリング チェーンとも呼ばれます。

Phantom との違いは、Greedy Phantom の色付けが引き継がれ、最も青い親よりも前のブロックの並べ替えが変更されていないことです。これに対し、Phantom アルゴリズムでは、各ブロックが過去 ( 過去 ) と未来 (将来)、そのため、ブロックが将来どのように接続されているかに完全に応じて、各ブロックの色が将来変わる可能性があります。

ブロックがブロック マップに追加されるにつれて、Greedy Phantom の色付けプロセスを見てみましょう。

GIF

このアニメーションでは、青、赤、透明のブロックに加えて、緑と破線の境界線のブロックがあります。

緑: 染色された先端を表します

点線: 現在のブロックの染色されたチェーン。 (最も青い親セット)

青: 青いブロックのコレクション。最新のブロックの視点を参照します (よく接続され、よく接続されています)。

赤: 最新のブロックから見て、青のブロックのセットの外側にあるブロック (あまりよく接続されていない)

最新のブロックから見ると、一部のブロックの色が (赤と青の間で) 変化していることがわかります。角度が異なると、染色されたストランドも異なることも観察できます。

DAG の開始時に、B、C、D、および E が追加されたとき、色付きのチェーンはこれらの新しいブロックになりませんでした。これは、2 つ以上のブロックが同じ青色の場合、より低いハッシュを持つブロックが勝つという内部タイブレーク ルールによるものです。この例では、B が最初 (最下位) の文字であるため、B が勝ちます。

Phantom と Greedy Phantom の計算の違い (エンジニアリングの実践に影響を与える) を要約すると、次のようになります。

ファントムはブロックの過去と未来を染色する際に使用し、ブロックグラフが成長するにつれてブロックの未来は無限に成長します。

Greedy Phantom は染色時にブロックの過去のみを考慮します。これは、ブロック グラフが成長し続けるため、Greedy Phantom が染色/選別エンジニアリングにとってより良い選択肢となるためです。

ファントムを使用する必要がある場合は、ノードの過去および将来の走査の下限と上限を設定することで、同様の効果を実現できます。

ただし、ノードの過去と未来を制限すると、色付け効果に影響を与える可能性があるため、理想的ではありません。

私たちのコード ベースには 2 つの実装が含まれています。その目的は、将来的にそれらの違いを比較し、他の開発者にさらなる参照を提供することです。

次に、ブロックチェーンをブロック図に拡張するという目的を達成するためにコードをどのように変更するかを詳しく説明します。

プロジェクトの開始前に、私たちは多くのオープンソース ブロックチェーン プロジェクトを調査し、最終的に上位層で反復するためのベースとして btcd を使用することにしました。新しいプロジェクト名は soterd です。 Github のリンクは次のとおりです: https://github.com/soteria-dag/soterd

プロジェクト実装ブロック図 (BlockDAG) には次の内容が含まれます。

既存のコードを整理し、ブロックチェーン シナリオのみを提供できるコードを削除し、BlockDAG の開発を複雑にしてあまり役に立たないコードを多数含めます。

ブロック図を表すコア モジュールを実装し (古いコードはブロックチェーンを表します)、次のようなブロックチェーン モジュールと同じまたは類似のサービス機能を提供します。

ヒントの機能を見つけてください。

既存のブロックに従って親ブロックを見つけます。

指定された範囲のブロック マップを取得します。

ブロック データ構造を更新しました (これはすべてのブロックチェーン プロジェクトで最も重要なデータ構造です😯)。

ブロック図では各ブロックが複数の親を持つことができる (ビットコインは 1 つだけを持つことができる) ため、領域を追加すると、より多くの親情報を保存できます。

プロトコル層のエンコードおよび解析方法(エンコード/デコード)を更新しました。

更新および追加されたテスト (テスト)

マイニング手順が更新されました。ブロックチェーン/ブロックグラフを横断できる他の場所もあります。

新しい P2P 呼び出しと RPC 呼び出しを追加しました

getdagtips rpc call 

renderdag rpc call 

addrcache p2p call 

ネットワーク同期セクションのコードを更新しました。

システム統合テストを追加しました。

ブロック グラフ (元はブロックチェーン) を生成し、各ブロックが複数の親ブロックを持つことができることを確認します。

ブロック グラフが異なるフル ノード間で同期できることを確認します。

マイニングしたSOTOが取引に利用できることを確認します。

(実際には、長ったらしい言葉がたくさんあります。プログラムを書かない人にとって、パブリック チェーン コードを変更するのは簡単な作業ではないことを覚えておいてください。プログラマーにとってはその方が良いです。:P… プログラマーの友人の皆さん、私たちの github を参照してください)詳しくはこちら)

上記の変更は、一度に変更する量が多すぎてリスクが高すぎるため、いくつかの異なる段階を経て行われました。また、ブロック図の理解と分析、トラブルシューティングに役立つ多くのツールも開発しました。ツールは後で共有されます。

皆さん、テキストの生放送を長い間見ていて、とても大変だったと思います。あなたの心の中にある大きな疑問の 1 つは、次のとおりです。"A picture is worth a thousand words"。おい、あなたの写真はどこにある? ? ?

画像は近日公開予定です。

はい、続けましょう...

直面した課題:

プロジェクトの開発プロセスでは、ブロック グラフをサポートするために多くのブロックチェーン コードを更新する必要があります。一般に、次の 3 つの異なる種類の課題があります。

ブロックチェーンの仮定。

既存のコードでは、システム設計が異なるため、多くの箇所でデフォルトでブロックチェーンが想定されています。

ピアツーピア (p2p) 同期。

プロトコル層でのエンコードと解析。

ブロックチェーンの前提条件:

コードの一部をリファクタリングする必要があります。たとえば、ブロックチェーンでは、ブロックの高さは、現在のブロックとジェネシス ブロックの間のブロックの数です。ブロック グラフでは、ブロックは複数の親ブロックを持つことができ、そのうちのいくつかは他のブロックよりも Genesis に直接接続されている可能性があります。したがって、ブロック グラフでは、ブロックの高さは親ブロックの最大高さ + 1 になります。




上図では、ブロック K の高さは、B のパスを通過する場合は 2、C、D、E を通過する場合は 3 になります。したがって、その高さは 3 であると考えられます。

孤立ブロックの処理:

Z-shaped dag 

オーファンブロックとはこのようなもので、フルノードが妥当なブロックを受け取ったものの、そのブロックの過去(過去)が見つからず、既存のブロックグラフに接続できない場合、そのブロックはブロックされ、オーファンブロックと呼ばれます。

ブロックチェーンでは、孤立したブロックは、孤立したブロックから始まり、その親の順に上から下に処理されます。ブロック グラフでは、このトラバーサル方法には問題があり、特にブロック グラフに Z-saped DAG がある場合、一部のブロックが無視されます。すべてのブロックを含めるために検索結果を深さ優先ソートして、このアルゴリズムを調整しました。

(この一節が非常に頭を悩ませているように思えることはわかっていますが、孤児はなんて可哀想なんだ、もちろん彼らは別の扱いを受けなければならない、とあなたは思うでしょう。)

孤立したブロックの処理における重複の問題 (ノット)

ブロック間の接続性が高いブロック グラフの部分では、各パスが存在するため、孤立ブロックの処理に時間がかかります。

接続は遡って行われます。このためにキャッシュを構築し、処理された孤立ブロックとその過去を記録しました。

(つまり、孤児を特別扱いしすぎると制度にも影響が出てくるということ)

道具:

以下にいくつかの開発ツールを紹介しますが、以下の目的で soterd のコードに色付け機能を追加しました。

1: ブロック図の実装や同期の問題を確認するのに役立ちます。ログ ファイル内のハッシュ値のセットだけを確認するよりも、ブロック図を直観的に確認できる方がはるかに便利です。

2: 上位層アプリケーション (ブラウザなど) にインターフェイスを提供します。

dagviz: 

Dagviz : https://github.com/soteria-dag/soterd/tree/master/cmd/dagvizDagviz はコマンドライン ツールです。

いくつかの完全なノード (はい、フルノード) を起動し、それらにブロックのマイニングと交換を行わせ、結果を段階的に記録し、(ブラウザー経由で) 再生できます。各ブロックはマイナーに応じて色付けされているため、各マイナーがネットワークに貢献していることが非常に直感的にわかります。 Dagviz を使用すると、Soterd ダイアグラムやブロック図を表示したり、マイニングの公平性に対するアルゴリズム変更の影響を測定したりできます。

min :

(dagviz ではコンピューター上で複数の完全なノードを実行できるため、CPU 要件は低くないことに注意してください)

dagparam  関連リンク dagparam https://github.com/soteria-dag/soterd/tree/master/cmd/dagparam Dagparam は、さまざまなピアツーピア ネットワーク パラメーターを探索するためのツールです。 targetTimespan や targetTimePerBlock など、およびこれらのパラメーターがブロック グラフの構成と伝播にどのように影響するか。

Dagparam は、さまざまなピアツーピア ネットワーク パラメーターを調査するためのツールです。 targetTimespan や targetTimePerBlock など、およびこれらのパラメーターがブロック グラフの構成と伝播にどのように影響するか。

たとえば、ブロック生成速度が 62.5 ブロック/秒、つまり 16 ミリ秒ごとに 1 ブロックを超えると、同期コードのパフォーマンスが不安定になります。




soterdash https://github.com/soteria-dag/soterdash Soterdash は、soterd ネットワーク内のブロック グラフとフル ノードを参照するための Web UI です。ブロック図の全体または一部を表示でき、各ブロックをクリックすると、ヘッダーやマークルルートなどの詳細情報が表示されます。開発中、特にトラブルシューティングの際に、Soterdash が非常に役に立ちました。

Soterdash は、soterd ネットワーク内のブロック グラフとフル ノードを参照するための Web UI です。ブロック図の全体または一部を表示でき、各ブロックをクリックすると、ヘッダーやマークルルートなどの詳細情報が表示されます。開発中、特にトラブルシューティングの際に、Soterdash が非常に役に立ちました。

最後の道具、最後が最高のものでなければなりません。

go repo sync  

私たちのコードベースの大部分は Go で書かれています。 Go では相対インポート パスが許可されていないため、フォーク/コピーされた異なるコードベース間でコードを共有するプロセスは非常に複雑になります。私たちの開発プロセスには複数のバージョンとさまざまな方向でのコード共有が含まれるため、異なるコードベース間の同期を支援するためにこのツールを独自に開発しました。変更部分を対象のコードライブラリに自動的に転送し、古いコードライブラリを参照していた箇所を新しいコードライブラリに置き換えるなど、必要な変更も同時に行います。

- 現在のプロジェクトとそれが依存する先行プロジェクトを処理します。

- 現在のプロジェクトとターゲット プロジェクトをステージング領域にコピーします。

- 現在のプロジェクトとターゲット プロジェクトを git アーカイブと同期します。

- git rm で対象プロジェクト内の不要なファイルを削除します。

- 参照ファイルとリンクを置き換えます。

- go のモジュール名を更新します。

- 必要な新しいファイルをターゲット プロジェクトに追加します。

-ローカルに提出する

- ターゲットの git ツリーにコミットします。

- このツールは現在プライベート リポジトリ (プライベート リポジトリ) にありますが、オンデマンドでオープン ソースを提供することもできます。このプロジェクトは、大多数の Go プログラマーにとって役立ちます。

(繰り返しますが、ブロックチェーン プログラマーだけでなく、すべての Go プログラマーが役に立ちます。もちろん、Go を使用しないブロックチェーン プログラマーもたくさんいます)

本日は共有にご参加いただきありがとうございます。テクノロジーは継続的な議論の過程で成長します。本日の共有はここまでです。以下は質疑応答です。ご質問ください。

以下はQ&Aのハイライトからの抜粋です。

seabook: 今日は @min@soteria が多くの内容を共有してくれましたが、あなたの経済モデルは何ですか?

min : ああ、それが次回の共有のトピックです。

SSDE (SELF SUSTAINABLE DECENTRALIZED ECONOMY)...You read my mind.

シーブック: 簡単に思い出させてください。

min : https://www.ssde.io/ 現在は英語ですが、共有コンテンツは中国語になります。また、UBI について語る 2 つのポッドキャストも特別に録画しました。

seabook: https://medium.com/bitcoin-is-alien-technology/https-medium-com-bitcoin-is-alien-technology-bitcoin-is-alien-technology-part-1-7c5c82faf552 

@min@soteria i enjoy reading your article.

Zhu Jiang²⁰¹⁹: シーブック、あなたが言及した経済モデルはマクロ モデルまたはミクロ モデルを指します。マクロ レベルでは、@min@soteria が言及したように、私たちの SSDE 提案は、報酬メカニズムなどのソテリア ダグ自体の生態に関するものです。インセンティブの設計など。これについては、後の技術共有で説明します。

seabook: incentive design

Zhu Jiang²⁰¹⁹: シーブック、SSDE、およびソテリアはUBIでも共産主義でもありません。彼らは依然として労働と仕事に応じた分配の精神を主張しています。これは、公平性、寛容性、セキュリティ、プライバシー、拡張性など、既存の集中型経済システムに対する分散型の機能強化にすぎません。インセンティブデザインさんはゲーム理論のファンでもありますよね?後で共有することに注意してください。

シーブック:注意してみます。

クレア: ご清聴ありがとうございました、そしてすべての放送プラットフォームに感謝します。後ほど引き続き Blockdag のテクノロジーについて詳しく議論していただいて結構です。これでこのトピックの共有は終わりです。 2 つの非常に核心的なトピックを共有した後、経済、金融、プライバシー保護、ビッグデータ分析、ブロックチェーン プロジェクトのビジネス モデルなど、私たちの生活に密接に関連する他のトピックを引き続き共有していきます。内容には関心がありますが、フォローアップのトピック共有には引き続き注意してください。 。 。ゲストスピーカーのウー・ミン氏、入念な準備と詳細な共有に改めて感謝します。

Soteria
作者文库