bro_sf
419 Bài đăng
bro_sf
Web3 Explorer 🌐 Gas Research 📈 On-Chain Analysis 🔍 | BTC & Altcoins 💎 Research & Education 📚 Insights 💡
Người nắm giữ BMT
Trader tần suất cao
{thời gian} năm
282 Đang theo dõi
89 Người theo dõi
256 Đã thích
Bài đăng
Tất cả
Trích dẫn
Xem bản dịch
#dusk $DUSK @Dusk
Previously, I thought a token only needed to do one thing well: move when told to. Everything else felt like an application's problem.
Looking at what a security actually has to do over its life, I found three moments where a token has to refuse instead.
The first is refusing a second account. An approved holder is not supposed to hold positions in several places, because a shareholder register has to answer one question cleanly: how much does this person own. Voting weight, reporting thresholds and ownership limits all break if the same person quietly sits in five wallets. That runs directly against the habit the rest of crypto has trained into us, where separating addresses is simply good practice.
The second is refusing your money. Some instruments cap how much a single holder may take, and that cap is written into the legal documents rather than invented by a developer. If it lives only in a policy, someone checks afterwards and unwinds the breach. If it lives in the asset, the transfer never completes and there is nothing to unwind.
The third is refusing to exist. A bond matures. A fund unit is redeemed. The instrument is not passed to a final owner and left there — it is settled and then destroyed, because the obligation behind it has been discharged.
What I find notable is that all three are absent from most tokenization explanations, which stop at issuance and trading as though those were the interesting parts.
What I cannot judge is how the third one behaves when the payment happens off-chain and the destruction happens on-chain. That seems like the easiest place for two records to drift apart.
From here I stopped reading a token as a container for value. For these assets it is closer to a rulebook that happens to be transferable.
Previously, I thought a token only needed to do one thing well: move when told to. Everything else felt like an application's problem.
Looking at what a security actually has to do over its life, I found three moments where a token has to refuse instead.
The first is refusing a second account. An approved holder is not supposed to hold positions in several places, because a shareholder register has to answer one question cleanly: how much does this person own. Voting weight, reporting thresholds and ownership limits all break if the same person quietly sits in five wallets. That runs directly against the habit the rest of crypto has trained into us, where separating addresses is simply good practice.
The second is refusing your money. Some instruments cap how much a single holder may take, and that cap is written into the legal documents rather than invented by a developer. If it lives only in a policy, someone checks afterwards and unwinds the breach. If it lives in the asset, the transfer never completes and there is nothing to unwind.
The third is refusing to exist. A bond matures. A fund unit is redeemed. The instrument is not passed to a final owner and left there — it is settled and then destroyed, because the obligation behind it has been discharged.
What I find notable is that all three are absent from most tokenization explanations, which stop at issuance and trading as though those were the interesting parts.
What I cannot judge is how the third one behaves when the payment happens off-chain and the destruction happens on-chain. That seems like the easiest place for two records to drift apart.
From here I stopped reading a token as a container for value. For these assets it is closer to a rulebook that happens to be transferable.
#dusk $DUSK @Dusk
Trước đây, tôi cho rằng việc có nhiều ví chỉ là cách mà crypto vận hành. Muốn tạo bao nhiêu thì tạo, chia tách thế nào cũng được, chẳng ai hỏi “vì sao”.
Khi đọc về cách mô hình tài sản được quản lý của Dusk được thiết kế, tôi phát hiện có một ràng buộc đi thẳng ngược lại thói quen đó.
Đối với một tài sản, người nắm giữ đã được phê duyệt trước sẽ không được phép nắm giữ quá một tài khoản. Không phải vì ai đó cố tình hạn chế chỉ để hạn chế, mà vì sổ đăng ký cổ đông phải trả lời một câu hỏi thật rõ ràng: người này sở hữu bao nhiêu?
Nếu cùng một người được phê duyệt có thể âm thầm nắm một vị thế ở năm nơi khác nhau, thì mọi câu hỏi được xây dựng trên khái niệm sở hữu sẽ trở nên mơ hồ. Quyền biểu quyết. Ngưỡng báo cáo. Giới hạn về việc mỗi người nắm giữ riêng lẻ được phép kiểm soát bao nhiêu.
Điều tôi thấy đặc biệt đáng chú ý là đây lại là điều ngược với những gì phần còn lại của crypto tối ưu hóa. Chúng ta coi việc tách địa chỉ là quyền riêng tư và là thực hành tốt. Với một công cụ được quản lý, sự tách biệt tương tự lại là một khiếm khuyết.
Vì vậy thiết kế phải dung hòa hai thứ đang kéo chúng đi theo hai hướng khác nhau. Người nắm giữ vẫn cần có tính bảo mật trước công chúng. Sổ đăng ký vẫn phải không mơ hồ về danh tính và quy mô.
Tôi không chắc hai yếu tố đó sẽ bám dính với nhau tốt đến mức nào khi khối lượng giao dịch thực sự tăng lên, và tôi cũng chưa thấy điều này được kiểm chứng công khai.
Nhưng từ đây, tôi đã dừng việc cho rằng một ví chỉ là một “bình chứa” trung tính. Với một số loại tài sản, chiếc ví là một phần của hồ sơ pháp lý, và các quy tắc áp dụng cho nó đến từ nơi khác chứ không chỉ là phần mềm.
Trước đây, tôi cho rằng việc có nhiều ví chỉ là cách mà crypto vận hành. Muốn tạo bao nhiêu thì tạo, chia tách thế nào cũng được, chẳng ai hỏi “vì sao”.
Khi đọc về cách mô hình tài sản được quản lý của Dusk được thiết kế, tôi phát hiện có một ràng buộc đi thẳng ngược lại thói quen đó.
Đối với một tài sản, người nắm giữ đã được phê duyệt trước sẽ không được phép nắm giữ quá một tài khoản. Không phải vì ai đó cố tình hạn chế chỉ để hạn chế, mà vì sổ đăng ký cổ đông phải trả lời một câu hỏi thật rõ ràng: người này sở hữu bao nhiêu?
Nếu cùng một người được phê duyệt có thể âm thầm nắm một vị thế ở năm nơi khác nhau, thì mọi câu hỏi được xây dựng trên khái niệm sở hữu sẽ trở nên mơ hồ. Quyền biểu quyết. Ngưỡng báo cáo. Giới hạn về việc mỗi người nắm giữ riêng lẻ được phép kiểm soát bao nhiêu.
Điều tôi thấy đặc biệt đáng chú ý là đây lại là điều ngược với những gì phần còn lại của crypto tối ưu hóa. Chúng ta coi việc tách địa chỉ là quyền riêng tư và là thực hành tốt. Với một công cụ được quản lý, sự tách biệt tương tự lại là một khiếm khuyết.
Vì vậy thiết kế phải dung hòa hai thứ đang kéo chúng đi theo hai hướng khác nhau. Người nắm giữ vẫn cần có tính bảo mật trước công chúng. Sổ đăng ký vẫn phải không mơ hồ về danh tính và quy mô.
Tôi không chắc hai yếu tố đó sẽ bám dính với nhau tốt đến mức nào khi khối lượng giao dịch thực sự tăng lên, và tôi cũng chưa thấy điều này được kiểm chứng công khai.
Nhưng từ đây, tôi đã dừng việc cho rằng một ví chỉ là một “bình chứa” trung tính. Với một số loại tài sản, chiếc ví là một phần của hồ sơ pháp lý, và các quy tắc áp dụng cho nó đến từ nơi khác chứ không chỉ là phần mềm.
🚨 Cập nhật Phân phối TMX — Ngày Nhận Phần Thưởng Đã Đến
Chiến dịch TermMax Booster Campaign đã chính thức bước vào giai đoạn phân phối, và hôm nay là ngày mà những người tham gia đã chờ đợi.
⏰ Việc nhận thưởng TMX sẽ mở vào hôm nay lúc 4:00 PM (Giờ Bangladesh).
Trong bản cập nhật chiến dịch, có hai nhóm phần thưởng chính:
🎁 Bốc thăm may mắn TermMax
→ 21.25 TMX cho mỗi người chiến thắng
🏆 Giải thưởng lớn TermMax
→ 300 TMX cho mỗi người dùng đủ điều kiện
Đối với người dùng đang xem trang phần thưởng của Binance Web3 Wallet, phần phân bổ hiện có thể đang hiển thị dưới mục “Pending TGE or Vesting” (Chờ TGE hoặc Chờ Vesting). Điều đó có nghĩa là nhìn thấy 0 / TMX đã phân bổ không nhất thiết có nghĩa là phần thưởng đã mất — phân bổ đã được hiển thị, nhưng nó chưa chuyển sang giai đoạn có thể nhận/đã nhận.
Trong bảng điều khiển phần thưởng được hiển thị tại đây, ví dụ, có thể thấy hai lượt phân bổ:
• 21.25 TMX
• 306.74846 TMX
Cả hai vẫn đang được đánh dấu là Pending TGE or Vesting.
Vì vậy, điều quan trọng bây giờ là đơn giản: hãy kiểm tra trang phần thưởng Booster sau khi khung thời gian mở nhận đã bắt đầu. Nếu phần thưởng của bạn trở thành “Instant Claim” (Nhận ngay), bạn sẽ có thể nhận trực tiếp. Nếu thay vào đó hiển thị ngày nhận / trạng thái vesting, hãy làm theo ngày được hiển thị cho phần phân bổ của bạn.
Hôm nay thực chất là thời điểm chuyển từ “reward confirmed” (xác nhận phần thưởng) → “reward distribution” (phân phối phần thưởng). 👀
Hãy kiểm tra Binance Web3 Wallet của bạn và đừng nhầm “Pending” (chờ) với “Missed” (bỏ lỡ).
$TMX #TermMax
Chiến dịch TermMax Booster Campaign đã chính thức bước vào giai đoạn phân phối, và hôm nay là ngày mà những người tham gia đã chờ đợi.
⏰ Việc nhận thưởng TMX sẽ mở vào hôm nay lúc 4:00 PM (Giờ Bangladesh).
Trong bản cập nhật chiến dịch, có hai nhóm phần thưởng chính:
🎁 Bốc thăm may mắn TermMax
→ 21.25 TMX cho mỗi người chiến thắng
🏆 Giải thưởng lớn TermMax
→ 300 TMX cho mỗi người dùng đủ điều kiện
Đối với người dùng đang xem trang phần thưởng của Binance Web3 Wallet, phần phân bổ hiện có thể đang hiển thị dưới mục “Pending TGE or Vesting” (Chờ TGE hoặc Chờ Vesting). Điều đó có nghĩa là nhìn thấy 0 / TMX đã phân bổ không nhất thiết có nghĩa là phần thưởng đã mất — phân bổ đã được hiển thị, nhưng nó chưa chuyển sang giai đoạn có thể nhận/đã nhận.
Trong bảng điều khiển phần thưởng được hiển thị tại đây, ví dụ, có thể thấy hai lượt phân bổ:
• 21.25 TMX
• 306.74846 TMX
Cả hai vẫn đang được đánh dấu là Pending TGE or Vesting.
Vì vậy, điều quan trọng bây giờ là đơn giản: hãy kiểm tra trang phần thưởng Booster sau khi khung thời gian mở nhận đã bắt đầu. Nếu phần thưởng của bạn trở thành “Instant Claim” (Nhận ngay), bạn sẽ có thể nhận trực tiếp. Nếu thay vào đó hiển thị ngày nhận / trạng thái vesting, hãy làm theo ngày được hiển thị cho phần phân bổ của bạn.
Hôm nay thực chất là thời điểm chuyển từ “reward confirmed” (xác nhận phần thưởng) → “reward distribution” (phân phối phần thưởng). 👀
Hãy kiểm tra Binance Web3 Wallet của bạn và đừng nhầm “Pending” (chờ) với “Missed” (bỏ lỡ).
$TMX #TermMax
#dusk $DUSK @Dusk
Trước đây, tôi cho rằng nếu bạn nắm giữ một token đại diện cho một trái phiếu thì bạn sở hữu trái phiếu đó. Token nằm trên chuỗi, khóa của bạn kiểm soát token, vì vậy câu hỏi về sở hữu dường như đã được giải quyết.
Nhìn kỹ hơn về cách các tài sản được quản lý (regulated assets) được cho là hoạt động trên một chuỗi như Dusk, tôi bắt đầu nhận ra rằng mình đã bỏ qua một bước.
Sở hữu một công cụ tài chính là một sự thật pháp lý, không phải một vấn đề kỹ thuật. Ở đâu đó sẽ có một sổ đăng ký, một văn bản pháp lý, hoặc một thực thể mà hồ sơ của họ quyết định ai là người mà pháp luật coi là chủ sở hữu. Một token có thể đại diện cho điều đó. Nó cũng có thể chính là sổ đăng ký đó. Hai cách sắp xếp này rất khác nhau, nhưng từ bên ngoài chúng trông giống hệt nhau.
Điều khiến tôi chú ý là đây chính là công việc thực sự trong token hóa. Không phải là di chuyển token nhanh chóng, mà là làm cho bản ghi trên chuỗi và bản ghi được pháp luật công nhận trở thành cùng một bản ghi, để không bao giờ có khoảnh khắc mà sổ cái nói một điều còn pháp luật nói một điều khác.
Nếu hai bên đó từng có bất đồng, pháp luật sẽ thắng, và token sẽ trở thành một biên nhận cho một thứ mà bạn có thể vẫn còn sở hữu hoặc cũng có thể không.
Tôi nghĩ điều này giải thích vì sao các dự án nghiêm túc trong lĩnh vực này thường tiến hành chậm và dành thời gian làm việc với các tổ chức được cấp phép hơn là với người dùng. Sự đồng bộ này không thể được xây dựng chỉ bằng một giao thức. Nó cần được những người duy trì hồ sơ pháp lý công nhận.
Tôi vẫn không thể biết từ bên ngoài rằng điều đó đã được hoàn thành đến mức nào trong từng trường hợp cụ thể, và tôi sẽ thận trọng với bất kỳ ai tuyên bố chắc chắn điều gì.
Nhưng từ đây, tôi đã ngừng đọc từ “được token hóa” theo nghĩa là “được sở hữu”. Nó có nghĩa là “được đại diện”. Việc “đại diện” và “sở hữu” có phải là cùng một thứ hay không phụ thuộc vào các cách sắp xếp diễn ra ở xa khỏi chuỗi.
Trước đây, tôi cho rằng nếu bạn nắm giữ một token đại diện cho một trái phiếu thì bạn sở hữu trái phiếu đó. Token nằm trên chuỗi, khóa của bạn kiểm soát token, vì vậy câu hỏi về sở hữu dường như đã được giải quyết.
Nhìn kỹ hơn về cách các tài sản được quản lý (regulated assets) được cho là hoạt động trên một chuỗi như Dusk, tôi bắt đầu nhận ra rằng mình đã bỏ qua một bước.
Sở hữu một công cụ tài chính là một sự thật pháp lý, không phải một vấn đề kỹ thuật. Ở đâu đó sẽ có một sổ đăng ký, một văn bản pháp lý, hoặc một thực thể mà hồ sơ của họ quyết định ai là người mà pháp luật coi là chủ sở hữu. Một token có thể đại diện cho điều đó. Nó cũng có thể chính là sổ đăng ký đó. Hai cách sắp xếp này rất khác nhau, nhưng từ bên ngoài chúng trông giống hệt nhau.
Điều khiến tôi chú ý là đây chính là công việc thực sự trong token hóa. Không phải là di chuyển token nhanh chóng, mà là làm cho bản ghi trên chuỗi và bản ghi được pháp luật công nhận trở thành cùng một bản ghi, để không bao giờ có khoảnh khắc mà sổ cái nói một điều còn pháp luật nói một điều khác.
Nếu hai bên đó từng có bất đồng, pháp luật sẽ thắng, và token sẽ trở thành một biên nhận cho một thứ mà bạn có thể vẫn còn sở hữu hoặc cũng có thể không.
Tôi nghĩ điều này giải thích vì sao các dự án nghiêm túc trong lĩnh vực này thường tiến hành chậm và dành thời gian làm việc với các tổ chức được cấp phép hơn là với người dùng. Sự đồng bộ này không thể được xây dựng chỉ bằng một giao thức. Nó cần được những người duy trì hồ sơ pháp lý công nhận.
Tôi vẫn không thể biết từ bên ngoài rằng điều đó đã được hoàn thành đến mức nào trong từng trường hợp cụ thể, và tôi sẽ thận trọng với bất kỳ ai tuyên bố chắc chắn điều gì.
Nhưng từ đây, tôi đã ngừng đọc từ “được token hóa” theo nghĩa là “được sở hữu”. Nó có nghĩa là “được đại diện”. Việc “đại diện” và “sở hữu” có phải là cùng một thứ hay không phụ thuộc vào các cách sắp xếp diễn ra ở xa khỏi chuỗi.
#dusk $DUSK @Dusk
Trước đây, tôi từng cho rằng một khi mã của blockchain đã được công khai mã nguồn, thì số lượng các nhóm triển khai nó không thực sự quan trọng. Giao thức là giao thức. Nếu các quy tắc được công khai, bất kỳ ai cũng có thể viết một phiên bản thứ hai, và thực tế là chưa ai cảm thấy cần đến chi tiết đó.
Sau đó tôi đi tìm phần mềm node của Dusk và phát hiện ra một điều đã thay đổi cách tôi đọc toàn bộ dự án.
Có một client duy nhất. Rusk, được viết bằng Rust. Bản cài đặt trước đó bằng Go vẫn còn trên GitHub, được công khai đánh dấu là đã không còn được duy trì/không khuyến nghị dùng và không còn cập nhật, kèm theo ghi chú hướng mọi người chuyển sang Rusk.
Vì vậy, mọi node trên mạng đều chạy cùng một mã.
Điều này đáng để suy ngẫm, vì phương án thay thế tồn tại vì một lý do. Ethereum khuyến khích nhiều client độc lập để khi có một lỗi ở một client thì chuỗi vẫn không bị dừng — các client còn lại vẫn tiếp tục tạo khối cho đến khi lỗi được khắc phục. Cách làm này tốn kém, chậm và được cố ý tạo ra sự trùng lặp. Sự trùng lặp chính là tính năng an toàn.
Với một client duy nhất, lỗi đồng thuận không dừng một phần. Nó là cả mạng.
Tôi không nghĩ đây là một sai lầm. Với một nhóm nhỏ, một client xuất sắc sẽ là cách sử dụng tài nguyên tốt hơn rất nhiều so với hai client trung bình, và Rusk đã được kiểm toán nhiều lần — thư viện node, lớp đồng thuận, giao thức mạng, tất cả đều được các công ty bên ngoài xem xét. Việc tập trung nguồn lực là một quyết định kỹ thuật có thể bảo vệ.
Nhưng nó cũng có nghĩa là một chuỗi được thiết kế cho thanh toán được quản lý hiện chưa có đa dạng hóa client. Thứ mà cơ sở hạ tầng thị trường truyền thống luôn ám ảnh — dự phòng, các nhánh hỏng độc lập, không có điểm đơn lẻ gây hỏng hóc — thì hiện vẫn chưa có.
Điều tôi không thể biết từ bên ngoài là liệu một phiên bản triển khai thứ hai có được lên kế hoạch hay không, hay liệu nó được xem là không cần thiết ở giai đoạn hiện tại của vòng đời mạng. Cả hai câu trả lời đều hợp lý. Tôi chỉ muốn biết đó là câu nào.
Từ đây, tôi ngừng đọc cụm “open source” như thể nó tự động đồng nghĩa với khả năng chống chịu. Mã nguồn mở là một lời mời. Đa dạng hóa client là điều xảy ra khi ai đó chấp nhận điều đó.
Trước đây, tôi từng cho rằng một khi mã của blockchain đã được công khai mã nguồn, thì số lượng các nhóm triển khai nó không thực sự quan trọng. Giao thức là giao thức. Nếu các quy tắc được công khai, bất kỳ ai cũng có thể viết một phiên bản thứ hai, và thực tế là chưa ai cảm thấy cần đến chi tiết đó.
Sau đó tôi đi tìm phần mềm node của Dusk và phát hiện ra một điều đã thay đổi cách tôi đọc toàn bộ dự án.
Có một client duy nhất. Rusk, được viết bằng Rust. Bản cài đặt trước đó bằng Go vẫn còn trên GitHub, được công khai đánh dấu là đã không còn được duy trì/không khuyến nghị dùng và không còn cập nhật, kèm theo ghi chú hướng mọi người chuyển sang Rusk.
Vì vậy, mọi node trên mạng đều chạy cùng một mã.
Điều này đáng để suy ngẫm, vì phương án thay thế tồn tại vì một lý do. Ethereum khuyến khích nhiều client độc lập để khi có một lỗi ở một client thì chuỗi vẫn không bị dừng — các client còn lại vẫn tiếp tục tạo khối cho đến khi lỗi được khắc phục. Cách làm này tốn kém, chậm và được cố ý tạo ra sự trùng lặp. Sự trùng lặp chính là tính năng an toàn.
Với một client duy nhất, lỗi đồng thuận không dừng một phần. Nó là cả mạng.
Tôi không nghĩ đây là một sai lầm. Với một nhóm nhỏ, một client xuất sắc sẽ là cách sử dụng tài nguyên tốt hơn rất nhiều so với hai client trung bình, và Rusk đã được kiểm toán nhiều lần — thư viện node, lớp đồng thuận, giao thức mạng, tất cả đều được các công ty bên ngoài xem xét. Việc tập trung nguồn lực là một quyết định kỹ thuật có thể bảo vệ.
Nhưng nó cũng có nghĩa là một chuỗi được thiết kế cho thanh toán được quản lý hiện chưa có đa dạng hóa client. Thứ mà cơ sở hạ tầng thị trường truyền thống luôn ám ảnh — dự phòng, các nhánh hỏng độc lập, không có điểm đơn lẻ gây hỏng hóc — thì hiện vẫn chưa có.
Điều tôi không thể biết từ bên ngoài là liệu một phiên bản triển khai thứ hai có được lên kế hoạch hay không, hay liệu nó được xem là không cần thiết ở giai đoạn hiện tại của vòng đời mạng. Cả hai câu trả lời đều hợp lý. Tôi chỉ muốn biết đó là câu nào.
Từ đây, tôi ngừng đọc cụm “open source” như thể nó tự động đồng nghĩa với khả năng chống chịu. Mã nguồn mở là một lời mời. Đa dạng hóa client là điều xảy ra khi ai đó chấp nhận điều đó.
Bằng chứng không kiến thức có tự động đồng nghĩa với 100% không cần tin tưởng?
Nghe có vẻ đúng như vậy. Không ai thấy bí mật, chỉ có toán học xác minh tính đúng đắn của bằng chứng.
Nhưng bài báo Citadel của Dusk lại chỉ ra một lớp phức tạp hơn nằm dưới PLONK: đó là giai đoạn “trusted setup” (thiết lập tin cậy).
Việc triển khai PLONK của Dusk chạy trên BLS12-381 và sử dụng KZG10 làm sơ đồ cam kết đa thức mặc định. KZG cần một Chuỗi Tham Chiếu Chung (Common Reference String) được tạo từ nhiễu ngẫu nhiên bí mật. Nếu “độc chất” đó tồn tại và lọt đến tay kẻ tấn công, giả định về tính đúng đắn (soundness) có thể bị phá vỡ.
Bài báo Citadel nói điều này rất thẳng thắn: tính ngẫu nhiên của thiết lập bị xâm phạm có thể cho phép giao dịch giả mạo và “những tổn thất tài chính cực lớn.” Với Citadel, hậu quả được nêu là giả mạo danh tính người dùng và sử dụng giấy phép của người khác.
Vậy “trusted setup” thực sự có nghĩa là gì?
Không phải việc tin tưởng một công ty duy nhất như thể họ có một “mật khẩu chủ”.
Một buổi lễ/phiên chạy (ceremony) cho phép nhiều người tham gia lần lượt thêm phần ngẫu nhiên của họ. Mỗi người sau đó hủy bỏ đóng góp bí mật của mình. Tính chất quan trọng là quá trình thiết lập vẫn an toàn nếu chỉ cần có ít nhất một người tham gia là trung thực và đã vĩnh viễn loại bỏ bí mật của mình.
Điều đó khiến tôi tự hỏi: ai đã tham gia vào buổi lễ của Dusk?
Thực ra, thông tin này còn được ghi chép nhiều hơn tôi tưởng.
Kho lưu trữ trusted-setup công khai của Dusk cho biết nó bắt đầu từ phản hồi Zcash Powers-of-Tau đã được xác minh #87, rồi sau đó thêm 15 người đóng góp của Dusk được liệt kê. Kho repo công khai các bản ghi đóng góp và các bước xác minh, trong khi Dusk cho biết kết quả sẽ được công bố để người khác có thể kiểm tra.
Điều đó không chứng minh rằng mọi giả định vận hành sẽ luôn đúng mãi về sau. Tôi vẫn muốn biết liệu các tham số dùng trong sản phẩm có khớp với bản ghi đã công bố hay không, và mối liên kết đó đã được kiểm tra độc lập trong thực tế như thế nào cho đến ngày nay.
Vì vậy, câu hỏi công bằng trở nên cụ thể hơn: liệu tôi có thể truy vết các tham số mật mã “live” trở lại buổi lễ có thể được xác minh công khai không?
Khi một dự án thừa nhận công khai một điểm yếu mật mã trong chính bài báo của mình, điều đó có tạo thêm niềm tin nhờ sự minh bạch — hay chỉ khiến bạn muốn biết thật chính xác rủi ro đó vẫn còn hiện hữu ở mức độ nào?
#dusk $DUSK @Dusk
Nghe có vẻ đúng như vậy. Không ai thấy bí mật, chỉ có toán học xác minh tính đúng đắn của bằng chứng.
Nhưng bài báo Citadel của Dusk lại chỉ ra một lớp phức tạp hơn nằm dưới PLONK: đó là giai đoạn “trusted setup” (thiết lập tin cậy).
Việc triển khai PLONK của Dusk chạy trên BLS12-381 và sử dụng KZG10 làm sơ đồ cam kết đa thức mặc định. KZG cần một Chuỗi Tham Chiếu Chung (Common Reference String) được tạo từ nhiễu ngẫu nhiên bí mật. Nếu “độc chất” đó tồn tại và lọt đến tay kẻ tấn công, giả định về tính đúng đắn (soundness) có thể bị phá vỡ.
Bài báo Citadel nói điều này rất thẳng thắn: tính ngẫu nhiên của thiết lập bị xâm phạm có thể cho phép giao dịch giả mạo và “những tổn thất tài chính cực lớn.” Với Citadel, hậu quả được nêu là giả mạo danh tính người dùng và sử dụng giấy phép của người khác.
Vậy “trusted setup” thực sự có nghĩa là gì?
Không phải việc tin tưởng một công ty duy nhất như thể họ có một “mật khẩu chủ”.
Một buổi lễ/phiên chạy (ceremony) cho phép nhiều người tham gia lần lượt thêm phần ngẫu nhiên của họ. Mỗi người sau đó hủy bỏ đóng góp bí mật của mình. Tính chất quan trọng là quá trình thiết lập vẫn an toàn nếu chỉ cần có ít nhất một người tham gia là trung thực và đã vĩnh viễn loại bỏ bí mật của mình.
Điều đó khiến tôi tự hỏi: ai đã tham gia vào buổi lễ của Dusk?
Thực ra, thông tin này còn được ghi chép nhiều hơn tôi tưởng.
Kho lưu trữ trusted-setup công khai của Dusk cho biết nó bắt đầu từ phản hồi Zcash Powers-of-Tau đã được xác minh #87, rồi sau đó thêm 15 người đóng góp của Dusk được liệt kê. Kho repo công khai các bản ghi đóng góp và các bước xác minh, trong khi Dusk cho biết kết quả sẽ được công bố để người khác có thể kiểm tra.
Điều đó không chứng minh rằng mọi giả định vận hành sẽ luôn đúng mãi về sau. Tôi vẫn muốn biết liệu các tham số dùng trong sản phẩm có khớp với bản ghi đã công bố hay không, và mối liên kết đó đã được kiểm tra độc lập trong thực tế như thế nào cho đến ngày nay.
Vì vậy, câu hỏi công bằng trở nên cụ thể hơn: liệu tôi có thể truy vết các tham số mật mã “live” trở lại buổi lễ có thể được xác minh công khai không?
Khi một dự án thừa nhận công khai một điểm yếu mật mã trong chính bài báo của mình, điều đó có tạo thêm niềm tin nhờ sự minh bạch — hay chỉ khiến bạn muốn biết thật chính xác rủi ro đó vẫn còn hiện hữu ở mức độ nào?
#dusk $DUSK @Dusk
Tôi chỉ đi tìm hiểu vì tôi đã cố gắng chuyển $DUSK qua cây cầu và cuối cùng lại đọc lịch sử sự cố.
Vào ngày 16 tháng 1 năm 2026, một kẻ tấn công đã truy cập được vào một ví ký được dùng bởi dịch vụ cầu của Dusk. @Dusk đã mô tả các hoạt động đáng ngờ liên quan đến một ví vận hành do nhóm quản lý, sau đó đã tắt và tái sử dụng các địa chỉ liên quan, tạm dừng cầu và phối hợp với Binance.
Họ cũng đã thêm một danh sách chặn người nhận vào Web Wallet để ngăn việc chuyển tiền tới các địa chỉ đã bị xâm nhập, liên quan đến lừa đảo hoặc bị trừng phạt.
Dusk cho biết đây không phải là sự cố đồng thuận hay một lỗ hổng khai thác ở cấp giao thức của DuskDS, và rằng tiền của người dùng không bị ảnh hưởng.
Tôi đọc thông tin đó theo hai cách.
Thứ nhất, phản hồi là một tín hiệu tích cực. Họ phát hiện hành vi bất thường, tắt đường đi rủi ro, công bố sự cố và sau đó công bố một bản phân tích chi tiết sau sự cố thay vì dừng ở "tiền an toàn."
Đối với một mạng ở giai đoạn sớm, điều đó rất quan trọng. Tốc độ ngăn chặn và mức độ rõ ràng trong công bố cũng là một phần của hồ sơ bảo mật.
Nhưng phần thứ hai thì khó bỏ qua hơn.
Cây cầu dựa vào một ví ký nằm trong một lộ trình vận hành do nhóm quản lý. Bài đăng sau sự cố của Dusk cho biết thiết kế ban đầu ưu tiên tốc độ và sự đơn giản, nhưng lại tập trung quá nhiều niềm tin vào một lộ trình duy nhất. Khi lộ trình ký đó bị xâm nhập, kẻ tấn công không cần phải bẻ gãy sự đồng thuận của Dusk.
Điều này lại có phần không khớp với định hướng "cầu gốc tin cậy không cần tin tưởng" của DuskDS ↔ DuskEVM. Một giao thức có thể phi tập trung, nhưng lớp hạ tầng phía trên nó vẫn có thể tồn tại các điểm nghẽn mang tính con người.
Về phía Dusk, họ đã làm đúng: cây cầu được thiết kế lại—việc ký được tách khỏi xử lý sự kiện, việc giải phóng quỹ được tách khỏi khâu nạp sự kiện, bề mặt phơi nhiễm của hot-wallet được giảm xuống, và dịch vụ được cô lập quyết liệt hơn.
Tài liệu hiện tại mô tả các luồng cầu giữa Dusk mainnet và BSC, nên việc gọi đợt tắt máy tháng 1 đó là "vẫn đã đóng" sẽ đã lỗi thời.
Vì vậy, câu hỏi thực sự là:
Tốc độ và mức độ chi tiết trong phản hồi của Dusk có xây dựng được thêm niềm tin, hay việc một lộ trình ký do một nhóm vận hành nắm giữ quá nhiều quyền lực vẫn là mối quan ngại lớn hơn?
#dusk $DUSK @Dusk
Vào ngày 16 tháng 1 năm 2026, một kẻ tấn công đã truy cập được vào một ví ký được dùng bởi dịch vụ cầu của Dusk. @Dusk đã mô tả các hoạt động đáng ngờ liên quan đến một ví vận hành do nhóm quản lý, sau đó đã tắt và tái sử dụng các địa chỉ liên quan, tạm dừng cầu và phối hợp với Binance.
Họ cũng đã thêm một danh sách chặn người nhận vào Web Wallet để ngăn việc chuyển tiền tới các địa chỉ đã bị xâm nhập, liên quan đến lừa đảo hoặc bị trừng phạt.
Dusk cho biết đây không phải là sự cố đồng thuận hay một lỗ hổng khai thác ở cấp giao thức của DuskDS, và rằng tiền của người dùng không bị ảnh hưởng.
Tôi đọc thông tin đó theo hai cách.
Thứ nhất, phản hồi là một tín hiệu tích cực. Họ phát hiện hành vi bất thường, tắt đường đi rủi ro, công bố sự cố và sau đó công bố một bản phân tích chi tiết sau sự cố thay vì dừng ở "tiền an toàn."
Đối với một mạng ở giai đoạn sớm, điều đó rất quan trọng. Tốc độ ngăn chặn và mức độ rõ ràng trong công bố cũng là một phần của hồ sơ bảo mật.
Nhưng phần thứ hai thì khó bỏ qua hơn.
Cây cầu dựa vào một ví ký nằm trong một lộ trình vận hành do nhóm quản lý. Bài đăng sau sự cố của Dusk cho biết thiết kế ban đầu ưu tiên tốc độ và sự đơn giản, nhưng lại tập trung quá nhiều niềm tin vào một lộ trình duy nhất. Khi lộ trình ký đó bị xâm nhập, kẻ tấn công không cần phải bẻ gãy sự đồng thuận của Dusk.
Điều này lại có phần không khớp với định hướng "cầu gốc tin cậy không cần tin tưởng" của DuskDS ↔ DuskEVM. Một giao thức có thể phi tập trung, nhưng lớp hạ tầng phía trên nó vẫn có thể tồn tại các điểm nghẽn mang tính con người.
Về phía Dusk, họ đã làm đúng: cây cầu được thiết kế lại—việc ký được tách khỏi xử lý sự kiện, việc giải phóng quỹ được tách khỏi khâu nạp sự kiện, bề mặt phơi nhiễm của hot-wallet được giảm xuống, và dịch vụ được cô lập quyết liệt hơn.
Tài liệu hiện tại mô tả các luồng cầu giữa Dusk mainnet và BSC, nên việc gọi đợt tắt máy tháng 1 đó là "vẫn đã đóng" sẽ đã lỗi thời.
Vì vậy, câu hỏi thực sự là:
Tốc độ và mức độ chi tiết trong phản hồi của Dusk có xây dựng được thêm niềm tin, hay việc một lộ trình ký do một nhóm vận hành nắm giữ quá nhiều quyền lực vẫn là mối quan ngại lớn hơn?
#dusk $DUSK @Dusk
Mỗi bài viết vào lúc hoàng hôn đều nhắc đến NPEX. Địa điểm được cấp phép của Hà Lan, việc phát hành đã được xác nhận trị giá €200M+, lượng nhà đầu tư 20.000+, quy trình hạ tầng cốt lõi cho thị trường.
Hầu như không ai trong số đó nhắc đến mối quan hệ đã bắt đầu như thế nào.
Hãy xem các liên kết truyền thông trên trang chủ của Dusk, và một trong số đó là bài viết của CoinDesk từ tháng 12/2020, cho biết Dusk Network đã nắm giữ khoảng 10% cổ phần tại sở giao dịch chứng khoán Hà Lan mà hiện nay họ đang hợp tác.
Điều đó làm thay đổi cách tôi đọc về quan hệ đối tác — theo cả hai chiều.
Cách đọc rộng lượng: đây là cách hạ tầng thực sự được xây dựng trong các thị trường được quản lý. Bạn không thể gọi lạnh một địa điểm được cấp phép và yêu cầu họ xây lại ngăn xếp thanh toán của mình dựa trên một L1 chưa được chứng minh của bạn. Việc nắm cổ phần sẽ đồng bộ lợi ích, đưa bạn vào cuộc trò chuyện về tuân thủ, và mua được nhiều năm kiên nhẫn mang tính tổ chức mà không một nhóm BD nào có thể mua được. Nó cũng giải thích vì sao lộ trình của Dusk có vẻ giống một kế hoạch hạ tầng thị trường hơn là một kế hoạch DeFi — họ đã ngồi ở phía đó của bàn từ năm 2020.
Cách đọc thận trọng: bằng chứng cốt lõi cho việc được áp dụng không hoàn toàn độc lập. Khi sự xác thực thể chế lớn nhất của một chuỗi đến từ một địa điểm mà nó đang nắm giữ cổ phần, thì “một tổ chức đã chọn chúng tôi” và “chúng tôi đã đầu tư vào một tổ chức” bắt đầu bị mờ đi.
Cả hai cách đọc đều có thể đúng cùng lúc, và tôi thà giữ cả hai suy nghĩ đó hơn là giả vờ rằng một trong hai là toàn bộ câu chuyện.
Cần lưu ý công bằng: báo cáo đó là từ năm 2020. Tôi chưa tìm thấy con số hiện tại, và các khoản nắm giữ có thể thay đổi. Nếu ai đó có một con số mới hơn, tôi thật lòng muốn được xem.
Khi một giao thức nắm cổ phần trong chính đối tác lớn nhất của mình — điều đó khiến nó giống như một cam kết dành cho bạn, hay như một dạng yếu hơn của bằng chứng về mức độ được áp dụng?
#dusk $DUSK @Dusk #NPEX
Hầu như không ai trong số đó nhắc đến mối quan hệ đã bắt đầu như thế nào.
Hãy xem các liên kết truyền thông trên trang chủ của Dusk, và một trong số đó là bài viết của CoinDesk từ tháng 12/2020, cho biết Dusk Network đã nắm giữ khoảng 10% cổ phần tại sở giao dịch chứng khoán Hà Lan mà hiện nay họ đang hợp tác.
Điều đó làm thay đổi cách tôi đọc về quan hệ đối tác — theo cả hai chiều.
Cách đọc rộng lượng: đây là cách hạ tầng thực sự được xây dựng trong các thị trường được quản lý. Bạn không thể gọi lạnh một địa điểm được cấp phép và yêu cầu họ xây lại ngăn xếp thanh toán của mình dựa trên một L1 chưa được chứng minh của bạn. Việc nắm cổ phần sẽ đồng bộ lợi ích, đưa bạn vào cuộc trò chuyện về tuân thủ, và mua được nhiều năm kiên nhẫn mang tính tổ chức mà không một nhóm BD nào có thể mua được. Nó cũng giải thích vì sao lộ trình của Dusk có vẻ giống một kế hoạch hạ tầng thị trường hơn là một kế hoạch DeFi — họ đã ngồi ở phía đó của bàn từ năm 2020.
Cách đọc thận trọng: bằng chứng cốt lõi cho việc được áp dụng không hoàn toàn độc lập. Khi sự xác thực thể chế lớn nhất của một chuỗi đến từ một địa điểm mà nó đang nắm giữ cổ phần, thì “một tổ chức đã chọn chúng tôi” và “chúng tôi đã đầu tư vào một tổ chức” bắt đầu bị mờ đi.
Cả hai cách đọc đều có thể đúng cùng lúc, và tôi thà giữ cả hai suy nghĩ đó hơn là giả vờ rằng một trong hai là toàn bộ câu chuyện.
Cần lưu ý công bằng: báo cáo đó là từ năm 2020. Tôi chưa tìm thấy con số hiện tại, và các khoản nắm giữ có thể thay đổi. Nếu ai đó có một con số mới hơn, tôi thật lòng muốn được xem.
Khi một giao thức nắm cổ phần trong chính đối tác lớn nhất của mình — điều đó khiến nó giống như một cam kết dành cho bạn, hay như một dạng yếu hơn của bằng chứng về mức độ được áp dụng?
#dusk $DUSK @Dusk #NPEX
#dusk $DUSK @Dusk Tôi đi tìm lịch sử kiểm toán của Dusk và cuối cùng lại đọc một thông báo rò rỉ.
Vào ngày 30 tháng 4 năm nay, OtterSec đã công bố một lỗi về tính đúng đắn (soundness bug) mà họ phát hiện trong dusk-plonk — hệ thống chứng minh (proof system) mà Dusk tự viết, thời điểm mà bài báo PLONK còn khá mới.
Tóm gọn: một giao dịch được Phoenix che chắn được “gating” (khóa/điều kiện) bởi đúng một thứ. Không phải chữ ký, không phải một lớp kiểm tra thứ hai — chỉ là một phán quyết duy nhất hợp lệ/không hợp lệ từ bộ thẩm định (proof verifier). Lưu ý quyền sở hữu, lưu ý tư cách thành viên, tính toàn vẹn số dư, tính đúng đắn của nullifier: tất cả những khẳng định đó đều tồn tại bên trong mạch (circuit), và nút chỉ hỏi: "chứng minh có được thẩm định hợp lệ không?"
Bốn giá trị trong chứng minh đã được người tạo (prover) cung cấp và được dùng trong phương trình thẩm định cuối cùng mà không bao giờ được đối chiếu với các cam kết (commitments) vốn đã nằm trong khóa xác minh (verifier key). Các cam kết đó tồn tại. Chỉ là chúng không được sử dụng cho bốn giá trị này.
Có hai điều khiến tôi suy nghĩ.
Thứ nhất, không có đường dự phòng thứ hai (no second net). Rusk kiểm tra những thứ như tính duy nhất của nullifier trước khi thẩm định, nhưng đối với các khẳng định nằm bên trong chứng minh thì không có lối thoát dự phòng. Chỉ cần một mắt xích hỏng, và mọi ràng buộc trong mạch sẽ sụp đồng loạt.
Thứ hai, ngăn xếp (stack) này đã được kiểm toán. dusk-plonk vào tháng 12/2023. Phoenix vào tháng 9/2024. Thư viện node của Rusk do Oak Security thực hiện vào tháng 9/2024. Giải thích riêng của OtterSec về lỗi này là một mô hình tinh thần: trong sách giáo khoa, các selector của PLONK là dữ liệu công khai của mạch, nên người rà soát nghĩ “phía verifier (verifier-side)” và chuyển qua — đi thẳng qua đúng chỗ mà phần hiện thực của Dusk đã bắt đầu tiêu thụ các giá trị do prover cung cấp.
Ghi nhận điều đúng: được báo cáo ngày 13/2, được thừa nhận và sửa ngày 14/2, phát hành công khai ngày 27/2. Một ngày để thừa nhận và vá là phản hồi nghiêm túc.
Nhưng nó đã làm thay đổi ý nghĩa của “đã được kiểm toán” đối với tôi. Kiểm toán là một bản chụp khoảnh khắc của sự chú ý, chứ không phải là bằng chứng về tính đúng đắn.
Khi bạn đọc rằng một chuỗi (chain) đã được kiểm toán — bạn có kiểm tra ai, khi nào, và thành phần nào được kiểm toán không?
Vào ngày 30 tháng 4 năm nay, OtterSec đã công bố một lỗi về tính đúng đắn (soundness bug) mà họ phát hiện trong dusk-plonk — hệ thống chứng minh (proof system) mà Dusk tự viết, thời điểm mà bài báo PLONK còn khá mới.
Tóm gọn: một giao dịch được Phoenix che chắn được “gating” (khóa/điều kiện) bởi đúng một thứ. Không phải chữ ký, không phải một lớp kiểm tra thứ hai — chỉ là một phán quyết duy nhất hợp lệ/không hợp lệ từ bộ thẩm định (proof verifier). Lưu ý quyền sở hữu, lưu ý tư cách thành viên, tính toàn vẹn số dư, tính đúng đắn của nullifier: tất cả những khẳng định đó đều tồn tại bên trong mạch (circuit), và nút chỉ hỏi: "chứng minh có được thẩm định hợp lệ không?"
Bốn giá trị trong chứng minh đã được người tạo (prover) cung cấp và được dùng trong phương trình thẩm định cuối cùng mà không bao giờ được đối chiếu với các cam kết (commitments) vốn đã nằm trong khóa xác minh (verifier key). Các cam kết đó tồn tại. Chỉ là chúng không được sử dụng cho bốn giá trị này.
Có hai điều khiến tôi suy nghĩ.
Thứ nhất, không có đường dự phòng thứ hai (no second net). Rusk kiểm tra những thứ như tính duy nhất của nullifier trước khi thẩm định, nhưng đối với các khẳng định nằm bên trong chứng minh thì không có lối thoát dự phòng. Chỉ cần một mắt xích hỏng, và mọi ràng buộc trong mạch sẽ sụp đồng loạt.
Thứ hai, ngăn xếp (stack) này đã được kiểm toán. dusk-plonk vào tháng 12/2023. Phoenix vào tháng 9/2024. Thư viện node của Rusk do Oak Security thực hiện vào tháng 9/2024. Giải thích riêng của OtterSec về lỗi này là một mô hình tinh thần: trong sách giáo khoa, các selector của PLONK là dữ liệu công khai của mạch, nên người rà soát nghĩ “phía verifier (verifier-side)” và chuyển qua — đi thẳng qua đúng chỗ mà phần hiện thực của Dusk đã bắt đầu tiêu thụ các giá trị do prover cung cấp.
Ghi nhận điều đúng: được báo cáo ngày 13/2, được thừa nhận và sửa ngày 14/2, phát hành công khai ngày 27/2. Một ngày để thừa nhận và vá là phản hồi nghiêm túc.
Nhưng nó đã làm thay đổi ý nghĩa của “đã được kiểm toán” đối với tôi. Kiểm toán là một bản chụp khoảnh khắc của sự chú ý, chứ không phải là bằng chứng về tính đúng đắn.
Khi bạn đọc rằng một chuỗi (chain) đã được kiểm toán — bạn có kiểm tra ai, khi nào, và thành phần nào được kiểm toán không?
Đã xác minh
Tôi đang đọc về một công cụ mã nguồn mở @Dusk được xây dựng để phát hiện tài liệu đã âm thầm ngừng khớp với mã nguồn. Thế là đương nhiên tôi thử ý tưởng này trên mục tiêu tiện nhất: tài liệu chính chủ của Dusk.
Công cụ đó là Pituitary. Được cấp phép MIT, chỉ là một tệp nhị phân, không cần Docker và không cần khóa API. Nó lập chỉ mục cho các bản đặc tả, tài liệu và hồ sơ quyết định của bạn, rồi gắn cờ các quyết định trùng lặp, tài liệu cũ, mã nguồn mâu thuẫn với đặc tả, sự trôi dạt thuật ngữ và chuỗi tác động khi một đặc tả thay đổi. Nó cũng đi kèm một máy chủ MCP, nên một tác nhân viết mã bằng AI sẽ có nhận thức về đặc tả ngay trong phiên thay vì tự tin xây dựng trên một quyết định đã bị đảo ngược từ nhiều tháng trước. Một nhóm blockchain xây dựng hạ tầng phát triển chung và lại đem tặng dưới giấy phép MIT thì không phải thứ tôi hay gặp. Ghi nhận nơi xứng đáng.
Rồi tôi đọc tiếp tài liệu. Bản ghi Network Updates của Dusk nêu thẳng rằng các giao dịch Phoenix mới bị từ chối trên mainnet sau khi khởi động lại Boreas, và Moonlight là mô hình giao dịch được hỗ trợ trong thời gian tới. Trang “Transaction Models” vẫn mô tả Phoenix ở thì hiện tại, như một trong hai cách bản địa để giá trị di chuyển trên DuskDS, và kết lại bằng việc nói với bạn rằng bạn được tự do chọn giữa chúng. Không hề nhắc gì đến việc đã bị vô hiệu hóa trên trang đó.
Sự trôi dạt đặc tả—đứng ngay trong tài liệu của chính đội ngũ đã phát hành bộ phát hiện sự trôi dạt.
Công bằng mà nói, tài liệu luôn chậm hơn thực tế trên mọi chuỗi. Điều làm Dusk trở nên khác biệt là họ công bố một bản ghi hard-fork chính xác, có nguồn dẫn đầy đủ, và đó là lý do duy nhất khoảng trống này hiện rõ đối với tôi. Vấn đề không phải là họ đã thất bại. Mà là ngay cả một đội ngũ đã tự xây bộ phát hiện cũng không thể hoàn toàn chạy thoát khỏi vấn đề.
Vậy bạn thực sự tin tài liệu nào cho một chuỗi: các trang “learn”, changelog hay mã nguồn? Và bạn làm gì khi cả ba thứ không khớp nhau?
#dusk $DUSK
Công cụ đó là Pituitary. Được cấp phép MIT, chỉ là một tệp nhị phân, không cần Docker và không cần khóa API. Nó lập chỉ mục cho các bản đặc tả, tài liệu và hồ sơ quyết định của bạn, rồi gắn cờ các quyết định trùng lặp, tài liệu cũ, mã nguồn mâu thuẫn với đặc tả, sự trôi dạt thuật ngữ và chuỗi tác động khi một đặc tả thay đổi. Nó cũng đi kèm một máy chủ MCP, nên một tác nhân viết mã bằng AI sẽ có nhận thức về đặc tả ngay trong phiên thay vì tự tin xây dựng trên một quyết định đã bị đảo ngược từ nhiều tháng trước. Một nhóm blockchain xây dựng hạ tầng phát triển chung và lại đem tặng dưới giấy phép MIT thì không phải thứ tôi hay gặp. Ghi nhận nơi xứng đáng.
Rồi tôi đọc tiếp tài liệu. Bản ghi Network Updates của Dusk nêu thẳng rằng các giao dịch Phoenix mới bị từ chối trên mainnet sau khi khởi động lại Boreas, và Moonlight là mô hình giao dịch được hỗ trợ trong thời gian tới. Trang “Transaction Models” vẫn mô tả Phoenix ở thì hiện tại, như một trong hai cách bản địa để giá trị di chuyển trên DuskDS, và kết lại bằng việc nói với bạn rằng bạn được tự do chọn giữa chúng. Không hề nhắc gì đến việc đã bị vô hiệu hóa trên trang đó.
Sự trôi dạt đặc tả—đứng ngay trong tài liệu của chính đội ngũ đã phát hành bộ phát hiện sự trôi dạt.
Công bằng mà nói, tài liệu luôn chậm hơn thực tế trên mọi chuỗi. Điều làm Dusk trở nên khác biệt là họ công bố một bản ghi hard-fork chính xác, có nguồn dẫn đầy đủ, và đó là lý do duy nhất khoảng trống này hiện rõ đối với tôi. Vấn đề không phải là họ đã thất bại. Mà là ngay cả một đội ngũ đã tự xây bộ phát hiện cũng không thể hoàn toàn chạy thoát khỏi vấn đề.
Vậy bạn thực sự tin tài liệu nào cho một chuỗi: các trang “learn”, changelog hay mã nguồn? Và bạn làm gì khi cả ba thứ không khớp nhau?
#dusk $DUSK
#dusk $DUSK @Dusk NPEX là một sàn giao dịch chứng khoán của Hà Lan, được thành lập vào năm 2008, nắm giữ giấy phép Cơ sở giao dịch đa phương (MTF) và giấy phép Nhà cung cấp dịch vụ gây quỹ cộng đồng châu Âu (ECSP) từ AFM. Các nhân vật công khai được Dusk và NPEX trích dẫn cho biết hoạt động tài trợ mà họ hỗ trợ đạt hơn 196–200 triệu EUR trên 100+ SME, với hơn 17.500 nhà đầu tư đang hoạt động. Dusk và NPEX đã hợp tác để đưa cổ phiếu và trái phiếu niêm yết lên chuỗi, đang tích hợp Chainlink CCIP để đảm bảo khả năng tương tác đa chuỗi cho các tài sản được token hóa do DuskEVM phát hành, và đang áp dụng Chainlink DataLink để đưa dữ liệu sàn giao dịch của NPEX lên chuỗi. Dusk mô tả quan hệ hợp tác này như việc giúp giao thức có quyền truy cập “bộ giấy phép tài chính đầy đủ” thông qua NPEX — MTF, Broker, ECSP và một giấy phép DLT-TSS sắp tới theo Chế độ thí điểm DLT của EU — với một dApp của NPEX được cùng xây dựng chạy trên DuskEVM làm giao diện người dùng.
Điểm cần lưu ý là sự khác biệt giữa hạ tầng và tư cách pháp lý. Về mặt kỹ thuật, một blockchain có thể biểu diễn một trái phiếu hoặc cổ phần ETF dưới dạng token mà không cần token đó nhận được bất kỳ sự công nhận theo quy định nào — chỉ đơn thuần là dữ liệu, trừ khi có một tổ chức được cấp phép đứng sau việc phát hành, lưu ký và giao dịch. Điều mà NPEX mang lại không phải là chức năng hợp đồng thông minh; mà là cấu trúc giấy phép khiến việc biểu diễn tài sản trên chuỗi có ý nghĩa pháp lý đối với chứng khoán tại EU, cùng với lịch sử vận hành tạo nên “nội dung thực” cho mối quan hệ. Chi tiết về Chế độ thí điểm DLT đặc biệt quan trọng vì đó là cơ chế của EU cho phép một MTF như NPEX cũng đảm nhận các nhiệm vụ sau giao dịch vốn thường do một tổ chức lưu ký chứng khoán trung ương xử lý — đúng là phần của “ngăn xếp” mà blockchain có vị trí thuận lợi nhất để thay thế.
Giấy phép gắn với chính tổ chức được cấp phép, không phải với giao thức. Nếu câu chuyện mang tính thể chế của Dusk nghiêng mạnh về mối quan hệ với NPEX, thì tính chính danh của nó về mặt thể chế một phần là hàm số của tư cách pháp lý của một sàn giao dịch và cam kết tiếp tục xây dựng trên Dusk. Vậy “tính tuân thủ được xây dựng sẵn theo thiết kế” là một thuộc tính ở cấp giao thức, hay là thuộc tính của chính liên minh hợp tác cụ thể này?
Điểm cần lưu ý là sự khác biệt giữa hạ tầng và tư cách pháp lý. Về mặt kỹ thuật, một blockchain có thể biểu diễn một trái phiếu hoặc cổ phần ETF dưới dạng token mà không cần token đó nhận được bất kỳ sự công nhận theo quy định nào — chỉ đơn thuần là dữ liệu, trừ khi có một tổ chức được cấp phép đứng sau việc phát hành, lưu ký và giao dịch. Điều mà NPEX mang lại không phải là chức năng hợp đồng thông minh; mà là cấu trúc giấy phép khiến việc biểu diễn tài sản trên chuỗi có ý nghĩa pháp lý đối với chứng khoán tại EU, cùng với lịch sử vận hành tạo nên “nội dung thực” cho mối quan hệ. Chi tiết về Chế độ thí điểm DLT đặc biệt quan trọng vì đó là cơ chế của EU cho phép một MTF như NPEX cũng đảm nhận các nhiệm vụ sau giao dịch vốn thường do một tổ chức lưu ký chứng khoán trung ương xử lý — đúng là phần của “ngăn xếp” mà blockchain có vị trí thuận lợi nhất để thay thế.
Giấy phép gắn với chính tổ chức được cấp phép, không phải với giao thức. Nếu câu chuyện mang tính thể chế của Dusk nghiêng mạnh về mối quan hệ với NPEX, thì tính chính danh của nó về mặt thể chế một phần là hàm số của tư cách pháp lý của một sàn giao dịch và cam kết tiếp tục xây dựng trên Dusk. Vậy “tính tuân thủ được xây dựng sẵn theo thiết kế” là một thuộc tính ở cấp giao thức, hay là thuộc tính của chính liên minh hợp tác cụ thể này?
#dusk $DUSK @Dusk
Trước đây tôi từng nghĩ rằng thiết kế “đồng thuận” (consensus) chỉ là phần nhàm chán trong bất kỳ dự án blockchain nào — nơi các kỹ sư tranh luận, nhưng không phải thứ quyết định liệu hoạt động tài chính thực sự có thể vận hành trên đó hay không. Việc tìm hiểu cách bộ xác thực (validator set) của Dusk vận hành đã khiến tôi nhìn nhận khác đi.
Phần lớn các chuỗi được tiếp thị cho lĩnh vực tài chính được quản lý vẫn chạy cơ chế đồng thuận được xây dựng ưu tiên cho sự tham gia mở ngay từ đầu, rồi tuân thủ (compliance) được bổ sung sau. Dusk không bỏ nền tảng không cần cấp phép đó — bất kỳ ai khóa lượng stake cần thiết đều có thể trở thành provisioner — nhưng nó làm một việc rất cụ thể với nền tảng ấy. Cơ chế đồng thuận Succinct Attestation của Dusk chọn các ủy ban gồm những provisioner đủ điều kiện thông qua sortition (bốc thăm) xác định theo định thức (deterministic), và các ủy ban này đề xuất, xác thực, rồi phê chuẩn (ratify) từng khối bằng các vòng bỏ phiếu rõ ràng thay vì cơ chế “chốt cuối” (finality) theo xác suất. Điều này quan trọng — một mạng muốn các tổ chức tiến hành quyết toán giao dịch trên đó cần một câu trả lời chắc chắn và có thể kiểm toán cho tính “final” của từng khối, mà không biến sổ cái thành một cuốn sổ công khai ghi lại toàn bộ hoạt động của mọi người tham gia.
Điểm nổi bật là thiết kế này không được trình bày như sự đánh đổi giữa phi tập trung và tuân thủ, mà như một ràng buộc thiết kế ngay từ ngày đầu. Một nhà vận hành thị trường hoạt động dưới dạng giấy phép như EU MTF cần một quy trình đồng thuận mà kết quả có thể được kiểm toán theo từng khối, mà không phải mọi đối tác đều thấy mọi giao dịch. Đây là điều khác với việc tối ưu TPS hay phí gas — thứ mà hầu hết các câu chuyện kiểu “enterprise blockchain” thường bỏ qua.
Nó cũng đặt ra một câu hỏi mà tôi chưa có câu trả lời chắc chắn: finality dựa trên ủy ban yêu cầu các provisioner của mỗi vòng phải thực sự hội tụ và tạo ra một “attestation”, thay vì để chuỗi tự chốt dần theo thời gian. Liệu điều này phù hợp hơn cho quyết toán được quản lý, hay chỉ là một cách đánh đổi khác liên quan đến tính sống (liveness) và mức độ tham gia, thì cần được kiểm chứng trong điều kiện mạng thực tế thay vì chỉ giả định từ thiết kế. Chúng ta sẽ không biết cho đến khi khối lượng giao dịch thực sự của các tổ chức muốn quyết toán trên chuỗi và buộc những giả định này phải chịu áp lực.
Trước đây tôi từng nghĩ rằng thiết kế “đồng thuận” (consensus) chỉ là phần nhàm chán trong bất kỳ dự án blockchain nào — nơi các kỹ sư tranh luận, nhưng không phải thứ quyết định liệu hoạt động tài chính thực sự có thể vận hành trên đó hay không. Việc tìm hiểu cách bộ xác thực (validator set) của Dusk vận hành đã khiến tôi nhìn nhận khác đi.
Phần lớn các chuỗi được tiếp thị cho lĩnh vực tài chính được quản lý vẫn chạy cơ chế đồng thuận được xây dựng ưu tiên cho sự tham gia mở ngay từ đầu, rồi tuân thủ (compliance) được bổ sung sau. Dusk không bỏ nền tảng không cần cấp phép đó — bất kỳ ai khóa lượng stake cần thiết đều có thể trở thành provisioner — nhưng nó làm một việc rất cụ thể với nền tảng ấy. Cơ chế đồng thuận Succinct Attestation của Dusk chọn các ủy ban gồm những provisioner đủ điều kiện thông qua sortition (bốc thăm) xác định theo định thức (deterministic), và các ủy ban này đề xuất, xác thực, rồi phê chuẩn (ratify) từng khối bằng các vòng bỏ phiếu rõ ràng thay vì cơ chế “chốt cuối” (finality) theo xác suất. Điều này quan trọng — một mạng muốn các tổ chức tiến hành quyết toán giao dịch trên đó cần một câu trả lời chắc chắn và có thể kiểm toán cho tính “final” của từng khối, mà không biến sổ cái thành một cuốn sổ công khai ghi lại toàn bộ hoạt động của mọi người tham gia.
Điểm nổi bật là thiết kế này không được trình bày như sự đánh đổi giữa phi tập trung và tuân thủ, mà như một ràng buộc thiết kế ngay từ ngày đầu. Một nhà vận hành thị trường hoạt động dưới dạng giấy phép như EU MTF cần một quy trình đồng thuận mà kết quả có thể được kiểm toán theo từng khối, mà không phải mọi đối tác đều thấy mọi giao dịch. Đây là điều khác với việc tối ưu TPS hay phí gas — thứ mà hầu hết các câu chuyện kiểu “enterprise blockchain” thường bỏ qua.
Nó cũng đặt ra một câu hỏi mà tôi chưa có câu trả lời chắc chắn: finality dựa trên ủy ban yêu cầu các provisioner của mỗi vòng phải thực sự hội tụ và tạo ra một “attestation”, thay vì để chuỗi tự chốt dần theo thời gian. Liệu điều này phù hợp hơn cho quyết toán được quản lý, hay chỉ là một cách đánh đổi khác liên quan đến tính sống (liveness) và mức độ tham gia, thì cần được kiểm chứng trong điều kiện mạng thực tế thay vì chỉ giả định từ thiết kế. Chúng ta sẽ không biết cho đến khi khối lượng giao dịch thực sự của các tổ chức muốn quyết toán trên chuỗi và buộc những giả định này phải chịu áp lực.
Đã xác minh
Liên tục quay lại dòng này trong tài liệu của Dusk — một cơ quan quản lý có thể xác minh rằng một quy tắc đã được tuân thủ mà không cần bao giờ nhìn thấy giao dịch đã diễn ra sau đó. Không phải “tin chúng tôi,” mà là một bằng chứng thực sự. Giới hạn sở hữu, điều kiện đủ điều kiện, các hạn chế chuyển nhượng, bất cứ quy tắc nào — chuỗi sẽ thể hiện bằng chứng và giữ dữ liệu được che chắn. Hầu hết các chuỗi tự nhận là “tuân thủ” chỉ công khai mọi thứ rồi gọi đó là minh bạch, điều này thành thật mà nói lại đánh mất mục tiêu khi làm điều này trên một chuỗi quyền riêng tư ngay từ đầu. Vì vậy, “phần chọn lọc” chính là ý tưởng cốt lõi, không phải một cách lách.
Tuy nhiên, chỗ tôi bị vướng là chuyện gì xảy ra sau đó. Một bằng chứng cho bạn biết quy tắc đã được giữ tại thời điểm giao dịch diễn ra. Nó không trao cho bất kỳ ai một đường mòn để lần ra dấu nếu sau này cần gỡ rối — ví dụ như một tranh chấp giữa hai bên, một cuộc điều tra, hoặc việc có người tuyên bố rằng một hạn chế chuyển nhượng đã bị lặng lẽ bỏ qua. Mật mã có thể xác nhận rằng việc tuân thủ là đúng. Tôi không chắc nó có thể tái dựng một câu chuyện theo cách mà một hồ sơ giấy cũ có thể, bởi tài chính được quản lý vận hành dựa vào việc có thể quay lại và dựng lại sự việc nhiều năm sau, chứ không chỉ xác nhận chúng tại đúng thời điểm.
Hôm nay DUSK đang ở quanh $0.065, tăng gần 7% trong ngày qua, vốn hóa thị trường gần $32M theo CoinMarketCap — con số đang biến động, nhưng thật ra không phải điểm mấu chốt ở đây.
@Dusk #dusk $DUSK
Thật sự không biết — bằng chứng tuân thủ có còn đứng vững khi ai đó thực sự cần đào sâu xem chuyện gì đã xảy ra hay đó là phần mà chưa ai kiểm chứng?
Tuy nhiên, chỗ tôi bị vướng là chuyện gì xảy ra sau đó. Một bằng chứng cho bạn biết quy tắc đã được giữ tại thời điểm giao dịch diễn ra. Nó không trao cho bất kỳ ai một đường mòn để lần ra dấu nếu sau này cần gỡ rối — ví dụ như một tranh chấp giữa hai bên, một cuộc điều tra, hoặc việc có người tuyên bố rằng một hạn chế chuyển nhượng đã bị lặng lẽ bỏ qua. Mật mã có thể xác nhận rằng việc tuân thủ là đúng. Tôi không chắc nó có thể tái dựng một câu chuyện theo cách mà một hồ sơ giấy cũ có thể, bởi tài chính được quản lý vận hành dựa vào việc có thể quay lại và dựng lại sự việc nhiều năm sau, chứ không chỉ xác nhận chúng tại đúng thời điểm.
Hôm nay DUSK đang ở quanh $0.065, tăng gần 7% trong ngày qua, vốn hóa thị trường gần $32M theo CoinMarketCap — con số đang biến động, nhưng thật ra không phải điểm mấu chốt ở đây.
@Dusk #dusk $DUSK
Thật sự không biết — bằng chứng tuân thủ có còn đứng vững khi ai đó thực sự cần đào sâu xem chuyện gì đã xảy ra hay đó là phần mà chưa ai kiểm chứng?
Đã xác minh
Trước đây, tôi cho rằng việc chứng minh tư cách nhà đầu tư đồng nghĩa với việc phải tiết lộ danh tính đứng sau. Nhưng khi tìm hiểu kỹ hơn về Citadel, tôi đã thay đổi suy nghĩ đó.
Luồng bắt đầu từ một thông tin xác thực — một giấy phép — do một Nhà Cung Cấp Giấy Phép đáng tin cậy cấp. Nhà cung cấp kiểm tra người dùng ngoài chuỗi (off-chain), ký các thuộc tính liên quan, công bố một giấy phép được mã hóa, và đăng ký nó trong một hợp đồng của Citadel. Sau đó, người dùng có thể tạo bằng chứng không kiến thức (zero-knowledge proof) để chứng minh rằng họ sở hữu một giấy phép đã được đăng ký và đã được nhà cung cấp ký — mà không tiết lộ khóa ví của mình, các thuộc tính cá nhân, hoặc thậm chí là giấy phép chính xác nào đã tạo ra bằng chứng đó.
Điều thực sự làm tôi thay đổi cách nghĩ là thế này: một dịch vụ được quản lý có thể nhận bằng chứng mật mã rằng đã diễn ra một bước kiểm tra tư cách, mà không cần danh tính đầy đủ của nhà đầu tư phải xuất hiện trên chuỗi. Nhưng Citadel không quyết định ai được chấp nhận. Bên cung cấp dịch vụ vẫn là người chọn các Nhà Cung Cấp Giấy Phép mà họ tin tưởng, những thuộc tính nào thỏa mãn các quy tắc của họ, và liệu một phiên có còn hiệu lực, bị thu hồi, hay có thể sử dụng lại hay không.
Vì vậy, bằng chứng giúp quyền sở hữu thông tin xác thực trở nên riêng tư và có thể kiểm chứng — nhưng ý nghĩa gán cho thông tin xác thực đó vẫn tồn tại ở tầng ứng dụng, nằm trong tay người phát hành và người diễn giải nó.
Citadel thực sự loại bỏ việc lộ danh tính khỏi cơ chế kiểm soát truy cập, hay chỉ đơn giản là chuyển vị trí của quyết định tin cậy quan trọng nhất sang bên cung cấp phát hành và diễn giải thông tin xác thực?
#dusk $DUSK @Dusk
Luồng bắt đầu từ một thông tin xác thực — một giấy phép — do một Nhà Cung Cấp Giấy Phép đáng tin cậy cấp. Nhà cung cấp kiểm tra người dùng ngoài chuỗi (off-chain), ký các thuộc tính liên quan, công bố một giấy phép được mã hóa, và đăng ký nó trong một hợp đồng của Citadel. Sau đó, người dùng có thể tạo bằng chứng không kiến thức (zero-knowledge proof) để chứng minh rằng họ sở hữu một giấy phép đã được đăng ký và đã được nhà cung cấp ký — mà không tiết lộ khóa ví của mình, các thuộc tính cá nhân, hoặc thậm chí là giấy phép chính xác nào đã tạo ra bằng chứng đó.
Điều thực sự làm tôi thay đổi cách nghĩ là thế này: một dịch vụ được quản lý có thể nhận bằng chứng mật mã rằng đã diễn ra một bước kiểm tra tư cách, mà không cần danh tính đầy đủ của nhà đầu tư phải xuất hiện trên chuỗi. Nhưng Citadel không quyết định ai được chấp nhận. Bên cung cấp dịch vụ vẫn là người chọn các Nhà Cung Cấp Giấy Phép mà họ tin tưởng, những thuộc tính nào thỏa mãn các quy tắc của họ, và liệu một phiên có còn hiệu lực, bị thu hồi, hay có thể sử dụng lại hay không.
Vì vậy, bằng chứng giúp quyền sở hữu thông tin xác thực trở nên riêng tư và có thể kiểm chứng — nhưng ý nghĩa gán cho thông tin xác thực đó vẫn tồn tại ở tầng ứng dụng, nằm trong tay người phát hành và người diễn giải nó.
Citadel thực sự loại bỏ việc lộ danh tính khỏi cơ chế kiểm soát truy cập, hay chỉ đơn giản là chuyển vị trí của quyết định tin cậy quan trọng nhất sang bên cung cấp phát hành và diễn giải thông tin xác thực?
#dusk $DUSK @Dusk
Đúng một phần
Phần lớn các chuỗi khoe “xác nhận cuối cùng nhanh” thực ra đang nói về “tính cuối cùng mang tính xác suất” — bạn chỉ cần chờ đủ lâu để việc đảo ngược trở nên thống kê gần như bất khả. Dusk thì không làm vậy. Nó cam kết “tính cuối cùng thật sự”, và cơ chế đứng sau điều đó đáng để bạn dành thời gian tìm hiểu lâu hơn những gì trang marketing cho phép.
Thỏa thuận Byzantine tách biệt (Segregated Byzantine Agreement) chia việc tạo khối thành hai công đoạn không bao giờ chạm vào nhau. Công đoạn tạo khối được xử lý bởi một Bộ Tạo Khối (Block Generator) được chọn thông qua Proof-of-Blind-Bid — một cơ chế chọn lọc (sortition) trong đó số tiền stake quyết định xác suất thắng của bạn được giữ kín, không chỉ che giấu danh tính. Công đoạn xác thực là một công việc riêng, được vận hành bởi một ủy ban luân phiên của các Provisioners; họ bỏ phiếu để đưa khối qua Reduction rồi đến Agreement. Hai giai đoạn, hai tập hợp tác nhân khác nhau, không có một vai trò vừa đề xuất vừa hoàn tất.
Vì sao sự tách bạch này quan trọng hơn nghe có vẻ? Bởi hầu hết các cuộc tấn công đồng thuận đều nhắm vào sự chồng lấn — một người lãnh đạo vừa có thể đề xuất vừa có ảnh hưởng vượt trội đến việc xác nhận. Khi tách các vai trò này ra, và ẩn các trọng số đặt giá (bid) quyết định ai được chọn để tạo khối, bạn loại bỏ một mục tiêu vốn sẽ rất dễ bị quấy rối (grief) hoặc bị mua chuộc. Khi một chứng chỉ (certificate) đã được hình thành ở giai đoạn Agreement, thì không phải là “chờ cuối mềm” trong thêm sáu lần xác nhận nữa — mà là cuối cùng. Đó mới là phần các tổ chức thực sự quan tâm, không phải lớp phủ thương hiệu về quyền riêng tư.
Đánh đổi mà không ai quảng cáo: điều này chỉ hoạt động vì quyền bỏ phiếu được sắp xếp lại mỗi vòng. Tập validator tĩnh thì dễ suy luận và dễ kiểm toán từ bên ngoài hơn, nhưng đồng thời cũng dễ bị lập bản đồ và nhắm tới. Dusk đặt cược vào tính khó đoán thay vì sự minh bạch.
Thế mọi người đang đứng ở đâu — với một chuỗi hướng tới việc thanh toán chứng khoán được quản lý, việc hoán đổi validator theo từng vòng có phải là một tính năng bảo mật, hay nó chỉ chuyển bề mặt tấn công từ “ai là người lãnh đạo” sang “bạn có thể dự đoán được đầu ra của sortition hay không”?
#dusk $DUSK @Dusk
Thỏa thuận Byzantine tách biệt (Segregated Byzantine Agreement) chia việc tạo khối thành hai công đoạn không bao giờ chạm vào nhau. Công đoạn tạo khối được xử lý bởi một Bộ Tạo Khối (Block Generator) được chọn thông qua Proof-of-Blind-Bid — một cơ chế chọn lọc (sortition) trong đó số tiền stake quyết định xác suất thắng của bạn được giữ kín, không chỉ che giấu danh tính. Công đoạn xác thực là một công việc riêng, được vận hành bởi một ủy ban luân phiên của các Provisioners; họ bỏ phiếu để đưa khối qua Reduction rồi đến Agreement. Hai giai đoạn, hai tập hợp tác nhân khác nhau, không có một vai trò vừa đề xuất vừa hoàn tất.
Vì sao sự tách bạch này quan trọng hơn nghe có vẻ? Bởi hầu hết các cuộc tấn công đồng thuận đều nhắm vào sự chồng lấn — một người lãnh đạo vừa có thể đề xuất vừa có ảnh hưởng vượt trội đến việc xác nhận. Khi tách các vai trò này ra, và ẩn các trọng số đặt giá (bid) quyết định ai được chọn để tạo khối, bạn loại bỏ một mục tiêu vốn sẽ rất dễ bị quấy rối (grief) hoặc bị mua chuộc. Khi một chứng chỉ (certificate) đã được hình thành ở giai đoạn Agreement, thì không phải là “chờ cuối mềm” trong thêm sáu lần xác nhận nữa — mà là cuối cùng. Đó mới là phần các tổ chức thực sự quan tâm, không phải lớp phủ thương hiệu về quyền riêng tư.
Đánh đổi mà không ai quảng cáo: điều này chỉ hoạt động vì quyền bỏ phiếu được sắp xếp lại mỗi vòng. Tập validator tĩnh thì dễ suy luận và dễ kiểm toán từ bên ngoài hơn, nhưng đồng thời cũng dễ bị lập bản đồ và nhắm tới. Dusk đặt cược vào tính khó đoán thay vì sự minh bạch.
Thế mọi người đang đứng ở đâu — với một chuỗi hướng tới việc thanh toán chứng khoán được quản lý, việc hoán đổi validator theo từng vòng có phải là một tính năng bảo mật, hay nó chỉ chuyển bề mặt tấn công từ “ai là người lãnh đạo” sang “bạn có thể dự đoán được đầu ra của sortition hay không”?
#dusk $DUSK @Dusk
Đã xác minh
Cứ mỗi @BabylonLabs_io lời giải thích lại lặp cùng một câu: ủy quyền cho một nhà cung cấp tính chung (finality provider) hoạt động sai, và Bitcoin của bạn sẽ bị cắt (slashed). Điều này được đưa ra như là thứ khiến 56.000+ BTC "bảo mật" cho các chuỗi này mang ý nghĩa gì đó — vốn thực sự đang bị rủi ro nếu một provider double-signs.
Vì vậy, tôi đã kiểm tra tham số thực tế thay vì dòng cảnh báo. Tài liệu dành cho người vận hành node của Pier Two nói thẳng: double-sign, và hình phạt BTC là cố định ở mức 0,1% giá trị số tiền đã stake. So với BABY validators, những bên này sẽ mất 5% cho cùng hành vi — tốc độ gấp năm mươi lần.
Khoảng cách đó là thứ khiến tôi dừng lại. Bản chào hàng là "sự bảo mật của Bitcoin lan tỏa ra bên ngoài", và đa số người đọc điều đó như một cách tấn công một BSN mà phía sau là thứ gì đó gần như toàn bộ BTC, giống như cách slashing nghiêm túc hoạt động trên Ethereum. Nhưng nếu cơ chế răn đe thực sự chỉ dừng ở 0,1%, thì "hàng tỷ USD Bitcoin bảo mật chuỗi này" đang làm nhiều công việc về mặt kể chuyện hơn là về mặt kinh tế. Một provider hoạt động sai không phải đang mạo hiểm hàng tỷ — họ chỉ đang mạo hiểm 0,1% của phần stake được ủy quyền, và rủi ro đó thuộc về những người nắm giữ BTC đã ủy quyền, chứ không phải vốn của chính provider.
Nói thẳng để dễ hiểu: đến nay chưa có finality provider nào thực sự bị slashed trên Babylon. Cơ chế này vẫn chưa được thử nghiệm trong sản xuất — chưa có kiểm chứng ngoài đời liệu liệu mức 0,1% có giữ cho 250+ nhà điều hành tuân thủ hay không, khi những động lực thật sự để hành xử sai xuất hiện.
0,1% có phải là lựa chọn có chủ đích để khiến rủi ro giảm xuống đủ nhỏ để người ủy quyền vẫn sẵn sàng stake, hay là dấu hiệu rằng "sự bảo mật" ở đây mỏng hơn nhiều so với tiêu đề TVL khi bạn nhìn vào điều gì thực sự có thể bị cưỡng chế?
#baby $BABY $BTC
Vì vậy, tôi đã kiểm tra tham số thực tế thay vì dòng cảnh báo. Tài liệu dành cho người vận hành node của Pier Two nói thẳng: double-sign, và hình phạt BTC là cố định ở mức 0,1% giá trị số tiền đã stake. So với BABY validators, những bên này sẽ mất 5% cho cùng hành vi — tốc độ gấp năm mươi lần.
Khoảng cách đó là thứ khiến tôi dừng lại. Bản chào hàng là "sự bảo mật của Bitcoin lan tỏa ra bên ngoài", và đa số người đọc điều đó như một cách tấn công một BSN mà phía sau là thứ gì đó gần như toàn bộ BTC, giống như cách slashing nghiêm túc hoạt động trên Ethereum. Nhưng nếu cơ chế răn đe thực sự chỉ dừng ở 0,1%, thì "hàng tỷ USD Bitcoin bảo mật chuỗi này" đang làm nhiều công việc về mặt kể chuyện hơn là về mặt kinh tế. Một provider hoạt động sai không phải đang mạo hiểm hàng tỷ — họ chỉ đang mạo hiểm 0,1% của phần stake được ủy quyền, và rủi ro đó thuộc về những người nắm giữ BTC đã ủy quyền, chứ không phải vốn của chính provider.
Nói thẳng để dễ hiểu: đến nay chưa có finality provider nào thực sự bị slashed trên Babylon. Cơ chế này vẫn chưa được thử nghiệm trong sản xuất — chưa có kiểm chứng ngoài đời liệu liệu mức 0,1% có giữ cho 250+ nhà điều hành tuân thủ hay không, khi những động lực thật sự để hành xử sai xuất hiện.
0,1% có phải là lựa chọn có chủ đích để khiến rủi ro giảm xuống đủ nhỏ để người ủy quyền vẫn sẵn sàng stake, hay là dấu hiệu rằng "sự bảo mật" ở đây mỏng hơn nhiều so với tiêu đề TVL khi bạn nhìn vào điều gì thực sự có thể bị cưỡng chế?
#baby $BABY $BTC
Đang mổ xẻ phần “pitch DeFi BTC không cần tin tưởng” của Babylon thay vì chỉ đọc slide.
TVL khoảng 2,6B USD, giảm gần 19% trong tuần này — hơn 600M USD đã biến mất. Không phải kiểu câu chuyện “chúng tôi chỉ vừa sửa xong DeFi BTC” mà lẽ ra phải trông như vậy, dù phần này cũng còn yếu vì việc mở rộng sản phẩm vẫn có thể tiếp tục trong khi TVL co lại.
Cái “khó nuốt” hơn nằm ở chỗ <$BABY > thực sự giao dịch ở đâu — khối lượng 24h khoảng 6,2M USD, và chỉ khoảng 13% nằm trên DEX, phần còn lại là dòng chảy qua sàn giao dịch tập trung. Với một giao thức được xây dựng để loại bỏ các bên trung gian cần tin tưởng, bản thân token hầu như không chạm tới những “làn đường” không cần tin tưởng.
Rồi đến “spoke” được hỗ trợ bằng BTC. Ban đầu đọc như chỉ thêm một dòng tài sản thế chấp nữa, nhưng việc tách riêng thanh khoản BTC làm lộ ra điều gì đó tinh tế hơn — nó sàng lọc cho người gửi đang thử nghiệm xem BTC có thể được đặt vào và hoạt động mà không bị bán hay không, chứ không phải nhóm săn lợi suất. Ma sát trong việc cầu nối và lưu ký loại trừ ai chưa thực sự bị thuyết phục từ trước. Vào chậm, ra chậm.
Tokenomics lại thêm một lớp nữa: lạm phát hằng năm 8% — cơ học và được đảm bảo — so với một “burn auction” chỉ kích hoạt nếu việc áp dụng BSN thực sự tạo ra dòng phần thưởng. Một chiếc đồng hồ chạy bất kể sử dụng. Còn chiếc kia thì không.
Không nói là bất kỳ thứ nào “bị hỏng” — chỉ là những hệ thống tách biệt với các mốc thời gian khác nhau, và chỉ có một trong số đó được đảm bảo sẽ dịch chuyển theo hướng có lợi cho Babylon.
“Không cần tin tưởng” thực sự phải đứng vững ở đâu — cơ chế tài sản thế chấp, hay toàn bộ những thứ được định giá dựa trên đó?
@BabylonLabs_io #baby $BABY $BTC
TVL khoảng 2,6B USD, giảm gần 19% trong tuần này — hơn 600M USD đã biến mất. Không phải kiểu câu chuyện “chúng tôi chỉ vừa sửa xong DeFi BTC” mà lẽ ra phải trông như vậy, dù phần này cũng còn yếu vì việc mở rộng sản phẩm vẫn có thể tiếp tục trong khi TVL co lại.
Cái “khó nuốt” hơn nằm ở chỗ <$BABY > thực sự giao dịch ở đâu — khối lượng 24h khoảng 6,2M USD, và chỉ khoảng 13% nằm trên DEX, phần còn lại là dòng chảy qua sàn giao dịch tập trung. Với một giao thức được xây dựng để loại bỏ các bên trung gian cần tin tưởng, bản thân token hầu như không chạm tới những “làn đường” không cần tin tưởng.
Rồi đến “spoke” được hỗ trợ bằng BTC. Ban đầu đọc như chỉ thêm một dòng tài sản thế chấp nữa, nhưng việc tách riêng thanh khoản BTC làm lộ ra điều gì đó tinh tế hơn — nó sàng lọc cho người gửi đang thử nghiệm xem BTC có thể được đặt vào và hoạt động mà không bị bán hay không, chứ không phải nhóm săn lợi suất. Ma sát trong việc cầu nối và lưu ký loại trừ ai chưa thực sự bị thuyết phục từ trước. Vào chậm, ra chậm.
Tokenomics lại thêm một lớp nữa: lạm phát hằng năm 8% — cơ học và được đảm bảo — so với một “burn auction” chỉ kích hoạt nếu việc áp dụng BSN thực sự tạo ra dòng phần thưởng. Một chiếc đồng hồ chạy bất kể sử dụng. Còn chiếc kia thì không.
Không nói là bất kỳ thứ nào “bị hỏng” — chỉ là những hệ thống tách biệt với các mốc thời gian khác nhau, và chỉ có một trong số đó được đảm bảo sẽ dịch chuyển theo hướng có lợi cho Babylon.
“Không cần tin tưởng” thực sự phải đứng vững ở đâu — cơ chế tài sản thế chấp, hay toàn bộ những thứ được định giá dựa trên đó?
@BabylonLabs_io #baby $BABY $BTC
Đúng một phần
Đêm qua tôi không ngủ được, nên tôi đang tự hỏi nên làm gì. Mình nên xem phim hay làm một chút việc? Rồi tôi nghĩ mình sẽ xem thị trường crypto, thế là tôi mở các ứng dụng coinmarketcap. Sau đó tôi thấy hôm nay thị trường BTC giảm 0.72%. Rồi tôi thấy token $BABY đang tăng 3.5% ở mức 0.01199$. Giá đang đi lên, vốn hóa 51.22m, khối lượng giao dịch 24h là 52.11m, xếp thứ 24 và khối lượng tăng 475%. Tôi cứ nghĩ mình có thể quyết định chỉ bằng việc nhìn vào giá. Nhưng trong vài ngày nay, @BabylonLabs_io lại hiện ra trước mắt tôi hết lần này đến lần khác, nên tôi muốn xem thêm chi tiết về dự án. Rồi tôi vào trang kiểm toán của Certik.Skynet. Sau đó tôi thực sự bị sốc khi thấy điểm số. Điểm đánh giá AA 89.58 có vẻ vẫn đang ở tình trạng tốt trong phần bảo mật. Ngoài ra còn có một vài cuộc kiểm toán từ bên thứ ba. Nhìn xuống thêm một chút trên trang Certik, tôi thấy kiểm toán của Certik vẫn chưa được hoàn tất, không có xác minh đội ngũ, và phần đánh giá cũng đang hiển thị là dạng một phần. Thế là trong đầu tôi nảy ra một câu hỏi. Nghe có vẻ khá mạnh. Nhưng tôi vẫn còn nghi ngờ trong lòng tại sao những mục đó lại chưa hoàn thành dù dự án này có vẻ tốt đến vậy. Tôi thấy từ trang Certik rằng việc kiểm toán vẫn chưa được hoàn tất. Có lẽ có những lý do đủ sâu phía sau mà chúng ta không biết, nhưng với tư cách là một người dùng bình thường, điều này đã khơi dậy sự tò mò của tôi. Vậy theo bạn, liệu có tốt hơn nếu những phần đó đã được hoàn tất/được thể hiện đầy đủ trong chủ đề này không? Hay phần thông tin ít ỏi như vậy là đã đủ?
#baby $BABY
#baby $BABY
Đã xác minh
Khi xem xét tokenomics của Babylon, có một điều thật sự thu hút sự chú ý của tôi. Theo thông tin hiện có, tổng cung là 10,98 tỷ, với khoảng 4,03 tỷ token đang được lưu hành. Nhưng đối với một dự án có quy mô như vậy, thật bất ngờ là trong tokenomics chính thức lại không có đề cập rõ ràng về tổng cung tối đa. Điều này khiến tôi tự hỏi: đó chỉ đơn giản là một sự thiếu sót hay có lý do nào đó khiến thông tin này vẫn chưa được công bố rõ ràng? Việc biết tổng cung tối đa là quan trọng vì nó giúp nhà đầu tư đánh giá lượng token sẽ được phát hành trong tương lai, khả năng lạm phát và định giá dài hạn. Vì vậy, luôn đáng để dành thời gian đào sâu vào các tài liệu chính thức thay vì chỉ dựa vào tin đồn hoặc sự thổi phồng. Ý kiến của bạn là gì? Bạn nghĩ việc thiếu thông tin về tổng cung tối đa chỉ là một sự thiếu sót, hay có thể có một cách giải thích khác?
@BabylonLabs_io #baby $BABY $BTC
@BabylonLabs_io #baby $BABY $BTC
Đăng nhập để khám phá thêm nội dung