高橋  花子

高橋 花子

1648908000

HyperledgerSawtoothの穏やかな紹介

Hyperledger Sawtoothは、Hyperledger傘下のオープンソースプロジェクトです。これは、分散型台帳アプリケーションとネットワークの作成と運用に使用されるエンタープライズレベルのブロックチェーンシステムとして機能し、特に企業で使用されます。

Hyperledger Sawtoothは、コアシステムの基本的な設計を知らなくても、カスタマイズされたスマートコントラクトとロジックを実行できる、エンタープライズのサービスとしてのブロックチェーンプラットフォームと呼ばれています。また、実用的なビザンチンフォールトトレランス(PBFT)や経過時間の証明(PoET)など、さまざまなコンセンサスアルゴリズムをサポートしているため、ユーザーは特定の要件に応じて最適な方法でブロックチェーンのパフォーマンスを作成できます。

Hyperledgerは、Linux Project、IBM、Intel、SAPなどの組織が後援する開発グループです。

のこぎり歯の特異点

鋸歯状のコンセンサスアルゴリズム

ブロックチェーンアーキテクチャの堅牢性の中心にあり、最も一般的な方法では、パブリック元帳にコンセンサスアルゴリズムがあります。最も伝統的なものは、ビザンチンフォールトトレラント(BFT)コンセンサスの限界を克服するために設計された坂本コンセンサスアルゴリズム[2]です。Hyperledger Sawtoothは、PoET、PBFT、およびRaftの3つの異なるコンセンサスメカニズムを提供します。

のこぎりの詩人

Sawtooth Proof of Elapsed Time(PoET)は、大規模なネットワーク人口をサポートするように設計されたナカモトスタイルのコンセンサス[2]アルゴリズムです。PoETは、「公正な宝くじ」メカニズムに依存して、次のブロックを追加するノードを選択します。各ノードは、ノードがスリープする必要があるランダムな待機時間を生成します。待ち時間が最も短いノードが最初にウェイクアップして宝くじに当選するため、新しいブロックをブロックチェーンにコミットすることができます。もちろん、ノードがブロックを配置しようとしてエネルギーを浪費しないため、PoETの方がエネルギー効率が高くなります。

のこぎり歯PBFT

Sawtooth Practical Byzantine Fault Tolerance(PBFT)(元のPBFT [3]に対する修正バージョン)は、ビザンチンフォールトトレランスを提供する投票ベースのコンセンサスアルゴリズムです。ノードがセットに追加されると、メッセージ数が指数関数的に増加するという欠点があります。

リーダーノードが追加する新しいブロックを提案すると、ノード間で交換される一連のメッセージが開始されます。このアルゴリズムは、実装に依存する悪意のあるノードの割合に対して証明可能な耐性を提供します。

のこぎりいかだ

Raftは、クラッシュフォールトトレランス(CFT)を提供するリーダーベースのコンセンサスアルゴリズムです。システムの要は、常に正直に行動すると想定されるリーダーです。リーダーによって追加されたブロックは偽造されておらず、その更新は信頼できます。

リーダーには、リーダーからの更新を単純に伝播するノードのコホートがあり、特定のタイムアウト後にリーダーにクラッシュが発生した場合、フォロワーの中から新しいリーダーが選出されます。

このアルゴリズムは、CFTに対して自然な回復力を持っています。たとえば、6つのノードのネットワークでは、新しいリーダーを選出するためのクォーラムは4つです(使用可能な6つのノードの半分以上)。

 

Raftには、ノード間にブロックを追加する競合がなく、CPU時間を浪費するため、PBFTやPoETよりも効率的であるという利点があります(エネルギーの観点からも)。リーダーが稼働している限り、更新は単純に伝播されます。

開発モードのコンセンサス

Sawtoothが提供するdevmodeコンセンサスアルゴリズムについて簡単に説明し、開発者がコンセンサスアルゴリズムを最初から作成する方法を理解できるようにします。

開発モードは、ご存知のとおり、開発モードでのみ使用されるコンセンサスアルゴリズムです。クラッシュ耐性がなく、単純な単純化されたランダムリーダーの選択を使用します。

討論

上記のアルゴリズムは、いくつかの理由で従来のPoWコンセンサスとは異なります。

  • Sawtoothは、Proof of Work(PoW)やProof of Elapsed Time(PoET)などの宝くじスタイルのコンセンサスアルゴリズムとは異なり、ノードによってコミットされたブロック間のコラボレーションが最終的なシナリオ向けに設計されています。
  • pBFTは通常、スケーリングしないアルゴリズムと考えられています。この認識は通常、ノード==サーバーの概念によってもたらされます。これは、エンタープライズ実稼働環境に展開された場合のpBFTの場合には当てはまりません。
  • pBFTは、各組織がネットワークノード==組織上のノードを表すエンタープライズ組織のコンソーシアムで使用する必要があります。これらの各組織ノードには、ノードのエンドポイントの背後にインスタンスとロードバランサーのクラスターがあり、計算能力をスケーリングして迅速な応答時間を確保する必要があります。

サンプルアプリケーション:単一ノードのSawtoothインストールをデプロイします

この段落では、簡単にするために、デモに必要な基本コンポーネントのみを含む非常に単純なDockerファイルから開始して、単一ノードのSawtoothインストールをデプロイすることから始めます。

特に、バリデーター、REST API、開発モードコンセンサスエンジン、および3つのトランザクションプロセッサを実行する単一のバリデーター設定をデプロイします。環境は、開発モードのコンセンサスと並列トランザクション処理を使用します。

 

これがより強力な設定とどのように異なるかをよりよく理解するために、4つのバリデーターノード設定と比較してみましょう。

 

より現実的な設定に関するもう1つの単純化は、上記のdevモードコンセンサスアルゴリズムを使用することです。システムが機能したら、これをより賢明なコンセンサスアルゴリズムに変更する方法を説明します。

リポジトリとセットアップ

便宜上、GitHubにリポジトリを用意しています。https://github.com/rosdec/singleから選択したディレクトリにクローンを作成するだけです。推奨される設定は選択したLinuxでの設定ですが、さらにハンマーを使用すると、WindowsまたはMacOSで簡単に機能することに注意してください。

一部のライブラリはノードのバージョンにこだわりがあるため、ノード12を使用してください。依存関係をインストールすると、すべてを実行できるようになります(詳細な手順は、リポジトリのREADMEにあります)。

サンプルアプリケーションの出力は非常に単純で、その背後にあるロジック全体は派手ではありません。ペイロード(文字列)をブロックチェーンの特定のアドレスに格納し、それを取得してすべてが期待どおりに機能することを確認します。

 

コードを詳しく調べると、内部で何が起こっているのかを理解するのに役立ち、Sawtoothの背後にあるアイデアを理解することもできます。

ソースコード検査

サンプルアプリケーションのコアは、プロセッサ(ファイルプロセッサ/processor.js)とインタラクション(ファイルinteract.js)の2つの部分に分けることができます。

プロセッサは、Hyperledger Sawtoothの可能性を最大限に発揮するサンプルトランザクションプロセッサです。トランザクションとは何か、およびトランザクションがブロックチェーンストレージとどのように相互作用するかを定義できます。

これは、トランザクションがストレージと対話する固定された方法を持ち、主に2つ以上のアカウント間でイーサリアムまたはビットコインを移動する従来のブロックチェーン(もちろん、イーサリアムやビットコインなど)と比較して大きな飛躍です。

Sawtoothでは、任意の言語で独自のプロセッサを作成できます。サンプルアプリケーションでは、プロセッサはトランザクションペイロード(文字列)を特定のアドレスに格納するだけです(42行目)。ただし、スマートコントラクトなどの代わりに、トランザクションレベルでより多くのロジックを配置することで、より複雑なインタラクションを設計できます。

 

これは、Sawtoothを使用することの大きな利点です。これは、ブロックチェーンの独自のフレーバーを作成するためのフレームワークであり、ロジックをトランザクションで直接プッシュできますが、必ずしもスマートコントラクトではプッシュできません。この柔軟性の例として、三目並べゲームを処理するトランザクションプロセッサが記述されているこのリポジトリを確認できます。

ブロックチェーンとの対話には2つのメソッドとがwrite_dataありread_data、どちらもREST APIを介して操作することでブロックチェーンと対話します(上の図のブロックを参照)。ブロックチェーンからの読み取りは非常に簡単です。これは、読み取るアドレスを使用したAPI/stateの呼び出しにすぎません。

 

一方、ブロックチェーンへの書き込みは、特定の一連のステップで構成されます。あなたはinteract.jsファイルでそれらに従うことができます:

  1. 最初に、トランザクションヘッダーが作成されます。これは、最も重要なこととして、トランザクションファミリーを含みます。つまり、トランザクションを処理するために呼び出されるトランザクションプロセッサです(48〜58行目)。次に、トランザクションは、それを送信しているサブジェクトの秘密鍵を使用して署名されます(61〜66行目)。
  2. トランザクションはバッチ内で収集され、バッチはさまざまなサブジェクトからのトランザクションを収集でき、それ自体が署名されます(69〜81行目)。
  3. 署名されたトランザクションのバッチの準備ができたら、API呼び出しで安全に使用できるように(行89〜93)、​​エンコードされます(行84〜86)。

コンセンサスアルゴリズムの変更

ソースコードを調べた後、Dockerで作成された。という名前のファイルを見てみましょうsingle-node.yaml。上記の5つのコンポーネントが正確に含まれています。

  1. ロジックがprocessor.jsファイルに記述されているトランザクションプロセッサ。
  2. バインドするポートを指定するだけのSawtoothRESTAPI。
  3. ブロックチェーンに保持されている設定との対話を可能にする必須の設定トランザクションプロセッサ。
  4. バリデーターは、バリデーターノードの構成を記述します。ご想像のとおり、ここでコンセンサスアルゴリズムが指定されます(48行目)。このバージョンでは、開発モードアルゴリズムを使用するように指定されています。
  5. devmodeエンジンには、この特定のアルゴリズムの(いくつかの)構成が含まれています

コンセンサスアルゴリズムの変更は非常に簡単です。使用するアルゴリズムを選択して、バリデーターノードの構成を変更するだけです。わかりやすくするために、単一ノードで快適に動作する開発モードエンジンを使用しました。より複雑なアルゴリズムには少なくとも4つのノードが必要であり、一貫して、docker-composeファイルはより複雑です。

例として、コンセンサスアルゴリズムとしてpBFTを使用するための構成を含むGitHub(138行目)と、このシナリオで使用するためにそのようなアルゴリズムがどのように設定されているか(300〜304行目)を確認します。pBFTが機能するには少なくとも4つのノードが必要です(リーダーの選出のため)。したがって、4つのバリデーターノードと、同様に、各バリデーターに1つずつ4つのpBFTエンジンがあります。

結論

Hyperledger Sawtoothは、さまざまなブロックチェーン構成に対応できるため、トランザクションの方法と手段をカスタマイズできます。ブロックチェーンが実際に動作する方法の中心となるコンセンサスアルゴリズムは構成可能であり、ブロックチェーンのパフォーマンスとビザンチン攻撃への耐性を慎重に選択するために、すぐに使用できる一連のオプションを利用できます。

ソース:https ://blog.logrocket.com/hyperledger-sawtooth-introduction/ 

#hyperledger #sawtooth 

What is GEEK

Buddha Community

HyperledgerSawtoothの穏やかな紹介
高橋  花子

高橋 花子

1648908000

HyperledgerSawtoothの穏やかな紹介

Hyperledger Sawtoothは、Hyperledger傘下のオープンソースプロジェクトです。これは、分散型台帳アプリケーションとネットワークの作成と運用に使用されるエンタープライズレベルのブロックチェーンシステムとして機能し、特に企業で使用されます。

Hyperledger Sawtoothは、コアシステムの基本的な設計を知らなくても、カスタマイズされたスマートコントラクトとロジックを実行できる、エンタープライズのサービスとしてのブロックチェーンプラットフォームと呼ばれています。また、実用的なビザンチンフォールトトレランス(PBFT)や経過時間の証明(PoET)など、さまざまなコンセンサスアルゴリズムをサポートしているため、ユーザーは特定の要件に応じて最適な方法でブロックチェーンのパフォーマンスを作成できます。

Hyperledgerは、Linux Project、IBM、Intel、SAPなどの組織が後援する開発グループです。

のこぎり歯の特異点

鋸歯状のコンセンサスアルゴリズム

ブロックチェーンアーキテクチャの堅牢性の中心にあり、最も一般的な方法では、パブリック元帳にコンセンサスアルゴリズムがあります。最も伝統的なものは、ビザンチンフォールトトレラント(BFT)コンセンサスの限界を克服するために設計された坂本コンセンサスアルゴリズム[2]です。Hyperledger Sawtoothは、PoET、PBFT、およびRaftの3つの異なるコンセンサスメカニズムを提供します。

のこぎりの詩人

Sawtooth Proof of Elapsed Time(PoET)は、大規模なネットワーク人口をサポートするように設計されたナカモトスタイルのコンセンサス[2]アルゴリズムです。PoETは、「公正な宝くじ」メカニズムに依存して、次のブロックを追加するノードを選択します。各ノードは、ノードがスリープする必要があるランダムな待機時間を生成します。待ち時間が最も短いノードが最初にウェイクアップして宝くじに当選するため、新しいブロックをブロックチェーンにコミットすることができます。もちろん、ノードがブロックを配置しようとしてエネルギーを浪費しないため、PoETの方がエネルギー効率が高くなります。

のこぎり歯PBFT

Sawtooth Practical Byzantine Fault Tolerance(PBFT)(元のPBFT [3]に対する修正バージョン)は、ビザンチンフォールトトレランスを提供する投票ベースのコンセンサスアルゴリズムです。ノードがセットに追加されると、メッセージ数が指数関数的に増加するという欠点があります。

リーダーノードが追加する新しいブロックを提案すると、ノード間で交換される一連のメッセージが開始されます。このアルゴリズムは、実装に依存する悪意のあるノードの割合に対して証明可能な耐性を提供します。

のこぎりいかだ

Raftは、クラッシュフォールトトレランス(CFT)を提供するリーダーベースのコンセンサスアルゴリズムです。システムの要は、常に正直に行動すると想定されるリーダーです。リーダーによって追加されたブロックは偽造されておらず、その更新は信頼できます。

リーダーには、リーダーからの更新を単純に伝播するノードのコホートがあり、特定のタイムアウト後にリーダーにクラッシュが発生した場合、フォロワーの中から新しいリーダーが選出されます。

このアルゴリズムは、CFTに対して自然な回復力を持っています。たとえば、6つのノードのネットワークでは、新しいリーダーを選出するためのクォーラムは4つです(使用可能な6つのノードの半分以上)。

 

Raftには、ノード間にブロックを追加する競合がなく、CPU時間を浪費するため、PBFTやPoETよりも効率的であるという利点があります(エネルギーの観点からも)。リーダーが稼働している限り、更新は単純に伝播されます。

開発モードのコンセンサス

Sawtoothが提供するdevmodeコンセンサスアルゴリズムについて簡単に説明し、開発者がコンセンサスアルゴリズムを最初から作成する方法を理解できるようにします。

開発モードは、ご存知のとおり、開発モードでのみ使用されるコンセンサスアルゴリズムです。クラッシュ耐性がなく、単純な単純化されたランダムリーダーの選択を使用します。

討論

上記のアルゴリズムは、いくつかの理由で従来のPoWコンセンサスとは異なります。

  • Sawtoothは、Proof of Work(PoW)やProof of Elapsed Time(PoET)などの宝くじスタイルのコンセンサスアルゴリズムとは異なり、ノードによってコミットされたブロック間のコラボレーションが最終的なシナリオ向けに設計されています。
  • pBFTは通常、スケーリングしないアルゴリズムと考えられています。この認識は通常、ノード==サーバーの概念によってもたらされます。これは、エンタープライズ実稼働環境に展開された場合のpBFTの場合には当てはまりません。
  • pBFTは、各組織がネットワークノード==組織上のノードを表すエンタープライズ組織のコンソーシアムで使用する必要があります。これらの各組織ノードには、ノードのエンドポイントの背後にインスタンスとロードバランサーのクラスターがあり、計算能力をスケーリングして迅速な応答時間を確保する必要があります。

サンプルアプリケーション:単一ノードのSawtoothインストールをデプロイします

この段落では、簡単にするために、デモに必要な基本コンポーネントのみを含む非常に単純なDockerファイルから開始して、単一ノードのSawtoothインストールをデプロイすることから始めます。

特に、バリデーター、REST API、開発モードコンセンサスエンジン、および3つのトランザクションプロセッサを実行する単一のバリデーター設定をデプロイします。環境は、開発モードのコンセンサスと並列トランザクション処理を使用します。

 

これがより強力な設定とどのように異なるかをよりよく理解するために、4つのバリデーターノード設定と比較してみましょう。

 

より現実的な設定に関するもう1つの単純化は、上記のdevモードコンセンサスアルゴリズムを使用することです。システムが機能したら、これをより賢明なコンセンサスアルゴリズムに変更する方法を説明します。

リポジトリとセットアップ

便宜上、GitHubにリポジトリを用意しています。https://github.com/rosdec/singleから選択したディレクトリにクローンを作成するだけです。推奨される設定は選択したLinuxでの設定ですが、さらにハンマーを使用すると、WindowsまたはMacOSで簡単に機能することに注意してください。

一部のライブラリはノードのバージョンにこだわりがあるため、ノード12を使用してください。依存関係をインストールすると、すべてを実行できるようになります(詳細な手順は、リポジトリのREADMEにあります)。

サンプルアプリケーションの出力は非常に単純で、その背後にあるロジック全体は派手ではありません。ペイロード(文字列)をブロックチェーンの特定のアドレスに格納し、それを取得してすべてが期待どおりに機能することを確認します。

 

コードを詳しく調べると、内部で何が起こっているのかを理解するのに役立ち、Sawtoothの背後にあるアイデアを理解することもできます。

ソースコード検査

サンプルアプリケーションのコアは、プロセッサ(ファイルプロセッサ/processor.js)とインタラクション(ファイルinteract.js)の2つの部分に分けることができます。

プロセッサは、Hyperledger Sawtoothの可能性を最大限に発揮するサンプルトランザクションプロセッサです。トランザクションとは何か、およびトランザクションがブロックチェーンストレージとどのように相互作用するかを定義できます。

これは、トランザクションがストレージと対話する固定された方法を持ち、主に2つ以上のアカウント間でイーサリアムまたはビットコインを移動する従来のブロックチェーン(もちろん、イーサリアムやビットコインなど)と比較して大きな飛躍です。

Sawtoothでは、任意の言語で独自のプロセッサを作成できます。サンプルアプリケーションでは、プロセッサはトランザクションペイロード(文字列)を特定のアドレスに格納するだけです(42行目)。ただし、スマートコントラクトなどの代わりに、トランザクションレベルでより多くのロジックを配置することで、より複雑なインタラクションを設計できます。

 

これは、Sawtoothを使用することの大きな利点です。これは、ブロックチェーンの独自のフレーバーを作成するためのフレームワークであり、ロジックをトランザクションで直接プッシュできますが、必ずしもスマートコントラクトではプッシュできません。この柔軟性の例として、三目並べゲームを処理するトランザクションプロセッサが記述されているこのリポジトリを確認できます。

ブロックチェーンとの対話には2つのメソッドとがwrite_dataありread_data、どちらもREST APIを介して操作することでブロックチェーンと対話します(上の図のブロックを参照)。ブロックチェーンからの読み取りは非常に簡単です。これは、読み取るアドレスを使用したAPI/stateの呼び出しにすぎません。

 

一方、ブロックチェーンへの書き込みは、特定の一連のステップで構成されます。あなたはinteract.jsファイルでそれらに従うことができます:

  1. 最初に、トランザクションヘッダーが作成されます。これは、最も重要なこととして、トランザクションファミリーを含みます。つまり、トランザクションを処理するために呼び出されるトランザクションプロセッサです(48〜58行目)。次に、トランザクションは、それを送信しているサブジェクトの秘密鍵を使用して署名されます(61〜66行目)。
  2. トランザクションはバッチ内で収集され、バッチはさまざまなサブジェクトからのトランザクションを収集でき、それ自体が署名されます(69〜81行目)。
  3. 署名されたトランザクションのバッチの準備ができたら、API呼び出しで安全に使用できるように(行89〜93)、​​エンコードされます(行84〜86)。

コンセンサスアルゴリズムの変更

ソースコードを調べた後、Dockerで作成された。という名前のファイルを見てみましょうsingle-node.yaml。上記の5つのコンポーネントが正確に含まれています。

  1. ロジックがprocessor.jsファイルに記述されているトランザクションプロセッサ。
  2. バインドするポートを指定するだけのSawtoothRESTAPI。
  3. ブロックチェーンに保持されている設定との対話を可能にする必須の設定トランザクションプロセッサ。
  4. バリデーターは、バリデーターノードの構成を記述します。ご想像のとおり、ここでコンセンサスアルゴリズムが指定されます(48行目)。このバージョンでは、開発モードアルゴリズムを使用するように指定されています。
  5. devmodeエンジンには、この特定のアルゴリズムの(いくつかの)構成が含まれています

コンセンサスアルゴリズムの変更は非常に簡単です。使用するアルゴリズムを選択して、バリデーターノードの構成を変更するだけです。わかりやすくするために、単一ノードで快適に動作する開発モードエンジンを使用しました。より複雑なアルゴリズムには少なくとも4つのノードが必要であり、一貫して、docker-composeファイルはより複雑です。

例として、コンセンサスアルゴリズムとしてpBFTを使用するための構成を含むGitHub(138行目)と、このシナリオで使用するためにそのようなアルゴリズムがどのように設定されているか(300〜304行目)を確認します。pBFTが機能するには少なくとも4つのノードが必要です(リーダーの選出のため)。したがって、4つのバリデーターノードと、同様に、各バリデーターに1つずつ4つのpBFTエンジンがあります。

結論

Hyperledger Sawtoothは、さまざまなブロックチェーン構成に対応できるため、トランザクションの方法と手段をカスタマイズできます。ブロックチェーンが実際に動作する方法の中心となるコンセンサスアルゴリズムは構成可能であり、ブロックチェーンのパフォーマンスとビザンチン攻撃への耐性を慎重に選択するために、すぐに使用できる一連のオプションを利用できます。

ソース:https ://blog.logrocket.com/hyperledger-sawtooth-introduction/ 

#hyperledger #sawtooth