Ánh hoàng hôn đã kéo tôi vào một hố thỏ khác tối nay—không phải về quyền riêng tư lần này, mà là về cách các khối được chuyển vật lý từ một node đến mọi node khác mà không làm mạng nghẽn chính nó.
hầu hết các blockchain vẫn dùng giao thức gossip:
một node nghe về một khối, chuyển tiếp nó cho các peer ngẫu nhiên, các peer đó lại chuyển tiếp, và chính dữ liệu đó liên tục bị truyền lại qua những đường đi dự phòng. Dusk đã thay điều đó bằng Kadcast, được xây dựng trên cơ chế định tuyến kiểu Kademlia dựa theo khoảng cách XOR. Mỗi node nhận một ID nhị phân, và khoảng cách giữa hai node bất kỳ chỉ đơn giản là XOR các ID của chúng—việc này sắp xếp các peer vào các "k-buckets" theo cấu trúc thay vì kết nối ngẫu nhiên. Khi một khối cần được phát tán, nó không dội tràn toàn mạng (flood), mà lan truyền theo những đường đi xác định dựa trên thước đo khoảng cách đó. Các nghiên cứu được trích dẫn đằng sau thiết kế cho thấy mức sử dụng băng thông giảm khoảng 25–50% so với gossip, và có vẻ như còn cắt giảm tỷ lệ khối lỗi thời/khối mồ côi (stale/orphaned) thêm 10–30% trong các điều kiện có tốc độ tạo khối nhanh.
Điều khiến tôi chú ý là: Kadcast còn "muối" (salt) thước đo khoảng cách cho mỗi lần phát sóng, bằng cách dùng một hash lấy từ chính dữ liệu của khối hoặc giao dịch—vì vậy vị trí tương đối của node bị ngẫu nhiên hóa theo kiểu giả lập trong mọi vòng lan truyền. Cụ thể là để ngăn kẻ tấn công dự đoán các tuyến đường định tuyến và bố trí bản thân nhằm chặn hoặc làm chậm một số thông điệp cụ thể—một cơ chế phòng vệ chống Eclipse được cài sẵn trực tiếp vào tầng mạng, chứ không phải gắn thêm như một quy tắc tường lửa đâu đó.
@Dusk cần điều này vì Succinct Attestation phụ thuộc vào các ủy ban trao đổi phiếu bầu nhanh và đáng tin cậy—một tầng mạng chậm chạp, bị tắc nghẽn sẽ âm thầm phá vỡ tính finality nhanh mà sự đồng thuận hứa hẹn trên giấy. $DUSK đảm bảo tốc độ của các validator chỉ nhanh đến mức các thông điệp đến được với họ. Một giải pháp hay cho một vấn đề mà phần lớn chuỗi thậm chí không bao giờ gọi tên. Việc định tuyến có cấu trúc như thế này liệu có còn đứng vững khi số lượng validator thực sự tăng lên hàng nghìn, hay việc duy trì k-bucket sẽ trở thành một nút thắt cổ chai riêng theo thời gian?
#dusk $DUSK @Dusk
hầu hết các blockchain vẫn dùng giao thức gossip:
một node nghe về một khối, chuyển tiếp nó cho các peer ngẫu nhiên, các peer đó lại chuyển tiếp, và chính dữ liệu đó liên tục bị truyền lại qua những đường đi dự phòng. Dusk đã thay điều đó bằng Kadcast, được xây dựng trên cơ chế định tuyến kiểu Kademlia dựa theo khoảng cách XOR. Mỗi node nhận một ID nhị phân, và khoảng cách giữa hai node bất kỳ chỉ đơn giản là XOR các ID của chúng—việc này sắp xếp các peer vào các "k-buckets" theo cấu trúc thay vì kết nối ngẫu nhiên. Khi một khối cần được phát tán, nó không dội tràn toàn mạng (flood), mà lan truyền theo những đường đi xác định dựa trên thước đo khoảng cách đó. Các nghiên cứu được trích dẫn đằng sau thiết kế cho thấy mức sử dụng băng thông giảm khoảng 25–50% so với gossip, và có vẻ như còn cắt giảm tỷ lệ khối lỗi thời/khối mồ côi (stale/orphaned) thêm 10–30% trong các điều kiện có tốc độ tạo khối nhanh.
Điều khiến tôi chú ý là: Kadcast còn "muối" (salt) thước đo khoảng cách cho mỗi lần phát sóng, bằng cách dùng một hash lấy từ chính dữ liệu của khối hoặc giao dịch—vì vậy vị trí tương đối của node bị ngẫu nhiên hóa theo kiểu giả lập trong mọi vòng lan truyền. Cụ thể là để ngăn kẻ tấn công dự đoán các tuyến đường định tuyến và bố trí bản thân nhằm chặn hoặc làm chậm một số thông điệp cụ thể—một cơ chế phòng vệ chống Eclipse được cài sẵn trực tiếp vào tầng mạng, chứ không phải gắn thêm như một quy tắc tường lửa đâu đó.
@Dusk cần điều này vì Succinct Attestation phụ thuộc vào các ủy ban trao đổi phiếu bầu nhanh và đáng tin cậy—một tầng mạng chậm chạp, bị tắc nghẽn sẽ âm thầm phá vỡ tính finality nhanh mà sự đồng thuận hứa hẹn trên giấy. $DUSK đảm bảo tốc độ của các validator chỉ nhanh đến mức các thông điệp đến được với họ. Một giải pháp hay cho một vấn đề mà phần lớn chuỗi thậm chí không bao giờ gọi tên. Việc định tuyến có cấu trúc như thế này liệu có còn đứng vững khi số lượng validator thực sự tăng lên hàng nghìn, hay việc duy trì k-bucket sẽ trở thành một nút thắt cổ chai riêng theo thời gian?
#dusk $DUSK @Dusk
