Solana에서 트랜잭션을 랜딩하는 방법

트랜잭션

프로그램 실행은 클러스터에 제출된 트랜잭션에서 시작됩니다. 트랜잭션에는 다음이 포함됩니다.

• 읽거나 쓰려는 모든 계정의 배열
• 하나 이상의 명령어(즉, 가장 작은 실행 단위)
• 최근 블록해시
• 하나 이상의 서명

런타임은 트랜잭션에 포함된 각 명령어를 순서대로 원자적으로 처리합니다. 명령어의 어느 부분이라도 실패하면 전체 트랜잭션이 실패합니다.

블록해시란 무엇인가요?

"블록해시"는 슬롯의 최신 역사 증명(Proof of History, PoH) 해시입니다. Solana는 PoH를 신뢰할 수 있는 시계로 사용하므로 트랜잭션의 최근 블록해시는 타임스탬프로 볼 수 있습니다. 블록해시는 중복을 방지하고 트랜잭션에 유효 기간을 부여합니다. 블록해시가 너무 오래된 트랜잭션은 거부됩니다. 블록해시의 최대 유효 기간은 150개 블록, 즉 약 ~1분 19초입니다.

트랜잭션은 어떻게 제출되나요?

Solana는 원장에 추가되는 트랜잭션을 검증하는 검증인 그룹이 유지합니다. 이 그룹에서 리더 검증인을 선정해 원장에 항목을 추가합니다. 원장의 항목은 틱 또는 트랜잭션 항목일 수 있습니다. 원장은 클라이언트가 서명한 트랜잭션이 포함된 항목 목록을 보관합니다. 개념적으로 원장은 제네시스 블록까지 거슬러 올라갑니다. 하지만 이전 블록은 설계상 향후 블록 검증에 필요하지 않으므로, 실제 검증인의 원장에는 저장 공간을 줄이기 위해 최신 블록만 남아 있을 수 있습니다.

리더 검증인은 슬롯당 하나의 블록만 생성할 수 있으며, 블록해시는 각 블록을 식별하는 고유 식별자입니다. 블록해시는 이전 블록의 해시를 포함해 블록 내 모든 항목을 해싱한 값입니다. 특정 시점에 어떤 검증인이 현재 리더가 될지는 각 에포크가 시작되기 전, 일반적으로 약 이틀 전에 리더 일정으로 결정됩니다. 트랜잭션이 시작되면 현재 리더 검증인과 다음 리더 검증인에게 전달됩니다.

트랜잭션은 다음 방법으로 리더에게 제출할 수 있습니다. 

1. RPC 서버: RPC 제공자는 sendTransaction JSON-RPC 메서드로 트랜잭션을 제출할 수 있습니다. 트랜잭션을 받은 RPC 노드는 트랜잭션이 최종 확정되거나 블록해시가 만료될 때까지(150개 블록 또는 약 ~1분 19초 후) 2초마다 현재 리더와 다음 리더에게 UDP 패킷으로 전송을 시도합니다. 그때까지는 클라이언트와 중계 RPC 노드가 알고 있는 정보 외에 트랜잭션 기록이 없습니다. 
2. TPU 클라이언트: TPU 클라이언트는 트랜잭션만 제출합니다. 재브로드캐스트와 리더 전달은 클라이언트 소프트웨어가 처리해야 합니다.

sendTransaction 메서드를 사용하려면 문자열로 인코딩된 트랜잭션 객체를 전달해야 합니다. 그 밖의 선택적 매개변수는 다음과 같습니다.

1. encoding: 트랜잭션 데이터에 사용하는 인코딩으로 base58 또는 base64를 지정합니다. 
2. skipPreflight: 프리플라이트 검사에는 트랜잭션 서명 검증과 프리플라이트 커밋먼트가 지정한 뱅크 슬롯을 기준으로 한 트랜잭션 시뮬레이션이 포함됩니다. 프리플라이트 검사에 실패하면 오류가 반환됩니다. 이 기능의 기본 설정은 false이며, 프리플라이트 검사를 건너뛰지 않는다는 의미입니다.
3. preflightCommitment: 프리플라이트 검사 중 사용할 커밋먼트 수준을 지정합니다. 기본 커밋먼트 수준은 finalized이지만 문자열을 지정해 변경할 수 있습니다. 혼동을 일으키는 동작을 피하려면 커밋먼트와 프리플라이트 커밋먼트를 동일하게 지정하는 것이 좋습니다.
4. maxRetries: maxRetries 매개변수는 RPC 노드가 리더에게 트랜잭션 전송을 재시도할 최대 횟수를 결정합니다. 이 매개변수를 제공하지 않으면 RPC 노드는 트랜잭션이 최종 확정되거나 블록해시가 만료될 때까지 재시도합니다. 
5. minContextSlot: minContextSlot 매개변수는 프리플라이트 트랜잭션 검사를 수행할 최소 슬롯을 지정합니다.

트랜잭션은 어떻게 처리되나요?

검증인의 트랜잭션 처리 장치(Transaction Processing Unit, TPU)는 트랜잭션을 수신하고 서명을 검증한 후 실행하여 네트워크의 다른 검증인과 공유합니다.

TPU는 트랜잭션을 서로 다른 5단계로 처리합니다.

가져오기 단계

가져오기 단계는 트랜잭션 수신을 담당합니다. 수신된 트랜잭션은 다음 세 포트에 따라 분류됩니다.

• tpu: 토큰 전송, NFT 발행, 프로그램 명령어와 같은 일반 트랜잭션을 처리합니다.
• tpu_vote: 투표 트랜잭션만 처리합니다.
• tpu_forwards: 현재 리더가 모든 트랜잭션을 처리할 수 없으면 처리되지 않은 패킷을 다음 리더에게 전달합니다.

패킷은 128개씩 배치로 묶여 SigVerify 단계로 전달됩니다.

SigVerify 단계

SigVerify 단계는 패킷의 서명을 검증하고 검증에 실패한 패킷을 제거합니다. 투표 패킷과 일반 패킷은 서로 분리된 두 파이프라인에서 처리됩니다. 소프트웨어 관점에서 수신한 패킷에는 일부 메타데이터가 포함되어 있지만, 이 시점에는 해당 패킷이 트랜잭션인지 아직 명확하지 않습니다.

GPU가 설치되어 있으면 서명 검증에 사용됩니다. 트래픽이 많을 때 과도한 패킷을 처리하기 위해 IP 주소를 기준으로 패킷을 드롭하는 로직도 있습니다.

뱅킹 단계

이 단계는 트랜잭션 필터링과 처리를 담당합니다. 현재 독립적인 작업자 스레드 6개로 구성되며, 이 중 2개는 투표 스레드이고 4개는 비투표 스레드입니다. 일반 트랜잭션은 비투표 스레드에 추가됩니다. 각 스레드에는 우선순위 큐에서 충돌하지 않는 트랜잭션을 최대 64개까지 보관할 수 있는 로컬 버퍼가 있습니다. 그런 다음 Sealevel을 통해 이 트랜잭션들을 병렬로 처리합니다. 뱅킹 단계에 대해 자세히 알아보려면 이 동영상을 참고하세요.

역사 증명 서비스

PoH 서비스 모듈은 틱의 경과를 기록합니다. 각 틱은 시간 단위를 나타내며, 한 슬롯에는 64개의 틱이 있습니다. 뱅킹 단계에서 레코드를 받을 때까지 해시가 반복적으로 생성됩니다.

next_hash = hash(prev_hash, hash(transaction_ids))

이 레코드는 이후 항목으로 변환되어 브로드캐스트 단계를 통해 네트워크에 전파됩니다.

브로드캐스트 단계

PoH 서비스의 항목은 블록의 최소 단위인 샤드로 변환된 후 Turbine이라는 블록 전파 기법을 통해 나머지 네트워크로 전송됩니다. 개괄적으로 Turbine은 블록을 더 작은 조각으로 나누고 계층형 노드 구조를 통해 배포합니다. 노드는 다른 모든 노드와 연결될 필요가 없습니다. 선택된 일부 노드와만 통신하면 됩니다. Turbine과 작동 방식을 자세히 알아보려면 이 글을 참고하세요. 

트랜잭션은 왜 실패하나요?

잘못된 명령어나 사용자 정의 프로그램 오류로 인한 실패를 제외하면, 트랜잭션이 실패하는 이유는 다음과 같습니다.

네트워크 드롭

네트워킹 계층은 리더가 처리하기 전에 트랜잭션을 드롭할 수 있습니다. 가장 단순한 원인은 UDP 패킷 손실입니다. 또 다른 원인은 TPU의 fetch stage와 관련이 있습니다. 네트워크 부하가 높으면 검증인은 처리해야 할 트랜잭션 수로 인해 과부하될 수 있습니다. 검증인은 초과 트랜잭션을 다음 검증인의 tpu_forward 포트로 전달할 수 있습니다. 하지만 전달할 수 있는 데이터 양에는 제한이 있으며, 각 전달은 검증인 간 한 홉으로 제한됩니다. 즉, tpu_forwards 포트에서 수신된 트랜잭션은 다른 검증인에게 전달되지 않습니다. 대기 중인 재브로드캐스트 큐가 10,000개 트랜잭션을 초과하면 새로 제출된 트랜잭션은 드롭됩니다.

오래되거나 잘못된 블록해시 

모든 트랜잭션에는 역사 증명(PoH) 시계의 타임스탬프 역할을 하는 "최근 블록해시"가 있습니다. 이 블록해시는 검증인이 동일한 트랜잭션을 두 번 처리하지 않도록 하고, 트랜잭션이 처리된 시점과 순서를 추적합니다. 처리 중 블록해시가 유효하지 않으면 검증인은 트랜잭션을 거부합니다.

블록해시 만료

트랜잭션의 블록해시는 더 이상 충분히 "최근" 값으로 간주되지 않으면 만료됩니다. 트랜잭션을 처리할 때 Solana 검증인은 블록에서 해당 블록해시의 슬롯 번호를 찾습니다. 검증인이 블록해시의 슬롯 번호를 찾지 못하거나, 조회한 슬롯 번호가 처리 중인 블록의 슬롯 번호보다 151개 슬롯을 초과해 낮으면 트랜잭션이 거부됩니다. 기본적으로 Solana 트랜잭션은 일정 시간 내에 블록에 커밋되지 않으면 만료됩니다(약 ~1분 19초).

지연되는 RPC 노드

RPC를 통해 트랜잭션을 제출할 때 해당 RPC 풀이 나머지보다 앞서 있을 수 있습니다. 이 경우 풀 내 노드가 함께 작업해야 할 때 문제가 발생할 수 있습니다. 예를 들어 풀에서 앞선 부분에 recentBlockhash를 조회하고 지연된 부분에 트랜잭션을 제출하면, 노드가 앞선 블록해시를 인식하지 못해 트랜잭션을 거부합니다. sendTransaction에서 프리플라이트 검사를 활성화하면 트랜잭션 제출 시 이를 감지할 수 있습니다.

일시적인 네트워크 포크

일시적인 네트워크 포크로 인해 트랜잭션이 드롭될 수도 있습니다. 검증인이 뱅킹 단계에서 블록을 늦게 재생하면 소수 포크가 생성될 수 있습니다. 클라이언트가 트랜잭션을 생성할 때 소수 포크에만 존재하는 recentBlockhash를 참조할 수 있습니다. 트랜잭션이 제출된 후 처리되기 전에 클러스터가 소수 포크에서 이탈할 수 있습니다. 이 경우 블록해시를 찾을 수 없어 트랜잭션이 드롭됩니다.

트랜잭션을 어떻게 랜딩하나요?

확정 문제를 진단하려면 트랜잭션 만료를 이해해야 합니다. 트랜잭션 성공 가능성을 높이려면 다음 단계를 따르세요.

요약

• 커밋먼트 “confirmed” 또는 “finalized”로 최신 블록해시를 가져옵니다.
• skipPreflight를 true로 설정합니다.
• 요청하는 컴퓨트 유닛 수를 최적화합니다.
• 우선순위 수수료를 추가하고 동적으로 계산합니다.
• maxRetries를 0로 설정하고, 트랜잭션 전송을 위한 사용자 정의 재시도 로직을 추가합니다.
• 스테이킹 연결을 검토합니다.
• 시간에 민감하지 않은 트랜잭션이라면 내구성 논스를 사용합니다.

블록해시

트랜잭션을 검증인이 처리할 수 있는 시간은 제한되어 있습니다. 검증인이 처리하기 전에 트랜잭션과 연결된 블록해시가 만료되면 트랜잭션이 취소됩니다. 트랜잭션이 정상적으로 처리되게 하려면 최근 블록해시와 함께 전송해야 합니다. 검증인이 트랜잭션을 처리하기 전에 블록해시가 만료되면 새 블록해시로 다시 시도하여 성공적으로 처리되게 할 수 있습니다. 다음 두 가지 방법을 사용할 수 있습니다. 

1. 새 커밋먼트 수준 설정:

최신 블록해시를 가져올 때 권장되는 RPC API 메서드는 getLatestBlockhash입니다. 기본적으로 이 메서드는 finalized 커밋먼트 수준을 사용해 가장 최근에 최종 확정된 블록의 블록해시를 반환합니다. 이 커밋먼트 수준은 해당 블록 위에 최소 31개의 확정된 블록이 추가되었음을 나타냅니다. 따라서 드롭된 포크에 속한 블록해시를 사용할 위험이 없습니다. 하지만 일반적으로 가장 최근에 확인된 블록과 최종 확정된 블록 사이에는 최소 32개 슬롯의 차이가 있습니다. 이 절충으로 트랜잭션의 유효 기간이 약 13초 줄어들며, 클러스터 상태가 불안정할 때는 더 크게 줄어들 수 있습니다. 

커밋먼트 매개변수를 다른 수준으로 설정해 블록해시의 커밋먼트를 재정의할 수 있습니다. RPC 요청에는 confirmed 커밋먼트 수준을 권장합니다. 일반적으로 processed 커밋먼트 수준보다 몇 슬롯만 뒤처지고 드롭된 포크에 속할 가능성이 낮기 때문입니다. processed 커밋먼트 수준은 다른 수준보다 최신 블록해시를 가져오지만 권장하지 않습니다. Solana 프로토콜의 포크로 인해 약 5%의 블록이 클러스터에서 최종 확정되지 않기 때문입니다. 트랜잭션이 드롭된 포크에 속한 블록해시를 사용하면 최종 확정된 블록체인의 어떤 블록에서도 최근 값으로 간주되지 않습니다.

2. 새로운 최근 블록해시를 자주 폴링:

getLatestBlockhash 메서드로 최신 블록해시를 자주(60초마다) 가져와 저장하는 스크립트를 추가하세요. 그러면 사용자가 트랜잭션을 시작할 때 애플리케이션에 최신 블록해시가 준비되어 있습니다. 지갑도 새 블록해시를 자주 폴링하고 트랜잭션 서명 직전에 최근 블록해시를 교체해 최대한 최신 상태를 유지해야 합니다.

프리플라이트 건너뛰기

트랜잭션을 제출하기 전에 다음 프리플라이트 검사가 수행됩니다.

• 트랜잭션 서명을 검증합니다.
• 프리플라이트 커밋먼트가 지정한 뱅크 슬롯을 기준으로 트랜잭션을 시뮬레이션합니다. 실패하면 오류가 반환됩니다. 

시뮬레이션을 위해 선택한 블록이 트랜잭션의 블록해시에 사용된 블록보다 오래된 경우, 시뮬레이션은 악명 높은 “blockhash not found” 오류와 함께 실패합니다. 

트랜잭션 서명이 검증되었고 다른 오류가 없다고 확신한다면 프리플라이트 검사를 건너뛸 수 있습니다. skipPreflight 매개변수를 사용하더라도 sendTransaction 및 simulateTransaction 요청 모두에서 preflightCommitment 매개변수를 트랜잭션 블록해시를 가져올 때 사용한 커밋먼트 수준과 항상 동일하게 설정하세요.

컴퓨트 유닛

트랜잭션이 네트워크에서 확정되면 블록에서 사용할 수 있는 전체 컴퓨트 유닛(CU)의 일부를 소비합니다. 현재 블록의 전체 컴퓨트 한도는 48M CU입니다. 개발자는 트랜잭션의 컴퓨트 유닛 예산을 지정할 수 있습니다. 예산을 설정하지 않으면 기본값인 200,000이 사용됩니다. 필요한 양보다 많은 예산을 요청해도 불이익이 없기 때문에 많은 트랜잭션이 CU 예산 전체를 사용하지 않습니다. 하지만 컴퓨트 유닛을 처음부터 과도하게 요청하면 트랜잭션을 효율적으로 스케줄링하기 어려워질 수 있습니다. 스케줄러는 트랜잭션이 실행되기 전까지 블록에 남은 컴퓨트 양을 알 수 없기 때문입니다. 이를 방지하려면 개발자는 트랜잭션 요구 사항에 맞도록 범위를 좁힌 CU 요청을 설정해야 합니다. 컴퓨트 유닛 예산을 최적화하려면 이 가이드를 참고하세요. 예정된 Solana 클라이언트 v1.18 업데이트에서는 더 적은 컴퓨트 유닛을 요구하는 트랜잭션에 더 높은 우선순위가 부여됩니다.

컴퓨트 유닛(CU) 사용량을 최적화하면 다음과 같은 이점이 있습니다.

• 더 작은 트랜잭션은 블록에 포함될 가능성이 높습니다.
• 명령어 비용이 낮아지면 프로그램의 결합성이 높아집니다.
• 전체 블록 사용량이 줄어 더 많은 트랜잭션을 블록에 포함할 수 있습니다.

우선순위 수수료 구현

우선순위 수수료는 기본 트랜잭션 수수료에 추가해 검증인이 트랜잭션을 우선 처리하도록 할 수 있습니다. 수수료는 컴퓨트 유닛당 마이크로 램포트(예: 소량의 SOL)로 책정됩니다. 검증인 노드가 네트워크의 블록에 트랜잭션을 포함할 경제적 유인을 제공하기 위해 트랜잭션에 추가됩니다.

다만 우선순위 수수료로 지불해야 할 금액에는 적정 한도가 있습니다. 일반적인 수수료보다 많이 지불해도 트랜잭션 성공 확률은 높아지지 않습니다. 따라서 과도한 지불을 피하면서 경쟁력을 유지할 수 있도록 적정 금액의 우선순위 수수료를 동적으로 계산하는 것이 좋습니다. 통합 과정은 간단합니다. 우선순위 수수료에 관한 공식 문서를 참고하거나 바로 사용할 수 있는 Helius API를 이용하세요.

견고한 재시도 로직 구현

네트워크가 혼잡할 때는 트랜잭션 실패를 처리하고 수동으로 재시도하는 사용자 정의 로직을 코드에 구현하세요. 이렇게 하려면 sendTransaction로 트랜잭션을 제출할 때 maxRetries 매개변수를 0로 설정하세요. 트랜잭션 재시도에는 다음과 같은 방법을 사용할 수 있습니다.

• 서로 다른 커밋먼트 수준으로 transaction status를 폴링하고, 스팸을 방지하기 위해 지수 백오프 메커니즘을 사용해 확정될 때까지 서명된 동일 트랜잭션을 계속 사용합니다. 또는 시간 초과가 발생할 때까지 일정한 간격으로 트랜잭션을 제출할 수 있습니다.
• getLatestBlockhash method에서 받은 lastValidBlockHeight를 저장합니다. 그런 다음 클러스터의 블록 높이를 폴링하고 현재 블록 높이가 lastValidBlockHeight를 초과하면 트랜잭션을 수동으로 재시도합니다. getLatestBlockhash로 폴링할 때는 원하는 커밋먼트 수준을 지정하는 것이 좋습니다. 커밋먼트를 confirmed(투표 완료) 또는 finalized(confirmed 후 ~30개 블록)로 설정하면 소수 포크에서 블록해시를 폴링하는 일을 피할 수 있습니다.

스테이킹 연결

리더의 네트워크 대역폭은 제한되어 있습니다. 이를 효과적으로 사용하려면 출처를 고려하지 않고 선착순으로 트랜잭션을 무조건 수락하지 않도록 스테이크 가중치를 적용해야 합니다. Solana는 지분 증명 네트워크이므로 트랜잭션의 서비스 품질을 높이기 위해 스테이크 가중치 사용을 확대하는 것이 자연스럽습니다. 이는 지분이 0.5%인 노드가 패킷의 최소 0.5%를 리더에게 보낼 수 있다는 의미입니다. 나머지 네트워크와 잔여 지분의 어떠한 조합도 이를 완전히 밀어낼 수 없습니다. 이 메커니즘을 스테이크 가중 서비스 품질(Stake-Weighted Quality of Service, SWQoS)이라고 합니다.

Helius는 유료 플랜에 스테이킹 연결을 제공합니다. 자세한 내용은 Solana에서 트랜잭션 전송 문서를 참고하세요.

내구성 논스

내구성 논스를 사용하면 미래 어느 시점에든 제출할 수 있는 트랜잭션을 생성하고 서명할 수 있습니다. 트랜잭션 서명을 생성하는 데 더 많은 시간이 필요한 수탁 서비스와 같은 사용 사례에 활용됩니다. 트랜잭션이 시간에 민감하지 않다면 이 방법으로 트랜잭션 recentBlockhash의 짧은 유효 기간을 우회할 수 있습니다.

내구성 트랜잭션을 사용하려면 온체인에 특수한 "논스" 계정을 생성하고 그 안에 "내구성 블록해시"를 저장하는 명령어를 호출하는 트랜잭션을 제출해야 합니다. 논스 계정은 논스 값을 저장합니다. 논스 계정이 아직 사용되지 않았다면 다음 두 규칙에 따라 내구성 트랜잭션을 생성할 수 있습니다.

• 명령어 목록은 온체인 논스 계정을 불러오는 "advance nonce" 시스템 명령어로 시작해야 합니다.
• 트랜잭션의 블록해시는 온체인 논스 계정에 저장된 내구성 블록해시와 같아야 합니다.

CLI와 Web3.js로 내구성 논스를 구현하는 방법은 이 글을 참고하세요.

트랜잭션 제출을 위한 Helius의 접근 방식

sendTransaction 요청은 가장 가까운 RPC 노드로 자동 라우팅됩니다. maxRetries를 지정하지 않으면 블록해시가 만료될 때까지 2초마다 트랜잭션을 재시도합니다. maxRetries를 0으로 설정하고 트랜잭션이 확정될 때까지 2초마다 직접 재브로드캐스트하는 것이 좋습니다. 

현재의 네트워크 혼잡에 대응하기 위해 사용자 트랜잭션의 랜딩 성공률을 높이는 작업을 지속하고 있습니다. sendTransaction 요청의 요청 한도를 낮췄습니다. 이는 혼잡을 관리하고 검증인에 대한 스팸을 방지하기 위한 조치입니다. 한도는 여기에서 확인할 수 있습니다.

또한 유료 플랜의 고품질 트래픽을 스테이킹 연결을 통해 라우팅하고 있습니다. 이러한 스테이킹 연결에는 자체 검증인을 활용합니다. 총 우선순위 수수료가 10,000 Lamports(클러스터 중앙값) 이상이면 고품질 트래픽으로 간주합니다.

검증인에게 고품질 트래픽을 제공하기 위해 총수수료가 10,000 Lamports를 초과하도록 요구합니다. 검증인은 수수료가 낮은 트랜잭션을 보내는 트래픽 소스에 요청 한도를 적용하거나 아예 차단하기 시작했습니다.

스테이킹 연결을 사용하면 트랜잭션 랜딩 성공률을 크게 높일 수 있습니다. 트랜잭션 생성 시 우선순위 수수료를 설정하는 방법은 이 글을 참고하세요.

권장 사항

초급/중급 사용자

skipPreflight를 false로 설정하는 것이 좋습니다. 프리플라이트 검사에는 트랜잭션 서명 검증과 프리플라이트 커밋먼트가 지정한 뱅크 슬롯을 기준으로 한 트랜잭션 시뮬레이션이 포함됩니다. 프리플라이트 검사에 실패하면 오류가 반환됩니다. 프리플라이트 검사를 사용하지 않으면 잘못된 구성으로 인해 트랜잭션이 드롭될 수 있습니다.

고급 사용자

가능한 한 가장 낮은 지연 시간이 필요한 고급 사용자는 skipPreflight를 true로 설정해야 합니다. 단, 트랜잭션이 올바르게 구성되었는지 직접 확인해야 합니다. 

결론

혼잡한 상황에서 Solana 네트워크에 트랜잭션을 성공적으로 랜딩하려면 네트워크 아키텍처와 트랜잭션 처리 메커니즘을 세밀하게 이해해야 합니다. 트랜잭션의 고유성과 적시성을 보장하는 블록해시의 역할, RPC 서버 또는 TPU 클라이언트를 통한 트랜잭션 제출 과정, skipPreflight, preflightCommitment, maxRetries 같은 매개변수의 올바른 설정 등 핵심 개념을 이해하면 트랜잭션 성능을 크게 개선할 수 있습니다. 사용자 정의 재시도 메커니즘을 구현하고 스테이킹 연결을 활용하면 성공률을 높일 수 있습니다.

또한 출시 예정인 v1.18 클라이언트에서 볼 수 있듯이, 네트워크의 현재 한계와 이를 해결하기 위한 Anza의 지속적인 노력을 파악하는 것이 중요합니다. 네트워크가 발전하고 확장됨에 따라 최신 정보를 확인하고 변화에 적응하는 것이 효과적인 상호작용의 핵심입니다. 

도움이나 지원이 필요하면 언제든 Discord로 문의하세요. 아래에 이메일 주소를 입력하면 Solana의 새로운 소식을 놓치지 않고 받아볼 수 있습니다. 더 자세히 알아볼 준비가 되셨나요? 지금 Helius 블로그의 최신 글을 살펴보고 Solana 여정을 이어가세요.

자료

• 트랜잭션 – Solana Cookbook
• Solana의 블록 최적화
• Solana 검증인 101: Jito Labs의 트랜잭션 처리
• Solana 검증인의 트랜잭션 처리 장치
• Solana의 스케줄러
• Solana의 트랜잭션 확정
• Solana의 트랜잭션 재시도
• 우선순위 수수료 사용 방법
• 컴퓨트 최적화 방법
• 우선순위 수수료와 컴퓨트 유닛
• 내구성 트랜잭션 논스
• 논스를 사용한 내구성 및 오프라인 트랜잭션 서명
• Solana 트랜잭션: Helius의 내구성 논스