거래 v1에서의 변화
레거시 및 v0 거래는 변경되지 않습니다. 대부분의 통합에서 거래 v1에 대한 두 가지 주요 사항은 다음과 같습니다:- 수신하려면 선택해야 합니다. 전체 거래 데이터를 요청하려면
maxSupportedTransactionVersion: 1가 필요하며, 클라이언트 라이브러리는 v1을 디시리얼라이즈할 수 있는 버전이 필요합니다. - 컴퓨팅 예산이 메시지 헤더로 이동합니다. v1 메시지는
transactionConfig객체를 가지고 있으며computeUnitLimit,heapSize,loadedAccountsDataSizeLimit,priorityFee를 포함합니다. v1 거래에는 ComputeBudget 프로그램 명령어가 없습니다.
"version": 1와 message에 transactionConfig를 포함합니다:
"priorityFee": 50000는 이 거래가 총 50,000 람포트를 지불함을 의미합니다. null 필드는 발신자가 설정하지 않았음을 의미합니다. 레거시 및 v0 메시지는 transactionConfig를 전혀 포함하지 않습니다.
maxSupportedTransactionVersion을 1로 설정
전체 거래 데이터를 반환하는 모든 요청은 처리할 수 있는 가장 높은 거래 버전을 선언해야 합니다. 다음에maxSupportedTransactionVersion: 1를 설정하세요:
getTransactiongetBlockgetTransactionsForAddresswithtransactionDetails: "full"transactionSubscribewithtransactionDetails: "accounts"or"full"blockSubscribe
0로 설정한 요청은 v1 거래에 도달하면 JSON-RPC 오류 -32015로 실패합니다:
getBlock의 경우, 블록 내 어디든지 v1 거래가 포함되어 있으면 전체 요청이 실패합니다. 로그에서 -32015를 확인하면 프로젝트가 이미 버전별 거래에서 실패하고 있음을 알 수 있습니다.
값을 올리기 전에 SDK 업그레이드
maxSupportedTransactionVersion: 1를 설정하면 노드가 v1 거래를 반환하도록 지시합니다. 클라이언트 라이브러리는 여전히 이를 디시리얼라이즈해야 합니다. 먼저 업그레이드하고, 그런 다음 매개변수를 변경하십시오:
구형
VersionedTransaction.deserialize 구현은 JavaScript에서 레거시 및 v0만 처리하며, 선행 0x81 바이트에서 오류를 발생시킵니다. 구형 Yellowstone 프로토는 v1 메시지 필드 이전에 있으므로, 해당 버전의 gRPC 소비자는 transactionConfig를 전혀 보지 않습니다. Go gRPC 클라이언트를 위해서는 최신 Yellowstone 프로토 기준으로 재생성하고 solana-storage-proto를 사용합니다.
transactionConfig에서 우선 수수료 읽기
ComputeBudget 프로그램 명령어 (ComputeBudget111111111111111111111111111111, setComputeUnitPrice, setComputeUnitLimit)를 스캔하여 거래의 우선 수수료를 추정하는 코드는 v1 거래를 모두 0으로 지불한다고 읽습니다. v1에서는 값이 message.transactionConfig에 있으며 단위가 다릅니다:
레거시
price × computeUnitLimit ÷ 1e6 수학을 priorityFee로 포팅하지 마세요. 이미 총합입니다.
priority-fee.ts
transactionConfig (또는 version === 1)에 따라 분기하십시오. 왜냐하면 우선 수수료가 없는 레거시 거래에도 역시 지시가 없기 때문입니다.
v1 인식 파서를 사용하여 원시 거래 바이트 해독
이 섹션은 preconfSubscribe, preprocessedSubscribe 또는base64-encoded RPC 응답에서 원시 거래 바이트를 사용하는 경우에만 적용됩니다. json 또는 jsonParsed 응답을 사용하는 경우 이 단계를 건너뛰세요.
거래 v1은 두 가지 방식으로 와이어 레이아웃을 변경합니다:
- 버전 바이트. v1 거래는
0x81(십진수 129)로 시작합니다. v0 거래는0x80로 시작합니다. - 서명이 끝으로 이동합니다. 레거시 및 v0는 서명을 먼저 두고, 그 다음 메시지를 두지만 거래 v1은 메시지를 먼저 두고 서명을 마지막에 두므로, 선행 서명 배열을 기대하는
bincode스타일 디코더가 v1 바이트에서 실패합니다.

세 개의 주소와 하나의 명령어가 있는 거래 v1의 바이트 레이아웃입니다. 서명은 메시지 후 끝에 위치합니다.
- Rust:
agave-transaction-view는 레거시, v0, v1을 현장에 디코드합니다. 현재 Solana SDK에서 사용하는 bincode 호환 시리얼라이저인wincode도 v1을VersionedTransaction로 디코드합니다. - 자바스크립트 / 타입스크립트:
@solana/kit8.0+ 또는@solana/web3.jsv3.
0x81는 v1을 의미하며 서명이 메시지 뒤에 따라온다는 것을 의미합니다.
체크리스트
getBlock,getTransaction,getTransactionsForAddress,transactionSubscribe, 그리고blockSubscribe를 포함하여 원시 JSON-RPC 본문과connection.getParsedTransaction같은 SDK 래퍼를 그랩합니다.- v1 지원 SDK로 업그레이드합니다.
- 1단계에서 찾은 모든 호출에
maxSupportedTransactionVersion: 1를 설정합니다. - ComputeBudget 명령어 스캔을
transactionConfig확인으로 대체하고priorityFee를 총 람포트로 취급합니다. bincode스타일 원시 디코더를agave-transaction-view나 업그레이드된 SDK로 대체합니다.- 위 테이블의 버전으로 스트리밍 종속성을 증가시킵니다.
- 변경 후 로그에서
-32015를 검색하여 여전히 실패하는 것이 없는지 확인합니다.
관련
getTransaction 안내서
단일 거래를 가져오기 위한 매개변수, 응답 형식 및 예시.
getBlock 안내서
포함된 모든 거래를 포함한 전체 블록 가져오기.
getTransactionsForAddress
한 번의 호출로 주소에 대한 필터링되고 페이지가 매겨진 거래 기록.
Agave 4.2 마이그레이션 체크리스트
모든 Agave 4.2 중단 변경 사항과 수정 단계.