【完全保存版】MagicBlockのエフェメラル・ロールアップについて（ホワイトペーパー解説）
この記事は、こちらのホワイトペーパーの２.２章を翻訳・編集したものです。
１ エフェメラル・ロールアップとは
ここでは、いろいろな観点から、エフェメラル・ロールアップを見てみましょう。
ちなみに、簡単にいうと、一時利用で使用したいトランザクションを行ってくれるL2です。
１ SVMの利用
エフェメラル・ロールアップは、SVM（Solana Virtual Machine）のアカウント構造と並列処理の能力を活用します。
それによりアプリやゲームの状態をクラスターに分割します。
翻訳者注
これにより、並列処理を行うことができます。
２ アカウントのロック
ユーザーは、1つまたは複数のアカウントをロックします。
そして、その状態を一時的に補助レイヤー（「エフェメラル・ロールアップ」と呼ばれる構成可能な専用のランタイム）に移すことができます。
３ シーケンサーへの権限の委任
このプロセスでは、エフェメラル・ロールアップ内でアカウントを修正する権限がシーケンサーに一時的に委任されます。
もし条件が満たされなかった場合、状態は強制的に元に戻され、L1（レイヤー1）でロックが解除されます。
４ 委任されたアカウントについて
この委任が行われても、オペレーションやトランザクションは委任されたアカウントをベースレイヤー上で読み取り可能なまま利用できます。
翻訳者注
あくまでも「書き込み」ではなく「読み取り」ですね。
５ 委任されていないアカウントについて
委任されていないアカウントは影響を受けず、引き続き修正可能です。
翻訳者注
アカウント毎に委任状況を管理できるのですね。
６ カスタマイズ性
エフェメラル・ロールアップは、取引処理を高スループットかつ低遅延で実行するために、特化したSVMランタイムとして機能します。
また、この専用ランタイムは、ガス代なしのトランザクションや、短いブロックタイム、ティッキングメカニズム（例：Clockworkのような統合されたトランザクションスケジューリングシステム、手数料なしで運用されるもの）などの設定に対応したカスタマイズも可能です。
翻訳者注
この辺りはかなりいいですね。
ブロックタイムを変えられるということは、ゲームのような短い時間での処理が必要なものは、短いブロックタイムを設定すれば良いと思いました。
７ RPCによるルーティング
このプロセス全体はエンドユーザーにとって透明です。
専用のRPCプロバイダーが、ゲームセッション中にトランザクションをベースレイヤーとエフェメラル・ロールアップに並行してルーティングすることができます。
翻訳者注
つまり、ユーザーとしては、単にRPCルーターに送れば、あとはアカウントの状態を判断して、適切な方に送ってくれるのですね。
８ プログラムについて
次の図は、システムの概要を示しています。
プログラムは命令と実行可能なロジックを定義します。
９ 状態について
状態は様々なアカウントで構成されます。
１０ アカウントの使用例
例えば、ゲームの場合、PDA（プログラム派生アカウント）はプレイヤーの位置を表すことができます。
別のアカウントは報酬を分配するための「チェスト」として使われる可能性があります。
翻訳者注
「チェスト」はアイテムが入っている箱のイメージです。
このプログラムは、L1上の既存のプログラム（例：リーダーボード、NFTを発行するためのコントラクト、エネルギーシステムなど）を活用します。
翻訳者注
ここがすごいところですね。
L2用にプログラムを作る必要がありません。
通常のやり方で、Solanaで作ったものを利用するだけです。
２ エフェメラル・ロールアップの流れについて
エフェメラル・ロールアップ（ER）のプロビジョニングと利用に関する手順は以下の通りです。
１ DLPとの通信
プログラムがデリゲーションプログラム（DLP）と通信します。
エフェメラル・ロールアップのプロビジョンをリクエストするトランザクションを開始します。
このリクエストには、ERの有効期間、ベースレイヤーの更新頻度、ターゲットとする秒間トランザクション数、ブロックタイムなどの設定が含まれます。
２ プロビジョナーによる検知⇨ランタイムの起動
デリゲーションプログラムを監視しているプロビジョナーがプロビジョンリクエストを検知し、設定に基づいて対応するランタイムを迅速に起動します。
３ 権限の委任
プログラムはアカウントをDLPに委任し、状態の更新と決済の権限を与えます。
この時点から、委任されたアカウントはER内でのみ更新可能となります。
この3番目のステップは、2番目のステップと並行して、あるいはそれ以前に行うことも可能です。
４ RPCルーターの利用
RPC経由でトランザクションを実行したりデータを取得したいクライアントは、トランザクションをRPCルーターに送信します。
このルーターは、トランザクションに含まれるアカウントに基づいて、ベースレイヤーまたはERのいずれかにトランザクションを転送します。
５ シーケンサーによる状態の更新
定期的に、またはER終了時に、シーケンサーがベースレイヤー上で状態を更新します。
６ 終了時の処理
ERが終了すると（またはゲームプログラムがその終了を強制した場合）、アカウントの制御は元のプログラムに戻ります。
そして、プロビジョナーがERを終了させます。
３ エフェメラル・ロールアップの利点の概要
１ Solanaチェーン上での存在
エフェメラル・ロールアップ（ER）の利点は、プログラムと資産がベースレイヤーに直接存在することです。
翻訳者注
あくまでも、プログラムはエフェメラル・ロールアップ（ER）ではなく、Solanaチェーンに存在するのですね。
２ SVMとの完全互換性
ERを通じてトランザクションが加速され、これらはSVM（Solana Virtual Machine）とバイトコードレベルで完全に互換性があります。
ベースレイヤーでの改善や進化は、プログラムを変更したり再デプロイすることなく、すぐに利用可能です。
翻訳者注
完全にSVMと互換性があるからですね。
solanaチェーンでできることは、エフェメラル・ロールアップでもできます。
４ エフェメラル・ロールアップの具体的な利点
１ Solanaチェーンでのデプロイ
開発者はプログラムをベースレイヤーにデプロイします（例：Solana）。
通常のロールアップでは別のチェーンにデプロイする必要があります。
しかし、ERではベースレイヤー上にプログラムが存在し、既存のプロトコルや資産と相互作用できます。
ERは既存のエコシステムを分断せず、ターゲットとする操作を高速化しながら、隔離された環境を作りません。
翻訳者注
「隔離された環境を作りません」と言っているのは、他のL2のように、完全に分断されていないということを表していると思います。
２ Solanaのインフラの活用
ERを使用するユーザー、開発者、プログラムはSolanaのインフラを活用できます。
これには、プログラミング言語、コードライブラリ、テストツール、クライアントソフトウェア、デプロイインフラなどが含まれます。
３ 特化されたランタイム
特化されたランタイムは、ゲームに特化したカスタマイズをサポートします（例：ティッキングやパッシブイベント。これらはブロックチェーンのイベント駆動型ランタイムとは異なり、ゲームに特有のものです）。
これにより、特定のアカウントに対してガス料金を支払う必要がありません。
４ 水平スケーリング
このアプローチにより、数百万件のトランザクションを行うユーザーに対応可能な、水平スケーリングを実現します。
従来のL2（レイヤー2）のようなトレードオフを伴うことなく、オンデマンドでロールアップを起動し、自動的にスケールします。
エフェメラル・ロールアップは、FOC（Full Ownership Control）ゲームをスケールさせ、ベースレイヤー上での相互運用性を損なうことなく拡張できます。
５ 状態の読み取りと更新について
１ 状態の保持
前のセクションで述べたように、状態はアカウント内で保持されます。
これらのアカウントは、ベースレイヤーとエフェメラル・ロールアップ（ER）の両方で同時に存在できます。
２ 状態の更新
アカウントは両方のレイヤーから読み取り可能ですが、ベースレイヤーまたはERのいずれかで修正されます。
ユーザーやクライアントがアカウントからデータを取得しようとする場合、最新のデータや更新されたデータがER内にある可能性があり、まだベースレイヤーに反映されていないことがあります。
翻訳者注
ここ、大事ですね。
整合性が取れていない場合の話です。
３ ERを使用した場合の遅延時間
例えば、ゲームクライアントがWebSocket接続を使って他のプレイヤーの位置をマップ上に表示するシナリオを考えてみましょう。
この場合、位置PDAがERに委任されていれば、WebSocket接続を通じてERのトランザクションをリアルタイムで観察し、ストリーミングすることが可能です。
この際の遅延やブロックタイムは、通常のマルチプレイヤーゲームサーバーと同等で、10〜100ミリ秒程度です。
４ データ分岐に使われるRPCルータ
どこにトランザクションを送信するか、どこからデータを取得するかを判断する複雑さは、RPCルーターを使うことで抽象化されます。
クライアントは従来のRPCと同じように、RPCルーターにトランザクションを送信したり、データを取得したりすることができます。
RPCルーターは、関わるアカウントに基づいて、トランザクションや接続をベースレイヤーまたはER RPCに転送します。
次のシナリオを考えてみましょう。
４ー１ RPCの挙動① 状態を読み取る場合
リクエストがERに委任されたアカウントにアクセスする場合、RPCルーターはそのリクエストをERのRPCに中継します。
それ以外の場合は、ベースレイヤーのRPCがリクエストを処理します。
４ー２ RPCの挙動② トランザクションを送信する場合
トランザクションがベースレイヤーまたはERの読み取り可能なアカウントを含み、すべての書き込み可能なアカウントがERに委任されている場合、そのトランザクションはERのRPCに中継されます。
トランザクションにベースレイヤーまたはERの読み取り可能なアカウントが含まれ、書き込み可能なアカウントが委任されていない場合、そのトランザクションはベースレイヤーのRPCに中継されます。
４ー２ RPCの挙動③ 両方に存在する場合
書き込み可能なアカウントがERとベースレイヤーの両方に存在するトランザクションを処理しようとする場合は、問題が発生します。
この場合には2つの解決策があります。
1つ目は、ベースレイヤーに中間的な決済を強制し、アカウントの委任を解除してベースレイヤーのRPC経由でトランザクションを送信する方法です。
2つ目は、そのトランザクションを無効として破棄する方法です。
どちらの解決策を選ぶかは、ユースケースに依存します。
５ RPCルーターによるブロックハッシュの提供
さらに、RPCルーターはトランザクションに正しいブロックハッシュを提供します。
これは、Solanaがセキュリティを確保し、二重支払いを防ぐための基本的な仕組みです。
翻訳者注
これはどちらかというと、Solanaの基本部分の話ですね。
６ アカウント/プログラムの遅延ロードとデータの可用性
１ 遅延ロードについて
エフェメラル・ロールアップに関する興味深い機能の1つは、トランザクションで使用されるアカウントやプログラムの遅延ロードを実行できる点です。
翻訳者注
日本語だとイメージがつきにくいかもですが、要は必要な時にロードができるというニュアンスだと思います。
「Lazy ミント」なども、まずはメタデータなどを設定して、後からミントを行うことでした。
もしトランザクションが、メインレイヤーの一部である状態やプログラム（ロジック）にアクセスする場合、ERは必要に応じてアカウントの状態をクローンできます。
この時、メインチェーン全体を複製する必要はありません。
２ データの可用性について
トランザクションは特定の時間枠で利用可能です。
翻訳者注
ややこしいですが、ERが起動している間のみということですね。
Solanaの圧縮アカウントや、Celestiaのような外部のDA（データアベイラビリティ）レイヤーに無期限に保存されることもあります。
トランザクションは、エフェメラル・ロールアップが終了した後も持続し、実行された計算の正確性を検証しやすくなります。
翻訳者注
つまり、利用はできないものの、保持されてはいるので、検証は可能ということですね。
以上です。
サポートをしていただけたらすごく嬉しいです😄 いただけたサポートを励みに、これからもコツコツ頑張っていきます😊