- Sử dụng kết nối có stake (mặc định)
- Sử dụng các dịch vụ chuyên biệt để đưa giao dịch vào chuỗi như Sender (khuyến nghị)
Tóm tắt
Kết nối có stake của Helius đảm bảo chuyển giao 100% giao dịch với thời gian xác nhận tối thiểu. Để tối ưu hóa tỷ lệ đưa giao dịch vào chuỗi bằng kết nối có stake, chúng tôi khuyến nghị các phương pháp hay nhất sau:- Sử dụng commitment “confirmed” để truy xuất blockhash mới nhất
- Thêm phí ưu tiên và tính toán phí theo cách linh hoạt
- Tối ưu hóa mức sử dụng đơn vị tính toán (CU)
- Đặt
maxRetriesthành 0 và triển khai logic thử lại mạnh mẽ - Gửi với
skipPreflightđược đặt thànhtrue(tùy chọn)
Các biện pháp tối ưu hóa được khuyến nghị cho nhà giao dịch
Đối với các trường hợp giao dịch nhạy cảm với độ trễ, chúng tôi khuyến nghị sử dụng Sender. Tuy nhiên, nếu đang sử dụng kết nối có stake và muốn tối ưu hóa cấu hình để đạt độ trễ thấp nhất có thể, bạn nên áp dụng các biện pháp tối ưu hóa sau (ngoài các phương pháp hay nhất nêu trên):- Máy chủ máy khách của bạn (máy dùng để gửi giao dịch) nên được đặt tại miền Đông Hoa Kỳ hoặc Tây Âu.
- Chọn FRA hoặc PIT nếu bạn muốn đặt cùng vị trí với các máy chủ gửi giao dịch của Helius.
- Tránh gửi từ các khu vực cách xa mạng lưới trình xác thực (ví dụ: Mỹ Latinh, Nam Phi).
- Làm nóng bộ nhớ đệm theo khu vực của Helius để giảm thiểu độ trễ đuôi.
- Mỗi khu vực chỉ cần một luồng làm nóng — sử dụng thêm sẽ không mang lại lợi ích nào.
- Gửi một lệnh gọi RPC
getHealthmỗi giây bằng cùng điểm cuối và khóa API mà bạn dùng để gửi giao dịch.
Gửi giao dịch thông minh
Cả SDK TypeScript và Rust của Helius đều có thể gửi giao dịch thông minh. Phương thức mới này tạo và gửi một giao dịch đã tối ưu hóa, đồng thời xử lý trạng thái xác nhận của giao dịch. Người dùng có thể cấu hình các tùy chọn gửi của giao dịch, chẳng hạn như có bỏ qua bước kiểm tra trước khi thực thi hay không. Ở mức cơ bản nhất, người dùng chỉ cần cung cấp cặp khóa và các chỉ thị muốn thực thi, chúng tôi sẽ xử lý phần còn lại. Chúng tôi sẽ:- Truy xuất blockhash mới nhất
- Tạo giao dịch ban đầu
- Mô phỏng giao dịch ban đầu để lấy số đơn vị tính toán (CU) đã tiêu thụ
- Đặt giới hạn CU bằng số CU đã tiêu thụ ở bước trước, cộng thêm một khoảng dự phòng
- Lấy phí ưu tiên do Helius khuyến nghị thông qua Priority Fee API
- Đặt phí ưu tiên (microlamport trên mỗi CU) thành mức phí do Helius khuyến nghị
- Thêm một khoản phí dự phòng nhỏ phòng trường hợp mức phí được khuyến nghị thay đổi trong vài giây tiếp theo
- Tạo và gửi giao dịch đã tối ưu hóa
- Trả về chữ ký giao dịch nếu thành công
Việc yêu cầu mức phí được khuyến nghị (hoặc cao hơn) cho các kết nối có stake đảm bảo Helius gửi các giao dịch chất lượng cao và không bị trình xác thực giới hạn tốc độ.
SDK TypeScript
Phương thứcsendSmartTransaction có trong SDK TypeScript của Helius từ phiên bản >= 1.3.2. Để cập nhật lên phiên bản SDK mới hơn, hãy chạy npm update helius-sdk.
Ví dụ này chuyển SOL đến một tài khoản do bạn chọn. Ví dụ sử dụng sendSmartTransaction để gửi một giao dịch đã tối ưu hóa mà không bỏ qua bước kiểm tra trước khi thực thi:
SDK Rust
Phương thứcsend_smart_transaction có trong SDK Rust của chúng tôi từ phiên bản >= 0.1.5. Để cập nhật lên phiên bản SDK mới hơn, hãy chạy cargo update helius.
Ví dụ sau chuyển 0.01 SOL đến một tài khoản do bạn chọn.
Ví dụ sử dụng send_smart_transaction để gửi một giao dịch đã tối ưu hóa, bỏ qua bước kiểm tra trước khi thực thi và thử lại hai lần nếu cần:
Gửi giao dịch mà không dùng SDK
Chúng tôi khuyến nghị gửi giao dịch thông minh bằng một trong các SDK của mình, nhưng bạn cũng có thể đạt được chức năng tương tự mà không cần sử dụng SDK. Cả SDK TypeScript và SDK Rust đều là mã nguồn mở, vì vậy bạn có thể xem mã nguồn cơ sở của chức năng gửi giao dịch thông minh bất cứ lúc nào.Chuẩn bị và tạo giao dịch ban đầu
Trước tiên, hãy chuẩn bị và tạo giao dịch ban đầu. Quá trình này bao gồm việc tạo một giao dịch mới với một tập hợp chỉ thị, thêm blockhash gần đây và chỉ định người trả phí. Đối với giao dịch có phiên bản, hãy tạo mộtTransactionMessage và biên dịch giao dịch đó với các bảng tra cứu nếu có.
Sau đó, tạo một giao dịch có phiên bản mới và ký giao dịch đó — thao tác này cần thiết cho bước tiếp theo khi chúng ta mô phỏng giao dịch vì giao dịch phải được ký.
Ví dụ, nếu muốn chuẩn bị một giao dịch có phiên bản:
Tối ưu hóa mức sử dụng đơn vị tính toán (CU) của giao dịch
Để tối ưu hóa mức sử dụng đơn vị tính toán (CU) của giao dịch, chúng ta có thể sử dụng phương thức RPCsimulateTransaction để mô phỏng giao dịch.
Việc mô phỏng giao dịch sẽ trả về số CU đã sử dụng, vì vậy chúng ta có thể dùng giá trị này để đặt giới hạn tính toán tương ứng.
Trước tiên, bạn nên sử dụng một giao dịch thử nghiệm có các chỉ thị mong muốn, cộng thêm một chỉ thị đặt giới hạn tính toán thành 1.4 triệu CU.
Việc này nhằm đảm bảo quá trình mô phỏng giao dịch thành công.
Ví dụ:
Tuần tự hóa và mã hóa giao dịch
Quá trình này tương đối đơn giản. Trước tiên, để tuần tự hóa giao dịch, cả kiểu Transaction và VersionedTransaction đều có phương thức.serialize(). Sau đó, sử dụng gói bs58 để mã hóa giao dịch.
Mã của bạn sẽ có dạng tương tự bs58.encode(txt.serialize());
Đặt mức phí ưu tiên phù hợp
Trước tiên, hãy sử dụng Priority Fee API để nhận giá trị ước tính của phí ưu tiên. Chúng ta cần truyền giao dịch vào và lấy mức phí do Helius khuyến nghị thông qua tham số recommended:Tạo và gửi giao dịch đã tối ưu hóa
Bước này gần như lặp lại bước đầu tiên. Tuy nhiên, mảng chỉ thị ban đầu đã được sửa đổi để thêm hai chỉ thị nhằm đặt giới hạn và giá đơn vị tính toán ở mức tối ưu. Bây giờ, hãy gửi giao dịch. Việc gửi có hoặc không có bước kiểm tra trước khi thực thi hay thay đổi bất kỳ tùy chọn gửi nào khác đều không ảnh hưởng — giao dịch sẽ được định tuyến qua kết nối có stake của chúng tôi đối với tất cả các gói trả phí.Thăm dò trạng thái giao dịch và phát lại
Phương thức RPCsendTransaction có tham số maxRetries có thể được đặt để ghi đè logic thử lại mặc định của RPC, giúp nhà phát triển kiểm soát quy trình thử lại tốt hơn.
Một mô hình phổ biến là truy xuất blockhash hiện tại qua getLatestBlockhash, lưu lastValidBlockHeight và thử lại giao dịch cho đến khi blockhash hết hạn.
Điều quan trọng là chỉ ký lại giao dịch khi blockhash không còn hợp lệ; nếu không, cả hai giao dịch đều có thể được mạng chấp nhận.
Sau khi gửi giao dịch, cần thăm dò trạng thái xác nhận để xem mạng đã xử lý và xác nhận giao dịch hay chưa trước khi thử lại. Sử dụng phương thức RPC getSignatureStatuses để kiểm tra trạng thái xác nhận của danh sách giao dịch.
SDK @solana/web3.js cũng có phương thức getSignatureStatuses trong lớp Connection để truy xuất trạng thái hiện tại của nhiều chữ ký.
Cách sendSmartTransaction xử lý việc thăm dò và phát lại
Phương thứcsendSmartTransaction có thời gian chờ là 60 giây. Vì một blockhash hợp lệ trong 150 slot và giả định mỗi slot có thời gian chính xác là 400 mili giây, chúng ta có thể suy luận hợp lý rằng blockhash của giao dịch sẽ không còn hợp lệ sau một phút.
Phương thức này gửi giao dịch và thăm dò chữ ký của giao dịch trong khoảng thời gian chờ này:
txtSig được đặt thành chữ ký của giao dịch vừa được gửi.
Sau đó, phương thức sử dụng phương thức pollTransactionConfirmation() để thăm dò trạng thái xác nhận của giao dịch. Phương thức này kiểm tra trạng thái của giao dịch mỗi năm giây, tối đa ba lần.
Nếu giao dịch không được xác nhận trong khoảng thời gian này, một lỗi sẽ được trả về: