Libra Developersサイトの要約:Life of a Transaction (1)

Libra

読む際の注意:この情報はペイメントシステムに大きな変更があったLibra white paper version 2より前に書かれたものです。この情報はその変更を適用する前のものなので注意して読んでください。

Life of a Transaction · Libra
_**Note to readers:** This information was published before the Association released White Paper v2.0, which includes a number of key updates to the Libra payme...

Libraトランザクションについて深く知るために、トランザクションが送られてから、リブラブロックチェーンに取り込まれるまでの道のりを見てみよう。

バリデータのそれぞれのロジカルコンポーネントにズームインして、他のコンポーネントとのインタラクションについて見てみる。

スポンサーリンク

クライアントがトランザクションを提出

10LBRをアリスのアカウントから、ボブのアカウントに転送するために、Libraクライアントは生のトランザクションを構成する(これをT5Rawと呼ぶ)

生のトランザクションは次のフィールドを含んでいる。

  • アリスのアカウントアドレス
  • アリス用に動作するアクションを示すプログラム
    • MoveバイトコードのP2Pトランザクションスクリプト
    • スクリプトのインプットのリスト(例えば、ボブのアカウントアドレスや支払い量)
  • ガスプライス(microlibra/gas unit):トランザクションを実行するために、アリスがGas Unitあたりで支払って良いとする金額。Gasは、計算処理とストレージのために支払う手段。Gas Unitは、計算処理の抽象的な計量値であって、実世界の(計算処理の)価値とはつながりがない。
  • アリスがこのトランザクションに支払う意思がある最大ガス金額。
  • トランザクションの有効時間
  • シーケンスナンバー(5):シーケンスナンバーが5のトランザクションはシーケンスナンバーが5のアカウントにのみ適用可能。

クライアントはトランザクションT5rawにアリスのプライベートキーで署名します。署名済みトランザクションT5は次のものを含んでいます。

  • 生のトランザクション
  • アリスのパブリックキー
  • アリスのサイン

Assumptions

トランザクションT5のライフサイクルを説明するために、次のことを仮定します。

  • アリスとボブはリブラブロックチェーンにアカウントを持っている。
  • アリスのアカウントは110LBRある
  • アリスのアカウントのシーケンスナンバーは5(これはアリスのアカウントから既に5のトランザクションが送られたことを示している)
  • ネットワークにはV1からV100までの100のバリデータがある。
  • クライアントはT5をV1に提出した。
  • バリデータV1はこのラウンドのプロポーザー/リーダである。

トランザクションのライフサイクル

このセクションでは、クライアントからサブミットされてから、ブロックチェーンにコミットされるまでの、トランザクションT5のライフサイクルについて説明する。

関連する場合、ライフサイクルの番号づけられたステップに続いて、 バリデータの対応するコンポーネント間のインタラクションへのリンクを提供する。トランザクションのライフサイクルについて詳しくなったら、各ステップの対応するコンポーネント間のインタラクションに関する情報を参照すると良い。

注:このドキュメントのすべてのグラフィックの矢印は、インタラクション/アクションを開始するコンポーネントから始まり、アクションが実行されるコンポーネント上で終わります。矢印は、データの読み書き、リターンを表すものではありません。

図1.1トランザクションのライフサイクル

/validator-sequence.svg

トランザクションの受付

  1. クライアントがトランザクションT5をバリデータV1に送り、V1のAdmission Control(AC)がトランザクションを受けとる。(Client → AC AC.1)
  2. ACはバーチャルマシーン(VM)コンポーネントを、サインの検証や、アリスのアカウントが十分なバランスがあるかのチェック、T5がリプレイになっていないかなどの検証に使います。(AC → VM AC.2,VM.1)
  3. T5がバリデーションチェックをパスしたら、ACはT5をV1のmempoolに送ります。(AC->Mempool AC.3,MP.1)

他のバリデータにトランザクションを共有。

  1. mempoolはT5をインメモリーバッファにホールドします。Mempoolには既にアリスのアドレスから送られた複数のトランザクションを含んでいるでしょう。
  2. 共有mempoolプロトコルを使って、V1はmempoolにあるT5を含んだトランザクションを他のバリデータ(V2-V100)にシェアします。そして、他のバリデータから受け取ったトランザクションで自分のmempoolを置き換えます。(Mempool -> Other validators MP.2)

ブロックの提案

  1. バリデータV1はプロポーザー/リーダなので、そのmempoolからトランザクションのブロックを取り出して、そのブロックを他のバリデータの提案としてコンセンサスコンポーネントを介して複製します。
  2. V1のコンセンサスコンポーネントには、提案するブロックのトランザクションのオーダーについて全てのバリデータの同意を調整する責任がある。 (Consensus → Other Validators CO.2) 提案プロトコル(LibraBFT)の詳細については、"State Machine Replication in the Libra Blockchain"のテクニカルペーパーを参照のこと。

ブロックを実行して同意に到達する

  1. 同意に至るための一環としてT5を含むトランザクションのブロックは実行コンポーネントに渡される。(Consensus → Execution CO.3, EX.1)
  2. 実行コンポーネントはトランザクションの実行をバーチャルマシーン上でうまくやる。この実行は、ブロック内のトランザクションが合意される前に投機的に行われることに注意してください。(Execution → VM EX.2, VM.3)
  3. ブロック内のトランザクションの実行の後、実行コンポーネントはT5を含むブロック内のトランザクションをレッジャーヒストリー内のマークルアキュムレータに追加する。これはインメモリーの一時的なバージョンのマークルアキュームレータです。この(提案された・投機的な)、これらのトランザクション実行結果はコンセンサスコンポーネントに返されます。 (Consensus → Execution CO.3, EX.1)。コンセンサスから実行コンポーネントへの矢印はコンセンサスコンポーネントによってトランザクションの実行がリクエストされたことを表しています。
  4. V1(コンセンサスリーダー)は、コンセンサスに参加している他のバリデータとブロックの実行結果についてコンセンサスを得ようとします。 (Consensus → Other Validators CO.3)

ブロックのコミット

  1. ブロックの実行結果が過半数を超えるバリデータによって合意され、署名された場合、バリデータV1の実行コンポーネントは、投機的な実行キャッシュからブロックの実行結果を読み取り、ブロック内のすべてのトランザクションを永続的なストレージにコミットします。 (Consensus → Execution CO.4, EX.3), (Execution → Storage EX.4, ST.3)
  2. アリスのアカウントは100LBRになり、シーケンスナンバーは6になります。もしT5がボブによりリプレイされたら、シーケンスナンバー6はリプレイされたトランザクションのシーケンスナンバー5よりも大きいため、リジェクトされます。
タイトルとURLをコピーしました