Tuần trước, nút của tôi trên một thiết lập relay testnet ở Karachi cứ bị lag mỗi khi tôi thử mô phỏng lưu lượng tin nhắn nặng. Tôi nghĩ vấn đề chỉ đơn giản là do băng thông của mình yếu—một vấn đề thường gặp với ISP địa phương mà trước đây tôi từng gặp.
Sau đó tôi thực sự đọc cách Dusk xử lý giao tiếp ngang hàng và nhận ra suy nghĩ của tôi là ngược. Hiện tượng lag không phải do băng thông thô, mà là do kiểu broadcast lan truyền theo kiểu “tràn” kém hiệu quả: mỗi nút sẽ lặp lại tin nhắn cho tất cả các hàng xóm của nó, bất kể khoảng cách.
Dusk dùng Kadcast, được xây dựng trên cấu trúc khoảng cách XOR của Kademlia. Các nút chỉ chuyển tiếp tin nhắn đến những peer được chọn ở khoảng cách tăng dần, tạo hiệu ứng dây chuyền thay vì lặp lại mù quáng. Cách này cắt giảm đáng kể các lần truyền dư thừa so với các giao thức gossip—những giao thức mà Ethereum dựa vào. Nó cũng tự nhiên làm mờ nguồn gốc xuất phát của tin nhắn, vì tin nhắn phải đi qua nhiều chặng (hop) trước khi đến được mạng diện rộng, điều này phù hợp với định hướng bảo mật của Dusk cho các giao dịch tài chính.
Điều mà whitepaper không diễn giải rõ ràng là các con số độ trễ (latency) trong thế giới thực khi mạng gặp điều kiện xấu—ví dụ như chuyện gì xảy ra cụ thể trong lúc nghẽn cục bộ theo khu vực ở những nơi hạ tầng không ổn định. Đây là khoảng trống mà tôi không thể điền một cách chắc chắn.
Bài kiểm tra thực sự cho DUSK là liệu Kadcast có giữ được lợi thế hiệu quả của mình khi số lượng nút tăng lên hàng nghìn dưới áp lực mạng thực tế hay không, chứ không chỉ trong các điều kiện testnet được kiểm soát.
Ở đây có ai đã từng chạy một nút Dusk đủ lâu để tự mình nhận thấy khác biệt về tốc độ lan truyền không?
#dusk $DUSK @Dusk
Sau đó tôi thực sự đọc cách Dusk xử lý giao tiếp ngang hàng và nhận ra suy nghĩ của tôi là ngược. Hiện tượng lag không phải do băng thông thô, mà là do kiểu broadcast lan truyền theo kiểu “tràn” kém hiệu quả: mỗi nút sẽ lặp lại tin nhắn cho tất cả các hàng xóm của nó, bất kể khoảng cách.
Dusk dùng Kadcast, được xây dựng trên cấu trúc khoảng cách XOR của Kademlia. Các nút chỉ chuyển tiếp tin nhắn đến những peer được chọn ở khoảng cách tăng dần, tạo hiệu ứng dây chuyền thay vì lặp lại mù quáng. Cách này cắt giảm đáng kể các lần truyền dư thừa so với các giao thức gossip—những giao thức mà Ethereum dựa vào. Nó cũng tự nhiên làm mờ nguồn gốc xuất phát của tin nhắn, vì tin nhắn phải đi qua nhiều chặng (hop) trước khi đến được mạng diện rộng, điều này phù hợp với định hướng bảo mật của Dusk cho các giao dịch tài chính.
Điều mà whitepaper không diễn giải rõ ràng là các con số độ trễ (latency) trong thế giới thực khi mạng gặp điều kiện xấu—ví dụ như chuyện gì xảy ra cụ thể trong lúc nghẽn cục bộ theo khu vực ở những nơi hạ tầng không ổn định. Đây là khoảng trống mà tôi không thể điền một cách chắc chắn.
Bài kiểm tra thực sự cho DUSK là liệu Kadcast có giữ được lợi thế hiệu quả của mình khi số lượng nút tăng lên hàng nghìn dưới áp lực mạng thực tế hay không, chứ không chỉ trong các điều kiện testnet được kiểm soát.
Ở đây có ai đã từng chạy một nút Dusk đủ lâu để tự mình nhận thấy khác biệt về tốc độ lan truyền không?
#dusk $DUSK @Dusk
