Staking thanh khoản và LST trên Solana

Giới thiệu

Bài viết này khám phá cấu trúc chính của Token Staking Thanh khoản (LST) trên Solana. LST cho phép người dùng khai mở tính thanh khoản của tài sản đã stake. Thông thường, khi token được stake trên blockchain Proof of Stake (PoS), chúng sẽ bị khóa trong một khoảng thời gian nhất định, qua đó bảo vệ mạng lưới để đổi lấy phần thưởng. Phần thưởng staking có thể bao gồm phí, doanh thu MEV khác và lượng phát hành mới (một hình thức chuyển giá trị từ người không stake sang người stake).

Dù đóng vai trò thiết yếu đối với an ninh kinh tế, cơ chế staking này khiến tài sản đã stake mất tính thanh khoản, hạn chế khả năng sử dụng chúng trong các hoạt động tài chính khác của hệ sinh thái. Staking làm giảm lượng cung lưu hành bằng cách khóa token trong giao thức. Điều này khuyến khích việc tạo và sử dụng LST để nâng cao hiệu quả sử dụng vốn, cho phép người nắm giữ token nhận phần thưởng staking mà vẫn duy trì tính thanh khoản.

Bài viết cũng tìm hiểu điểm khác biệt giữa các cấu trúc này với Ethereum, cùng những vấn đề khác cần cân nhắc khi xây dựng LST trên Solana.

Các cấu trúc LST trên Solana

Solana sử dụng cơ chế Delegated Proof-of-Stake (DPoS) tích hợp trong giao thức. Người dùng gửi SOL vào các pool staking do từng validator vận hành. Sau đó, đơn vị vận hành staking có thể phát hành LST riêng, được bảo chứng bằng lượng SOL đã ủy quyền. Điều này giúp người dùng có thanh khoản tức thì cho phần stake của mình.

LST của pool staking

LST sử dụng các pool staking dựa trên chương trình pool staking SPL. Khi đóng góp SOL vào các pool phi lưu ký này, phần stake sẽ được phân bổ cho một nhóm validator đủ điều kiện. Đổi lại, người tham gia nhận được một LST, chẳng hạn như JitoSOL của Jito.

Mỗi pool staking áp dụng một chiến lược ủy quyền stake riêng. Ví dụ, Jito ưu tiên các validator chạy client của mình. Cách này tối đa hóa lợi nhuận MEV và tái cân bằng giữa 100 validator có hiệu suất cao nhất, theo tiêu chí của họ.

Có thể biểu diễn quá trình chuyển giao stake giữa các bên liên quan trong một pool staking dưới dạng bảng cân đối kế toán (đọc từ trái sang phải, từ trên xuống dưới):

1. Một người stake/người ủy quyền gửi trực tiếp 10 SOL vào pool staking và nhận số dư LST “spSOL” (“stake pool SOL”), đại diện cho quyền yêu cầu quy đổi 10 SOL đã gửi.
2. Pool staking hiện có 10 SOL. Trong trường hợp này, pool ủy quyền 5 SOL cho “Stake Pool Validator 1” và 5 SOL còn lại cho “Stake Pool Validator 2”. Pool staking nhận tổng cộng 10 vSOL (“validator SOL”) – 5 vSOL từ mỗi validator. Dù không được mã hóa thành token thực tế, số dư này đại diện cho quyền yêu cầu quy đổi SOL đã gửi.
3. “Stake Pool Validator 1” và “Stake Pool Validator 2” mỗi bên stake 5 SOL để thực hiện nhiệm vụ thực thi và đồng thuận. Họ nhận một lượng “sSOL” ảo từ giao thức Solana, đại diện cho quyền yêu cầu quy đổi SOL đã gửi (cũng không được mã hóa thành token, mà được dùng để minh họa cách giao thức theo dõi việc quy đổi).

Lưu ý rằng đây là trường hợp đơn giản nhất, không có phí hoặc slashing. Trên thực tế, Solana hiện không có slashing theo chương trình, nhưng một số LST có thu phí.

LST của validator

LST của validator giúp các dự án dễ dàng phát hành LST dựa trên một validator duy nhất, tạo cảm giác “cộng đồng riêng” xoay quanh LST do validator cụ thể phát hành.

LST của validator hoạt động rất giống pool staking, ngoại trừ việc chỉ có một validator duy nhất:

1. Một người stake/người ủy quyền gửi trực tiếp 10 SOL vào pool staking và nhận số dư LST “v_lstSOL” (“validator LST SOL”), đại diện cho quyền yêu cầu quy đổi 10 SOL đã gửi.
2. Sau đó, đơn vị quản lý pool staking ủy quyền cho validator duy nhất trong pool, gửi 10 SOL vào validator và nhận một lượng “vSOL” ảo.
3. Validator hiện có 10 SOL. Vì validator là thực thể tham gia thực hiện nhiệm vụ đồng thuận, validator gửi 10 SOL vào Solana. Validator nhận một lượng “sSOL” ảo từ giao thức Solana, đại diện cho quyền yêu cầu quy đổi SOL đã gửi.

Trong cả hai trường hợp, người stake đều ủy quyền SOL cho validator, validator thực hiện nhiệm vụ xác thực và một phần phần thưởng SOL được chuyển cho người stake. LST của validator không thu phí gửi stake, phí rút hoặc phí quản lý.

Về mặt cơ chế, LST của validator gọn nhẹ hơn. Chúng giảm đáng kể tổng số tài khoản stake, qua đó rút ngắn thời gian cần thiết để tính phần thưởng cho các tài khoản này. Ngoài ra, LST của validator có thể triển khai các chương trình khuyến khích hoặc khách hàng thân thiết: gần đây, Laine đã airdrop phần thưởng khối và phí ưu tiên cho người nắm giữ laineSOL, mang lại APY cao cho họ. Tensor có thể cho phép người dùng đặt giá thầu bằng tensorSOL thay vì SOL, tạo lợi suất từ các lệnh đang mở. Nhờ đó, Tensor có thể trao thêm điểm cho người dùng và triển khai hệ thống xổ số không mất vốn, trong đó mỗi khoản thanh toán bằng tensorSOL đều mang lại cơ hội nhận một phần phần thưởng staking đã tích lũy.

Cơ chế token LST

Tương tự Ethereum, cơ chế của token LST có thể là tích lũy phần thưởng hoặc điều chỉnh lại nguồn cung. Mỗi LST lựa chọn thiết kế khác nhau để chuyển phần thưởng cho người stake vì nhiều lý do, bao gồm khả năng tối ưu hiệu quả thuế. Solana hiện không có LST điều chỉnh lại nguồn cung.

Cách sử dụng LST trên Solana

Trên Ethereum, phần lớn ETH đã stake đến từ LST, bao gồm stETH, rETH và cbETH. stETH chiếm ~70% tổng thị trường LST.

Trên Solana, LST chiếm chưa đến 5% tổng lượng stake. Jito và Marinade lần lượt chiếm 35% và 42% thị trường LST.

Sự chênh lệch trong mức độ sử dụng LST này có thể bắt nguồn từ nhiều nguyên nhân:

• Việc sử dụng LST trên Ethereum phụ thuộc phần lớn vào lộ trình phát triển trước đó, trong đó The Merge tác động mạnh đến trạng thái cân bằng hiện tại của LST. Hiệu ứng mạng lưới và mức độ chấp nhận lớn, có tính cộng dồn, tập trung quanh 1-3 token staking thanh khoản đã bứt phá, tạo nên một vòng lặp tự củng cố về “tính tiền tệ”.
• LST chưa có đủ tiện ích on-chain, trong khi người dùng rất nhạy cảm với việc giảm tỷ trọng tài sản thế chấp trong Solana DeFi (khó xảy ra).
• Đối với người nắm giữ lớn (tổ chức và cá nhân), động lực tự vận hành validator (các dịch vụ tính theo trọng số stake) cao hơn. Họ cũng có thể chọn stake mà không nhận stake bên ngoài để tránh trách nhiệm pháp lý tiềm ẩn. Các tài khoản/tập đoàn nắm giữ lượng SOL đã stake lớn (có thể từng bị khóa) thường không muốn tham gia staking LST. Vì vậy, họ tự vận hành validator và nhận phần thưởng staking tương ứng (vì lý do pháp lý, quy định hoặc lý do khác).
• Người dùng Solana chưa thực sự quen thuộc với cấu trúc của LST.

LST và DeFi

Trên các mạng PoS, lãi suất cho vay cao trong DeFi thường cạnh tranh trực tiếp với staking. Điều này có thể làm suy yếu an ninh mạng lưới vì người stake có lý do hợp lý để rút stake nhằm tìm kiếm lợi nhuận cao hơn từ các nền tảng cho vay DeFi. Hiện tượng này thể hiện rõ trên các blockchain như Cosmos, vốn từng mắc kẹt trong một vòng luẩn quẩn khó khăn: hoạt động DeFi bị hạn chế do lợi suất staking cao trên toàn hệ sinh thái (nhưng điều này có thể sớm thay đổi). Mức lợi suất này đặt ra một ngưỡng cạnh tranh cao và thường không bền vững cho Cosmos DeFi khi phải cạnh tranh với lợi nhuận staking. Một thị trường LST thanh khoản và sôi động có thể giảm thiểu vấn đề này bằng cách cho phép người stake đồng thời tham gia staking và cho vay, từ đó giảm động lực tấn công. 

Solana DeFi đã ghi nhận mức tăng đáng kể về khối lượng, hoạt động và sự chú ý sau các đợt airdrop của Jito và Jupiter. Các đợt airdrop này thường là khởi nguồn cho trạng thái chia sẻ phong phú hơn khi hoạt động, mức độ quan tâm và số lượng tài sản tăng lên. Việc khai mở toàn bộ SOL đã stake trên một hệ thống trạng thái chia sẻ như Solana sẽ tạo điều kiện cho nền kinh tế DeFi gốc phong phú hơn.

Dù hệ sinh thái LST trên Solana vẫn ở giai đoạn sơ khai, nhiều khả năng hệ sinh thái này sẽ có danh mục LST dài và đa dạng hơn nhiều (khác với Ethereum), phần lớn nhờ mức độ phổ biến ngày càng tăng của LST validator.

Sanctum và danh mục LST dài trên Solana

LST của validator có thể hoán đổi lẫn nhau (sẽ trình bày thêm ở phần sau). Chúng là lớp bọc quanh cùng các tài khoản stake và đại diện cho quyền yêu cầu đối với lượng SOL đã stake tương ứng.

LST của validator cho phép mỗi validator phân phối LST riêng. Một trong những đội ngũ đầu tiên xây dựng cho tương lai “LST vô hạn” này là Sanctum. Sanctum Reserve cung cấp một pool SOL thanh khoản lớn (> 200.000 SOL), cho phép hủy stake tức thì với bất kỳ LST nào bằng cách chuyển tài khoản stake của người dùng sang Sanctum để nhận lượng SOL tương ứng, sau khi trừ một khoản phí (cho thời gian chờ hủy stake hai ngày). Đội ngũ Sanctum cũng đã xây dựng Sanctum Router, cho phép hoán đổi LST thông qua bộ định tuyến off-chain của Jupiter, cùng Sanctum Infinity sắp ra mắt. Nhờ đó, bất kỳ LST nào cũng có thể được hủy stake tức thì, hoán đổi với nhau và đổi sang bất kỳ token nào khác với mức phí tối thiểu.

Các cấu trúc LST trên Ethereum

Không phải giao thức nào cũng có cơ chế ủy quyền gốc như trên Solana. Dưới đây là những cấu trúc LST phổ biến nhất trên Ethereum:

Đơn vị vận hành node cần cấp quyền (ví dụ: stETH)

stETH do Lido DAO phát hành. Lido DAO quản lý việc phân phối và vận hành tài sản đã stake giữa một nhóm chọn lọc gồm ~30 đơn vị vận hành node cần cấp quyền. Thiết kế này có tính cấp quyền và không yêu cầu tài sản thế chấp. Điều đó có nghĩa là các đơn vị vận hành node được lựa chọn cẩn thận theo tiêu chí nghiêm ngặt nhưng không phải ký quỹ tài sản thế chấp (tạo ra vấn đề người ủy quyền-người đại diện). Lượng stake được ủy quyền cho pool LIDO được phân bổ đồng đều giữa các đơn vị vận hành này. Cách tiếp cận này nhấn mạnh niềm tin vào các đơn vị vận hành đã qua thẩm định để duy trì an ninh mạng lưới mà không cần bảo đảm tài chính bổ sung. Lido hiện chiếm ~31% tổng lượng Ethereum đã stake.

Đơn vị vận hành node không cần cấp quyền (ví dụ: rETH)

RocketPool cung cấp một nhóm đơn vị vận hành node không cần cấp quyền, cho phép bất kỳ ai trở thành validator miễn là đáp ứng yêu cầu về tài sản thế chấp. Mô hình này dân chủ hóa quyền tiếp cận hoạt động vận hành node, với điều kiện người tham gia phải khóa tài sản thế chấp. Cụ thể, để tạo một node validator đầy đủ với 32 ETH, đơn vị vận hành cần cung cấp 8 ETH từ nguồn vốn của mình và thêm lượng token RPL gốc của RocketPool trị giá 2,4 ETH, tổng cộng 10,4 ETH. Sau đó, họ đủ điều kiện nhận 24 ETH từ pool.

Thiết kế này nhằm giảm thiểu tác động của vấn đề người ủy quyền-người đại diện, trong đó bên cung cấp vốn chịu rủi ro và đơn vị vận hành là các thực thể khác nhau.

Đơn vị vận hành node tập trung (ví dụ: cbETH)

Thông qua Coinbase hoặc các tổ chức tập trung khác, người dùng có thể stake ETH trực tiếp trên nền tảng, còn nền tảng chịu trách nhiệm vận hành các node cần thiết. Ngoài ra, người dùng có thể tiếp cận thanh khoản on-chain cho cbETH. Mô hình này ưu tiên tính dễ sử dụng và khả năng tiếp cận, vì người dùng giao phó cho Coinbase xử lý những vấn đề vận hành phức tạp của staking.

Một số nhận định khác

Các chương trình pool staking được kiểm soát bằng multisig. Quyền staker – có thể là một keypair duy nhất – kiểm soát một số khía cạnh của việc ủy quyền stake và chỉ có thể thực hiện một tập hợp hành động hạn chế hơn nhiều. Các dự án như Stakenet hướng đến việc phi tập trung hóa quyền staker bằng cách ủy quyền quyền này cho một chương trình thay vì một keypair duy nhất. Quyền staker có thể tái ủy quyền stake cho các validator hiện có khác và tăng phí (cần ít nhất 1 epoch mới có hiệu lực). Ngoài ra, mức tăng phí của đơn vị quản lý cũng bị giới hạn.

Hiện tại, Solana không có slashing theo chương trình (khác với các blockchain như Ethereum). Điều này đồng nghĩa với việc bên nhận ủy quyền (đơn vị vận hành) có ít hướng khai thác hơn để thực hiện hành vi độc hại bằng lượng stake được ủy quyền. Dù các đơn vị vận hành LST validator tương ứng bị hạn chế nghiêm ngặt và không thể đánh cắp lượng stake được ủy quyền – vì người dùng vẫn sở hữu SOL đã stake – vẫn cần cân nhắc thêm nếu và khi Solana hỗ trợ slashing theo chương trình. Ethereum hiện đang nghiên cứu các giải pháp như staking hai tầng để giảm thiểu một số tác động của vấn đề người ủy quyền-người đại diện liên quan đến slashing.

Kết luận

Trong bài viết này, chúng ta đã tìm hiểu cách triển khai LST hiện tại của Solana vận hành trong thực tế. Bài viết cũng nêu bật sự khác biệt giữa cơ chế ủy quyền gốc và mô hình LST tương ứng của Solana so với Ethereum.

Mức độ sử dụng LST trên Solana và Ethereum cho thấy sự chênh lệch đáng kể, trong đó thị trường LST của Solana vẫn còn tương đối non trẻ. Khi tiện ích của LST mở rộng và người dùng quen thuộc hơn với cấu trúc của chúng, nhiều trạng thái DeFi gốc hơn sẽ xuất hiện trên Solana

Cảm ơn FP Lee (Sanctum) và Jon Charbonneau đã đóng góp ý kiến và rà soát.