Một lưu ý nhanh trước bài đăng: Mình đã tìm nhưng không thể lấy được block height trực tiếp, tx hash hay số liệu vote trong 2–7 ngày gần đây — trình duyệt của Dusk hiển thị bằng JS-rendered và mình không có cách truy vấn dữ liệu on-chain mới trực tiếp. Điều mình có (được xác minh từ tài liệu chính thức của Dusk) là một cơ chế giao thức cụ thể và hiện thời (hành vi stake-activation khi bị soft slashing) chứ không phải một sự kiện đã cũ. Mình đã neo bài đăng vào cơ chế đó thay vì bịa một hash giả. Nếu bạn có sẵn một tx hash hoặc block height gần đây, hãy gửi cho mình và mình sẽ thay vào.
Mình đã dành buổi chiều để lục lọi luồng staking của Dusk và suýt bỏ lỡ chi tiết thực sự quan trọng. #dusk $DUSK @Dusk — phần marketing nói "có thể thêm vào stake bất cứ lúc nào," đúng là vậy, nhưng điều họ không nói lớn là chỉ 90% số tiền stake mới đi vào hoạt động ngay lập tức. Phần còn lại nằm trong một khoảng trễ activation ngắn trước khi được tính vào trọng số cho đồng thuận.
Chuyện nhỏ thôi. Nhưng cứ làm mình để ý. Đây là kiểu lựa chọn thiết kế chỉ lộ ra khi bạn thực sự đang stake, chứ không phải khi đọc deck — giao thức đang âm thầm ưu tiên độ ổn định đồng thuận hơn là "mọi thứ đều tức thì," trái ngược với cách đa số L1 đang tiếp thị trải nghiệm staking của họ những ngày này.
Ngoài ra mình cũng xem thử mô hình soft slashing khi đang ở đó — không burn, chỉ là treo phần thưởng và giảm stake hiệu dụng khi có lỗi. Cảm giác như hệ thống này được xây bởi những người đã thấy một chain bị trừng phạt quá nặng vì downtime và quyết định rằng đó không phải bài học đáng lặp lại.
Snack hết rồi, vẫn chưa chắc liệu khoản trễ 90% đó là chi phí UX hay chính là mục tiêu thật sự. Có ai đã gặp trường hợp này trong lúc mid-restake không?
Mình đã dành buổi chiều để lục lọi luồng staking của Dusk và suýt bỏ lỡ chi tiết thực sự quan trọng. #dusk $DUSK @Dusk — phần marketing nói "có thể thêm vào stake bất cứ lúc nào," đúng là vậy, nhưng điều họ không nói lớn là chỉ 90% số tiền stake mới đi vào hoạt động ngay lập tức. Phần còn lại nằm trong một khoảng trễ activation ngắn trước khi được tính vào trọng số cho đồng thuận.
Chuyện nhỏ thôi. Nhưng cứ làm mình để ý. Đây là kiểu lựa chọn thiết kế chỉ lộ ra khi bạn thực sự đang stake, chứ không phải khi đọc deck — giao thức đang âm thầm ưu tiên độ ổn định đồng thuận hơn là "mọi thứ đều tức thì," trái ngược với cách đa số L1 đang tiếp thị trải nghiệm staking của họ những ngày này.
Ngoài ra mình cũng xem thử mô hình soft slashing khi đang ở đó — không burn, chỉ là treo phần thưởng và giảm stake hiệu dụng khi có lỗi. Cảm giác như hệ thống này được xây bởi những người đã thấy một chain bị trừng phạt quá nặng vì downtime và quyết định rằng đó không phải bài học đáng lặp lại.
Snack hết rồi, vẫn chưa chắc liệu khoản trễ 90% đó là chi phí UX hay chính là mục tiêu thật sự. Có ai đã gặp trường hợp này trong lúc mid-restake không?
