Mình có một thứ mình nhận ra khi thử nghĩ liệu cơ chế 90/10 của Dusk có nên thiết kế lại theo hướng lũy tiến, thay vì áp dụng tỷ lệ cố định cho mọi lần restake.
Nếu vấn đề nằm ở việc retail staker phải restake nhiều lần hơn provisioner lớn, cách xử lý hợp lý có thể là giảm dần mức phạt theo số lần restake trong một chu kỳ — vài lần đầu giữ đúng 90/10 để chống thao túng, nhưng từ lần thứ tư, thứ năm trở đi, tỷ lệ kích hoạt ngay có thể cao hơn, vì đó thường là nhu cầu tăng vốn thực sự, khác với hành vi cố tình restake liên tục để gaming sortition.
Đây là bài toán quen thuộc trong thiết kế chống lạm dụng — phân biệt hành vi lặp lại có mục đích thao túng với hành vi lặp lại từ nhu cầu tự nhiên thường khó, vì cả hai giống hệt nhau về dữ liệu on-chain. Cơ chế cố định như hiện tại chọn cách an toàn — áp dụng đồng đều để không cần phân biệt — nhưng cái giá là công bằng về quy tắc, không công bằng về tác động.
@Dusk có thể đã cân nhắc và chọn cách đơn giản này có chủ đích, vì thiết kế lũy tiến phức tạp hơn nhiều để triển khai và có thể mở ra bề mặt tấn công mới nếu không cẩn thận.
Tự phản biện: đề xuất lũy tiến nghe hợp lý trên giấy, nhưng kẻ muốn thao túng sortition có thể học cách restake vừa đủ để lợi dụng ngưỡng lũy tiến, khiến cơ chế phức tạp hơn mà chưa chắc an toàn hơn.
Mình đang chờ xem $DUSK có công bố lý do cụ thể vì sao chọn tỷ lệ cố định thay vì lũy tiến, để hiểu đây là lựa chọn cân nhắc kỹ, hay chỉ là giải pháp đầu tiên chưa tối ưu thêm.
#dusk $BTC #ETH #BTC
Nếu vấn đề nằm ở việc retail staker phải restake nhiều lần hơn provisioner lớn, cách xử lý hợp lý có thể là giảm dần mức phạt theo số lần restake trong một chu kỳ — vài lần đầu giữ đúng 90/10 để chống thao túng, nhưng từ lần thứ tư, thứ năm trở đi, tỷ lệ kích hoạt ngay có thể cao hơn, vì đó thường là nhu cầu tăng vốn thực sự, khác với hành vi cố tình restake liên tục để gaming sortition.
Đây là bài toán quen thuộc trong thiết kế chống lạm dụng — phân biệt hành vi lặp lại có mục đích thao túng với hành vi lặp lại từ nhu cầu tự nhiên thường khó, vì cả hai giống hệt nhau về dữ liệu on-chain. Cơ chế cố định như hiện tại chọn cách an toàn — áp dụng đồng đều để không cần phân biệt — nhưng cái giá là công bằng về quy tắc, không công bằng về tác động.
@Dusk có thể đã cân nhắc và chọn cách đơn giản này có chủ đích, vì thiết kế lũy tiến phức tạp hơn nhiều để triển khai và có thể mở ra bề mặt tấn công mới nếu không cẩn thận.
Tự phản biện: đề xuất lũy tiến nghe hợp lý trên giấy, nhưng kẻ muốn thao túng sortition có thể học cách restake vừa đủ để lợi dụng ngưỡng lũy tiến, khiến cơ chế phức tạp hơn mà chưa chắc an toàn hơn.
Mình đang chờ xem $DUSK có công bố lý do cụ thể vì sao chọn tỷ lệ cố định thay vì lũy tiến, để hiểu đây là lựa chọn cân nhắc kỹ, hay chỉ là giải pháp đầu tiên chưa tối ưu thêm.
#dusk $BTC #ETH #BTC
