Solana의 인증 메커니즘: x402가 EVM을 넘어 어떻게 작동하는지
Source: Dev.to
왜 Solana는 ERC‑3009가 필요하지 않은가
Ethereum에서는 ERC‑3009가 두 가지 주요 문제를 해결합니다:
- 두 단계 승인 –
approve+transferFrom패턴은 두 개의 트랜잭션이 필요합니다. - 가스 비용 – 사용자는 가스 비용을 지불하기 위해 ETH를 보유해야 합니다.
Solana의 아키텍처는 이 두 문제를 근본적으로 해결합니다.
원자성 멀티‑인스트럭션 트랜잭션
단일 Solana 트랜잭션은 여러 인스트럭션을 포함할 수 있으며, 이들은 원자적으로 실행됩니다:
const transaction = new Transaction()
.add(createApproveInstruction(...)) // Approve
.add(createTransferInstruction(...)); // Transfer
// 두 인스트럭션이 ONE 원자 트랜잭션으로 실행됩니다
await sendAndConfirmTransaction(connection, transaction, [payer]);
수수료 지급자 추상화
Solana에서는 어떤 계정이든 트랜잭션 수수료를 낼 수 있습니다:
const transaction = new Transaction();
transaction.feePayer = sponsorPublicKey; // 스폰서가 가스를 부담
transaction.add(transferInstruction);
이를 통해 사용자는 SOL을 전혀 보유하지 않아도 되는 “가스 없는” 경험을 제공할 수 있습니다.
Solana의 토큰 권한 모델
SPL 토큰 프로그램 기본
| Concept | Description |
|---|---|
| Mint | 토큰 계약 (예: USDC mint) |
| Token Account | 특정 토큰에 대한 사용자의 잔액 |
| Associated Token Account (ATA) | 지갑 + mint에서 파생된 표준 토큰 계정 |
| Authority | 전송을 승인할 수 있는 계정 |
EVM (ERC‑3009) vs Solana 비교
| Aspect | EVM + ERC‑3009 | Solana |
|---|---|---|
| Approval pattern | 오프‑체인 서명 | 트랜잭션에 내장 |
| Gas payment | 중개자가 지불 | 설정 가능한 수수료 지급자 |
| Nonce handling | 임의 bytes32 | 최신 블록 해시 |
| Transaction atomicity | 단일 연산 | 멀티‑인스트럭션 |
| Meta‑transaction support | ERC‑3009 필요 | 네이티브 지원 |
x402에 두 접근 방식이 모두 작동하는 이유
아키텍처 차이가 있더라도, 두 방식 모두 동일한 x402 목표를 달성합니다:
- 사용자가 가스를 내지 않음 – 중개자가 수수료를 부담
- 단일 사용자 행동 – 하나의 서명/승인
- 신뢰 없는 검증 – 의도에 대한 암호학적 증명
- 원자적 정산 – 전부 혹은 전무 실행
Solana에서 가스 없는 전송
1. 수수료 지급자 스폰서십 (네이티브)
const transaction = new Transaction();
transaction.feePayer = facilitatorPublicKey;
transaction.add(usdcTransferInstruction);
2. Kora Protocol
SPL 토큰 수수료를 SOL로 변환해 주는 서비스 — 사용자는 USDC로 비용을 지불하고 SOL을 전혀 다루지 않습니다.
3. Octane
토큰 기반 수수료 지불을 위한 오픈소스 가스 없는 트랜잭션 릴레이어.
Solana의 USDC
| Property | Value |
|---|---|
| Mint Address | EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v |
| Decimals | 6 |
| Program | SPL Token |
| Issuer | Circle |