Tổng quan điều hành về Solana

Giới thiệu

Solana là một blockchain hiệu năng cao, độ trễ thấp, nổi tiếng về tốc độ, hiệu quả và sự tập trung vào trải nghiệm người dùng. Kiến trúc tích hợp độc đáo của Solana cho phép xử lý hàng nghìn giao dịch mỗi giây trên một mạng lưới phi tập trung toàn cầu. Với thời gian tạo khối 400 mili giây và phí giao dịch chỉ bằng một phần nhỏ của một xu, Solana đáp ứng cả yêu cầu về tốc độ lẫn hiệu quả chi phí. Báo cáo này đi sâu vào những điểm phức tạp trong thiết kế và hoạt động của Solana, đồng thời khám phá các cơ chế chủ chốt và cấu trúc liên kết mạng tạo nên năng lực của hệ thống.

Solana áp dụng phương pháp tích hợp trong phát triển blockchain, tận dụng hàng chục năm kinh nghiệm xây dựng hệ thống phân tán của đội ngũ sáng lập. Một trong những nguyên tắc cốt lõi của Solana là phần mềm không bao giờ được cản trở phần cứng. Điều này có nghĩa là phần mềm khai thác tối đa mọi phần cứng mà nó chạy trên đó và mở rộng cùng phần cứng. Trong một hệ sinh thái thống nhất, mọi ứng dụng được xây dựng trên blockchain duy nhất này đều thừa hưởng khả năng kết hợp, cho phép chúng tương tác và phát triển dựa trên nhau một cách liền mạch. Kiến trúc này cũng bảo đảm trải nghiệm người dùng đơn giản, trực quan mà không cần cầu nối, ID chuỗi riêng biệt hay phân mảnh thanh khoản.

Solana đang phát triển nhanh chóng, với những bước tiến gần đây như các SVM rollup và ZK Compression đóng vai trò là những giải pháp mở rộng quan trọng. Dù một ngày nào đó các dự án này có thể định hình cách chúng ta nhìn nhận Solana trong tương lai, hiện chúng vẫn đang ở giai đoạn phát triển hoặc áp dụng rất sớm và sẽ không được đề cập trong báo cáo này.

Vòng đời giao dịch

Trong toàn bộ báo cáo này, chúng ta sẽ chủ yếu tìm hiểu Solana qua vòng đời của một giao dịch điển hình. Để xây dựng mô hình cơ bản nhằm hiểu các giao dịch Solana, có thể phác thảo quy trình như sau: 

• Người dùng khởi tạo giao dịch và tất cả giao dịch được gửi đến nhà sản xuất khối chính hiện tại, được gọi là leader. Leader tập hợp các giao dịch này thành một khối, thực thi chúng và qua đó cập nhật trạng thái cục bộ.
• Khối giao dịch này sau đó được truyền đi khắp mạng để các validator khác thực thi và xác nhận.‍

Các phần tiếp theo của báo cáo sẽ mở rộng mô hình này và đi sâu hơn nhiều vào quy trình, bắt đầu từ những bên tham gia chính—người dùng.

Sáu giai đoạn

Trong suốt báo cáo này, chúng ta sẽ tham chiếu hình minh họa sáu giai đoạn ở trên vì nó cung cấp một khuôn khổ nhất quán để hiểu mối quan hệ giữa các thành phần cốt lõi của Solana.

Các chương đầu được sắp xếp theo sáu giai đoạn này. Những chương cuối—Gossip, Lưu trữ, Kinh tế học và Jito—sẽ hoàn thiện các nội dung còn lại. Cần lưu ý rằng một số chương sẽ bao quát nhiều giai đoạn và một số giai đoạn sẽ xuất hiện trong nhiều chương.

Sự chồng lấn này là không thể tránh khỏi vì khuôn khổ sáu giai đoạn có những giới hạn riêng. Trên thực tế, Solana là một hệ thống phân tán phức tạp với nhiều thành phần phụ thuộc lẫn nhau.

Người dùng

Hành trình của người dùng thường bắt đầu bằng việc thiết lập và nạp tiền vào một ứng dụng ví. Solana có nhiều ứng dụng ví phổ biến, dưới dạng ứng dụng di động gốc hoặc tiện ích mở rộng trình duyệt.

Ví tạo các cặp khóa người dùng bằng mật mã, bao gồm khóa công khai và khóa riêng tư. Khóa công khai đóng vai trò là mã định danh duy nhất cho tài khoản và được tất cả bên tham gia mạng biết đến. Tài khoản của người dùng trên Solana có thể được xem là một cấu trúc dữ liệu lưu giữ thông tin và trạng thái liên quan đến các tương tác của họ với blockchain Solana. Theo nghĩa này, khóa công khai tương tự tên tệp: cũng như tên tệp xác định duy nhất một tệp trong hệ thống tệp, khóa công khai Solana xác định duy nhất một tài khoản trên blockchain Solana. Khóa công khai trên Solana được biểu diễn dưới dạng chuỗi 32 byte mã hóa Base58.

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

Khóa riêng tư—còn gọi là khóa bí mật—có thể được xem như mật khẩu hoặc khóa truy cập cấp quyền truy cập và sửa đổi tài khoản. Ký bằng khóa riêng tư là cách blockchain xử lý việc cấp quyền. Ai biết khóa riêng tư sẽ có toàn quyền đối với tài khoản. Khóa riêng tư Solana cũng dài 32 byte. Cặp khóa là tổ hợp 64 byte gồm khóa công khai (nửa đầu) và khóa riêng tư (nửa sau).

Ví dụ:

3j15jr41S9KmdfughusutvvqBjAeEDbU5sDQp8EbwQ3Hify2pfM1hiEsuFFAVq8bwGywnZpswrbDzPENbBZbd5nj

[63,107,47,255,141,135,58,142,191,245,78,18,90,162,107,197,8,33,211,15,228,235,250,30,185,122,105,23,147,115,115,86,8,155,67,155,110,51,117,0,19,150,143,217,132,205,122,91,167,61,6,246,107,39,51,110,185,81,13,81,16,182,30,71]

Khóa riêng tư cũng có thể được tạo từ cụm từ hạt giống ghi nhớ, thường dài 12 hoặc 24 từ. Định dạng này thường được dùng trong ví để sao lưu và khôi phục dễ dàng hơn. Có thể tạo nhiều khóa theo cách xác định từ một cụm từ hạt giống duy nhất.

Solana sử dụng Ed25519, một thuật toán chữ ký số đường cong elliptic được dùng rộng rãi, cho các nhu cầu mật mã khóa công khai. Ed25519 được ưa chuộng nhờ kích thước khóa nhỏ, kích thước chữ ký nhỏ, tốc độ tính toán nhanh và khả năng chống lại nhiều cuộc tấn công phổ biến. Mỗi địa chỉ ví Solana đại diện cho một điểm trên đường cong elliptic Ed25519.

Người dùng ký giao dịch bằng khóa riêng tư. Chữ ký này được đưa vào dữ liệu giao dịch và các bên tham gia khác có thể xác minh bằng khóa công khai của người gửi. Quy trình này bảo đảm giao dịch không bị can thiệp và đã được chủ sở hữu khóa riêng tư tương ứng cho phép. Chữ ký cũng đóng vai trò là mã định danh duy nhất cho giao dịch.

Giao dịch Solana‍

Gửi giao dịch là cách duy nhất để thay đổi trạng thái trên Solana. Mọi thao tác ghi đều được thực hiện thông qua giao dịch và các giao dịch có tính nguyên tử—hoặc mọi việc giao dịch cố thực hiện đều xảy ra, hoặc giao dịch thất bại. Một giao dịch, tên gọi chính thức hơn là "thông điệp giao dịch", gồm bốn phần: header, danh sách địa chỉ tài khoản, blockhash gần đây và các instruction.

Header

Header chứa các tham chiếu đến danh sách địa chỉ tài khoản, cho biết những tài khoản nào phải ký giao dịch.

Địa chỉ tài khoản

Danh sách này bao gồm tất cả tài khoản sẽ được đọc hoặc ghi trong giao dịch. Việc lập danh sách như vậy cho mọi giao dịch là một yêu cầu đặc thù của Solana và có thể gây khó khăn cho nhà phát triển. Tuy nhiên, biết trước giao dịch sẽ tương tác với những phần trạng thái nào cho phép thực hiện các tối ưu hóa vốn không khả thi trên nhiều blockchain khác.

Blockhash gần đây

Phần này được dùng để ngăn giao dịch trùng lặp và lỗi thời. Một blockhash gần đây sẽ hết hạn sau 150 khối (khoảng 1 phút). Theo mặc định, các RPC cố gắng chuyển tiếp giao dịch sau mỗi 2 giây cho đến khi giao dịch được hoàn tất hoặc blockhash gần đây hết hạn; khi đó giao dịch sẽ bị loại bỏ.

Instruction

Đây là phần cốt lõi của giao dịch. Mỗi instruction đại diện cho một thao tác cụ thể (ví dụ: chuyển, mint, burn, tạo tài khoản, đóng tài khoản). Mỗi instruction chỉ định chương trình cần thực thi, các tài khoản cần thiết và dữ liệu cần dùng để thực thi instruction.

Số lượng instruction trong một giao dịch trước hết bị giới hạn bởi kích thước giao dịch, tối đa 1.232 byte. Số lượng tài khoản có thể được tham chiếu cũng bị giới hạn. Cuối cùng, độ phức tạp của giao dịch được đo bằng đơn vị tính toán (CU) cũng có giới hạn. CU định lượng tài nguyên tính toán được sử dụng khi xử lý giao dịch.

Chi phí bằng SOL để thực thi một giao dịch được chia thành 2 phần: phí cơ bản và phí ưu tiên. Phí cơ bản là mức cố định 5.000 lamport cho mỗi chữ ký, bất kể độ phức tạp của giao dịch—thông thường mỗi giao dịch có 1 chữ ký.

Về mặt kỹ thuật, phí ưu tiên là không bắt buộc, nhưng trở nên cần thiết trong những giai đoạn nhu cầu không gian khối cao. Phí này được định giá bằng micro-lamport (một phần triệu lamport) trên mỗi đơn vị tính toán. Mục đích của nó là đóng vai trò tín hiệu giá, khiến việc đưa giao dịch vào khối trở nên hấp dẫn hơn về mặt kinh tế đối với các node validator. ‍

total fee = prioritization fee + base fee

prioritization fee = compute unit price (micro-lamports) x compute unit limit

Hiện tại, 50% tổng phí liên quan đến giao dịch bị đốt, vĩnh viễn loại lượng SOL này khỏi lưu thông; 50% còn lại được chuyển cho nhà sản xuất khối. Một thay đổi mới (SIMD 96) sắp được áp dụng, cho phép 100% phí ưu tiên được chuyển cho nhà sản xuất khối. Phí cơ bản vẫn không đổi.

Gửi giao dịch

Người dùng kết nối ví với ứng dụng, cho phép ứng dụng đọc khóa công khai của họ. Khóa riêng tư vẫn được mã hóa và cách ly an toàn trong một môi trường tách biệt với ứng dụng.

Ứng dụng xây dựng các tham số của thông điệp giao dịch dựa trên tương tác của người dùng. Ví dụ, nếu muốn hoán đổi hai token, người dùng sẽ chỉ định lượng token cần mua, lượng token tương ứng cần bán và mức trượt giá giao dịch có thể chấp nhận.

Khi thông điệp giao dịch đã sẵn sàng, nó được gửi đến ví để ký bằng khóa riêng tư của người dùng. Lúc này, một cửa sổ bật lên sẽ yêu cầu người dùng xác nhận muốn thực hiện giao dịch. Cửa sổ này có thể bao gồm mô phỏng kết quả giao dịch. Sau khi ký, thông điệp giao dịch và chữ ký được trả về ứng dụng; sau đó ứng dụng có thể chuyển tiếp giao dịch đến nhà cung cấp RPC do mình lựa chọn, có thể là nhà cung cấp riêng hoặc nhà cung cấp của ví.

Các nhà cung cấp RPC (Remote Procedure Call) đóng vai trò trung gian giữa ứng dụng và những validator xây dựng khối. Đây là dịch vụ thiết yếu cho phép ứng dụng gửi hoặc mô phỏng giao dịch đã ký và truy xuất dữ liệu on-chain hiệu quả. Các ứng dụng muốn tương tác với mạng sẽ thực hiện qua endpoint JSON-RPC hoặc WebSocket (tài liệu).

Gulf Stream

RPC (Remote Procedure Call) chỉ các node RPC. Có thể xem các node này là cổng để tương tác và đọc dữ liệu từ mạng. Chúng chạy cùng phần mềm với các validator đầy đủ nhưng có cấu hình khác, cho phép mô phỏng giao dịch chính xác và duy trì góc nhìn cập nhật về trạng thái hiện tại. Tại thời điểm viết bài, mạng Solana có hơn 4.000 node RPC.

Không giống các node validator đầy đủ, node RPC không nắm giữ stake trong mạng. Nếu không có stake, chúng không thể bỏ phiếu hoặc xây dựng khối. Cách thiết lập này khác với hầu hết các blockchain khác, nơi node validator và RPC thường là một. Vì node RPC không nhận phần thưởng staking, mô hình kinh tế của việc vận hành node RPC khác với validator; nhiều node hoạt động như một dịch vụ trả phí dành cho các nhà phát triển vận hành ứng dụng Solana.

Solana nổi bật vì ngay từ đầu đã được thiết kế để hoạt động không cần mempool. Không giống các blockchain truyền thống sử dụng giao thức gossip để truyền giao dịch ngẫu nhiên và rộng khắp mạng, Solana chuyển tiếp mọi giao dịch đến một validator chính được xác định trước cho mỗi slot, gọi là leader.

Khi RPC nhận được một thông điệp giao dịch cần đưa vào khối, nó phải chuyển tiếp thông điệp đó đến leader. Lịch leader được tạo trước mỗi epoch (khoảng hai ngày một lần). Epoch sắp tới được chia thành các slot, mỗi slot cố định ở mức 400 mili giây, và một leader được chọn cho từng slot. Các validator có stake cao hơn sẽ thường xuyên được chọn làm leader hơn trong mỗi epoch. Trong mỗi slot, các thông điệp giao dịch được chuyển tiếp đến leader, bên có cơ hội tạo khối. Khi đến lượt một validator, họ chuyển sang "chế độ leader", bắt đầu chủ động xử lý giao dịch và phát khối đến phần còn lại của mạng.

Chất lượng dịch vụ theo trọng số stake - SWQoS

Đầu năm 2024, Solana giới thiệu một cơ chế mới nhằm ngăn chặn spam và tăng khả năng chống Sybil, gọi là Chất lượng dịch vụ theo trọng số stake (SWQoS). Hệ thống này cho phép leader ưu tiên các thông điệp giao dịch được chuyển tiếp qua những validator có stake khác. Theo đó, validator có stake cao hơn được cấp dung lượng cao hơn theo tỷ lệ để truyền các gói thông điệp giao dịch đến leader. Cách tiếp cận này giảm thiểu hiệu quả các cuộc tấn công Sybil từ những node không có stake trên toàn mạng.

‍Theo mô hình này, các validator cũng có thể ký thỏa thuận cho node RPC thuê dung lượng theo trọng số stake của mình. Đổi lại, node RPC có thêm băng thông, nhờ đó đạt tỷ lệ giao dịch được đưa vào khối cao hơn. Đáng chú ý, 80% dung lượng của leader (2.000 kết nối) được dành cho SWQoS. 20% còn lại (500 kết nối) được phân bổ cho thông điệp giao dịch từ các node không có stake. Chiến lược phân bổ này tương tự làn đường ưu tiên trên cao tốc, nơi tài xế trả phí để tránh ùn tắc.

SWQoS đã tác động đến hệ sinh thái Solana bằng cách nâng cao yêu cầu chuyển tiếp giao dịch đến leader và làm giảm hiệu quả của các cuộc tấn công spam. Thay đổi này khuyến khích các ứng dụng có lưu lượng lớn tích hợp hoạt động theo chiều dọc. Bằng cách vận hành node validator riêng hoặc truy cập các kết nối có stake, ứng dụng có thể bảo đảm quyền truy cập ưu tiên vào leader, qua đó nâng cao khả năng xử lý giao dịch.

Lưu ý về QUIC

Cuối năm 2022, Solana áp dụng giao thức mạng QUIC để quản lý việc truyền thông điệp giao dịch đến leader. Quá trình chuyển đổi này bắt nguồn từ các gián đoạn mạng do bot spam các đợt mint NFT on-chain. QUIC hỗ trợ giao tiếp nhanh và bất đồng bộ.

‍Được Google phát triển lần đầu vào năm 2012, QUIC cố gắng kết hợp ưu điểm của cả hai phía. Nó hỗ trợ giao tiếp nhanh, bất đồng bộ tương tự UDP, nhưng có các phiên bảo mật và chiến lược kiểm soát luồng tiên tiến của TCP. Nhờ đó, hệ thống có thể đặt giới hạn cho từng nguồn lưu lượng để mạng tập trung xử lý các giao dịch hợp lệ. QUIC cũng có khái niệm các stream riêng biệt; vì vậy, nếu một giao dịch bị loại bỏ, nó không cần chặn những giao dịch còn lại. Tóm lại, có thể xem QUIC là nỗ lực kết hợp những đặc tính tốt nhất của TCP và UDP.

Xây dựng khối

Nhiều mạng blockchain xây dựng toàn bộ khối trước khi phát đi, được gọi là xây dựng khối rời rạc. Ngược lại, Solana sử dụng phương pháp xây dựng khối liên tục, trong đó các khối được tập hợp và truyền phát linh hoạt ngay khi được tạo trong slot thời gian được phân bổ, giúp giảm đáng kể độ trễ.

Mỗi slot kéo dài 400 mili giây và mỗi leader được phân bổ bốn slot liên tiếp (1,6 giây) trước khi chuyển sang leader tiếp theo. Để một khối được chấp nhận, tất cả giao dịch trong đó phải hợp lệ và có thể được các node khác tái tạo.

Hai slot trước khi đảm nhận vai trò leader, validator dừng chuyển tiếp giao dịch để chuẩn bị cho khối lượng công việc sắp tới. Trong khoảng thời gian này, lưu lượng đến tăng vọt, vượt quá một gigabyte mỗi giây khi toàn bộ mạng hướng các gói dữ liệu đến leader sắp tiếp quản.

Sau khi được tiếp nhận, các thông điệp giao dịch đi vào Transaction Processing Unit (TPU), logic cốt lõi của validator chịu trách nhiệm sản xuất khối. Tại đây, trình tự xử lý giao dịch bắt đầu với Fetch Stage, nơi các giao dịch được nhận qua QUIC. Tiếp theo, giao dịch chuyển đến SigVerify Stage để trải qua các bước xác thực nghiêm ngặt. Tại đây, validator xác minh tính hợp lệ của chữ ký, kiểm tra số lượng chữ ký có chính xác hay không và loại bỏ giao dịch trùng lặp.

‍Banking Stage

Có thể mô tả Banking Stage là giai đoạn xây dựng khối. Đây là giai đoạn quan trọng nhất của TPU và tên của nó bắt nguồn từ “bank”. Bank đơn giản là trạng thái tại một khối nhất định. Với mỗi khối, Solana có một bank dùng để truy cập trạng thái tại khối đó. Khi một khối được hoàn tất sau khi có đủ validator bỏ phiếu cho nó, các bản cập nhật tài khoản từ bank sẽ được ghi xuống đĩa và trở thành vĩnh viễn. Trạng thái cuối cùng của chuỗi là kết quả của mọi giao dịch đã được xác nhận. Trạng thái này luôn có thể được tái tạo theo cách xác định từ lịch sử blockchain.‍

Các giao dịch được xử lý song song và đóng gói thành các “entry” của sổ cái, tức những lô gồm 64 giao dịch không xung đột. Việc xử lý giao dịch song song trên Solana trở nên dễ dàng vì mỗi giao dịch phải bao gồm danh sách đầy đủ tất cả tài khoản mà nó sẽ đọc và ghi. Lựa chọn thiết kế này tạo thêm gánh nặng cho nhà phát triển nhưng cho phép validator dễ dàng chỉ chọn các giao dịch không xung đột để thực thi trong từng entry, từ đó tránh tình trạng tranh chấp. Các giao dịch xung đột nếu cả hai cùng cố ghi vào một tài khoản (hai thao tác ghi), hoặc nếu một giao dịch cố đọc còn giao dịch kia ghi vào cùng tài khoản (đọc + ghi). Vì vậy, các giao dịch xung đột được đưa vào các entry khác nhau và thực thi tuần tự, còn các giao dịch không xung đột được thực thi song song.

Có sáu luồng xử lý giao dịch song song, trong đó bốn luồng dành cho giao dịch thông thường và hai luồng chỉ xử lý giao dịch bỏ phiếu—một phần không thể thiếu trong cơ chế đồng thuận của Solana. Toàn bộ quá trình song song hóa xử lý được thực hiện qua nhiều lõi CPU; validator không yêu cầu GPU (tài liệu).‍

Sau khi giao dịch được nhóm thành các entry, chúng đã sẵn sàng để Solana Virtual Machine (SVM) thực thi. Các tài khoản cần thiết cho giao dịch bị khóa; hệ thống tiến hành kiểm tra để xác nhận giao dịch còn mới nhưng chưa từng được xử lý. Các tài khoản được tải và logic giao dịch được thực thi, qua đó cập nhật trạng thái tài khoản. Hash của entry sẽ được gửi đến dịch vụ Proof of History để ghi lại (phần tiếp theo sẽ trình bày chi tiết hơn). Nếu quá trình ghi thành công, mọi thay đổi sẽ được commit vào bank và các khóa được đặt trên từng tài khoản ở bước đầu tiên sẽ được gỡ bỏ. Việc thực thi do SVM đảm nhiệm, một máy ảo được xây dựng bằng bản fork rBPF của Solana, là thư viện dùng để làm việc với biên dịch JIT và các máy ảo cho chương trình eBPF. Lưu ý rằng Solana không quy định cách validator sắp xếp giao dịch trong một khối. Tính linh hoạt này là điểm then chốt mà chúng ta sẽ quay lại trong phần Kinh tế học + Jito ở phần sau của báo cáo.‍

Client

Solana là một mạng gồm hàng nghìn node được vận hành độc lập, cùng phối hợp để duy trì một sổ cái thống nhất duy nhất. Mỗi node là một máy hiệu năng cao chạy cùng một phần mềm nguồn mở được gọi là “client”.

Solana ra mắt với một phần mềm client validator duy nhất—ban đầu là client Solana Labs, nay được gọi là client Agave —được viết bằng Rust. Kể từ đó, mở rộng tính đa dạng của client luôn là ưu tiên và sẽ thực sự thành hiện thực khi client Firedancer ra mắt. Firedancer là bản viết lại hoàn toàn từ đầu của client gốc bằng ngôn ngữ lập trình C. Được xây dựng bởi một đội ngũ giàu kinh nghiệm từ công ty giao dịch tần suất cao Jump, Firedancer hứa hẹn trở thành client validator có hiệu năng cao nhất trên mọi blockchain.

Proof of History

Proof of History (PoH) là bí quyết cốt lõi của Solana, hoạt động như một chiếc đồng hồ đặc biệt trong mỗi validator để hỗ trợ đồng bộ hóa trên toàn mạng. PoH thiết lập một nguồn sự thật đáng tin cậy về thứ tự sự kiện và dòng chảy thời gian. Quan trọng nhất, cơ chế này bảo đảm tuân thủ lịch trình leader. Dù có tên gọi tương tự, Proof of History không phải là một thuật toán đồng thuận như Proof of Work.

‍Chi phí giao tiếp giữa các node thường tăng khi mạng mở rộng, khiến việc phối hợp ngày càng phức tạp. Solana giảm thiểu vấn đề này bằng cách thay giao tiếp giữa các node bằng một phép tính PoH cục bộ. Nhờ đó, validator có thể cam kết một block chỉ với một vòng bỏ phiếu. Dấu thời gian đáng tin cậy trong thông điệp bảo đảm các validator không thể vượt mặt nhau và bắt đầu block quá sớm.

Nền tảng của PoH là các thuộc tính độc đáo của thuật toán băm, cụ thể là SHA256:

• Tính xác định: Cùng một đầu vào luôn tạo ra cùng một giá trị băm.
• Kích thước cố định: Bất kể kích thước đầu vào, giá trị băm đầu ra luôn là 256 bit.
• Hiệu quả: Có thể nhanh chóng tính giá trị băm cho bất kỳ đầu vào nào.
• Khả năng chống truy tìm ảnh trước: Không thể tìm đầu vào ban đầu từ đầu ra băm trong phạm vi tính toán khả thi.
• Hiệu ứng thác lũ: Một thay đổi nhỏ trong đầu vào, dù chỉ một bit, cũng tạo ra giá trị băm khác biệt đáng kể; thuộc tính này được gọi là hiệu ứng thác lũ.
• Khả năng chống va chạm: Không thể tìm hai đầu vào khác nhau tạo ra cùng một đầu ra băm trong phạm vi khả thi.

Trong mỗi client validator, một "dịch vụ Proof of History" chuyên dụng liên tục chạy thuật toán băm SHA256 để tạo thành chuỗi giá trị băm. Đầu vào của mỗi giá trị băm là đầu ra của giá trị băm trước đó. Chuỗi này hoạt động tương tự một hàm trì hoãn có thể xác minh, vì công việc băm phải được thực hiện tuần tự và không thể biết trước kết quả của các giá trị băm trong tương lai. Nếu dịch vụ PoH tạo ra một chuỗi gồm một nghìn giá trị băm, ta biết rằng thời gian đã trôi qua để dịch vụ tính tuần tự từng giá trị — có thể coi đây là một “proof of work vi mô”. Tuy nhiên, các validator khác có thể xác minh song song tính chính xác của một nghìn giá trị băm với tốc độ nhanh hơn nhiều so với lúc chúng được tạo ra, vì đầu vào và đầu ra của mỗi giá trị băm đã được phát lên mạng. Do đó, PoH khó tạo nhưng dễ xác minh.

Phạm vi hiệu năng tính toán SHA-256 giữa các CPU khác nhau hẹp đến đáng ngạc nhiên, chỉ có khác biệt nhỏ giữa những máy nhanh nhất. Một giới hạn trên phổ biến đã được xác lập, dù đã đầu tư đáng kể thời gian và công sức để tối ưu hóa hàm này, phần lớn do Bitcoin phụ thuộc vào nó.

‍Trong slot của một leader, dịch vụ PoH sẽ nhận các entry mới được xử lý từ giai đoạn banking. Giá trị băm PoH hiện tại cùng giá trị băm của tất cả transaction trong entry được kết hợp để tạo thành giá trị băm PoH tiếp theo. Giá trị này đóng vai trò là dấu thời gian chèn entry vào chuỗi giá trị băm, qua đó chứng minh trình tự xử lý các transaction. Quy trình này không chỉ xác nhận thời gian đã trôi qua mà còn tạo thành bản ghi mật mã của các transaction.

Trong một block có 800.000 giá trị băm. Luồng PoH cũng chứa các "tick", tức các entry trống biểu thị leader vẫn đang hoạt động và thời gian đã trôi qua, xấp xỉ một phần nhỏ của giây. Một tick xuất hiện sau mỗi 6,25 mili giây, tạo ra 64 tick mỗi block và tổng thời gian block là 400 mili giây.

Các validator liên tục chạy đồng hồ PoH ngay cả khi không phải là leader, vì đồng hồ này giữ vai trò then chốt trong quá trình đồng bộ hóa giữa các node.

Mô hình account

Trong một validator Solana, trạng thái toàn cục được duy trì trong cơ sở dữ liệu account có tên AccountsDB. Cơ sở dữ liệu này chịu trách nhiệm lưu trữ mọi account, cả trong bộ nhớ lẫn trên đĩa. Cấu trúc dữ liệu chính trong chỉ mục account là hashmap, khiến AccountsDB về cơ bản trở thành một kho khóa-giá trị khổng lồ. Tại đây, khóa là địa chỉ account và giá trị là dữ liệu account.

Theo thời gian, số lượng account Solana đã tăng lên hàng trăm triệu. Con số lớn này một phần là vì, như các nhà phát triển Solana thường nói, "Mọi thứ trên Solana đều là một account!"

Account Solana

Account là một vùng chứa lưu trữ dữ liệu lâu dài, tương tự một tệp trên máy tính. Account có nhiều dạng:

• Account người dùng: Các account này có khóa riêng tư và thường được phần mềm ví tạo cho người dùng.
• Account dữ liệu: Các account này lưu trữ thông tin trạng thái, chẳng hạn số lượng một token cụ thể mà người dùng nắm giữ.
• Account chương trình: Đây là các account lớn hơn, chứa bytecode có thể thực thi, gần tương đương với tệp .exe trên Windows hoặc .app trên Mac.
• Account chương trình gốc: Đây là các account chương trình đặc biệt được triển khai sẵn để thực hiện nhiều chức năng cốt lõi của mạng. Ví dụ gồm Vote Program và BPF Loader.

Mọi account đều có các trường sau:

Chương trình‍

Account chương trình Solana chỉ chứa logic có thể thực thi. Điều này có nghĩa là khi chạy, chương trình sẽ thay đổi trạng thái của các account khác nhưng bản thân nó không thay đổi. Việc tách biệt code và state này giúp Solana khác với các blockchain khác và hỗ trợ nhiều hoạt động tối ưu hóa. Các nhà phát triển chủ yếu viết chương trình bằng Rust, một ngôn ngữ lập trình đa dụng nổi bật nhờ chú trọng mạnh vào tính an toàn và hiệu năng. Ngoài ra, nhiều SDK bằng TypeScript và Python cũng có sẵn để hỗ trợ xây dựng giao diện người dùng ứng dụng và cho phép tương tác với mạng bằng chương trình.

Các chương trình gốc cung cấp sẵn nhiều chức năng phổ biến. Ví dụ, Solana không yêu cầu nhà phát triển triển khai code để tạo token. Thay vào đó, các instruction được gửi đến một chương trình gốc đã triển khai sẵn. Chương trình này sẽ thiết lập một account để lưu metadata của token, qua đó tạo token mới.

Phí lưu trữ

Phí lưu trữ là cơ chế được thiết kế để khuyến khích người dùng đóng account và giảm tình trạng phình to trạng thái. Để tạo account mới, account phải duy trì số dư SOL tối thiểu, được gọi là mức "miễn phí lưu trữ". Có thể xem đây là chi phí lưu trữ để giữ account hoạt động trong bộ nhớ của validator. Nếu kích thước dữ liệu của account tăng, yêu cầu số dư tối thiểu cho phí lưu trữ cũng tăng theo tỷ lệ. Khi không còn cần account, người dùng có thể đóng account và phí lưu trữ sẽ được hoàn lại cho chủ sở hữu. 

Ví dụ, nếu người dùng nắm giữ stablecoin neo theo đô la, trạng thái này được lưu trong một token account. Hiện tại, mức miễn phí lưu trữ cho token account là 0,002 SOL. Nếu người dùng chuyển toàn bộ số dư stablecoin cho bạn bè, token account có thể được đóng và người dùng sẽ nhận lại 0,002 SOL. Các chương trình thường tự động xử lý việc đóng account cho người dùng. Một số ứng dụng giúp người dùng dọn dẹp các account cũ không còn sử dụng và thu hồi lượng SOL nhỏ được lưu trong đó.

Quyền sở hữu

Mặc dù mọi người đều có thể đọc dữ liệu account, mô hình sở hữu của Solana tăng cường bảo mật bằng cách giới hạn chính xác đối tượng có thể sửa đổi (ghi) dữ liệu của account. Khái niệm này rất quan trọng để thực thi các quy tắc và quyền trên blockchain Solana. Mỗi account có một chương trình "chủ sở hữu". Chủ sở hữu account chịu trách nhiệm quản lý account, bảo đảm chỉ những chương trình được ủy quyền mới có thể thay đổi dữ liệu. Một ngoại lệ đáng chú ý là việc chuyển lamport (đơn vị nhỏ nhất của SOL) — bất kỳ ai cũng có thể tăng số dư lamport của account, bất kể quyền sở hữu.

Lưu trữ trạng thái

Vì là các tệp thực thi chỉ đọc, chương trình Solana phải lưu trữ trạng thái bằng “Program Derived Addresses” (PDA). PDA là loại account đặc biệt được liên kết với và thuộc sở hữu của một chương trình thay vì một người dùng cụ thể. Trong khi địa chỉ người dùng Solana thông thường được tạo từ khóa công khai của một cặp khóa Ed25519, PDA không có khóa riêng tư. Thay vào đó, khóa công khai của chúng được tạo từ tổ hợp các tham số — thường là từ khóa hoặc địa chỉ account khác — cùng với ID chương trình (địa chỉ) của chương trình sở hữu.

Địa chỉ PDA nằm "ngoài đường cong", nghĩa là không nằm trên đường cong Ed25519 như địa chỉ thông thường. Chỉ chương trình sở hữu PDA mới có thể tạo chữ ký cho PDA bằng chương trình, qua đó bảo đảm đây là thực thể duy nhất có thể sửa đổi trạng thái của PDA.

Turbine

Trong giai đoạn banking, các transaction được sắp xếp thành entry và gửi đến luồng Proof of History để đóng dấu thời gian. Bank của block được cập nhật và các entry giờ đã sẵn sàng cho giai đoạn tiếp theo — Turbine.

Turbine là quy trình leader dùng để truyền block của mình đến phần còn lại của mạng. Lấy cảm hứng từ BitTorrent, Turbine được thiết kế để hoạt động nhanh và hiệu quả, giảm chi phí giao tiếp và lượng dữ liệu leader cần gửi.

‍Turbine thực hiện điều này bằng cách chia dữ liệu transaction thành các "shred'' thông qua quy trình gọi là "shredding". Shred là các gói dữ liệu nhỏ, tối đa 1.280 byte, tương tự từng frame trong luồng video. Khi được ghép lại, các shred cho phép validator phát lại toàn bộ block. Shred được gửi qua internet giữa các validator bằng UDP và sử dụng mã xóa để xử lý tình trạng mất gói hoặc cố ý loại bỏ gói. Mã xóa, một cơ chế phát hiện và sửa lỗi dựa trên đa thức, bảo đảm tính toàn vẹn của dữ liệu. Ngay cả khi một số shred bị mất, block vẫn có thể được tái tạo.

Các shred được nhóm thành những lô gọi là lô sửa lỗi chuyển tiếp (FEC). Theo mặc định, mỗi lô gồm 64 shred (32 shred dữ liệu + 32 shred khôi phục). Dữ liệu được khôi phục theo từng lô FEC, nghĩa là ngay cả khi tối đa một nửa số gói trong lô bị mất hoặc hỏng, toàn bộ dữ liệu vẫn có thể được phục hồi. Mỗi lô 64 shred được tổ chức thành cây Merkle, với root được leader ký và liên kết với lô trước đó. Quy trình này bảo đảm có thể lấy shred một cách an toàn từ bất kỳ node nào đang nắm giữ chúng trong mạng, vì chuỗi Merkle root cung cấp đường dẫn có thể xác minh về tính xác thực và toàn vẹn.

Ban đầu, leader phát đến một root node duy nhất, node này phân phối shred đến tất cả validator node khác. Root node thay đổi theo từng shred. Các validator được sắp xếp thành nhiều tầng, tạo nên "Cây Turbine". Validator có lượng stake lớn hơn thường nằm gần đỉnh cây, còn validator có stake thấp hơn nằm gần đáy.

‍Cây thường trải dài qua hai hoặc ba hop, tùy vào số validator đang hoạt động. Để đơn giản hóa hình ảnh, sơ đồ trên minh họa fanout là 3, nhưng giá trị fanout thực tế của Solana hiện được đặt là 200. Vì lý do bảo mật, thứ tự của cây được xoay vòng với mỗi lô shred mới.

Mục tiêu chính của hệ thống này là giảm áp lực dữ liệu đầu ra lên leader và root node. Bằng cách sử dụng cơ chế truyền và truyền lại, tải được phân bổ giữa leader và các node truyền lại, giảm áp lực lên từng node riêng lẻ.

Đồng thuận

Khi validator nhận block mới từ leader qua Turbine, validator phải xác thực mọi transaction trong từng entry. Quá trình này bao gồm phát lại toàn bộ block, xác thực song song các giá trị băm PoH, tái tạo transaction theo trình tự do PoH quy định và cập nhật bank cục bộ. 

‍Quy trình này do Transaction Validation Unit (TVU) xử lý. TVU tương tự Transaction Processing Unit (TPU) của leader, đóng vai trò là logic cốt lõi chịu trách nhiệm xử lý shred và xác thực block. Giống TPU, luồng TVU được chia thành nhiều giai đoạn, bắt đầu với Shred Fetch Stage, nơi các shred được nhận qua Turbine. Trong Shred Verify Leader Signature Stage tiếp theo, shred trải qua nhiều bước kiểm tra tính hợp lệ, nổi bật nhất là xác minh chữ ký của leader để bảo đảm shred nhận được thực sự bắt nguồn từ leader. ‍

Trong Retransmit Stage, dựa trên vị trí của mình trong cây Turbine, validator chuyển tiếp shred đến các validator hạ nguồn thích hợp. Trong Replay Stage, validator tái tạo chính xác từng transaction theo đúng thứ tự, đồng thời cập nhật phiên bản bank cục bộ.

Replay Stage tương tự giai đoạn banking trong TPU; đây là giai đoạn quan trọng nhất và có thể được mô tả trực tiếp hơn là giai đoạn xác thực block. Replay là một vòng lặp xử lý đơn luồng điều phối nhiều hoạt động chính, gồm bỏ phiếu, đặt lại đồng hồ PoH và chuyển đổi bank. 

Đồng thuận

Để đạt được đồng thuận, Solana sử dụng Tower BFT (TBFT), một cách triển khai tùy chỉnh của thuật toán Practical Byzantine Fault Tolerance (PBFT) nổi tiếng, thường được phần lớn blockchain dùng để thống nhất trạng thái của chuỗi. Giống mọi blockchain, Solana giả định có các node độc hại trong mạng, vì vậy hệ thống không chỉ phải chịu được lỗi node mà còn phải chống chịu được một số mức độ tấn công nhất định.

Tower BFT khác với các chuỗi khác nhờ tận dụng đồng hồ đồng bộ do Proof of History cung cấp. Trong khi PBFT truyền thống cần nhiều vòng giao tiếp để thống nhất thứ tự transaction, các node Solana sử dụng thứ tự sự kiện đã được thiết lập trước, qua đó giảm đáng kể chi phí truyền thông điệp.

Bỏ phiếu

‍Để tham gia đồng thuận và nhận phần thưởng, validator gửi phiếu bầu cho những block mà họ tin là hợp lệ (tức không có vấn đề như chi tiêu kép hoặc chữ ký không chính xác) và nên được xem là chính thống. Validator trả phí transaction cho các phiếu bầu này. Leader xử lý và đưa chúng vào block cùng với transaction thông thường của người dùng. Đây là lý do transaction Solana thường được phân loại thành transaction bỏ phiếu và không bỏ phiếu. Khi validator gửi phiếu bầu chính xác và thành công, họ nhận được một credit. Cơ chế này khuyến khích validator bỏ phiếu cho fork mà họ tin có khả năng được chọn cao nhất, tức fork “nặng nhất”.

Fork

Một phần trong thiết kế giúp Solana hoạt động nhanh là mạng không chờ tất cả validator thống nhất về một block mới tạo trước khi tạo block tiếp theo. Vì vậy, việc hai block khác nhau cùng liên kết với một block cha và tạo ra các fork không phải là hiếm.

Validator Solana phải bỏ phiếu cho các fork này và dùng thuật toán đồng thuận để xác định fork sẽ được chấp nhận. Khi có các fork cạnh tranh, cuối cùng mạng chỉ hoàn tất một fork, còn các block trong những fork bị loại sẽ bị từ bỏ.

Mỗi slot có một leader được xác định trước và chỉ block của leader đó được chấp nhận; không thể có hai block được đề xuất cho cùng một slot. Vì vậy, số fork tiềm năng bị giới hạn trong một danh sách bỏ qua "có/không" có thể xuất hiện tại ranh giới giữa các slot luân chuyển leader. Khi validator chọn một fork, validator bị ràng buộc với fork đó cho đến khi thời gian khóa hết hạn, nghĩa là phải giữ nguyên lựa chọn trong một khoảng thời gian tối thiểu.

‍"Tỷ lệ bỏ qua" của Solana — tỷ lệ phần trăm slot không tạo được block — dao động từ 2% đến 10%, trong đó fork là nguyên nhân chính khiến các slot này bị bỏ qua. Những nguyên nhân khác có thể gồm thời điểm bắt đầu epoch mới, leader ngoại tuyến hoặc tạo ra block không hợp lệ.

Hãy nhớ:

Trạng thái của một transaction trên Solana thay đổi tùy theo giai đoạn hiện tại trong quy trình đồng thuận:

• Đã xử lý: Transaction đã được đưa vào một block.
• Đã xác nhận: Block chứa transaction đã nhận được phiếu bầu của đại đa số hai phần ba.
• Đã hoàn tất: Hơn 31 block đã được xây dựng trên block chứa transaction.

Cho đến nay, chưa từng có trường hợp nào trong lịch sử Solana mà một block đã được xác nhận (theo hướng lạc quan) lại không được hoàn tất.‍

Với mỗi block, Solana dùng một bank để truy cập trạng thái tại block đó. Khi bank được hoàn tất, các cập nhật account từ bank đó và các ancestor của nó được ghi xuống đĩa. Ngoài ra, mọi cập nhật account từ các bank trước đó không phải ancestor của bank đã hoàn tất đều bị loại bỏ. Quy trình này cho phép Solana duy trì nhiều trạng thái tiềm năng một cách hiệu quả.

Gossip + Lưu trữ

Gossip

Có thể xem mạng gossip là mặt phẳng điều khiển của mạng Solana. Không giống mặt phẳng dữ liệu xử lý luồng transaction, mặt phẳng điều khiển phân phối metadata quan trọng về trạng thái blockchain, chẳng hạn thông tin liên hệ, độ cao ledger và thông tin bỏ phiếu. Nếu không có gossip, validator và RPC sẽ không biết địa chỉ và cổng nào đang mở để giao tiếp giữa các dịch vụ. Các node mới cũng dựa vào gossip để tham gia mạng.

Giao thức gossip của Solana sử dụng giao tiếp ngang hàng phi chính thức cùng cách phát quảng bá dạng cây lấy cảm hứng từ thuật toán PlumTree đã sửa đổi. Phương pháp này truyền thông tin hiệu quả mà không phụ thuộc vào bất kỳ nguồn trung tâm nào.

Gossip hoạt động phần nào như một hệ thống biệt lập, độc lập với hầu hết thành phần validator khác. Validator và RPC chia sẻ các đối tượng dữ liệu đã ký sau mỗi 0,1 giây qua UDP bằng gossip, bảo đảm thông tin luôn sẵn có trên toàn mạng. Mọi thông điệp gossip phải có kích thước nhỏ hơn hoặc bằng đơn vị truyền tối đa (MTU) 1.280 byte, được gọi là "packet struct" trong codebase.

Bản ghi gossip là các đối tượng dữ liệu thực tế được chia sẻ giữa các node. Có khoảng 10 loại bản ghi khác nhau, mỗi loại phục vụ một mục đích riêng. Bản ghi gossip được ký, gắn phiên bản và đóng dấu thời gian để bảo đảm tính toàn vẹn và tính cập nhật.

Có bốn loại thông điệp gossip:‍

1. Push: Loại thông điệp phổ biến nhất, chia sẻ thông tin với một nhóm "push peer".
2. Pull & Pull Response: Định kỳ kiểm tra các thông điệp bị bỏ lỡ, trong đó phản hồi pull gửi lại thông tin mà node chưa có.
3. Prune: Cho phép node giảm có chọn lọc số lượng kết nối đang duy trì.
4. Ping & Pong: Kiểm tra tình trạng của node — nếu gửi ping thì phải nhận lại pong, cho biết peer node vẫn đang hoạt động.

Dữ liệu gossip được lưu trong Cluster Replicated Data Store (CrdsTable). Cấu trúc dữ liệu này có thể phát triển rất lớn và cần được cắt giảm định kỳ.

Lưu trữ

Solana khác biệt với các blockchain khác ở chỗ không yêu cầu toàn bộ lịch sử để xác định trạng thái hiện tại của một account. Mô hình account của Solana bảo đảm trạng thái tại bất kỳ slot nào cũng được biết, cho phép validator lưu trạng thái hiện tại của từng account mà không cần xử lý mọi block trong lịch sử. Theo thiết kế, RPC và validator không lưu giữ toàn bộ ledger lịch sử. Thay vào đó, chúng thường chỉ lưu dữ liệu transaction của 1 hoặc 2 epoch (2–4 ngày), đủ để xác thực phần đầu chuỗi.

Các kho lưu trữ hiện do "warehouse node" quản lý. Chúng được vận hành bởi các nhà cung cấp dịch vụ RPC chuyên nghiệp, Solana Foundation và những bên tham gia hệ sinh thái khác muốn bảo đảm lịch sử transaction luôn sẵn có. Warehouse node thường duy trì một hoặc cả hai loại sau:

1. Kho lưu trữ ledger: Tải lên ledger thô và snapshot AccountsDB phù hợp để phát lại từ đầu.
2. Phiên bản Google Bigtable: Lưu dữ liệu block từ genesis block trở đi, được định dạng để phục vụ yêu cầu RPC.

Kinh tế học + Jito

Solana sử dụng lạm phát để phân phối phần thưởng staking bằng cách tạo token SOL mới trong mỗi epoch. Quy trình này khiến tỷ trọng trong mạng của người không staking giảm so với người staking, dẫn đến việc chuyển giao tài sản từ người không staking sang người staking. Lạm phát bắt đầu vào đầu năm 2021 với tỷ lệ ban đầu là 8%, giảm 15% mỗi năm cho đến khi ổn định ở mức dài hạn 1,5%.

‍Bất kỳ người nắm giữ token SOL nào cũng có thể nhận phần thưởng và giúp bảo vệ mạng bằng cách staking token vào một hoặc nhiều validator. Việc phân bổ token cho validator được gọi là ủy quyền. Ủy quyền token cho validator thể hiện sự tin tưởng vào validator đó. Tuy nhiên, việc này không trao cho validator quyền sở hữu hoặc kiểm soát token. Mọi hành động staking, unstaking và ủy quyền đều được thực hiện vào đầu epoch mới tiếp theo.

Phần thưởng bỏ phiếu

‍Khi validator gửi phiếu bầu, họ nhận được một credit nếu phiếu bầu chính xác và thành công. Transaction bỏ phiếu có phí 0,000005 SOL và được miễn phí ưu tiên. Chi phí bỏ phiếu vào khoảng 1 SOL mỗi ngày cho mỗi validator, khiến đây trở thành chi phí vận hành chính khi chạy validator. Trong suốt một epoch, validator tích lũy credit từ việc bỏ phiếu và có thể đổi chúng lấy một phần lạm phát vào cuối epoch.

Các validator hoạt động tốt nhất bỏ phiếu thành công cho khoảng 90% số slot. Lưu ý rằng tỷ lệ slot không có block (tỷ lệ slot bị bỏ qua) dao động từ 2% đến hơn 10% và không thể bỏ phiếu cho các slot này. Một validator trung bình bỏ phiếu thành công cho khoảng 80% số slot, nhận 345.600 credit trong một epoch gồm 432.000 slot.

Tổng quỹ lạm phát trước tiên được phân chia dựa trên số credit kiếm được trong epoch. Tỷ trọng credit của một validator trong tổng số credit (credit của họ chia cho tổng credit của tất cả validator) quyết định phần thưởng tương ứng. Kết quả này tiếp tục được tính trọng số theo stake.

Do đó, một validator nắm 1% tổng stake sẽ nhận khoảng 1% tổng lạm phát nếu có số credit ở mức trung bình. Nếu số credit cao hơn hoặc thấp hơn mức trung bình, phần thưởng sẽ thay đổi tương ứng.‍

Khác biệt về hiệu suất bỏ phiếu là một lý do khiến lợi nhuận (đo bằng APY) mà validator cung cấp cho người staking không giống nhau. Một yếu tố khác là tỷ lệ hoa hồng do validator thu, tức một tỷ lệ phần trăm trong tổng phần thưởng lạm phát được chuyển đến validator của họ. Ngoài ra, việc validator ngoại tuyến hoặc không đồng bộ với blockchain (được gọi là delinquency) ảnh hưởng đáng kể đến lợi nhuận.

Phần thưởng block

Validator được chỉ định làm leader cho một block cụ thể sẽ nhận thêm phần thưởng block. Phần thưởng này gồm 50% phí cơ bản và 50% phí ưu tiên của mọi transaction trong block; phần phí còn lại bị đốt. Chỉ validator tạo ra block mới nhận được phần thưởng này. Không giống phần thưởng staking được phân phối theo từng epoch, phần thưởng block được ghi có ngay vào account định danh của validator khi block được tạo.

Liquid staking

Liquid staking đã trở thành một lựa chọn thay thế phổ biến cho staking gốc. Người tham gia nhận một token gọi là Liquid Staking Token (LST) hoặc Liquid Staking Derivative (LSD) để đổi lấy việc staking SOL, thường trong một stake pool phân bổ token của họ cho nhiều validator. Token LST mới nhận đại diện cho phần SOL đã staking của người dùng. Những token này có thể được giao dịch, sử dụng trong các ứng dụng hoặc chuyển cho người khác mà vẫn tiếp tục nhận phần thưởng staking. Lợi thế lớn nhất của hệ thống này là nâng cao đáng kể hiệu quả sử dụng vốn.

Price of LST = (total staked SOL in pool * price of SOL) / total LST minted

Với staking gốc truyền thống, theo thời gian, người staking sẽ trực tiếp tích lũy thêm SOL. Trong khi đó, với liquid staking, phần thưởng được tái đầu tư vào pool, làm tăng giá trị hợp lý của LST. Miễn là có cơ chế đổi LST lấy lượng SOL đã staking làm tài sản cơ sở, các nhà giao dịch chênh lệch giá sẽ bảo đảm giá token luôn hợp lý.

Jito

Tại thời điểm viết bài, hơn 80% (nguồn) stake trên Solana sử dụng phần mềm validator client Jito. Client này là một fork của client Agave ban đầu và bổ sung phiên đấu giá blockspace ngoài giao thức, mang lại thêm động lực kinh tế cho validator thông qua tiền tip. Động lực bổ sung này là yếu tố chính khiến client Jito được sử dụng rộng rãi trong cộng đồng validator.

Khi leader sử dụng validator client Jito, transaction của họ trước tiên được chuyển đến Jito-Relayer. Phần mềm nguồn mở này hoạt động như một router proxy cho transaction. Các node khác trong mạng không biết Jito-Relayer tồn tại, vì chúng chỉ gửi transaction đến cấu hình địa chỉ và cổng mà leader đã quảng bá qua mạng gossip làm ingress_socket của mình, với giả định đó là địa chỉ của leader.

‍Relayer giữ tất cả transaction trong 200 mili giây trước khi chuyển tiếp đến leader. Cơ chế "gờ giảm tốc" này trì hoãn các thông điệp transaction đến, tạo ra một khoảng thời gian ngắn để tổ chức đấu giá. Sau 200 mili giây, relayer chủ động giải phóng transaction bất kể kết quả đấu giá.

Các phiên đấu giá blockspace diễn ra ngoài chuỗi thông qua Jito Block Engine, cho phép searcher và ứng dụng gửi các nhóm transaction được thực thi nguyên tử, gọi là bundle. Các bundle này thường chứa transaction nhạy cảm về thời gian như giao dịch chênh lệch giá hoặc thanh lý. Jito thu phí 5% trên mọi khoản tip, với mức tip tối thiểu là 10.000 lamport. Tiền tip hoạt động hoàn toàn ngoài giao thức, tách biệt với phí ưu tiên và phí cơ bản trong giao thức. Trước đây, Jito vận hành một dịch vụ mem-pool ngoài giao thức chính thức, nhưng dịch vụ này hiện đã ngừng hỗ trợ.