「プロトコルアルファの読み込みを開始する方法」の版間の差分

提供: tezos-wiki
移動先: 案内、 検索
(ページの作成:「.. _entering_alpha: = How to start reading protocol Alpha = Protocol Alpha, whose Alpha has nothing to do with the one in Alphanet, is the name of the initial economic...」)
 
 
1行目: 1行目:
−
.. _entering_alpha:
+
.. _entering_alpha：
  
−
= How to start reading protocol Alpha =
+
=プロトコルの読み込みを開始する方法Alpha =
  
−
Protocol Alpha, whose Alpha has nothing to do with the one in Alphanet, is the name of the initial economic protocol. Alpha is a placeholder name, while we decide on the naming convention for protocol versions.
+
AlphaがAlphanetのものと何の関係もないプロトコルAlphaは、初期経済プロトコルの名前です。 Alphaはプレースホルダの名前ですが、プロトコルバージョンの命名規則を決定します。
  
−
Before reading that document, you may want to:
+
その文書を読む前に、以下のことを行うことができます：
  
−
* read the whitepaper,
+
*ホワイトペーパーを読んで、
−
* read :ref:<code>how the economic protocol is    sandboxed &lt;protocol_environment&gt;</code>.
+
* read：ref：<code>経済プロトコルがサンドボックス化された＆lt; protocol_environment＆gt; </code>の仕組み。
  
−
As all protocols, Alpha is made of a series of OCaml interface and implementation files, accompanied by a <code>TEZOS_PROTOCOL</code> file.
+
すべてのプロトコルとして、Alphaは、<code> TEZOS_PROTOCOL </code>ファイルを伴う一連のOCamlインタフェースと実装ファイルで構成されています。
  
−
== The <code>TEZOS_PROTOCOL</code> structure ==
+
== <code> TEZOS_PROTOCOL </code>構造体==
  
−
If you look at this file in the repository, you will see that it is composed of the hash of the sources, and the list of its modules, in linking order.
+
リポジトリ内のこのファイルを見ると、ソースのハッシュとそのモジュールのリストがリンク順で構成されていることがわかります。
  
−
Protocol Alpha is structured as a tower of abstraction layers, a coding discipline that we designed to have OCaml check as many invariants as possible at typing time. You will also see empty lines in <code>TEZOS_PROTOCOL</code> that denotate these layers of abstraction.
+
プロトコルアルファは抽象化層のタワーとして構成されています。これは、OCamlが入力時に可能な限り多くのインバリアントをチェックするように設計したコーディング規律です。これらの抽象化レイヤを示す<code> TEZOS_PROTOCOL </code>の空白行も表示されます。
  
−
These layers follow the linking order: the first modules are the tower’s foundation that talk to the raw key-value store, and going forward in the module list means climbing up the abstraction tower.
+
これらのレイヤーは、リンク順序に従います。最初のモジュールは、生のキー値ストアと通信するタワーの基盤であり、モジュールリストでは、抽象タワーを登ることを意味します。
  
−
== The big abstraction barrier: <code>Alpha_context</code> ==
+
==大きな抽象バリア：<code> Alpha_context </code> ==
  
−
the proof-of-stake algorithm, as described in the white paper, relies on an abstract state of the ledger, that is read and transformed during validation of a block.
+
ホワイトペーパーで説明されているように、ブロックの検証中に読み取られ、変換される元帳の抽象状態に依存します。
  
−
Due to the polymorphic nature of Tezos, the ledger’s state (that we call '''context''' in the code), cannot be specific to protocol Alpha’s need. The proof-of-stake is thus implemented over a generic key-value store whose keys and associated binary data must implement the abstract structure.
+
Tezosの多様性のために、元帳の状態（コード内で「コンテキスト」と呼ばれる）は、プロトコルAlphaの必要性に特定できません。このように、ステークの証明は、キーおよび関連するバイナリデータが抽象的な構造を実装しなければならない一般的なキー値ストアを介して実装されます。
  
−
The <code>Alpha_context</code> module enforces the separation of concerns between, on one hand, mapping the abstract state of the ledger to the concrete structure of the key-value store, and, on the other hand, implementing the proof-of-stake algorithm over this state.
+
<code> Alpha_context </code>モジュールは、一方で、元帳の抽象状態をキー値ストアの具体的な構造にマッピングすることと、このステートに対するステーク・オブ・ステーク・アルゴリズム
  
−
In more practical terms, <code>Alpha_context</code> defines a type <code>t</code> that represents a state of the ledger. This state is an abstracted out version of the key-value store that can only be manipulated through the use of the few selected manipulations reexported by <code>Alpha_context</code>, that always preserve the well-typed aspect and internal consistency invariants of the state.
+
より実際的には、<code> Alpha_context </code>は元帳の状態を表す<code> t </code>型を定義します。この状態は、<code> Alpha_context </code>によって再エクスポートされた少数の選択された操作の使用によってのみ操作できるキー値ストアの抽象化されたバージョンであり、常に型付きのアスペクトおよび内部一貫性不変条件を保持します。状態。
  
−
When validating a block, the low-level state that result from the predecessor block is read from the disk, then abstracted out to a <code>Alpha_context.t</code>, which is then only updated by high level operations that preserve consistency, and finally, the low level state is extracted to be committed on disk.
+
ブロックの検証時には、先行ブロックの結果である低レベルの状態がディスクから読み込まれ、次に<code> Alpha_context.t </code>に抽象化され、整合性を保つ上位レベルの操作によってのみ更新されます最後に、低レベル状態が抽出されてディスク上にコミットされる。
  
−
This way, we have two well separated parts in the code. The code below <code>Alpha_context</code> implements the ledger’s state storage, while the code on top of it is the proof-of-stake algorithm. Thanks to this barrier, the latter can remain nice, readable OCaml that only manipulates plain OCaml values.
+
このようにして、コード内に2つの分かれた部分があります。 <code> Alpha_context </code>以下のコードは、元帳の状態ストレージを実装していますが、その上にあるコードは、立証証明アルゴリズムです。この障壁のおかげで、後者は、単純なOCaml値を操作するだけで、見やすく読みやすいOCamlのままにすることができます。
 +
== <code> Alpha_context </code> ==の下に
  
−
== Below the <code>Alpha_context</code> ==
+
この部分については、ソースコードの最初の発見で、まずこの粗い記述に頼ることから始めることができます。具体的な不変量がどのように強制されるかについて興味があるときにチェリーピッキングを少し行います。
  
−
For this part, in a first discovery of the source code, you can start by relying mostly on this coarse grained description, with a little bit of cherry-picking when you’re curious about how a specific invariant is enforced.
+
モジュール<sub> <sub> <sub> <sub> <sub> <sub>?</sub> </sub> </sub> </sub>の<code> * _ repr </code> ?<sub>?</sub> </sub>?
  
−
The <code>*_repr</code> modules <sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub>~<sub>~</sub></sub>~
+
これらのモジュールは：ref：<code> Data_encoding＆lt; data_encoding＆gt; </code>を使用して、生のKey-Valueコンテキストの値を抽象化します。
  
−
These modules abstract the values of the raw key-value context by using :ref:<code>Data_encoding&lt;data_encoding&gt;</code>.
+
これらのモジュールは、プロトコルによって使用されるデータ型（量、契約ハンドル、スクリプト式など）を直列化する必要があります。各タイプについて、それは：ref：<code> Data_encoding＆lt; data_encoding＆gt; </code>を使用して、そのシリアライズフォーマットも定義します。
  
−
These modules define the data types used by the protocol that need to be serialized (amounts, contract handles, script expressions, etc.). For each type, it also defines its serialization format using :ref:<code>Data_encoding&lt;data_encoding&gt;</code>.
+
このレイヤーの上には、データベースのバイトシーケンス、送信されたブロックや操作のバイトシーケンス、またはRPC経由で送信されるデータの未処理のJSONはコードに決して表示されません。 OCaml値のみを操作します。
  
−
Above this layer, the code should never see the byte sequences in the database, the ones of transmitted blocks and operations, or the raw JSON of data transmitted via RPCs. It only manipulates OCaml values.
+
<code>ストレージ</code>モジュールとストレージファンクタ<sub> <sub> <sub> <sub> <sub> <sub> <sub> <sub> <sub> <sub> <sub>?</sub > </sub> </sub> </sub> </sub> </sub> </sub> </sub> </sub> > </sub>?</sub>?</sub>?</sub>?</sub>
  
−
The <code>Storage</code> module and storage functors <sub><sub><sub><sub><sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub></sub></sub></sub><sub><sub><sub>~</sub></sub></sub><sub><sub>~</sub></sub></sub>~<sub>~</sub>
+
コンテキスト内の値の具体的なフォーマットが抽象化されていても、コードが間違ったキーを持つ値や別の値にバインドされたキーにアクセスすると、型（または一貫性）エラーが発生することがあります。次の抽象化障壁はそれに対する救済策です。
  
−
Even with the concrete formats of values in the context abstracted out, type (or consistency) errors can still occur if the code accesses a value with a wrong key, or a key bound to another value. The next abstraction barrier is a remedy to that.
+
記憶モジュールは、キーリテラルが定義されているプロトコル内の単一の場所です。したがって、キーが衝突していないことを知るために、監査に必要な唯一のモジュールです。
  
−
The storage module is the single place in the protocol where key litterals are defined. Hence, it is the only module necessary to audit, to know that the keys are not colliding.
+
また、キーを抽象化して、各種類のキーに独自のアクセサーを取得します。たとえば、モジュール<code> Storage.Contract.Balance </code>には、契約の残高に固有のアクセサが含まれています。
  
−
It also abstracts the keys, so that each kind of key get its own accessors. For instance, module <code>Storage.Contract.Balance</code> contains accessors specific to contracts’ balances.
+
さらに、キーは、それらが指し示す値のタイプを保持します。たとえば、キー<code> Storage.Contract.Balance </code>に<code> Tez_repr.t </code>タイプの値だけを格納することができます。また、キーがグローバルキーではなくパラメトリックキーである場合、このキーは生のキーパートではなくOCaml値によってパラメータ化されます。
  
−
Moreover, the keys bear the type of the values they point to. For instance, only values of type <code>Tez_repr.t</code> can by stored at keys <code>Storage.Contract.Balance</code>. And in case a key is not a global key, but a parametric one, this key is parametered by an OCaml value, and not the raw key part.
+
したがって、契約残高にアクセスする際に使用する唯一の方法は、<code> Contract_repr.t </code>で<code> Storage.Contract.Balance.get </code> > Tez_repr.t </code>。
 +
これらの型付き操作はすべて、<code> TEZOS_CONTEXT </code>の<code> Storage </code>の直前にある一連のファンクタによって生成されます。
  
−
So in the end, the only way to be used when accessing a contract balance is <code>Storage.Contract.Balance.get</code>, which takes a <code>Contract_repr.t</code> and gives a <code>Tez_repr.t</code>.
+
<code> * _ storage </code>モジュール<sub> <sub> <sub> <sub> <sub> <sub> <sub> <sub>?</sub> </sub> </sub > </sub> </sub> </sub>?</sub>
  
−
All these well-typed operations are generated by a set of functors, that come just before <code>Storage</code> in <code>TEZOS_CONTEXT</code>.
+
前の2つの手順では、元帳の状態が常に型付きの方法でアクセスおよび更新されるようにしています。
  
−
The <code>*_storage</code> modules <sub><sub><sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub></sub><sub>~</sub></sub>~
+
ただし、契約が削除された場合など、コンテキスト内に状態を格納するすべてのキーが実際に削除されるなど、強制されません。
  
−
The two previous steps ensure that the ledger’s state is always accessed and updated in a well-typed way.
+
<code> * _ storage </code>という最後のこの一連のモジュールは、コンテキスト構造の恒常的な一貫性を保証するために、そのような不変条件を強制するためのものです。
  
−
However, it does not enforce that, for instance, when a contract is deleted, all of the keys that store its state in the context are indeed deleted.
+
これらの取引は、例えば、取引先がクレジットされた場合、ソースが借方記入されている場合があるように、借方記入されているかどうかを確認するまでは行かない。
  
−
This last series of modules named <code>*_storage</code> is there to enforce just that kind of invariants: ensuring the insternal consistency of the context structure.
+
== <code> Alpha_context </code> ==の上に
  
−
These transaction do not go as far as checking that, for instance, when the destination of a transaction is credited, the source is also debitted, as in some cases, it might not be the case.
+
次の3つのセクションでは、プロトコルの主なエントリポイントについて説明します。シェルによるブロックの検証（アプリケーションとも呼ばれることが多い）、スマートコントラクト、RPCサービスです。
  
−
== Above the <code>Alpha_context</code> ==
+
<code> Main </code>モジュールは、シェルが使用するエントリポイントです。それは、すべてのプロトコルが従わなければならないモジュールタイプを尊重します。そのために、そのコードはほとんどが配管ですが、
  
−
The three next sections describe the main entrypoints to the protocol: validation of blocks by the shell (that we often also call application), smart contracts, and RPC services.
+
<code>適用</code> <sub> <sub> <sub> <sub> <sub>?</sub> </sub> </sub> </sub> </sub> </sub> </sub> </sub>
  
−
The <code>Main</code> module is the entrypoint that’s used by the shell. It respects the module type that all protocol must follow. For that, its code is mostly plumbing,
+
これは、あなたが最初に読んだときから始めることです。たとえエラーケースの宣言や登録のようないくつかの配管コードが織り込まれていても、ほとんどのOCMl知識を理解するためには、ステークホルダーコードの大部分が冗長なスタイルで書かれています。
  
−
Starting from <code>Apply</code> <sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub>~<sub><sub><sub>~</sub></sub></sub>
+
シェルエントリポイント（ブロックヘッダの検証、操作の検証、ブロック検証の終了）から始め、<code> Alpha_context </code>抽象化バリアに達するまで制御フローに従います。これにより、<code> Baking </code>と<code> Amendment </code>モジュールを読むことができます。
  
−
This is were you want to start on your first read. Even if some plumbing code is woven in, such as error cases declaration and registration, most of the proof-of-stake code has been written in a verbose style, to be understood with minimum OCaml knowledge.
+
スマート契約<sub> <sub> <sub> <sub> <sub> <sub>?</sub> </sub> </sub> </sub> </sub> </サブ>
  
−
You want to start from the shell entry points (validation of the block header, validation of an operation, finalization of a block validation), and follow the control flow until you hit the <code>Alpha_context</code> abstraction barrier. This will lead you to reading modules <code>Baking</code> and <code>Amendment</code>.
+
<code> Apply </code>から、<code> Script_ir_translator </code>と<code> Script_interpreter </code>のモジュールになります。前者は新しいスマートコントラクトを作成するときに呼び出されるマイケルソンのタイプチェッカーであり、後者はトークンを新しいスマートコントラクトに転送するときに呼び出されるインタープリタです。
  
−
Smart contracts <sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub>
+
プロトコルRPC API?<sub> <sub> <sub> <sub> </sub> </sub>
  
−
From <code>Apply</code>, you will also end up in modules <code>Script_ir_translator</code> and <code>Script_interpreter</code>. The former is the typechecker of Michelson that is called when creating a new smart contract, and the latter is the interpreter that is called when transfering tokens to a new smart contract.
+
最後に、Alpha固有のRPCも<code> Alpha_context </code>バリアの上に定義されています。
  
−
Protocol RPC API ~<sub><sub><sub><sub><sub><sub><sub>~</sub></sub></sub></sub></sub></sub></sub>
+
サービスはテーマ別に分けられたいくつかのモジュールで定義されています。各モジュールはRPC APIを定義しています：パラメータのタイプと入出力JSONスキーマのURLスキーム。このインターフェースは3つの目的を果たす。これは型指定されているので、（同じファイルに登録されている）ハンドラが正しい入力と出力の型を持っていることを確認します。また、RPC呼び出しを実行するためにクライアントによって使用され、URLスキームとJSON形式と2者間で一貫性があることを確認します。これらの2つの機能は、リファクタリング時に非常に便利です.OCaml型チェッカーは、コードベース全体でRPC APIの変更の影響を追跡するのに役立ちます。第3の目的はもちろん、自動ドキュメンテーションの生成を可能にすることです（<code> tezos client rpc list / format </code>のように）。各サービスには、クライアントから呼び出しを実行するために使用できる呼び出し側関数と、偽のメモリ内コンテキストで呼び出しをシミュレートするテストが付随しています。
  
−
Finally, the RPCs specific to Alpha are also defined above the <code>Alpha_context</code> barrier.
+
自動的に生成されたJSON階層ではなく、サービス階層のOCaml定義を直接読んでみたいサードパーティの開発者にとっては便利です。
−
 
 
−
Services are defined in a few modules, divided by theme. Each module defines the RPC API: URL schemes with the types of parameters, and input and output JSON schemas. This interface serves three purposes. As it is thourouhgly typed, it makes sure that the handlers (that are registered in the same file) have the right input and output types. It is also used by the client to perform RPC calls, to make sure that the URL schemes and JSON formats and consistent between the two parties. These two features are extremely useful when refactoring, as the OCaml typechecker will help us track the effects of an RPC API change on the whole codebase. The third purpose is of course, to make automatic documentation generation possible (as in <code>tezos client rpc list/format</code>). Each service is also accompanied by a caller function, that can be used from the client to perform the calls, and by the tests to simulate calls in a fake in-memory context.
 
−
 
 
−
It can be useful if you are a third party developer who wants to read the OCaml definition of the service hierarchy directly, instead of the automatically generated JSON hierarchy.
 

2018年5月31日 (木) 00:36時点における最新版

.. _entering_alpha：

プロトコルの読み込みを開始する方法Alpha[編集]

AlphaがAlphanetのものと何の関係もないプロトコルAlphaは、初期経済プロトコルの名前です。 Alphaはプレースホルダの名前ですが、プロトコルバージョンの命名規則を決定します。

その文書を読む前に、以下のことを行うことができます：

  • ホワイトペーパーを読んで、
  • read：ref：経済プロトコルがサンドボックス化された＆lt; protocol_environment＆gt; の仕組み。

すべてのプロトコルとして、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＆lt; data_encoding＆gt; を使用して、生のKey-Valueコンテキストの値を抽象化します。

これらのモジュールは、プロトコルによって使用されるデータ型（量、契約ハンドル、スクリプト式など）を直列化する必要があります。各タイプについて、それは：ref： Data_encoding＆lt; data_encoding＆gt; を使用して、そのシリアライズフォーマットも定義します。

このレイヤーの上には、データベースのバイトシーケンス、送信されたブロックや操作のバイトシーケンス、または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定義を直接読んでみたいサードパーティの開発者にとっては便利です。

「http://tezos-wiki.jp/wiki/index.php?title=プロトコルアルファの読み込みを開始する方法&oldid=26281」から取得