Nói về hiệu năng blockchain, trong số mười người thì chín người phản ứng đầu tiên là TPS. Còn người còn lại có thể nhìn vào độ trễ. Nhưng với dự án Dusk thì sao? Bạn lật whitepaper lên và đọc kỹ, sẽ thấy có một thứ đáng để “soi” hơn cả tốc độ giao dịch—đó là giữa các node chúng “nói chuyện” với nhau như thế nào.
Bánh còn thì vẫn ổn chứ, BTC rớt không nhiều!
Mình nói vậy không phải vì TPS không quan trọng, mà vì “tính nhanh” và “truyền nhanh” vốn là hai chuyện khác nhau. Nếu tầng thực thi của bạn mạnh cỡ nào, thiết kế đồng thuận tinh xảo ra sao mà thông điệp bị kẹt trong mạng node—thì đề xuất không tới được cho bộ xác thực, kết quả xác thực không quay về được cho ủy ban ratification—thì cả quy trình ba giai đoạn sẽ phải chờ đợi. Khối tới trễ vài giây: nhẹ thì trải nghiệm bị giảm; nặng thì các node khác nhau nhìn thấy các khối ứng viên khác nhau, và tỉ lệ stale block cứ tăng vọt.
Dusk chọn con đường Kadcast. Nó không phải kiểu broadcast “gặp ai chuyển nấy” như Gossip, mà là một mạng phủ có cấu trúc dựa trên Kademlia DHT: khoảng cách XOR giữa các ID node quyết định tuyến đường, và các thông điệp được “triển khai” theo từng tầng như một cái cây. Nghe có vẻ hàn lâm đúng không? Nhưng logic cốt lõi thực ra chỉ là một câu: mỗi thông điệp chỉ đi đúng đường của nó, không đi đường oan.
Whitepaper trích nghiên cứu nói rằng Kadcast tiết kiệm từ 25% đến 50% băng thông so với Gossip. Ví dụ trước đây tốn 100 phần băng thông, thì giờ khoảng 50 đến 75 phần—nhưng con số này không thể dịch trực tiếp thành “chi phí node giảm một nửa”. Cấu hình máy không đổi, tính toán proof không đổi, chi phí lưu trữ không đổi; chỉ thay đổi là chi phí truyền ở lớp mạng. Nhưng nói đi cũng phải nói lại: với người vận hành node, băng thông giảm một nửa đồng nghĩa gì? Nghĩa là với cùng điều kiện băng thông, có thể kết nối nhiều node hơn; hoặc với cùng quy mô node thì ít bị mắc kẹt bởi chi phí băng thông hơn.
Có một chi tiết rất đáng nói. Trong tài liệu node, cổng 9000/udp được đánh dấu là cổng bắt buộc cho Kadcast; Provisioner muốn tham gia đồng thuận thì phải đảm bảo kênh đó truy cập được. Còn 8080/tcp ngược lại là tùy chọn, chỉ bật lên khi cần giao diện truy vấn. Nói cách khác, Kadcast không phải là món trang trí trong sơ đồ kiến trúc—nó khóa thẳng vào ngưỡng để node có thể tham gia đồng thuận hay không.
Người quen với broadcast ngang hàng của BTC biết rằng, chuyện thông điệp đi xuyên qua mạng node từ trước tới giờ chưa từng là chuyện nhỏ. @Dusk $DUSK #dusk
Bánh còn thì vẫn ổn chứ, BTC rớt không nhiều!
Mình nói vậy không phải vì TPS không quan trọng, mà vì “tính nhanh” và “truyền nhanh” vốn là hai chuyện khác nhau. Nếu tầng thực thi của bạn mạnh cỡ nào, thiết kế đồng thuận tinh xảo ra sao mà thông điệp bị kẹt trong mạng node—thì đề xuất không tới được cho bộ xác thực, kết quả xác thực không quay về được cho ủy ban ratification—thì cả quy trình ba giai đoạn sẽ phải chờ đợi. Khối tới trễ vài giây: nhẹ thì trải nghiệm bị giảm; nặng thì các node khác nhau nhìn thấy các khối ứng viên khác nhau, và tỉ lệ stale block cứ tăng vọt.
Dusk chọn con đường Kadcast. Nó không phải kiểu broadcast “gặp ai chuyển nấy” như Gossip, mà là một mạng phủ có cấu trúc dựa trên Kademlia DHT: khoảng cách XOR giữa các ID node quyết định tuyến đường, và các thông điệp được “triển khai” theo từng tầng như một cái cây. Nghe có vẻ hàn lâm đúng không? Nhưng logic cốt lõi thực ra chỉ là một câu: mỗi thông điệp chỉ đi đúng đường của nó, không đi đường oan.
Whitepaper trích nghiên cứu nói rằng Kadcast tiết kiệm từ 25% đến 50% băng thông so với Gossip. Ví dụ trước đây tốn 100 phần băng thông, thì giờ khoảng 50 đến 75 phần—nhưng con số này không thể dịch trực tiếp thành “chi phí node giảm một nửa”. Cấu hình máy không đổi, tính toán proof không đổi, chi phí lưu trữ không đổi; chỉ thay đổi là chi phí truyền ở lớp mạng. Nhưng nói đi cũng phải nói lại: với người vận hành node, băng thông giảm một nửa đồng nghĩa gì? Nghĩa là với cùng điều kiện băng thông, có thể kết nối nhiều node hơn; hoặc với cùng quy mô node thì ít bị mắc kẹt bởi chi phí băng thông hơn.
Có một chi tiết rất đáng nói. Trong tài liệu node, cổng 9000/udp được đánh dấu là cổng bắt buộc cho Kadcast; Provisioner muốn tham gia đồng thuận thì phải đảm bảo kênh đó truy cập được. Còn 8080/tcp ngược lại là tùy chọn, chỉ bật lên khi cần giao diện truy vấn. Nói cách khác, Kadcast không phải là món trang trí trong sơ đồ kiến trúc—nó khóa thẳng vào ngưỡng để node có thể tham gia đồng thuận hay không.
Người quen với broadcast ngang hàng của BTC biết rằng, chuyện thông điệp đi xuyên qua mạng node từ trước tới giờ chưa từng là chuyện nhỏ. @Dusk $DUSK #dusk