Khi thật sự thấy khó chịu, thường không phải là một khối (block) đột nhiên to lên, mà là mạng bắt đầu “không nghe lời”.
Lần này, khi xem lớp truyền (propagation layer) của #dusk , tôi lại bị một chi tiết thu hút: nó không đơn giản coi hiệu suất mạng là “băng thông càng lớn càng tốt”, mà cố gắng can thiệp ngay từ bản thân cách một tin nhắn đi như thế nào.
@Dusk sử dụng Kadcast theo logic truyền có định hướng dựa trên khoảng cách giữa các nút. Nút không nhận được một tin nhắn rồi vô não lan tỏa đến tất cả các hàng xóm, mà sẽ chọn bước tiếp theo dựa trên quan hệ định tuyến, để tin nhắn đi theo một con đường rõ ràng hơn. Thiết kế này có vẻ không “đã mắt” cho lắm, nhưng với blockchain công khai thì nó lại rất quan trọng.
Vì rắc rối lớn nhất của Gossip không phải là “chậm”, mà là “trùng lặp”.
Cùng một giao dịch đi vòng qua nhiều nút khác nhau rồi quay lại, mạng vẫn phải tiếp tục chuyển tiếp, xác thực và lưu đệm. Chỉ cần số lượng nút tăng lên, độ dư thừa của tin nhắn sẽ dễ dàng làm ngốn băng thông lẫn CPU cùng lúc. Cốt lõi Kadcast muốn giải quyết chính là giảm kiểu truyền vô hiệu này, để tài nguyên mạng được dùng vào những tin nhắn thực sự cần được chuyển đến.
Nhưng tôi sẽ không gật đầu chỉ vì thấy cụm từ “giảm tiêu hao băng thông”.
Thiết kế này sợ nhất chính là mạng trong thực tế. Khi các nút đột nhiên mất kết nối, độ trễ tăng vọt, hay các hàng xóm trong bảng định tuyến bị vô hiệu, thì “đường đi ngắn nhất” trong lý thuyết rất có thể ngay lập tức biến thành một con đường bị cắt. Để đảm bảo tin nhắn cuối cùng vẫn tới nơi, hệ thống buộc phải chuẩn bị cơ chế đường thay thế và định tuyến lại. Cơ chế dự phòng càng phức tạp thì mức giằng co giữa hiệu quả truyền và chi phí bảo trì càng rõ rệt.
Hơn nữa, các nút của blockchain công khai không phải là máy chủ cố định trong phòng thí nghiệm.
Tôi ngược lại nghĩ rằng, đây mới là điểm đáng tiếp tục quan sát ở lớp truyền của $DUSK .
Nếu Kadcast vẫn giữ được sự ổn định trong các tình huống bẩn như nút ra vào quy mô lớn, độ trễ xuyên vùng và phân mảnh mạng, thì nó không chỉ tiết kiệm băng thông—mà còn giúp các nút bình thường dễ tham gia vào mạng hơn.
Nhưng nếu cứ gặp lỗi định tuyến là lại thường xuyên phải quay lui (fallback), thì những hiệu quả lý thuyết đẹp đẽ phía trước cũng không còn nhiều ý nghĩa.
Blockchain công khai cuối cùng không phải là ghép được theo điều gì đẹp hơn trong bản whitepaper, mà là liệu đến 3 giờ sáng khi mạng gặp sự cố, các nút có tự tìm lại đường được hay không. Các bạn nghĩ sao: với thay đổi ở lớp truyền này, nó sẽ cộng điểm cho sự phi tập trung lâu dài của blockchain, hay lại đẩy độ phức tạp của hệ thống lên cao hơn?
Lần này, khi xem lớp truyền (propagation layer) của #dusk , tôi lại bị một chi tiết thu hút: nó không đơn giản coi hiệu suất mạng là “băng thông càng lớn càng tốt”, mà cố gắng can thiệp ngay từ bản thân cách một tin nhắn đi như thế nào.
@Dusk sử dụng Kadcast theo logic truyền có định hướng dựa trên khoảng cách giữa các nút. Nút không nhận được một tin nhắn rồi vô não lan tỏa đến tất cả các hàng xóm, mà sẽ chọn bước tiếp theo dựa trên quan hệ định tuyến, để tin nhắn đi theo một con đường rõ ràng hơn. Thiết kế này có vẻ không “đã mắt” cho lắm, nhưng với blockchain công khai thì nó lại rất quan trọng.
Vì rắc rối lớn nhất của Gossip không phải là “chậm”, mà là “trùng lặp”.
Cùng một giao dịch đi vòng qua nhiều nút khác nhau rồi quay lại, mạng vẫn phải tiếp tục chuyển tiếp, xác thực và lưu đệm. Chỉ cần số lượng nút tăng lên, độ dư thừa của tin nhắn sẽ dễ dàng làm ngốn băng thông lẫn CPU cùng lúc. Cốt lõi Kadcast muốn giải quyết chính là giảm kiểu truyền vô hiệu này, để tài nguyên mạng được dùng vào những tin nhắn thực sự cần được chuyển đến.
Nhưng tôi sẽ không gật đầu chỉ vì thấy cụm từ “giảm tiêu hao băng thông”.
Thiết kế này sợ nhất chính là mạng trong thực tế. Khi các nút đột nhiên mất kết nối, độ trễ tăng vọt, hay các hàng xóm trong bảng định tuyến bị vô hiệu, thì “đường đi ngắn nhất” trong lý thuyết rất có thể ngay lập tức biến thành một con đường bị cắt. Để đảm bảo tin nhắn cuối cùng vẫn tới nơi, hệ thống buộc phải chuẩn bị cơ chế đường thay thế và định tuyến lại. Cơ chế dự phòng càng phức tạp thì mức giằng co giữa hiệu quả truyền và chi phí bảo trì càng rõ rệt.
Hơn nữa, các nút của blockchain công khai không phải là máy chủ cố định trong phòng thí nghiệm.
Tôi ngược lại nghĩ rằng, đây mới là điểm đáng tiếp tục quan sát ở lớp truyền của $DUSK .
Nếu Kadcast vẫn giữ được sự ổn định trong các tình huống bẩn như nút ra vào quy mô lớn, độ trễ xuyên vùng và phân mảnh mạng, thì nó không chỉ tiết kiệm băng thông—mà còn giúp các nút bình thường dễ tham gia vào mạng hơn.
Nhưng nếu cứ gặp lỗi định tuyến là lại thường xuyên phải quay lui (fallback), thì những hiệu quả lý thuyết đẹp đẽ phía trước cũng không còn nhiều ý nghĩa.
Blockchain công khai cuối cùng không phải là ghép được theo điều gì đẹp hơn trong bản whitepaper, mà là liệu đến 3 giờ sáng khi mạng gặp sự cố, các nút có tự tìm lại đường được hay không. Các bạn nghĩ sao: với thay đổi ở lớp truyền này, nó sẽ cộng điểm cho sự phi tập trung lâu dài của blockchain, hay lại đẩy độ phức tạp của hệ thống lên cao hơn?