#dusk $DUSK @Dusk
𝐂𝐡ế độ 𝐊𝐡ẩ𝐧 cấp 𝐁𝐚𝐧 𝐃ê: 𝐂𝐚́𝐜 𝐕𝐢ệ𝐜 𝐱ả𝐲 𝐫𝐚 𝐤𝐡𝐢 𝐜𝐚́𝐜 𝐩𝐡𝐢ê𝐧 𝐭𝐡ủ 𝐭𝐡à𝐧𝐡 𝐜𝐨𝐡𝐨𝐞̂𝐧 𝐠𝐨𝐧 𝐜𝐡𝐢̉ 𝐡𝐨𝐥𝐢?\n\nĐiều gì xảy ra khi các người tham gia đồng thuận của một blockchain đơn giản là không còn xuất hiện? Không có tấn công, không có vụ khai thác kịch tính. Chỉ là đủ nhiều bên vận hành (provisioners) đi offline khiến mạng bắt đầu gặp khó khăn trong việc đạt được sự đồng thuận. Đây là phần trong thiết kế của @Dusk đã thu hút sự chú ý của tôi.$STAR \n\nTôi đã xem Chế độ Khẩn cấp của Dusk và ý tưởng khá đơn giản, nhưng thực sự rất quan trọng. Nếu một số vòng lặp đồng thuận thất bại, Dusk không chỉ ngồi chờ mãi mãi. Các vòng lặp trước đó có thể vẫn mở trong khi những vòng mới bắt đầu, để những provisioners vẫn còn hoạt động có thêm cơ hội đạt được ngưỡng (quorum) cần thiết. $DOS \nCó một chi tiết thú vị khác ở đây. Nhiều vòng lặp có thể kết thúc với các khối ứng viên khác nhau. Dusk xử lý điều này bằng cách ưu tiên cho vòng lặp thành công thấp nhất. Đây là một quy tắc nhỏ, nhưng những quy tắc nhỏ như vậy chính là thứ khiến các hệ thống đồng thuận vận hành được khi mọi thứ trở nên rối ren.\n\nRồi đến Yêu cầu Khối Khẩn cấp (Emergency Block Request - EBR). Nếu các EBR đại diện cho đa số lượng stake của mạng được thu thập, Dusk có thể tạo một khối khẩn cấp rỗng. Nó không cố nhồi giao dịch vào đó. Nhiệm vụ chính là giữ chuỗi tiếp tục chạy và tạo điểm khởi đầu mới cho một lần thử đồng thuận khác.\nQuan điểm của tôi là điều này ít liên quan đến “khối khẩn cấp” theo đúng nghĩa và nhiều hơn là thiết kế cho sự tham gia không hoàn hảo. Mạng staking phụ thuộc vào việc con người và máy móc luôn trực tuyến, và giả định đó sớm hay muộn sẽ bị kiểm chứng. Vẫn còn sớm, và cơ chế này có thể có giới hạn nếu tình trạng tham gia kém kéo dài quá lâu. Nhưng tôi thích việc Dusk nghĩ về khả năng phục hồi trước khi việc phục hồi thực sự cần thiết.\nCó lẽ đó là điểm nổi bật nhất đối với tôi. Hạ tầng tốt cũng cần có một kế hoạch cho những ngày khi một nửa mạng không hợp tác.\n\n\n