議題

問題

1. 最終状態の定義:暗号アプリケーションを「使用可能」にするもの

2. なぜ「チェーン抽象化」は、モジュラーブロックチェーンの基本的なトポロジーから生じるUX問題の解決策なのか

3. 使用可能な暗号アプリケーションをチェーン抽象化インフラストラクチャの上に構築する必要がある理由

ソリューションスペース

1. インテントベースのアーキテクチャがチェーンの抽象化をもたらす方法

2. 意図マーケットプレイスは、ソルバーネットワークが大規模かつ競争力がある場合に最高のパフォーマンスを発揮することを理解する

3. 意図ソルバーネットワークのブートストラップには、意図を生成するアプリケーションをさらにオンボーディングする必要があります

提案

1. なぜ私たちは、ネットワーク効果を実現するために、十分な規模のソルバーおよび意図マーケットプレイスを成長させるために「ソルバーUX」を優先するクロスチェーンインテント標準が必要なのか

チェーン抽象化なしには、使用可能な暗号アプリケーションを構築することはできません

私たちの最も優秀で明るい建物は冗長なインフラですか?

多くの人々が l2s 利用可能であり、それに対する需要が多すぎることを嘆いています。最高の暗号エンジニアや基本的な考え方を持つ人々が、ユーザーにもっとブロックスペースを提供する方向に過剰に注意とエネルギーを割り当てているという批判には理由があります。

しかし、私は存在しない有用な暗号アプリケーションはないという考えを拒否します。

分散型金融は、個人がデジタル資産を自己管理する能力を提供し、厳格なサービスプロバイダーを回避し、デジタル資産を使用して現実世界で価値のあるものを購入することを可能にします。また、自己管理データの約束は、FAANGの独占企業を信頼してデータを安全に保つことにますます警戒心を強めている個人にとって、ユートピア的な選択肢を提供します。

私の意見では、本当の問題は有用な暗号アプリケーションの欠如ではなく、それらにアクセスしようとするエンドユーザーにとっての摩擦です。エンドユーザーは、暗号アプリケーションと対話するときに次のことを経験できる必要があります。

1. Speed: アプリケーションは、web2アプリケーションと同じくらい速く感じる必要があります。
2. コスト：Web2とは異なり、すべてのweb3のインタラクションにはある程度のコストがかかる必要がありますが、「クリックごとのコスト」は無視できるほど小さくなければなりません。
3. 検閲耐性（「許可なし」）：ウォレットを持っている人であれば、クリックできる余裕があれば、アプリケーションとやり取りできるはずです。
4. セキュリティ：クリックはユーザーが期待する動作を行うべきであり、すべてのweb3の更新は恒久的であるべきです。

これらは「利用可能な」暗号アプリケーションの特性です。

私たちは長い間使いやすい暗号通貨を構築しようとしてきました

今日のモジュラーなブロックチェーンソリューションは、これらすべての特性を消費者に提供しますが、すべてが同じ場所で利用できるわけではありません。

2020年、ブロックチェーンはモノリシックであり、ユーザーに速度、コスト、またはセキュリティのうち2つを提供していました。その後、私たちはビジョンを見据えました。ロールアップ中心またはモジュラーな未来同時にすべてのプロパティを解除する

今日、私たちはこのロールアップ中心のインフラストラクチャの基盤を構築しました。L2は安価で高速なブロックスペースを提供し、ほとんどの場合、無許可のブロックスペースを提供します。一方、L1はWW3に耐える安全なブロックスペースを提供します。（L1とL2が提供するセキュリティとUXのトレードオフについては、詳しくはこちらをお読みください。私の短い調査記事）これらのL2は、カノニカルメッセージパスを介してL1に安全に接続し、モジュラーでありながら相互運用可能なネットワークの基盤を築いています。過去4年間、将来的に有用な暗号アプリケーションをサポートするブロックチェーン間の光ファイバーを構築してきました。しかし、なぜモジュラーブロックチェーンはあまり使いやすくないのでしょうか？

モジュラー・ブロックチェーン・ネットワークの必然性は、資本資産が最も安全なレイヤーで蓄積される一方、ユーザーのクリックはより速く安くなるレイヤーで蓄積されるということです。

モジュラーなブロックチェーンのトポロジーは、安全なブロックスペースを安価で高速なブロックスペースよりも異なるレイヤーで提供するよう奨励します。ユーザーは自然に最も安全なネットワークに価値を保管することを好むでしょうが、最も頻繁に安価で高速なネットワークとやり取りすることを要求するでしょう。設計上, L2とL1間の正規パスは遅く、または高価です。これらの現象によって、ユーザーはL1アセットを使用してL2インタラクションの支払いを行うためにこれらの正規パスを横断する必要があることが説明されます。これにより、“使用できない”暗号UXが生じます。

Vitalikによる異なるタイプのL2について

チェーン抽象化の目標は、ユーザーからプロトコル内の経路を通じて価値を送信する際の摩擦を減らすことです。チェーン抽象化ユーザーは、「意図」として、DAppに望む最終状態を指定することを好むと仮定し、その意図を達成するのはDAppの責任です。ユーザーは、低手数料や低レイテンシにアクセスするために、自分の資産の安全な管理を犠牲にする必要はありません。

したがって、チェーンの抽象化ユーザーが価値を安全に、安価に、迅速にネットワーク間で転送できることが重要です。現在一般的なユーザーフローは、イーサリアムのような「安全」なチェーン上にUSDC残高を持つユーザーが、BlastやBaseなどの新しいチェーンでNFTを作成したり新しいトークンと交換したいというものです。これを可能な手順で実行する方法は、Bridge→Swap→Mintの一連のトランザクション(またはSwap→Bridge→Mint)を順次実行することです。

この例では、ユーザーの意図は、安全なチェーン上のUSDCを使用して、別のチェーン上でNFTを作成することです。ユーザーは、NFTを受け取り、どこで保管するかに関係なく、USDCの残高が減少することができれば満足します。

インテントベースのアーキテクチャは、チェーンの抽象化を構築する唯一の方法です

チェーンの抽象化は、クロスチェーン価値の転送に依存していますが、基本的なメッセージパスを介した価値の送信は高価か遅いです。 「高速ブリッジ」は、ユーザーがネットワーク間で価値を送信するための安価で迅速な代替手段を提供しますが、新しい信頼の前提条件を導入します。 メッセージパッシングは、TCP/IPアーキテクチャに基づいてモデル化されているため、高速ブリッジを構築する最も直感的な方法です。 TCPルーターとして機能するブリッジプロトコルに依存して、2つのチェーンを接続します。

ResearchGateからのTCP/IP図

メッセージパッシングを介した価値の転送は、ブリッジプロトコルが元のチェーンと送信先のチェーン間でメッセージを送信することを含みます。このメッセージは、ユーザートランザクションによって元の側でトリガーされ、メッセージの「有効性」が検証された後、送信先の側に中継されます。

メッセージは、メッセージを開始するオリジナルチェーントランザクションが完了した後にのみ検証できます。つまり、トランザクションはオリジンチェーンの正規ブロックチェーンに恒久的に含まれています。この検証は、オリジンチェーンのトランザクションが合意によって含まれていることを証明する妥当性証明として、楽観的な提案として、またはオリジン側での証人署名の閾値が蓄積された後に完了できます。メッセージが目的地チェーンのブリッジ契約に中継されると、トークンがユーザーにリリースされます。

このアーキテクチャにはいくつかの基本的な問題点があります。

1. 検証メカニズムは、メッセージを宛先チェーンプロトコル契約に送信する前に完全な最終性を待たなければなりません。これは、楽観的最終性期間を持つL2に最大7日かかることがあります。
2. 1つのクロスチェーンメッセージが1つのブリッジトランザクションごとに送信されるか、メッセージがバッチ処理されるが、バッチ内の最後のメッセージが確定された後にのみ送信できます。
3. このブリッジは、ユーザーの意図の達成経路について宣言しなければならないため、ユーザーに価格改善を提供するための外部流動性を限定的に取得する能力があります。

メッセージパッシング型の高速ブリッジは、検証メカニズムに応じて、安全でない、遅い、または高価になる可能性があります。 インテント・マーケットプレイスは、高速ブリッジのための代替アーキテクチャであり、重要な洞察から生まれたものです。

価値は代替可能であり、受取人にとって、資金を受け取れば送金方法は問題ではないはずです

ブリッジは、速度を向上させ、コストを削減するために、価値の転送を洗練されたエージェントに外部委託できるでしょうか？流動性はオンチェーンとオフチェーンで動的であり、ブリッジメカニズムが転送時に最適な実行パスを選択する柔軟性を持っていれば、価格改善が実現できます。

インテントメカニズムを使用すると、ユーザーは、その価値転送トランザクションが実行される条件や契約を正確に指定できます。

最小限の有効な意図は、チェーンAからXトークンを支払ってチェーンBでYトークンを受け取るための注文です。

ブリッジプロトコルは、ユーザーのクロスドメイン意図を達成するためにブリッジトランザクションごとにドメイン間でメッセージを送信する必要はありません。代わりに、プロトコルは価値の転送を許可されていないソルバーネットワークから選択されたエージェントに外部委託し、個々のソルバーは後でブリッジプロトコルから返済を求めます。これに対して、メッセージパッシングメカニズムは、自分たちのトランザクションがどのように実行されるべきかを正確に指定し、エージェントの可用性に依存する必要はありません。

意図決済プロトコル

意図ベースのブリッジプロトコルは、ソルバーがユーザー指定の条件を違反しないようにする責任を持つ意図決済プロトコルとして、より正確にラベル付けできます。意図決済プロトコルは、ソルバーに、ユーザーの意図を満たした場合に返済され、報酬されることを保証します。このため、意図決済プロトコルは、意図の達成の真正性を検証するためにオラクルに訴える必要があります。オラクルのセキュリティは、楽観的な挑戦期間、証人の閾値、または例えばZK有効性証明に基づくことができます。

インテント決済プロトコルは、個々のソルバが最終的なリスクを負って最適な実行パスを特定できるため、高速かつ安価な価値転送を提供します

メッセージパッシングブリッジは、発信元チェーンがファイナリティに到達した場合にのみ通信できます。最終的な時間は、オプティミスティック ロールアップでは 7 日、現在の ZK ロールアップでは 1 時間です。ZKライトクライアント技術の普及と共有シーケンシング事前確認技術の進歩により、これらのファイナリティ時間は減少傾向にあるはずですが、すべてのブロックチェーンのファイナリティ時間がユーザーにとって「即時」に感じられる可能性は低く、高速ブリッジングソリューションが持続的に必要であることを示唆しています。ファイナリティ リスク (メッセージ パッシング ブリッジの範囲外) を引き受けずにファイナリティ期間よりも速くメッセージを中継することは不可能です。ただし、ブリッジが、チェーンの再編成による損失をバックストップする信頼できるエージェントをリレー パスに追加しない限り、メッセージ パッシング ブリッジの範囲外です。

意図ベースのアーキテクチャによって提供されるスピードアップは、異種ソルバーネットワーク内の個々のソルバーが、メッセージパッシングプロトコルよりもより多くの最終リスクを想定し、チェーン再編のリスクが完全に消失する前にユーザーの意図を実現できるためです。その後、ソルバーは、ユーザーにこの最終リスクを請け負うことで、より速い埋め込み時間を提供する代わりに料金を請求します。

エージェントにクロスチェーンの意図履行を外部委託することは、ユーザーにとって平均的に価格改善につながります。意図ベースのブリッジでは、ユーザーオーダーを望ましい宛先チェーンにフロントするソルバーは、履行が検証された後にシステムから後で返済されます。これらの意図の決済は、コストを分散するために一緒にバッチ処理することができます。ユーザーとは異なり、フィラーは即時返済を要求せず、資本をフロントするためにユーザーに対して適切な料金を請求します。バッチ決済は意図ベースのアーキテクチャに固有のものではありませんが、このアーキテクチャはバッチ決済とより協調的であるため、返済ステップを意図履行ステップから分離しています。

価格改善の大きなソースは、価値が代替可能であるという直感から来ており、適切な経路を見つけることが通常、価値の転送を上回るでしょう。(ただし、いくつかの経路は、USDCをCCTP経由でブリッジングする場合のように、コストで勝ることが不可能な場合があります。)

メッセージパッシングブリッジは、価値をユーザーにどのように転送するかをエンコードする必要があります。一部は、予め決められた交換レートでトークンを流動性プールから送信することを選択しますが、他の一部は、希望の正規トークン資産と交換するために代表トークンを受取人に造幣します。

ユーザーの意図を満たす際、エージェントはオンチェーンおよびオフチェーンの流動性ソースを組み合わせて流動性を供給することができます。競争力のあるソルバーネットワークは、理論上ユーザーに無制限の流動性ソースを提供します（ただし、これらの流動性ソースも、一方向のボリュームトレンドが高い波乱がオンチェーンイベントで発生した場合、人気のあるNFTミント、エアドロップ、およびラグプルのような場合には迅速に枯渇することがあります）。

クロスチェーン注文を意図として送信することで、ソルバーは注文によって生成されたMEVを価格改善として内部化することができます。

意図ベースのアーキテクチャは基本的に安全に設計されています

意図に基づいたブリッジは、ユーザーの緊急の要求を決済ネットワークの複雑な要求から分離するために安全に構築できます。ソルバーはユーザーとは異なり、返済を待つことができ、決済プロトコルが返済を待たせる時間に応じてユーザーに料金を請求します。したがって、意図の決済は厳格な時間制約なしに非常に堅牢なメカニズムを使用して検証することができます。これはセキュリティの観点から望ましいものです。意図の達成を検証することは直感的に複雑です。

本番環境での意図検証の例として、横断90分の楽観的なチャレンジ期間に続いて、バッチで埋め込みを検証して返済します。 もちろん、決済ネットワークは、エンドユーザー料金を削減するために埋め込みをできるだけ早く返済する努力をすべきです。 楽観的なチャレンジメカニズムの改善点は、ZK有効性証明メカニズムであり、これには意図の検証ロジックをZK回路にエンコードする必要があります。 私の意見では、有効性証明メカニズムが楽観的なチャレンジメカニズムを置き換え、意図の決済ネットワークがユーザーに返済する速度を高めることは避けられないと思います。

だから、チェーン抽象化は意図ベースのアーキテクチャからどのように生じるのですか？

チェーンの抽象化には、迅速かつ安価なチェーン間バリュートランスファーが必要です。また、ユーザーが自分の資産が保管されているネットワーク上でオンチェーントランザクションを提出する必要はありません。

ユーザーの意図には、それが含まれる場合、ユーザーによってチェーン上に提出する必要はありません。Permit2またはEIP3074signature。これは、メッセージパッシング型とインテントベース型の両方に当てはまります。両方のアーキテクチャは、Permit2パターンを活用して、ユーザーが元のチェーンウォレットから支払いたいトークンの量にサインをオフチェーンで行うことを許可することができます。

意図マーケットプレイスは、安価かつ迅速なクロスチェーン価値転送を提供するため、チェーンの抽象化を最もよくサポートします。ユーザーがリクエストを送信して、WETHステーキングポジションに入るための見積もりを求め、それをOptimism上のUSDCを支払いとして使用することができる世界を想像してみてください。ユーザーはこの意図をオフチェーンでRFQオークションに送信し、ソルバーがそれに入札することができます。オークションの勝利者であるソルバーは、ユーザーの署名入りの意図を受け取り、Optimism上のUSDCを使って支出する許可、Arbitrum上で受け取るWETHの希望数量、およびArbitrum上のステーキングポジションにこのWETHを預け入れるために必要なcalldataが含まれています。ソルバーはその後、このトランザクションをOptimism上で（ユーザーの代わりに）提出し、クロスチェーンの意図を開始し、ユーザーのOptimismウォレットからUSDCを引き出すことができます。最後に、ソルバーはユーザーの意図をArbitrum上で埋めて、WETHを送信し、ユーザーをオンチェーンのステーキングポジションに入れるためのcalldataを転送することができます。

チェーンの抽象化インフラストラクチャを構築することは、このユーザーフローが即座で安価に感じられるようにすることを意味し、オンチェーントランザクションを提出する必要はありません。この記事を広く普及させる障害について議論して、結論を出しましょう。

Acrossによるインテントアーキテクチャ

意図ベースのチェーン抽象化から最良のユーザーエクスペリエンスが具体化するためには、競争力のあるソルバーのネットワークが必要です

意図を結ぶことは、メッセージパッシングのバリアントよりも優れたパフォーマンスを発揮するために、ソルバーネットワーク効果に依存しています。これは、意図とメッセージパッシングアーキテクチャとの核心のトレードオフです。現実的には、意図を生成するすべてのアプリケーションが完全に競争力のあるソルバーのセットへのアクセスが必要とは限らず、一部のアプリケーションは意図をルーティングすることを好むかもしれません。oligopolistic solver networks. ただし、ソルバーネットワークの現在の状態は 未熟そして、インテントマーケットプレイスが依存するソルバーネットワークのライブネスの前提を満たすことはできません。

私たちは、各Dappが孤立したソルバーネットワークに意図をルーティングしている世界を望んでいません。UXの最良のケースは、多くのDappが同じソルバープールと通信し、すべてのDappがどのソルバープールに意図を送信するかを自由に変更できることです。

ソルバーネットワークをどのようにブートストラップしますか？

私たちはソルバーUXを優先する必要があります。

インテントソルバーを実行することは複雑であり、高性能ソフトウェアの構築とクロスチェーンインベントリリスクの管理に精通している専門知識が必要です。当然、このコードを実行するためのスタートアップコストを支払う興味を持つ限られたパーティーが存在するでしょう。最良のケースでは、UniswapXソルバーのような1つのdapp向けに書かれたソルバーは、AcrossやCowSwapなど他のインテントを生成するdapp向けに再利用される可能性があります。

すべてのインテントベースのdappsのソルバーネットワークの集約資本効率を実際に向上させる必要があります。これには、ソルバーの実行の障壁に対処する必要があります。

このためには、dappsが意図を生成し、すべてのソルバーが多様で競争力のある意図決済ネットワークにアクセスできるようにすることが必要です。これにより、ソルバーにとっては信頼できる決済ネットワークに意図の達成をルーティングする選択肢があるという自信が生まれます。決済ネットワーク間の競争もソルバーにとってコストを下げるでしょう。

意図決済ネットワークの価値提案は、解決者にセキュリティを提供するだけでなく、解決者の意図を充たす能力に影響を与える他の機能を提供することです。

The solver’s choice of intent settlement network will affect their ability to offer fees and execution-time guarantees to users. Some settlement networks might offer solver exclusivity periods, which would support the development of offchain auctions where solvers and users could negotiate and commit to relay fees. (These intent auctions might moreover offer economically bonded pre-confirmations, further enhancing UX. To learn more about a user flow featuring intent discovery via auctions and pre-confirmations I recommend this SorellaのKarthikによる話.)

一部の決済ネットワークは、意図の期限切れ（つまり、ある達成期限が過ぎた後に価値をユーザーに返送すること）、意図の補助（つまり、解決者がいない場合に決済ネットワークが独自の貸借対照表を使用してユーザーの意図を達成すること）、または柔軟な返済チェーン（つまり、解決者が選択したチェーンで返済を受けること）を提供するかもしれません。

最終的に、決済ネットワークはセキュリティを損なうことなく、解決者に迅速かつ安価に返済するために激しく競争します。その結果、解決者は、ユーザーに最も安い手数料を提供することを可能にする決済ネットワークに注文フローを送信し、それによってDapp注文フローを獲得できるようにします。決済および解決者ネットワークの競争は、意図された供給チェーンのすべての当事者が同じ言語を話すために調整することに依存し、競争はクロスチェーン価値転送の最良のUXにつながるでしょう。

クロスチェーンの意図には標準が必要であることは明らかです

もしソルバーが意図が共通の要素を共有すると仮定できる場合、それらは異なるdappsによって発生した意図を解決するためのコードを再利用することができ、その結果、セットアップコストを下げることができます。異なるdappsが同じ標準に準拠した意図を作成する場合、それらはすべての意図を同じソルバープールにルーティングすることができます。これにより、次世代のdappsをオンボードすることができ、彼らは既存の成熟したソルバープールに直接クロスチェーンの意図を接続する能力を与えられます。新しいdappsは個々にソルバーをオンボードする必要はなく、その代わりに安価で高速で安全で許可なしのバリュートランスファーにアクセスできるようになります。

サードパーティのトラッキングソフトウェアは、新しいDappに対して意図のステータスを追跡することがより容易になります。それらが標準に準拠している場合。

このインテント標準は、インテントプリンシパルまたはソルバーが自分のインテントを決済したいネットワークを指定できるようにするべきです。

SUAVE、Across、Anoma、およびKhalaniなどの競合する決済プロトコルが意図ソルバーに異なる機能を提供することを想定しています。 ソルバーが返済する決済ネットワークによって異なる価格と時間の保証を意図の所有者に提供できます。 dappとソルバーは、検閲を回避し、データプライバシーを維持し、またソルバーに返済する信頼性がある十分に安全な決済ネットワークにユーザーの意図をルーティングすることに同意できます。

決済ネットワークの選択を意図注文自体に組み込むことで、ソルバーはこの確実性をユーザーに表示する見積もりに組み込むことができます。ソルバーとユーザーは、チェーン上で意図を送信する前に、ブリッジの価格に関する前向きな不確実性を取り除くことができます。これによりコストが削減されます。

Uniswapとの協力およびCAKEワーキンググループからのフィードバックに基づき、Acrossと私は、ソルバーUXを優先する次のクロスチェーンインテント標準を提案します。

/// @titleCrossChainOrderタイプ

///@noticeスワッパーによって署名され、埋め込まれたフィラーに拡散され、決済契約に提出される標準注文構造体

struct CrossChainOrder {

/// @dev オーダーを決済するために使用される契約アドレス。/// フィラーはこの契約アドレスにこのオーダーを送信します。元のチェーンアドレス決済契約;/// @dev スワップを開始するユーザーのアドレス、/// 入力トークンが取得およびエスクローされるアドレススワッパー;/// @dev オーダーのリプレイ保護として使用されるノンスuint256 nonce;/// @dev 元のチェーンのチェーンIDuint32 originChainId;/// @dev オーダーを開始する必要があるタイムスタンプuint32 initiateDeadline;/// @dev オーダーを宛先チェーンで埋める必要があるタイムスタンプuint32 fillDeadline;/// @dev 任意の実装固有のデータ/// トークン、金額、宛先チェーン、手数料、決済パラメータ、/// またはその他のオーダータイプ固有の情報を定義するために使用できるバイトオーダーデータ;

}

この標準は、ソルバーの仕事をより簡単にするために設計されています。その一つの意見のある選択肢は、Permit2/EIP3074をネイティブでサポートし、nonceとinitiateDeadlineをサポートすることです。また、fillerには、決済ネットワークからの返金額や、追跡できるユーザーの意図の形式など、いくつかの保証が与えられます。さらに、この標準には、fillerDataを指定することが重要なイニシエータ機能が定義されており、ユーザーがCrossChainOrderに署名した時点では知らなかった追加の「fillerData」をオンチェーンで指定することができます。これにより、fillerは決済契約によってユーザーのメタトランザクションを提出することで報酬を受け取ることを確認し、また返済チェーンなどの返済特定情報を設定することができます。

この標準は、dapp がそのライフサイクル全体で意図の達成状況を追跡しやすくするように設計されています。この標準を実装する任意の決済契約は、任意の orderData フィールドから解析できるカスタムサブタイプ ResolvedCrossChainOrder を作成する必要があります。これには、スワップに関与するトークン、宛先チェーン、およびその他の達成制約などの情報が含まれる場合があります。標準には解決関数が含まれており、dapp がユーザーに意図の状態を表示する方法を理解し、解決者が作業する具体的な意図の順序構造を把握するためのものです。

///@titleResolvedCrossChainOrderタイプ

/// @notice注文の実装に汎用的な表現

///@dev実装固有のorderDataを解除して注文を埋めるためのすべての要件を定義します。

/// @dev任意の順序の入力および出力情報を計算できるようにすることによって、フィラーが統合の一般化を改善することを意図しています

struct ResolvedCrossChainOrder {

/// @dev 注文を解決するために意図された契約アドレス。アドレスsettlementContract；/// @dev 交換を開始するユーザーのアドレス。アドレスswapper；/// @dev 注文のリプレイ保護として使用されるノンスuint256 nonce；/// @dev オリジンチェーンのchainIduint32 originChainId；/// @dev 注文を開始する必要があるタイムスタンプuint32 initiateDeadline；/// @dev 注文を実行する必要があるタイムスタンプ（宛先チェーン）uint32 fillDeadline；/// @dev 注文開始時にswapperから取得する入力Input[] swapperInputs；/// @dev 注文の解決の一環としてswapperに提供する出力Output[] swapperOutputs；/// @dev 注文の解決の一環としてfillerに提供する出力Output[] fillerOutputs；

}

/// @noticeスワッパーによって送信されたトークンは、注文の入力として送信されました

struct Input {

/// @dev The address of the ERC20 token on the origin chainaddress token;/// @dev The amount of the token to be sentuint256 amount;

}

/// @notice有効な注文の遂行のために受け取る必要があるトークン

struct Output {

/// @dev 宛先チェーン上のERC20トークンのアドレス/// @dev アドレス(0)はネイティブトークンのセンチネルとして使用されますaddress token;/// @dev 送信されるトークンの量uint256 amount;/// @dev 出力トークンを受け取るアドレスaddress recipient;/// @dev この出力の宛先チェーンuint32 chainId;

}

コンプライアンスのある決済契約の実装は、ISettlementContractインターフェースを実装する必要があります:

///@titleISettlementContract

///@notice決済契約の標準インターフェース

interface ISettlementContract {

/// @notice クロスチェーン注文の決済を開始します/// @dev フィラーによって呼び出される/// @param order クロスチェーン注文の定義/// @param signature 注文に対するスワッパーの署名/// @param fillerData 決済人が必要とするフィラー定義データ/// @param order クロスチェーン注文の定義/// @param fillerData 決済人が必要とするフィラー定義データ/// @returns 入力および出力を含む、ResolvedCrossChainOrderのデータを取得します。

}

この標準の設計目標は、ソルバーのUXを向上させ、複数の決済ネットワークをサポートしやすくし、報酬を確実に計算することでした。これにより、ユーザーにより正確で緻密な見積もりを提供することが可能になると信じています。この標準、コード名ERC7683に関する詳細は、こちらでご確認いただけます。このX/Twitterの投稿およびそれに関連する議論Ethereum Magiciansフォーラムで.

閉会の挨拶

「インテント」は定義されていないために混乱しており、この定義の欠如が実際のUX欠陥を引き起こしています。

皆が他の人が彼らの意図の標準定義を使用することを望んでいるので、標準を確立することは実質的に不可能だと認めます。意図の決済システムを最初に定義し、オーダーフローを引き付けようとするのは、業界全体の標準を確立するための正しいアプローチだとは思いません。

私の意見では、すでに多くのユーザーフローを所有し、多くのユーザー意図を起源とするdappsにとって、より扱いやすいアプローチは、その既存のソルバーが採用するいくつかの最小基準に適合することです。これにより、新しい、より大きなソルバープールが形成されます。既存の有名な会場からの統合注文フローにアクセスすることで、この新しいソルバープールはより多くの利益を得ることができ、エンドユーザーにより良い価格を提示することができます。最終的には、新しいdappsもこのソルバープールに意図をルートし、その意図の標準をサポートするように要求するでしょう。

始動するために、AcrossとUniswapが共同で標準を提案するすべての意図されたサプライチェーン関係者が、ユーザーオーダーを処理する際に使用することができる、チェーンAからXトークンを送信し、チェーンBでYトークンを受け取るための注文フロー。オークションデザインにおける比較的優位性を持つUniswapX（意図の発生と起源において比較的優位性を持つ）と、意図の達成を解決する比較的優位性を持つAcross（比較的優位性を持つ）を通じて実行される注文フローは、より大規模で競争力のあるソルバーネットワークの育成プロセスを開始させることができます。

免責事項：

1. この記事は[ミラー], すべての著作権は元の著者に帰属します[Nick Pai]. If there are objections to this reprint, please contact the Gate Learnチームが promptly すぐに対処します。
2. 責任の免責事項：この記事で表現されている意見は、著者個人のものであり、投資アドバイスを構成するものではありません。
3. 他の言語への記事の翻訳は、Gate Learnチームによって行われます。特に言及されていない限り、翻訳された記事のコピー、配布、または盗用は禁止されています。