솔라나의 트랜잭션 검증 방식은 어떻게 이루어집니까?

1. 트랜잭션 검증이란 무엇인가?
- Solana 네트워크에 제출된 트랜잭션의 유효성(서명, 잔액, 계정 상태 등)을 확인하고, 블록에 포함시킬지 결정하는 과정입니다. 이 과정을 통해 네트워크의 일관성과 보안을 유지합니다.

2. 트랜잭션 흐름은 어떻게 진행되나?
1) 클라이언트가 트랜잭션 생성 → ed25519 개인키로 서명
2) 노드(Peer)로 전파 → Leader 후보(블록 프로듀서)에게 전달
3) Leader가 PoH 타임스탬프 및 순서 부여
4) Leader가 로컬에서 1차 검증(서명, blockhash 유효성, 계정 잠금)
5) 올바른 트랜잭션을 블록(Entry)으로 묶어서 네트워크에 브로드캐스트
6) 검증자(Validator)들이 블록을 재연산·확인 후 Tower BFT로 최종 확정

3. Proof of History(PoH)의 역할은?
- 트랜잭션 간 순서를 암호학적 시간증명으로 기록.
- 별도 메시지 교환 없이도 “언제” 발생했는지를 검증 가능케 해 TPS를 높입니다.

4. Leader(블록 프로듀서)의 역할은?
- 일정 간격(1 epoch)마다 선택된 스테이크 기반 노드.
- PoH 기록, 트랜잭션 수집·검증, 블록 생성·방송, 다음 Leader로 릴레이

5. 트랜잭션 검증 단계별 검사 항목은?
1) 서명 검증: ed25519로 트랜잭션 무결성 확인
2) blockhash 유효성: 최근 블록해시와 일치 여부
3) 계정 잠금(Account Locking): 동일 계정 동시 변경 방지
4) 잔액·상태 검사: 송금 가능 여부, 스마트컨트랙트 호출 파라미터
5) Compute Unit 한도: 트랜잭션당 계산량(CU) 초과 여부
6. Tower BFT (합의) 과정은?
- Solana 특화된 PBFT 계열 합의
- 각 Validator가 제출한 투표(vote) 기록을 PoH 타임스탬프와 함께 누적
- 슈퍼다수(약 2/3 스테이크) 이상의 승인이 모이면 블록이 최종 확정

7. 병렬 처리와 Sealevel 런타임
- Solana는 계정 충돌이 없는 트랜잭션을 동시에 실행
- Sealevel이 독립 상태(계정 키) 단위로 락/해제해 멀티스레드 처리 최적화

8. 트랜잭션 전파 프로토콜 (Turbine)
- 대용량 데이터 전송을 위해 블록을 소조각(Shred)으로 분할
- Kademlia 스타일 피어 투 피어 전파로 대역폭 효율화, 지연 최소화

9. 중복·재생 공격 방지
- 트랜잭션마다 최근 blockhash 포함 → 일정 블록 이후 만료
- 계정 잠금→동일 Nonce 재사용 차단

10. 검증 완료 후 처리 및 확정
- 블록 생성 후 네트워크 전파
- 다른 Validator들이 독립 검증 → Tower BFT 투표
- 슈퍼다수 승인 시 “결정적 최종성(Deterministic Finality)” 확보

11. 우선순위 및 수수료 구조
- 트랜잭션 수수료는 스테이크 수익률, 네트워크 혼잡도 기반 동적 책정
- 높은 수수료 제시 시 Leader가 우선 수집·검증

위 과정을 통해 Solana는 초당 수천 건 이상의 트랜잭션을 빠르고 안전하게 처리합니다.

솔라나(Solana)의 거래(Transaction) 검증은 크게 ‘사전 검증(pre‐validation)’, ‘병렬 실행(parallel execution)’, ‘블록 생성 및 전파(block production & propagation)’, ‘합의(consensus)’의 네 단계로 구분할 수 있습니다.

아래에서는 각 단계에서 내부적으로 어떤 일이 벌어지는지 순서대로 풀이해 드리겠습니다.

1. 거래 수신 및 사전 검증 리더 노드(Leader)는 네트워크로부터 클라이언트가 보낸 거래를 수집합니다.

이때 각 거래는 • 송신자의 디지털 서명(signature) • 최근 블록 해시(recent blockhash) • 거래 수수료(fee) 정보 • 대상 계정(account) 목록과 페이로드(packed instructions) 을 포함하고 있습니다.

우선 서명 검증 단계에서 Ed25519 알고리즘으로 거래 데이터 전체에 대한 서명이 유효한지 확인합니다.

동시에 거래에 첨부된 블록 해시는 네트워크 전체가 공유하는 ‘최근 블록 해시’ 목록(약 2분가량 유효)에 포함되어야만 거래가 중복·재사용(replay)되지 않도록 검사합니다.

이 과정을 통과해야만 다음 단계로 넘어갑니다.



2. 계정 잠금 및 병렬 실행 준비 검증된 거래는 내부적으로 읽기 전용 계정과 읽기·쓰기 계정으로 분류되며, 같은 계정을 동시에 쓰기하려는 두 거래는 충돌(conflict)이 발생하지 않도록 잠금(locking) 메커니즘이 작동합니다.

솔라나는 Sealevel이라는 병렬 실행 엔진을 쓰는데, 거래 간 계정 접근이 서로 겹치지 않으면 완전히 독립적으로 동시에 처리할 수 있습니다.

이때 잠금 정보만 보고 의존도가 없는 거래끼리 최대 수백 개 단위로 묶어서 병렬 실행대로 넘깁니다.



3. 거래 실행과 상태 변경 각 거래 실행 단계는 다음과 같은 파이프라인으로 운용됩니다.

가. 인터프리터(Interpreter) 단계: BPF(Berkeley Packet Filter) 기반 프로그램으로서, 거래에 담긴 스마트컨트랙트(프로그램)를 호출하는 초기 해석 작업 나. 실행기(Runtime) 단계: 실제로 스마트컨트랙트 로직을 수행하면서 계정 잔액 전송, 데이터 쓰기·읽기, 토큰 민팅·소각 등의 상태(state) 변경 다. 결과 검증(Post‐processing) 단계: 프로그램 실행 후 발생한 로그, 에러 여부, 소비한 연산(Compute Unit) 등 메타 정보를 집계하고, 지정된 수수료가 충분히 지불됐는지 다시 확인 이 과정을 거쳐야 거래가 유효한 상태변경으로 확정됩니다.

일단 한 블록 내 거래들의 실행이 끝나면, 이 변경 사항은 해당 블록의 트랜잭션 결과(Transaction Result)로 묶여 블록에 포함됩니다.



4. 블록 생성·전파와 합의 블록을 만드는 주체인 리더 노드는 PoH(Proof of History) 타임스탬프에 따라 거래들을 순서대로 정리해 블록 헤더를 구성합니다.

그런 다음 Turbine 프로토콜을 통해 블록을 네트워크 전체에 조각(fragment) 단위로 확산시키고, 각 검증자(Validator)는 블록을 받은 뒤 같은 파이프라인으로 재실행하여 블록 생산자가 조작하지 않았는지 확인합니다.

검증이 끝난 블록에 대해서는 Solana의 PoS(Proof of Stake) 투표 메커니즘이 적용됩니다.

검증자들은 실행 결과가 동일함을 확인한 블록에 대해 서명(vote)을 하며, 네트워크 지분의 2/3 이상이 투표를 완료하면 해당 블록이 영구적으로 확정(finalized)됩니다.

이렇게 솔라나는 PoH를 이용한 시간 증명으로 거래 순서를 미리 확정짓고, Sealevel 기반 병렬 실행으로 초당 수천~만 건의 거래를 처리하며, PoS 투표를 통해 최종 확정을 보장하는 구조를 갖추고 있습니다.

이러한 요소들이 합쳐져 ‘낮은 지연(latency)’, ‘높은 처리량(throughput)’, ‘정확한 검증’을 동시에 달성합니다.