Dusk nói “quyền riêng tư có thể kiểm toán”, vậy chiếc “chìa khóa vạn năng” nằm trong tay ai?
Lần đầu khi đọc về “quyền riêng tư có thể kiểm toán” của Dusk, tôi thấy thiết kế này thật khéo léo—dữ liệu giao dịch được mã hóa, không ai nhìn thấy được, nhưng khi cơ quan quản lý rút ra lệnh của tòa án, họ có thể mở bằng một chìa khóa đặc biệt. Nghe qua thì giống như đã tìm được sự cân bằng hoàn hảo giữa quyền riêng tư và sự giám sát. Nhưng rồi tôi nghĩ tới một vấn đề chí mạng: rốt cuộc, chiếc chìa khóa vạn năng ấy cuối cùng nằm trong tay ai? @Dusk
Theo Dusk, họ giao chìa khóa cho một “hội đồng giám sát”, quản lý bằng ví đa chữ ký để quyền lực được phân tán. Nhưng tôi đã suy nghĩ kỹ—hội đồng đó gồm những ai? Họ được chọn như thế nào? Do một quỹ đứng sẵn quyết định, hay do người nắm giữ bỏ phiếu? Các thành viên có phân bố ở nhiều khu vực pháp lý khác nhau không? Nếu Tòa án châu Âu ra lệnh kiểm toán, nhưng luật của quốc gia nơi một thành viên cư trú lại cấm phối hợp thì sao?
Tôi không tìm được câu trả lời cho những câu hỏi đó. Đau lòng hơn là: trong khuôn khổ pháp quyền hiện đại, bất kỳ cá nhân hay tổ chức nào có vị trí vật lý đều không thể thoát hoàn toàn khỏi sự ràng buộc của quyền tài phán. Các thành viên của hội đồng chắc chắn có quốc tịch, nơi cư trú, và tài sản—tất cả đều là “điểm yếu” theo luật. Một thành viên người Mỹ, bị chính phủ Mỹ đóng băng tài sản và đe dọa kiện tụng—anh ta có thể chịu đựng được bao lâu? Trước sức ép pháp lý, ý chí cá nhân thường rất mong manh. #dusk $DUSK
Có người có thể nói đa chữ ký có thể ngăn chặn việc lạm dụng. Nhưng tôi càng nghĩ càng thấy rằng, đa chữ ký chỉ bảo vệ ở “tầng kỹ thuật”, tránh để một cá nhân mở được. Khi nhiều khu vực pháp lý cùng lúc gây sức ép, thì cái gọi là bảo vệ đa chữ ký lại trở thành trò hề. Không phải là kỹ thuật bị bẻ khóa—mà là bản chất con người và thực tế pháp lý đã “đánh gãy” thiết kế.
Dusk cố gắng nắm đồng thời quyền riêng tư và sự giám sát, nhưng kết quả lại tạo cho bạn ảo tưởng về quyền riêng tư, trong khi vẫn không ngăn được sự tập trung quyền lực. Tôi không cho rằng đây là lỗi thiết kế, nhưng tôi tin rằng cơ chế này không an toàn như những gì họ quảng bá. Chiếc chìa khóa được phân tán về mặt kỹ thuật, nhưng trong thực tế vẫn bị kiểm soát bởi một số ít người. Chỉ cần có ai đó tham gia, thì luôn tồn tại sức ép pháp lý và chính trị ngoài đời thực. Thứ quyết định thật sự là chiếc chìa khóa cuối cùng thuộc về ai—đó mới là câu trả lời thực sự của thiết kế này. Tôi đang chờ một hệ thống phi tập trung thực sự, nơi không ai, không tổ chức, không quyền tài phán nào có thể cưỡng bức mở khóa quyền riêng tư.
“Chủ quyền tuân thủ” của Dusk—quyền chủ quyền của ai, sự tuân thủ của ai?
Dusk tự định vị mình là “chuỗi quyền riêng tư của các tổ chức được quản lý”. Ý là: bạn có thể thực hiện các giao dịch về quyền riêng tư, nhưng cơ quan quản lý có quyền xem. Về mặt thiết kế cơ chế, quyền này được giao cho “các nút chủ quyền” — nút tuân thủ nắm giữ khóa kiểm toán; khi cơ quan quản lý yêu cầu xem, nút sẽ giải mã và cung cấp dữ liệu. Nghe giống như đã giải quyết được mâu thuẫn kinh điển giữa “quyền riêng tư vs tuân thủ”.
Nhưng tôi muốn hỏi một câu: ai sẽ quyết định “các nút chủ quyền” đó là những ai? Tiêu chuẩn tuyển chọn các nút chủ quyền là gì? Nếu các nút chủ quyền bị tấn công, khóa bị rò rỉ, thì lịch sử giao dịch của tất cả người dùng có bị lộ hết không?
Tôi đã lật tài liệu của Dusk: các nút chủ quyền do Quỹ Dusk thẩm định và bổ nhiệm. Tiêu chí thẩm định là “tính tuân thủ và năng lực kỹ thuật” — không nêu chi tiết cụ thể. Nếu một cơ quan quản lý nào đó kiểm soát các nút chủ quyền, hoặc các nút chủ quyền bị ép phải giao nộp khóa, thì quyền riêng tư của người dùng còn lại được bao nhiêu trong khuôn khổ “chủ quyền tuân thủ” này?@Dusk
Điều khiến tôi đặc biệt quan tâm là: về mặt kỹ thuật, thiết kế này đúng là có thể đạt được “quyền riêng tư có thể kiểm toán” — giao dịch được che giấu, nhưng các nút kiểm toán có thể mở. Tuy nhiên, về bản chất, bạn không tin vào mật mã học mà bạn tin rằng các nút chủ quyền sẽ không lạm dụng quyền hạn. Bạn không tin vào toán học mà tin rằng các tổ chức sẽ không làm điều xấu.
Câu chuyện về sự tuân thủ của Dusk trước các khách hàng là tổ chức quả thực có sức cạnh tranh. “Chúng tôi có thể đưa bạn lên blockchain, đồng thời đáp ứng yêu cầu của cơ quan quản lý” — câu này chắc chắn đáng giá đối với các tổ chức tài chính có ngân sách tuân thủ dồi dào. Nhưng điều kiện để “đưa bạn lên blockchain” là: bạn phải chấp nhận rằng các nút chủ quyền có quyền xem giao dịch của bạn. Nếu bạn là khách hàng tổ chức, bạn thao tác trong “phòng kính”, còn khi cơ quan quản lý muốn xem thì họ có thể xem. Vậy “quyền riêng tư” rốt cuộc là quyền riêng tư cho ai? Quyền riêng tư của công chúng hay tính minh bạch cho cơ quan quản lý? Đúng là đó là thứ Dusk muốn bán. Nhưng “chủ quyền tuân thủ” bản thân lại đòi hỏi bạn phải tin vào một cơ quan có thẩm quyền. Cuối cùng, chuyện này rốt cuộc được xem là “quyền riêng tư” hay “lộ thông tin được kiểm soát” — còn tùy góc nhìn của bạn đứng về phía nào.#dusk $DUSK
Lỗ hổng PLONK của Dusk, lớp quyền riêng tư với vốn hóa 600.000 USD suýt bị một kẻ giả mạo bằng chứng đánh bại
Sau khi tôi đọc xong bản báo cáo an ninh mà OtterSec công bố vào ngày 30/04/2026, tôi đã ngẩn ra khoảng năm phút. Bộ xác minh của dusk-plonk chưa từng xác minh bốn cam kết đa thức mà người chứng đưa ra. Nói đơn giản, kẻ tấn công có thể giả mạo một bằng chứng zero-knowledge giả để đúc token DUSK mà không cần bất kỳ tài sản thực nào và chuyển các khoản thu nhập bất hợp pháp. Một giao thức quyền riêng tư được thiết kế cho thị trường tài chính được quản lý, nhưng lõi mật mã của nó lại có lỗ hổng cho phép kẻ tấn công tạo token “từ hư không”. Một hạ tầng được gắn mác là khiến các tổ chức yên tâm đưa lên chuỗi, lại tồn tại một khiếm khuyết mang tính nền tảng ở lớp quyền riêng tư.
Câu chuyện về tuân thủ trên whitepaper thì rất đẹp, nhưng trong mã thì suýt có một “cửa hậu” để đúc vô hạn. Bạn có thể nói lỗ hổng đã được khắc phục. Nhưng lỗ hổng xuất hiện ở phần xác minh trong lớp quyền riêng tư, bản thân nó đã là một cái tát vào định vị “ưu tiên quyền riêng tư”. Một dự án kiếm cơm nhờ ZK, mà hiện thực ZK lại gặp vấn đề. Sau khi đọc báo cáo, câu hỏi đầu tiên xuất hiện trong đầu tôi là—một chuỗi quyền riêng tư dựa vào ZK, nếu hiện thực ZK có thể mắc kiểu lỗ hổng như vậy, thì còn điều gì có thể không bị lỗi? Dusk đã giảm khá nhiều so với đỉnh; quy đổi 600.000 USD theo giá lúc đó, nếu kẻ tấn công dùng lỗ hổng này để đúc một lượng lớn token, giá có thể bị đập thẳng xuống. @Dusk
Tôi tìm được một báo cáo kiểm toán của Dusk và lướt qua. Đơn vị kiểm toán là Dust Labs, phạm vi kiểm toán chỉ bao phủ một số module nhất định, vậy logic xác minh của dusk-plonk có nằm trong phạm vi kiểm toán không? Tôi không tìm thấy mô tả rõ ràng. Nếu mã nguồn lớp quyền riêng tư cốt lõi của một dự án bị bỏ sót trong đợt kiểm toán, hoặc bản thân phạm vi kiểm toán không bao phủ đến, thì giá trị của báo cáo kiểm toán đó cần phải được đánh giá lại. Kiểm toán không phải làm một lần là xong.
Tôi không nói rằng Dusk không đáng tin, nhưng một dự án viết chữ “quyền riêng tư” ngay trong tên gọi, mà ở lớp xác minh ZK cốt lõi lại tồn tại lỗ hổng nền tảng như vậy, thì tôi rất khó thuyết phục bản thân tiếp tục nắm giữ. Hãy chờ sau khi lõi mật mã được xác thực qua thêm vài vòng. Tạm thời tôi sẽ đưa nó trở lại danh sách theo dõi, xem liệu sau đó có còn công bố thêm lỗ hổng mới không. Nếu cùng một module lại tiếp tục gặp vấn đề lần nữa, thì không chỉ là vấn đề kỹ thuật nữa—mà là vấn đề quy trình. #dusk $DUSK
Cơ chế tịch thu (slashing) của Babylon: lỗi bug code có thể đốt cháy BTC của bạn vĩnh viễn
Sáng kiến quan trọng nhất của Babylon chính là cơ chế tịch thu. Trên Bitcoin, việc triển khai slashing trước đây chưa từng ai làm. Về mặt kỹ thuật thì đúng là đi trước, nhưng vấn đề cũng nằm ở chính kỹ thuật đó. Trong báo cáo xếp hạng rủi ro của Hindenrank có một câu mà tôi đã đọc đi đọc lại vài lần: “Slashing is enforced cryptographically — an honest software bug can burn your BTC irreversibly.” Một lỗi phần mềm vô hại cũng có thể đốt cháy BTC của bạn vĩnh viễn. Không phải tấn công của hacker, không phải hành vi xấu cố ý, mà là do code của trình xác thực mà bạn đã chọn bị lỗi, vô tình kích hoạt điều kiện slashing, và thế là BTC của bạn mất luôn. Kinh khủng hơn nữa là nếu nhiều trình xác thực chạy cùng một bản client có bug, chỉ một lỗi cũng có thể đồng thời đốt cháy BTC của tất cả mọi người. Trong hệ thống này, slashing không phải “làm điều xấu thì bị phạt”, mà là “có lỗi thì bị phạt”. @BabylonLabs_io
Babylon dùng EOTS (chữ ký dùng một lần có thể trích xuất) làm nền tảng mật mã cho việc tịch thu. Nếu trình xác thực ký đôi (double sign), khóa riêng (private key) sẽ bị lộ và kẻ tấn công có thể lấy thẳng phần BTC tương ứng. Cơ chế này trong bài báo nhìn rất đẹp—làm điều sai thì bị phạt, logic khép kín. Nhưng trong thế giới thực, bug code, điều kiện tranh chấp khi nút khởi động lại (node restart), độ trễ mạng… đều có thể khiến một trình xác thực vô tội vô tình kích hoạt ký đôi. Và chỉ trong khoảnh khắc đó, vài chục triệu đô la BTC bị hủy vĩnh viễn. Bitcoin không phải Ethereum—không có cơ chế rollback, không có bỏ phiếu quản trị để khôi phục tài sản bị slashing. Lỡ là lỡ, đốt là đốt. Đốt xong thì không ai có thể giúp bạn lấy lại.
Hiện tại, cơ chế slashing chưa có bất kỳ tiền lệ nào được kiểm chứng qua thực chiến. Lần triển khai đầu tiên lên Bitcoin, một hệ thống tịch thu lần đầu tiên “cầm trịch” lượng tài sản hàng chục tỷ đô la, lần đầu tiên đối mặt với kẻ tấn công thực sự. Ba cái “lần đầu tiên” này chồng lên nhau khiến tôi không quá yên tâm. Cơ chế slashing của Babylon trong bài báo viết rất đẹp, nhưng giữa bài báo và mạng chính (mainnet) là cả một dây chuyền sản xuất. Cho đến khi code đã được kiểm chứng, các tình huống biên (edge cases) đã được rà soát, tôi sẽ không nhét BTC vào đó. Không phải vì không tin kỹ thuật, mà vì không tin vào “vũ khí mới” khi chưa có bất kỳ thử nghiệm nào trước khi ra chiến trường thật. Đợi khi nó chạy trơn tru rồi hãy tính. Một hệ thống mà chưa từng xảy ra sự kiện slashing nào lại—ngược lại—mới là nguy hiểm nhất. #baby $BABY
Lợi suất năm của việc thế chấp BTC Babylon hiện vào khoảng 1%. Thời gian khóa từ 7 đến 90 ngày tùy trường hợp. Lợi nhuận được trả bằng BABY.
Tôi đã nhìn con số này và suy nghĩ rất lâu. Lợi suất năm 1%, trong thời gian khóa thì BTC không thể di chuyển. Nếu trong khoảng thời gian đó BTC tăng 5%, thì chi phí cơ hội của bạn là 4%. Nếu tăng 10%, thì chi phí cơ hội là 9%. Biến động của BTC trung bình năm ở mức trên 50%, việc tăng 5% trong 7 ngày không phải chuyện hiếm. Tôi hỏi một người đã nắm giữ BTC hơn 5 năm: “Để lấy 1% lợi suất năm, bạn có sẵn sàng khóa BTC trong 3 tháng không?” Anh ấy nói: “Không. BTC tăng một ngày là đã hơn 1% rồi. Khóa vào thì dù tăng cũng không bán được.”
Quan trọng hơn, lợi nhuận được trả bằng BABY. Nếu trong thời gian thế chấp, giá BABY giảm thì lợi nhuận thực tế của bạn có thể sẽ âm. Từ khi BABY lên sàn đến nay đã giảm bao nhiêu? Tự xem biểu đồ K đi. Lợi suất 1%/năm, trừ đi phần giảm giá của BABY, thì bạn còn nhận lại được bao nhiêu? Chẳng ai tính cả. @BabylonLabs_io
Babylon đúng là đã giải quyết vấn đề cầu nối xuyên chuỗi—không cần bọc (wrap), không cần “bridge”, không cần đưa BTC cho bất kỳ ai. BTC vẫn luôn nằm trên mainnet Bitcoin, nên mức độ an toàn chắc chắn cao hơn một bậc so với đa số giải pháp BTCFi. Nhưng cái giá phải trả cho độ an toàn chính là việc bị khóa. Bạn khóa BTC vào đó, kiếm 1% bằng BABY, đồng thời gánh rủi ro bỏ lỡ khi giá BTC tăng, rủi ro mất giá khi giá BABY giảm, và rủi ro hợp đồng thông minh nếu giao thức có sự cố. Ba loại rủi ro đổi lấy lợi suất 1%. Tôi hỏi một người làm chiến lược DeFi: “Tỷ lệ rủi ro–lợi nhuận này, anh thấy có đáng không?” Anh ấy nói: “Không đáng. Lợi suất 1% thì không chạy kịp lạm phát, lại còn bị khóa. Thế thì thà không thế chấp.”
Lợi suất 1%, trong thời gian khóa không được động đến, lợi nhuận được trả bằng BABY. Ba điều kiện chồng lên nhau như vậy, thì tính thế nào cũng không ra được số lời. Trừ khi bạn vốn dĩ chẳng định bán, và cũng không quan tâm BABY rơi tới đâu. Nếu không, thế chấp là dùng một phần “khóa chắc chắn” để đổi lấy một lợi nhuận “không chắc chắn”. Sau khi tôi tính xong khoản này, tôi quyết định tiếp tục để BTC trong ví lạnh. Không thế chấp thì ít nhất sẽ không bị lỗ.
Đợi khi lợi nhuận được trả bằng BTC, thời gian khóa được rút ngắn xuống còn trong vài ngày, và giá BABY ổn định trở lại thì tôi quay lại tính lại từ đầu. #baby $BABY