ChainLink(チェーンリンク)のホワイトペーパーの翻訳 #2

2.アーキテクチャーの概要

チェーンリンクのコアは、オンチェーンとオフチェーンの二つの環境をブリッジする役割を担っている。チェーンリンクの各アーキテクチャのコンポーネントは以下に記述している。チェーンリンクは、イーサリウム上に構築されており、我々は、全てのオフチェーンとクロスチェーンのトランザクションをサポートすることを視野に入れている。オンチェーンとオフチェーンの両者において、チェーンリンクは、モジュールモデルを採用する考えである。であるから、チェーンリンクシステムの各ピースは、アップデートが自在に可能であり、異なるコンポーネントをより優れた技術のものに置き換えていくことができる。

2.1 オンチェーンのアーキテクチャ

オラクルサービスとして、チェーンリンクのノードは、USER-SCによって規定されるデータリクエストもしくはユーザーの契約に基づくクエリにリプライを返す。契約に対して応答するChainlinkのオンチェーンインターフェース自体が、CHAINLINK-SCと呼ぶオンチェーンのコントラクトになる。

CHAINLINK-SCの裏には3つのメインコントラクトコンポーネントから成る。つまり、レピュテーションコントラクト、オーダーマッチングコントラクト、そして、アグリゲーションコントラクトである。

レピュテーション・コントラクトは、オラクル・サービス・プロバイダーのパフォーマンスメトリックスをトラッキングする役割を担っている。オーダーマッチング・スマートコントラクトは、提案されたサービスレベルアグリーメントの形態を取り、SLAパラメーターのログを取り、そして、オラクルプロバイダーから入札を集める。入札の中から、レピュテーションコントラクトを利用して、選別し最終的なorcale SLAを決定する。アグリゲーション・コントラクトが、オラクル・プロバイダーのレスポンスを収集し、そしてChainlinkクエリの最終的な集合結果を計算する。同様に、オラクルプロバイダーのメトリックスは、レピュテーションコントラクトにデータフィードを返す。ChainLInkコントラクトは、モジュール形態でデザインされているので、ユーザーの必要に応じて、コンフィグレーションを変更したり、別のものにリプレイスするなどができるようになっている。であるから、オンチェーンのワークフローは、3つのステップを踏むことに成る。1.オラクルの選定、2.データレポーティング、3.結果のアグリゲーションの順序である。

オラクルの選定

オラクルの利用者は、要件を明確化したサービス・レベル・アグリーメント(SLA)の提案を作る必要がある。そのSLAの提案は、クエリの変数やオラクルの必要数などの情報を含む。加えて、利用者は、レプテーションとアグリゲーションコントラクトも特定する必要がある。

過去の契約の大量のログデータと合わせて、オンチェーン上でメンテナンスされているレピュテーションコントラクトを使うことで、利用者は、オフチェーンのリスティングサービスを使うことで、一連のオラクルをソートし、フィルターし、そして、最終的な候補を選択する。我々の意図は、Chainlinkが一つのリスティングサービスを維持し、全てのChainlinkに関係するログを収集し、バイナリーコード化されたオラクルコントラクトを認証するということにある。リスティングサービスとレピュテーションシステムについては、Section5で詳述する。リスティング結果を生成するためのデータは、Chainlinkのブロックチェーンから抽出し、同時に代替的なオラクルリスティングサービスも提供する。利用者は、SLA提案をオラクルオフチェーンに提出し、SLAのオンチェーン処理を行う前に、アグリーメントに到達する必要がある。

人為的なマッチングは、全ての状況において不可能になっている。例えば、あるコントラクトが、オラクルのサービスをその量に応じてダイナミックに選ぶ必要があるとする。自動化されたソリューションがこの問題を解決し、ユーザービリティを引き上げていくことを考えている。これらに対しては、自動化されたオラクルマッチングサービスもオーダーマッチングのコントラクトを使うことでChainklinkによって提案される。

利用者が、SLA提案を特定すると、オラクルと直接契約するのではなく、そのSLAをオーダーマッチングのコントラクトに提案するのである。そのオーダーマッチングコントラクトへのSLA提出がトリガーとなって、オラクル。プロバイダーは、彼らの実行可能性とサービス目的に基づき、フィルター作業が始まる。ChainLinkのノードネットワークは、そのコントラクトが、SLAの要件に見合ったノードの中から、入札のみを受ける形で、その提案に入札するかしないかを選択する。オラクルサービスの提供者がコントラクトに入札するときは、SLAで定義されている要件に対して誤った振る舞いを行った場合にペナルティが課されられるよう、一定のトークンをデポジットすることが求められる。

入札が入札ウィンドウのエンタティにアクセプトされる。SLAが、十分な入札が得られ、入札ウィンドウが閉じれた状態になると、その入札プールの中から、必要な数のオラクルが選定される。選ばれなかったオラクルには、ペナルティ用にデポジットされたトークンは返却される。そして、最終的なSLAのレコードが生成される。このレコード生成がトリガーとなって、選択されらオラクルにノーティスが送られ、オラクルは、SLAに明記されたアサインメントを実行する。

データレポーティング

新しいオラクルレコードが生成されると、オフチェーンのオラクルが、その合意を実行し、オンチェーンにレポーティングする。オフチェーントランザクションの詳細については、2.2と4を参照。

結果のアグリゲーション

オラクルが、そのオラクル契約に対して、その仕事の成果を明らかにすると、その成果が、アグリゲーションコントラクトにデータフィードとして送られる。そのアグリゲーションコントラクトは、その集計結果に従い、重み付けされた回答を計算する。各オラクルのレスポンスの認証が、レピュテーションコントラクトにレポートされ記録される。

最終的に、重み付けされた回答は、USER-SCにおける特定の契約機能に戻される。特手のデータフィードやアプリに不正のあるバリューが発見されることは問題である。たとえば、アウトラインされた回答を発見したり拒否するためには、数的なデータを平均化する前には必要かもしれないが、ブール代数には必要ない。この理由から、特定のアグリゲーションコントラクトではなく、利用者によって特定されるコンフィギュレーションコントラクトのアドレスがそこにあるのである。ChainLinkは、アグリゲーションコントラクトのスタンダードセットを含みつつも、カスタマイズされたコントラクトが、スタンダードな集計インターフェースに従う形で、特定することもできる。

つづく。

関連記事