Layer 2はどのように迅速な引き出しを実現するのか？「条件付き取引」について知っておこう。

この記事はEthereum愛好者に掲載され、著者：Starkware、翻訳：阿剣。

この記事は、StarkEXが迅速な引き出し（Fast Withdrawal）（Layer-2から任意のLayer-1アドレスへの引き出しを1ブロック時間内で行う）をサポートするために提案した解決策を説明することを目的としています。このソリューションの利点は、その速度がL2のオペレーターが有効性証明を生成する速度とは完全に独立していることです。

迅速な引き出しモジュールは、EthereumメインネットのStarkEx上で稼働しており（2020年10月のStarkEx 2.0のリリース以降）、DeversiFi取引所とdYdX取引所に力を与えています。

以下で説明するソリューションは、迅速な引き出し以外にも非常に多くの使用シーンがあります。まず、ニーズが何であるかを理解しましょう。

ニーズ

ブロックチェーンは、二者間の信頼不要の相互作用を可能にします。アリスは、特定の条件が満たされたときのみ実行される取引を発行したいと考えています。ボブは、条件が満たされたときにアリスの取引を直接実行できることを望んでおり、再度アリスの許可を得る必要はありません。このような相互作用モデルをサポートするコンポーネントを「条件付き取引（Conditional Transaction、CT）」と呼びます。

L1上でCTを実現するには特別なアイデアは必要ありません。スマートコントラクトが時間と取引実行の結合を保証できるからです。しかし、L2で実現することを求めると、いくつかの課題があります。たとえば、StarkExでは、取引の発起人が署名した後、取引をオペレーターに渡し、オペレーターがその取引を実行する責任がありますが、必要な条件が満たされる前にオペレーターがその取引を実行するのをどうやって防ぐのでしょうか？

この記事では、L2でL1イベント（記号としてL2 | L1）に依存するCTの実現に焦点を当てます。つまり、このCTは、オペレーターが特定のチェーン上のイベントが発生した後にのみ署名された取引を実行できることを保証する必要があります。さらに、別のL2のイベント（記号としてL21 | L22）に依存するCTを追加し、StarkExインスタンス間およびStarkNet内の相互運用性をサポートします。

次に、このチェーン上のイベントの概念を形式化し、StarkExのCTがどのようにそれを利用するかを見ていきましょう。

条件付き取引の概要

チェーン上のイベントの登録

CTは、チェーン上のイベントを追跡するためにFact Registryコントラクトを使用します。実際には、Fact Registryコントラクトに登録されたイベントのみがCTを「解除」することができます。たとえば、アリスがEthereumチェーン上でボブに1 ETHを直接送金した場合（Fact Registryコントラクトを介さずに）、CTはそのために実行前提を満たすことはできません。

上記のケースでは、Fact Registryコントラクトにはtransfer()という関数が必要で、アリスはボブのアドレスを受取人として渡します。transfer()関数は2つのことを行います：（1）転送するETHを受取人に送信する；（2）この送金の記録を保存します。たとえば、送信者、受取人、金額に関連するパラメータのハッシュ値をコントラクトのストレージ項目に保存します。Fact RegistryコントラクトにはisValid()という関数もあり、ハッシュ値を引数として受け取り、ブール値を返します ------ 入力されたハッシュ値がコントラクト内に記録されたハッシュ値と等しい場合、Trueを返します。このように、コントラクト内のハッシュ値は、事実（あるイベントが発生したこと）の証明として扱うことができます。このFact Registryコントラクトに新しい事実を導入するプロセスは、通常「事実登録」と呼ばれます。

署名されたCTに含まれるチェーン上のイベントのフィンガープリンツには2つのフィールドがあります（実際にはこれら2つのパラメータのハッシュ値）：（1）Fact Registryコントラクトのアドレス；（2）上記のコントラクトに記録されるべき事実。

StarkExの条件付き取引

StarkExは、Layer-2内の取引をバッチ処理し、これらの取引を決済するためにチェーン上に送信されるSTARK証明を使用します。バッチ内にCTが含まれている場合、StarkExは関連する事実が登録されていることを保証し、そのバッチの取引を清算できるようにします。そうでない場合、バッチ全体がロールバックされます。

条件付き取引のケーススタディ

このセクションでは、いくつかのアプリケーションシーンを提案し、CTがこれらのシーンでどのように使用できるかを示します。

詳細なケース ------ 迅速な引き出し

任意のL2ソリューションにおいて、L2からL1に資金を引き出す最も基本的な方法は、L2の状態更新を一度確定させることです（この更新には引き出し取引が含まれます）。有効性証明に基づくシステム（たとえばStarkEx）では、L2の状態更新を確定させるには、チェーン上に対応する（この更新に関連する）有効性証明を提出する必要があり、一般的には10分かかります。つまり、ユーザーがこの方法で引き出しを行う場合、少なくとも10分待たなければなりません。

迅速な引き出しの目的は、この（引き出しがL2の状態更新に依存する）依存関係を切り離し、ユーザーが「ブロック時間」内で信頼不要に資金を引き出せるようにすることです。つまり、通常のEthereumコントラクトを使用するのと同じようにです。

では、具体的なプロセスはどうなっているのでしょうか？アリスがL2からL1に1 ETHを引き出したい場合、アリスはL2上で流動性提供者（LP）に1 ETHを転送するCTに署名します。その条件は、LPがL1上でアリスに1 ETH（手数料を差し引いた額）を転送することです。アリスのCTは、彼女がL1上での送金を受け取った後にのみ実行できるため、彼女は対抗リスクに直面することはありません。

CTを支援する簡易的なFact Registryコントラクトを見てみましょう：

このコントラクトには、2つの機能を持つpayable関数transfer()があります：

1. 特定の数量のETHをあるアドレスに転送する
2. keccack(amount、address、nonce)を登録する

アリスが発行したCTは、keccack(1 ETH, アリス, nonce)がFact Registryに登録された後にのみ実行されます。そして、この事実は、アリスへの1 ETHの送金が発生した後にのみ成功裏に登録されます。アリスは信頼なしに1 ETHを引き出すことができ、全プロセスは彼女の署名と、LPがEthereumチェーン上で行った取引のみに依存します。

さらなるアプリケーションシーン

同様のプロセスは、以下のタイプのイベントをキャッチすることができるため、L2のCTにもさらに多くの用途があります。たとえば：

• ETHの価格が1010 DAIに下がった場合（既知の情報入力サービスを介してチェーン上に登録可能）、アリスはL2で1 ETHを売却し、L1で1000 DAIを受け取りたいと考えています。

• アリスは、ボブがアリスの指定したdApp（たとえばAaveやCompound）に9.5 ETHを預ける限り、L2上でボブに10 ETHを送りたいと考えています。

• アリスは、DeversiFiのL2上でボブに10 ETHを送りたいと考えていますが、ボブがdYdXのL2でアリスのアカウントに9.5 ETHを預ける限りです。

まとめ

CTの最初の用途は迅速な引き出しですが、StarkExのオペレーターはこのコンポーネントを使用して多くの種類のL2-L1相互作用を実現できます。