솔라나는 프로그램이 상태를 내부에 품기보다 거래가 읽고 쓸 계정을 명시하고, 서로 충돌하지 않는 계정 집합의 거래를 병렬 처리할 수 있게 설계합니다. 쓰기 계정이 겹치면 순차화되거나 경쟁이 생기며, 총수수료는 서명 기반 기본 수수료와 요청한 컴퓨트 한도·가격에 따른 우선순위 수수료로 구성됩니다.
프로그램과 상태 계정이 분리돼 있다
솔라나 프로그램은 실행 코드를 담은 계정이고 변경 가능한 상태는 별도 데이터 계정에 둔다. instruction은 호출할 program ID, 필요한 계정 목록, 불투명한 데이터 바이트를 포함한다. 여러 instruction을 하나의 transaction에 넣으면 모두 성공하거나 전체가 실패한다.
Solana Program Execution은 런타임이 각 instruction의 계정 인덱스, signer와 writable 플래그를 준비하고 sBPF 프로그램을 실행한 뒤 읽기 전용 계정 변경과 잔액 보존 같은 규칙을 검사한다고 설명한다.
이 구조에서는 ‘어느 계약을 호출했는가’만큼 ‘어떤 계정을 writable로 넘겼는가’가 중요하다. 악성 프런트엔드는 정당한 프로그램에 사용자의 다른 토큰 계정을 넘길 수 있으므로 서명 화면에서 계정 메타를 확인해야 한다.
| 요소 | 역할 | 확인할 점 |
|---|---|---|
| signatures | 서명자 권한 증명 | 요구 서명자·fee payer |
| message | 계정·blockhash·instruction 묶음 | 거래 버전·주소 테이블 |
| account metas | 읽기/쓰기·서명 플래그 | 예상 외 writable 계정 |
| instructions | 프로그램 호출과 데이터 | program ID·내부 CPI |
| recent blockhash | 거래 유효 창과 중복 방지 | 만료·재서명 |
| compute budget | CU 한도·가격 설정 | 과다 한도·실패 비용 |
계정 잠금이 병렬 처리의 경계를 만든다
런타임은 거래가 선언한 계정 접근을 보고 잠금을 잡는다. 여러 거래가 같은 계정을 읽기만 하면 병렬 처리할 수 있지만, 하나라도 쓰기 접근이 겹치면 동시에 실행할 수 없다. 인기 민팅 계정이나 AMM 풀에 쓰기가 몰리면 해당 계정이 병목이 된다.
네트워크 전체 처리량 수치를 특정 앱의 체결 능력으로 읽으면 안 된다. 독립 계정 거래는 병렬화돼도 동일 시장·상태를 갱신하는 거래는 충돌한다. 프로그램 설계는 상태를 여러 계정으로 분할해 병렬성을 높일 수 있지만 회계·동기화 복잡성이 늘어난다.
instruction은 순차 실행되고 CPI로 확장된다
한 거래 안의 top-level instruction은 메시지 순서대로 실행된다. 프로그램은 CPI로 다른 프로그램을 호출하며 서명자·writable 권한은 상위 호출에서 받은 범위를 넘어 임의로 확대할 수 없다. PDA는 개인키 없이 프로그램이 seeds와 program ID로 권한을 행사하는 주소다.
거래 탐색 시 top-level 프로그램 이름만 보지 말고 inner instructions를 펼친다. 토큰 전송, 계정 생성, 시스템 프로그램 호출이 CPI 안에서 일어날 수 있다. 이벤트·잔액 변화와 호출 스택을 함께 본다.
compute unit은 가스와 닮았지만 계산법이 다르다
CU는 산술, 메모리, syscall 등 실행 자원을 계량한다. 거래는 compute unit limit을 요청하며 실행이 이를 넘으면 실패한다. 한도를 크게 잡는다고 실제 프로그램이 더 빨라지는 것은 아니고 우선순위 수수료 계산에서 비용이 커질 수 있다.
Solana Fee Structure는 legacy·v0 거래의 우선순위 수수료를 CU price×CU limit으로 계산한다고 설명한다. 실제 사용 CU가 아니라 요청 한도가 기준이므로 시뮬레이션 결과에 적절한 여유를 더해 설정한다.
- 거래 버전과 fee payer 확인
- 모든 writable·signer 계정 검토
- top-level·inner instructions와 CPI 펼치기
- 시뮬레이션 CU 사용량과 요청 limit 비교
- recent blockhash 만료 후 재서명 내용 재확인
실패해도 기본·우선순위 수수료가 청구될 수 있다
수수료는 실행 전에 fee payer에서 차감되며 프로그램이 나중에 오류로 실패해도 반환되지 않는다. 상태 변경은 원자적으로 되돌아가지만 서명 검증과 스케줄링·실행 자원은 이미 사용됐다. 실패 원인을 수정하지 않고 같은 거래를 반복하면 비용만 누적된다.
base fee는 서명 수에 영향을 받고 priority fee는 혼잡한 스케줄링에서 포함 가능성을 높이는 신호다. 높은 우선순위 수수료가 프로그램 성공이나 특정 슬롯 포함을 보장하지 않는다. 계정 잠금 충돌, blockhash 만료, 슬리피지 조건은 별도다.
솔라나의 병렬성은 거래 수가 아니라 서로 쓰지 않는 계정 집합에서 나온다.
JOBCOIN 해설
실패 거래를 재현하는 읽기 순서
먼저 signature status와 err 필드를 확인하고 logMessages에서 실패한 instruction index와 custom error를 찾는다. loaded addresses가 있는 v0 거래라면 address lookup table을 해석해 최종 계정 목록을 복원한다. pre/post balances와 token balances로 실제 상태 변화가 없었는지 확인한다.
시뮬레이션 로그와 확정 거래 로그는 상태 시점이 다를 수 있다. 시뮬레이션 성공 뒤 다른 거래가 계정을 바꾸거나 blockhash가 만료될 수 있다. 재시도는 새 메시지와 blockhash를 사용하므로 지갑이 요청하는 모든 instruction을 다시 검토한다.
수수료 문서의 현재 상수는 프로토콜 업데이트로 변할 수 있다. 5,000 lamports 같은 수치를 영구 규칙으로 외우지 말고 RPC의 getFeeForMessage와 현재 공식 문서를 사용해 해당 메시지 비용을 확인한다.
자주 묻는 질문
솔라나는 모든 거래를 병렬로 처리하나요?
아닙니다. 읽기·쓰기 계정 집합이 충돌하지 않는 거래가 병렬화되며 같은 writable 계정을 쓰는 거래는 경쟁합니다.
CU limit을 높이면 거래가 빨리 실행되나요?
실행 가능 자원 한도를 늘릴 뿐이며 우선순위는 CU 가격·한도와 스케줄러 비용에 영향을 받습니다. 성공은 보장되지 않습니다.
실패 거래도 수수료가 나가나요?
네. 상태 변경은 되돌아가도 서명 검증과 실행 자원을 사용했으므로 기본·우선순위 수수료가 청구될 수 있습니다.
