Skip to main content

Permission Program

オンチェーン権限管理(近日公開)

Ephemeral Rollups SDK

Private Ephemeral Rollups 向け SDK

概要

Private Ephemeral Rollups は、コンプライアンスを中核に据えた Trusted Execution Environment 上で、permissioned accounts に対するきめ細かな権限制御を可能にする Ephemeral Rollups です。各 permission account は、メンバー一覧と、それぞれが実行できる操作を決める特定のフラグを保持します。

基本概念

  • Permission Account: 特定のアカウントに対するアクセス制御ルールを保存する PDA
  • Members: フラグを通じて特定の権限を付与されたアドレス
  • Flags: メンバーが何をできるか(authority、ログ閲覧、残高閲覧など)を定義するビットマスク
  • Public Permissions: メンバーが None に設定されると、permissioned account は一時的に可視状態になる

メンバーフラグ

メンバーフラグは、各メンバーに対するきめ細かな権限を定義します。フラグはビット OR で組み合わせることで、複数の権限を付与できます。 フラグの説明:
  • AUTHORITY: 権限設定の更新・委任、他メンバーの追加・削除、メンバーフラグの更新を許可します。
  • TX_LOGS: トランザクション実行ログの閲覧を許可します。
  • TX_BALANCES: アカウント残高の変化の閲覧を許可します。
  • TX_MESSAGE: トランザクションメッセージデータの閲覧を許可します。
  • ACCOUNT_SIGNATURES: アカウント署名の閲覧を許可します

Ephemeral Permission

EphemeralPermission アカウントは Ephemeral Rollup 上で完結し、レントは委任済みの PDA が負担します — Base Layer に permission account を作成・委任・commit-and-undelegate する必要はありません。ライフサイクル全体は CreateUpdateClose の 3 つの CPI 操作でカバーされ、すべて ER 上のデータアカウントが PDA として署名し、 MagicBlock の Permission Program ACLseoPoyC3cBqoUtkbjZ4aDrkurZW86v19pXz2XQnp1 経由で実行されます。
前提条件 — データ PDA を委任する。 委任されるのはデータアカウントのみです (Base Layer 上で、MagicBlock の Delegation Program DELeGGvXpWV2fqJUhqcF5ZSYMS4JTLjteaAMARRSaeSh 経由)。委任後、PDA は自身のプログラム シードを使って ER 上で 3 つの permission 操作すべてに署名し、ephemeral permission の レントを支払います — そのため initialize 時に事前にチャージしておく必要があります。 エンドツーエンドの流れは クイックスタート を参照してください。

これらの公開バリデータは開発用として利用できます。委任命令には、 対象となる ER バリデータを必ず追加してください。

メインネット
  • アジア (as.magicblock.app): MAS1Dt9qreoRMQ14YQuhg8UTZMMzDdKhmkZMECCzk57
  • EU (eu.magicblock.app): MEUGGrYPxKk17hCr7wpT6s8dtNokZj5U2L57vjYMS8e
  • 米国 (us.magicblock.app): MUS3hc9TCw4cGC12vHNoYcCGzJG1txjgQLZWVoeNHNd
  • TEE (mainnet-tee.magicblock.app): MTEWGuqxUpYZGFJQcp8tLN7x5v9BSeoFHYWQQ3n3xzo
Devnet
  • アジア (devnet-as.magicblock.app): MAS1Dt9qreoRMQ14YQuhg8UTZMMzDdKhmkZMECCzk57
  • EU (devnet-eu.magicblock.app): MEUGGrYPxKk17hCr7wpT6s8dtNokZj5U2L57vjYMS8e
  • 米国 (devnet-us.magicblock.app): MUS3hc9TCw4cGC12vHNoYcCGzJG1txjgQLZWVoeNHNd
  • TEE (devnet-tee.magicblock.app): MTEWGuqxUpYZGFJQcp8tLN7x5v9BSeoFHYWQQ3n3xzo
ローカルネット
  • ローカル ER (localhost:7799): mAGicPQYBMvcYveUZA5F5UNNwyHvfYh5xkLS2Fr1mev
1

Ephemeral Permission を作成

初期メンバーとプライバシーフラグを指定して、ER 上に新しい EphemeralPermission アカウントを初期化します。べき等 — 既に存在する場合はスキップします。
2

Ephemeral Permission を更新

プライバシーフラグの切り替え、またはメンバーの追加 / 削除 / フラグ変更を行います。 更新は ER 上で即座に反映されます。
3

Ephemeral Permission を閉じる

permission が不要になった時点で、ER 上の EphemeralPermission アカウントを閉じ、 レントをデータ PDA に返金します。

Ephemeral Permission 操作

CreateEphemeralPermissionCpi を使って ER 上に新しい EphemeralPermission アカウントを初期化します。Payer は委任済みのデータ PDA で、自身のプログラムシードで 署名し、initialize 時に事前チャージされた lamports からレントを支払います。
ユースケース:
  • ER 上で新たに委任された PDA のアクセス制御をブートストラップ
  • 公開状態(is_private: false、メンバー空)で開始し、後で Update により絞り込む
⬆️ トップに戻る
参考実装: private-counter/anchor (Anchor)と private-counter/pinocchio

ベストプラクティス

  1. Authority 管理: 常に少なくとも 1 人の信頼できるメンバーに AUTHORITY_FLAG を割り当てる
  2. 最小権限: 各メンバーには必要なフラグだけを付与する
  3. リアルタイム更新: permission は委任解除せずに Private Ephemeral Rollup 上でリアルタイム更新でき、動的なアクセス制御調整が可能
  4. クリーンアップ: 未使用の permission accounts を委任解除して閉じ、SOL を解放する

セキュリティ上の考慮事項

  • 署名者の検証: AUTHORITY_FLAG を持つメンバー、または permissioned account を持つプログラムだけが変更を認可できます
  • 公開アカウント: メンバーを None に設定すると、アカウントは公開可視状態になります
  • デフォルト Authority: デフォルトでは、permissioned account の所有者が permission account の members に permission authority として追加されます
  • 空のメンバー一覧: members フィールドが空リストに設定されると、permissioned account は完全に制限されて非公開になります。permission を変更できるのは所有者だけです
  • アクセス監査: メンバーフラグを使ってアクセスを監査・制御します

アクセス制御

きめ細かなアクセス制御

オンチェーンプライバシー

プライバシーの仕組みと概念

認可

認可フレームワーク

コンプライアンスフレームワーク

コンプライアンス基準とガイドライン