- Sản phẩm và nền tảng Helius
- Kiến thức cơ bản về Solana
- Cơ chế giao dịch
- Token và tài sản
- Kết nối và truyền phát
- Hệ sinh thái
Sản phẩm và nền tảng Helius
Tự động mở rộng
Cơ chế tự động nạp tín dụng của Helius dành cho các gói tiền pháp định. Khi hạn mức tín dụng hằng tháng cạn kiệt, tính năng tự động mở rộng sẽ mua thêm tín dụng đến mức trần do người dùng đặt, ngăn lỗi429 làm gián đoạn lưu lượng production. Các gói tiền mã hóa không có tính năng tự động mở rộng. Thay vào đó, chúng sử dụng tín dụng trả trước, được mua thủ công.
Xem Tự động mở rộng.
Tín dụng
Đơn vị Helius dùng để tính phí sử dụng API và dịch vụ truyền phát. Các phương thức RPC, lệnh gọi DAS và thông lượng truyền phát đều có mức chi phí tín dụng cụ thể. Mỗi gói bao gồm một hạn mức tín dụng hằng tháng được đặt lại sau mỗi chu kỳ thanh toán (tín dụng chưa sử dụng không được chuyển sang kỳ sau). Xem Tín dụng để biết bảng chi phí đầy đủ.DAS API
Digital Asset Standard — một đặc tả mở cung cấp giao diện thống nhất cho tài sản số trên Solana (NFT, NFT nén, token có thể thay thế). Phần triển khai DAS API của Helius trả về siêu dữ liệu mở rộng, quyền sở hữu và giá trong một phản hồi có cấu trúc duy nhất, loại bỏ nhu cầu sử dụng trình phân tích cú pháp tùy chỉnh cho dữ liệu tài sản onchain. Xem DAS API.Nút chuyên dụng
Các nút RPC Helius riêng tư không có giới hạn tốc độ hoặc đo lường tín dụng, được tính phí cố định hằng tháng. Chúng phù hợp với các trường hợp sử dụng chuyên biệt cần thông lượng không giới hạn; hầu hết ứng dụng phù hợp hơn với RPC Helius thông thường nhờ hiệu suất, khả năng chuyển đổi dự phòng và phạm vi tính năng vượt trội. Xem Nút chuyên dụng.Giao dịch nâng cao
API giao dịch đã phân tích cú pháp của Helius, giải mã các giao dịch Solana thô thành sự kiện mà con người có thể đọc được — chuyển token, bán NFT, hoán đổi, thao tác staking và nhiều nội dung khác — mà không cần trình phân tích cú pháp lệnh riêng cho từng chương trình. Xem Giao dịch nâng cao.Mã lỗi
Các mã trạng thái HTTP tiêu chuẩn do API của Helius trả về, kèm theo ngữ cảnh riêng của Helius:400 Bad Request— tham số không hợp lệ hoặc yêu cầu sai định dạng (ví dụ: định dạng địa chỉ không hợp lệ, thiếu trường bắt buộc, JSON sai định dạng)401 Unauthorized— thiếu hoặc khóa API không hợp lệ403 Forbidden— quyền truy cập bị từ chối, thường do hạn chế IP, gói đăng ký không bao gồm điểm cuối hoặc khóa API không có đủ quyền404 Not Found— không có dữ liệu cho tài nguyên được yêu cầu (đây là điều bình thường khi tra cứu danh tính của ví không xác định)429 Too Many Requests— hạn mức tín dụng đã cạn, vượt quá giới hạn tốc độ hoặc đạt giới hạn yêu cầu đồng thời5xx— sự cố phía Helius; thử lại với cơ chế lùi theo cấp số nhân
Gatekeeper
Cổng biên của Helius mang lại độ trễ thấp hơn đáng kể so với các lệnh gọi RPC tiêu chuẩn bằng cách định tuyến yêu cầu qua một đội proxy phân tán toàn cầu. Truy cập bằng cách thaymainnet.helius-rpc.com bằng beta.helius-rpc.com trong URL RPC.
Xem Gatekeeper và bài viết giới thiệu Gatekeeper để tìm hiểu nền tảng kiến trúc.
LaserStream
Dịch vụ truyền phát gRPC hiệu suất cao của Helius dành cho dữ liệu onchain Solana, có khả năng phát lại lịch sử, chuyển đổi dự phòng đa khu vực và bộ tính năng phong phú nhất trong các sản phẩm truyền phát của Helius. SDK chính thức có sẵn cho JavaScript/TypeScript, Rust và Go. LaserStream WebSocket chạy trên cùng cơ sở hạ tầng. Xem LaserStream và bài viết về hiệu suất SDK LaserStream để tìm hiểu chuyên sâu về các chỉ số chuẩn của SDK.LaserStream WebSocket
Dịch vụ truyền phát WebSocket liên tục của Helius. Dịch vụ này cung cấp cả các phương thức WebSocket Solana tiêu chuẩn và phần mở rộng riêng của Helius (transactionSubscribe và phiên bản accountSubscribe nâng cao với khả năng lọc phong phú hơn) trên một điểm cuối hợp nhất duy nhất. LaserStream WebSocket dùng chung backend với LaserStream gRPC.
Xem LaserStream WebSocket.
Preconfirmations
Tín hiệu giao dịch có độ trễ thấp nhất của Helius. Dịch vụ truyền phát các giao dịch trước khi chúng được thu thập thành mục nhập và chia thành shred: Helius Preconfirmations được phát ngay khi leader thực thi giao dịch, cùng với trạng thái thực thi; BAM Preconfirmations được phát khi trình xác thực cam kết thực thi giao dịch, trước khi giao dịch chạy. Tín hiệu này đến sớm hơn Shred Delivery và các luồng có mức cam kết processed. Được phân phối qua đăng ký WebSocketpreconfSubscribe. Yêu cầu gói Professional trở lên; được tính 10 tín dụng cho mỗi thông báo. Phạm vi bao phủ phụ thuộc vào những trình xác thực chuyển tiếp luồng của họ đến Helius, vì vậy nguồn cấp dữ liệu không liên tục.
Xem Preconfirmations và preconfSubscribe.
API phí ưu tiên
Điểm cuối ước tính phí của Helius trả về các giá trị phí ưu tiên được đề xuất dựa trên thị trường phí onchain theo thời gian thực. Cho phép định giá phí cạnh tranh mà không cần phỏng đoán hoặc trả quá nhiều khi tắc nghẽn. Xem API phí ưu tiên.Giới hạn tốc độ
Số yêu cầu tối đa mỗi giây được phép theo một gói Helius nhất định. Giới hạn tốc độ thay đổi theo cấp gói và nhóm API (RPC tiêu chuẩn, API nâng cao, truyền phát). Vượt quá giới hạn sẽ trả về429 Too Many Requests.
Xem Giới hạn tốc độ.
Sender
Dịch vụ đưa giao dịch vào chuỗi chuyên biệt của Helius được xây dựng cho các nhà giao dịch cần độ trễ thấp, kết hợp phí ưu tiên, tiền boa Jito và định tuyến kết nối có stake để tối đa hóa tỷ lệ giao dịch được đưa vào chuỗi. Có tạihttps://sender.helius-rpc.com/fast.
Xem Sender.
Shred Delivery
Dịch vụ của Helius dùng để truyền phát các shred Solana thô qua UDP, được phân phối trước khi khối hoàn tất quá trình lắp ráp. Helius tổng hợp shred từ một mạng lưới trình xác thực phân tán trên nhiều khu vực để giảm thiểu độ biến thiên về độ trễ địa lý của bất kỳ trình xác thực đơn lẻ nào. Hữu ích cho giao dịch tần suất cao, kinh doanh chênh lệch giá và các ứng dụng có độ trễ thấp khác. Có thể tự đăng ký shred thô từ Helius Dashboard - $1.000/tháng cho mỗi IP ($800/tháng cho mỗi IP với gói Pro). Xem Shred Delivery và bài viết Chiến thắng trong cuộc đua mili giây: Shred, LaserStream và lợi thế của Solana để tìm hiểu chuyên sâu về cách shred hoạt động.Kết nối có stake
Đường gửi giao dịch mặc định cho các gói Helius trả phí. Kết nối có stake định tuyến giao dịch đến các leader khối sắp tới thông qua cơ chế Chất lượng dịch vụ có trọng số theo stake (SWQoS) ở cấp giao thức của Solana. Cơ chế này cấp các vị trí kết nối ưu tiên dựa trên stake của trình xác thực và giảm tình trạng mất gói khi tắc nghẽn. Các gói trả phí của Helius thừa hưởng lợi thế về tỷ lệ đưa giao dịch vào chuỗi này mà bên gọi không cần trực tiếp vận hành một trình xác thực có lượng stake lớn. Xem Tối ưu hóa giao dịch và bài viết Chất lượng dịch vụ có trọng số theo stake: Mọi điều bạn cần biết.Wallet API
REST API của Helius dùng để truy vấn số dư, lịch sử giao dịch, giao dịch chuyển, danh tính và nguồn cấp vốn của ví Solana — cung cấp phản hồi có cấu trúc và định giá bằng USD thay vì đầu ra RPC thô. API chấp nhận.sol SNS và tên miền ANS ngoài địa chỉ.
Xem Wallet API.
Kiến thức cơ bản về Solana
Tài khoản
Một vùng chứa lưu giữ dữ liệu lâu dài trên Solana, được xác định bằng khóa công khai 32 byte. Mọi trạng thái onchain — số dư người dùng, mã chương trình, siêu dữ liệu token — đều nằm trong tài khoản, bao gồm cả chính các chương trình. Mỗi tài khoản có một chủ sở hữu, là chương trình được phép sửa đổi dữ liệu hoặc rút lamport, đồng thời phải duy trì số dư SOL tối thiểu (được miễn tiền thuê) để tiếp tục tồn tại. Xem bài viết Mô hình lập trình Solana: Giới thiệu về phát triển trên Solana để tìm hiểu chuyên sâu hơn.Agave
Ứng dụng trình xác thực Solana chính tắc hiện tại, do Anza duy trì — phiên bản kế nhiệm được đổi thương hiệu từ ứng dụng Solana Labs ban đầu. Các tham chiếu đến bản phát hành Agave cụ thể (ví dụ: ngưỡng stake tối thiểu của SWQoS trong v1.17.31) thường cố định hành vi theo một phiên bản cụ thể của ứng dụng. Jito-Solana là một nhánh của Agave tích hợp công cụ khối của họ; Firedancer là giải pháp độc lập dựa trên C do Jump Crypto phát triển. Xem bài viết Máy ảo Solana để tìm hiểu mô hình SVM mà Agave triển khai.Airdrop
Khoản phân phối SOL hoặc token SPL đến một địa chỉ. Trên Devnet và Testnet, airdrop thường chỉ một lượng nhỏ SOL thử nghiệm từ faucet dùng để cấp vốn cho ví phát triển; trên Mainnet, thuật ngữ này chỉ việc phân phối token hàng loạt cho những người nắm giữ hiện tại. Airdrop trên Devnet có sẵn qua faucet Devnet.Tài khoản token liên kết (ATA)
Một tài khoản token được suy ra theo cách xác định, nắm giữ một token SPL cụ thể cho một địa chỉ ví nhất định. Mỗi ví có tối đa một ATA cho mỗi token mint, khiến ATA trở thành nơi chính tắc để tra cứu số dư token của người dùng. ATA được suy ra bằng cách dùng địa chỉ ví và token mint làm seed.Khối
Một cấu trúc dữ liệu chứa tập hợp giao dịch cùng với siêu dữ liệu thiết yếu — bao gồm hàm băm của khối và hàm băm của khối trước đó, tạo thành một chuỗi bất biến. Các khối được tạo trong slot: leader được chỉ định cho một slot sẽ xác thực giao dịch đến, đóng gói chúng thành một khối và phát khối đó đến mạng qua Turbine. Không phải slot nào cũng tạo ra khối — nếu leader không thể tạo khối kịp thời, slot sẽ bị bỏ qua và mạng tiếp tục hoạt động. Khi một khối nhận được phiếu bầu của đại đa số trình xác thực có trọng số theo stake, khối đó được xem là đã xác nhận (xem Mức cam kết). Xem bài viết Tìm hiểu slot, khối và epoch trên Solana để tìm hiểu chuyên sâu hơn.Mức cam kết
Mức độ tin cậy rằng một giao dịch đã được đưa lên chuỗi:processed— leader hiện tại đã nhìn thấy nhưng chưa được bỏ phiếu; vẫn có thể bị loại nếu khối không đạt đồng thuận (~0,4 giây)confirmed— ≥66% phiếu bầu của trình xác thực có trọng số theo stake dành cho khối; trong lịch sử, chưa có khối đã xác nhận nào bị đảo ngược (~0,6 giây)finalized— khối có ≥66% phiếu bầu cộng với 31 khối tiếp theo được xây dựng trên đó (tức thời gian khóa tối đa của Tower BFT), khiến khối gần như không thể đảo ngược (~13 giây)
confirmed là giá trị mặc định được khuyến nghị. Dùng processed để phản hồi trên giao diện người dùng và finalized cho các thao tác có giá trị cao như nạp tiền vào sàn giao dịch hoặc cầu nối xuyên chuỗi. Blockhash được lấy ở mức finalized hết hạn sớm hơn blockhash ở mức confirmed, làm thu hẹp khoảng thời gian trước khi giao dịch hết hạn.
Xem bài viết Các mức cam kết Solana là gì? để tìm hiểu chuyên sâu hơn.
Đơn vị tính toán (CU)
Đơn vị đo khối lượng công việc tính toán mà một giao dịch thực hiện trên Solana, tương tự gas trên Ethereum. Mỗi giao dịch chỉ định giới hạn đơn vị tính toán và giá đơn vị tính toán (phí ưu tiên tính bằng microlamport trên mỗi CU); tích của hai giá trị xác định tổng chi phí phí ưu tiên. Vượt quá giới hạn sẽ khiến giao dịch thất bại.CPI (Lệnh gọi xuyên chương trình)
Cơ chế Solana cho phép một chương trình onchain gọi một chương trình khác, truyền vào tài khoản và dữ liệu lệnh — thành phần nguyên thủy tạo nên khả năng kết hợp của Solana. CPI được cung cấp qua syscallsol_invoke_signed, giúp xác minh bên gọi có quyền thích hợp đối với các tài khoản được truyền vào; PDA cho phép chương trình ký thay cho các tài khoản mà chúng sở hữu.
Chương trình được gọi hoạt động trong ngân sách tính toán còn lại của chương trình gọi: nếu dùng hết ngân sách hoặc vượt quá giới hạn đã đặt, toàn bộ chuỗi lệnh gọi sẽ thất bại — bao gồm cả giao dịch ban đầu.
Xem bài viết Máy ảo Solana để tìm hiểu chuyên sâu hơn.
Epoch
Một cụm gồm khoảng 432.000 slot Solana — khoảng thời gian tổ chức cấp cao hơn mà tại đó Solana cập nhật tập hợp trình xác thực, lịch leader, các khoản ủy quyền stake và phân phối phần thưởng. Mỗi epoch kéo dài khoảng 2 ngày theo mục tiêu slot hiện tại. Xem bài viết Tìm hiểu slot, khối và epoch trên Solana để tìm hiểu chuyên sâu hơn.Firedancer
Ứng dụng trình xác thực Solana độc lập thứ hai, được Jump Crypto viết lại từ đầu bằng C. Các mục tiêu được công bố của Firedancer là (1) lập tài liệu và chuẩn hóa giao thức Solana thông qua một phần triển khai độc lập, (2) cải thiện tính đa dạng của ứng dụng (không ứng dụng đơn lẻ nào kiểm soát >33% stake) và (3) nâng cao hiệu suất hệ sinh thái. Kiến trúc có tính mô-đun: nhiều tiến trình Linux đơn nhiệm được gọi là “tile” (tile QUIC, tile xác minh, v.v.) giao tiếp qua bộ nhớ dùng chung, trái ngược với thiết kế đơn tiến trình của Agave. Frankendancer là phiên bản trung gian kết hợp của họ — mã mạng C hiệu suất cao của Firedancer kết hợp với mã runtime và đồng thuận Rust của Agave. Xem bài viết Firedancer là gì? để tìm hiểu chuyên sâu hơn.Lệnh
Đơn vị công việc nhỏ nhất bên trong một giao dịch Solana — một lần gọi chương trình duy nhất cùng các tài khoản và dữ liệu liên quan. Một giao dịch gộp một hoặc nhiều lệnh và thực thi theo cách nguyên tử (tất cả cùng thành công hoặc cùng hoàn tác). Xem bài viết Mô hình lập trình Solana: Giới thiệu về phát triển trên Solana để tìm hiểu chuyên sâu hơn.Lamport
Đơn vị nhỏ nhất của SOL: 1 SOL = 1.000.000.000 lamport (10⁻⁹ SOL), được đặt theo tên Leslie Lamport, người đoạt Giải Turing nhờ công trình nền tảng về hệ thống phân tán. Các phương thức RPC Solana thô trả về số dư và phí bằng lamport; Wallet API của Helius tự động xử lý việc chuyển đổi. Phí ưu tiên được tính bằng microlamport — một phần triệu lamport (10⁻¹⁵ SOL).Leader / Lịch leader
Leader là trình xác thực được chỉ định để đề xuất một khối mới trong một slot nhất định. Leader được chọn theo lịch ngẫu nhiên có trọng số theo stake được tính ở đầu mỗi epoch, vì vậy bất kỳ trình xác thực nào cũng có thể tự xác định ai sẽ dẫn dắt từng slot trong khoảng thời gian ~2-3 ngày sắp tới. Mỗi leader được chỉ định bốn slot liên tiếp (~1,6 giây với ~400 ms mỗi slot), cho họ một khoảng thời gian ngắn để liên tục tạo khối. Nếu leader không tạo được khối trong slot của mình, slot sẽ bị bỏ qua — mạng tiếp tục thay vì chờ khối còn thiếu. Các dịch vụ gửi giao dịch như Sender định tuyến giao dịch đã ký đến leader hiện tại và hai leader tiếp theo để tối đa hóa xác suất được đưa vào chuỗi. Xem bài viết Đồng thuận trên Solana: Tower BFT và Proof of History để tìm hiểu chuyên sâu hơn.Cây Merkle
Một cấu trúc cây mật mã trong đó mỗi nút không phải lá là hàm băm của các nút con, do đó một hàm băm gốc duy nhất cam kết cho toàn bộ tập dữ liệu. Việc xác minh một phần dữ liệu thuộc về cây chỉ cần các hàm băm anh em dọc theo đường đi từ lá đến gốc — một bằng chứng Merkle — có lượng dữ liệu O(log n) bất kể kích thước cây. Với cây có độ sâu 26, bằng chứng đó gồm 26 hàm băm anh em (~832 byte), tuy nhỏ nhưng vẫn tính theo từng lá: đây là dạng bằng chứng được NFT nén sử dụng. ZK Compression thay thế nó bằng một Bằng chứng hợp lệ duy nhất có kích thước cố định, không tăng theo tập dữ liệu. Xem bài viết Nhập môn công cụ mật mã: Giải thích hàm băm và cây Merkle.Chương trình
Một tài khoản có thể thực thi chứa bytecode sBPF đã biên dịch (tức hợp đồng thông minh trên Solana). Chương trình không có trạng thái — chúng đọc và ghi các tài khoản dữ liệu do chúng sở hữu và được xác định bằng ID chương trình (địa chỉ 32 byte). Solana đi kèm một tập hợp chương trình gốc (System, Stake, Vote, v.v.) được tích hợp vào runtime; mọi chương trình khác đều do người dùng triển khai. Xem bài viết Mô hình lập trình Solana: Giới thiệu về phát triển trên Solana để tìm hiểu chuyên sâu hơn.Địa chỉ dẫn xuất từ chương trình (PDA)
Một địa chỉ xác định được suy ra từ ID chương trình và một tập hợp seed. PDA cho phép chương trình ký cho các tài khoản mà chúng kiểm soát, vì vậy chúng rất cần thiết cho thiết kế chương trình có trạng thái. PDA được cố ý đặt ngoài đường cong nên không tồn tại khóa riêng tương ứng.Proof of History (PoH)
Thành phần nguyên thủy dùng để đồng bộ hóa của Solana — không phải thuật toán đồng thuận. PoH cung cấp một hàm đóng dấu thời gian bằng mật mã, cho phép trình xác thực thống nhất thứ tự sự kiện mà không cần giao tiếp với nhau. Cách triển khai: một chuỗi băm SHA-256 tuần tự chạy liên tục trên một lõi CPU duy nhất cho mỗi trình xác thực, sử dụng đầu ra của mỗi lần lặp làm đầu vào cho lần lặp tiếp theo. Quá trình tạo diễn ra tuần tự và đơn luồng; quá trình xác minh có thể được thực hiện song song. PoH cung cấp các “tick” xác định thời điểm một khối hợp lệ. Leader phải xuất bản khối trong một phạm vi tick PoH nhất định — khối nằm ngoài phạm vi được xem là đã bị bỏ qua. PoH chạy cùng với Tower BFT, cơ chế đồng thuận thực tế. Xem bài viết Giải thích Proof of History, Proof of Stake và Proof of Work để tìm hiểu chuyên sâu hơn.Tiền thuê / Miễn tiền thuê
Số dư SOL mà mọi tài khoản Solana phải nắm giữ để tiếp tục tồn tại onchain, được điều chỉnh theo dung lượng lưu trữ của tài khoản. Tài khoản phải được tạo ở trạng thái miễn tiền thuê: giao dịch khiến tài khoản có số dư thấp hơn mức tối thiểu sẽ thất bại. Khi đã được miễn tiền thuê, tài khoản sẽ tồn tại vô thời hạn mà không cần thanh toán thêm.Sealevel
Công cụ thực thi giao dịch song song của Solana. Không giống các VM tuần tự như EVM, Sealevel thực thi đồng thời nhiều giao dịch trên các lõi CPU. Điều này khả thi vì mọi giao dịch Solana đều khai báo rõ những tài khoản mà giao dịch sẽ đọc và ghi trước khi bắt đầu thực thi, nhờ đó bộ lập lịch có thể xác định các lô không xung đột mà không cần phân tích trong runtime. Quy tắc lập lịch rất đơn giản: các giao dịch truy cập những tài khoản khác nhau chạy song song; các giao dịch chỉ đọc cùng một tài khoản cũng chạy song song (hoạt động đọc không xung đột); các giao dịch ghi vào cùng một tài khoản chạy tuần tự để ngăn tình trạng tranh chấp. Xem bài viết Máy ảo Solana để tìm hiểu chuyên sâu hơn.Slot
Đơn vị thời gian cơ bản của Solana, trong đó một trình xác thực leader được chỉ định có cơ hội tạo khối. Slot hiện có mục tiêu là 400 ms, dù thời lượng thực tế có thể thay đổi tùy điều kiện mạng. Nếu leader không tạo được khối trong slot của mình, slot sẽ bị bỏ qua — mạng chuyển sang slot tiếp theo thay vì chờ đợi, vì vậy không phải slot nào cũng tạo ra khối. Xem bài viết Tìm hiểu slot, khối và epoch trên Solana để tìm hiểu chuyên sâu hơn.SVM (Máy ảo Solana)
Toàn bộ ngăn xếp thực thi giao dịch của Solana — không chỉ là một trình thông dịch bytecode chuyên biệt. SVM bao gồm thành phần Bank điều phối quá trình thực thi, bộ lập lịch Banking Stage, trình nạp BPF và chính máy ảo sBPF (một VM dựa trên thanh ghi với 11 thanh ghi đa dụng và khoảng 100 opcode, được biên dịch JIT để tăng hiệu suất). Khái niệm này khác với EVM, vốn chỉ rõ ràng một trình thực thi bytecode duy nhất. Các chương trình Solana được biên dịch sang sBPF, nhánh eBPF Linux của Solana. Bất kỳ ngôn ngữ nào có frontend LLVM (C, C++, Rust, Zig) đều có thể nhắm đến sBPF. Yêu cầu giao dịch khai báo trước quyền truy cập tài khoản chính là yếu tố mở ra khả năng thực thi song song của Sealevel và thị trường phí cục bộ của Solana. Xem bài viết Máy ảo Solana để tìm hiểu chuyên sâu hơn.Tower BFT
Cơ chế đồng thuận của Solana. Tower BFT là một thuật toán tương tự pBFT tận dụng đồng hồ đồng bộ của Proof of History, loại bỏ nhu cầu về một vòng đồng thuận đồng bộ trong mỗi slot. Trình xác thực xây dựng một “tháp phiếu bầu” — một ngăn xếp phiếu bầu tuần tự, trong đó mỗi phiếu bầu mới nhân đôi thời gian khóa của tất cả phiếu bầu trước đó, làm tăng theo cấp số nhân chi phí mất stake khi chuyển nhánh. Ngưỡng xác nhận: một khối được xác nhận khi ≥2/3 số phiếu có trọng số theo stake đã dành cho khối đó (≥4,6% tổng stake sẽ phải bị cắt giảm để vi phạm tính hoàn tất). Một khối được hoàn tất khi có phiếu bầu cộng với 31 khối tiếp theo được xây dựng bên trên, tức thời gian khóa tối đa của Tower BFT. Xem Mức cam kết để biết hướng dẫn sử dụng. Xem bài viết Đồng thuận trên Solana: Tower BFT và Proof of History để tìm hiểu chuyên sâu hơn.Turbine
Giao thức truyền khối của Solana. Leader chia mỗi khối thành các shred có kích thước MTU cùng các shred khôi phục được mã hóa xóa Reed-Solomon — tỷ lệ FEC (thường là 32:32) cho phép mạng tái tạo một khối ngay cả khi mất khoảng 33% gói. Sau đó, leader chuyển tiếp shred qua một cây xác định gồm các trình xác thực ngang hàng có trọng số theo stake (được tạo seed theo từng nhóm shred bằng(leader id, slot, shred index, shred type)), thay vì phát trực tiếp toàn bộ khối đến mọi trình xác thực. Cây (DATA_PLANE_FANOUT = 200) giữ băng thông gửi đi của leader gần như không đổi bất kể số lượng trình xác thực và cho phép khối tiếp cận mạng trong 2–3 bước nhảy thay vì O(n).
Xem bài viết Turbine: Truyền khối trên Solana.
Trình xác thực
Một nút trên mạng Solana tham gia đồng thuận bằng cách tạo khối trong các slot leader được chỉ định và bỏ phiếu cho khối từ các trình xác thực khác. Trình xác thực được chọn vào slot leader theo tỷ lệ stake đang hoạt động của họ.Cơ chế giao dịch
Bảng tra cứu địa chỉ (ALT)
Một bảng địa chỉ Solana onchain mà giao dịch có phiên bản có thể tham chiếu bằng chỉ mục 1 byte thay vì khóa công khai đầy đủ 32 byte, cho phép một giao dịch duy nhất tham chiếu tối đa 256 tài khoản. ALT rất cần thiết cho các thao tác DeFi phức tạp mà nếu không sẽ vượt quá giới hạn kích thước giao dịch.Blockhash
Một hàm băm 32 byte xác định một khối gần đây, được đưa vào mọi giao dịch Solana để chứng minh tính mới. Blockhash hết hạn sau khoảng 150 slot (~1 phút); giao dịch có blockhash hết hạn sẽ bị từ chối. Ứng dụng khách lấy blockhash gần đây quagetLatestBlockhash ngay trước khi ký.
Phí ưu tiên
Khoản tiền boa trên mỗi đơn vị tính toán được trả cho trình xác thực để giao dịch được ưu tiên hơn các giao dịch khác, giúp rút ngắn thời gian được đưa vào chuỗi. Phí ưu tiên được đặt bằng microlamport trên mỗi đơn vị tính toán (µLamports/CU). API phí ưu tiên của Helius trả về các ước tính theo thời gian thực dựa trên thị trường phí onchain gần đây.Shred
Đơn vị nhỏ nhất của một khối Solana. Các khối được chia (tức được shred) thành các shred để truyền song song trên mạng trình xác thực qua Turbine. Quyền truy cập ở cấp shred cung cấp cho nhà giao dịch tín hiệu onchain có độ trễ cực thấp trước khi khối được lắp ráp — dù Preconfirmations còn đến sớm hơn, trước khi các mục nhập được chia thành shred. Xem Shred thô (UDP) và tổng quan về Shred Delivery.Chất lượng dịch vụ có trọng số theo stake (SWQoS)
Một cơ chế ở cấp giao thức Solana ưu tiên các giao dịch đến leader hiện tại và sắp tới dựa trên stake của bên gửi. Được giới thiệu sau sự cố ngừng hoạt động của Solana vào ngày 30 tháng 4 năm 2022 như một biện pháp chống tấn công Sybil, SWQoS ngăn các nút ngang hàng có ít stake hoặc không có stake độc chiếm băng thông của leader khi tắc nghẽn. Leader cung cấp hai nhóm kết nối đến: khoảng 500 kết nối mở được chia sẻ giữa tất cả nút ngang hàng không có stake và khoảng 2.000 kết nối có trọng số theo stake được phân phối theo tỷ lệ cho các trình xác thực có stake — một trình xác thực nắm giữ X% tổng stake đang hoạt động có thể gửi tối đa X% số gói đến leader. Trình xác thực có dưới khoảng 15.000 SOL stake đang hoạt động (~1/25.000 tổng stake mạng) được xem là không có stake. Ngưỡng stake tối thiểu được đưa vào Agave v1.17.31. Kết nối có stake của Helius thừa hưởng lợi thế về tỷ lệ đưa giao dịch vào chuỗi này bằng cách định tuyến giao dịch của khách hàng qua trình xác thực lớn nhất của Solana, nhờ đó bên gọi được hưởng lợi từ SWQoS mà không cần trực tiếp vận hành một trình xác thực có lượng stake lớn. Xem bài viết Chất lượng dịch vụ có trọng số theo stake: Mọi điều bạn cần biết.Giao dịch có phiên bản
Một định dạng giao dịch Solana được xác định bằng byte phiên bản ở đầu giao dịch đã tuần tự hóa. Phiên bản 0 (v0) bổ sung Bảng tra cứu địa chỉ, cho phép một giao dịch tham chiếu tối đa 256 tài khoản (so với khoảng 35 trong giao dịch cũ). Phiên bản 1 (v1, SIMD-0385, Agave 4.2) chuyển chữ ký xuống cuối giao dịch và mang ngân sách tính toán trong trường tiêu đềtransactionConfig thay vì các lệnh ComputeBudget. Đặt maxSupportedTransactionVersion: 1 trong yêu cầu RPC để nhận mọi phiên bản. Xem Hỗ trợ giao dịch v1.
Token và tài sản
Tài khoản nén
Tài khoản nén là một tài khoản Solana có dữ liệu được cam kết với sổ cái thông qua nhật ký giao dịch, trong khi trạng thái trình xác thực chỉ lưu một dấu vân tay băm — thay vì toàn bộ dữ liệu chiếm một vị trí tài khoản truyền thống trên ổ đĩa của trình xác thực. Nhà phát triển có thể xử lý tài khoản nén như tài khoản thông thường; các trình lập chỉ mục (chẳng hạn như Photon) phân tích nhật ký giao dịch để tái tạo trạng thái hiện tại, còn bằng chứng không tiết lộ có kích thước cố định Groth16 xác minh tính toàn vẹn khi tài khoản được đọc hoặc sửa đổi qua ZK Compression. Mô hình này phù hợp nhất với các tài khoản có ít dữ liệu — dữ liệu lớn hơn (trên khoảng 100 byte) khiến việc nén không còn thực tế.NFT nén (cNFT)
Một NFT Solana được biểu diễn dưới dạng lá trong cây Merkle đồng thời onchain thay vì có tài khoản riêng. Cây nằm trong một tài khoản Solana và các chuyển đổi trạng thái của cây được sổ cái bảo vệ; trạng thái hiện tại của NFT được các trình lập chỉ mục suy ra từ lịch sử giao dịch, đồng thời chúng tạo ra bằng chứng Merkle có thể xác minh dựa trên gốc onchain của cây. Vì vậy, việc đọc cNFT cần trình lập chỉ mục như DAS API — RPC Solana tiêu chuẩn không thể trực tiếp trả về dữ liệu cNFT. Mô hình này giảm chi phí mint đến 99% so với NFT tiêu chuẩn.Cây Merkle đồng thời
Một biến thể Cây Merkle dành riêng cho Solana, được thiết kế để cho phép nhiều bên ghi cập nhật cây trong cùng một slot mà không làm mất hiệu lực bằng chứng của nhau. Tài khoản onchain không chỉ lưu gốc hiện tại mà còn lưu bộ đệm nhật ký thay đổi gồm các gốc hợp lệ gần đây và một canopy (tập hợp con được lưu vào bộ nhớ đệm của các nút phía trên trong cây), cho phép trình xác thực xác minh bằng chứng được tạo dựa trên bất kỳ gốc nào vẫn còn trong cửa sổ bộ đệm. Ba tham số xác định một cây: độ sâu tối đa (giới hạn số lá ở 2^độ sâu), kích thước bộ đệm (độ sâu nhật ký thay đổi — số lần ghi có thể xảy ra trước khi các bằng chứng cũ đang xử lý mất hiệu lực) và độ sâu canopy (đánh đổi tiền thuê onchain để có bằng chứng nhỏ hơn trong giao dịch). Các cặp (độ sâu, bộ đệm) hợp lệ nằm trong khoảng từ (3, 8) đến (30, 2048); để duy trì khả năng kết hợp thực tế, hãy giữmaxDepth − canopyDepth ≤ 10.
Cây Merkle đồng thời được triển khai bởi chương trình SPL Account Compression và là nền tảng cho NFT nén, được mint dưới dạng lá thông qua Metaplex Bubblegum.
Xem bài viết Mọi điều bạn cần biết về nén trên Solana.
Groth16
Một hệ thống chứng minh zk-SNARK tạo ra bằng chứng không tiết lộ có kích thước cố định (128 byte trên đường cong BN254, sử dụng nén điểm) bất kể độ phức tạp của mệnh đề, với thời gian xác minh O(1). ZK Compression sử dụng Groth16 để tạo Bằng chứng hợp lệ cho thấy một tài khoản nén thuộc về một trạng thái đã biết tại một gốc đã biết — kích thước bằng chứng nhỏ là yếu tố giúp giao dịch tài khoản nén có chi phí thấp. Xem bài viết Nhà phát triển Solana: ZK Compression.Tài khoản mint
Tài khoản onchain xác định các thuộc tính của token SPL — nguồn cung, số chữ số thập phân và thẩm quyền mint/đóng băng. Địa chỉ của tài khoản mint là mã định danh chính tắc của token (“địa chỉ hợp đồng” theo thuật ngữ Ethereum).Token SPL
Một token trên Solana được phát hành qua Token Program của Solana Program Library (SPL). Các token có thể thay thế (USDC, BONK, JUP, v.v.) là token SPL; NFT tiêu chuẩn (không nén) cũng là token SPL, được mint với nguồn cung 1 và 0 chữ số thập phân. Token SPL gần tương đương với ERC-20 và ERC-721 trên Ethereum. Token-2022 là một chương trình mới hơn, mở rộng giao diện này bằng các tính năng tùy chọn như phí chuyển và giao dịch chuyển bảo mật.Cây trạng thái
Cây Merkle mà ZK Compression sử dụng để lưu hàm băm của tài khoản nén. Tài khoản onchain chỉ giữ gốc hiện tại cùng siêu dữ liệu tối thiểu; dữ liệu nén thực tế nằm trong nhật ký giao dịch và được các trình lập chỉ mục như Photon tái tạo. Chương trình đọc hoặc sửa đổi trạng thái nén bằng cách truyền vào Bằng chứng hợp lệ cho thấy nội dung được khai báo của tài khoản băm thành một lá dưới gốc hiện tại. Xem ZK Compression.Tài khoản token
Một tài khoản onchain nắm giữ số dư của một token SPL cụ thể cho một chủ sở hữu cụ thể. Ví có thể sở hữu các tài khoản token tùy ý, nhưng quy ước là sử dụng Tài khoản token liên kết (ATA) — một tài khoản token được suy ra theo cách xác định cho mỗi cặp (ví, mint), do Associated Token Account Program tạo.Token-2022 (Phần mở rộng token)
Một biến thể của SPL Token Program hỗ trợ các phần mở rộng tùy chọn (ví dụ: phí chuyển, giao dịch chuyển bảo mật, token sinh lãi, token không thể chuyển nhượng). Token-2022 chạy dưới dạng một chương trình onchain riêng với ID chương trình riêng, nhưng được thiết kế làm phiên bản kế nhiệm tương thích của Token Program cổ điển, vì vậy SDK thường có thể xử lý cả hai. Mint phải được tạo trong chương trình Token-2022 để sử dụng phần mở rộng. Xem bài viết Phần mở rộng token là gì?.Bằng chứng hợp lệ
Một bằng chứng không tiết lộ Groth16 có kích thước cố định, chứng minh rằng nội dung được khai báo của một tài khoản nén đã tồn tại trong Cây trạng thái tại một gốc cụ thể. Các chương trình ZK Compression yêu cầu bằng chứng hợp lệ bất cứ khi nào tài khoản nén được đọc hoặc sửa đổi; bằng chứng cho phép chương trình xác minh trạng thái ngoài chuỗi mà trình xác thực không cần lưu dữ liệu onchain. Photon cung cấp bằng chứng hợp lệ cho bên gọi thông qua phương thức RPCgetValidityProof.
Bằng chứng hợp lệ là yếu tố phân biệt ZK Compression với NFT nén: cNFT sử dụng bằng chứng Merkle thông thường (danh sách hàm băm anh em từ lá đến gốc, tăng theo độ sâu cây), trong khi bằng chứng ZK có kích thước cố định của ZK Compression không tiết lộ đường đi hoặc trạng thái cây xung quanh.
Xem bài viết Nhà phát triển Solana: ZK Compression.
ZK Compression
ZK Compression là một thành phần nguyên thủy của Solana do Helius và Light Protocol phát triển, giúp giảm đáng kể chi phí lưu trữ onchain bằng cách cam kết dữ liệu tài khoản vào nhật ký giao dịch trong sổ cái và chỉ lưu một dấu vân tay băm trong trạng thái trình xác thực. Tính toàn vẹn mật mã được duy trì bằng các bằng chứng không tiết lộ Groth16 có kích thước cố định, được tạo từ dữ liệu giao dịch đã lập chỉ mục. Thành phần nguyên thủy này khác với NFT nén, vốn sử dụng cây Merkle đồng thời mà không có bằng chứng không tiết lộ. Xem ZK Compression và bài viết Nhà phát triển Solana: ZK Compression để tìm hiểu chuyên sâu hơn.Kết nối và truyền phát
Geyser
Hệ thống plugin của Solana dùng để truyền phát các thay đổi trạng thái của trình xác thực — tài khoản, giao dịch, slot, khối — đến bên tiêu thụ bên ngoài theo thời gian thực. Trình xác thực nạp plugin Geyser dưới dạng thư viện động; plugin nhận bản cập nhật trạng thái khi trình xác thực xử lý chúng, loại bỏ nhu cầu liên tục thăm dò RPC để tìm thay đổi. Yellowstone gRPC — plugin Geyser phổ biến nhất — cung cấp các bản cập nhật đó qua gRPC. LaserStream của Helius triển khai giao diện Yellowstone gRPC với các tính năng bổ sung như phát lại lịch sử (tối đa khoảng 48 giờ, khoảng 691.200 slot theo tốc độ mạng hiện tại) và chuyển đổi dự phòng đa khu vực.gRPC
gRPC là một giao thức RPC nhị phân đa dụng, hiệu suất cao (tên viết tắt đệ quy của “gRPC Remote Procedure Call”). Trong ngữ cảnh Solana, “gRPC” thường chỉ Yellowstone gRPC — một giao diện truyền phát được xây dựng trên hệ thống plugin Geyser của Solana, cung cấp các bản cập nhật tài khoản và giao dịch qua gRPC. Dịch vụ LaserStream của Helius được xây dựng trên giao diện dựa trên Yellowstone với các tính năng bổ sung như phát lại lịch sử, chuyển đổi dự phòng đa khu vực và cơ sở hạ tầng được quản lý.RPC
RPC là viết tắt của Remote Procedure Call, một mẫu tổng quát để gọi phương thức máy chủ như thể đó là một hàm cục bộ. Trong Solana, “RPC” thường chỉ nút RPC — một nút theo dõi trạng thái Solana nhưng không tham gia đồng thuận, chuyên phục vụ yêu cầu dữ liệu (tức trạng thái tài khoản, lịch sử giao dịch, gửi giao dịch) qua giao diện JSON-RPC. Ngược lại, trình xác thực tạo khối và bỏ phiếu cho chúng. Dịch vụ RPC của Helius là một đội nút RPC phân tán toàn cầu, được tối ưu hóa cho khối lượng công việc production. Xem bài viết Nút Solana — Nhập môn RPC Solana, trình xác thực và nhà cung cấp RPC để tìm hiểu chuyên sâu hơn.Webhook
Webhook là một yêu cầu HTTP POST được máy chủ gửi đến URL của bên nhận khi một sự kiện đã đăng ký xảy ra — HTTP “đảo ngược”, trong đó máy chủ khởi tạo lệnh gọi. Webhook của Helius đẩy các sự kiện onchain Solana (giao dịch chuyển, bán NFT, hoạt động chương trình tùy chỉnh) đến một điểm cuối đã đăng ký, loại bỏ nhu cầu thăm dò.WebSocket (WSS)
WebSocket là một kết nối TCP hai chiều liên tục được nâng cấp từ HTTP, dùng để truyền phát dữ liệu Solana theo cơ chế đẩy mà không cần lặp lại yêu cầu HTTP. WSS (WebSocket Secure) là cùng giao thức đó chạy qua TLS và là biến thể được dùng cho các kết nối Solana trong production. LaserStream WebSocket — sản phẩm truyền phát WebSocket của Helius, bao gồm các phương thức Solana tiêu chuẩn và phần mở rộng Helius nhưtransactionSubscribe — sử dụng WSS.
Hệ sinh thái
Anchor
Anchor là một framework Rust để xây dựng chương trình Solana nhanh chóng và an toàn. Framework xử lý các mã soạn sẵn như tuần tự hóa tài khoản, xác thực và điều phối lệnh thông qua macro thủ tục, cho phép nhà phát triển tập trung vào logic chương trình thay vì các chi tiết cấp thấp. Hầu hết nhà phát triển Solana sử dụng Anchor thay vì viết chương trình bằng Rust thuần. Xem bài viết Giới thiệu về Anchor: Hướng dẫn xây dựng chương trình Solana cho người mới bắt đầu để tìm hiểu chuyên sâu hơn.IDL
IDL là viết tắt của Interface Definition Language. IDL là một lược đồ JSON mô tả các lệnh, tài khoản và kiểu dữ liệu của chương trình Solana; ứng dụng khách sử dụng nó để xây dựng giao dịch và giải mã dữ liệu chương trình mà không cần tự tạo bố cục lệnh. Anchor tự động tạo IDL và mặc định xuất bản chúng onchain trong một tài khoản chuyên dụng để công chúng có thể tìm thấy.Jito
Một công ty trong hệ sinh thái Solana vận hành công cụ khối phổ biến nhất của mạng — một lớp cơ sở hạ tầng MEV (giá trị có thể trích xuất tối đa) chấp nhận các gói giao dịch (nhóm giao dịch nguyên tử cùng thực thi hoặc hoàn toàn không thực thi) và cho phép bên tìm kiếm trả tiền boa cho trình xác thực để ưu tiên đưa chúng vào chuỗi. Ứng dụng trình xác thực Jito-Solana là một nhánh của Agave có tích hợp công cụ khối. Để được đưa vào gói, cần khoản tiền boa tối thiểu 10.000 lamport và Jito-Relayer giữ lưu lượng đến trong khoảng 200 ms để hỗ trợ phiên đấu giá gói ngoài chuỗi. Sender của Helius đồng thời gửi giao dịch qua cả kết nối có stake và công cụ khối của Jito, sử dụng đường nào đưa giao dịch vào chuỗi trước. Xem bài viết MEV Solana: Giới thiệu.Light Protocol
Nhóm giao thức Solana đồng phát triển ZK Compression với Helius. Helius xây dựng trình lập chỉ mục chính tắc (Photon) và vận hành RPC công khai; Light Protocol xây dựng các chương trình onchain và ngăn xếp chứng minh mà trình lập chỉ mục phụ thuộc vào. Xem github.com/Lightprotocol/light-protocol.Photon
Trình lập chỉ mục ZK Compression mã nguồn mở do Helius xây dựng. Dữ liệu tài khoản nén nằm trong nhật ký giao dịch Solana thay vì trạng thái tài khoản, vì vậy trình xác thực không cung cấp dữ liệu này qua RPC tiêu chuẩn — Photon phân tích giao dịch Solana, tái tạo trạng thái tài khoản nén và phục vụ dữ liệu qua giao diện JSON-RPC mô phỏng RPC gốc của Solana cùng các phương thức dành riêng cho ZK Compression nhưgetCompressedAccount và getValidityProof. Nhà phát triển có thể tự lưu trữ từ github.com/helius-labs/photon hoặc sử dụng điểm cuối do Helius lưu trữ.
Xem ZK Compression.