Cách đưa giao dịch lên Solana

Giao dịch

Quá trình thực thi chương trình bắt đầu bằng một giao dịch được gửi đến cụm. Một giao dịch bao gồm:

• Một mảng chứa tất cả account mà giao dịch dự định đọc hoặc ghi
• Một hoặc nhiều instruction (tức đơn vị thực thi nhỏ nhất)
• Một blockhash gần đây
• Một hoặc nhiều chữ ký

Runtime sẽ xử lý lần lượt và theo cơ chế nguyên tử từng instruction trong giao dịch. Nếu bất kỳ phần nào của một instruction thất bại, toàn bộ giao dịch sẽ thất bại.

Blockhash là gì?

"Blockhash" là hash Proof of History (PoH) mới nhất của một slot. Vì Solana dựa vào PoH như một đồng hồ đáng tin cậy, blockhash gần đây của giao dịch có thể được xem là dấu thời gian. Blockhash ngăn trùng lặp và xác định thời hạn tồn tại của giao dịch. Nếu blockhash của giao dịch quá cũ, giao dịch sẽ bị từ chối. Tuổi tối đa của blockhash là 150 block, tương đương khoảng ~1 phút 19 giây.

Giao dịch được gửi như thế nào?

Solana được duy trì bởi một nhóm validator, những bên xác thực các giao dịch được thêm vào sổ cái. Một validator leader được chọn từ nhóm này để thêm các entry vào sổ cái. Một entry trên sổ cái có thể là một tick hoặc entry của giao dịch. Sổ cái lưu danh sách các entry chứa giao dịch do client ký. Về mặt khái niệm, block khởi nguyên truy ngược về đầu sổ cái. Tuy nhiên, sổ cái thực tế của validator có thể chỉ lưu các block mới hơn để giảm dung lượng lưu trữ, vì theo thiết kế, các block cũ không cần thiết để xác thực block trong tương lai.

Validator leader chỉ có thể tạo một block trên mỗi slot, còn blockhash là mã định danh duy nhất dùng để nhận diện từng block. Đây là hash của tất cả entry trong một block, bao gồm cả hash của block trước đó. Lịch leader được xác định trước mỗi epoch, thường là khoảng hai ngày trước đó, để quyết định validator nào sẽ đóng vai trò leader tại từng thời điểm. Khi một giao dịch được khởi tạo, giao dịch đó được chuyển tiếp đến validator leader hiện tại và tiếp theo.

Giao dịch có thể được gửi đến leader qua: 

1. Máy chủ RPC: Nhà cung cấp RPC có thể gửi giao dịch qua phương thức JSON-RPC sendTransaction. Node RPC tiếp nhận sẽ cố gắng gửi giao dịch dưới dạng gói UDP đến leader hiện tại và leader tiếp theo mỗi hai giây, cho đến khi giao dịch được hoàn tất hoặc blockhash của giao dịch hết hạn (sau 150 block hoặc khoảng ~1 phút 19 giây). Trước thời điểm đó, không có bản ghi giao dịch nào ngoài thông tin mà client và các node RPC chuyển tiếp biết. 
2. TPU Client: TPU Client chỉ đơn giản gửi giao dịch. Phần mềm client cần tự xử lý việc phát lại và chuyển tiếp đến leader.

Để sử dụng phương thức sendTransaction, bạn cần truyền đối tượng giao dịch được mã hóa dưới dạng chuỗi. Các tham số tùy chọn khác bao gồm:

1. encoding: Kiểu mã hóa dùng cho dữ liệu giao dịch là base58 hoặc base64. 
2. skipPreflight: Các bước kiểm tra preflight bao gồm xác minh chữ ký giao dịch và mô phỏng giao dịch dựa trên bank slot do preflight commitment chỉ định. Nếu kiểm tra preflight thất bại, hệ thống sẽ trả về lỗi. Cài đặt mặc định của tính năng này là false, nghĩa là không bỏ qua kiểm tra preflight.
3. preflightCommitment: Tham số này chỉ định mức commitment được dùng khi thực hiện kiểm tra preflight. Mức commitment mặc định là finalized, nhưng có thể thay đổi bằng cách chỉ định một chuỗi. Nên chỉ định cùng một mức commitment và preflight commitment để tránh hành vi khó hiểu.
4. maxRetries: Tham số maxRetries xác định số lần tối đa node RPC cần thử gửi lại giao dịch đến leader. Nếu không cung cấp tham số này, node RPC sẽ thử lại cho đến khi giao dịch được hoàn tất hoặc blockhash hết hạn. 
5. minContextSlot: Tham số minContextSlot chỉ định slot tối thiểu để thực hiện kiểm tra preflight cho giao dịch.

Giao dịch được xử lý như thế nào?

Transaction Processing Unit (TPU) của validator tiếp nhận giao dịch, xác minh chữ ký, thực thi giao dịch và chia sẻ giao dịch đó với các validator khác trong mạng.

TPU xử lý giao dịch qua năm giai đoạn riêng biệt:

Giai đoạn Fetch

Giai đoạn Fetch chịu trách nhiệm tiếp nhận giao dịch. Giai đoạn này phân loại giao dịch đến theo ba cổng:

• tpu: xử lý các giao dịch thông thường như chuyển token, mint NFT và instruction của chương trình
• tpu_vote: chỉ tập trung vào giao dịch bỏ phiếu
• tpu_forwards: nếu leader hiện tại không thể xử lý tất cả giao dịch, cổng này sẽ chuyển tiếp các gói chưa được xử lý đến leader tiếp theo

Các gói được gom thành nhóm 128 gói và chuyển tiếp đến Giai đoạn SigVerify.

Giai đoạn SigVerify

Giai đoạn SigVerify xác minh chữ ký trên các gói và loại bỏ chúng nếu xác minh thất bại. Các gói bỏ phiếu và gói thông thường chạy trong hai pipeline riêng biệt. Từ góc nhìn của phần mềm, các gói nhận được chứa một số metadata, nhưng vẫn chưa thể xác định rõ liệu các gói này có phải là giao dịch hay không.

Nếu có GPU, hệ thống sẽ sử dụng GPU để xác minh chữ ký. Ngoài ra, còn có logic xử lý số lượng gói quá lớn khi lưu lượng tăng cao, sử dụng địa chỉ IP để loại bỏ gói.

Giai đoạn Banking

Giai đoạn này chịu trách nhiệm lọc và xử lý giao dịch. Hiện tại, giai đoạn này gồm 6 worker thread độc lập, trong đó 2 thread xử lý bỏ phiếu và 4 thread xử lý giao dịch không bỏ phiếu. Các giao dịch thông thường được thêm vào những thread không bỏ phiếu. Mỗi thread có một buffer cục bộ, có thể chứa tối đa 64 giao dịch không xung đột trong một hàng đợi ưu tiên. Sau đó, các giao dịch này được xử lý song song nhờ Sealevel. Bạn có thể xem video này để tìm hiểu thêm về giai đoạn Banking.

Dịch vụ Proof of History

Mô-đun PoH Service ghi lại tiến trình của các tick. Mỗi tick đại diện cho một đơn vị thời gian và mỗi slot có 64 tick. Hash được tạo liên tục cho đến khi nhận được một bản ghi từ Giai đoạn Banking:

next_hash = hash(prev_hash, hash(transaction_ids))

Sau đó, các bản ghi này được chuyển thành entry và phát đến mạng qua Giai đoạn Broadcast.

Giai đoạn Broadcast

Các entry từ dịch vụ PoH được chuyển thành shred, đơn vị nhỏ nhất của một block, rồi được gửi đến phần còn lại của mạng bằng kỹ thuật truyền block có tên Turbine. Ở cấp độ tổng quan, Turbine chia một block thành các phần nhỏ hơn và phân phối chúng qua cấu trúc node phân cấp. Các node không cần kết nối với mọi node khác. Chúng chỉ cần giao tiếp với một số node được chọn. Bạn có thể tham khảo bài viết này để tìm hiểu thêm về Turbine và cách hoạt động của nó. 

Tại sao giao dịch thất bại?

Không tính các lỗi do instruction không chính xác hoặc lỗi chương trình tùy chỉnh, những nguyên nhân có thể khiến giao dịch thất bại gồm:

Mất gói trên mạng

Lớp mạng có thể loại bỏ một giao dịch trước cả khi leader xử lý giao dịch đó. Mất gói UDP là nguyên nhân đơn giản nhất có thể dẫn đến tình trạng này. Một nguyên nhân khác liên quan đến fetch stage của TPU. Khi mạng chịu tải cao, validator có thể bị quá tải bởi số lượng giao dịch cần xử lý. Validator có thể chuyển tiếp các giao dịch dư thừa đến cổng tpu_forward của validator tiếp theo. Tuy nhiên, lượng dữ liệu có thể chuyển tiếp bị giới hạn và mỗi lần chuyển tiếp chỉ được đi qua một chặng giữa các validator. Điều này có nghĩa là giao dịch nhận tại cổng tpu_forwards sẽ không được chuyển tiếp đến validator khác. Nếu kích thước hàng đợi phát lại đang chờ vượt quá 10.000 giao dịch, các giao dịch mới gửi sẽ bị loại bỏ.

Blockhash cũ/không chính xác 

Mỗi giao dịch có một "blockhash gần đây", đóng vai trò là dấu thời gian cho đồng hồ Proof of History (PoH). Blockhash này giúp validator tránh xử lý cùng một giao dịch hai lần, đồng thời theo dõi thời điểm và thứ tự xử lý giao dịch. Validator sẽ từ chối giao dịch trong quá trình xử lý nếu blockhash không hợp lệ.

Blockhash hết hạn

Blockhash của giao dịch sẽ hết hạn khi không còn được xem là đủ "gần đây". Để xử lý một giao dịch, validator Solana tìm số slot của blockhash tương ứng trong một block. Nếu validator không tìm thấy số slot cho blockhash hoặc nếu số slot tra được thấp hơn số slot của block đang xử lý quá 151 slot, giao dịch sẽ bị từ chối. Theo mặc định, giao dịch Solana hết hạn nếu không được commit vào một block trong một khoảng thời gian nhất định (~1 phút 19 giây).

Node RPC bị chậm

Khi gửi giao dịch qua RPC, RPC Pool có thể đi trước phần còn lại của mạng. Điều này có thể gây ra vấn đề khi các node trong pool cần phối hợp với nhau. Ví dụ, nếu recentBlockhash của giao dịch được truy vấn từ phần đi trước của pool rồi gửi đến phần bị chậm, các node sẽ không nhận ra blockhash đi trước và từ chối giao dịch. Bạn có thể phát hiện điều này khi gửi giao dịch bằng cách bật kiểm tra preflight trên sendTransaction.

Fork mạng tạm thời

Fork mạng tạm thời cũng có thể khiến giao dịch bị loại bỏ. Nếu một validator phát lại các block trong Giai đoạn Banking quá chậm, validator đó có thể tạo ra một fork thiểu số. Khi client tạo giao dịch, giao dịch có thể tham chiếu đến một recentBlockhash chỉ tồn tại trên fork thiểu số. Sau khi giao dịch được gửi, cụm có thể chuyển khỏi fork thiểu số trước khi giao dịch được xử lý. Trong trường hợp này, giao dịch bị loại bỏ vì không tìm thấy blockhash.

Làm cách nào để đưa giao dịch lên chuỗi?

Để chẩn đoán các vấn đề xác nhận, điều quan trọng là phải hiểu cơ chế hết hạn của giao dịch. Hãy làm theo các bước sau để tăng khả năng giao dịch thành công:

Tóm tắt

• Lấy blockhash mới nhất với commitment “confirmed” hoặc “finalized”
• Đặt skipPreflight thành true
• Tối ưu số Compute Unit được yêu cầu
• Thêm và tính phí ưu tiên một cách linh hoạt
• Đặt maxRetries thành 0 và thêm logic thử lại tùy chỉnh để gửi giao dịch.
• Khám phá kết nối có stake
• Nếu giao dịch không nhạy cảm về thời gian, hãy dùng durable nonce

Blockhash

Giao dịch chỉ có một khoảng thời gian giới hạn để validator xử lý. Nếu blockhash liên kết với giao dịch hết hạn trước khi validator xử lý, giao dịch sẽ bị hủy. Để bảo đảm giao dịch được thực hiện, bạn cần gửi giao dịch với một blockhash gần đây. Nếu blockhash hết hạn trước khi validator xử lý giao dịch, bạn có thể thử lại với blockhash mới để bảo đảm giao dịch được xử lý thành công. Có hai cách để thực hiện: 

1. Đặt mức commitment mới:

Phương thức RPC API được khuyến nghị để lấy blockhash mới nhất là getLatestBlockhash. Theo mặc định, phương thức này dùng mức commitment finalized để trả về blockhash của block mới nhất đã được hoàn tất. Mức commitment này cho biết có ít nhất 31 block đã được xác nhận thêm phía trên block đó. Điều này loại bỏ rủi ro dùng blockhash thuộc một fork đã bị loại bỏ. Tuy nhiên, thường có chênh lệch ít nhất 32 slot giữa block được xác nhận gần nhất và block được hoàn tất gần nhất. Sự đánh đổi này rút ngắn khoảng thời gian trước khi giao dịch hết hạn khoảng 13 giây, và có thể còn nhiều hơn khi cụm không ổn định. 

Bạn có thể ghi đè commitment của blockhash bằng cách đặt tham số commitment thành một mức khác. Mức commitment confirmed được khuyến nghị cho các yêu cầu RPC vì thường chỉ chậm hơn mức commitment processed vài slot và có xác suất thấp thuộc về một fork bị loại bỏ. Dù mức commitment processed lấy được blockhash mới nhất so với các mức commitment khác, mức này không được khuyến nghị vì khoảng 5% số block không được cụm hoàn tất do cơ chế fork trong giao thức Solana. Nếu giao dịch dùng blockhash thuộc một fork bị loại bỏ, blockhash đó sẽ không được bất kỳ block nào trong blockchain đã hoàn tất xem là gần đây.

2. Thường xuyên thăm dò blockhash mới:

Thêm một script để thường xuyên lấy và lưu blockhash mới nhất bằng phương thức getLatestBlockhash (mỗi 60 giây). Nhờ đó, mỗi khi người dùng kích hoạt giao dịch, ứng dụng đã có sẵn một blockhash mới. Ví cũng nên thường xuyên thăm dò blockhash mới và thay thế blockhash gần đây của giao dịch ngay trước khi ký để bảo đảm blockhash mới nhất có thể.

Bỏ qua Preflight

Trước khi gửi giao dịch, hệ thống thực hiện các bước kiểm tra preflight sau:

• Xác minh chữ ký của giao dịch.
• Mô phỏng giao dịch dựa trên bank slot do preflight commitment chỉ định. Nếu thất bại, hệ thống sẽ trả về lỗi. 

Nếu block được chọn để mô phỏng cũ hơn block dùng cho blockhash của giao dịch, quá trình mô phỏng sẽ thất bại với lỗi “không tìm thấy blockhash” đáng ngại. 

Nếu chắc chắn chữ ký giao dịch đã được xác minh và không có lỗi nào khác, bạn có thể bỏ qua kiểm tra preflight. Ngay cả khi dùng tham số skipPreflight, hãy luôn đặt tham số preflightCommitment thành cùng mức commitment được dùng để lấy blockhash của giao dịch cho cả yêu cầu sendTransaction và simulateTransaction.

Compute Unit

Khi một giao dịch được xác nhận trên mạng, giao dịch đó sử dụng một phần tổng số compute unit (CU) có trong block. Hiện tại, tổng giới hạn compute của một block là 48 triệu CU. Nhà phát triển có thể chỉ định ngân sách compute unit cho giao dịch. Nếu không đặt ngân sách, giá trị mặc định 200.000 sẽ được dùng. Nhiều giao dịch không sử dụng toàn bộ ngân sách CU vì không có hình phạt khi yêu cầu ngân sách cao hơn mức cần thiết. Tuy nhiên, yêu cầu trước quá nhiều compute unit có thể khiến việc lập lịch giao dịch hiệu quả trở nên khó khăn hơn, vì bộ lập lịch không biết block còn bao nhiêu compute cho đến khi giao dịch được thực thi. Để tránh điều này, nhà phát triển nên đặt yêu cầu CU có phạm vi phù hợp hơn với nhu cầu của giao dịch. Bạn có thể tham khảo hướng dẫn này để tối ưu ngân sách compute unit. Trong bản cập nhật Solana client v1.18 sắp tới, các giao dịch cần ít Compute Unit hơn sẽ được ưu tiên cao hơn.

Tối ưu mức sử dụng Compute Unit (CU) mang lại các lợi ích sau:

• Giao dịch nhỏ hơn có nhiều khả năng được đưa vào block hơn.
• Instruction ít tốn kém hơn giúp chương trình có khả năng kết hợp tốt hơn.
• Giảm tổng mức sử dụng block, cho phép đưa nhiều giao dịch hơn vào một block.

Triển khai phí ưu tiên

Có thể cộng phí ưu tiên vào phí giao dịch cơ bản để validator ưu tiên giao dịch. Mức phí này được tính bằng micro-lamport trên mỗi Compute Unit (tức một lượng nhỏ SOL). Phí được thêm vào giao dịch để tạo động lực kinh tế cho các node validator đưa giao dịch vào block trên mạng.

Tuy nhiên, cần lưu ý rằng phí ưu tiên nên có giới hạn. Trả cao hơn mức phí thông thường sẽ không làm tăng xác suất thành công của giao dịch. Vì vậy, nên tính phí ưu tiên một cách linh hoạt để trả mức phù hợp, duy trì khả năng cạnh tranh mà không trả quá nhiều. Việc tích hợp rất đơn giản. Bạn có thể tham khảo tài liệu chính thức về phí ưu tiên hoặc dùng Helius API có sẵn.

Triển khai logic thử lại vững chắc

Khi mạng tắc nghẽn, hãy triển khai logic tùy chỉnh trong mã để xử lý giao dịch thất bại và thử lại theo cách thủ công. Để thực hiện, hãy đặt tham số maxRetries thành 0 khi dùng sendTransaction để gửi giao dịch. Bạn có thể thử lại giao dịch bằng nhiều phương pháp:

• Thăm dò transaction status với các mức commitment khác nhau và liên tục dùng cùng một giao dịch đã ký cho đến khi giao dịch được xác nhận, áp dụng cơ chế exponential backoff để tránh tạo lưu lượng rác. Hoặc bạn có thể gửi giao dịch theo khoảng thời gian cố định cho đến khi hết thời gian chờ.
• Lưu lastValidBlockHeight từ getLatestBlockhash method. Sau đó, thăm dò block height của cụm và thử lại giao dịch theo cách thủ công khi block height hiện tại vượt quá lastValidBlockHeight. Khi thăm dò qua getLatestBlockhash, bạn nên chỉ định mức commitment mong muốn. Bằng cách đặt commitment thành confirmed (đã được bỏ phiếu) hoặc finalized (~30 block sau confirmed), bạn có thể tránh thăm dò blockhash từ một fork thiểu số.

Kết nối có stake

Dung lượng băng thông mạng của leader có giới hạn. Để sử dụng hiệu quả, cần áp dụng trọng số stake nhằm tránh chấp nhận giao dịch một cách mù quáng theo nguyên tắc đến trước phục vụ trước mà không xét đến nguồn. Solana hoạt động như một mạng proof-of-stake, vì vậy việc mở rộng sử dụng trọng số stake để cải thiện chất lượng dịch vụ giao dịch là điều tự nhiên. Điều này có nghĩa là một node có 0,5% stake có thể gửi ít nhất 0,5% số gói đến leader. Phần còn lại của mạng — cũng như bất kỳ tổ hợp nào của lượng stake còn lại — sẽ không thể loại bỏ hoàn toàn các gói đó. Cơ chế này được gọi là Chất lượng dịch vụ có trọng số stake (SWQoS).

Helius cung cấp kết nối có stake cho các gói trả phí. Để tìm hiểu thêm, vui lòng xem tài liệu của chúng tôi: Gửi giao dịch trên Solana.

Durable Nonce

Durable nonce cho phép tạo và ký một giao dịch có thể được gửi vào bất kỳ thời điểm nào trong tương lai. Chúng được dùng trong các trường hợp như dịch vụ lưu ký, vốn cần nhiều thời gian hơn để tạo chữ ký giao dịch. Nếu giao dịch không nhạy cảm về thời gian, bạn có thể dùng phương thức này để tránh thời hạn tồn tại ngắn của recentBlockhash trong giao dịch.

Để bắt đầu dùng giao dịch bền vững, bạn cần gửi một giao dịch gọi các instruction để tạo một account "nonce" đặc biệt on-chain và lưu một "durable blockhash" trong đó. Account Nonce lưu giá trị của nonce. Miễn là account nonce chưa được dùng, bạn có thể tạo giao dịch bền vững bằng cách tuân theo hai quy tắc sau:

• Danh sách instruction phải bắt đầu bằng một instruction hệ thống "advance nonce", dùng để tải account nonce on-chain của bạn.
• Blockhash của giao dịch phải bằng durable blockhash được lưu trong account nonce on-chain.

Tìm hiểu cách triển khai durable nonce qua CLI và Web3.js bằng cách tham khảo bài viết này.

Cách Helius gửi giao dịch

Yêu cầu sendTransaction được tự động định tuyến đến node RPC gần nhất của chúng tôi. Nếu không chỉ định maxRetries, hệ thống sẽ thử lại giao dịch mỗi 2 giây cho đến khi blockhash hết hạn. Chúng tôi khuyên bạn đặt maxRetries thành 0 và tự phát lại giao dịch mỗi 2 giây cho đến khi được xác nhận. 

Để giải quyết tình trạng tắc nghẽn mạng hiện tại, chúng tôi đang làm việc liên tục để cải thiện tỷ lệ giao dịch được ghi nhận cho người dùng. Chúng tôi đã giảm giới hạn tốc độ cho yêu cầu sendTransaction. Biện pháp này giúp kiểm soát tắc nghẽn và ngăn gửi lưu lượng rác đến validator. Bạn có thể xem các giới hạn tại đây.

Tiếp theo, chúng tôi định tuyến lưu lượng chất lượng cao của các gói trả phí qua kết nối có stake. Chúng tôi tận dụng validator của mình cho các kết nối có stake này. Lưu lượng được xem là chất lượng cao nếu tổng phí ưu tiên ít nhất là 10.000 Lamport (trung vị của cụm).

Chúng tôi yêu cầu tổng phí trên 10.000 Lamport để bảo đảm cung cấp lưu lượng chất lượng cao cho validator. Các validator đã bắt đầu giới hạn tốc độ (hoặc thậm chí chặn hoàn toàn) những nguồn lưu lượng gửi giao dịch có phí thấp.

Dùng kết nối có stake có thể cải thiện đáng kể tỷ lệ giao dịch được ghi nhận. Vui lòng tham khảo bài viết này để tìm hiểu thêm về cách đặt phí ưu tiên khi tạo giao dịch.

Khuyến nghị của chúng tôi

Người dùng mới bắt đầu/trung cấp

Chúng tôi khuyên bạn đặt skipPreflight thành false. Các bước kiểm tra preflight bao gồm xác minh chữ ký giao dịch và mô phỏng giao dịch dựa trên bank slot do preflight commitment chỉ định. Nếu kiểm tra preflight thất bại, hệ thống sẽ trả về lỗi. Nếu không kiểm tra preflight, giao dịch có thể bị loại bỏ do cấu hình sai.

Người dùng nâng cao

Với người dùng nâng cao cần độ trễ thấp nhất có thể, bạn nên đặt skipPreflight thành true. Tuy nhiên, bạn có trách nhiệm bảo đảm giao dịch được cấu hình chính xác. 

Kết luận

Để đưa giao dịch lên mạng Solana thành công trong thời gian tắc nghẽn, bạn cần hiểu rõ kiến trúc mạng và cơ chế xử lý giao dịch. Bằng cách nắm vững các khái niệm cốt lõi như vai trò của blockhash trong việc bảo đảm tính duy nhất và kịp thời của giao dịch, quy trình gửi giao dịch qua máy chủ RPC hoặc TPU client, cũng như tầm quan trọng của việc đặt đúng tham số (như skipPreflight, preflightCommitment và maxRetries), người dùng có thể cải thiện đáng kể hiệu suất giao dịch. Triển khai cơ chế thử lại tùy chỉnh và tận dụng kết nối có stake có thể giúp tăng tỷ lệ thành công.

Ngoài ra, điều quan trọng là phải nhận thức rõ các giới hạn hiện tại của mạng và nỗ lực liên tục của Anza nhằm khắc phục chúng, như có thể thấy trong bản phát hành client v1.18 sắp tới. Khi mạng phát triển và mở rộng quy mô, việc luôn cập nhật thông tin và linh hoạt thích ứng sẽ là chìa khóa để tương tác hiệu quả với mạng. 

Nếu cần trợ giúp hoặc hỗ trợ, đừng ngần ngại liên hệ với chúng tôi trên Discord. Hãy nhập địa chỉ email bên dưới để không bao giờ bỏ lỡ thông tin mới nhất về Solana. Sẵn sàng tìm hiểu sâu hơn? Khám phá các bài viết mới nhất trên blog Helius và tiếp tục hành trình Solana ngay hôm nay.

Tài nguyên

• Giao dịch – Solana Cookbook
• Tối ưu block trên Solana
• Solana Validator 101: Xử lý giao dịch của Jito Labs
• Transaction Processing Unit trong một Solana Validator
• Bộ lập lịch của Solana
• Xác nhận giao dịch của Solana
• Thử lại giao dịch của Solana
• Cách sử dụng phí ưu tiên
• Cách tối ưu compute
• Phí ưu tiên và Compute Unit
• Durable Nonce cho giao dịch
• Ký giao dịch bền vững và ngoại tuyến bằng Nonce
• Giao dịch Solana: Durable Nonce của Helius