プロトコルの構成可能性: あるアプリケーションが別のアプリケーションに接続する方法
ボタンから始めましょう
オンチェーン アプリケーションを開くときに、ユーザーが通常目にするのは、ウォレットに接続し、金額を入力し、操作を確認することです。インターフェイスは非常にシンプルですが、その背後にある作業は複数のプログラムによって完了する場合があります。つまり、1 つのモジュールが口座を読み取り、別のモジュールが交換結果を計算し、別のモジュールが資産の受け取り、残高の更新、ステータスの記録を担当します。このコラボレーションはプロトコルの構成可能性として理解できます。つまり、既存の機能がインターフェイスを介して接続され、別のアプリケーションの一部になります。
この概念を理解するために、最初にすべてのコードを読む必要はありません。まず、具体的な質問をすることができます。「このボタンを押すと、どのようなオブジェクトが関係しますか?」インターフェイス上のアクションを分解し、誰がリクエストを作成し、誰がルールを実行し、誰が結果を記録するかを区別することで、アプリケーション間の関係が徐々に見えてきます。この記事は、読み取り方法を説明するために仮想的なシナリオを使用しており、特定の製品の実際の操作プロセスに対応するものではありません。
読書プロセス中に、製品プロモーションの壮大な物語を一時的に無視して、目に見える最小のアクションから始めることもできます。最初にクエリについて説明し、次に状態変化について説明し、最後に複数のモジュールがどのように連携するかを説明します。この順序により、同時に出現する馴染みのない用語の負担が軽減され、それぞれの新しい概念が以前に理解された例に基づいて作成されるようになります。
あるアプリケーションが別のアプリケーションを使用できる機能
資産を管理するためのアプリケーションを考えてみましょう。ユーザーが資産 A を資産 B に交換することを望んでいましたが、チームは交換メカニズムを再開発しませんでした。代わりに、既存の契約によって提供されるインターフェイスを通じて交換機能を呼び出しました。ユーザーはあるページから操作を開始しますが、実際のやり取りは別の契約の契約となる場合があります。この分業により、アプリケーションは独自のエクスペリエンスに集中できるようになり、成熟した基本機能を再利用できるようになります。
ここでは 2 つの関係を区別する必要があります。ユーザーを別の Web サイトに誘導することは、ポータル間の接続にすぎません。プログラムは別のプログラムを直接呼び出しますが、これには実行レベルの組み合わせが含まれます。この 2 つはインターフェースが似ているように見えますが、役割は異なります。製品紹介を読むときは、「統合」をジャンプ、データ読み取り、トランザクション呼び出しなどの特定のアクションに分解するとよいでしょう。
インターフェースは共通言語であり、ルールは個別に存在します
モジュールを最初に接続できるかどうかは、双方が互いの入力と出力を理解しているかどうかによって決まります。インターフェイスは、どの関数を呼び出すことができるか、どのパラメータを指定する必要があるか、どのような結果が返されるかを規定します。たとえば、残高の読み取りと送金のリクエストは別のアクションであり、同じ資産を中心に展開する場合でも、これらを混同することはできません。統合インターフェイスにより通信コストが削減されますが、すべての製品ルールが自動的に統合されるわけではありません。
特定のトークン規格も使用する資産には、異なる発行の取り決めや制限がある場合があります。アクセス側は、実際の動作が想定と一致しているかどうかを確認する必要があり、見慣れた名前を見ただけでチェックを終了することはできません。したがって、インターフェイスは調査の開始点として使用でき、特定の実装、権限設定、例外処理によって、接続が現在のシナリオに適しているかどうかが決まります。
アセットのパスに沿ってプロセスを解凍します。
資産管理の例を続けます。ユーザー口座、取引所モジュール、受取口座という 3 つのノードを紙に書き留め、各ステップで資産の種類、数量、管理者を順番に記録します。資産は最初に中間契約を締結しますか?償還後の受け取り住所は誰ですか?ページには期待される結果が表示されますか? それともすでに実行された結果が表示されますか?これらの質問は、単に製品名を覚えるよりも役に立ちます。
プロセスに別のプロトコルへの入金も含まれる場合は、すべてのアクションを「完全な投資」に結合するのではなく、別のノードを追加します。入金後に得られるものは、残高記録または別の種類のバウチャーである可能性があります。具体的な意味は別途確認する必要がある。逆アセンブリの目的は、各ステータス変更に対応する説明を提供し、複数の異なるアクションをカバーするために 1 つのインターフェイス ワードを使用することを避けることです。
データの依存関係を実行の依存関係から分離する
アプリケーション間の接続は、必ずしも資産の移動を伴うわけではありません。一部の接続は、残高、価格、特定のステータスなどのデータの読み取りのみを行います。他の接続では、資産の転送やポジションの更新など、ステータスが変更されます。 2 種類の依存関係を分離して読み込むことで、外部モジュールの変更が表示、判定条件、実際の実行に影響を与えるかどうかをより迅速に判断できます。
ページでは複数のデータ ソースを同時に使用できます。表示される価格のソースは、契約締結時に使用される価格と必ずしも一致しません。ページの更新速度は、チェーン上の状態変化の速度と等しくありません。データがどこで生成されたか、誰が更新したか、どのリンクで使用されたかを調査記録に示すことが最善です。説明できない部分があった場合は、自分で完成させるのではなく、検証項目として残しておく必要があります。
1 回の確認は 1 回のアクションだけを意味するわけではありません
ユーザーがトランザクションを確認すると、内部で複数のコントラクト呼び出しが発生する場合があります。特定の実行環境では、同じトランザクション内で複数のステップをスケジュールできますが、これに該当するかどうかは、特定の実装を確認する必要があります。ページ上にボタンが 1 つしかないからといって、すべてのリンクが同じ完了条件を持つとは想定できません。また、ネットワーク間およびサービス間のプロセスを同期実行として理解することもできません。
読者にとっては、「送信されたリクエスト」と「形成された目標状態」を区別する方がより実用的です。インターフェイスのプロンプト、取引記録、および最終残高は、それぞれ異なる質問に答えます。また、プログラムが内部ステップの失敗を検出し、他のロジックを続行する可能性がある状況も考慮する必要があります。したがって、トランザクションが成功したことを確認した後も、予想される結果に対して実際に何が起こったのかを検証する必要があります。
権限は複合関係の一部です
関数を接続できるからといって、どのアカウントでも関数を任意の方法で呼び出せるわけではありません。特定のエントリには承認が必要な場合があり、特定の管理アクションは特定の役割によってのみ実行される場合があります。組み合わせたアプリケーションを研究するときは、通常のプロセスを調べることに加えて、どのサブジェクトがパラメータの調整、機能の一時停止、依存するアドレスの変更、または実装のアップグレードを実行できるかを記録することも必要です。これらの能力はその後の行動に影響を与えます。
ユーザー側の権限も別途理解する必要があります。ウォレットの接続、メッセージへの署名、アセットの承認は異なる動作です。承認が必要なプロセスについては、承認される対象、金額、目的を確認し、後で承認を取り消す方法を理解しておく必要があります。ここでのポイントは、すべての権限を例外として扱うことではなく、権限を実際のニーズに合わせて、ユーザーが同意する内容を説明できるようにすることです。
組み合わせにより利便性がもたらされ、依存関係の連鎖が増加します
既存の機能を再利用すると、最初から構築する作業が軽減され、チームは新しい使用シナリオに集中できるようになります。ユーザーにとって、本来は複数のページにわたって完了する必要があるタスクも、より連続的なプロセスに編成される場合があります。ただし、入り口が少なくても、根底にある関係が少なくなるわけではありません。多くの場合、複雑さはインターフェイスに単純に含まれています。
したがって、組み合わせた製品を評価する場合、接続されているプロトコルの数だけを見ることはお勧めできません。さらに注目に値するのは、接続が必要かどうか、依存関係が明確かどうか、例外が説明できるかどうか、終了がまだ可能かどうかです。外部リンクが一時的に利用できなくなると、他の機能にどのような影響が出ますか?これらの質問に答えることができれば、コラボレーション ロゴの長いリストを表示するよりも、実際の操作にはるかに近くなります。
バージョンとネットワークにより、どのオブジェクトを調査しているかが決まります
同じ製品名で、異なるネットワーク上に展開することも、複数のバージョンを同時に維持することもできます。調査する場合、単にブランド名を記録するだけでは十分ではありません。ネットワーク、バージョン、契約アドレス、ドキュメントのリンク、レビュー日をまとめて記載しておくと、後の人が結論がどのオブジェクトを指しているのかがわかり、変更後に再確認できるようにするのが最善です。
ドキュメントがインターフェイスの説明と矛盾している場合でも、どちらかを急いで信じないでください。まず、2 つが同じバージョンを指しているかどうかを確認してから、リリース レコードとオンチェーン レコードを検索します。確認できない関係については、疑いや不足している証拠を明確に書き留めてください。この記録方法により、調査の継続が容易になり、古いバージョンの経験を新しい実装に直接転送することを避けることができます。
完全な記録で理解を確認する
公的な記録から研究課題に関連する例を選択することは、宣伝文句を何度も読むよりも効果的であることがよくあります。まず、発信元の住所、ターゲットの契約、時刻を記録し、次に資産の変更と関連イベントを観察します。レコードを以前に描画したプロセスと項目ごとに比較して、未確認の中間リンクがあるかどうか、また実際の結果が独自の解釈と一致しているかどうかを確認します。
ただし、1 つの例はその時点の状況を説明するだけであり、すべての入力が同じ結果を生成することを証明することはできません。制約と例外パスについてもお読みください。たとえば、数量、流動性、または権限が変更された後、プロセスが別のブランチに分岐する可能性があります。研究ノートには、観察された事実、文書に基づいた説明、個人的な推論を明確に記載する必要があります。
一般的な結論を与えるよりも、具体的な質問を書き留めることの方が重要です。
研究ノートでよく使われる表現は、「このプロトコルは別のプロトコルに依存しています」です。 This sentence is in the right direction, but it doesn’t help readers understand the impact.どの関数が依存し合っているのか、どのような情報を読み取って、どのステップを呼び出し、戻り値をどのような判断に使うのか、より具体的に書き直すことができます。相手が応答を停止した場合、現在の操作は終了するか、待機するか、または別のパスに入るでしょうか?質問が具体的であればあるほど、追跡調査はより指示されたものになります。
Likewise, "supporting an asset" also needs to be unpacked.残高の表示のサポート、転送のサポート、交換のサポート、およびある種のバウチャーとしてのサポートは、さまざまなレベルの機能です。アプリケーションはこれの一部のみを実行できます。 When reading, first define the capabilities you are concerned about, and then check the corresponding evidence. This can avoid interpreting a name appearing in the interface as supporting all operations surrounding it.
You can also invite another reader to just look at the notes and try to retell the entire process.相手方当事者が依然として資産がどこに行くのかを知らない場合、またはページと契約の責任を区別できない場合、それは記録にギャップがあることを意味します。このプロセスでは専門的な語彙量を追求する必要はなく、むしろその表現が他の人が同じように明確な理解を確立するのに役立つかどうかをテストします。
出口パスには独自のページが必要です
多くのプレゼンテーションでは、プロセスに入る方法については詳しく説明されていますが、プロセスを終了する方法についてはあまり詳しく説明されていません。資産ステータスの変更を伴うアプリケーションの場合、バウチャーの取得、返済、認証解除、または償還のパスを個別に編成できます。各ステップがどのような条件に依存するか、追加のトランザクションが必要かどうか、他の関係者が関与するかどうかはすべて、製品を理解するために不可欠な部分です。
ここでは、単純な逆の読み取りを行うことができます。つまり、最終的に望ましい状態から始めて、前のステップで何を行う必要があるかを徐々に尋ねます。特定のリンクが手動処理のみに依存できる場合、または外部ステータスの更新を待つ必要がある場合は、真実を記録する必要があります。通常の入場と通常の終了を組み合わせると、スタート ボタンを理解するだけでなく、プロセスを完全に理解することができます。
継続的に更新できるリサーチノートを作成する
最後に、メモのページで調査を締めくくります。アプリケーションがどのような問題を解決するのか、どの機能がそれ自身から来るのか、どの機能が外部から来るのか、などです。資産とデータの流れ。誰が調整権限を持っているか。結果はどこで検証されますか。そして終了するにはどのような条件が必要ですか。結論ごとにレビューできるレコードを含めるようにして、未解決の問題にマークを付けて、次回の更新が明確な開始点になるようにしてください。
プロトコルの構成可能性について理解する最も価値のあることは、機能間に新しい協力関係を形成できることです。この関係を理解するには、インターフェイスの利便性と各モジュールが保持する境界の両方を確認する必要があります。アプリケーションを説明可能かつ検証可能なリンクに分割し、それらを接続できるようになると、インターフェイスを観察することからインターフェイスの背後にある操作を理解することができるようになります。