메인 콘텐츠로 건너뛰기

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: 멤버가 permission 설정을 업데이트하고 위임하며, 다른 멤버를 추가/제거하고 멤버 플래그를 업데이트할 수 있게 합니다.
  • 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-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 관리: 항상 최소 한 명의 신뢰할 수 있는 멤버에게 AUTHORITY_FLAG를 부여하세요
  2. 최소 권한 원칙: 각 멤버에게 필요한 플래그만 부여하세요
  3. 실시간 업데이트: 위임 해제 없이도 Private Ephemeral Rollup에서 permission을 실시간으로 업데이트해 동적 접근 제어 조정이 가능합니다
  4. 정리: 사용하지 않는 permission accounts를 위임 해제하고 닫아 SOL을 확보하세요

보안 고려 사항

  • 서명자 검증: AUTHORITY_FLAG를 가진 멤버 또는 permissioned account를 가진 프로그램만 변경을 인가할 수 있습니다
  • 공개 계정: 멤버를 None으로 설정하면 계정이 공개적으로 보이게 됩니다
  • 기본 Authority: 기본적으로 permissioned account의 소유자가 permission account의 members에 permission authority로 추가됩니다
  • 빈 멤버 목록: members 필드가 빈 목록으로 설정되면 permissioned account는 완전히 제한되고 비공개가 됩니다. permission을 수정할 수 있는 것은 소유자뿐입니다
  • 접근 감사: 멤버 플래그를 사용해 접근을 감사하고 제어하세요

접근 제어

세밀한 접근 제어

온체인 프라이버시

프라이버시 메커니즘과 개념

인가

인가 프레임워크

컴플라이언스 프레임워크

컴플라이언스 기준 및 가이드라인