著者: imToken Labs、ChiHaoLu 著
この記事では主に、zkSync のレイヤー 2 ソリューションにおける抽象アカウント (AA、抽象アカウント) の開発と関連コンテンツを紹介します。次の 3 つの部分に焦点を当てます。
目次
背景
ここでは、読みやすくするために、zkSync を深く理解する必要はありませんが、zkSync の基本情報を簡単に復習します。 zkSync には、バージョン 1.0 (zkSync Lite) とバージョン 2.0 (zkSync Era) の 2 つの主要なバージョンがあります。
zkSync バージョン 1.0 は EOA (外部アカウント) のみをサポートし、スマート コントラクトはサポートしません (トークンの転送と交換のみをサポートします)。zkSync 2.0、つまり zkSync Era はネイティブ AA (抽象アカウント) に属します (すべてのアカウント タイプはコントラクトであり、EOA はありません) 、イーサリアムにおけるEOAとコントラクトアカウントの違い）、EVM（イーサリアム仮想マシン）と互換性があり、Rust、Yul、Vyper、Solidityなどを使用したスマートコントラクトの開発をサポートします。
以下で言及する zkSync は、特に指定がない限り、zkSync 2.0、つまり zkSync Era を指します。
zkSync 時代には複数のコントラクトがあり、これらはスマート コントラクトで zkSync のいくつかの重要なオペレーティング システム機能を実装していると理解できます。これらのコントラクトは、一度もデプロイされていない (ノード内で直接実行される) 事前にコンパイルされたコントラクトですが、すべて正式なアドレスを持っています。
AAプロトコルを実装する際、zkSyncはいくつかのコントラクトを介して論理演算や判定を行うことになりますが、例えば、nonceの検証はNonceHolderによって判定され、抽象アカウント機構の実装や料金徴収はブートローダによって判定されます。それらを一つずつ。
アカウントの抽象化の要約
アカウント抽象化の中核となる概念は、署名の抽象化と支払いの抽象化という 2 つの重要な点に要約できます。
署名抽象化の目的は、さまざまなアカウント契約で異なる検証スキームを使用できるようにすることです。これは、ユーザーが特定の曲線のみを使用できるデジタル署名アルゴリズムに限定されず、好みの検証メカニズムを選択できることを意味します。
支払いの抽象化は、ユーザーにさまざまなトランザクション支払いオプションを提供することを目的としています。たとえば、ネイティブ トークンの代わりに ERC-20 トークンを使用して支払いを行ったり、サードパーティやその他のよりアドホックな支払いモデルによってトランザクションをスポンサーしたりすることができます。
zkSync 2.0 のアカウントは EOA などのトランザクションを開始できますが、そのプログラム機能を利用して契約アカウントなどの任意のロジックを実装することもできます。これは、私たちがアカウント抽象化と呼んでいるもので、イーサリアムの 2 種類のアカウントの利点を組み合わせて、AA アカウントの使用体験をより柔軟にし、上記の 2 つの目標、署名の抽象化と支払いの抽象化を達成します。
zkSync 時代の AA メカニズム
zkSync時代では、zkSync AAの最も重要な役割はブートローダーです。これは主にトランザクションを処理し、EIP-4337のEntryPointコントラクトに対応するAAメカニズムを実行するために使用されるコントラクトです。ブートローダーはユーザーが呼び出すことはできず (オペレーターによってのみトリガーできます)、デプロイされたことはありません (ノード上で直接実行されます)。しかし、正式なアドレスがあります (支払いの受け取りに使用できます)。
Operator は ZK Rollup で重要な役割を果たします。これは集中化されたオフチェーン サーバーであり、見たことがあるかもしれない Sequencer と同様に、外部からブートローダーなどのコントラクトをトリガーする役割を果たします。
ネイティブ アカウント抽象化プロトコル (StarkNet、zkSync など) は基本的に EIP-4337 を参照して設計されており、zkSync の実装では、ユーザーはトランザクションを Operator に送信し、Operator はトランザクションをブートローダーに送信して、一連の加工。
ブロックの観点から見ると、次のようになります。
ブートローダーがオペレーターから入力を受け取ると、ブートローダーはまずブロックのいくつかの環境変数 (ガス価格、ブロック番号、ブロックのタイムスタンプなど) を定義します。次に、ブートローダーはトランザクション リストを順番に読み取り、最初にアカウント コントラクトがトランザクションに一致するかどうかをクエリし (つまり、AA メカニズムの validate 関数を呼び出し)、次にそれらをブロックに入れます。
各トランザクションが検証された後、オペレーターはブロックが検証者に送信できるほど大きいかどうか (またはタイムアウトするかどうか) を検証します。それが十分に大きい場合、またはタイムアウトした場合、オペレーターはブロックを閉じ、ブートローダーへの新しいトランザクションの追加を停止し、トランザクションの実行を完了します。
トランザクションの観点から見ると、Operator がブートローダーをトリガーすると、ブートローダーは各トランザクションを順番に処理します。
上記の最初の 3 つのステップは EIP-4337 の検証ループ (Verification Loop) に対応し、4 番目のステップは EIP-4337 の実行ループ (ution Loop) に対応します。
ここでは主に概要を紹介し、各ステップの詳細と役割については、以下の詳細な説明で 1 つずつ詳しく説明します。
zkSync 抽象アカウント契約の概要
ノンス
zkSync のアカウント nonce は、nonceHolder という名前のシステム コントラクトに記録されます。このコントラクトは、各 (account_address, nonce) のペアがマッピング (マッピング) によって nonce が正当であるかどうかを判断するために使用されるかどうかを記憶します。
上記によれば、オペレーターがブートローダーをトリガーした後の最初のステップは nonce をチェックすることです。したがって、各トランザクションが開始される前に、NonceHolder を使用して、現在使用されている nonce のセットが正当であるかどうかを確認します (現在は、それらが使用されているかどうかのみを確認します)。 nonce が正当な場合、検証フェーズ (検証フェーズ) に入り、その時点で nonce は使用済みとしてマークされますが、nonce が正当でない場合、トランザクション (検証) は失敗します。
zkSync の現在の nonce に関する重要な点:
現在、ユーザーは異なるノンスを持つ複数のトランザクションを同時にアカウントに送信して実行できますが、zkSync は並列処理をサポートしていないため、異なるノンスを持つトランザクションは引き続き順次処理されます。
理論上、ユーザーは任意の 256 ビットのゼロ以外の整数をノンスとして使用できますが、zkSync は依然として、ノンスが順番にインクリメントされるようにノンスを管理する方法として、incrementNonceIfEquals を使用することを推奨しています (現在、zkSync の AA メカニズムは未使用のノンスを確認するだけですが、公式文書には、将来的には順次増分が必要になる可能性があることが示されています)。
アカウント契約
zkSync のアカウント コントラクトには、次の 4 つの必要なエントリ ポイント (エントリ ポイント) があります。
Paymaster については、手数料額（tx.gasprice * tx.gaslimit）などについては後章で説明します。
zkSync のアカウントには、必須ではない保険関数 uteTransactionFromOutside もあります。操作を実行できない場合（シーケンスジェネレーターが応答しない場合、または zkSync が規制上のリスクであることが判明した場合など）、「エスケープメカニズム」を使用して資金を L1 に引き出すことができます。この部分はAAプロトコルとはあまり関係ないのでここでは詳しく説明しませんが、興味のある方は公式ドキュメントやzkSyncの仕様を確認してください。
検証機能の重要な点と制限事項
validateTransaction 関数では、さまざまなカスタム ロジックを実装できます。たとえば、アカウントが EIP-1271 標準を実装している場合、EIP-1271 の検証ロジックを validateTransaction に直接適用したり、マルチシグネチャ アカウント コントラクトを参照したりできます。 zkSync 公式ドキュメントの実装。
同時に、EIP-4337 の検証フェーズで DoS 脅威を回避するために、いくつかの制限があり (外部オペコードを使用できない、深度が制限されているなど)、zkSync にも同様の制限があります。たとえば、次のとおりです。
1. コントラクト ロジックは、自身のスロットのみにアクセスできます (アカウント コントラクトのアドレスが A の場合):
アドレス A に属するスロット
他のアドレスのスロット A
他のアドレスのスロット keccak256(A||X) は、そのアドレスをマッピング (address=>value) などのキーとして直接使用できますが、スロット keccak256( A||X)、拡張を実現します。たとえば、ERC-20 のトークン残高。
2. コントラクト ロジックでは、block.number などのグローバル変数を使用してはなりません
関数実行のキーポイントと制限事項
uteTransaction 関数で注意する必要があるのは、システム コール (Call) を実行する場合は、is フラグがあることを確認する必要があることです。これらのシステム コントラクトはアカウント システムに大きな影響を与えるためです。たとえば、nonce を増やす唯一の方法は、NonceHolder と対話することです。コントラクトをデプロイするには、ContractDeployer と対話する必要があります。is フラグを使用すると、アカウント開発者が意識的に対話できるようになります。システム契約あり。
ただし、zkSync が提供する ContractsCaller ライブラリを使用して、is フラグを自分で処理することを避け、CallWithPropagatedRevert を使用してシステム コールを完了することをお勧めします。
上記のコード サンプルには、DEPLOYER__CONTRACT との対話が含まれています。アカウント開発者が遭遇する最も一般的なシステム コントラクトの状況は、アカウントを使用してコントラクトをデプロイすることです。このとき、ContractDeployer システム コントラクトと対話する必要があります。この場合、アカウント開発者は、ContractDeployer コントラクトと通信して、コントラクトが正常にデプロイされ、必要な操作が実行されていることを確認する必要があります。
zkSync時代の料金モデルとPaymaster
料金とガス制限
zkSync の料金モデルはイーサリアムに非常に似ており、料金トークンは依然として ETH です。ただし、他のレイヤー 2 ソリューション (Arbitrum、Optimism など) と同様に、zkSync は、基本的な計算と書き込みスロットのコストに加えて、L1 への公開の追加コスト (セキュリティ料金) も考慮する必要があります。データを L1 に公開するガスの価格は非常に不安定であるため、zkSync のオペレーターは、各ブロックがオープンされる (トランザクションの記録が開始される) ときに次の動的パラメーターを定義します。
gasPrice: gwei のガス価格、つまり、上記のトランザクション オブジェクトの tx.gasprice
gasPerPubdata: イーサリアム上で 1 バイトのデータを公開するために必要なガスの量
さらに、EIP-4337 とは異なり、zkSync は 3 つのガス制限 (verificationGas、utionGas、preVerificationGas) を定義する必要はありませんが、上記のすべてのコストをカバーするのに必要なのは、gasLimit だけです。そのため、ユーザーは、gasLimit がすべてのコストをカバーするのに十分であることを確認する必要があります。検証段階、利用段階、データアップロードセキュリティ料などの費用はすべてL1に負担。この手数料コストは、上記のトランザクション オブジェクトの tx.gaslimit に含まれます。
2 つ (tx.gasprice * tx.gaslimit) を乗算して、ブートローダーに支払われるトランザクション手数料を取得します。
支払主
Paymasterは、ユーザーのトランザクション支払い手数料の段階でユーザーのアカウント契約ではなく、主にブートローダーにETHを支払います。ユーザーは、手数料を支払うために、次のようなさまざまな Paymaster および支払いモードを選択できます (ただし、これらに限定されません)。
トランザクションの開始前またはトランザクションの実行後の Paymaster への ERC-20 トークンの支払い
Paymaster 契約にクレジット カードでチャージする
Paymaster は引き続きユーザーの料金の一部または全額を無料で支払います
ユーザーが Paymaster と対話する方法はさまざまなプロトコルに依存し、集中型または分散型、トランザクションの前後で行うことができ、ERC-20 トークンや法定通貨を使用したり、無料で使用したりすることもできます。
zkSync の Paymaster コントラクトは主に 2 つの関数、つまり validateAndPayForPaymasterTransaction (必須) と postTransaction (オプション) で構成されており、どちらもブートローダーによってのみ呼び出すことができます。
validateAndPayForPaymasterTransaction は、Paymaster 契約全体で実装する必要がある唯一の関数です。オペレーターが Paymaster パラメーターを含むトランザクションを受け取った場合、手数料はユーザーのアカウント契約によってではなく、Paymaster によって支払われることを意味します。この時点で、オペレーターは validateAndPayForPaymasterTransaction を呼び出して、Paymaster が取引手数料を支払う意思があるかどうかを判断します。 Paymaster が同意した場合、この関数は少なくとも tx.gasprice * tx.gaslimit ETH をブートローダーに送信します。
postTransaction はオプションの機能で、通常は返金 (未使用のガスを送り主に返却) に使用されます。ただし、現在の zkSync はまだこの操作をサポートしていません。
zkSync の Paymaster は、postTransaction が実装された後に postTransaction を実行しますが、これは EIP-4337 とは異なります。EIP-4337 は、validatePaymasterUserOp がコンテキストを返さない場合、postOp を呼び出しません。また、その逆も同様です。
上記に基づいて、たとえば、ユーザーが手数料を Paymaster が支払うトランザクションを送信したい場合、プロセスは次のようになります。
最後のステップでは、ガス欠エラーにより postTransaction を実行できない場合でも、この AA トランザクションは成功したとみなされますが、postTransaction を呼び出すアクションは省略されます。
zkSync の Paymaster をさらに詳しく調べると、その検証ルールが 4337 とは若干異なることがわかります (zkSync Paymaster は他の契約スロットを踏むことができます)、またさまざまなタイプ (承認ベースなど) があることがわかります。詳細の比較については、公式ドキュメントや私の以前の実装を参照してください。
概要と比較
これまでの説明を通じて、アカウント契約にはどのような重要なエントリポイントがあるのか、またその機能と関連する制限事項が理解できました。同時にシステム契約の機能についても学びました。次に、zkSync の自動化操作 (AA) トランザクションの構築から完了までのプロセスを要約します。さらに詳しく知りたい人のために、より詳細なリファレンスも提供します。
ユーザーは SDK またはウォレットをローカルで使用して、トランザクション オブジェクト (例: from、to、データ、値など) を構築します。
ユーザーはトランザクションに署名します。ここでの署名は、必ずしも従来の EIP-712 形式および ECDSA 曲線署名である必要はありません。 zkSync は EIP-2718 および EIP-1559 もサポートしており、署名方法と検証方法を選択する鍵は、アカウント契約の検証機能を通じて検証することです。
署名されたトランザクションを RPC API 経由でオペレーターに送信します。この時点で、トランザクションは保留状態になります。オペレーターはトランザクションをブートローダーに渡し (ブートローダー コントラクトで processL2Tx 関数を呼び出し)、一連の AA プロトコル プロセスを開始します。
ブートローダーは Nonce が正当であるかどうかをチェックし、NonceHolder を使用してチェックします。
ブートローダーは、ユーザー アカウント コントラクトの validateTransaction 関数を呼び出し、トランザクションがアカウント所有者によって承認されたことを確認します。
ブートローダーが料金を請求するには 2 つの方法があり、具体的な請求方法はトランザクション パラメーター (トランザクション オブジェクトの構築時に paymaster パラメーターが付加されているかどうか) によって異なります。
a. payForTransaction 関数とアカウント コントラクトを呼び出して、取引手数料を請求します。
b. prepareForPaymaster 関数と validateAndPayForPaymasterTransaction 関数を呼び出して、Paymaster 契約で取引手数料を収集します。
「payForTransaction を呼び出してアカウントとの契約料金を取得する」または「prepareForPaymaster を呼び出して validateAndPayForPaymasterTransaction を呼び出して Paymaster との契約料金を取得する」
ブートローダーが少なくとも tx.gasprice * tx.gaslimit のトランザクション料金を受け取っているかどうかを確認します。
ブートローダーは、ユーザー アカウント コントラクトで uteTransaction 関数を呼び出し、トランザクションを実行します。
(オプション) Paymaster を使用して取引手数料を支払う場合、ブートローダーは postTransaction 関数を呼び出します。 Paymaster が postTransaction を実装していない場合、またはガスが枯渇している場合、このステップはスキップされます。
上記の 4. ～ 7. ステップは検証フェーズ (ブートローダーの l2TxValidation で定義) と、8. ～ 9. ステップの実行フェーズ (ブートローダーの l2Txution で定義) です。
EIP-4337、StarkNet、および zkSync 時代の比較
基本的に、3 つの AA メカニズムのプロセスは似ており、いずれも検証段階→手数料メカニズム (アカウント契約またはペイマスターによって支払われる)→実行段階となりますが、主な違いは次のとおりです。
比較
StarkNet は Paymaster メカニズムをまだ実現しておらず、zkSync はガス返金メカニズムの設計をまだ完了していないため、より詳細な比較はここにはリストされていません。
さらに、現在の 4337 バンドラーの P2P メモリプールが完成しており、zkRollups のシーケンサーとオペレーターも唯一の公式サーバーであるため、特定の集中化されたコンポーネントがあります。
開発プロセスにおいて、zkSync にはさまざまなバンドラーとの接続の問題がない (Operator API と対話するだけでよい) ため、4337 の使用が簡単で、アカウント コントラクト (SDK) の開発エクスペリエンスも優れています。同時に、zkSync は契約開発言語として Solidity を使用できるため、StarkNet 開発でカイロの敷居を超える必要はありません。
結論
StarkNet と zkSync は両方ともローカル AA (ネイティブ AA) のカテゴリに属しているため、以前の StarkNet AA の紹介「StarkNet アカウント抽象化の紹介」(StarkNet アカウント抽象化の紹介) も参照してください。また、詳細については、EIP-4337 に関連する他の記事を参照してください。
13k 人気度
18k 人気度
33k 人気度
36k 人気度
zkSync のネイティブ アカウント抽象化の概要
著者: imToken Labs、ChiHaoLu 著
この記事では主に、zkSync のレイヤー 2 ソリューションにおける抽象アカウント (AA、抽象アカウント) の開発と関連コンテンツを紹介します。次の 3 つの部分に焦点を当てます。
目次
背景
ここでは、読みやすくするために、zkSync を深く理解する必要はありませんが、zkSync の基本情報を簡単に復習します。 zkSync には、バージョン 1.0 (zkSync Lite) とバージョン 2.0 (zkSync Era) の 2 つの主要なバージョンがあります。
zkSync バージョン 1.0 は EOA (外部アカウント) のみをサポートし、スマート コントラクトはサポートしません (トークンの転送と交換のみをサポートします)。zkSync 2.0、つまり zkSync Era はネイティブ AA (抽象アカウント) に属します (すべてのアカウント タイプはコントラクトであり、EOA はありません) 、イーサリアムにおけるEOAとコントラクトアカウントの違い）、EVM（イーサリアム仮想マシン）と互換性があり、Rust、Yul、Vyper、Solidityなどを使用したスマートコントラクトの開発をサポートします。
以下で言及する zkSync は、特に指定がない限り、zkSync 2.0、つまり zkSync Era を指します。
zkSync 時代には複数のコントラクトがあり、これらはスマート コントラクトで zkSync のいくつかの重要なオペレーティング システム機能を実装していると理解できます。これらのコントラクトは、一度もデプロイされていない (ノード内で直接実行される) 事前にコンパイルされたコントラクトですが、すべて正式なアドレスを持っています。
AAプロトコルを実装する際、zkSyncはいくつかのコントラクトを介して論理演算や判定を行うことになりますが、例えば、nonceの検証はNonceHolderによって判定され、抽象アカウント機構の実装や料金徴収はブートローダによって判定されます。それらを一つずつ。
アカウントの抽象化の要約
アカウント抽象化の中核となる概念は、署名の抽象化と支払いの抽象化という 2 つの重要な点に要約できます。
署名抽象化の目的は、さまざまなアカウント契約で異なる検証スキームを使用できるようにすることです。これは、ユーザーが特定の曲線のみを使用できるデジタル署名アルゴリズムに限定されず、好みの検証メカニズムを選択できることを意味します。
支払いの抽象化は、ユーザーにさまざまなトランザクション支払いオプションを提供することを目的としています。たとえば、ネイティブ トークンの代わりに ERC-20 トークンを使用して支払いを行ったり、サードパーティやその他のよりアドホックな支払いモデルによってトランザクションをスポンサーしたりすることができます。
zkSync 2.0 のアカウントは EOA などのトランザクションを開始できますが、そのプログラム機能を利用して契約アカウントなどの任意のロジックを実装することもできます。これは、私たちがアカウント抽象化と呼んでいるもので、イーサリアムの 2 種類のアカウントの利点を組み合わせて、AA アカウントの使用体験をより柔軟にし、上記の 2 つの目標、署名の抽象化と支払いの抽象化を達成します。
zkSync 時代の AA メカニズム
zkSync時代では、zkSync AAの最も重要な役割はブートローダーです。これは主にトランザクションを処理し、EIP-4337のEntryPointコントラクトに対応するAAメカニズムを実行するために使用されるコントラクトです。ブートローダーはユーザーが呼び出すことはできず (オペレーターによってのみトリガーできます)、デプロイされたことはありません (ノード上で直接実行されます)。しかし、正式なアドレスがあります (支払いの受け取りに使用できます)。
Operator は ZK Rollup で重要な役割を果たします。これは集中化されたオフチェーン サーバーであり、見たことがあるかもしれない Sequencer と同様に、外部からブートローダーなどのコントラクトをトリガーする役割を果たします。
ネイティブ アカウント抽象化プロトコル (StarkNet、zkSync など) は基本的に EIP-4337 を参照して設計されており、zkSync の実装では、ユーザーはトランザクションを Operator に送信し、Operator はトランザクションをブートローダーに送信して、一連の加工。
ブロックの観点から見ると、次のようになります。
ブートローダーがオペレーターから入力を受け取ると、ブートローダーはまずブロックのいくつかの環境変数 (ガス価格、ブロック番号、ブロックのタイムスタンプなど) を定義します。次に、ブートローダーはトランザクション リストを順番に読み取り、最初にアカウント コントラクトがトランザクションに一致するかどうかをクエリし (つまり、AA メカニズムの validate 関数を呼び出し)、次にそれらをブロックに入れます。
各トランザクションが検証された後、オペレーターはブロックが検証者に送信できるほど大きいかどうか (またはタイムアウトするかどうか) を検証します。それが十分に大きい場合、またはタイムアウトした場合、オペレーターはブロックを閉じ、ブートローダーへの新しいトランザクションの追加を停止し、トランザクションの実行を完了します。
トランザクションの観点から見ると、Operator がブートローダーをトリガーすると、ブートローダーは各トランザクションを順番に処理します。
上記の最初の 3 つのステップは EIP-4337 の検証ループ (Verification Loop) に対応し、4 番目のステップは EIP-4337 の実行ループ (ution Loop) に対応します。
ここでは主に概要を紹介し、各ステップの詳細と役割については、以下の詳細な説明で 1 つずつ詳しく説明します。
zkSync 抽象アカウント契約の概要
ノンス
zkSync のアカウント nonce は、nonceHolder という名前のシステム コントラクトに記録されます。このコントラクトは、各 (account_address, nonce) のペアがマッピング (マッピング) によって nonce が正当であるかどうかを判断するために使用されるかどうかを記憶します。
上記によれば、オペレーターがブートローダーをトリガーした後の最初のステップは nonce をチェックすることです。したがって、各トランザクションが開始される前に、NonceHolder を使用して、現在使用されている nonce のセットが正当であるかどうかを確認します (現在は、それらが使用されているかどうかのみを確認します)。 nonce が正当な場合、検証フェーズ (検証フェーズ) に入り、その時点で nonce は使用済みとしてマークされますが、nonce が正当でない場合、トランザクション (検証) は失敗します。
zkSync の現在の nonce に関する重要な点:
現在、ユーザーは異なるノンスを持つ複数のトランザクションを同時にアカウントに送信して実行できますが、zkSync は並列処理をサポートしていないため、異なるノンスを持つトランザクションは引き続き順次処理されます。
理論上、ユーザーは任意の 256 ビットのゼロ以外の整数をノンスとして使用できますが、zkSync は依然として、ノンスが順番にインクリメントされるようにノンスを管理する方法として、incrementNonceIfEquals を使用することを推奨しています (現在、zkSync の AA メカニズムは未使用のノンスを確認するだけですが、公式文書には、将来的には順次増分が必要になる可能性があることが示されています)。
アカウント契約
zkSync のアカウント コントラクトには、次の 4 つの必要なエントリ ポイント (エントリ ポイント) があります。
Paymaster については、手数料額（tx.gasprice * tx.gaslimit）などについては後章で説明します。
zkSync のアカウントには、必須ではない保険関数 uteTransactionFromOutside もあります。操作を実行できない場合（シーケンスジェネレーターが応答しない場合、または zkSync が規制上のリスクであることが判明した場合など）、「エスケープメカニズム」を使用して資金を L1 に引き出すことができます。この部分はAAプロトコルとはあまり関係ないのでここでは詳しく説明しませんが、興味のある方は公式ドキュメントやzkSyncの仕様を確認してください。
検証機能の重要な点と制限事項
validateTransaction 関数では、さまざまなカスタム ロジックを実装できます。たとえば、アカウントが EIP-1271 標準を実装している場合、EIP-1271 の検証ロジックを validateTransaction に直接適用したり、マルチシグネチャ アカウント コントラクトを参照したりできます。 zkSync 公式ドキュメントの実装。
同時に、EIP-4337 の検証フェーズで DoS 脅威を回避するために、いくつかの制限があり (外部オペコードを使用できない、深度が制限されているなど)、zkSync にも同様の制限があります。たとえば、次のとおりです。
1. コントラクト ロジックは、自身のスロットのみにアクセスできます (アカウント コントラクトのアドレスが A の場合):
アドレス A に属するスロット
他のアドレスのスロット A
他のアドレスのスロット keccak256(A||X) は、そのアドレスをマッピング (address=>value) などのキーとして直接使用できますが、スロット keccak256( A||X)、拡張を実現します。たとえば、ERC-20 のトークン残高。
2. コントラクト ロジックでは、block.number などのグローバル変数を使用してはなりません
関数実行のキーポイントと制限事項
uteTransaction 関数で注意する必要があるのは、システム コール (Call) を実行する場合は、is フラグがあることを確認する必要があることです。これらのシステム コントラクトはアカウント システムに大きな影響を与えるためです。たとえば、nonce を増やす唯一の方法は、NonceHolder と対話することです。コントラクトをデプロイするには、ContractDeployer と対話する必要があります。is フラグを使用すると、アカウント開発者が意識的に対話できるようになります。システム契約あり。
ただし、zkSync が提供する ContractsCaller ライブラリを使用して、is フラグを自分で処理することを避け、CallWithPropagatedRevert を使用してシステム コールを完了することをお勧めします。
上記のコード サンプルには、DEPLOYER__CONTRACT との対話が含まれています。アカウント開発者が遭遇する最も一般的なシステム コントラクトの状況は、アカウントを使用してコントラクトをデプロイすることです。このとき、ContractDeployer システム コントラクトと対話する必要があります。この場合、アカウント開発者は、ContractDeployer コントラクトと通信して、コントラクトが正常にデプロイされ、必要な操作が実行されていることを確認する必要があります。
zkSync時代の料金モデルとPaymaster
料金とガス制限
zkSync の料金モデルはイーサリアムに非常に似ており、料金トークンは依然として ETH です。ただし、他のレイヤー 2 ソリューション (Arbitrum、Optimism など) と同様に、zkSync は、基本的な計算と書き込みスロットのコストに加えて、L1 への公開の追加コスト (セキュリティ料金) も考慮する必要があります。データを L1 に公開するガスの価格は非常に不安定であるため、zkSync のオペレーターは、各ブロックがオープンされる (トランザクションの記録が開始される) ときに次の動的パラメーターを定義します。
gasPrice: gwei のガス価格、つまり、上記のトランザクション オブジェクトの tx.gasprice
gasPerPubdata: イーサリアム上で 1 バイトのデータを公開するために必要なガスの量
さらに、EIP-4337 とは異なり、zkSync は 3 つのガス制限 (verificationGas、utionGas、preVerificationGas) を定義する必要はありませんが、上記のすべてのコストをカバーするのに必要なのは、gasLimit だけです。そのため、ユーザーは、gasLimit がすべてのコストをカバーするのに十分であることを確認する必要があります。検証段階、利用段階、データアップロードセキュリティ料などの費用はすべてL1に負担。この手数料コストは、上記のトランザクション オブジェクトの tx.gaslimit に含まれます。
2 つ (tx.gasprice * tx.gaslimit) を乗算して、ブートローダーに支払われるトランザクション手数料を取得します。
支払主
Paymasterは、ユーザーのトランザクション支払い手数料の段階でユーザーのアカウント契約ではなく、主にブートローダーにETHを支払います。ユーザーは、手数料を支払うために、次のようなさまざまな Paymaster および支払いモードを選択できます (ただし、これらに限定されません)。
トランザクションの開始前またはトランザクションの実行後の Paymaster への ERC-20 トークンの支払い
Paymaster 契約にクレジット カードでチャージする
Paymaster は引き続きユーザーの料金の一部または全額を無料で支払います
ユーザーが Paymaster と対話する方法はさまざまなプロトコルに依存し、集中型または分散型、トランザクションの前後で行うことができ、ERC-20 トークンや法定通貨を使用したり、無料で使用したりすることもできます。
zkSync の Paymaster コントラクトは主に 2 つの関数、つまり validateAndPayForPaymasterTransaction (必須) と postTransaction (オプション) で構成されており、どちらもブートローダーによってのみ呼び出すことができます。
validateAndPayForPaymasterTransaction は、Paymaster 契約全体で実装する必要がある唯一の関数です。オペレーターが Paymaster パラメーターを含むトランザクションを受け取った場合、手数料はユーザーのアカウント契約によってではなく、Paymaster によって支払われることを意味します。この時点で、オペレーターは validateAndPayForPaymasterTransaction を呼び出して、Paymaster が取引手数料を支払う意思があるかどうかを判断します。 Paymaster が同意した場合、この関数は少なくとも tx.gasprice * tx.gaslimit ETH をブートローダーに送信します。
postTransaction はオプションの機能で、通常は返金 (未使用のガスを送り主に返却) に使用されます。ただし、現在の zkSync はまだこの操作をサポートしていません。
zkSync の Paymaster は、postTransaction が実装された後に postTransaction を実行しますが、これは EIP-4337 とは異なります。EIP-4337 は、validatePaymasterUserOp がコンテキストを返さない場合、postOp を呼び出しません。また、その逆も同様です。
上記に基づいて、たとえば、ユーザーが手数料を Paymaster が支払うトランザクションを送信したい場合、プロセスは次のようになります。
最後のステップでは、ガス欠エラーにより postTransaction を実行できない場合でも、この AA トランザクションは成功したとみなされますが、postTransaction を呼び出すアクションは省略されます。
zkSync の Paymaster をさらに詳しく調べると、その検証ルールが 4337 とは若干異なることがわかります (zkSync Paymaster は他の契約スロットを踏むことができます)、またさまざまなタイプ (承認ベースなど) があることがわかります。詳細の比較については、公式ドキュメントや私の以前の実装を参照してください。
概要と比較
これまでの説明を通じて、アカウント契約にはどのような重要なエントリポイントがあるのか、またその機能と関連する制限事項が理解できました。同時にシステム契約の機能についても学びました。次に、zkSync の自動化操作 (AA) トランザクションの構築から完了までのプロセスを要約します。さらに詳しく知りたい人のために、より詳細なリファレンスも提供します。
ユーザーは SDK またはウォレットをローカルで使用して、トランザクション オブジェクト (例: from、to、データ、値など) を構築します。
ユーザーはトランザクションに署名します。ここでの署名は、必ずしも従来の EIP-712 形式および ECDSA 曲線署名である必要はありません。 zkSync は EIP-2718 および EIP-1559 もサポートしており、署名方法と検証方法を選択する鍵は、アカウント契約の検証機能を通じて検証することです。
署名されたトランザクションを RPC API 経由でオペレーターに送信します。この時点で、トランザクションは保留状態になります。オペレーターはトランザクションをブートローダーに渡し (ブートローダー コントラクトで processL2Tx 関数を呼び出し)、一連の AA プロトコル プロセスを開始します。
ブートローダーは Nonce が正当であるかどうかをチェックし、NonceHolder を使用してチェックします。
ブートローダーは、ユーザー アカウント コントラクトの validateTransaction 関数を呼び出し、トランザクションがアカウント所有者によって承認されたことを確認します。
ブートローダーが料金を請求するには 2 つの方法があり、具体的な請求方法はトランザクション パラメーター (トランザクション オブジェクトの構築時に paymaster パラメーターが付加されているかどうか) によって異なります。
a. payForTransaction 関数とアカウント コントラクトを呼び出して、取引手数料を請求します。
b. prepareForPaymaster 関数と validateAndPayForPaymasterTransaction 関数を呼び出して、Paymaster 契約で取引手数料を収集します。
「payForTransaction を呼び出してアカウントとの契約料金を取得する」または「prepareForPaymaster を呼び出して validateAndPayForPaymasterTransaction を呼び出して Paymaster との契約料金を取得する」
ブートローダーが少なくとも tx.gasprice * tx.gaslimit のトランザクション料金を受け取っているかどうかを確認します。
ブートローダーは、ユーザー アカウント コントラクトで uteTransaction 関数を呼び出し、トランザクションを実行します。
(オプション) Paymaster を使用して取引手数料を支払う場合、ブートローダーは postTransaction 関数を呼び出します。 Paymaster が postTransaction を実装していない場合、またはガスが枯渇している場合、このステップはスキップされます。
上記の 4. ～ 7. ステップは検証フェーズ (ブートローダーの l2TxValidation で定義) と、8. ～ 9. ステップの実行フェーズ (ブートローダーの l2Txution で定義) です。
EIP-4337、StarkNet、および zkSync 時代の比較
基本的に、3 つの AA メカニズムのプロセスは似ており、いずれも検証段階→手数料メカニズム (アカウント契約またはペイマスターによって支払われる)→実行段階となりますが、主な違いは次のとおりです。
比較
さらに、現在の 4337 バンドラーの P2P メモリプールが完成しており、zkRollups のシーケンサーとオペレーターも唯一の公式サーバーであるため、特定の集中化されたコンポーネントがあります。
開発プロセスにおいて、zkSync にはさまざまなバンドラーとの接続の問題がない (Operator API と対話するだけでよい) ため、4337 の使用が簡単で、アカウント コントラクト (SDK) の開発エクスペリエンスも優れています。同時に、zkSync は契約開発言語として Solidity を使用できるため、StarkNet 開発でカイロの敷居を超える必要はありません。
結論
StarkNet と zkSync は両方ともローカル AA (ネイティブ AA) のカテゴリに属しているため、以前の StarkNet AA の紹介「StarkNet アカウント抽象化の紹介」(StarkNet アカウント抽象化の紹介) も参照してください。また、詳細については、EIP-4337 に関連する他の記事を参照してください。