Khi tôi đọc phần Kadcast này, trong đầu tôi cứ so sánh với giao thức gossip của Ethereum. Logic của gossip rất đơn giản: bạn nhận một tin nhắn, chuyển tiếp cho tất cả các hàng xóm mà bạn biết, rồi các hàng xóm lại chuyển tiếp cho các hàng xóm của họ, cho đến khi toàn mạng đều nhận được. Nhưng ở đây có một vấn đề: khi số lượng node tăng lên, lượng chuyển tiếp trùng lặp sẽ tăng theo cấp số nhân.
Cách Kadcast làm thì khác. Nó dựa trên Kademlia DHT, phân tầng các node theo khoảng cách XOR. Mỗi node không chuyển tiếp tới tất cả các hàng xóm, mà chỉ chuyển tiếp tới các node được chọn ở khoảng cách XOR tăng dần. Tôi phải đọc tới hai lần mới hiểu được chỗ khéo léo của cơ chế này—nó tạo ra hiệu ứng dây chuyền (cascade), chứ không phải kiểu lan truyền tràn ngập (flooding).
Ví dụ, node A gửi một tin nhắn: nó chỉ chuyển tiếp tới một số node ở gần nhất. Những node này lại chuyển tiếp tới các node ở xa hơn. Số lượng node đích ở mỗi tầng được kiểm soát, không phải khuếch tán vô hạn. Bản whitepaper nói rằng cách này giảm đáng kể tổng số lần truyền dữ liệu cần thiết cho việc lan truyền mạng.
Vậy thiết kế này liên quan gì đến tình huống tài chính $DUSK ? Theo hiểu của tôi, tình huống tài chính đặc biệt nhạy với hai thứ: độ trễ và băng thông. Nếu một giao dịch broadcast mà phải mất hàng chục giây hoặc thậm chí cả phút mới lan tới toàn mạng thì tính “finality” theo từng giây sẽ không còn ý nghĩa. Kadcast nén thời gian lan truyền tới mức tối đa bằng cách đưa tin nhắn đến mọi node với số lần chuyển tiếp (relay) ít nhất, nhờ cấu trúc dạng cây.
Còn một điểm mà lúc đầu tôi chưa để ý: whitepaper đề cập rằng Kadcast tự nhiên làm “mờ” điểm xuất phát của tin nhắn. Vì node chỉ giao tiếp với các peer được chọn, không broadcast ra toàn mạng, nên kẻ tấn công rất khó truy ra một giao dịch được phát từ node nào. Điều này là một điểm cộng thêm cho câu chuyện về quyền riêng tư của Dusk@Dusk .
Tuy nhiên tôi vẫn có một câu hỏi. Whitepaper có so sánh gossip và Kadcast, nhưng chỉ đưa mô tả định tính, không có số liệu cụ thể về tiết kiệm băng thông. Tiết kiệm được bao nhiêu—tiết kiệm 30% hay 90%? Thiếu dữ liệu này, tôi thực sự khó đánh giá lợi thế hiệu quả của nó lớn đến đâu. Có lẽ quy mô này cần được trả lời bằng dữ liệu mạng thực tế sau khi triển khai trên mainnet. #dusk
Cách Kadcast làm thì khác. Nó dựa trên Kademlia DHT, phân tầng các node theo khoảng cách XOR. Mỗi node không chuyển tiếp tới tất cả các hàng xóm, mà chỉ chuyển tiếp tới các node được chọn ở khoảng cách XOR tăng dần. Tôi phải đọc tới hai lần mới hiểu được chỗ khéo léo của cơ chế này—nó tạo ra hiệu ứng dây chuyền (cascade), chứ không phải kiểu lan truyền tràn ngập (flooding).
Ví dụ, node A gửi một tin nhắn: nó chỉ chuyển tiếp tới một số node ở gần nhất. Những node này lại chuyển tiếp tới các node ở xa hơn. Số lượng node đích ở mỗi tầng được kiểm soát, không phải khuếch tán vô hạn. Bản whitepaper nói rằng cách này giảm đáng kể tổng số lần truyền dữ liệu cần thiết cho việc lan truyền mạng.
Vậy thiết kế này liên quan gì đến tình huống tài chính $DUSK ? Theo hiểu của tôi, tình huống tài chính đặc biệt nhạy với hai thứ: độ trễ và băng thông. Nếu một giao dịch broadcast mà phải mất hàng chục giây hoặc thậm chí cả phút mới lan tới toàn mạng thì tính “finality” theo từng giây sẽ không còn ý nghĩa. Kadcast nén thời gian lan truyền tới mức tối đa bằng cách đưa tin nhắn đến mọi node với số lần chuyển tiếp (relay) ít nhất, nhờ cấu trúc dạng cây.
Còn một điểm mà lúc đầu tôi chưa để ý: whitepaper đề cập rằng Kadcast tự nhiên làm “mờ” điểm xuất phát của tin nhắn. Vì node chỉ giao tiếp với các peer được chọn, không broadcast ra toàn mạng, nên kẻ tấn công rất khó truy ra một giao dịch được phát từ node nào. Điều này là một điểm cộng thêm cho câu chuyện về quyền riêng tư của Dusk@Dusk .
Tuy nhiên tôi vẫn có một câu hỏi. Whitepaper có so sánh gossip và Kadcast, nhưng chỉ đưa mô tả định tính, không có số liệu cụ thể về tiết kiệm băng thông. Tiết kiệm được bao nhiêu—tiết kiệm 30% hay 90%? Thiếu dữ liệu này, tôi thực sự khó đánh giá lợi thế hiệu quả của nó lớn đến đâu. Có lẽ quy mô này cần được trả lời bằng dữ liệu mạng thực tế sau khi triển khai trên mainnet. #dusk