Solana의 Preconfirmations(Preconfs)이란 무엇인가요?

리더 내부에서 트랜잭션이 처리되는 과정

다음은 Preconfirmations과 관찰 가능성에 초점을 맞춰 리더 내부의 트랜잭션 처리 과정을 설명한 내용입니다. Solana의 전체 트랜잭션 처리 과정은 Solana Virtual Machine(SVM) 기술 개요를 참조하세요.

리더에 도달하기 전

Solana에서는 서명된 트랜잭션을 블록 생성자, 즉 현재 리더와 이후 리더들에게 직접 전송합니다. 트랜잭션은 QUIC을 통해 도착하며, 연결 용량은 스테이크 가중치에 따라 할당됩니다. 따라서 스테이킹된 연결을 통해 중계되는 트랜잭션은 부하가 클 때도 수신될 가능성이 훨씬 높습니다.

이 시점에 트랜잭션을 볼 수 있는 주체는 발신자와 이를 현재 및 이후 리더들에게 중계하는 RPC 노드 또는 트랜잭션 랜딩 서비스뿐입니다. 

이 단계에서는 트랜잭션의 결과를 전혀 알 수 없습니다. 

1단계: 수신 및 SigVerify

리더의 Transaction Processing Unit(TPU)은 수신 트랜잭션을 패킷 형태로 받아 역직렬화하고 서명을 검증한 다음 중복 항목을 제거합니다. 부하가 클 때는 잘못된 패킷과 스팸 트랜잭션을 추가 리소스가 소비되기 전에 삭제합니다.

트랜잭션이 수신되고 SigVerify 단계의 서명 검증을 통과해도 아직 후보에 불과합니다. 슬롯마다 수천 개의 후보 트랜잭션이 도착하며, 그중 상당수는 블록에 포함되지 않습니다.

이 단계의 트랜잭션을 스트리밍하는 것은 노이즈를 스트리밍하는 것과 같으므로 의미 있는 관찰 가능성이 없습니다. 

2단계: 스케줄러

블록 생성은 Banking Stage에서 이루어집니다. Agave 1.18부터는 모든 대기 트랜잭션을 전역적으로 파악하고 실행 워커 풀에 작업을 전달하는 단일 스케줄링 스레드인 중앙 스케줄러가 핵심을 담당합니다. 전체 컨텍스트를 가진 단일 스레드는 공유 큐를 두고 n개의 스레드가 경쟁할 때보다 잠금 충돌을 크게 줄이며 블록을 채울 수 있습니다.

스케줄러는 기본적으로 트랜잭션을 다음 세 가지 주요 단계로 처리합니다.

1. 버퍼링 및 우선순위 지정

수신 트랜잭션은 스케줄러의 수신 및 버퍼 컴포넌트로 전달됩니다. 여기서 각 트랜잭션의 우선순위와 비용을 계산한 뒤 우선순위순 컨테이너에 삽입합니다.

이 시점에도 트랜잭션은 수천 개의 ‘잠재적 후보’ 중 하나일 뿐입니다. 버퍼가 더 높은 우선순위의 작업으로 가득 차면 제거될 수 있습니다.

2. 스케줄링 

스케줄러의 컨트롤러에 있는 제어 루프는 컨테이너에서 우선순위가 가장 높은 트랜잭션을 반복적으로 꺼내 계정 잠금 충돌을 확인하고 실행 배치로 묶습니다.

Agave 2.3부터 제공되는 스케줄링 알고리즘은 그리디 스케줄러입니다. 테스트 결과 그리디 방식이 더 적은 오버헤드로 블록을 채운다는 점이 확인되어 기존 prio-graph 설계를 대체했습니다.

3. 전달 

예약된 배치는 채널을 통해 실행 워커로 전송됩니다. 이제 리더는 워커 스레드, 계정 잠금, 조립 중인 블록의 공간 등 실제 리소스를 이 특정 트랜잭션에 할당한 상태입니다.

이 시점에도 트랜잭션은 대기 중입니다. 리더는 이를 실행할 예정이지만 아직 실행된 작업은 없으므로 보고할 결과도 없습니다. Preconfirmations은 다음 단계에서 생성됩니다.

Firedancer의 스케줄러 아키텍처는 Agave와 어떻게 다른가요?

Firedancer는 약간 다른 아키텍처를 통해 같은 시점에 도달합니다. 메모리를 공유하는 스레드 대신, Firedancer는 공유 메모리 큐로 연결된 격리형 타일을 실행합니다. 스케줄링 로직은 pack tile에 있습니다. 

pack tile은 모든 대기 트랜잭션을 유지하고 각 bank tile이 현재 보유한 계정을 추적합니다. 그런 다음 충돌이 없고 수수료를 극대화하는 트랜잭션을 선택해 마이크로블록으로 구성하고, 실행을 위해 bank tile에 전달합니다. 

여기서도 동일한 전달 과정이 일어납니다. 선택된 트랜잭션이 패킹 로직에서 실행 유닛으로 이동하고, 그곳에서 결과가 결정됩니다.

3단계: 실행

Agave의 워커 또는 Firedancer의 bank tile은 현재 bank를 기준으로 예약된 트랜잭션 배치를 실행합니다. 계정을 로드하고 프로그램을 실행한 뒤 결과를 커밋합니다.

이 단계에서는 예약된 트랜잭션이 잔액 부족, 프로그램 오류, 되돌려지는 슬리피지 검사 또는 기타 런타임 조건 등 다양한 이유로 실패할 수도 있습니다. 결과가 무엇이든 이 시점에는 리더의 머신에만 로컬로 존재합니다.

바로 이 순간 preconfirmation이 생성됩니다. 리더는 각 트랜잭션이 실행되는 즉시 상태와 함께 스트리밍합니다. 결과가 엔트리에 기록되기 전이며, 어떤 블록 데이터도 머신을 떠나기 훨씬 전입니다.

전체 처리 과정에서 트랜잭션 결과가 실제로 존재하면서 보고도 가능한 최초의 순간입니다. 실행보다 앞선 단계에는 스트리밍할 결과가 없는 대기 후보 풀만 있습니다. 이후 단계에서는 정보가 이미 블록으로 패키징되어 네트워크의 나머지 영역으로 전송되고 있습니다.

따라서 이런 조기 신호가 존재할 수 있는 곳은 실행 단계뿐입니다. 모든 preconfirmation에 예측이 아닌 트랜잭션의 실제 결과가 포함되는 이유도 여기에 있습니다.

하지만 preconfirmation으로는 트랜잭션이 포함된 블록이 정식 체인에 포함될지 알 수 없습니다. 해당 블록은 아직 샤드로 분할되거나 전파되거나 투표되지 않았습니다. 

이 때문에 Preconfirmations은 보장이 아닌 신호입니다.

4단계: 역사 증명과 엔트리

실행된 배치는 엔트리를 생성하기 위해 역사 증명 스트림에 기록됩니다. 엔트리는 트랜잭션을 해시로 묶어 리더의 검증 가능한 시계에 결합한 단위입니다. 엔트리는 원장의 기본 형식이지만 현재는 리더의 머신에만 존재합니다.

리더 외부에서는 사실상 전혀 관찰할 수 없습니다.

Alpenglow 업데이트에서는 역사 증명이 제거됩니다. Rotor와 Votor가 Solana에서 탈중앙화 시계의 필요성을 없애기 때문입니다. Preconfirmation 모델에는 영향이 없습니다. 리더는 앞으로도 트랜잭션을 전파하기 전에 실행하므로 가장 빠르게 관찰할 수 있는 신호는 여전히 리더의 로컬 실행 결과입니다. 

5단계: 샤드 분할 및 브로드캐스트

엔트리는 샤드, 즉 손실 허용을 위해 소거 코딩된 MTU 크기의 조각으로 나뉩니다. 이 샤드에는 서명이 추가되고 Turbine의 스테이크 가중치 트리를 통해 브로드캐스트됩니다.

이 지점부터 본격적인 관찰이 가능해집니다. 샤드는 특정 블록에서 리더의 머신을 떠나는 최초의 산출물입니다. 따라서 샤드 스트림을 포함해 Solana의 다른 모든 조기 데이터 제품은 여기서 시작합니다. 샤드에서 트랜잭션을 재구성하면 RPC 커밋 수준보다는 빠릅니다. 하지만 샤드가 생성되기 전에 리더가 트랜잭션을 실행한다는 점에서 preconfirmation보다는 늦습니다. 

이후에는 검증인이 블록을 재실행하고 투표하며, 트랜잭션이 processed, confirmed, finalized 커밋 수준을 차례로 거칩니다. 

지연 시간 단계에서 Preconfirmations은 어디에 있나요?

Preconfirmations은 원시 및 디코딩된 샤드, LaserStream과 기타 데이터 스트리밍 방식을 포함한 모든 신호 중 Solana에서 가장 빠릅니다. 

다만 preconfs은 지연 시간 단계의 한 계층으로 이해하는 것이 좋습니다. 각 계층은 더 이른 관찰을 위해 일정 수준의 완전성이나 확실성을 포기합니다.

가장 빠른 신호부터 가장 늦은 신호까지 나열하면 다음과 같습니다.

이 표에서 두 가지 사실을 확인할 수 있습니다. 

첫째, 이러한 신호는 서로를 직접 대체하기보다 상호 보완합니다.

예를 들어 Preconfirmations은 네트워크가 알기 전에 리더가 방금 실행한 내용을 알려주지만, LaserStream의 메시지는 전체 메타데이터와 함께 결과를 알려줍니다.

프로덕션 시스템은 일반적으로 두 신호를 모두 사용해야 합니다. Preconfirmations을 기반으로 작업하고 이후 단계의 신호로 검증합니다.  

둘째, 각 단계 사이의 차이는 일정하지 않습니다.

processed 스트림에서 샤드로 올라가면 몇 밀리초를 줄일 수 있습니다. 반면 샤드에서 Preconfirmations으로 올라가면 블록 생성 파이프라인의 나머지 과정, 즉 엔트리 기록, 샤드 분할, 전파를 건너뜁니다. 관찰 지점이 블록의 최초 공개 산출물에서 리더 내부에만 존재하는 결과로 이동하기 때문입니다. 

따라서 Preconfirmations은 샤드보다 약 5~50밀리초 빠릅니다. 

Preconfirmations 신뢰 모델: 보장이 아닌 신호

Preconfirmation이 보장하는 내용은 한 문장으로 요약할 수 있습니다. 리더가 이 트랜잭션을 이 결과로 실행했습니다. preconf이 보장하지 않는 모든 내용도 같은 문장에서 비롯됩니다.

실행된 트랜잭션은 아직 반영된 트랜잭션이 아닙니다. 이를 포함한 블록이 아직 샤드로 분할되거나 전파되거나 투표되지 않았다는 의미입니다. 네트워크에서 확인되기 전에 이 블록이 건너뛰어지거나 포크에서 제외될 가능성도 있습니다. Preconfirmation된 트랜잭션은 거의 모두 온체인에 정상 반영됩니다. 하지만 Preconfirmations을 기반으로 작동하는 시스템은 결과를 최종 확정하기 전에 다른 관찰 수단으로 확인해야 합니다.

커버리지는 설계상 부분적입니다. Preconfirmations은 리더가 예약된 트랜잭션 스트림을 Helius로 전달하는 슬롯에서만 존재합니다. 따라서 커버리지는 참여하는 네트워크 스테이크 비율에 따라 확대되며 스트림이 항상 연속적이지는 않습니다.

서비스에 중단 없는 커버리지가 반드시 필요하다면 공백이 발생할 때 LaserStream 또는 Shred Delivery로 대체하는 방식을 고려해야 합니다.

Preconfirmations은 실행 후 생성되므로 구독자는 이미 결정된 결과를 보게 됩니다. 악용을 기다리는 미결 주문 흐름이 아닙니다. 즉, 블록 안에서 해당 트랜잭션보다 앞설 기회는 이미 사라진 상태입니다. 이것이 조기 가시성을 판매하는 것과 스케줄링 전 주문 흐름을 유출하는 것의 핵심 차이입니다. 전자는 구독자가 나머지 네트워크보다 빠르게 대응하도록 하지만, 후자는 스트리밍되는 트랜잭션에 불리한 행동을 가능하게 합니다. Preconfirmations은 전자에만 해당합니다.

이 신호는 특성을 명확히 드러냅니다. preconfirmation을 뒷받침하는 경제적 약속은 없으며, 이를 주장하지도 않습니다. 리더는 로컬 결과를 보고하지만 후속 이행을 담보하기 위해 어떤 자산도 스테이킹하지 않습니다. Preconfirmations을 활용하는 전략에는 이것이 적절한 절충점입니다.

예를 들어 청산 봇에는 트랜잭션 반영을 무조건 보장하고 위반 시 슬래싱할 수 있는 약속이 필요하지 않습니다. 특정 트랜잭션의 결과를 경쟁자보다 몇 밀리초 먼저 아는 것이 중요합니다.

Helius Preconfirmations은 어떻게 작동하나요?

Helius Preconfirmations은 단일 WebSocket 구독을 통해 제공됩니다. 클라이언트는 Gatekeeper 엔드포인트, 즉 wss://beta.helius-rpc.com에 연결하고 preconfSubscribe 요청을 보낼 수 있습니다.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "preconfSubscribe",
  "params": [
    {
      "failed": false,
      "regionInclude": ["ewr", "fra"],
      "accountInclude": ["TARGET_WALLET_ADDRESS"],
      "accountExclude": [],
      "accountRequired": []
    }
  ]
}

필터는 서버 측에서 계정(포함, 제외, 필수), 리전, 상태를 기준으로 적용되며 조회 테이블(LUT)도 지원합니다. 따라서 구독자는 전략과 관련된 예약 트랜잭션만 수신하고 해당 트랜잭션에 대해서만 비용을 지불합니다. 

Preconfirmations은 실행 후 생성되므로 상태 필터는 실제 결과에 적용됩니다. failed: false으로 설정하면 실패한 트랜잭션은 전송되지 않으며 메시지별 요금도 부과되지 않습니다.

Preconfirmations은 모든 Helius 유료 플랜인 Developer, Business, Professional, Enterprise에서 사용할 수 있습니다. 전송된 메시지가 0개인 슬롯은 크레딧을 소비하지 않습니다. 슬롯에서 메시지가 하나 이상 전송되면 열려 있는 각 preconfSubscribe 구독에 300크레딧과 전송된 메시지당 10크레딧 중 더 큰 금액이 청구됩니다.

이후 필터와 일치하는 모든 예약 트랜잭션은 압축된 바이너리 프레임으로 도착합니다. 트랜잭션 버전, 예약된 슬롯, 슬롯 내 트랜잭션 인덱스, 상태를 포함하는 고정 18바이트 헤더 뒤에 전체 트랜잭션 바이트가 이어집니다. 

고정 헤더는 핫 패스에서 JSON을 파싱하지 않고도 나노초 단위로 디코딩할 수 있으므로 의도적으로 최소한의 형식을 사용합니다. 이 과정에서 필요한 JSON은 편의를 위한 구독 확인 메시지뿐입니다. 

Preconfirmation은 거래의 절반에 불과합니다. 트랜잭션을 먼저 보더라도 응답이 먼저 반영되어야 의미가 있습니다. 이것이 Helius Sender의 최고 성능 티어인 Sender Max를 출시한 이유입니다.

Sender Max는 제출 요청, 즉 단일 트랜잭션 또는 최대 4개 트랜잭션으로 구성된 원자적 번들을 사용 가능한 모든 고속 경로로 라우팅합니다. 또한 높은 팁을 우선하는 우선순위 팁 버퍼에 넣습니다. 최소 팁은 0.001 SOL입니다.

preconfSubscribe으로 신호를 받고 Sender Max로 트랜잭션을 반영하세요.  

Preconfirmations으로 무엇을 구축할 수 있나요?

트랜잭션 결과가 결정된 시점부터 관찰되는 시점까지 매 밀리초마다 수익성이 감소하는 모든 전략이 preconfs의 이점을 얻을 수 있습니다. 대표적인 사용 사례는 다음과 같습니다. 

스나이핑

새로운 풀 생성과 토큰 출시는 배포 트랜잭션이 리더 내부에서 실행되는 즉시 확인할 수 있습니다. Preconfirmations을 사용하는 스나이퍼는 샤드 관찰자가 블록의 첫 조각을 기다리는 동안 먼저 대응합니다. 

카피 트레이딩

리더가 대상 지갑의 트랜잭션을 실행하는 순간 해당 움직임이 preconfirmation 스트림에 나타납니다. accountInclude을 사용해 대상 주소를 필터링하면 스트림이 전용 미러 피드로 바뀌며, 다른 카피 트레이더보다 먼저 움직임을 파악할 수 있습니다.

청산

포지션을 지급 불능 상태로 만드는 오라클 업데이트는 실행 즉시 알 수 있습니다. 이 시점에 업데이트를 감지한 청산 봇은 샤드나 processed 커밋을 관찰하는 봇보다 전체 파이프라인을 앞서 시작합니다. 따라서 Preconfirmations은 청산 작업에 매우 중요합니다.

마켓 메이킹 및 propAMMs

실행 순간에 들어오는 흐름을 확인할 수 있으므로 propAMMs과 기타 호가 시스템은 흐름이 공개되기 전에 가격을 조정하거나 오래된 호가를 철회할 수 있습니다. 

모든 사례에서 Preconfirmations은 전략의 대응 시점을 ‘네트워크가 알게 된 후’에서 ‘리더가 실행하는 순간’으로 앞당깁니다.

Preconfirmations 전달로 수익 창출하기

Preconfirmation 커버리지는 공급 측에 검증인이 참여하는 네트워크 효과를 가집니다. 모든 검증인은 스트림을 Helius로 전달하고 수익을 얻을 수 있습니다. 블록 생성의 부산물을 수익원으로 전환하며, 검증인이 다른 방식으로 자신의 지위를 수익화하는지와는 무관합니다.

참여 스테이크가 많을수록 커버리지가 넓어집니다. 참여하려는 검증인은 문의하거나 검증인용 Preconfirmations 문서에서 자세한 내용을 확인할 수 있습니다. 

Ethereum preconfs과 Solana preconfs의 차이점은 무엇인가요?

Ethereum Preconfirmations은 트랜잭션이 향후 블록에 반영될 것을 보장하는 제안자의 약속입니다. 반면 Solana Preconfirmations은 현재 블록을 위해 리더가 방금 로컬에서 실행한 트랜잭션에 대한 실시간 온체인 신호입니다. 전자가 결과를 더 빨리 아는 것이라면 후자는 결과를 더 빨리 보는 것입니다.

Ethereum Preconfirmations

Ethereum에서 Preconfirmations은 연구 문헌에서 based preconfs으로 자주 표기되며, 2023년 Justin Drake가 처음 제안한 설계입니다. 이는 포함 약속입니다. 제안자는 자신의 슬롯보다 앞서 트랜잭션을 향후 블록에 포함하겠다고 약속하며, 이 약속은 슬래싱 같은 경제적 메커니즘으로 뒷받침됩니다. 

현재 운영 중인 구현은 여러 가지입니다. 

• Primev의 MEV-Commit: 지갑, 서처, 인텐트 프로토콜이 약속을 받기 위해 실행 제공자, 즉 블록 빌더와 시퀀서에 입찰하는 마켓플레이스
• ETHGas: 경제적 보장이 적용된 preconfirmation 네트워크
• Chainbound의 Bolt: 무허가형 MEV-Boost 호환 제안자 약속 제공

가장 중요한 Ethereum Preconfirmations의 특징은 다음과 같습니다.

• 자신의 트랜잭션을 대상으로 함
• 실행 전에 발행됨
• 확실성에 최적화됨

Ethereum Preconfirmations은 실제로 반영되기 전에 트랜잭션이 반영될 것을 보장합니다.

Ethereum은 블록 생성 방식 때문에 이런 장치가 필요합니다. 대부분의 제안자는 MEV-Boost를 통해 블록 생성을 적시에 경매로 넘기므로, 경매가 끝나기 전에는 블록에 대해 신뢰할 만한 약속을 할 수 없습니다. 하지만 Solana에는 애초에 이런 공백이 없었습니다. 리더 일정이 미리 알려져 있고 멤풀이 없으며, 단일 리더가 슬롯 내에서 블록을 지속적으로 수신하고 정렬하고 실행하고 스트리밍합니다. Ethereum이 경제적 기반을 통해 만들어야 하는 조기 신호는 Solana의 블록 생성 파이프라인에 기본적으로 존재합니다. 이를 외부에 노출하기만 하면 됩니다.

Solana Preconfirmations

Solana Preconfirmations은 미래에 대한 약속이 아닌 실시간 온체인 신호입니다. 리더는 트랜잭션이 나머지 네트워크에 전파되기 전에 이미 실행한 트랜잭션을 보고합니다.

가장 중요한 Solana Preconfirmations의 특징은 다음과 같습니다.

• 모든 사용자의 트랜잭션을 포함함
• 실행 후에 생성됨
• 지연 시간에 최적화됨

Solana Preconfirmations을 사용하면 실행된 트랜잭션이 샤드나 표준 커밋 수준의 RPC 요청을 통해 네트워크 전체에서 관찰되기 몇 밀리초 전에 확인할 수 있습니다.

Ethereum의 블록 공간 예약형 preconfirmation과 가장 유사한 Solana 방식은 Raiku의 Ahead-of-Time(AOT) Transactions용 컴퓨트 유닛 마켓플레이스입니다. 앱이 향후 블록에 포함될 공간을 보장받아 예약할 수 있습니다.

결론

Solana의 모든 트랜잭션에는 결과가 미정에서 확정으로 바뀌는 단 하나의 순간이 있습니다. 리더가 트랜잭션을 실행하는 순간입니다. Preconfirmations은 바로 이 순간을 나머지 네트워크가 보기 전에 스트리밍합니다. 블록의 공개 산출물이 아닌 리더의 실행 결과를 관찰하므로 지연 시간 단계에서 샤드보다 앞섭니다. 하지만 블록은 네트워크에서 확인된 뒤에야 정식 체인의 일부로 간주되므로 Preconfirmations은 보장이 아닌 신호입니다.

스나이퍼, 카피 트레이더, 청산자, 마켓 메이커, 서처처럼 지연 시간에 민감한 시스템이라면 preconfSubscribe로 구독하고, 중요한 계정을 필터링하고, Sender Max로 신호에 대응한 뒤 표준 커밋 검사로 결과를 검증하세요.

전체 구독 레퍼런스, 메시지 형식, 통합 예시는 Preconfirmations 문서에서 확인할 수 있습니다.