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. 버퍼링 및 우선순위 지정

수신 트랜잭션은 스케줄러의 receive and buffer 구성 요소에 들어갑니다. 여기서 각 트랜잭션의 우선순위와 비용을 계산한 뒤 우선순위순 컨테이너에 삽입합니다.

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

2. 스케줄링 

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

Agave 2.3부터 제공되는 스케줄링 알고리즘은 greedy scheduler입니다. 탐욕적 방식이 더 적은 오버헤드로 블록을 채운다는 테스트 결과에 따라 이전의 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단계: Proof of History와 엔트리

실행된 배치는 Proof of History 스트림에 기록되어 엔트리를 생성합니다. 엔트리는 리더의 검증 가능한 시계에 엮인, 트랜잭션의 해시된 묶음입니다. 엔트리는 원장의 기본 형식이지만 현재는 리더의 머신에만 존재합니다.

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

Alpenglow 업데이트에서 Proof of History가 제거될 예정이라는 점에 유의하세요. Rotor와 Votor가 Solana의 탈중앙화 시계 필요성을 없애기 때문입니다. Preconfirmations 모델은 영향을 받지 않습니다. 리더는 여전히 트랜잭션을 배포하기 전에 실행하므로, 가장 빠르게 관찰할 수 있는 신호는 계속 리더의 로컬 실행 결과입니다. 

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이 보장하지 않는 내용도 같은 문장에서 도출됩니다.

실행된 트랜잭션은 아직 포함된 트랜잭션이 아닙니다. 즉, 이를 담은 블록이 아직 샤드로 분할되거나 전파되거나 투표되지 않았습니다. 네트워크에서 확인되기 전에 이 블록이 건너뛰어지거나 포크에서 제외될 수 있습니다. 사전 확인된 트랜잭션은 거의 모두 온체인에 성공적으로 포함됩니다. 하지만 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이므로 실패한 트랜잭션은 스트리밍되거나 과금되지 않습니다.

가격은 크레딧 기반이며 다른 Helius WebSocket 구독과 동일하게 메시지당 10크레딧입니다. 스트리밍되는 트랜잭션마다 메시지 하나가 전송되며 Professional 이상 플랜에서 사용할 수 있습니다. 

이후 필터와 일치하는 예약 트랜잭션은 모두 간결한 바이너리 프레임으로 도착합니다. 트랜잭션 버전, 예약된 슬롯, 슬롯 내 트랜잭션 인덱스, 상태가 담긴 고정 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 전달로 수익 창출하기

Preconfirmations의 적용 범위는 검증인이 공급 측에 참여하는 네트워크 효과로 결정됩니다. 모든 검증인은 자신의 스트림을 Helius에 전달하고 수익을 얻을 수 있습니다. 블록 생성의 부산물을 수입원으로 전환하며, 검증인이 다른 방식으로 자신의 지위를 수익화하는지와 관계없이 작동합니다.

참여 스테이크가 많을수록 적용 범위가 넓어집니다. 참여하려는 검증인은 문의하거나 검증인용 Preconfirmations 문서에서 자세한 정보를 확인할 수 있습니다. 

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

Ethereum Preconfirmations은 트랜잭션이 향후 블록에 포함될 것을 보장하는 제안자의 약속입니다. 반면 Solana Preconfirmations은 현재 블록의 리더가 방금 로컬에서 실행한 트랜잭션에 대한 실시간 온체인 신호입니다. 전자는 더 일찍 확정하는 데 목적이 있고, 후자는 더 일찍 확인하는 데 목적이 있습니다.

Ethereum Preconfirmations

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

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

• 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 모델은 Ahead-of-Time(AOT) Transactions을 위한 Raiku의 컴퓨트 유닛 마켓플레이스입니다. 이를 통해 앱은 향후 블록에 포함될 공간을 보장받을 수 있습니다.

결론

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

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

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