Sau khi xem quy trình DIP của Dusk, tôi vẫn không tìm được người “chốt quyết định” đó
Bánh thịt rớt giá chút rồi, nhưng BTC vẫn còn tương lai!
Tôi lật lại tài liệu hướng dẫn DIP của Dusk, cái sự chỉn chu gọn gàng kia đúng là khiến người ta phải nể. Từ động cơ đến khâu kiểm thử, từ khả năng tương thích đến tác động an toàn—mọi thứ từ lớn đến nhỏ đều được yêu cầu theo một cấu trúc rất chặt chẽ. Ít nhất thì nó cho thấy nhóm có thái độ kính trọng đối với quá trình tiến hóa kỹ thuật, chứ không phải một nhóm “lắp ghép” làm theo kiểu chụp mũ bằng cảm tính. Nhưng sau khi đọc xong, tôi lại hỏi một câu với không khí: chạy được quy trình này rồi thì rốt cuộc ai là người có quyền quyết?
Trong tài liệu có cụm “cộng đồng đạt được sự đồng thuận”. Nghe giống câu “chúng ta bàn thêm ở cuộc họp sau” trong phòng họp—dân chủ đấy, nhưng bạn không biết sau khi tan họp, ai là người ký bút ở quyết định cuối cùng. Là nhà phát triển cốt lõi chịu trách nhiệm merge code sao? Người đó tập trung vào chất lượng code và rủi ro kỹ thuật, có thể họ nghĩ rằng việc bỏ phiếu trên chuỗi chỉ là người ngoài hướng dẫn người trong. Hay là giao cho người vận hành node? Cái này thì đúng tinh thần blockchain: nhưng tiếng nói của những “ông lớn” có số lượng stake thì vốn dĩ lớn hơn tiếng của các nhà đầu tư lẻ, xét ra vẫn là cuộc giằng co giữa sức mạnh tính toán và vốn. Còn phần bỏ phiếu của người nắm giữ $DUSK —nghe thì “Web3” nhất, nhưng đối với những lỗ hổng bảo mật kiểu AEGIS cần phản ứng cực nhanh, đợi đến khi kết quả bỏ phiếu ra thì hacker có khi đã rút tiền rảnh tay được vài vòng rồi.
Nói thẳng ra, đây không phải vấn đề không tin ai. Bạn phải công khai quyền xác định thế nào là “khẩn cấp”, quyền cân nhắc đánh đổi thế nào là “tương thích”, và cả lộ trình ra quyết định cho “rollback”. Minh bạch quản trị không phải là treo bản nháp đề xuất lên là xong, mà là để mọi người thấy rõ: từ lúc một đề xuất nảy ra đến khi đi vào mainnet, ở giữa những ngã rẽ đó, nhóm nào đang cầm tay lái—căn cứ của họ là gì, động cơ của họ là gì. Điều này không liên quan đến việc mã nguồn có mở hay không. Đây là việc “mở bản đồ quyền lực”.
Vì vậy đừng vội hô khẩu hiệu quản trị phi tập trung. Hãy làm trước: biến các bài thảo luận của vài DIP đầu tiên, các điểm tranh cãi trọng yếu, và bản ghi chi tiết về việc cuối cùng có được chấp nhận hay không thành một trang có thể công khai tìm kiếm. Đến một ngày tôi có thể đi theo đường link, xem một bản vá then chốt đã được mài giũa từ những cuộc tranh cãi như thế nào, và ai là người bấm nút merge vào thời khắc cuối cùng—thì tôi mới tin mô hình quản trị này thật sự đang tiến hóa, chứ không chỉ là một cuốn mô tả quy trình viết rất chỉn chu. Có hay không? @Dusk $DUSK #dusk
Bánh thịt rớt giá chút rồi, nhưng BTC vẫn còn tương lai!
Tôi lật lại tài liệu hướng dẫn DIP của Dusk, cái sự chỉn chu gọn gàng kia đúng là khiến người ta phải nể. Từ động cơ đến khâu kiểm thử, từ khả năng tương thích đến tác động an toàn—mọi thứ từ lớn đến nhỏ đều được yêu cầu theo một cấu trúc rất chặt chẽ. Ít nhất thì nó cho thấy nhóm có thái độ kính trọng đối với quá trình tiến hóa kỹ thuật, chứ không phải một nhóm “lắp ghép” làm theo kiểu chụp mũ bằng cảm tính. Nhưng sau khi đọc xong, tôi lại hỏi một câu với không khí: chạy được quy trình này rồi thì rốt cuộc ai là người có quyền quyết?
Trong tài liệu có cụm “cộng đồng đạt được sự đồng thuận”. Nghe giống câu “chúng ta bàn thêm ở cuộc họp sau” trong phòng họp—dân chủ đấy, nhưng bạn không biết sau khi tan họp, ai là người ký bút ở quyết định cuối cùng. Là nhà phát triển cốt lõi chịu trách nhiệm merge code sao? Người đó tập trung vào chất lượng code và rủi ro kỹ thuật, có thể họ nghĩ rằng việc bỏ phiếu trên chuỗi chỉ là người ngoài hướng dẫn người trong. Hay là giao cho người vận hành node? Cái này thì đúng tinh thần blockchain: nhưng tiếng nói của những “ông lớn” có số lượng stake thì vốn dĩ lớn hơn tiếng của các nhà đầu tư lẻ, xét ra vẫn là cuộc giằng co giữa sức mạnh tính toán và vốn. Còn phần bỏ phiếu của người nắm giữ $DUSK —nghe thì “Web3” nhất, nhưng đối với những lỗ hổng bảo mật kiểu AEGIS cần phản ứng cực nhanh, đợi đến khi kết quả bỏ phiếu ra thì hacker có khi đã rút tiền rảnh tay được vài vòng rồi.
Nói thẳng ra, đây không phải vấn đề không tin ai. Bạn phải công khai quyền xác định thế nào là “khẩn cấp”, quyền cân nhắc đánh đổi thế nào là “tương thích”, và cả lộ trình ra quyết định cho “rollback”. Minh bạch quản trị không phải là treo bản nháp đề xuất lên là xong, mà là để mọi người thấy rõ: từ lúc một đề xuất nảy ra đến khi đi vào mainnet, ở giữa những ngã rẽ đó, nhóm nào đang cầm tay lái—căn cứ của họ là gì, động cơ của họ là gì. Điều này không liên quan đến việc mã nguồn có mở hay không. Đây là việc “mở bản đồ quyền lực”.
Vì vậy đừng vội hô khẩu hiệu quản trị phi tập trung. Hãy làm trước: biến các bài thảo luận của vài DIP đầu tiên, các điểm tranh cãi trọng yếu, và bản ghi chi tiết về việc cuối cùng có được chấp nhận hay không thành một trang có thể công khai tìm kiếm. Đến một ngày tôi có thể đi theo đường link, xem một bản vá then chốt đã được mài giũa từ những cuộc tranh cãi như thế nào, và ai là người bấm nút merge vào thời khắc cuối cùng—thì tôi mới tin mô hình quản trị này thật sự đang tiến hóa, chứ không chỉ là một cuốn mô tả quy trình viết rất chỉn chu. Có hay không? @Dusk $DUSK #dusk