Đã từng có một khoảng thời gian tôi để node chạy và đi pha cà phê, quay lại thì thấy log vẫn đang chảy đều đều... lúc đó tôi bắt đầu nghĩ rằng thời gian uptime ổn định nhất cũng là thứ dễ khiến bạn trở nên tự mãn.
Tôi vào config.rs: proposal = 1 credit, validation = 64, ratification = 64, quorum = 33.
Nếu chỉ cần đủ lượng stake là đã đủ thì những tham số này dùng để làm gì?
Tôi chuyển sang sortition.rs: score = hash mod total_staking_weight.
khi trọng số stake tăng lên, xác suất được chọn có thể tăng, nhưng xác suất không phải là quyền thụ hưởng.
Rồi tôi sang core/src/stake.rs, dòng 46: DEFAULT_MINIMUM_STAKE = 1000.
Nói thật, trước đây tôi từng coi minimum stake là vạch đích, nhưng thực ra nó giống như điều kiện khởi tạo hơn là một trạng thái được bảo đảm.
Staking 1500 DUSK nghĩa là vượt mức tối thiểu thêm 500 DUSK.
nhưng bỏ lỡ việc bỏ phiếu sẽ mang lại hình phạt mềm, tạm đình chỉ tính đủ điều kiện, và một khi một phần stake chuyển sang trạng thái bị khóa, con số đó trông không còn “đẹp” như trước nữa ngay lập tức.
Việc nạp thêm cũng hoạt động tương tự: 90% hoạt động ngay, 10% bị khóa.
500 DUSK nghĩa là 450 DUSK ở trạng thái hoạt động, 50 DUSK bị khóa... nó có vẻ nhỏ, nhưng hậu quả thì không.
Từ đó, mỗi khi kiểm toán một giao thức, tôi đều xem xét datatype, triển khai, chuyển trạng thái, mức độ tham gia bỏ phiếu, điều kiện runtime, khả năng sẵn sàng của máy, và việc unstaking hoàn toàn.
quorum = 33.
nhưng là 33 phiếu hay 33%?
Rút ra kết luận mà không kiểm tra datatype thì chắc chắn nhanh, nhưng đôi khi câu trả lời nhanh nhất lại có thể là sai nhất.
score, hash, committee, trạng thái bị khóa, validation, ratification... Càng lần theo chúng, tôi càng thấy một validator không phải là một đống stake chỉ ngồi yên, mà là một hệ thống phải luôn sống và vận hành liên tục.
Với tôi, một validator đáng tin cậy không phải là node có lượng stake lớn nhất, mà là node có kỷ luật vận hành mạnh nhất trong thời điểm không ai đứng bên cạnh nhắc nó phải bỏ phiếu.
Nếu bạn phải chọn giữa việc tăng trọng số stake thêm 20% và giảm số lần bỏ lỡ bỏ phiếu, giảm downtime, giảm penalty trong vận hành thực tế, bạn sẽ chọn phía nào?#dusk $DUSK @Dusk
Tôi vào config.rs: proposal = 1 credit, validation = 64, ratification = 64, quorum = 33.
Nếu chỉ cần đủ lượng stake là đã đủ thì những tham số này dùng để làm gì?
Tôi chuyển sang sortition.rs: score = hash mod total_staking_weight.
khi trọng số stake tăng lên, xác suất được chọn có thể tăng, nhưng xác suất không phải là quyền thụ hưởng.
Rồi tôi sang core/src/stake.rs, dòng 46: DEFAULT_MINIMUM_STAKE = 1000.
Nói thật, trước đây tôi từng coi minimum stake là vạch đích, nhưng thực ra nó giống như điều kiện khởi tạo hơn là một trạng thái được bảo đảm.
Staking 1500 DUSK nghĩa là vượt mức tối thiểu thêm 500 DUSK.
nhưng bỏ lỡ việc bỏ phiếu sẽ mang lại hình phạt mềm, tạm đình chỉ tính đủ điều kiện, và một khi một phần stake chuyển sang trạng thái bị khóa, con số đó trông không còn “đẹp” như trước nữa ngay lập tức.
Việc nạp thêm cũng hoạt động tương tự: 90% hoạt động ngay, 10% bị khóa.
500 DUSK nghĩa là 450 DUSK ở trạng thái hoạt động, 50 DUSK bị khóa... nó có vẻ nhỏ, nhưng hậu quả thì không.
Từ đó, mỗi khi kiểm toán một giao thức, tôi đều xem xét datatype, triển khai, chuyển trạng thái, mức độ tham gia bỏ phiếu, điều kiện runtime, khả năng sẵn sàng của máy, và việc unstaking hoàn toàn.
quorum = 33.
nhưng là 33 phiếu hay 33%?
Rút ra kết luận mà không kiểm tra datatype thì chắc chắn nhanh, nhưng đôi khi câu trả lời nhanh nhất lại có thể là sai nhất.
score, hash, committee, trạng thái bị khóa, validation, ratification... Càng lần theo chúng, tôi càng thấy một validator không phải là một đống stake chỉ ngồi yên, mà là một hệ thống phải luôn sống và vận hành liên tục.
Với tôi, một validator đáng tin cậy không phải là node có lượng stake lớn nhất, mà là node có kỷ luật vận hành mạnh nhất trong thời điểm không ai đứng bên cạnh nhắc nó phải bỏ phiếu.
Nếu bạn phải chọn giữa việc tăng trọng số stake thêm 20% và giảm số lần bỏ lỡ bỏ phiếu, giảm downtime, giảm penalty trong vận hành thực tế, bạn sẽ chọn phía nào?#dusk $DUSK @Dusk
