@Dusk Nhiều người nói rằng mạng P2P chỉ cần có đủ nhiều nút thì sẽ tự nhiên trở nên nhanh hơn, nhưng tôi vẫn chưa thực sự tin vào câu đó. Mãi đến khi đọc $DUSK về các Core Components, tôi nhận ra rằng Kadcast không dùng gossip ngẫu nhiên, mà là structured overlay. Mục tiêu của nó là giảm băng thông và giúp độ trễ có thể dự đoán tốt hơn. Lựa chọn này khiến tôi thay đổi cách đánh giá: hiệu quả mạng không chỉ phụ thuộc vào số lượng nút, mà còn phụ thuộc vào việc các thông điệp được truyền qua các mối liên kết như thế nào để đạt được đích.

Đối với người vận hành nút, đây không phải là khái niệm trừu tượng. Khi tuyến đường có cấu trúc hơn, nút sẽ phụ thuộc nhiều hơn vào chất lượng việc phát hiện hàng xóm và tính liên thông của mạng. Và một khi môi trường vận hành chặn các kênh UDP hoặc địa chỉ của Kadcast, về lý thuyết độ trễ có thể dự đoán sẽ không tự động trở thành hiệu năng mạng thực sự có thể sử dụng. Điều mà người vận hành nhìn thấy có thể chỉ là thông điệp không nhận được hoặc khối bị trễ, nhưng lại phải tự phán đoán rốt cuộc đó là vấn đề do phiên bản, vấn đề do chiến lược mạng hay do cấu hình sai.

Các kịch bản chịu áp lực rất cụ thể. Khi có thêm các hoạt động thị trường, ứng dụng mong giao dịch được xác nhận nhanh hơn, nhưng một nút then chốt lại bị tường lửa chặn mất kết nối. Hệ thống này không đơn giản là “nút càng nhiều thì càng an toàn”. Khả năng truy cập được của các nút cũng có thể quyết định liệu thông điệp có thể lan truyền đúng theo thiết kế hay không, và cuối cùng chi phí cho việc khắc phục lại rơi vào người đang vận hành các nút. Vì vậy, khi tôi xem hiệu năng mạng của DUSK, tôi không chỉ nhìn thời gian khối hay số lượng nút; tôi còn muốn đối chiếu quan hệ hàng xóm của Kadcast, các cổng truyền thông, và xem liệu các nút bị tụt lại có tín hiệu giám sát trực quan nào để tham chiếu hay không. @Dusk chọn truyền lan theo cấu trúc, và việc nó có chuyển hóa được tính dự đoán thành thứ thực sự nằm trong tay người vận hành hay không—đó mới là phần mà #dusk mạng cần chứng minh.