メインコンテンツへスキップ

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: アカウント署名の閲覧を許可します
use ephemeral_rollups_sdk::access_control::structs::{
    Member,
    AUTHORITY_FLAG,
    TX_LOGS_FLAG,
    TX_BALANCES_FLAG,
    TX_MESSAGE_FLAG,
    ACCOUNT_SIGNATURES_FLAG,
};

// Set flags by combining them with bitwise OR
let flags = AUTHORITY_FLAG | TX_LOGS_FLAG;

// Create a member with combined flags
let mut member = Member {
    flags,
    pubkey: user_pubkey,
};

// Check if member has a specific flag using bitwise AND
let is_authority = (member.flags & AUTHORITY_FLAG) != 0;
let can_see_logs = (member.flags & TX_LOGS_FLAG) != 0;

// Use helper methods to set/remove flags
member.set_flags(TX_BALANCES_FLAG); // Add a flag
member.remove_flags(TX_LOGS_FLAG);  // Remove a flag

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 からレントを支払います。
use ephemeral_rollups_sdk::access_control::{
    instructions::CreateEphemeralPermissionCpi,
    structs::{EphemeralMembersArgs, Member},
};

// Counter PDA pays for its own permission rent (it carries lamports onto the ER
// after delegation and signs as PDA via seeds).
let signers = [
    COUNTER_SEED,
    ctx.accounts.counter.authority.as_ref(),
    &[ctx.bumps.counter],
];

CreateEphemeralPermissionCpi {
    payer: ctx.accounts.counter.to_account_info(),                  // pays ephemeral rent
    permissioned_account: ctx.accounts.counter.to_account_info(),   // what the permission gates
    permission: ctx.accounts.permission.to_account_info(),
    vault: ctx.accounts.ephemeral_vault.to_account_info(),
    magic_program: ctx.accounts.magic_program.to_account_info(),
    permission_program: ctx.accounts.permission_program.to_account_info(),
    args: EphemeralMembersArgs {
        is_private: false,    // start public — flip via UpdateEphemeralPermission
        members: vec![],
    },
}
.invoke_signed(&[&signers])?;
ユースケース:
  • ER 上で新たに委任された PDA のアクセス制御をブートストラップ
  • 公開状態(is_private: false、メンバー空)で開始し、後で Update により絞り込む
⬆️ トップに戻る
参考実装: private-counter (Anchor)と pinocchio-private-counter

ベストプラクティス

  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 を変更できるのは所有者だけです
  • アクセス監査: メンバーフラグを使ってアクセスを監査・制御します

アクセス制御

きめ細かなアクセス制御

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

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

認可

認可フレームワーク

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

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