@Dusk_Foundation
Điều gì đó trong whitepaper “bản nháp Dusk” đã làm tôi bất ngờ: nó thẳng thắn thừa nhận một điểm yếu trong thiết kế của chính nó, thay vì chỉ bán tầm nhìn. Các bộ tạo (generator) bị chọn theo một công thức xác định, nên đôi khi một người cung cấp (provisioner) có thể biết trước rằng chúng sẽ được xếp vào một lần thử sau cho cùng một khối nếu các lần thử trước thất bại — từ đó tạo ra động cơ kỳ lạ là cứ để những lần thử đó sụp đổ.
Bài viết gọi đó là “future-generator incentive problem” (vấn đề động cơ đối với bộ tạo trong tương lai). Và thay vì lướt qua, nó đưa ra các bản vá thực sự: thưởng cho mọi người chỉ vì việc bỏ phiếu, gắn một phần phần thưởng của một generator với số phiếu họ đưa vào, và giữ cho generator tiếp theo trong hàng không tham gia vào lượt bỏ phiếu hiện tại. Sự “thành thật” kiểu đó có vẻ nhắm tới những người thường xuyên kiểm toán hệ thống, chứ không phải những người đang chạy theo một câu chuyện — điều này cũng khớp với toàn bộ định vị của Dusk hướng tới tài chính được quản lý.
Tuy vậy, một bản vá không phải là một giải pháp. Phần thưởng có thể “đẩy” hành vi, nhưng không loại bỏ tính dự đoán vốn có, và một provisioner được cấp vốn tốt, không quan tâm đến danh tiếng, vẫn có thể quyết định rằng rủi ro là đáng giá. Đây là cùng một kiểu “khoảng trống” xuất hiện giữa code và luật: một giao thức có thể khiến hành vi xấu trở nên đắt đỏ, nhưng chỉ tòa án hoặc cơ quan quản lý mới có thể khiến hậu quả trở nên nghiêm trọng bất chấp việc ai đó có bao nhiêu tiền.
Không có điều nào trong số này làm cách tiếp cận của Dusk kém chu đáo; nó chỉ có nghĩa là phần thú vị của một whitepaper thường là đoạn thừa nhận điểm yếu, chứ không phải đoạn bán ra kết quả. Hãy đọc các giới hạn mà dự án tự nêu tên, rồi cân nhắc xem phần còn lại đáng tin đến mức nào.
Vẫn đang học những thứ này từng bài viết một, và thành thật mà nói, đó mới là phần vui.
@Dusk_Foundation #dusk $DUSK
Điều gì đó trong whitepaper “bản nháp Dusk” đã làm tôi bất ngờ: nó thẳng thắn thừa nhận một điểm yếu trong thiết kế của chính nó, thay vì chỉ bán tầm nhìn. Các bộ tạo (generator) bị chọn theo một công thức xác định, nên đôi khi một người cung cấp (provisioner) có thể biết trước rằng chúng sẽ được xếp vào một lần thử sau cho cùng một khối nếu các lần thử trước thất bại — từ đó tạo ra động cơ kỳ lạ là cứ để những lần thử đó sụp đổ.
Bài viết gọi đó là “future-generator incentive problem” (vấn đề động cơ đối với bộ tạo trong tương lai). Và thay vì lướt qua, nó đưa ra các bản vá thực sự: thưởng cho mọi người chỉ vì việc bỏ phiếu, gắn một phần phần thưởng của một generator với số phiếu họ đưa vào, và giữ cho generator tiếp theo trong hàng không tham gia vào lượt bỏ phiếu hiện tại. Sự “thành thật” kiểu đó có vẻ nhắm tới những người thường xuyên kiểm toán hệ thống, chứ không phải những người đang chạy theo một câu chuyện — điều này cũng khớp với toàn bộ định vị của Dusk hướng tới tài chính được quản lý.
Tuy vậy, một bản vá không phải là một giải pháp. Phần thưởng có thể “đẩy” hành vi, nhưng không loại bỏ tính dự đoán vốn có, và một provisioner được cấp vốn tốt, không quan tâm đến danh tiếng, vẫn có thể quyết định rằng rủi ro là đáng giá. Đây là cùng một kiểu “khoảng trống” xuất hiện giữa code và luật: một giao thức có thể khiến hành vi xấu trở nên đắt đỏ, nhưng chỉ tòa án hoặc cơ quan quản lý mới có thể khiến hậu quả trở nên nghiêm trọng bất chấp việc ai đó có bao nhiêu tiền.
Không có điều nào trong số này làm cách tiếp cận của Dusk kém chu đáo; nó chỉ có nghĩa là phần thú vị của một whitepaper thường là đoạn thừa nhận điểm yếu, chứ không phải đoạn bán ra kết quả. Hãy đọc các giới hạn mà dự án tự nêu tên, rồi cân nhắc xem phần còn lại đáng tin đến mức nào.
Vẫn đang học những thứ này từng bài viết một, và thành thật mà nói, đó mới là phần vui.
@Dusk_Foundation #dusk $DUSK