Nếu một giao dịch được gửi đi từ tay bạn, thử thách thực sự không phải là máy cục bộ của bạn nhanh đến đâu, mà là thông điệp đó có thể được chuyển tiếp một cách có trật tự tới đúng nút cần nó hay không. Người dùng không nhìn thấy chặng đường này, nhưng nó lại ảnh hưởng đến vì sao sự đồng thuận diễn ra chậm và vì sao xuất hiện xử lý trùng lặp.
Hãy hình dung mạng như một thành phố: cách thô bạo nhất là tại mỗi ngã tư, sao chép cùng một thông báo để gửi tới tất cả các ngã tư liền kề. Thông báo tất nhiên sẽ lan rộng, nhưng cái giá phải trả là quá nhiều trùng lặp. Tư duy của Kadcast không phải để mọi nút cùng rao một lần, mà là tận dụng khoảng cách trong Kademlia và khoảng cách XOR để đưa thông điệp vào một cấu trúc chuyển tiếp được tổ chức, giảm việc phát tán ngẫu nhiên tràn lan.
Điều quan trọng nhất ở đây không phải là “Dusk đã nhanh đến mức nào”, mà là cuối cùng bạn có được một câu hỏi chính xác hơn: chi phí ở đâu trong việc phủ (coverage) thông điệp? Thời gian thực thi chỉ trả lời tốc độ các nút xử lý công việc, còn đường đi truyền thông điệp sẽ phải trả lời cách thông điệp được gửi tới các nút khác như thế nào. Nếu không nhìn rõ cả hai phần, bạn không thể lấy một kết quả cục bộ làm thành chỉ số hiệu năng tổng thể.
Tất nhiên, Kadcast trong whitepaper là thiết kế cơ chế, không phải báo cáo benchmark cho mainnet hiện tại. Quy mô nút, biến động mạng và tuyến đường thực tế đều có thể thay đổi kết quả cuối cùng. Nhìn vào @Dusk , tôi sẽ vẽ ra trước đường đi này, rồi mới đánh giá liệu sự đồng thuận có bị kìm lại bởi việc phát quảng bá lặp lại hay không. $DUSK là token gốc của mạng, không thể dùng nó để làm bằng chứng cho bức tranh này; còn phần thảo luận kỹ thuật #dusk cũng nên bắt đầu từ cách thông điệp được truyền tới.
Xét từ góc độ sử dụng thông thường, một thông điệp xác nhận không tự nhiên xuất hiện—nó phải đi qua việc truyền, nhận và xử lý trùng lặp. Chúng ta đương nhiên không thể rút kết luận cho mainnet chỉ từ whitepaper một cách tùy tiện, nhưng có thể bắt đầu bằng cách đặt đúng câu hỏi: nếu một công cụ thực thi mà vẫn phủ thông điệp theo cách kém hiệu quả, thì tầng nào sẽ kéo chậm trải nghiệm cuối cùng mà người dùng nhìn thấy? Việc đưa đường đi vào đánh giá hiệu năng chính là điều đáng quan sát ở bộ cơ chế này.
Hãy xem đường đi trước, rồi mới xem các con số—trình tự không thể đảo ngược. Đừng chỉ nhìn vào tốc độ thực thi.
Hãy hình dung mạng như một thành phố: cách thô bạo nhất là tại mỗi ngã tư, sao chép cùng một thông báo để gửi tới tất cả các ngã tư liền kề. Thông báo tất nhiên sẽ lan rộng, nhưng cái giá phải trả là quá nhiều trùng lặp. Tư duy của Kadcast không phải để mọi nút cùng rao một lần, mà là tận dụng khoảng cách trong Kademlia và khoảng cách XOR để đưa thông điệp vào một cấu trúc chuyển tiếp được tổ chức, giảm việc phát tán ngẫu nhiên tràn lan.
Điều quan trọng nhất ở đây không phải là “Dusk đã nhanh đến mức nào”, mà là cuối cùng bạn có được một câu hỏi chính xác hơn: chi phí ở đâu trong việc phủ (coverage) thông điệp? Thời gian thực thi chỉ trả lời tốc độ các nút xử lý công việc, còn đường đi truyền thông điệp sẽ phải trả lời cách thông điệp được gửi tới các nút khác như thế nào. Nếu không nhìn rõ cả hai phần, bạn không thể lấy một kết quả cục bộ làm thành chỉ số hiệu năng tổng thể.
Tất nhiên, Kadcast trong whitepaper là thiết kế cơ chế, không phải báo cáo benchmark cho mainnet hiện tại. Quy mô nút, biến động mạng và tuyến đường thực tế đều có thể thay đổi kết quả cuối cùng. Nhìn vào @Dusk , tôi sẽ vẽ ra trước đường đi này, rồi mới đánh giá liệu sự đồng thuận có bị kìm lại bởi việc phát quảng bá lặp lại hay không. $DUSK là token gốc của mạng, không thể dùng nó để làm bằng chứng cho bức tranh này; còn phần thảo luận kỹ thuật #dusk cũng nên bắt đầu từ cách thông điệp được truyền tới.
Xét từ góc độ sử dụng thông thường, một thông điệp xác nhận không tự nhiên xuất hiện—nó phải đi qua việc truyền, nhận và xử lý trùng lặp. Chúng ta đương nhiên không thể rút kết luận cho mainnet chỉ từ whitepaper một cách tùy tiện, nhưng có thể bắt đầu bằng cách đặt đúng câu hỏi: nếu một công cụ thực thi mà vẫn phủ thông điệp theo cách kém hiệu quả, thì tầng nào sẽ kéo chậm trải nghiệm cuối cùng mà người dùng nhìn thấy? Việc đưa đường đi vào đánh giá hiệu năng chính là điều đáng quan sát ở bộ cơ chế này.
Hãy xem đường đi trước, rồi mới xem các con số—trình tự không thể đảo ngược. Đừng chỉ nhìn vào tốc độ thực thi.