プロトコルアルファの読み込みを開始する方法
.. _entering_alpha:
プロトコルの読み込みを開始する方法Alpha[編集]
AlphaがAlphanetのものと何の関係もないプロトコルAlphaは、初期経済プロトコルの名前です。 Alphaはプレースホルダの名前ですが、プロトコルバージョンの命名規則を決定します。
その文書を読む前に、以下のことを行うことができます:
- ホワイトペーパーを読んで、
- read:ref:
経済プロトコルがサンドボックス化された< protocol_environment>
の仕組み。
すべてのプロトコルとして、Alphaは、 TEZOS_PROTOCOL
ファイルを伴う一連のOCamlインタフェースと実装ファイルで構成されています。
TEZOS_PROTOCOL
構造体[編集]
リポジトリ内のこのファイルを見ると、ソースのハッシュとそのモジュールのリストがリンク順で構成されていることがわかります。
プロトコルアルファは抽象化層のタワーとして構成されています。これは、OCamlが入力時に可能な限り多くのインバリアントをチェックするように設計したコーディング規律です。これらの抽象化レイヤを示す TEZOS_PROTOCOL
の空白行も表示されます。
これらのレイヤーは、リンク順序に従います。最初のモジュールは、生のキー値ストアと通信するタワーの基盤であり、モジュールリストでは、抽象タワーを登ることを意味します。
大きな抽象バリア: Alpha_context
[編集]
ホワイトペーパーで説明されているように、ブロックの検証中に読み取られ、変換される元帳の抽象状態に依存します。
Tezosの多様性のために、元帳の状態(コード内で「コンテキスト」と呼ばれる)は、プロトコルAlphaの必要性に特定できません。このように、ステークの証明は、キーおよび関連するバイナリデータが抽象的な構造を実装しなければならない一般的なキー値ストアを介して実装されます。
Alpha_context
モジュールは、一方で、元帳の抽象状態をキー値ストアの具体的な構造にマッピングすることと、このステートに対するステーク・オブ・ステーク・アルゴリズム
より実際的には、 Alpha_context
は元帳の状態を表す t
型を定義します。この状態は、 Alpha_context
によって再エクスポートされた少数の選択された操作の使用によってのみ操作できるキー値ストアの抽象化されたバージョンであり、常に型付きのアスペクトおよび内部一貫性不変条件を保持します。状態。
ブロックの検証時には、先行ブロックの結果である低レベルの状態がディスクから読み込まれ、次に Alpha_context.t
に抽象化され、整合性を保つ上位レベルの操作によってのみ更新されます最後に、低レベル状態が抽出されてディスク上にコミットされる。
このようにして、コード内に2つの分かれた部分があります。 Alpha_context
以下のコードは、元帳の状態ストレージを実装していますが、その上にあるコードは、立証証明アルゴリズムです。この障壁のおかげで、後者は、単純なOCaml値を操作するだけで、見やすく読みやすいOCamlのままにすることができます。
== Alpha_context
==の下に
この部分については、ソースコードの最初の発見で、まずこの粗い記述に頼ることから始めることができます。具体的な不変量がどのように強制されるかについて興味があるときにチェリーピッキングを少し行います。
モジュール ? の * _ repr
?? ?
これらのモジュールは:ref: Data_encoding< data_encoding>
を使用して、生のKey-Valueコンテキストの値を抽象化します。
これらのモジュールは、プロトコルによって使用されるデータ型(量、契約ハンドル、スクリプト式など)を直列化する必要があります。各タイプについて、それは:ref: Data_encoding< data_encoding>
を使用して、そのシリアライズフォーマットも定義します。
このレイヤーの上には、データベースのバイトシーケンス、送信されたブロックや操作のバイトシーケンス、またはRPC経由で送信されるデータの未処理のJSONはコードに決して表示されません。 OCaml値のみを操作します。
ストレージ
モジュールとストレージファンクタ ? > ???</sub>?</sub>
コンテキスト内の値の具体的なフォーマットが抽象化されていても、コードが間違ったキーを持つ値や別の値にバインドされたキーにアクセスすると、型(または一貫性)エラーが発生することがあります。次の抽象化障壁はそれに対する救済策です。
記憶モジュールは、キーリテラルが定義されているプロトコル内の単一の場所です。したがって、キーが衝突していないことを知るために、監査に必要な唯一のモジュールです。
また、キーを抽象化して、各種類のキーに独自のアクセサーを取得します。たとえば、モジュール Storage.Contract.Balance
には、契約の残高に固有のアクセサが含まれています。
さらに、キーは、それらが指し示す値のタイプを保持します。たとえば、キー Storage.Contract.Balance
に Tez_repr.t
タイプの値だけを格納することができます。また、キーがグローバルキーではなくパラメトリックキーである場合、このキーは生のキーパートではなくOCaml値によってパラメータ化されます。
したがって、契約残高にアクセスする際に使用する唯一の方法は、 Contract_repr.t
で Storage.Contract.Balance.get
> Tez_repr.t </code>。
これらの型付き操作はすべて、 TEZOS_CONTEXT
の Storage
の直前にある一連のファンクタによって生成されます。
* _ storage
モジュール ? ?
前の2つの手順では、元帳の状態が常に型付きの方法でアクセスおよび更新されるようにしています。
ただし、契約が削除された場合など、コンテキスト内に状態を格納するすべてのキーが実際に削除されるなど、強制されません。
* _ storage
という最後のこの一連のモジュールは、コンテキスト構造の恒常的な一貫性を保証するために、そのような不変条件を強制するためのものです。
これらの取引は、例えば、取引先がクレジットされた場合、ソースが借方記入されている場合があるように、借方記入されているかどうかを確認するまでは行かない。
== Alpha_context
==の上に
次の3つのセクションでは、プロトコルの主なエントリポイントについて説明します。シェルによるブロックの検証(アプリケーションとも呼ばれることが多い)、スマートコントラクト、RPCサービスです。
Main
モジュールは、シェルが使用するエントリポイントです。それは、すべてのプロトコルが従わなければならないモジュールタイプを尊重します。そのために、そのコードはほとんどが配管ですが、
適用
? </sub> </sub>
これは、あなたが最初に読んだときから始めることです。たとえエラーケースの宣言や登録のようないくつかの配管コードが織り込まれていても、ほとんどのOCMl知識を理解するためには、ステークホルダーコードの大部分が冗長なスタイルで書かれています。
シェルエントリポイント(ブロックヘッダの検証、操作の検証、ブロック検証の終了)から始め、 Alpha_context
抽象化バリアに達するまで制御フローに従います。これにより、 Baking
と Amendment
モジュールを読むことができます。
スマート契約 ? </サブ>
Apply
から、 Script_ir_translator
と Script_interpreter
のモジュールになります。前者は新しいスマートコントラクトを作成するときに呼び出されるマイケルソンのタイプチェッカーであり、後者はトークンを新しいスマートコントラクトに転送するときに呼び出されるインタープリタです。
プロトコルRPC API?
最後に、Alpha固有のRPCも Alpha_context
バリアの上に定義されています。
サービスはテーマ別に分けられたいくつかのモジュールで定義されています。各モジュールはRPC APIを定義しています:パラメータのタイプと入出力JSONスキーマのURLスキーム。このインターフェースは3つの目的を果たす。これは型指定されているので、(同じファイルに登録されている)ハンドラが正しい入力と出力の型を持っていることを確認します。また、RPC呼び出しを実行するためにクライアントによって使用され、URLスキームとJSON形式と2者間で一貫性があることを確認します。これらの2つの機能は、リファクタリング時に非常に便利です.OCaml型チェッカーは、コードベース全体でRPC APIの変更の影響を追跡するのに役立ちます。第3の目的はもちろん、自動ドキュメンテーションの生成を可能にすることです( tezos client rpc list / format
のように)。各サービスには、クライアントから呼び出しを実行するために使用できる呼び出し側関数と、偽のメモリ内コンテキストで呼び出しをシミュレートするテストが付随しています。
自動的に生成されたJSON階層ではなく、サービス階層のOCaml定義を直接読んでみたいサードパーティの開発者にとっては便利です。