Quản trị Solana: Phân tích toàn diện

Những nhận định có thể áp dụng

• Các cuộc bỏ phiếu quản trị trên Solana không mang tính ràng buộc mà chỉ có vai trò tư vấn, đóng vai trò như tín hiệu về quan điểm của cộng đồng. Việc cho phép các validator thể hiện lập trường trước khi triển khai đầy đủ giúp định hướng phát triển và giảm thiểu bất đồng. Quyết định cuối cùng được đưa ra khi các validator chọn phần mềm sẽ chạy. Đề xuất vẫn có thể thay đổi sau khi bỏ phiếu và xét cho cùng, quản trị phản ánh sự đồng thuận chứ không phải sự cưỡng chế.
• Người nắm giữ token SOL tham gia gián tiếp bằng cách ủy quyền SOL đã stake cho các validator có lựa chọn bỏ phiếu phù hợp với giá trị hoặc ưu tiên của họ. Đây là một hệ thống đại diện tỷ lệ, trong đó validator có thể được xem là đại diện được bầu. Người stake trên Solana ủy quyền stake của mình cho validator, còn quyền biểu quyết của mỗi validator dựa trên lượng stake được ủy quyền.
• Hoạt động bỏ phiếu quản trị của Solana được thực hiện bằng token SPL. Validator được phân bổ token theo tỷ lệ stake đang hoạt động và gửi các token này đến những địa chỉ được chỉ định đại diện cho các phương án bỏ phiếu khác nhau. Validator có thể tự do chia phiếu cho nhiều phương án. Sau khi gửi, phiếu bầu là quyết định cuối cùng và không thể thay đổi.
• Mọi bản cập nhật giao thức phá vỡ đồng thuận đều được kích hoạt thông qua feature gate, tức các hard fork không tương thích ngược. Khác với Bitcoin hoặc Ethereum, nơi bất đồng về một hard fork có thể dẫn đến chia tách chuỗi vĩnh viễn, cách tiếp cận của Solana đảm bảo feature gate được kích hoạt trên toàn cluster tại một slot cụ thể. Validator nâng cấp trước, nhờ đó ngăn việc chia tách chuỗi.
• Một số thay đổi kinh tế trong giai đoạn phát triển ban đầu của Solana—đáng chú ý là việc áp dụng phí ưu tiên với tỷ lệ đốt 50%—đã được triển khai mà không có cuộc bỏ phiếu quản trị chính thức vì hệ thống quản trị lúc đó vẫn chưa hoàn thiện.
• Mô hình bỏ phiếu quản trị hiện tại—chỉ validator bỏ phiếu—được thiết lập sau một cuộc bỏ phiếu tư vấn vào tháng 10 năm 2023. Hơn 170 validator đã tham gia, đại diện cho 14,3% tổng lượng stake; hơn 70% lượng stake đó ủng hộ mô hình chỉ validator bỏ phiếu vì đây là điểm khởi đầu thiết thực và hiệu quả nhất.
• Cuộc bỏ phiếu gần đây về SIMD-228 đạt tỷ lệ tham gia kỷ lục 74,3%, trở thành sự kiện quản trị blockchain lớn nhất lịch sử xét theo số người tham gia và vốn hóa thị trường, với 281 triệu SOL (~35 tỷ USD) và hơn 900 validator thực hiện hơn 1.000 lượt bỏ phiếu. Đây là lần đầu tiên các validator của sàn giao dịch lớn như Coinbase, Kraken và Bybit tích cực tham gia, cho thấy mức độ tham gia ngày càng tăng của các tổ chức vào Solana.
• Một mối quan ngại thường trực trong quy trình quản trị của Solana là vai trò hạn chế của người ủy quyền trong việc ra quyết định. Hiện chưa có cơ chế chính thức để người ủy quyền thể hiện ưu tiên hoặc phủ quyết quyết định của validator, dẫn đến những trường hợp phiếu bầu của validator có thể xung đột với mong muốn của người ủy quyền cho họ.
• Vai trò của ngưỡng túc số xác định trong các cuộc bỏ phiếu quản trị Solana cũng làm dấy lên lo ngại. Trên thực tế, ngưỡng túc số có thể tạo ra động cơ sai lệch, khiến người tham gia chủ động không bỏ phiếu để ngăn đề xuất đạt ngưỡng bắt buộc. Điều này đã được ghi nhận trong xu hướng bỏ phiếu cho SIMD-228.
• Solana Foundation Delegation Program ủy quyền 10% tổng SOL đã stake (41,01 triệu) cho 897 validator, qua đó khuếch đại quyền biểu quyết của các validator này. Phân tích cuộc bỏ phiếu SIMD-288 gần đây cho thấy stake từ SFDP chủ yếu được dùng để bỏ phiếu chống lại đề xuất. Nếu lượng stake này bỏ phiếu YES, đề xuất đã được thông qua. Nếu lượng stake do SFDP ủy quyền bỏ phiếu trắng, đề xuất vẫn không được thông qua, nhưng với khoảng cách nhỏ hơn—64,77% so với mức thực tế 61,39%.
• Vẫn còn chưa rõ tiêu chí để một vấn đề phải được đưa ra bỏ phiếu quản trị. Vào tháng 3 năm 2025, cuộc bỏ phiếu dự kiến về SIMD-218 (IVC) đã bị rút lại sau khi xuất hiện đồng thuận rằng đề xuất này không cần phê duyệt quản trị. Tương tự, dù đã được thông qua, SIMD-123 không rõ ràng là một thay đổi kinh tế và có thể không cần một cuộc bỏ phiếu chính thức.

Giới thiệu

Quản trị là một thành phần thiết yếu của quá trình phi tập trung hóa, tác động đến mọi khía cạnh từ nâng cấp giao thức và chính sách kinh tế đến hành vi của validator và tiêu chuẩn cộng đồng. Một hệ thống quản trị vận hành tốt sẽ cải thiện tính minh bạch, công bằng và niềm tin, trong khi quản trị yếu kém có thể dẫn đến tình trạng mơ hồ, trì trệ hoặc tập trung quyền lực.

Hoạt động quản trị của Solana vẫn đang ở giai đoạn phát triển ban đầu. Giống như nhiều mạng blockchain khác, Solana không ra mắt với một khuôn khổ quản trị hoàn thiện hoặc được chính thức hóa đầy đủ. Thay vào đó, khuôn khổ này phát triển dần theo thông lệ cộng đồng, hạn chế kỹ thuật và những bài học kinh nghiệm. Việc hoàn thiện mô hình quản trị Solana là một quá trình liên tục và lặp lại.

Hệ sinh thái Solana bao gồm nhiều nhóm bên liên quan đa dạng và có sự giao thoa: người nắm giữ token, người stake, người dùng, validator, nhà vận hành RPC, nhà phát triển ứng dụng và kỹ sư giao thức cốt lõi. Mỗi nhóm có góc nhìn, động lực và mục tiêu khác nhau. Dù những lợi ích này có thể đồng nhất trong một số lĩnh vực, chúng thường khác biệt, đặc biệt xoay quanh việc phân phối tài nguyên, quyền kiểm soát giao thức và chính sách kinh tế.

Trong các hệ thống phi tập trung, quản trị phụ thuộc vào đồng thuận xã hội cũng nhiều như phụ thuộc vào mã nguồn. Blockchain thường được mô tả bằng nguyên tắc “mã nguồn là luật”, nhưng lịch sử cho thấy khi sự đồng thuận của cộng đồng yêu cầu, mã nguồn có thể—và thực sự sẽ—thay đổi. Vì vậy, việc thiết kế cơ chế quản trị và khả năng phát triển cơ chế đó theo thời gian cũng quan trọng như kiến trúc kỹ thuật ban đầu.

Báo cáo này nhằm làm rõ cấu trúc, quá trình phát triển và trạng thái hiện tại của hoạt động quản trị trên Solana. Báo cáo cung cấp góc nhìn toàn diện về cách các quyết định được đưa ra trong mạng và cách mô hình quản trị này được so sánh với những hệ sinh thái blockchain khác. Nội dung gồm bốn phần chính:

• Các thành phần trong quản trị Solana – Xem xét những thành phần cốt lõi trong quy trình quản trị Solana, bao gồm SIMD, hoạt động kích hoạt feature gate và các cuộc bỏ phiếu chính thức on-chain.
• Phân tích hoạt động bỏ phiếu quản trị – Tổng quan chi tiết về mọi cuộc bỏ phiếu quản trị chính thức cho đến nay, bao gồm kết quả, hành vi của cử tri và số liệu tham gia.
• Thách thức và khuyến nghị – Phân tích các vấn đề chính mà mô hình quản trị hiện tại của Solana đang đối mặt, kèm theo các khuyến nghị có thể áp dụng khi phù hợp.
• So sánh với các mạng khác – Tìm hiểu cách hoạt động quản trị diễn ra trong các hệ sinh thái tương đồng là Cosmos và Ethereum, đồng thời nêu bật những thông lệ có thể giúp cải thiện Solana.

Dù báo cáo mạch lạc nhất khi được đọc theo thứ tự, mỗi phần đều có nội dung độc lập và có thể được đọc riêng.

Các thành phần trong quản trị Solana

Bảng dưới đây cung cấp thông tin tổng quan về hệ thống quản trị Solana, được xây dựng theo một khuôn khổ phân tích điều chỉnh từ bài nghiên cứu Phân tích quy trình ra quyết định trong quản trị blockchain của Schädler, Lustenberger và Spychiger (2023). Chúng tôi đã điều chỉnh khuôn khổ này để phản ánh các cơ chế và động lực cụ thể trong hệ sinh thái Solana.

Các sửa đổi đối với giao thức Solana tuân theo một quy trình nhiều giai đoạn, thay đổi tùy theo bản chất và tác động của từng thay đổi. Các yếu tố chính bao gồm việc thay đổi đó có phá vỡ đồng thuận hay không, tác động đến các bên liên quan và mức độ tranh cãi hoặc phức tạp. Thay đổi phá vỡ đồng thuận là bất kỳ bản cập nhật giao thức nào khiến các node chạy những phiên bản phần mềm khác nhau không thống nhất về trạng thái blockchain. 

Bảng sau trình bày các bước điển hình đối với những thay đổi có quy mô khác nhau. “Thay đổi lớn” là những thay đổi có khả năng tạo ra tác động kinh tế.

Dưới đây, chúng tôi sẽ mô tả chi tiết quy trình kích hoạt feature gate, SIMD và bỏ phiếu quản trị.

Kích hoạt feature gate

Các nhóm phát triển cốt lõi của Anza và Firedancer thường xuyên phát hành tính năng mới, bao gồm syscall, chương trình native và những thay đổi kinh tế có thể phá vỡ đồng thuận. Các tính năng này được tạo, đưa vào bản phát hành phần mềm client mới và mặc định bị vô hiệu hóa sau một feature flag. Feature Gate Program, mới được chuyển sang một chương trình Core BPF, theo dõi mỗi tính năng mới dưới dạng một account. Khóa riêng dành riêng cho từng feature gate do cộng tác viên cốt lõi phụ trách feature gate đó nắm giữ. Khi đủ số validator có stake đã nâng cấp lên bản phát hành mới và phiên bản được coi là ổn định, công tắc tính năng runtime sẽ được kích hoạt thủ công bằng một instruction; tính năng bắt đầu hoạt động trên tất cả các node trong mạng vào đầu epoch tiếp theo. Có thể theo dõi chính xác thứ tự và thời điểm kích hoạt qua lịch feature gate. Việc kích hoạt tính năng không phụ thuộc vào cluster: tính năng được kích hoạt trước trên Testnet, sau đó là Devnet và cuối cùng là Mainnet, giúp củng cố mức độ tin cậy vào các phiên bản mới trước khi kích hoạt lần cuối trên Mainnet.

“Sàn phiên bản” là phiên bản phần mềm được hỗ trợ tối thiểu hiện tại của một cluster. Khi feature gate mới được kích hoạt, sàn phiên bản được nâng lên để khớp với bản phát hành phần mềm chứa tính năng đó. Hoạt động kích hoạt tính năng mới trên Solana tuân theo nhịp độ đều đặn, thường diễn ra tại ranh giới epoch rơi vào giờ làm việc các ngày trong tuần. Việc kích hoạt được tạm dừng trong quá trình chuyển đổi phiên bản và tiếp tục khoảng hai epoch sau khi 95% lượng stake đã nâng cấp lên một bản phát hành nhỏ mới (ví dụ: từ phiên bản 2.2 lên 2.3).

Kích hoạt feature gate là các hard fork không tương thích ngược và cần được áp dụng trên toàn mạng mới có hiệu lực. Nếu một validator không nâng cấp lên phiên bản nhận diện feature gate đã kích hoạt, validator đó không thể tiếp tục xác thực trạng thái toàn cục và sẽ tách khỏi mạng.

Khác với Bitcoin hoặc Ethereum, nơi bất đồng về một hard fork có thể dẫn đến chia tách chuỗi vĩnh viễn, cách tiếp cận của Solana đảm bảo feature gate được kích hoạt trên toàn cluster tại một slot cụ thể. Validator phải nâng cấp trước, nhờ đó ngăn việc chia tách chuỗi. Vì vậy, dù feature gate là hard fork theo nghĩa chúng thay đổi quy tắc đồng thuận, chúng không thể tạo ra các chuỗi cạnh tranh.

Các phiên bản client mới cũng chứa nhiều thay đổi không phá vỡ đồng thuận, chẳng hạn như tái cấu trúc mã và tối ưu hóa hiệu suất, nên không yêu cầu feature gate.

Tài liệu cải tiến Solana (SIMD)

Các đề xuất Tài liệu cải tiến Solana (SIMD) là tài liệu chính thức cần thiết cho mọi thay đổi đáng kể đối với các thành phần cốt lõi của Solana. Thay đổi "đáng kể" được định nghĩa là những thay đổi thường tác động đến giao thức mạng, tính hợp lệ của transaction hoặc khả năng tương tác. Các thay đổi không đáng kể như tái cấu trúc mã nhỏ hoặc cải thiện hiệu suất khách quan không cần đề xuất. Đề xuất phải ghi lại lý do của tính năng và cung cấp đủ tài liệu để hiểu cách triển khai. 

Dù bất kỳ ai cũng có thể gửi SIMD mà không cần cấp quyền, hầu hết SIMD do các nhà phát triển thuộc nhóm client đang làm việc toàn thời gian để cải thiện giao thức cốt lõi gửi lên.

Có hai loại đề xuất: 

• Đề xuất tiêu chuẩn: ảnh hưởng đến các tính năng cốt lõi của Solana (ví dụ: đồng thuận, kết nối mạng và giao diện API)
• Đề xuất meta: đề cập đến các quy trình hoặc hướng dẫn bên ngoài codebase

SIMD thường trải qua các giai đoạn thẩm định ý tưởng, soạn thảo, đánh giá và chấp thuận. Quá trình đánh giá chính thức diễn ra công khai trên GitHub. Tác giả đề xuất chịu trách nhiệm thu thập phản hồi từ các cộng tác viên cốt lõi có liên quan thuộc cả hai nhóm client Agave và Firedancer. Những người này sẽ xác định đề xuất được chấp thuận, sửa đổi hay rút lại dựa trên yếu tố bảo mật, sự đánh đổi và khả năng tương thích ngược.

Tác giả không bắt buộc phải triển khai đề xuất của mình, nhưng thường được khuyến nghị làm như vậy vì đây là cách tốt nhất để đảm bảo hoàn thành thành công. Nếu được chấp thuận, đề xuất thường đi kèm một issue theo dõi việc triển khai tính năng và thông thường sẽ cần kích hoạt qua cơ chế feature gate của Solana. 

Dù không phải mọi lần kích hoạt feature gate đều yêu cầu SIMD, phần lớn đều đi kèm một SIMD để cung cấp bối cảnh, lý do và hồ sơ chuẩn hóa về thay đổi được đề xuất.

Bỏ phiếu quản trị

Các SIMD làm thay đổi đáng kể giao thức, đặc biệt là những SIMD tác động đến tham số kinh tế, cần được bỏ phiếu quản trị. Quy trình quản trị của Solana do các thành viên giàu kinh nghiệm trong cộng đồng validator dẫn dắt và chỉ tập trung vào những vấn đề then chốt để duy trì mức độ tham gia cũng như tránh sự mệt mỏi với quản trị. Vì vậy, mỗi năm chỉ có một vài cuộc bỏ phiếu.  

Các cuộc bỏ phiếu quản trị chủ yếu đóng vai trò như một cơ chế đánh giá quan điểm đối với những thay đổi được đề xuất. Việc cho phép validator thể hiện lập trường trước khi triển khai đầy đủ giúp định hướng phát triển và giảm thiểu bất đồng. Triển khai một thay đổi mà không có đồng thuận rộng rãi có thể gây xung đột, đặc biệt nếu hơn một phần ba mạng phản đối việc áp dụng.

Việc bỏ phiếu được thực hiện bằng token SPL. Identity account của mỗi validator đang hoạt động được phân bổ token theo tỷ lệ stake đang hoạt động, tính bằng lamport. Sau đó, validator có thể gửi các token này đến địa chỉ được chỉ định đại diện cho những phương án bỏ phiếu khác nhau, bao gồm cả phương án bỏ phiếu trắng. Validator có thể tự do chia phiếu cho nhiều phương án—ví dụ: phân bổ 80% cho YES và 20% cho NO—qua đó linh hoạt phản ánh những ưu tiên đa dạng của người stake. Sau khi gửi, phiếu bầu là quyết định cuối cùng và không thể thay đổi.

Trong cấu trúc này, người nắm giữ token SOL tham gia gián tiếp bằng cách ủy quyền SOL đã stake cho các validator có lựa chọn bỏ phiếu phù hợp với giá trị hoặc ưu tiên của họ. Đây là một hệ thống đại diện tỷ lệ, trong đó validator có thể được xem là đại diện được bầu. Người stake trên Solana ủy quyền stake của mình cho validator và quyền biểu quyết của mỗi validator dựa trên lượng stake đang hoạt động của họ.

Giới hạn của quản trị on-chain

toly 🇺🇸

@toly

@garious14 There is no “governance”. It’s just a signal to check if the proposed upgrade would cause a contentious fork. It has to come from validators.

3:56 CH 17 thg 3, 2025

Quản trị trên Solana xét cho cùng không mang tính ràng buộc mà chỉ có vai trò tư vấn. Trên thực tế, cuộc bỏ phiếu thực sự diễn ra khi các validator chọn phiên bản phần mềm sẽ chạy. Dù các cuộc bỏ phiếu quản trị có thể cho thấy sự ủng hộ hoặc phản đối rộng rãi từ cộng đồng, chúng không buộc validator phải áp dụng bất kỳ mã cụ thể nào. Đề xuất thậm chí có thể thay đổi sau cuộc bỏ phiếu và validator vẫn giữ toàn quyền kiểm soát phần mềm chạy trên hạ tầng của mình. Điều này có nghĩa quản trị thiên về báo hiệu đồng thuận hơn là cưỡng chế kết quả.

Trong bối cảnh này, các cộng tác viên cốt lõi như Anza, Jump và Jito cùng những nhà cung cấp hạ tầng như Helius và Triton có ảnh hưởng phi chính thức đáng kể. Do validator ít có khả năng phản đối các nhóm này và chấp nhận nguy cơ mất stake hoặc mất đồng bộ với mạng, những tổ chức này có thể định hình kết quả nâng cấp một cách hiệu quả—dù có hay không có thẩm quyền ra quyết định chính thức.

Một đợt fork có thể xảy ra trong kịch bản cực đoan khi validator từ chối nâng cấp. DAO Fork của Ethereum vào năm 2016, dẫn đến sự ra đời của Ethereum Classic, vẫn là một ví dụ cảnh báo. Khi quy trình quản trị Solana phát triển, việc làm rõ mối quan hệ giữa phiếu bầu báo hiệu, bản phát hành phần mềm và mức độ chấp nhận thực tế của validator sẽ đảm bảo tính minh bạch và tránh rủi ro cực đoan về chia tách chuỗi.

Phân tích hoạt động bỏ phiếu quản trị

Hoạt động quản trị ban đầu của Solana: 2020-2022

Cách tiếp cận ban đầu của Solana đối với quản trị rất khác với khuôn khổ ngày nay. Hoạt động quản trị ban đầu xoay quanh Feature Proposal Program, cho phép validator bỏ phiếu về các thay đổi giao thức bằng token SPL được tính trọng số theo stake. Khi một bản phát hành tính năng mới sẵn sàng để kích hoạt, validator được phân bổ token biểu quyết theo tỷ lệ stake đang hoạt động. Bằng cách gửi lại các token này đến một account được chỉ định trong thời hạn hai tuần, validator có thể báo hiệu sự chấp thuận đối với việc kích hoạt tính năng được đề xuất. Khi đạt ngưỡng 67% lượng stake, thay đổi sẽ được kích hoạt trực tiếp on-chain trong epoch tiếp theo.

Feature Proposal Program đã được dùng để tổ chức nhiều cuộc bỏ phiếu quản trị của validator trên cả Testnet và Mainnet, đáng chú ý nhất là cuộc bỏ phiếu kích hoạt lịch lạm phát hiện tại.

Hồ sơ trực tuyến về các cuộc bỏ phiếu quản trị ban đầu này khá ít ỏi vì Diễn đàn Solana nguyên bản đã ngừng hoạt động và hiện chỉ có thể truy cập qua các phiên bản lưu trữ trên Wayback Machine.

Dù cơ chế này đã đưa vào một mức độ phối hợp on-chain nhất định, nó vẫn bị chỉ trích rộng rãi. Validator không có cách nào thể hiện sự phản đối—chỉ phiếu YES được tính và không có phương thức chính thức để báo hiệu phản đối hoặc bỏ phiếu trắng. Hệ thống này cũng tạo ra áp lực xã hội phải phê duyệt thay đổi, đặc biệt sau khi một lượng công sức kỹ thuật đáng kể đã được đầu tư vào quá trình triển khai. 

Quan trọng hơn, hệ thống không cung cấp tín hiệu sớm. Điều này đồng nghĩa các tính năng phức tạp có thể được xây dựng mà không biết liệu chúng có được chấp nhận hay không, dẫn đến sự kém hiệu quả và lãng phí thời gian phát triển.

Nhìn chung, dù Feature Proposal Program là một bước đi quan trọng ở giai đoạn đầu trong hành trình quản trị của Solana, các hạn chế của chương trình đã góp phần định hình những cơ chế quản trị linh hoạt hơn đang được sử dụng ngày nay.

Cần lưu ý rằng một số thay đổi kinh tế lớn trong giai đoạn đầu này—chẳng hạn như áp dụng phí ưu tiên với tỷ lệ đốt 50%—đã được triển khai mà không có cuộc bỏ phiếu quản trị chính thức, phản ánh một thời kỳ mà hệ thống quản trị vẫn còn sơ khai.

Hoạt động quản trị hiện tại của Solana: Từ năm 2023 trở đi

Sau giai đoạn sử dụng Feature Proposal Program, Solana đã phát triển thành hệ thống bỏ phiếu quản trị hiện tại. Cho đến nay, đã có năm cuộc bỏ phiếu quản trị chính thức:

• Cuộc bỏ phiếu tư vấn ban đầu vào tháng 10 năm 2023
• SIMD-33 Tín dụng phiếu bầu đúng hạn vào tháng 4 năm 2024 của Bryan Ischo và Zantetsu, Shinobi Systems
• SIMD-96 Toàn bộ phí ưu tiên cho validator vào tháng 5 năm 2024 của Tao Zhu, Anza
• SIMD-123 Phân phối phần thưởng khối trong giao thức của Justin Starry, Anza
• SIMD-228 Cơ chế phát hành dựa trên thị trường của Tushar Jain và Vishal Kankani, Multicoin Capital, Max Resnick, Anza vào tháng 3 năm 2025

Cuộc bỏ phiếu tư vấn ban đầu

Một quyết định quan trọng ban đầu trong việc định hình khuôn khổ quản trị hiện tại của Solana là xác định ai nên tham gia quy trình bỏ phiếu. Cộng đồng được đưa ra ba phương án:

1. Chỉ validator bỏ phiếu, với phiếu bầu được tính trọng số theo stake
2. Validator và stake account, cho phép người ủy quyền phủ quyết phiếu bầu của validator
3. Validator, stake account và các bên liên quan khác như nhà vận hành RPC và nhà phát triển

Cuộc bỏ phiếu tư vấn có hơn 170 validator tham gia, đại diện cho 14,3% tổng lượng stake. Trong lượng stake đã bỏ phiếu, hơn 70% ủng hộ mô hình chỉ validator bỏ phiếu, còn 24% ủng hộ mô hình validator và người ủy quyền. Cuộc bỏ phiếu này không áp dụng ngưỡng tham gia tối thiểu.

Mô hình chỉ validator bỏ phiếu được ưu tiên vì là điểm khởi đầu thiết thực và hiệu quả nhất, do hạ tầng cần thiết đã tồn tại và được kiểm chứng trong thực tế. Các hệ thống phức tạp hơn có sự tham gia của người ủy quyền hoặc những bên liên quan khác được coi là quá sớm và có thể tạo thêm gánh nặng cho một quy trình quản trị còn non trẻ. Cộng đồng thừa nhận rằng các mô hình bỏ phiếu khác có thể được giới thiệu và hoàn thiện qua những đề xuất trong tương lai khi hoạt động quản trị trưởng thành hơn.

Xu hướng bỏ phiếu quản trị

Kể từ cuộc bỏ phiếu tư vấn ban đầu, đã có thêm bốn cuộc bỏ phiếu quản trị với cùng ba phương án: YES, NO và Bỏ phiếu trắng. Các phương án này thể hiện mức độ đồng ý với SIMD được đề xuất. Để được thông qua, ít nhất hai phần ba tổng số phiếu YES và NO phải là phiếu ủng hộ (tức YES). 

SIMD-33: Tín dụng phiếu bầu đúng hạn đã được phê duyệt với mức ủng hộ áp đảo, nhận 98,4% phiếu YES. Thay đổi đồng thuận không gây tranh cãi này xử lý những động lực chưa phù hợp bằng cách loại bỏ lợi ích mà validator trước đây nhận được khi gửi phiếu muộn, qua đó cải thiện hành vi và tính công bằng của mạng.

SIMD-96: Toàn bộ phí ưu tiên cho validator được thông qua với 77,7% phiếu YES. Đề xuất kinh tế này nhằm hạn chế việc xử lý transaction qua kênh phụ bằng cách chuyển 100% phí ưu tiên cho validator. Dù hiệu quả trong việc điều chỉnh động lực, đề xuất vẫn gây phần nào tranh cãi do làm tăng nhẹ lạm phát và bị cho là ưu ái validator hơn người nắm giữ SOL.

SIMD-123: Phân phối phần thưởng khối trong giao thức được phê duyệt với 74,91% phiếu YES. Đề xuất đưa ra một cơ chế chuẩn hóa, không bắt buộc để validator trực tiếp phân phối phần thưởng khối cho người stake. Dù một số validator đã làm điều này bằng các phương thức thủ công hơn, việc đưa hoạt động này vào giao thức đã làm dấy lên tranh luận về áp lực cạnh tranh, với lo ngại rằng nó có thể dẫn đến một "cuộc đua về 0" đối với tỷ lệ hoa hồng phần thưởng khối.

SIMD-228: Cơ chế phát hành dựa trên thị trường không được thông qua khi chỉ có 61,39% bỏ phiếu YES. Đề xuất nhằm làm cho tỷ lệ lạm phát của Solana phản ứng linh hoạt hơn với mức độ tham gia staking, lập luận rằng mức phát hành hiện tại quá cao, không phản ứng với nhu cầu lợi suất và khiến mạng phải trả quá nhiều cho bảo mật.

Các bên phản đối bày tỏ lo ngại về khả năng tồn tại về mặt kinh tế của những validator nhỏ hơn và mức độ bất định gia tăng mà đề xuất có thể tạo ra đối với lợi suất staking. Cuộc bỏ phiếu gây tranh cãi gay gắt, tạo ra nhiều cuộc thảo luận và làm nổi bật các quan điểm khác nhau về mô hình kinh tế dài hạn của Solana.

Để tìm hiểu chi tiết hành vi bỏ phiếu, độc giả nên tham khảo các dashboard phiếu bầu nguồn mở dành cho SIMD-96, SIMD-123 và SIMD-228. Ngoài ra, chúng tôi còn cung cấp một bảng tính chứa dữ liệu bỏ phiếu tại đây.

Ngưỡng túc số 33% lượng stake tham gia—bao gồm cả phiếu trắng—đã được áp dụng cho SIMD-228 và SIMD-123. Ngược lại, các đề xuất trước đó như SIMD-96 và SIMD-33 không có yêu cầu tham gia tối thiểu, nghĩa là chúng có thể được thông qua bất kể bao nhiêu phần trong tổng lượng stake tham gia bỏ phiếu.

Tỷ lệ tham gia

Tỷ lệ tham gia bỏ phiếu có xu hướng tăng theo thời gian. Cuộc bỏ phiếu tư vấn ban đầu vào tháng 10 năm 2023 ghi nhận mức độ tham gia rất thấp, khi chỉ 14,3% lượng stake tham gia. Kể từ đó, tỷ lệ này tăng đều và đạt đỉnh trong cuộc bỏ phiếu tháng 3 năm 2025 về SIMD-228, Cơ chế phát hành dựa trên thị trường, với tỷ lệ tham gia 74,3%. Ba cuộc bỏ phiếu còn lại cho đến nay có mức tham gia tương đối ổn định, dao động từ 51,2% đến 57,1%.

Cuộc bỏ phiếu về SIMD-228 là sự kiện quản trị lớn nhất trong lịch sử tiền mã hóa xét theo cả số người tham gia và tổng vốn hóa thị trường được đại diện. Tại thời điểm tranh luận, vốn hóa thị trường của Solana tương đương Bitcoin trong cuộc chiến kích thước khối giữa năm 2017, cho thấy tầm quan trọng của quyết định này. Tổng cộng 281 triệu SOL, trị giá 35 tỷ USD, đã tham gia bỏ phiếu, với hơn 900 validator gửi hơn 1.000 phiếu. Đáng chú ý, đây là lần đầu tiên các validator của sàn giao dịch lớn—bao gồm Coinbase, Kraken và Bybit—tích cực tham gia hoạt động quản trị on-chain của Solana, báo hiệu sự hiện diện ngày càng tăng của các tổ chức trong quy trình ra quyết định của mạng. Mức tăng tham gia gần đây, đặc biệt từ các tổ chức có trụ sở tại Hoa Kỳ, cũng có thể một phần bắt nguồn từ môi trường pháp lý blockchain thuận lợi hơn dưới chính quyền hiện tại.

Vấn đề và khuyến nghị

Trong phần tiếp theo, chúng tôi sẽ phân tích những thách thức chính trong quy trình bỏ phiếu quản trị và đưa ra khuyến nghị nhằm cải thiện tính minh bạch, bảo mật và hiệu quả khi phù hợp.

Người stake chưa tham gia đầy đủ

Một mối quan ngại thường trực trong quy trình quản trị Solana là vai trò hạn chế của người ủy quyền trong việc ra quyết định. Dù validator bỏ phiếu về đề xuất bằng quyền quản trị được tính trọng số theo stake, chưa có cơ chế chính thức để người ủy quyền thể hiện ưu tiên hoặc phủ quyết quyết định của validator. Điều này có thể dẫn đến trường hợp phiếu bầu của validator xung đột với lợi ích của người ủy quyền, khiến người stake không có cách trực tiếp tác động đến kết quả quản trị.

Các validator có hàng nghìn người ủy quyền gặp khó khăn khi thu thập lựa chọn bỏ phiếu của từng người, trong khi tỷ lệ tham gia của người stake thường thấp. Một số validator giải quyết phần nào vấn đề này bằng cách tham khảo ý kiến những người ủy quyền lớn nhất trước khi bỏ phiếu và chia phiếu theo ưu tiên của họ. Những validator khác đã thử nghiệm công cụ tùy chỉnh mô phỏng hệ thống bỏ phiếu bằng token hiện có—phát hành token quản trị mới cho người stake dựa trên tỷ lệ stake của họ. Tuy nhiên, đây vẫn là giải pháp riêng của từng validator thay vì một tính năng chuẩn hóa trên toàn giao thức.

Những người phản đối sự tham gia của người stake cho rằng hầu hết người ủy quyền không có chuyên môn kỹ thuật, hiếm khi theo sát các quyết định quản trị và thiếu hiểu biết chuyên sâu về cơ chế blockchain cũng như những đánh đổi cần thiết để đưa ra quyết định sáng suốt. Tuy nhiên, bên ủng hộ cho rằng việc chỉ dựa vào validator tạo ra xung đột lợi ích—không thực tế khi kỳ vọng phần lớn validator bỏ phiếu cho những đề xuất có lợi cho mạng nếu chúng gây tổn hại đến lợi ích kinh tế của chính họ.

Các cải tiến tiềm năng bao gồm xây dựng kênh giao tiếp tốt hơn giữa validator và người ủy quyền, chẳng hạn như dashboard quản trị, công cụ theo dõi quan điểm hoặc thậm chí thông báo trong ví về các sự kiện quản trị. Một phần sau của báo cáo sẽ quay lại chủ đề này và xem xét cách tiếp cận của hệ sinh thái Cosmos.

Thách thức trong thảo luận quản trị

Quản trị hiệu quả trong các hệ sinh thái phi tập trung phụ thuộc vào hoạt động giao tiếp rõ ràng, giàu thông tin. Tuy nhiên, trong đề xuất SIMD-288 gần đây, những cuộc tranh luận căng thẳng, công kích cá nhân và tình trạng bè phái đã tạo ra môi trường quản trị không lành mạnh, cuối cùng cản trở việc thảo luận hiệu quả. Các cuộc thảo luận về những đề xuất quan trọng trên Solana có thể thiếu hiệu quả và giảm chất lượng thông tin trên nhiều nền tảng. Dù các cuộc thảo luận kỹ thuật trên GitHub và diễn đàn Solana chính thức có cấu trúc và chiều sâu, khi lan sang Discord và Twitter, nội dung trao đổi có ý nghĩa đôi khi biến thành những cuộc khẩu chiến và công kích cá nhân, làm giảm chất lượng chung của quá trình ra quyết định.

Ngoài ra, phần lớn người tham gia chỉ xuất hiện trong những ngày cuối trước cuộc bỏ phiếu thay vì tận dụng toàn bộ thời gian thảo luận. Khuyến khích tham gia sớm hơn và cấu trúc tốt hơn lịch trình quản trị—chẳng hạn đảm bảo các cuộc thảo luận quan trọng diễn ra từ lâu trước thời gian bỏ phiếu cuối cùng—có thể giúp giảm thiểu những vấn đề này.

Các cuộc gọi về quản trị đã chứng minh hiệu quả khi cho phép trao đổi trực tiếp, giải đáp nhanh chóng và giảm cơ hội phá rối hoặc định hướng sai lệch. Tăng cường kiểm duyệt, thúc đẩy thảo luận có cấu trúc và nhấn mạnh phân tích dựa trên dữ kiện thay vì trao đổi mang tính đối đầu là những yếu tố thiết yếu để duy trì quy trình quản trị mang tính xây dựng.

Gộp các đề xuất quản trị

Các quyết định quản trị thường hiệu quả nhất khi mỗi đề xuất được bỏ phiếu độc lập, cho phép cử tri đánh giá từng vấn đề dựa trên giá trị riêng. Một mối quan ngại chính khi gộp đề xuất là thiên kiến vô thức—cử tri có quan điểm mạnh về một vấn đề có thể vô tình để quan điểm đó ảnh hưởng đến lập trường của họ về những vấn đề khác, ngay cả khi chúng không liên quan. Điều này làm giảm khả năng ra quyết định có cân nhắc và có thể ngăn những thay đổi vốn có lợi được triển khai.

Một rủi ro khác là việc gộp đề xuất làm tăng độ phức tạp trong vận hành, khiến lỗi dễ xảy ra hơn. Điều này được ghi nhận trong giai đoạn bỏ phiếu chung cho SIMD-228 và SIMD-123, khi một lượng nhỏ token dành cho SIMD-123 bị gửi nhầm đến địa chỉ bỏ phiếu trắng của SIMD-228. Dù hiếm gặp, những lỗi như vậy làm sai lệch kết quả bỏ phiếu và suy giảm niềm tin vào quy trình quản trị.

Tuy nhiên, lập luận ủng hộ việc gộp đề xuất là tập hợp nhiều quyết định vào ít giai đoạn bỏ phiếu hơn có thể giúp giảm sự mệt mỏi của cử tri và khuyến khích tỷ lệ tham gia cao hơn. Dù có thể cải thiện mức độ tham gia, cách làm này phải đánh đổi sự rõ ràng và chính xác trong quá trình ra quyết định. Ngoài ra, khi các đề xuất gộp có tính phức tạp, chúng thường cần thời gian thảo luận và đánh giá kéo dài trước khi bắt đầu bỏ phiếu để cử tri—đặc biệt là những người thường chỉ tham gia vào phút chót—có đủ thời gian hiểu và đánh giá kỹ từng thành phần.

Cách tiếp cận hiệu quả hơn có thể là tách riêng các đề xuất quản trị bất cứ khi nào có thể, đảm bảo mỗi vấn đề được đánh giá độc lập. Nếu cần gộp, lý do phải được trình bày rõ ràng.

Ngưỡng túc số bỏ phiếu

Vai trò của ngưỡng túc số xác định trong các cuộc bỏ phiếu quản trị Solana đã làm dấy lên lo ngại. Trên thực tế, ngưỡng túc số có thể tạo ra động cơ sai lệch, khiến người tham gia chủ động không bỏ phiếu để ngăn đề xuất đạt ngưỡng bắt buộc. Trong cuộc bỏ phiếu SIMD-228 gần đây, điều này đặc biệt rõ ràng ở những cử tri chọn NO. Trong hai epoch bỏ phiếu đầu tiên, họ nhận thấy việc không tham gia là chiến lược hiệu quả hơn so với tích cực bỏ phiếu chống lại đề xuất. 

Khả năng xem số phiếu hiện tại ảnh hưởng đến mức độ tham gia. Một số validator có thể chọn không bỏ phiếu nếu kết quả dự kiến đã phù hợp với mong muốn của họ. Để ngăn thao túng ngưỡng túc số, một cải tiến tiềm năng là trì hoãn việc hiển thị phiếu bầu cho đến khi thời gian bỏ phiếu kết thúc.

Trước những thách thức này, ngày càng có nhiều ý kiến ủng hộ việc đánh giá lại hoặc loại bỏ yêu cầu về ngưỡng túc số để khuyến khích sự tham gia quản trị minh bạch và trực tiếp hơn.

Tác động của SFDP

Tại thời điểm viết bài, Solana Foundation Delegation Program ủy quyền SOL cho 897 validator, chiếm 66% tổng số validator đang hoạt động trên mạng. Tổng lượng được ủy quyền là 41,01 triệu SOL, tương đương 10% tổng SOL đã stake. Độc giả có thể tham khảo báo cáo trước đây của blog Helius về SFDP để biết đầy đủ chi tiết về chương trình và các chiến lược ủy quyền.

Theo mô hình quản trị hiện tại, quyền biểu quyết của các validator trong chương trình được khuếch đại trên thực tế và họ bỏ phiếu thay mặt Solana Foundation. Phân tích nội bộ của chúng tôi và dashboard công khai về cuộc bỏ phiếu quản trị SIMD-288 gần đây xác nhận rằng stake từ SFDP đóng vai trò quan trọng trong kết quả bỏ phiếu. Trong cuộc bỏ phiếu này, stake từ SFDP chủ yếu được dùng để bỏ phiếu NO chống lại đề xuất. Nếu lượng stake do SFDP kiểm soát đã bỏ phiếu NO hoặc bỏ phiếu trắng chuyển sang bỏ phiếu YES, đề xuất đã được thông qua. Nếu toàn bộ stake do SFDP kiểm soát giữ trung lập và bỏ phiếu trắng, đề xuất vẫn không được thông qua, nhưng với khoảng cách nhỏ hơn—64,77% so với mức thực tế 61,39% (cần 66,6% để được thông qua).

Làm rõ tiêu chí tổ chức bỏ phiếu

Các cuộc bỏ phiếu quản trị tháng 3 năm 2025 ban đầu bao gồm ba đề xuất: SIMD-228, SIMD-123 và SIMD-218: Tín dụng phiếu bầu trung gian (IVC). IVC loại bỏ nhu cầu sử dụng các bản mod do validator vận hành để tối ưu hóa tín dụng phiếu bầu Tower BFT (biến thể thuật toán đồng thuận pBFT của Solana) bằng cách tự động bổ sung tín dụng cho tất cả khối cha khi validator bỏ phiếu cho một khối con.

Trong thời gian thảo luận, ngày càng có nhiều đồng thuận rằng SIMD-218 không cần phê duyệt quản trị. Thay đổi này được xem rộng rãi là một bản sửa lỗi thay vì thay đổi đáng kể đối với giao thức, vì nó chỉ cải thiện hoặc sửa bản nâng cấp Tín dụng phiếu bầu đúng hạn (TVC). TVC trước đó đã vượt qua một cuộc bỏ phiếu quản trị và nhận được sự ủng hộ mạnh mẽ từ cộng đồng. Một cuộc thăm dò không chính thức giữa các validator trên Solana Tech Discord củng cố quan điểm này với mức đồng thuận gần như tuyệt đối.

Ngoài ra, các kỹ sư từ Anza lưu ý rằng SIMD-123: Phân phối phần thưởng khối trong giao thức không phải là thay đổi kinh tế như tên gọi có thể hàm ý. Đề xuất đưa ra một phương thức không bắt buộc trong giao thức để phân phối phần thưởng khối cho người stake, chính thức hóa thông lệ mà một số validator đã thực hiện bằng các phương thức khác và chuẩn hóa hoạt động trước đây diễn ra ngoài giao thức.

Điều này đặt ra những câu hỏi quản trị quan trọng:

• Ai quyết định một đề xuất có cần bỏ phiếu hay không? Hiện không có cơ quan chính thức hoặc quy trình có cấu trúc nào để xác định một đề xuất nên trải qua quy trình quản trị hay được triển khai trực tiếp.
• Tiêu chí cấu thành một “thay đổi đáng kể đối với giao thức” vẫn còn mơ hồ. Ranh giới giữa một bản nâng cấp thông thường và một thay đổi cần sự can thiệp chính thức của hoạt động quản trị chưa rõ ràng, trong khi các định nghĩa hiện tại phụ thuộc nhiều vào khái niệm “tác động kinh tế” tương đối mơ hồ.

Vấn đề bảo mật

Quy trình bỏ phiếu hiện tại cho các đề xuất quản trị phụ thuộc vào công cụ của bên thứ ba là solgov-distributor, do một thành viên cộng đồng tên Laine phát triển và lưu trữ. Công cụ này là một bản fork của công cụ phân phối token dựa trên Merkle do Jito phát triển ban đầu. Dù Laine là một thành viên được cộng đồng tôn trọng, việc phụ thuộc vào công cụ do bên ngoài kiểm soát tạo ra các giả định về niềm tin và rủi ro bảo mật.

• Khả năng thay đổi – cả công cụ và tài liệu đều có thể thay đổi, nghĩa là chúng có thể bị đơn phương sửa đổi bất kỳ lúc nào.
• Sử dụng cặp khóa định danh của validator – Validator phải tự build CLI và nhận token bằng cặp khóa định danh validator, vốn là thông tin cực kỳ nhạy cảm. Bất kỳ quy trình nào phụ thuộc vào phần mềm bên ngoài để tương tác với thông tin xác thực quan trọng như vậy đều gây ra rủi ro bảo mật.
• Phụ thuộc vào một người duy trì – Quy trình quản trị chính thức không nên có sự phụ thuộc thiết yếu vào bên thứ ba bên ngoài nếu không có bảo đảm bảo mật chính thức hoặc hoạt động kiểm tra độc lập.

Các cơ chế bỏ phiếu khác

Hiện có một công cụ SPL Feature Proposal (tài liệu tại đây), ban đầu được thiết kế để hỗ trợ quản trị on-chain. Tuy nhiên, các quy trình quản trị gần đây không sử dụng cách tiếp cận này. Thay vào đó, solgov-distributor đã được sử dụng, làm dấy lên câu hỏi liệu công cụ bổ sung này có cần thiết hay không.

Về nguyên tắc, hệ thống token SPL đã cung cấp một phương thức native để phân phối quyền bỏ phiếu quản trị. Người khởi xướng quy trình chỉ cần phân phối token SPL cho tất cả validator, cho phép họ bỏ phiếu bằng spl-token CLI tiêu chuẩn thay vì phụ thuộc vào công cụ bên ngoài. Điều này sẽ loại bỏ những sự phụ thuộc không cần thiết và tăng tính không cần tin cậy trong quy trình bỏ phiếu.

Công cụ quản trị on-chain sắp ra mắt: SIMD-133

SIMD-133: Truy xuất stake theo epoch sắp tới, dự kiến sớm được kích hoạt trên Mainnet, giới thiệu công cụ quản trị mới cho phép chương trình truy xuất trọng số stake on-chain. Hiện tại, các chương trình on-chain không biết phân phối stake của epoch hiện tại và lượng stake được ủy quyền cho từng vote account.

Với SIMD-133, các chương trình quản trị có thể tạo snapshot on-chain về lượng stake của validator thông qua một sysvar mới, loại bỏ nhu cầu về quy trình xác minh stake off-chain hoặc thủ công. Điều này đơn giản hóa đáng kể quy trình quản trị hiện tại và loại bỏ nhu cầu đối soát stake thủ công.

So sánh với các mạng khác

Cosmos

Các chuỗi Cosmos SDK cung cấp mô hình quản trị lấy người ủy quyền làm trung tâm, trong đó người stake có thể trực tiếp phủ quyết phiếu bầu của validator thông qua những ví phổ biến như Keplr và Leap. Điều này có nghĩa khi một validator ban đầu bỏ phiếu bằng toàn bộ trọng số stake, những người ủy quyền không đồng ý có thể phân bổ lại phần stake của mình sang một phương án bỏ phiếu khác. Ví dụ: nếu một validator nắm giữ 2% tổng lượng stake nhưng một người ủy quyền có trọng số stake 1% không đồng ý, họ có thể bỏ phiếu riêng, giảm phiếu bầu thực tế của validator xuống 1% và chuyển 1% của mình sang phương án khác.

Hệ thống này đảm bảo người ủy quyền luôn có tiếng nói cuối cùng, tạo ra một quy trình quản trị minh bạch, thân thiện với người dùng và hiệu quả. Hoạt động tham gia quản trị trên Cosmos có khả năng hiển thị cao vì chức năng bỏ phiếu được tích hợp trực tiếp vào ví và trình khám phá khối, giúp tất cả các bên liên quan dễ dàng tiếp cận.

Một ví dụ liên quan về hành vi bỏ phiếu khác nhau giữa người stake và validator đã xảy ra trong cuộc bỏ phiếu giảm một nửa ATOM của Cosmos (Đề xuất 848, tháng 11/2023), khi đề xuất tìm cách giảm tỷ lệ lạm phát tối đa xuống 10%:

• 94,93% người stake bỏ phiếu YES, ủng hộ giới hạn lạm phát.
• Chỉ 53,44% validator bỏ phiếu YES vì nhiều người muốn duy trì nguồn doanh thu cao hơn.

Sự khác biệt này cho thấy tầm quan trọng của việc người stake tham gia trực tiếp, đảm bảo các quyết định quản trị phản ánh quan điểm rộng hơn của cộng đồng thay vì chỉ phản ánh ưu tiên của validator.

Mô-đun quản trị Cosmos được tích hợp ở cấp giao thức, củng cố vai trò của nó như một tính năng cốt lõi của blockchain. Một số quyết định quản trị có thể được tự động thực thi on-chain, nâng cao tính minh bạch và trách nhiệm giải trình. 

Dù mô hình này mang đến một cấu trúc quản trị dân chủ, nó phụ thuộc vào sự tham gia tích cực và giả định rằng người ủy quyền có thời gian cũng như kiến thức để đưa ra quyết định sáng suốt. Cosmos cung cấp một khuôn khổ quản trị thay thế thuyết phục mà Solana có thể nghiên cứu để xác định những cải tiến tiềm năng.

Ethereum

Hoạt động quản trị Ethereum tuân theo một quy trình xã hội, off-chain thay vì bỏ phiếu trực tiếp dựa trên stake. Quy trình ra quyết định chủ yếu dựa vào Ethereum Improvement Proposal (EIP), các nhà phát triển cốt lõi và sự đồng thuận của cộng đồng.

Các thay đổi đối với Ethereum được đề xuất qua EIP, tương đương với SIMD của Solana. Các EIP này trình bày tính năng, tiêu chuẩn hoặc bản nâng cấp mới cho giao thức Ethereum. Ethereum Request for Comments (ERC) xác định tiêu chuẩn cho các tính năng ở lớp ứng dụng, chẳng hạn như token ERC-20 và NFT ERC-721. Những đề xuất này được thảo luận công khai trên các diễn đàn nghiên cứu Ethereum (Ethereum Magicians), tại các sự kiện Ethereum nổi tiếng (ví dụ: Devcon, ETHDenver, ETHCC), trên GitHub và trong các cuộc gọi của nhà phát triển cốt lõi. Cộng đồng rộng lớn hơn tham gia quản trị bằng cách tranh luận về đề xuất trên các nền tảng như Discord, Farcaster và X.

Khác với Cosmos hoặc Solana, Ethereum không sử dụng cơ chế quản trị dựa trên stake hoặc bỏ phiếu bằng token cho các quyết định giao thức. Kể từ khi Ethereum chuyển sang Proof-of-Stake, validator đóng vai trò tích cực hơn trong đồng thuận nhưng không bỏ phiếu chính thức. Thay vào đó, sự đồng thuận tương đối đạt được qua các cuộc tranh luận kỹ thuật và sự ủng hộ rộng rãi của cộng đồng. Những thay đổi giao thức Ethereum phụ thuộc nhiều vào các nhà phát triển cốt lõi duy trì client thực thi và client đồng thuận của Ethereum (ví dụ: Geth, Nethermind, Prysm).

Các bản nâng cấp lớn được kích hoạt qua hard fork, yêu cầu validator và nhà vận hành node nâng cấp phần mềm. Validator thực thi các quy tắc mạng bằng cách lựa chọn có áp dụng bản nâng cấp mới hay không. Dù hiếm gặp, nếu một thay đổi được đề xuất gây tranh cãi và thiếu đồng thuận, nó có thể dẫn đến chia tách chuỗi, như từng xảy ra với DAO Fork (2016, Ethereum Classic) và ở mức độ thấp hơn là quá trình Ethereum chuyển sang Proof-of-Stake (2022, EthereumPoW).

Mô hình quản trị xã hội của Ethereum ưu tiên đồng thuận kỹ thuật và thảo luận cộng đồng hơn cơ chế bỏ phiếu chính thức. Dù điều này giúp Ethereum duy trì tính linh hoạt và phi tập trung, nó cũng đồng nghĩa các thay đổi cần những cuộc thảo luận kéo dài và sự phối hợp xã hội thay vì cơ chế quản trị trực tiếp dựa trên token. Ngoài ra, không có cách chính thức nào để người nắm giữ ETH hoặc người stake bỏ phiếu về đề xuất, làm hạn chế ảnh hưởng trực tiếp của người dùng.

Kết luận

Hệ thống quản trị Solana vẫn đang phát triển và được định hình qua thử nghiệm thực tế cùng ý kiến đóng góp của cộng đồng. Báo cáo này đã xem xét các thành phần cốt lõi—SIMD, hoạt động kích hoạt tính năng và bỏ phiếu on-chain—đồng thời đánh giá mọi cuộc bỏ phiếu chính thức cho đến nay, các thách thức chính và so sánh với những mạng tương đồng như Cosmos và Ethereum. 

Hệ sinh thái Solana bắt nguồn từ một nền văn hóa mạnh mẽ do kỹ thuật dẫn dắt, coi trọng khả năng lặp lại và triển khai nhanh hơn các cuộc tranh luận kéo dài. Dù tốc độ nâng cấp cao giúp Solana khác biệt với nhiều mạng tương đồng, nó cũng tạo ra căng thẳng với các mô hình quản trị dựa vào thảo luận cộng đồng kéo dài và sự phối hợp xã hội rộng rãi, từ đó đặt ra những thách thức riêng khi cân bằng tốc độ với quy trình ra quyết định toàn diện.

Mô hình quản trị Solana vẫn đang thành hình, nhưng có một điều rõ ràng: mức độ tham gia của cộng đồng chưa bao giờ cao đến vậy. Khi ngày càng nhiều bên liên quan tích cực định hình mạng, Solana có cơ hội đặc biệt để xây dựng một mô hình quản trị tương xứng với tham vọng, tốc độ và hệ sinh thái ngày càng phát triển của mình.

Tài nguyên bổ sung

• Đo lường mức độ phi tập trung của Solana: Sự thật và số liệu - Blog Helius
• Nhóm chuyên gia cố vấn quản trị Solana
• Quản trị blockchain: Lập trình tương lai của chúng ta - Fred Ehrsam