Skip to main content
Có hai phương thức chính để gửi giao dịch trên Solana:
  1. Sử dụng kết nối có stake (mặc định)
  2. 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ị)
Bài viết này trình bày các phương pháp hay nhất để tối ưu hóa giao dịch khi sử dụng kết nối có stake, đây là phương thức mặc định cho tất cả các gói trả phí của Helius. Kết nối có stake phù hợp nhất với các trường hợp sử dụng mà độ trễ không mang tính quyết định đối với hoạt động kinh doanh của bạn (ví dụ: thanh toán, ví, ứng dụng mạng xã hội, v.v.) Nếu bạn là nhà giao dịch chuyên nghiệp (ví dụ: propAMM, sniper, copy trader, bot thanh lý, kinh doanh chênh lệch giá) đang tìm kiếm một dịch vụ chuyên biệt để đưa giao dịch vào chuỗi với độ trễ cực thấp, hãy đọc hướng dẫn về Sender.

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 maxRetries thành 0 và triển khai logic thử lại mạnh mẽ
  • Gửi với skipPreflight được đặt thành true (tùy chọn)
Bạn muốn tìm hiểu sâu hơn? Chúng tôi trình bày tất cả kiến thức nền tảng trong bài đăng blog này.

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 getHealth mỗ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.
Chỉ những nhà giao dịch giàu kinh nghiệm mới nhận thấy những lợi ích này. Đối với các nhà phát triển ứng dụng nói chung, chúng tôi khuyến nghị làm theo hướng dẫn trong phần Gửi giao dịch thông minh bên dưới.
Nhận dữ liệu giao dịch onchain nhanh nhất có thể bằng Raw Shreds (UDP). Đăng ký trong Bảng điều khiển Helius.

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 độ.
Phương thức này là cách dễ nhất để tạo, gửi và đưa một giao dịch vào chuỗi trên Solana. Khi sử dụng mức phí do Helius khuyến nghị, các giao dịch do người dùng Helius gửi bằng một trong các gói trả phí tiêu chuẩn của chúng tôi sẽ được định tuyến qua kết nối có stake, đảm bảo tỷ lệ chuyển giao giao dịch gần 100% và độ trễ tối thiểu.

SDK TypeScript

Phương thức sendSmartTransaction 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ức send_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ột TransactionMessage 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 RPC simulateTransaction để 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ụ:
Bạn cũng nên thêm một khoảng dự phòng nhỏ để đảm bảo giao dịch được thực thi mà không gặp vấn đề. Có thể thực hiện bằng cách đặt như sau:
Sau đó, tạo một chỉ thị đặt giới hạn đơn vị tính toán thành giá trị này và thêm chỉ thị đó vào mảng chỉ thị của bạn:

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:
Sau đó, tạo một chỉ thị đặt giá đơn vị tính toán thành giá trị này và thêm chỉ thị đó vào các chỉ thị trước đó:

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

Mặc dù kết nối có stake sẽ chuyển tiếp giao dịch trực tiếp đến leader, giao dịch vẫn có thể bị loại bỏ trong Giai đoạn Banking. Người dùng nên triển khai logic phát lại riêng thay vì phụ thuộc vào RPC để thử lại giao dịch.
Phương thức RPC sendTransaction 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ức sendSmartTransaction 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ề: