高橋  花子

高橋 花子

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 

HyperledgerSawtoothの穏やかな紹介

Una Suave introducción A Hyperledger Sawtooth

Hyperledger Sawtooth es un proyecto de código abierto bajo el paraguas de Hyperledger. Funciona como un sistema de cadena de bloques de nivel empresarial que se utiliza para crear y operar aplicaciones y redes de registros distribuidos, particularmente para uso de empresas.

Hyperledger Sawtooth se conoce como una plataforma empresarial de cadena de bloques como servicio que puede ejecutar contratos inteligentes personalizados y lógica sin necesidad de conocer el diseño subyacente del sistema central. También es compatible con una variedad de algoritmos de consenso, incluida la tolerancia práctica a fallas bizantinas (PBFT) y la prueba de tiempo transcurrido (PoET), lo que permite al usuario diseñar el rendimiento de la cadena de bloques de la manera más adecuada según los requisitos específicos.

Hyperledger es un grupo de desarrollo patrocinado por organizaciones como Linux Project, IBM, Intel y SAP.

Singularidades de diente de sierra

Algoritmos de consenso de diente de sierra

En el núcleo mismo de la solidez de la arquitectura de la cadena de bloques y, en general, de los libros de contabilidad públicos, se encuentra el algoritmo de consenso. El más tradicional es el Algoritmo de Consenso de Sakamoto [2] que fue diseñado para superar los límites del Consenso de Tolerancia a Fallos Bizantinos (BFT). Hyperledger Sawtooth proporciona tres mecanismos de consenso diferentes: PoET, PBFT y Raft.

PoET diente de sierra

Sawtooth Proof of Elapsed Time (PoET) es un algoritmo de consenso al estilo de Nakamoto [2] que está diseñado para admitir grandes poblaciones de redes. PoET se basa en un mecanismo de "lotería justa" para seleccionar qué nodo agregará el siguiente bloque: cada nodo genera un tiempo de espera aleatorio durante el cual los nodos deben dormir. El nodo con el tiempo de espera más corto se despertará primero y ganará la lotería, lo que le permitirá enviar un nuevo bloque a la cadena de bloques. Por supuesto, PoET es más eficiente energéticamente porque los nodos no desperdiciarán energía tratando de colocar bloques.

PBFT de diente de sierra

Sawtooth Practical Byzantine Fault Tolerance (PBFT) (versión modificada con respecto al PBFT original [3]) es un algoritmo de consenso basado en votación que proporciona tolerancia a fallas bizantinas. Viene con el inconveniente de un recuento de mensajes que aumenta exponencialmente a medida que se agregan nodos al conjunto.

Una vez que el nodo líder propone agregar un nuevo bloque, comienza una serie de mensajes intercambiados entre los nodos. El algoritmo proporciona una resistencia demostrable a un porcentaje de nodos maliciosos que depende de la implementación.

balsa de dientes de sierra

Raft es un algoritmo de consenso basado en líder que proporciona tolerancia a fallas de choque (CFT): la piedra angular del sistema es el líder que se supone que siempre actúa con honestidad. Los bloques agregados por el líder no han sido falsificados y sus actualizaciones son confiables.

El líder tiene una cohorte de nodos que simplemente propagarán las actualizaciones del líder y, en caso de que el líder se bloquee después de un tiempo de espera determinado, se elige un nuevo líder entre los seguidores.

Este algoritmo tiene una resistencia natural a CFT. Por ejemplo, en una red de seis nodos, el quórum para elegir un nuevo líder es de cuatro (uno más de la mitad de los seis nodos disponibles).

 

Raft tiene la ventaja de ser más eficiente (también desde el punto de vista energético) que PBFT y PoET porque no hay competencia para agregar bloques entre nodos, desperdiciando tiempo de CPU; las actualizaciones simplemente se propagan siempre que el líder esté en funcionamiento.

Consenso del modo de desarrollo

Describamos brevemente el algoritmo de consenso devmode que proporciona Sawtooth para que los desarrolladores entiendan cómo escribir un algoritmo de consenso desde cero.

El modo Dev es, como el más inteligente de ustedes ya entendió, un algoritmo de consenso que se usa solo en el modo de desarrollo: no tiene tolerancia a fallas y usa una selección de líder aleatorio simple y simplificada.

Discusión

Los algoritmos anteriores difieren del consenso PoW clásico por algunas razones:

  • Sawtooth está diseñado para un escenario en el que la colaboración entre los bloques comprometidos por los nodos es definitiva, a diferencia de los algoritmos de consenso de tipo lotería, como la Prueba de trabajo (PoW) o la Prueba de tiempo transcurrido (PoET)
  • pBFT se considera comúnmente como un algoritmo que no escala. Esta percepción generalmente es provocada por la noción de un nodo == servidor, lo que no debería ser el caso con pBFT cuando se implementa en un entorno de producción empresarial.
  • pBFT debe usarse con un consorcio de organizaciones empresariales, donde cada organización representaría un nodo en la red nodo == organización. Cada uno de estos nodos organizacionales debe tener grupos de instancias y balanceadores de carga detrás del punto final del nodo para escalar la potencia computacional y garantizar un tiempo de respuesta rápido.

Una aplicación de muestra: implementar una instalación Sawtooth de un solo nodo

En este párrafo, comenzaremos implementando una instalación de Sawtooth de un solo nodo a partir de un archivo Docker muy simple que, en aras de la simplicidad, contiene solo los componentes básicos necesarios para la demostración.

En particular, implementaremos una única configuración de validador que ejecuta un validador, una API REST, el motor de consenso del modo de desarrollo y tres procesadores de transacciones. El entorno utiliza el consenso del modo de desarrollo y el procesamiento de transacciones en paralelo.

 

Para comprender mejor cuán diferente es esto de una configuración más potente, comparémoslo con una configuración de cuatro nodos de validación:

 

Otra simplificación, con respecto a una configuración más realista, es que usaremos el algoritmo de consenso del modo desarrollador descrito anteriormente. Explicaré cómo cambiar esto a un algoritmo de consenso más sensato una vez que el sistema funcione.

El repositorio y la configuración

Hemos proporcionado un repositorio en GitHub para su comodidad: solo tiene que clonar desde https://github.com/rosdec/single en un directorio de su elección. Tenga en cuenta que la configuración sugerida está bajo un Linux de elección, pero con un poco más de martillazos, funcionará fácilmente bajo Windows o Mac OS.

Use Node 12 porque algunas de las bibliotecas son exigentes con la versión de Node. Instale las dependencias y todo estará listo para ejecutarse (las instrucciones adicionales y detalladas se encuentran en el LÉAME del repositorio).

La aplicación de muestra tiene una salida muy simple y toda la lógica detrás de ella no es elegante: simplemente almacenará la carga útil (una cadena) en una dirección específica de la cadena de bloques y la recuperará para verificar que todo funcione como se esperaba.

 

Una inspección más cercana del código ayudará a comprender lo que sucede debajo del capó y también nos permitirá captar la idea detrás de Sawtooth.

Inspección de código fuente

El núcleo de la aplicación de ejemplo se puede dividir en dos partes: el procesador (archivo procesador/procesador.js) y las interacciones (archivo interact.js).

El procesador es un procesador de transacciones de muestra que expresa todo el potencial de Hyperledger Sawtooth: puede definir qué es una transacción y cómo interactúa con el almacenamiento de la cadena de bloques.

Este es un gran salto con respecto a las cadenas de bloques tradicionales (por ejemplo, Ethereum y Bitcoin, por supuesto) donde las transacciones tienen una forma fija de interactuar con el almacenamiento, principalmente moviendo ethers o bitcoins entre dos o más cuentas.

En Sawtooth, puede escribir su propio procesador en cualquier idioma que prefiera. En la aplicación de muestra, nuestro procesador simplemente almacenará la carga útil de la transacción (una cadena) en una dirección específica (línea 42). Pero puede diseñar interacciones mucho más complejas, poniendo más lógica en el nivel de transacción en lugar de, por ejemplo, un contrato inteligente.

 

Esta es la gran ventaja de usar Sawtooth: es un marco para escribir su propio sabor de una cadena de bloques, donde la lógica se puede impulsar directamente en la transacción y no, necesariamente, en los contratos inteligentes. Como ejemplo de esta flexibilidad, puede consultar este repositorio donde se describe un procesador de transacciones que manejará un juego de tres en raya.

La interacción con la cadena de bloques tiene solo dos métodos, write_datay read_dataambos interactuarán con la cadena de bloques operando a través de la API REST (ver el bloque en el diagrama de arriba). La lectura de la cadena de bloques es bastante sencilla; es solo la invocación de la API /estado con la dirección desde la que leer.

 

Escribir en la cadena de bloques, por otro lado, consiste en una secuencia específica de pasos. Puedes seguirlos en el interact.jsarchivo:

  1. Primero, se crea el encabezado de la transacción que, lo más importante, contendrá la familia de transacciones. Es decir, el procesador de transacciones que se invocará para manejar nuestra transacción (líneas 48–58). En segundo lugar, la transacción se firma (líneas 61 a 66) utilizando la clave privada del sujeto que la envía;
  2. Las transacciones se recopilan dentro de un lote, un lote puede recopilar transacciones provenientes de diferentes sujetos y se firma en sí mismo (líneas 69 a 81);
  3. Una vez que el lote de transacciones firmado está listo, se codifica (líneas 84 a 86) para poder usarlo de forma segura en la invocación de la API (líneas 89 a 93).

Cambiar el algoritmo de consenso

Después de inspeccionar el código fuente, echemos un vistazo al archivo compuesto por Docker llamado single-node.yaml. Contiene exactamente los cinco componentes descritos anteriormente:

  1. El procesador de transacciones cuya lógica se describe en el processor.jsarchivo;
  2. La API REST de Sawtooth que solo especificará en qué puerto se vinculará;
  3. El procesador de transacciones de configuración obligatoria que permite interactuar con la configuración guardada en la cadena de bloques;
  4. El validador describe la configuración del nodo validador. Como es de esperar, aquí es donde se especifica el algoritmo de consenso (línea 48). En esta versión, se especifica que usaremos el algoritmo del modo dev;
  5. El motor devmode contiene las (pocas) configuraciones de este algoritmo específico

Cambiar el algoritmo de consenso es bastante simple: simplemente modifique la configuración del nodo de validación eligiendo el algoritmo que pretende usar. En aras de la claridad, hemos utilizado el motor de modo de desarrollo, que funciona cómodamente con un solo nodo; los algoritmos más complejos necesitan al menos cuatro nodos y, coherentemente, el archivo docker-compose es más complejo.

Como ejemplo, verifique el GitHub que contiene las configuraciones para usar pBFT como un algoritmo de consenso (línea 138) y cómo se configura dicho algoritmo para su uso en este escenario (líneas 300–304); pBFT necesita al menos cuatro nodos para funcionar (debido a la elección del líder), por lo que encontrará cuatro nodos validadores y, análogamente, cuatro motores pBFT, uno para cada validador.

Conclusión

Hyperledger Sawtooth es capaz de acomodar una amplia gama de diferentes configuraciones de blockchain, lo que nos permite personalizar la forma y los medios de las transacciones. El algoritmo de consenso, que es central en la forma en que la cadena de bloques realmente se comporta, es configurable y, listo para usar, hay una variedad de opciones disponibles para seleccionar cuidadosamente el rendimiento de la cadena de bloques y la resistencia a los ataques bizantinos.

Fuente: https://blog.logrocket.com/hyperledger-sawtooth-introduction/ 

#hyperledger #sawtooth 

Una Suave introducción A Hyperledger Sawtooth

Deploying DAML Smart Contracts on Hyperledger Sawtooth

In our last blog, Deploying DAML based Smart Contracts on project:DABL, we deployed our daml application on project:DABL, a blockchain platform by digital asset. We also discussed how DAML provides support on multiple blockchain platforms like hyperledger sawtooth, fabric, Corda etc.

In this blog we will take a step further in our DAML journey and deploy our application on another blockchain platform which is Hyperledger Sawtooth.

Hyperledger Sawtooth

So before jumping to deployment of applications and all the technical stuff, let’s just have a small introduction to sawtooth.

Hyperledger Sawtooth is an open source Blockchain platform founded by the Linux Foundation’s open-source blockchain project, Hyperledger. It is an enterprise-grade distributed ledger and was one of the first projects under the Hyperledger umbrella.

Hyperledger is a home to different distributed ledger frameworks like hyperledger fabric, Indy, and our today’s main focus which is hyperledger sawtooth.

Some Advantages of hyperledger sawtooth are :

  1. Permissioned/Permission less: Sawtooth can be configured to be either permissioned or permission less. By default, Hyperledger Sawtooth is permissioned.
  2. Scaleable: sawtooth can handle large amounts of transactions. Depending on the number of transactions it can be scaled easily.
  3. Multi-Language support: sawtooth allows developing smart contracts in Python, JavaScript, Rust, C++, and Go.
  4. Loose coupling architecture. The blocks within the Sawtooth’s network are not highly dependent on each other, which means that the change that is made to one element would not affect the network as a whole. It offers smart contract abstraction to allow developers to create contract logic in the programming language of their choice.

Now that we know what hyperledger sawtooth is let’s us understand how we can take DAML application and deploy it on sawtooth

#scala #daml #hyperledger #sawtooth

Deploying DAML Smart Contracts on Hyperledger Sawtooth