著者 | ヴィタリック・ブテリン
著者 | ヴィタリック・ブテリン
2 つのロールアップ ソリューション A と B があり、アリスはロールアップ A の一定量のトークンをロールアップ B の同じトークンと交換したいとします。この問題に対する解決策はすでに誰かが提案しており、ロールアップ A とロールアップ B の両方がスマート コントラクトを完全にサポートしている場合、この仮定は分散型の方法で実現できます。ただし、この記事では、ロールアップ B のみがスマート コントラクトを完全にサポートしている (ロールアップ A は単純なトランザクションのみを処理できる) 場合に、クロスロールアップ転送を実装する方法を提案します。
提案
提案
交換仲介者 Ivan があるとします (実装には多数の仲介者から選択できます)。 Ivan は、ロールアップ A の IVAN_A (彼が完全に管理するアカウント) を所有しています。同時に、Ivan はロールアップ B のスマート コントラクト IVAN_B にも資金を入金しました。
スマート コントラクト IVAN_B には次のルールがあります。
➤ いずれかのユーザーがトランザクションを送信する場合（トークンのトランザクション値 TRADE_VALUE をアカウント IVAN_A に送信する）（宛先アドレス B DESTINATION もトランザクションのメモとして添付されます）、MIN_REDEMPTION_DELAY ブロックの最小返済遅延の後、ユーザー A のトランザクションはアカウント IVAN_B (以前の送金証明を含む) に返され、その後、トランザクションはアドレス DESTINATION への出金のためにキューに入れられます。
➤ 一定の遅延（たとえば 1 日）を待った後、出金はバッチおよびインデックス順で処理され、転送はロールアップ A にパッケージ化されます。
➤ Ivan は、自分のアカウント IVAN_A がお金を受け取ったことを知ったら、TRADE_VALUE * (1 - 手数料) トークンを個人的に DESTINATION に送信できます。これを行うには、IVAN_B メソッドを使用してトランザクションを送信します。このメソッドは記録を保持し、契約内の自動送信条項によってトランザクションがトリガーされるのを防ぎます。
期待される動作は単純です。
➤ アリスはトランザクションをアカウント IVAN_A に送信します (N 個のトークンとメモ ALICE_B が含まれます)
➤ Ivan は、TRADE_VALUE * (1 - 料金) トークンを IVAN_B 経由で ALICE_B に送信します
2 番目のトランザクションは、最初のトランザクションの直後に発生します。最初のトランザクションと 2 番目のトランザクションのタイムスタンプの違いが非常に小さいことを Ivan が証明できれば、契約には料金の引き上げを許可するルールさえ含まれます。
最初のレベルのタイトル
資本コスト
このスキームの主な制限は、すべてのトランザクション送信者に支払いを確実に行うために、IVAN_B が大量の資金を保持する必要があることです。特に、次のような状況が発生すると想定します。
➤ トランザクションの上限を TRADE_LIMIT に設定します（したがって、IVAN_A に送信されたトランザクションが制限値 > TRADE_LIMIT を超えると、トランザクションは無効になります）
➤ 各ロールアップ・バッチには最大 TXS_PER_BATCH トランザクションを含めることができます
アリスは、ロールアップ A の次のトランザクション バッチを処理する必要があるまでに、未処理のトランザクションがどれだけ残っているかを自分で確認し、契約 IVAN_B の資金からこれらのトランザクションの合計額を差し引き、残りの金額が十分であるかどうかを確認できます。出金は順番に処理されるため (これが上記のキューイングメカニズムの目的です)、アリスは出金トランザクションリクエストを処理する前にコントラクトが他の出金リクエストを処理していることを心配する必要がありません。
各バッチの最大トランザクション サイズは TRADE_LIMIT * TXS_PER_BATCH であるため、IVAN_B コントラクトには少なくともこれに相当する量の ETH が必要であり、さらに、処理用のトランザクションを含めるために追加の資金が必要です。たとえば、トランザクション制限が 0.1 ETH TRADE_LIMIT = 0.1 ETH (大きなトランザクションはいくつかの小さなトランザクションに分割できるため、トランザクション制限は比較的低く設定できます) で、各バッチは 1000 個のトランザクション TXS_PER_BATCH = 1000 を処理できるとします。次に、コントラクト IVAN_B は 100 ETH を保持する必要があります。
0.1 ETH を超える取引を行うユーザーはブロック スペースを無駄にする必要があるため、この設計では暗黙の料金も発生することに注意してください。これは資本要件と比較検討されます。つまり、ユーザーがブロックスペースの半分を消費した場合、資本要件は 2 倍になり、その逆も同様です。適切なバランスを取りたい場合、暗黙の手数料は市場での明示的な手数料よりも数倍低くなります。
最初のレベルのタイトル
述べる
上記の設計は仮定に基づいています。ロールアップ A のトランザクションにはコメント フィールドがあり、アリスはそれを通じてトークンを受信する宛先アドレスとして ALICE_B を指定できます。ロールアップにこの機能がない場合は、次の解決策を使用できます。アリスは、ロールアップ B で順次登録された契約にアカウント ALICE_B を登録し、順次割り当てられる ID を取得できます (したがって、アリスの ID は、彼女の前に登録されているユーザーの数と等しくなります)。
最初のレベルのタイトル
ロールアップ B からロールアップ A へのトランザクション
アリスがトークンをロールアップ B からロールアップ A に転送する場合、同じメカニズムを使用できますが、役割が逆になります。
➤ アリスはトークンを IVAN_B に送信します
➤ しばらく遅れてから、彼女にはトークンを取り戻す権利が与えられます。
ECN の翻訳作業は、中国のイーサリアム コミュニティに高品質の情報と学習リソースを提供することを目的としています。記事の著作権は原著者に帰属し、転載する場合は原文の出典と ETH 中国の Web サイトを表示する必要があります。長期にわたって再版する場合は、eth@ecn.co に連絡して許可を取得してください。
「原文を読む」をクリックすると記事の内部リンクが表示されます！
元のリンク:https://ethresear.ch/
ECN の翻訳作業は、中国のイーサリアム コミュニティに高品質の情報と学習リソースを提供することを目的としています。記事の著作権は原著者に帰属し、転載する場合は原文の出典と ETH 中国の Web サイトを表示する必要があります。長期にわたって再版する場合は、eth@ecn.co に連絡して許可を取得してください。
