Base B20과 Solana Token-2022 — 멀티체인 토큰 설계 뭐가 다를까

삼코딩

@samcoding

Base B20과 Solana Token-2022 — 멀티체인 토큰 설계 뭐가 다를까

Base B20과 Solana Token-2022 — 멀티체인 토큰 설계 뭐가 다를까

기존 ERC-20 토큰은 가상머신 위에서 매번 스마트 계약 바이트코드를 실행하는 구조적 한계로 인해 높은 가스 수수료와 승인 피싱 취약점을 안고 있었습니다. 최근 베이스(Base)와 솔라나(Solana)는 토큰 실행 환경을 개별 계약 레이어에서 노드 및 프로토콜 엔진 레벨로 직접 이전하여 성능과 안전성을 끌어올리고 있습니다. 베이스의 B20 표준과 솔라나의 Token-2022 프로그램이 각각 어떻게 가스를 혁신적으로 절감하고 모듈식 확장을 달성했는지 아키텍처와 구현 차이를 비교해 봅니다.

Base B20: Rust 프리컴파일을 통한 가스 수수료 50% 절감

Base가 베릴 업그레이드를 통해 도입한 B20 표준은 스마트 계약의 바이트코드 실행 한계를 노드 수준에서 해결합니다. 이 표준은 EVM 가상머신 위에서 Solidity 계약을 매번 실행하는 대신, Reth V2 노드 엔진에 내장된 Rust 프리컴파일러를 직접 호출하는 방식으로 동작하여 트랜잭션 가스 수수료를 약 50% 절감합니다. 기존 ERC-20 표준과 완벽한 함수 선택자 호환성을 유지하므로 탈중앙화 거래소(DEX)나 기존 암호화폐 지갑 등 기존 디파이 인프라를 수정 없이 그대로 사용할 수 있습니다.

B20은 복잡한 스마트 계약 개발 없이도 엔터프라이즈 급의 기능을 즉시 제공합니다. 자산 동결 및 압류, 유연한 전송 정책 제어, EIP-2612 기반 서명 승인 기능이 프로토콜 레벨에 기본 내장되어 있습니다. 덕분에 규제 준수가 필요한 스테이블코인이나 실물자산 프로젝트가 검증되지 않은 솔리디티 코드를 작성하는 과정에서 발생할 수 있는 보안 취약점을 원천 차단합니다.

모든 B20 토큰은 싱글톤 프리컴파일 주소인 0xB20f000000000000000000000000000000000000을 통해 결정론적으로 생성되며, 발행된 토큰 주소는 항상 0xB200 접두사로 시작합니다. 일반적인 파운드리 환경에서 테스트를 실행하면 코드가 배포되지 않은 주소라는 오류가 발생하기 때문에 로컬 환경 구성 시 유의해야 합니다. 개발자는 Base가 릴리스한 base-foundryup을 통해 전용 파운드리 포크인 base-forge 툴체인을 설치하고, base-std 헬퍼 라이브러리를 프로젝트에 연동해야만 로컬 테스트 환경에서 프리컴파일 호출을 정상적으로 시뮬레이션할 수 있습니다.

solidity
// base-std 라이브러리를 사용한 B20 토큰 생성 테스트 예시
import { B20Factory } from "base-std/B20Factory.sol";

contract B20LocalTest is Test {
    address constant FACTORY_ADDR = 0xB20f000000000000000000000000000000000000;

    function testCreateB20() public {
        // base-forge 환경에서만 프리컴파일 호출 시뮬레이션이 성공합니다.
        address token = B20Factory(FACTORY_ADDR).createB20(variant, salt, params, initCalls);
        assertTrue(token != address(0));
    }
}

Solana Token-2022: 트랜스퍼 훅과 ExtraAccountMetaList 아키텍처

Solana의 Token-2022 표준은 개별 토큰 민트 계정에 모듈형 확장 기능을 결합하여 토큰의 기능을 온체인에서 직접 제어합니다. 그중 핵심은 모든 전송 거래에서 개발자가 지정한 커스텀 로직을 강제로 실행하는 트랜스퍼 훅 기능입니다. 화이트리스트 검증이나 거래 수수료 부과 등 복잡한 규정 준수 조건을 토큰 자체에 내장할 수 있어 많은 빌더의 관심을 받고 있습니다.

Solana의 엄격한 병렬 처리 엔진은 트랜잭션이 접근할 모든 계정을 미리 명시해야 동작합니다. 이를 위해 트랜스퍼 훅은 전송 과정에서 필요한 추가 계정을 ExtraAccountMetaList라 불리는 프로그램 파생 주소(PDA)에 미리 등록해 둡니다. 이 PDA는 ["extra-account-metas", mint_pubkey, hook_program_id] 형태의 고정된 시드 구조로 파생되어 온체인 로드맵 역할을 수행합니다.

사용자 지갑이나 클라이언트가 토큰을 전송할 때는 이 추가 계정들을 매번 수동으로 채워 넣을 필요가 없습니다. spl-tlv-account-resolution 라이브러리를 통해 클라이언트 사이드에서 해당 PDA 데이터를 조회하여 필요한 계정 목록을 자동으로 식별하고, 이를 전송 명령에 알아서 병합해 줍니다. 덕분에 사용자는 일반적인 토큰을 전송할 때와 동일하게 서명 한 번만으로 트랜스퍼 훅이 연결된 토큰을 전송할 수 있습니다.

Anchor 0.31 프레임워크를 사용하면 트랜스퍼 훅 백엔드를 깔끔하게 빌드할 수 있습니다. #[interface(spl_transfer_hook_interface::execute)] 속성을 부여하면 매칭되는 명령 식별자를 자동으로 라우팅해 주며, 아래와 같이 직관적으로 커스텀 유효성 검증 로직을 배치할 수 있습니다.

rust
#[interface(spl_transfer_hook_interface::execute)]
pub fn transfer_hook(ctx: Context<TransferHook>, amount: u64) -> Result<()> {
    // 커스텀 유효성 검증 및 규정 준수 로직
    Ok(())
}

이때 강력한 보안 장벽이 작동합니다. Solana 런타임은 토큰 전송 명령이 트랜스퍼 훅 프로그램으로 교차 프로그램 호출(CPI)을 보낼 때 전송 발신자의 서명 권한을 즉시 제거하고 읽기 전용 계정으로 강등시킵니다. 트랜스퍼 훅 프로그램이 사용자 서명을 악용해 마음대로 다른 명령을 실행하는 위협을 프로토콜 수준에서 원천 차단하는 안전 장치입니다.

멀티체인 보안 분석: 주소 권한 하락 vs 업그레이드 경로 취약점

토큰 표준의 유연성이 높아질수록 보안 취약점의 노출 표면도 함께 넓어집니다. Base B20과 Solana Token-2022는 유연성과 안전성을 양립하기 위해 완전히 다른 보안 아키텍처와 트레이드오프를 선택했습니다.

Solana는 트랜스퍼 훅이 실행될 때 발생할 수 있는 자산 탈취 시도를 차단하고자 엄격한 런타임 권한 제어 모델을 사용합니다. 토큰 전송 시 교차 프로그램 호출(CPI)을 통해 커스텀 트랜스퍼 훅 프로그램을 실행하면, Solana 런타임은 전송 발신자의 서명 권한을 강제로 제거하고 계정 권한을 읽기 전용으로 강등합니다. 이 덕분에 악성 트랜스퍼 훅이 사용자의 서명 권한을 남용해 임의의 다른 트랜잭션을 실행하는 것을 기술적으로 방지할 수 있습니다.

하지만 이러한 보호막도 프로그램 업그레이드 권한이 가진 백도어 위험을 완벽히 메우지는 못합니다. 만약 트랜스퍼 훅 프로그램의 업그레이드 권한이 다중서명으로 철저히 분산되지 않고 중앙화되어 있다면, 배포 초기에는 정상 토큰처럼 동작하다가 대규모 유동성이 모인 시점에 악성 코드로 훅을 업그레이드하여 전송 수수료를 가로채거나 특정 주소의 거래를 잠가버리는 공격이 가능합니다. 외부 보안 감사를 통과한 토큰이라 하더라도 훅 프로그램의 소유자 권한이 유출되거나 남용되면 순식간에 취약해지는 맹점이 존재합니다.

반면 Base B20은 노드 합의 레벨에 구현된 Rust 프리컴파일러를 통해 실행 흐름을 통제하므로 실행 예측 가능성이 극도로 높습니다. 기본적으로 동결 및 압수 기능이나 전송 정책 준수 제어가 프로토콜 엔진에 하드코딩되어 작동하기 때문에, 개별 빌더가 실수로 버그를 주입하거나 악성 코드로 스마트 계약을 무단 변경할 여지 자체가 차단됩니다. 다만 이 방식은 하드포크를 동반하는 네트워크 업그레이드 없이는 개별적인 런타임 기능 확장이 불가능하다는 구조적 제약이 뒤따릅니다.

빌더는 어떤 표준을 선택해야 하는가

모든 요구사항을 완벽히 해결하는 단일 표준은 없습니다. 결국 비즈니스 아키텍처와 해결하려는 문제에 맞춰 도구를 선택해야 합니다.

기존 EVM 디파이 생태계와의 완벽한 호환성을 유지하면서 극한의 가스 최적화와 프로토콜 네이티브 규제 준수가 필요하다면 Base B20이 정답에 가깝습니다. Rust 프리컴파일 기반의 압도적인 실행 속도와 안정적인 보안 모델을 얻을 수 있습니다. 반면, 온체인 토큰 전송 시점마다 유연한 커스텀 실행 로직을 강제하거나 영지식 기반 기밀 전송을 직접 구축하고 싶다면 Solana Token-2022의 확장 모듈과 트랜스퍼 훅이 강력한 무기가 될 것입니다.

두 진영 모두 개발 도구의 진화로 생산성 제약을 빠르게 극복하고 있습니다. Base는 base-forge와 같은 전용 툴체인으로 프리컴파일 시뮬레이션 환경을 지원하고, Solana는 Codama를 통해 타입 안정성을 보장하는 경량 클라이언트를 자동 생성해 줍니다. 빌더로서 우리의 역할은 각 도구 체인의 내부 작동 원리와 권한 모델을 정확히 이해하고, 요구사항에 맞는 강력한 아키텍처를 안전하게 설계하는 것입니다. 일단 로컬 환경에 테스트 포크를 띄우고 직접 컨트랙트와 프로그램을 배포해 동작을 비교해 보기를 권장합니다.

참고 링크

(Edited)