#dusk $DUSK @Dusk Đã xem qua phần khuyến khích đồng thuận trong tuần này vì tôi muốn hiểu liệu một bên nắm giữ lớn hơn có thể “gian lận” về thời điểm tạo khối hay không.
Phát hiện bất ngờ: bản whitepaper nêu đúng chính vấn đề này. "Future-generator incentive problem" — các bộ tạo ở vòng lặp cao hơn có thể được lợi nếu các vòng lặp trước thất bại, vì khi đó họ giành được phần thưởng khối. Đây là một lỗ hổng được đặt tên rõ ràng, không hề bị che giấu.
Nâng cấp Aegis trên mainnet (ngày 3/3/2026) tập trung vào khả năng phục hồi của mạng. Một phần lý do khả năng phục hồi lại quan trọng ở đây: chính cơ chế khuyến khích này có thể khiến các bộ tạo ở vòng lặp sớm hoạt động kém hơn.
Có ba cơ chế xử lý nó: thưởng cho người bỏ phiếu (các nhà cung cấp nhận thu nhập nhờ bỏ phiếu, không chỉ nhờ tạo); phần tín dụng bổ sung (bộ tạo sẽ bị mất khoản thưởng tín dụng bổ sung 10% nếu họ loại trừ việc bỏ phiếu — vì vậy phá hoại cũng khiến họ phải trả giá); loại trừ các bộ tạo của vòng lặp kế tiếp khỏi bước bỏ phiếu hiện tại.
Hầu hết các hệ thống PoS không gặp vấn đề này: không có cấu trúc lặp theo trình tự nghĩa là không có người kế nhiệm chờ để được hưởng lợi từ sự thất bại của người đi trước. Thiết kế của Dusk tạo ra lỗ hổng này và sau đó vá lại.
Một giao thức nêu rõ ràng sai sót về mặt trò chơi (game-theoretic flaw) của chính mình một cách công khai là đang làm điều khá bất thường. Liệu ba bản vá có đứng vững khi mạng thực sự chịu áp lực với mức đặt cược tập trung hay không vẫn là câu hỏi mở thẳng thắn. @Dusk
$DUSK #dusk
Phát hiện bất ngờ: bản whitepaper nêu đúng chính vấn đề này. "Future-generator incentive problem" — các bộ tạo ở vòng lặp cao hơn có thể được lợi nếu các vòng lặp trước thất bại, vì khi đó họ giành được phần thưởng khối. Đây là một lỗ hổng được đặt tên rõ ràng, không hề bị che giấu.
Nâng cấp Aegis trên mainnet (ngày 3/3/2026) tập trung vào khả năng phục hồi của mạng. Một phần lý do khả năng phục hồi lại quan trọng ở đây: chính cơ chế khuyến khích này có thể khiến các bộ tạo ở vòng lặp sớm hoạt động kém hơn.
Có ba cơ chế xử lý nó: thưởng cho người bỏ phiếu (các nhà cung cấp nhận thu nhập nhờ bỏ phiếu, không chỉ nhờ tạo); phần tín dụng bổ sung (bộ tạo sẽ bị mất khoản thưởng tín dụng bổ sung 10% nếu họ loại trừ việc bỏ phiếu — vì vậy phá hoại cũng khiến họ phải trả giá); loại trừ các bộ tạo của vòng lặp kế tiếp khỏi bước bỏ phiếu hiện tại.
Hầu hết các hệ thống PoS không gặp vấn đề này: không có cấu trúc lặp theo trình tự nghĩa là không có người kế nhiệm chờ để được hưởng lợi từ sự thất bại của người đi trước. Thiết kế của Dusk tạo ra lỗ hổng này và sau đó vá lại.
Một giao thức nêu rõ ràng sai sót về mặt trò chơi (game-theoretic flaw) của chính mình một cách công khai là đang làm điều khá bất thường. Liệu ba bản vá có đứng vững khi mạng thực sự chịu áp lực với mức đặt cược tập trung hay không vẫn là câu hỏi mở thẳng thắn. @Dusk
$DUSK #dusk