Chất lượng dịch vụ theo trọng số stake: Mọi điều bạn cần biết

Giới thiệu

Solana đang dẫn đầu công nghệ blockchain với vai trò là một mạng có thông lượng cao và độ trễ thấp, liên tục mở rộng giới hạn của những gì một mạng phi tập trung có thể đạt được. Tuy nhiên, điều này đặt ra nhiều thách thức đáng kể. Một thời điểm mang tính bước ngoặt trong quá trình phát triển của Solana là sự cố ngừng hoạt động ngày 30 tháng 4 năm 2022, cho thấy cần có các cơ chế mạnh mẽ hơn để xử lý khối lượng giao dịch lớn và duy trì hiệu suất mạng khi tải cao.

Chất lượng dịch vụ theo trọng số stake (SWQoS) được tạo ra để ứng phó với sự kiện này. Cơ chế này ưu tiên lưu lượng mạng dựa trên lượng stake mà các validator nắm giữ, bảo đảm validator có nhiều stake hơn có thể gửi giao dịch với mức ưu tiên cao hơn. SWQoS được thiết kế để ngăn các validator có ít stake gây quá tải mạng, qua đó tăng cường khả năng phục hồi và hiệu quả của Solana.

Bài viết này tìm hiểu SWQoS, mô hình xử lý giao dịch của Solana và cách SWQoS tác động đến mô hình đó. Bài viết cũng trình bày về các kết nối có stake, cách thiết lập chúng và sự khác biệt giữa SWQoS với phí ưu tiên. Ngoài ra, bài viết thảo luận về những tác động trong tương lai, cụ thể là tầm quan trọng ngày càng tăng của validator và token staking thanh khoản (LST), các rào cản gia nhập và những giả định về lòng tin vốn có trong hệ thống này.

Bài viết này giả định bạn đã hiểu mô hình lập trình của Solana và QUIC. Nếu chưa quen với các chủ đề đó, bạn nên đọc các bài viết sau trước khi đi sâu vào bài này:

• Mô hình lập trình Solana: Giới thiệu về phát triển trên Solana
• Cách giảm thiểu spam thật QUICk: Mọi điều bạn cần biết về Solana và QUIC

Dù vậy, bài viết vẫn cung cấp ngữ cảnh khi cần thiết.

Chất lượng dịch vụ theo trọng số stake là gì?

Chất lượng dịch vụ theo trọng số stake (SWQoS) là cơ chế ưu tiên lưu lượng mạng dựa trên lượng stake mà các validator nắm giữ. Cơ chế này bảo đảm validator có nhiều stake hơn có thể gửi giao dịch hiệu quả hơn, qua đó nâng cao chất lượng dịch vụ của họ.

Vì Solana là mạng Proof of Stake, việc mở rộng cơ chế trọng số stake sang hiệu suất giao dịch là điều tự nhiên. Nói đơn giản, Solana sử dụng stake (tức khoản tiền được khóa với validator để bảo mật mạng) làm tín hiệu về mức độ đáng tin cậy của validator. Validator càng nắm giữ nhiều stake, lợi ích gắn liền của họ đối với tính bảo mật và độ tin cậy của mạng càng lớn. Ngoài ra, chất lượng dịch vụ là một khái niệm mạng trong đó một số gói tin được ưu tiên để có hiệu suất đáng tin cậy hơn trên mạng. Vì vậy, Solana mang lại hiệu suất ổn định hơn cho các validator có stake khi gửi giao dịch bằng cách định tuyến chúng qua các kết nối ưu tiên.

Mục đích chính của SWQoS là ngăn validator có ít stake làm mạng quá tải bằng các giao dịch có thể lấn át giao dịch được gửi từ validator chất lượng cao hơn hoặc có nhiều stake hơn. Ví dụ: nếu một validator nắm giữ 5% tổng stake, họ có thể gửi 5% tổng số gói tin đến leader. SWQoS có thể được xem là một cơ chế chống Sybil, khiến tác nhân độc hại khó làm ngập mạng bằng các giao dịch “chất lượng thấp” hơn.

Hãy tưởng tượng bạn đang ở một sự kiện nổi tiếng như buổi hòa nhạc hoặc công viên giải trí có số lượng vé giới hạn. Có các hàng mua vé thông thường mà bất kỳ ai cũng có thể xếp hàng, nhưng chúng có thể rất dài và di chuyển chậm. Đồng thời, cũng có các hàng VIP dành cho khách hàng trả nhiều tiền hơn. Những hàng VIP này ngắn và nhanh hơn nhiều vì quyền tiếp cận chỉ dành cho người đáp ứng một số tiêu chí nhất định, chẳng hạn có tư cách thành viên cụ thể, và một số lượng người nhất định được bảo đảm vào cửa tại mỗi thời điểm. Trong bối cảnh Solana, SWQoS giống như các hàng VIP này, nơi quyền tiếp cận được xác định theo lượng stake mà validator nắm giữ. Bạn càng có nhiều stake thì càng nhận được nhiều quyền tiếp cận VIP (tức các kết nối ưu tiên), bảo đảm quá trình xử lý vé (giao dịch) nhanh và đáng tin cậy hơn.

Vậy cơ chế này hoạt động như thế nào trong thực tế? Trước tiên, cần hiểu cách Solana xử lý giao dịch.

Cách Solana xử lý giao dịch

Bộ phận xử lý giao dịch (TPU) của Solana xử lý và thực thi giao dịch hiệu quả. Quá trình xử lý diễn ra qua nhiều giai đoạn riêng biệt để bảo đảm giao dịch được xác thực, thực thi và truyền đi trên toàn mạng. Đó là Giai đoạn Fetch, Giai đoạn SigVerify, Giai đoạn Banking, Dịch vụ Proof of History (PoH) và Giai đoạn Broadcast.

Giai đoạn Fetch

Giai đoạn Fetch nhận các giao dịch đến từ client qua mạng. Giai đoạn này gom nhóm dữ liệu đầu vào từ một socket UDP và phân loại vào ba socket chính:

• tpu: Dành cho giao dịch thông thường như chuyển token, mint NFT và tương tác với chương trình
• tpu_vote: Dành cho giao dịch bỏ phiếu
• tpu_forwards: Chuyển tiếp các gói tin chưa xử lý đến leader tiếp theo nếu leader hiện tại không thể xử lý mọi giao dịch.

Các socket này được tạo trong Gossip, lưu trong struct ContactInfo và được gắn thẻ theo socket tương ứng.

Giai đoạn Fetch sử dụng một cơ chế để hợp nhất các gói tin nhận cùng lúc, giảm số thao tác xử lý từng gói tin riêng lẻ đồng thời tăng thông lượng. Khi nhận được các gói tin chuyển tiếp, giai đoạn này đánh dấu chúng bằng cờ FORWARDED để bảo đảm chúng được nhận diện phù hợp ở các giai đoạn sau. Nếu node không phải leader hiện tại, các gói tin chuyển tiếp này sẽ bị loại bỏ để tránh xử lý không cần thiết. Tuy nhiên, nếu node là leader, các gói tin này sẽ được chấp nhận và xử lý tương ứng.

Giai đoạn Fetch tạo các kênh không giới hạn (ví dụ: packet_sender, packet_receiver) để chuyển giao dịch sang giai đoạn tiếp theo là SigVerify. Các kênh này tách rời các giai đoạn của TPU, cho phép chúng hoạt động đồng thời mà không chặn lẫn nhau. Hàm unbounded tạo một kênh có dung lượng không giới hạn để bảo đảm các gói tin không bị loại bỏ do tràn kênh. 

Giao dịch được gom thành các nhóm gồm 128 gói tin trước khi chuyển tiếp đến giai đoạn SigVerify. Việc gom nhóm này giúp xử lý giao dịch hiệu quả hơn và giảm chi phí xử lý từng gói tin riêng lẻ. 

Lưu ý rằng Giai đoạn Fetch hoạt động trên nhiều luồng để xử lý thông lượng cao. Mỗi luồng chịu trách nhiệm cho một tác vụ cụ thể, chẳng hạn nhận gói tin, xử lý lô và chuyển tiếp giao dịch. Một luồng cho mỗi loại socket (tức tpu, tpu_vote, tpu_forwards) được tạo bằng hàm streamer::receiver. Mỗi luồng lắng nghe socket được chỉ định, xử lý các gói tin đến và gửi chúng qua kênh thích hợp.

Bằng cách quản lý hiệu quả dữ liệu đầu vào và phân loại giao dịch, Giai đoạn Fetch đặt nền móng cho tất cả giai đoạn xử lý tiếp theo trong TPU của Solana.

Giai đoạn SigVerify

Giai đoạn SigVerify là giai đoạn thứ hai trong quy trình xử lý giao dịch của Solana. Đây là bước thiết yếu để bảo đảm tính toàn vẹn và xác thực của giao dịch. 

Trong giai đoạn này, TPU nhận các giao dịch đã gom nhóm từ Giai đoạn Fetch qua các kênh không giới hạn. Nhiệm vụ chính là xác minh chữ ký giao dịch bằng cơ chế chữ ký Ed25519. Quá trình xác thực mật mã này xác nhận rằng chủ sở hữu chính xác của các tài khoản liên quan đã ký giao dịch.

Giai đoạn SigVerify được thiết kế để có hiệu suất cao, tận dụng khả năng xử lý song song của CPU và GPU hiện đại để xác minh chữ ký. Theo mặc định, CPU đảm nhiệm toàn bộ quá trình xử lý. Tuy nhiên, nhờ tính chất song song, việc chuyển tải sang GPU tăng tốc đáng kể quá trình khi có sẵn các thư viện hiệu suất.

Quá trình bắt đầu với hàm new, khởi tạo Giai đoạn SigVerify và thiết lập các kênh nhận cần thiết để nhận gói tin từ Giai đoạn Fetch. Hàm verifier chịu trách nhiệm nhận các nhóm và xác minh chữ ký. Hàm này xử lý việc loại bỏ trùng lặp, loại bỏ các gói tin dư thừa và xác minh những gói tin còn lại. Hàm sử dụng phương thức xác minh chữ ký ed25519_verify. Trong thời gian khối lượng giao dịch cao, hệ thống thực hiện giảm tải. Đây là lúc Giai đoạn SigVerify loại bỏ các gói tin dư thừa. Giai đoạn này thực hiện bằng cách nhóm gói tin theo địa chỉ IP nguồn và phân bổ số lượng gói tin tối đa cần xử lý cho mỗi địa chỉ.

Các giao dịch có chữ ký không hợp lệ sẽ bị gắn cờ và loại bỏ. Quá trình này bảo đảm chỉ giao dịch hợp lệ được chuyển tiếp, ngăn giao dịch gian lận hoặc không chính xác đi đến giai đoạn tiếp theo.

Sau khi xác minh chữ ký, các giao dịch hợp lệ được chuyển sang giai đoạn tiếp theo (tức Giai đoạn Banking) qua một tập hợp kênh không giới hạn khác. Điều này bảo đảm các giai đoạn vẫn tách rời và có thể hoạt động đồng thời. Lưu ý rằng giai đoạn này hoạt động trên nhiều luồng, trong đó mỗi luồng xử lý một tập hợp con của giao dịch, xác minh chữ ký, loại bỏ trùng lặp và giảm tải.

Giai đoạn Banking

Giai đoạn Banking là giai đoạn thứ ba trong quy trình xử lý giao dịch của Solana. Giai đoạn này rất quan trọng vì đây là nơi giao dịch được thực thi và áp dụng vào trạng thái hiện tại của sổ cái. Giai đoạn Banking tận dụng môi trường thực thi Sealevel độc đáo của Solana để cho phép xử lý giao dịch song song với thông lượng cao.

Giai đoạn Banking có sáu luồng—hai luồng chuyên xử lý giao dịch bỏ phiếu từ TPU hoặc Gossip và bốn luồng dành cho giao dịch không bỏ phiếu. Mỗi luồng hoạt động độc lập, nhận các gói tin từ một kênh dùng chung (lưu ý điều này sẽ thay đổi sau phiên bản 1.18), nơi SigVerify gửi gói tin theo lô. Mỗi luồng lấy giao dịch từ kênh dùng chung này và lưu chúng trong bộ đệm cục bộ. Bộ đệm cục bộ hoạt động như một hàng đợi ưu tiên, tự động cập nhật để phản ánh thay đổi theo thời gian thực về trạng thái giao dịch và nhu cầu mạng. 

Cách xử lý các giao dịch này phụ thuộc vào việc validator có nằm trong lịch trình leader hay không. Nếu validator chưa sắp trở thành leader, nó chuyển tiếp các gói tin đến leader sắp tới rồi loại bỏ chúng. Khi validator gần đến lượt hơn (cách khoảng ~20 slot), nó tiếp tục chuyển tiếp gói tin nhưng vẫn giữ lại phòng trường hợp các leader sắp tới không xử lý được. Khi validator chỉ còn cách hai slot trước khi trở thành leader, nó giữ các gói tin để bảo đảm chúng được xử lý khi nó trở thành leader.

Mỗi luồng xử lý giao dịch trong quá trình tạo block bằng cách lấy 128 giao dịch đầu tiên từ hàng đợi cục bộ. Quy trình này gồm các bước như khóa, kiểm tra, tải, thực thi, ghi, commit và mở khóa. 

Giai đoạn Banking sử dụng phương pháp đa iterator để gom nhóm giao dịch. Phương pháp này cho phép duyệt đồng thời một tập dữ liệu, nhóm giao dịch thành các lô không xung đột. Trước tiên, giao dịch được tuần tự hóa thành một vector dựa trên mức ưu tiên. Sau đó, đa iterator đặt các iterator tại những điểm mà giao dịch không xung đột, tạo thành các lô gồm 128 giao dịch. Các giao dịch xung đột bị bỏ qua và được đưa vào các lô tiếp theo sau khi xung đột được giải quyết. Sau khi tạo lô, các giao dịch được thực thi. Giao dịch thành công được ghi vào Dịch vụ Proof of History và phát đến mạng qua Turbine.

Dịch vụ Proof of History (PoH)

Dịch vụ Proof of History (PoH) là một thành phần nền tảng trong quy trình xử lý giao dịch của Solana. Dịch vụ này cung cấp cách có thể xác minh để theo dõi thời gian và thứ tự sự kiện trong mạng, bảo đảm việc sắp xếp giao dịch hiệu quả và an toàn. Nó tạo ra một chuỗi mật mã đóng vai trò dấu thời gian cho giao dịch thông qua chuỗi hash. Chuỗi hash liên tục này tạo ra một bản ghi lịch sử chứng minh thời gian đã trôi qua giữa các sự kiện.

Dịch vụ PoH bảo đảm mọi thành viên mạng có thể thống nhất về thứ tự giao dịch mà không cần bộ phận giữ thời gian trung tâm. Dịch vụ này cũng giúp đồng bộ các validator trên toàn mạng. Nó hỗ trợ quy trình bầu chọn leader của Solana bằng cách cung cấp dấu thời gian đáng tin cậy để xác định thời điểm validator nên trở thành leader và tạo block tiếp theo.

Dịch vụ PoH bắt đầu bằng cách khởi tạo một giá trị seed để tạo ra một chuỗi hash. Khi nhận được giao dịch, chúng được gắn thẻ bằng hash hiện tại trong chuỗi PoH, cung cấp cho mỗi giao dịch một dấu thời gian duy nhất. Sau đó, các validator xác minh chuỗi hash để xác nhận thứ tự và thời điểm của giao dịch.

Để tìm hiểu thêm về Proof of History, hãy đọc bài viết Giải thích Proof of History, Proof of Stake và Proof of Work. Nếu mật mã học nghe như một ngôn ngữ xa lạ, chúng tôi cũng khuyên bạn đọc bài viết Nhập môn công cụ mật mã — Giải thích hàm hash và cây Merkle.

Giai đoạn Broadcast

Giai đoạn Broadcast là bước cuối cùng trong quy trình xử lý giao dịch của Solana. Giai đoạn này chịu trách nhiệm phân phối các giao dịch đã được xác thực và xác nhận đến phần còn lại của mạng.

Sau khi giao dịch được xử lý và commit trong Giai đoạn Banking, chúng được tạo thành các entry. Sau đó, các entry này được đóng gói vào cấu trúc dữ liệu gọi là shred. Giai đoạn Broadcast tuần tự hóa các shred này, ký chúng và tạo mã xóa để tăng cường tính toàn vẹn và khả năng khôi phục dữ liệu. Shred được gửi đến các peer thông qua quy trình phổ biến có cấu trúc dạng cây gọi là Turbine. Đây là quy trình phân phối hiệu quả và có tính dự phòng, còn mã xóa cho phép validator tái tạo dữ liệu bị thiếu hoặc hỏng.

Để xem phân tích toàn diện hơn về Turbine, hãy đọc bài viết Turbine: Truyền block trên Solana.

Vòng đời của giao dịch với SWQoS

Không giống các blockchain khác, Solana không có mempool để giao dịch chờ trước khi được xử lý. Thay vào đó, giao dịch được định tuyến trực tiếp đến leader hiện tại và được TPU của leader xử lý. Người dùng tạo giao dịch trực tiếp hoặc gián tiếp bằng ví hay ứng dụng rồi gửi đến các node RPC qua JSON RPC API. Các node này đóng vai trò trung gian giữa người dùng và validator của Solana. Điều quan trọng là chúng không nên có stake trong mạng. Nghĩa là các node RPC không có stake, không bỏ phiếu và do đó không tham gia đồng thuận.

Các kết nối đến leader hiện được thiết lập qua QUIC. QUIC đã được thêm vào các cổng tiếp nhận giao dịch người dùng để thay thế UDP cho TPU của Solana. Vì QUIC yêu cầu bắt tay, có thể đặt giới hạn cho lưu lượng của một tác nhân để mạng tập trung xử lý giao dịch thực đồng thời lọc bỏ spam. Tất nhiên, đây là mục đích của việc triển khai QUIC, và bài viết này sẽ không tranh luận về hiệu quả hiện tại của nó. Điều quan trọng cần lưu ý là các kết nối đến leader được thiết lập qua QUIC.

Có hai loại kết nối:

• 500 kết nối mở mà bất kỳ node RPC nào cũng có thể truy cập
• 2.000 kết nối theo trọng số stake chỉ dành cho các validator có stake. Validator nhận được tỷ lệ kết nối tương ứng dựa trên stake của mình

Để chuyển tiếp giao dịch hiệu quả, RPC phải được kết nối peer với một validator có stake. Vì RPC không có stake trong mạng, validator cần mở rộng stake của mình theo cách ảo. Validator có thể dùng cờ --staked-nodes-overrides để phân bổ một phần kết nối có stake của mình cho các node RPC cụ thể. 

Validator phải chỉ định đường dẫn tệp YAML bằng --staked-nodes-overrides flag để cấu hình các kết nối theo trọng số stake. Tệp YAML chứa các ánh xạ theo dạng:

staked_map_id:
	<pubkey_of_RPC>: 80000000000000000

Mỗi khóa công khai của một danh tính RPC nhất định cần có một giá trị bằng lamport. Giá trị này xác định trọng số stake mà bạn muốn cấp cho danh tính RPC. Ví dụ: nếu chỉ định một triệu SOL, phần bạn phân bổ cho họ là một triệu SOL chia cho tổng stake đang hoạt động. Về cơ bản, bạn cấp cho node RPC các kết nối có stake như thể đó là một validator có lượng stake tương ứng trong mạng. Bạn đang nói rằng: “Theo góc nhìn cục bộ của tôi, hãy coi danh tính RPC này như thể họ có x stake khi giao tiếp với validator của tôi.” Lưu ý rằng thiết lập này không yêu cầu khởi động lại validator—có thể sửa đổi tệp và tải lại ngay trong khi hệ thống đang chạy.

Ngoài ra, Jito relayer hỗ trợ cờ ghi đè node có stake. Nên chạy relayer trên cùng máy với node có stake để tối ưu hóa hiệu suất.

Để sử dụng các kết nối có stake này, nhà vận hành RPC phải dùng cờ --rpc-send-transaction-tpu-peer, yêu cầu IP và cổng TPU của validator có stake. Cổng TPU thường bắt đầu từ phạm vi cổng động cộng thêm ba, như tìm thấy trong Gossip. Trong trường hợp Jito, lưu lượng sẽ đi đến relayer do nhà vận hành chạy vì không thể sử dụng các Jito relayer công khai. Nhà vận hành RPC nên kiểm tra log để tìm các mục như solana_quic_client và warm nhằm xác minh kết nối. Lưu ý rằng thiết lập này yêu cầu node RPC chạy client Agave phiên bản v1.17.28 trở lên để hỗ trợ cờ cần thiết.

Nhìn chung, vòng đời của giao dịch với SWQoS phần lớn vẫn giống giao dịch thông thường. Người dùng tạo và gửi giao dịch qua các node RPC, sau đó các node này gửi chúng đến leader. Tuy nhiên, giao dịch được gửi qua kết nối có stake khi node RPC được kết nối peer với validator có stake và sử dụng cờ --rpc-send-transaction-tpu-peer. Tóm lại:

• Tạo giao dịch: Người dùng tạo giao dịch bằng ví, ứng dụng hoặc thông qua lập trình 
• Gửi đến node RPC: Giao dịch được gửi đến node RPC qua JSON RPC API
• Kết nối QUIC: Node RPC thiết lập kết nối QUIC đến leader, tận dụng kết nối mở hoặc kết nối theo trọng số stake tùy theo cấu hình
• QoS theo trọng số stake: Nếu node RPC đã kết nối peer với validator có stake, nó sử dụng các kết nối có stake của validator, giúp cải thiện hiệu suất giao dịch
• Chuyển tiếp đến leader: Giao dịch được gửi đến leader qua các kết nối có stake này, với khả năng bị trì hoãn hoặc loại bỏ thấp hơn
• Xử lý giao dịch: Giao dịch đi qua TPU như đã đề cập và được leader xử lý

SWQoS cải thiện vòng đời giao dịch bằng cách bảo đảm validator có stake và node RPC kết nối peer với nó có khả năng tiếp cận leader tốt hơn, giảm nguy cơ chậm trễ do tắc nghẽn mạng. Cơ chế này phối hợp với phí ưu tiên để cải thiện hiệu suất giao dịch.

SWQoS và phí ưu tiên: Sự khác biệt rõ ràng

Trong tình huống mạng tắc nghẽn, SWQoS bảo đảm giao dịch của các validator có nhiều stake ít có khả năng bị trì hoãn hoặc loại bỏ hơn. Hệ thống này có thể được, và thường được, ví như đường thu phí, nơi validator có nhiều stake hơn được tiếp cận tuyến đường ít tắc nghẽn hơn, tương tự như có thêm làn trên đường cao tốc. Hãy xem hình trên làm ví dụ. Tại Colorado, tài xế có thể ngồi chờ trong dòng xe hoặc trả thêm vài đô la để đi trong làn thu phí. Express Lanes là mạng lưới làn đường cao cấp của Colorado, nơi giá được điều chỉnh liên tục ở mức đủ cao để duy trì lưu lượng thông suốt. Vì vậy, có thể ví các kết nối có stake của Solana với Express Lanes của Colorado, bởi cả hai đều là tuyến đường ưu tiên nhằm giảm tắc nghẽn cho người dùng cao cấp.

Tuy nhiên, cần phân biệt SWQoS với phí ưu tiên, vì phép so sánh phổ biến với đường thu phí có thể làm mờ ranh giới giữa hai khái niệm này:

• Phí ưu tiên phát huy tác dụng trong Giai đoạn Banking, khi leader ưu tiên giao dịch dựa trên mức phí đã trả. Ý tưởng là giao dịch trả phí cao hơn sẽ được xử lý sớm hơn, bảo đảm thực thi nhanh hơn cho người dùng sẵn sàng trả nhiều hơn.
• SWQoS cải thiện khả năng truy cập kết nối và không ảnh hưởng đến mức ưu tiên của giao dịch trong hàng đợi giao dịch của leader. SWQoS bảo đảm validator có stake tiếp cận mạng tốt hơn, giảm khả năng giao dịch bị trì hoãn hoặc loại bỏ do tắc nghẽn mạng

Trong khi phí ưu tiên ảnh hưởng đến cách giao dịch được sắp xếp và xử lý sau khi đã vào hàng đợi của leader, SWQoS bảo đảm giao dịch từ validator có stake có tuyến đường ưu tiên để đến leader. Cả hai cơ chế đều nhằm nâng cao hiệu suất mạng nhưng hoạt động ở các giai đoạn khác nhau trong vòng đời giao dịch.

Cuộc chiến SWQoS

Trong tương lai, SWQoS sẽ trở thành một khía cạnh nền tảng của cơ sở hạ tầng mạng Solana. Nó sẽ tác động đáng kể đến hệ sinh thái bằng cách tối ưu hóa quá trình xử lý giao dịch và ưu tiên kết nối từ validator có stake đến leader. Tôi không thể nhấn mạnh đủ tầm quan trọng của điều này.

Có thể lập luận rằng lợi thế của việc sử dụng validator có nhiều stake bắt đầu giảm khi mạng không tắc nghẽn và giao dịch không nhạy cảm về thời gian. Lý do là mạng có đủ năng lực để xử lý giao dịch nhanh chóng, bất kể trọng số stake đứng sau chúng. Tuy nhiên, khi nhu cầu sử dụng Solana tăng lên cùng triển vọng được áp dụng rộng rãi, mạng có thể không phải lúc nào cũng đủ năng lực xử lý mọi giao dịch mà không bị trì hoãn hoặc thỉnh thoảng bị loại bỏ. Điều này không có nghĩa Solana không thể mở rộng, bởi đây có thể là một trong những blockchain có khả năng mở rộng tốt nhất, nếu không muốn nói là tốt nhất. Điểm mấu chốt là khi nhu cầu tăng, SWQoS sẽ tiếp tục đóng vai trò quan trọng trong việc mang lại UX xuất sắc.

Theo đó, vai trò của validator càng trở nên quan trọng, dẫn đến nhiều cạnh tranh và đổi mới hơn nhằm cung cấp dịch vụ tốt nhất có thể. Vậy chẳng phải mọi người đều sẽ muốn tự vận hành validator của riêng mình sao?   

Validator và token staking thanh khoản (LST)

Xu hướng đã rõ: mọi giao thức Solana nghiêm túc đều sẽ vận hành một validator. Lý do là họ cần làm vậy để hỗ trợ ứng dụng của mình. Nếu muốn vận hành validator riêng, hãy xem hướng dẫn bắt đầu trên blog Helius.

Chúng ta đang đứng trước một đợt bùng nổ LST khổng lồ kiểu kỷ Cambri trên Solana, được SWQoS thúc đẩy mạnh hơn. Chỉ trong tháng này, tổng stake (tức Native + LST) đã tăng khoảng 3,2 triệu. Riêng giá trị thị trường của LST hiện nằm trong khoảng 6 đến 9 tỷ USD trong tháng này. Các giao thức như Sanctum đang dần trở thành những bên tham gia lớn vì nền tảng của họ cho phép validator và ứng dụng tạo LST riêng. Ngoài ra, Picasso Network cho phép restaking trên Solana, đóng vai trò là trung tâm giúp LST có nhiều tiện ích và lợi suất hơn. Vì vậy, khả năng tạo LST với tiện ích bổ sung đã hiện hữu và đang phát triển mạnh mẽ.

Tuy nhiên, cần xem xét một số rào cản gia nhập tiềm ẩn.

Rào cản gia nhập

Dù có nhiều lợi ích tiềm năng, SWQoS tạo ra một số rào cản gia nhập. Cụ thể, yêu cầu về mức stake tối thiểu đã được đưa vào phiên bản v1.17.31 của client Agave để coi các validator có ít stake như những peer không có stake. Vấn đề là các node có lượng stake thấp có thể lạm dụng kết nối có stake bằng cách nhận băng thông không tương xứng. Hiện nay, các node có tỷ lệ stake thấp hơn công thức sau sẽ được coi là không có stake:

stake / total_stake < 1 / (max packet per 100ms)

Điều này có nghĩa các client có ít hơn khoảng 15.000 SOL được stake hiện được phân loại là validator không có stake. Yêu cầu này có thể làm tăng thêm gánh nặng tài chính và kỹ thuật vốn đã cao khi vận hành validator Solana, qua đó có thể loại các bên nhỏ hơn và validator độc lập khỏi việc tham gia mạng. Yêu cầu này tương đương khoảng 3 triệu USD, thoạt nhìn là một con số lớn. 

Tuy nhiên, như Austin Federa chỉ ra, ngưỡng này chỉ bằng 1/25.000 tổng stake, có thể xem là thấp. Hơn nữa, nếu phần lớn validator cạnh tranh để thu hút stake liên tục cải thiện hiệu suất nhằm cung cấp dịch vụ tốt nhất có thể và tối đa hóa lợi nhuận của mình, toàn bộ mạng sẽ được hưởng lợi. Đây chính là điều Toly mô tả là mục tiêu tổng thể của SWQoS.

Tại Helius, chúng tôi đang hạ thấp rào cản gia nhập cho mọi gói trả phí gửi giao dịch với mức phí do Helius đề xuất. Nghĩa là mọi người dùng gửi giao dịch qua gói dùng chung trả phí giờ đây sẽ được định tuyến qua các kết nối có stake của chúng tôi nếu họ gửi với mức phí bằng hoặc cao hơn giá trị khuyến nghị do Priority Fee API cung cấp. Chúng tôi cũng đã hợp lý hóa quy trình này bằng tính năng Smart Transactions mới, được thêm vào các SDK Node.js và Rust. Ở cấp độ cơ bản nhất, bất kể sử dụng SDK nào, người dùng chỉ cần cung cấp keypair và các lệnh muốn thực thi; chúng tôi sẽ xử lý phần còn lại. Giờ đây, người dùng có thể truy cập kết nối có stake dùng chung chỉ với 50 USD mỗi tháng trong gói Developer. Lưu ý rằng chúng tôi cũng cung cấp kết nối có stake chuyên dụng, bảo đảm băng thông kết nối có stake và được khuyến nghị cho doanh nghiệp, chuyên gia định lượng và công ty giao dịch. Nếu quan tâm đến kết nối có stake chuyên dụng, vui lòng liên hệ đội ngũ bán hàng của chúng tôi.

Điều quan trọng cần lưu ý là stake có khả năng bắt đầu tập trung vào các validator do giao thức lớn và nhà cung cấp RPC vận hành, những bên có thể áp dụng mức hoa hồng 0%. Hãy lấy Helius làm ví dụ: chúng tôi có thể tạo doanh thu từ nguồn khác để bù đắp chi phí vận hành validator. Chúng tôi làm vậy để cải thiện tính phi tập trung của mạng bằng cách để một đội ngũ gắn bó với Solana vận hành validator hàng đầu, đồng thời có quyền tiếp cận tốt hơn với các kết nối có stake nhằm cải thiện trải nghiệm người dùng.

Các giả định về lòng tin

Nếu stake có khả năng tập trung vào validator do các giao thức lớn và nhà cung cấp RPC vận hành, bạn cần stake với một validator đặt lợi ích tốt nhất của Solana lên hàng đầu. SWQoS đưa ra một số giả định về lòng tin.

Một trong những giả định chính là validator và node RPC cần có mức độ tin cậy cao với nhau. Như đã mô tả xuyên suốt bài viết, SWQoS cho phép leader xác định và ưu tiên giao dịch từ validator có stake. Vì các node RPC không có stake, không bỏ phiếu và không tham gia đồng thuận, chúng không thể trực tiếp hưởng lợi từ giao dịch ưu tiên theo cách giống validator có stake. Do đó, validator và node RPC phải thiết lập mối quan hệ đáng tin cậy để tận dụng lợi ích của SWQoS.

Mối quan hệ tin cậy này rất quan trọng vì việc bật SWQoS liên quan đến chia sẻ cấu hình mạng nhạy cảm và cho phép node RPC tác động đến mức ưu tiên giao dịch. Validator phải bảo đảm các node RPC mà họ kết nối peer sẽ hành động vì lợi ích tốt nhất của mạng và không lạm dụng stake được mở rộng cho mục đích xấu. Validator và node RPC nên có thỏa thuận từ trước và hiểu biết chung về cách sử dụng các kết nối có stake. Lý tưởng nhất, thiết lập này nên diễn ra giữa các thực thể có mức độ tin cậy cao, chẳng hạn đối tác lâu năm hoặc các bên trong cùng một tổ chức.

Hiện tại, những mối quan hệ này thường không được công khai. Và trong tương lai, tôi không hình dung ra một kịch bản mà các nhà vận hành RPC không đàm phán với validator để được ghi đè stake. Cần có tính minh bạch cao hơn để người dùng thông thường biết họ đang ủng hộ RPC và validator nào. Nhu cầu này sẽ chỉ tăng theo thời gian.

Kết luận

SWQoS sẵn sàng tạo ra cuộc cách mạng cho cơ sở hạ tầng mạng Solana. Dù mang lại nhiều lợi ích, bao gồm nâng cao hiệu suất giao dịch và tăng khả năng chống Sybil, cơ chế này cũng đặt ra những thách thức và giả định mới về lòng tin cần được xử lý cẩn thận. Mặc dù SWQoS được thiết kế để ưu tiên giao dịch do validator có stake gửi, hiện không có gì thực thi mức ưu tiên này. Các validator nghiêm túc thường ghi đè cài đặt mặc định và thậm chí có thể chặn một số tác nhân nhất định. Điều này nhấn mạnh nhu cầu về lòng tin và tính minh bạch trong mối quan hệ giữa validator và node RPC nhằm bảo đảm SWQoS được sử dụng công bằng và hiệu quả. Dù vậy, việc triển khai cơ chế này đánh dấu một bước tiến đáng kể trong quá trình phát triển của Solana thành một mạng hiệu quả và có khả năng phục hồi.

Trong bài viết này, chúng ta đã tìm hiểu SWQoS và cách nó tác động đến quá trình xử lý giao dịch. Chúng ta cũng đề cập đến những điểm khác biệt quan trọng, chẳng hạn sự khác nhau giữa SWQoS và phí ưu tiên. Ngoài ra, chúng ta đã thảo luận về sự trỗi dậy của validator và LST, các rào cản gia nhập tiềm ẩn cũng như những giả định về lòng tin liên quan, qua đó cung cấp một điểm khởi đầu quan trọng cho các cuộc thảo luận trong tương lai. Hiểu tất cả các yếu tố này là điều thiết yếu để tận dụng SWQoS hiệu quả và cải thiện Solana nói chung.

Nếu đã đọc đến đây, cảm ơn bạn, anon! Hãy nhập địa chỉ email bên dưới để không bao giờ bỏ lỡ thông tin mới nhất trên Solana. Bạn đã sẵn sàng tìm hiểu sâu hơn chưa? Hãy 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 bổ sung

• Báo cáo và biện pháp khắc phục sự cố ngừng hoạt động Solana Mainnet Beta ngày 30-04-2022
• Hướng dẫn về chất lượng dịch vụ theo trọng số stake trên Solana
• Cách thiết lập validator Solana
• Gửi Smart Transactions
• Đào tạo validator Solana — QoS theo trọng số stake