Lần đó cái tin nhắn cảnh báo nút lúc nửa đêm làm nổ điện thoại tôi, phản ứng đầu tiên của tôi là RPC đã bị quét—cho đến khi trong iftop toàn là các cổng kadcast cho thấy bên ngoài đang retransmission, tôi mới nhận ra. Thói quen “nhận được là chuyển hết cho mọi hàng xóm” của gossip truyền thống, khi mạng giữa các khu vực bị rung lắc (cross-zone jitter) thì lại thành bộ khuếch đại tự kích. Sau đó tôi ngồi soi mã nguồn Rusk và Bạch thư bản 2024, mục Section 2, mới thấy: Dusk thay broadcast bằng Kadcast không phải kiểu vá nhỏ để tiết kiệm băng thông, mà là viết lại tầng P2P thành cơ chế tìm kiếm theo khoảng cách XOR của Kademlia DHT. Mỗi nút lưu người liên hệ theo bucket; khi chuyển tiếp thì chỉ chọn một vài peer có khoảng cách XOR tăng dần để tạo chuỗi chuyển tiếp, không phải ngập tràn toàn mạng.
Nghiên cứu được trích trong bạch thư nói rằng so với gossip, nó tiết kiệm 25%–50% băng thông tương đối, và khi khối nhanh thì stale block giảm 10%–30%. Tôi xem đó như mức trần trong phòng lab. Còn môi trường thật thì provisioner node thỉnh thoảng vài phút lại ra vào, RTT Tokyo–Frankfurt cứ vọt lên tới khoảng 40ms; bucket được làm mới nhờ ping định kỳ chứ không phải sự kiện; vì vậy bảng định tuyến cũ đi—chỉ vài giây là các gói tin phải quay lại kiểu flooding. Băng thông tiết kiệm được lại bị đổ ngược về một nửa.
Trong cơ chế đồng thuận SA ba giai đoạn (Generation → 1st/2nd Reduction → Agreement), mọi thông điệp bỏ phiếu của ủy ban đều chạy qua Kadcast. Nếu đường chuyển tiếp bị đứt dưới điều kiện churn, không thu đủ 2/3 phiếu BLS theo luật định thì khối không còn chuyện “ít hay nhiều băng thông” nữa—mà là bị kẹt vòng.
Điểm nó mạnh hơn gossip là đúng nghĩa “tách rải điểm khởi nguồn của thông điệp”—không phụ thuộc vào các hàng xóm nối trực tiếp; đồng thời làm tăng độ khó để liên hệ IP nguồn của các giao dịch bị Phoenix che giấu thêm một bậc. Đổi lại là gánh nặng tư duy khi gỡ lỗi nặng nề: mempool mặc định 10000 bản ghi, chiến lược hết hạn cục bộ Rusk mặc định 3 ngày, và node-installer cấu hình 30 phút. Những tham số bị phân mảnh như vậy nhìn vào thì đối với người mới vận hành chẳng khác gì bug “ma”.
Tôi nghĩ Kadcast có đáng hay không thì không dựa vào con số 25%–50% trên giấy; nhìn ba việc “cứng”: bucket có hội tụ trong vòng 1 epoch khi nút rớt mạng không? Khi ở tình huống SA vote trên hai phân khu, có thể dựa vào tiểu đồ liên thông còn lại để gom đủ 67% phiếu hợp lệ không? Và khi tỉ lệ nút băng thông gia đình của Provisioner tăng lên thì độ trễ ở đuôi (tail latency) có bị sập không. Qua được ba ải này, thì nó đúng là “phân phối có cấu trúc” mà một chuỗi tài chính cần; không qua, thì đó là một bài báo đẹp dùng để đào hố cho đội vận hành. #disk @Dusk $DUSK
Nghiên cứu được trích trong bạch thư nói rằng so với gossip, nó tiết kiệm 25%–50% băng thông tương đối, và khi khối nhanh thì stale block giảm 10%–30%. Tôi xem đó như mức trần trong phòng lab. Còn môi trường thật thì provisioner node thỉnh thoảng vài phút lại ra vào, RTT Tokyo–Frankfurt cứ vọt lên tới khoảng 40ms; bucket được làm mới nhờ ping định kỳ chứ không phải sự kiện; vì vậy bảng định tuyến cũ đi—chỉ vài giây là các gói tin phải quay lại kiểu flooding. Băng thông tiết kiệm được lại bị đổ ngược về một nửa.
Trong cơ chế đồng thuận SA ba giai đoạn (Generation → 1st/2nd Reduction → Agreement), mọi thông điệp bỏ phiếu của ủy ban đều chạy qua Kadcast. Nếu đường chuyển tiếp bị đứt dưới điều kiện churn, không thu đủ 2/3 phiếu BLS theo luật định thì khối không còn chuyện “ít hay nhiều băng thông” nữa—mà là bị kẹt vòng.
Điểm nó mạnh hơn gossip là đúng nghĩa “tách rải điểm khởi nguồn của thông điệp”—không phụ thuộc vào các hàng xóm nối trực tiếp; đồng thời làm tăng độ khó để liên hệ IP nguồn của các giao dịch bị Phoenix che giấu thêm một bậc. Đổi lại là gánh nặng tư duy khi gỡ lỗi nặng nề: mempool mặc định 10000 bản ghi, chiến lược hết hạn cục bộ Rusk mặc định 3 ngày, và node-installer cấu hình 30 phút. Những tham số bị phân mảnh như vậy nhìn vào thì đối với người mới vận hành chẳng khác gì bug “ma”.
Tôi nghĩ Kadcast có đáng hay không thì không dựa vào con số 25%–50% trên giấy; nhìn ba việc “cứng”: bucket có hội tụ trong vòng 1 epoch khi nút rớt mạng không? Khi ở tình huống SA vote trên hai phân khu, có thể dựa vào tiểu đồ liên thông còn lại để gom đủ 67% phiếu hợp lệ không? Và khi tỉ lệ nút băng thông gia đình của Provisioner tăng lên thì độ trễ ở đuôi (tail latency) có bị sập không. Qua được ba ải này, thì nó đúng là “phân phối có cấu trúc” mà một chuỗi tài chính cần; không qua, thì đó là một bài báo đẹp dùng để đào hố cho đội vận hành. #disk @Dusk $DUSK