요약
Helius의 스테이킹 연결은 100% 트랜잭션 전달을 보장하며 확인 시간을 최소화합니다. 스테이킹 연결로 트랜잭션 도착률을 최적화하기 위해 다음 모범 사례를 권장합니다:- “confirmed” 커밋을 사용하여 최신 블록해시 가져오기
- 우선 수수료를 추가하고 동적으로 계산
- 계산 유닛(CU) 사용 최적화
maxRetries를 0으로 설정하고 강력한 재시도 로직 구현skipPreflight를true로 설정하여 전송 (선택 사항)
트레이더를 위한 권장 최적화
지연 시간에 민감한 거래 사용 사례의 경우, Sender 사용을 권장합니다. 그러나 스테이킹 연결을 사용하고 가능한 최저 지연 시간으로 설정을 최적화하려면 위에서 언급한 모범 사례를 적용하는 것 외에도 다음 최적화를 권장합니다:- 클라이언트 서버(트랜잭션을 전송하는 기기)는 미국 동부 또는 서유럽에 위치해야 합니다.
- Helius 트랜잭션 전송 서버와 협력하려면 FRA 또는 PIT를 선택하세요.
- 검증자 네트워크에서 멀리 떨어진 지역(LATAM, 남아프리카 등)에서 전송하는 것을 피하세요.
- 말단 지연 시간을 최소화하기 위해 Helius 지역 캐시를 예열하세요.
- 지역별로 하나의 예열 스레드만 필요하며 그 이상은 효과가 없습니다.
getHealthRPC 호출을 트랜잭션을 전송하는 것과 동일한 엔드포인트 및 API 키를 사용하여 매초 한 번씩 전송하세요.
스마트 트랜잭션 전송
Helius Node.js 및 Rust SDK는 스마트 트랜잭션을 보낼 수 있습니다. 이 새로운 방법은 최적화된 트랜잭션을 구축하고 전송하며 확인 상태를 처리합니다. 사용자는 트랜잭션 발송 옵션을 구성할 수 있으며, 트랜잭션이 사전 비행 검사를 건너뛸지 여부를 선택할 수 있습니다. 기본적으로 사용자는 자신이 실행하려는 키페어와 지침을 제공해야 하며 나머지는 우리가 처리합니다. 우리는 다음을 수행합니다:- 최신 블록해시 가져오기
- 초기 트랜잭션 구축
- 사용된 계산 유닛(CU)을 가져오기 위해 초기 트랜잭션을 시뮬레이션
- 앞 단계에서 소비된 CU에 약간의 여유를 두어 CU 한도 설정
- 우선 수수료 API에서 Helius 추천 우선 수수료 가져오기
- 우선 수수료(CU당 마이크로 라모프)로 Helius 추천 수수료 설정
- 추천 수수료가 몇 초 내에 변경될 경우를 대비하여 작은 버퍼 수수료 추가
- 최적화된 트랜잭션 구축 및 전송
- 성공 시 트랜잭션 서명 반환
스테이킹 연결에 권장값(또는 그 이상)을 요구하는 것은 Helius가 고품질의 트랜잭션을 보내며 검증자가 속도를 제한하지 않도록 보장합니다.
Node.js SDK
sendSmartTransaction 메서드는 Helius Node.js SDK에서 버전 >= 1.3.2에서 사용할 수 있습니다. 최신 버전의 SDK로 업데이트하려면 npm update helius-sdk를 실행하세요.
이 예제는 선택한 계정으로 SOL을 전송합니다. sendSmartTransaction를 사용하여 사전 비행 검사를 건너뛰지 않는 최적화된 트랜잭션을 전송합니다:
Rust SDK
send_smart_transaction 메서드는 Rust SDK에서 버전 >= 0.1.5에서 사용할 수 있습니다. 최신 버전의 SDK로 업데이트하려면 cargo update helius를 실행하세요.
다음 예제는 0.01 SOL을 선택한 계정으로 전송합니다.
send_smart_transaction를 활용하여 사전 비행 검사를 건너뛰고 필요한 경우 두 번 재시도하는 최적화된 트랜잭션을 전송합니다:
SDK 없이 트랜잭션 보내기
하나의 SDK로 스마트 트랜잭션을 전송하는 것을 권장하지만, SDK를 사용하지 않고도 동일한 기능을 구현할 수 있습니다. Node.js SDK와 Rust SDK는 모두 오픈 소스이므로, 스마트 트랜잭션 발송 기능의 기본 코드는 언제든지 볼 수 있습니다.초기 트랜잭션 준비 및 구축
먼저 초기 트랜잭션을 준비하고 구축하세요. 여기에는 지침 세트로 새 트랜잭션을 생성하고, 최신 블록해시를 추가하며, 수수료 지불자를 할당하는 것이 포함됩니다. 버전이 있는 트랜잭션의 경우TransactionMessage를 생성하고 조회 테이블이 있는 경우 컴파일하세요.
그런 다음 새 버전 트랜잭션을 생성하고 서명하세요. 이는 트랜잭션을 시뮬레이션할 때 필수적입니다. 트랜잭션은 서명되어야 합니다.
예를 들어 버전이 있는 트랜잭션을 준비하려면:
트랜잭션의 계산 유닛 (CU) 사용 최적화
트랜잭션의 계산 유닛 (CU) 사용 최적화하기 위해,simulateTransaction RPC 메서드를 사용하여 트랜잭션을 시뮬레이션할 수 있습니다.
트랜잭션 시뮬레이션은 사용된 CU의 양을 반환하므로 이 값을 사용하여 우리의 계산 한도를 적절히 설정할 수 있습니다.
먼저 원하는 지침과 1.4m CU로 계산 한도를 설정하는 지침을 추가하여 시험 트랜잭션을 사용해 보는 것이 좋습니다.
이렇게 해야 트랜잭션 시뮬레이션이 성공적으로 완료됩니다.
예를 들어:
트랜잭션 직렬화 및 인코딩
이 과정은 비교적 간단합니다. 먼저 트랜잭션을 직렬화하려면, Transaction 및 VersionedTransaction 유형 모두에.serialize() 메서드가 있습니다. 그런 다음 bs58 패키지를 사용하여 트랜잭션을 인코딩하세요.
코드 조각은 bs58.encode(txt.serialize());과 같아야 합니다.
올바른 우선 수수료 설정
먼저 Priority Fee API를 사용하여 우선 수수료를 추정하세요. 트랜잭션을 전달하고 권장 매개변수를 통해 Helius 추천 수수료를 받기를 원합니다:최적화된 트랜잭션 구축 및 전송
이 단계는 거의 첫 단계의 반복입니다. 그러나 초기 지침 배열은 계산 유닛 한도 및 가격을 최적으로 설정하기 위해 두 개의 지침을 추가하기 위해 변경되었습니다. 이제 트랜잭션을 보내세요. 사전 비행 검사를 사용 여부 및 기타 전송 옵션을 변경 여부는 중요하지 않습니다 — 트랜잭션은 모든 유료 플랜에 대해 우리의 스테이킹 연결을 통해 라우팅됩니다.트랜잭션의 상태를 폴링 및 재방송
sendTransaction RPC 메서드에는 RPC의 기본 재시도 로직을 재정의할 수 있는 maxRetries 매개변수가 있어서 개발자가 재시도 프로세스를 보다 제어할 수 있습니다.
getLatestBlockhash를 통해 현재 블록해시를 가져오고 lastValidBlockHeight를 저장하며 블록해시가 만료될 때까지 트랜잭션을 재시도하는 것이 일반적인 패턴입니다.
블록해시가 더 이상 유효하지 않을 때만 트랜잭션에 다시 서명해야 하며, 그렇지 않을 경우 두 트랜잭션 모두 네트워크에 의해 수락될 수 있습니다.
트랜잭션이 전송된 후, 네트워크가 이를 처리하고 확인했는지 상태를 확인하여 다시 시도하기 전에 그 상태를 폴링하는 것이 중요합니다. getSignatureStatuses RPC 메서드를 사용하여 여러 트랜잭션의 확인 상태를 확인하세요.
@solana/web3.js SDK에도 여러 서명의 현재 상태를 가져올 수 있는 getSignatureStatuses 메서드가 Connection 클래스에 있습니다.
sendSmartTransaction의 폴링 및 재방송 처리 방식
sendSmartTransaction 메서드는 60초의 타임아웃 기간을 가집니다. 블록해시는 150 슬롯 동안 유효하며, 이상적인 400ms 슬롯을 가정하면 트랜잭션 블록해시는 1분 후에 무효화된다고 합리적으로 가정할 수 있습니다.
이 메서드는 트랜잭션을 전송하고 이 타임아웃 기간을 사용하여 서명을 폴링합니다:
txtSig는 방금 전송된 트랜잭션의 서명으로 설정됩니다.
그런 다음 pollTransactionConfirmation() 메서드를 사용하여 트랜잭션의 확인 상태를 폴링합니다. 이 메서드는 최대 3번, 5초마다 트랜잭션의 상태를 확인합니다.
이 시간 내에 트랜잭션이 확인되지 않으면 오류가 반환됩니다: