Blockchain thường được mô tả như một hệ thống vận hành không cần trung tâm điều khiển. Tuy nhiên, không có mạng lưới nào hoàn toàn đứng yên. Phần mềm cần được sửa lỗi, quy tắc cần được cập nhật, tham số kỹ thuật đôi khi phải điều chỉnh và cộng đồng có thể phải phản ứng trước những tình huống chưa từng được dự tính. Từ đó xuất hiện một câu hỏi quan trọng nhưng không phải lúc nào cũng được chú ý đúng mức: ai có quyền quyết định khi một blockchain cần thay đổi?
Câu hỏi này dẫn đến khái niệm quản trị blockchain. Đây không chỉ là việc bỏ phiếu trên một giao diện trực tuyến, cũng không đơn thuần là quyền lực của nhóm phát triển mã nguồn. Quản trị là toàn bộ quá trình hình thành đề xuất, thảo luận, đánh giá, biểu quyết, triển khai và kiểm tra một thay đổi có thể ảnh hưởng đến mạng lưới. Cách một blockchain tổ chức quá trình ấy cho thấy nhiều điều về mức độ phân quyền, trách nhiệm và khả năng thích nghi của nó.
Blockchain không loại bỏ quyết định, mà phân bổ lại quyền quyết định
Trong một tổ chức truyền thống, quyết định thường đi theo cấu trúc tương đối rõ ràng. Ban lãnh đạo hoặc một cơ quan có thẩm quyền có thể phê duyệt thay đổi, giao nhiệm vụ cho bộ phận kỹ thuật và chịu trách nhiệm về kết quả. Blockchain lại phân tách những vai trò này giữa nhiều nhóm khác nhau. Nhà phát triển viết và đề xuất mã nguồn, người vận hành nút xác nhận hoặc từ chối chạy phiên bản mới, người nắm giữ tài sản có thể tham gia một số cơ chế biểu quyết, còn người dùng thể hiện lựa chọn thông qua việc tiếp tục sử dụng mạng lưới.
Sự phân tách đó tạo ra một hình thức kiểm soát nhiều tầng, nhưng cũng khiến việc ra quyết định trở nên phức tạp. Một đề xuất được cộng đồng ủng hộ chưa chắc đã được triển khai nếu các nút xác thực không nâng cấp phần mềm. Ngược lại, một thay đổi được nhóm phát triển đánh giá là cần thiết cũng có thể gặp phản đối nếu người dùng cho rằng nó làm thay đổi mục tiêu ban đầu của mạng lưới.
Vì vậy, phân quyền không có nghĩa là mọi người đều có quyền ngang nhau trong mọi tình huống. Nó thường có nghĩa là quyền lực được phân bổ giữa nhiều chủ thể, với các lợi ích, năng lực kỹ thuật và mức độ tham gia khác nhau. Hiểu đúng điểm này giúp tránh hai cách nhìn cực đoan: coi blockchain là hệ thống không ai kiểm soát, hoặc coi mọi quyết định đều do một nhóm duy nhất điều khiển.
Những nhóm thường tham gia vào quá trình quản trị
Nhóm phát triển là lực lượng trực tiếp xây dựng và duy trì phần mềm của blockchain. Họ có thể phát hiện lỗi, đề xuất cải tiến, giải thích tác động kỹ thuật và chuẩn bị phiên bản mới. Tuy nhiên, việc viết mã không đồng nghĩa với quyền tự động áp đặt thay đổi. Trong một mạng lưới có nhiều bên vận hành, mã nguồn chỉ trở thành quy tắc thực tế khi đủ số người chấp nhận và sử dụng nó.
Những người vận hành nút hoặc trình xác thực giữ vai trò đặc biệt vì họ chạy phần mềm kết nối với mạng lưới. Họ quyết định phiên bản nào được cài đặt trên hạ tầng của mình, đồng thời góp phần xác định giao dịch và trạng thái nào được mạng lưới chấp nhận. Quyết định của họ có thể chịu ảnh hưởng bởi chi phí vận hành, rủi ro kỹ thuật, yêu cầu bảo mật và lợi ích kinh tế.
Người dùng và những người nắm giữ tài sản cũng có tiếng nói, dù cách thể hiện không phải lúc nào cũng giống nhau. Họ có thể tham gia bỏ phiếu, thảo luận công khai, sử dụng hoặc ngừng sử dụng một ứng dụng, chuyển tài sản sang mạng lưới khác, hoặc ủng hộ một phiên bản phần mềm cụ thể. Những lựa chọn tưởng như riêng lẻ này có thể tạo ra tín hiệu đáng kể về mức độ chấp nhận của cộng đồng.
Bên cạnh đó là các nhóm xây dựng ứng dụng, nhà cung cấp dịch vụ và những tổ chức phụ thuộc vào blockchain. Họ quan tâm đến tính ổn định, khả năng dự đoán và chi phí thay đổi. Một nâng cấp có thể mang lại lợi ích kỹ thuật cho giao thức nhưng đồng thời buộc các ứng dụng phải điều chỉnh. Vì thế, đánh giá một đề xuất chỉ từ góc nhìn của mã nguồn là chưa đủ.
Biểu quyết bằng tài sản: rõ ràng nhưng không hoàn hảo
Một số hệ thống sử dụng quyền biểu quyết gắn với lượng tài sản mà một người hoặc tổ chức nắm giữ. Cách làm này có ưu điểm là tương đối dễ thiết kế và tạo ra động lực để người tham gia quan tâm đến sự phát triển lâu dài của mạng lưới. Người có lợi ích kinh tế lớn có thể chịu tổn thất nếu hệ thống suy yếu, từ đó có lý do để cân nhắc các đề xuất một cách thận trọng.
Tuy nhiên, quyền biểu quyết theo tài sản cũng đặt ra vấn đề về sự tập trung. Người sở hữu nhiều tài sản có thể có ảnh hưởng lớn hơn người dùng nhỏ lẻ, ngay cả khi họ không đại diện cho toàn bộ lợi ích trong hệ sinh thái. Một tài khoản có thể biểu quyết thay mặt cho nhiều người khác thông qua cơ chế ủy quyền, khiến việc nhìn vào số phiếu cuối cùng không phải lúc nào cũng cho thấy đầy đủ chất lượng của quá trình thảo luận.
Hơn nữa, tài sản và kiến thức kỹ thuật là hai loại nguồn lực khác nhau. Một người có quyền biểu quyết lớn chưa chắc hiểu rõ tác động của một thay đổi đối với bảo mật, khả năng vận hành hoặc ứng dụng. Ngược lại, một nhà phát triển có chuyên môn sâu có thể sở hữu ít tài sản hơn và có ảnh hưởng chính thức hạn chế. Đây là lý do nhiều mô hình quản trị cố gắng kết hợp biểu quyết với thảo luận chuyên môn, đánh giá độc lập và thời gian xem xét trước khi triển khai.
Quy trình tốt cần chậm ở điểm quan trọng
Một quy trình quản trị đáng tin cậy thường bắt đầu bằng việc mô tả rõ vấn đề. Đề xuất không nên chỉ nêu rằng một tính năng mới là cần thiết, mà cần giải thích vấn đề hiện tại, mục tiêu của thay đổi, các phương án thay thế và những rủi ro có thể phát sinh. Cách trình bày này giúp cộng đồng đánh giá nhu cầu thực tế thay vì chỉ phản ứng với một giải pháp đã được đóng gói sẵn.
Sau giai đoạn đề xuất là thảo luận và phản biện. Những người tham gia cần có đủ thời gian để đặt câu hỏi, kiểm tra mã nguồn, xem xét tác động đến các ứng dụng và chỉ ra những giả định chưa được chứng minh. Đối với thay đổi ảnh hưởng đến tài sản hoặc quy tắc đồng thuận, sự vội vàng có thể tạo ra hậu quả khó đảo ngược.
Tiếp đó, một số hệ thống có thể sử dụng triển khai thử nghiệm hoặc mạng kiểm tra trước khi áp dụng rộng rãi. Mục tiêu không phải là loại bỏ hoàn toàn rủi ro, bởi không thử nghiệm nào tái hiện được mọi điều kiện thực tế. Giá trị của bước này nằm ở việc phát hiện lỗi, làm rõ quy trình nâng cấp và cho phép các bên chuẩn bị trước.
Cuối cùng, cần có giai đoạn theo dõi sau khi thay đổi được triển khai. Một quyết định không kết thúc ở thời điểm biểu quyết. Cộng đồng cần quan sát các dấu hiệu bất thường, đánh giá kết quả so với mục tiêu ban đầu và xác định cách xử lý nếu tác động thực tế khác với dự đoán. Việc thừa nhận một nâng cấp chưa đạt mục tiêu không phải là thất bại của quản trị; ngược lại, đó là điều kiện để cơ chế này có thể tự sửa chữa.
Khó khăn lớn nhất nằm ở sự bất cân xứng thông tin
Trong các cuộc thảo luận về blockchain, người tham gia thường có mức độ hiểu biết rất khác nhau. Một số người đọc được mã nguồn và phân tích tác động ở cấp độ giao thức, trong khi nhiều người chỉ có thể dựa vào bản tóm tắt hoặc ý kiến của bên khác. Khoảng cách này dễ tạo ra tình trạng quyết định được hình thành bởi khẩu hiệu, tâm lý đám đông hoặc niềm tin vào một cá nhân có ảnh hưởng.
Giải pháp không phải là yêu cầu mọi người trở thành kỹ sư phần mềm. Một quy trình minh bạch cần cung cấp thông tin ở nhiều tầng: bản giải thích dễ tiếp cận cho người dùng phổ thông, tài liệu kỹ thuật cho người có chuyên môn, mô tả rủi ro và các tiêu chí đánh giá sau triển khai. Khi thông tin được trình bày rõ ràng, người tham gia có thể đóng góp theo năng lực của mình mà không bị loại khỏi quá trình chỉ vì không đọc được mã nguồn.
Minh bạch cũng đòi hỏi phân biệt giữa sự đồng thuận thật sự và sự im lặng. Một đề xuất có ít phản đối không nhất thiết được cộng đồng hiểu đầy đủ. Có thể nhiều người không biết cuộc bỏ phiếu diễn ra, không đủ thời gian nghiên cứu hoặc cho rằng ý kiến của mình không tạo ra khác biệt. Vì vậy, số lượng phiếu không nên là tiêu chí duy nhất để đánh giá tính chính danh của một quyết định.
Quản trị tốt phải cân bằng ổn định và khả năng đổi mới
Nếu thay đổi quá dễ dàng, blockchain có thể trở nên khó dự đoán. Người dùng, nhà phát triển ứng dụng và các bên vận hành sẽ khó lập kế hoạch dài hạn khi quy tắc liên tục bị điều chỉnh. Nhưng nếu quy trình quá cứng nhắc, mạng lưới có thể không phản ứng kịp trước lỗi nghiêm trọng, nhu cầu mới hoặc những biến động trong môi trường công nghệ.
Cân bằng hai mục tiêu này không có công thức chung. Một thay đổi nhỏ về giao diện có thể cần quy trình đơn giản hơn một thay đổi tác động đến quy tắc xác nhận giao dịch. Những vấn đề khẩn cấp có thể đòi hỏi phản ứng nhanh, nhưng sau đó vẫn cần giải trình và đánh giá độc lập. Ngược lại, các thay đổi mang tính nền tảng nên được thảo luận lâu hơn, ngay cả khi việc trì hoãn khiến một số lợi ích chưa thể xuất hiện ngay.
Điều quan trọng là quyền hạn trong tình huống khẩn cấp phải được xác định trước. Nếu một nhóm có thể tự ý thay đổi quy tắc với lý do bảo vệ mạng lưới, cộng đồng cần biết giới hạn của quyền đó, điều kiện kích hoạt và cơ chế kiểm tra sau quyết định. Một ngoại lệ không có ranh giới rõ ràng rất dễ trở thành lối tắt để tập trung quyền lực.
Người dùng nên đặt câu hỏi gì?
Trước một đề xuất quản trị, người dùng không nhất thiết phải tự phân tích toàn bộ mã nguồn. Họ có thể bắt đầu bằng những câu hỏi cơ bản: vấn đề nào đang được giải quyết, ai là người đề xuất, nhóm nào chịu ảnh hưởng trực tiếp, lợi ích và chi phí được phân bổ ra sao, thay đổi có thể đảo ngược hay không, và nếu kết quả không như kỳ vọng thì ai chịu trách nhiệm xử lý?
Cũng nên xem xét cách thức biểu quyết. Quyền bỏ phiếu thuộc về người dùng trực tiếp, người vận hành nút, người nắm giữ tài sản hay một nhóm được ủy quyền? Có thời gian thảo luận trước khi bỏ phiếu không? Kết quả có được công bố cùng với tỷ lệ tham gia và các điều kiện thông qua không? Những câu hỏi này giúp người dùng nhìn vượt ra ngoài con số phần trăm được hiển thị trên một trang quản trị.
Quan trọng hơn, người dùng cần phân biệt giữa sự nổi tiếng của một đề xuất và chất lượng của nó. Một thay đổi được quảng bá mạnh có thể vẫn chứa rủi ro chưa được giải thích. Ngược lại, một đề xuất ít gây chú ý có thể giải quyết vấn đề nền tảng mà không tạo ra hiệu ứng truyền thông lớn. Thói quen đọc tài liệu, so sánh nhiều lập luận và chờ thông tin bổ sung là một phần của việc tham gia quản trị có trách nhiệm.
Kết luận
Blockchain không thể tránh khỏi việc phải đưa ra quyết định. Câu hỏi cốt lõi không phải là có ai nắm quyền hay không, mà là quyền lực được phân bổ như thế nào, có thể kiểm tra ra sao và cộng đồng có cơ hội phản biện đến mức nào. Một mạng lưới đáng tin cậy cần những quy tắc kỹ thuật vững chắc, nhưng cũng cần quy trình xã hội minh bạch để thay đổi các quy tắc đó.
Quản trị tốt không hứa hẹn loại bỏ mọi tranh chấp. Nó tạo ra cách để tranh chấp được bộc lộ, lập luận được kiểm tra và quyết định được xem xét sau khi triển khai. Khi người dùng hiểu rằng sự phân quyền luôn đi kèm trách nhiệm tham gia, blockchain sẽ được nhìn nhận thực tế hơn: không phải một hệ thống không có người quyết định, mà là một hệ thống đang thử nghiệm những cách mới để phân chia quyền quyết định trong môi trường số.
