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

Documentation Index

Fetch the complete documentation index at: https://docs.magicblock.gg/llms.txt

Use this file to discover all available pages before exploring further.


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

Permission のライフサイクル

permissioned account の典型的なライフサイクルでは、MagicBlock の Permission Program ACLseoPoyC3cBqoUtkbjZ4aDrkurZW86v19pXz2XQnp1 と Delegation Program DELeGGvXpWV2fqJUhqcF5ZSYMS4JTLjteaAMARRSaeSh との連携が必要です。
1

Permission を作成する

初期メンバーとそのフラグを持つ新しい permission account を初期化します。
2

Permission を委任する

Private Ephemeral Rollup に permission を委任し、強制力のあるリアルタイムアクセス制御を有効にします。

これらの公開バリデータは開発用として利用できます。委任命令には、 対象となる 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
3

Permission を更新する

必要に応じてメンバー権限を追加、削除、変更します。更新は Private Ephemeral Rollup 上でリアルタイムに行えます。
4

リクエストを行う

リクエストを行う前に、TEE RPC の完全性を検証し、認可トークンを取得します。適切なフラグを持つメンバーのみがアカウント状態へアクセスまたは変更できます。
5

コミットして委任解除する

最終状態を Solana に同期し、アカウントを Base Layer の制御に戻します。
6

Permission を閉じる

不要になった permission account を閉じて lamports を回収します。

Permission 操作

プログラムを作成したら、permission と delegation のフックを追加してアカウントへのアクセスを制御できます。例としてはクイックスタートを参照してください。MagicBlock の Permission Program ACLseoPoyC3cBqoUtkbjZ4aDrkurZW86v19pXz2XQnp1 を通じて、初期メンバーとそのフラグを持つ新しい permission account を作成します。
use ephemeral_rollups_sdk::access_control::{
    instructions::CreatePermissionCpiBuilder,
    structs::{
        Member,
        MembersArgs,
        AUTHORITY_FLAG,        // Member can directly modify the permission
        TX_LOGS_FLAG,          // Member can view transaction logs
        TX_BALANCES_FLAG       // Member can view account balances
    }
};

let members = Some(vec![
    Member {
        // AUTHORITY_FLAG allows this member to modify permission settings
        // TX_LOGS_FLAG allows viewing transaction logs
        flags: AUTHORITY_FLAG | TX_LOGS_FLAG,
        pubkey: *payer.key,
    },
]);

// Note: Either the authority or permissioned_account can sign the transaction
// The signer depends on who has AUTHORITY_FLAG in the members list
CreatePermissionCpiBuilder::new(&permission_program)
    .permissioned_account(&permissioned_account)
    .permission(&permission)
    .payer(&payer)
    .system_program(&system_program)
    .args(MembersArgs { members })
    .invoke_signed(&[seed_refs.as_slice()])?;
ユースケース:
  • 新しく委任されたアカウントのアクセス制御を初期化する
  • authority メンバーとその権限を設定する
  • 誰がトランザクション詳細を見られるかを定義する
⬆️ トップに戻る

ベストプラクティス

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

アクセス制御

きめ細かなアクセス制御

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

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

認可

認可フレームワーク

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

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