Đây là một số kết quả thú vị. Thật tuyệt khi thấy MegaETH đứng đầu : ) Để đặt dữ liệu vào một số bối cảnh, độ trễ end-to-end của một yêu cầu RPC bao gồm ba thành phần: (1) độ trễ truyền ánh sáng từ/người quan sát đến/máy chủ, (2) thời gian mà máy chủ cần để lấy và xử lý dữ liệu được yêu cầu, (3) thời gian mà người quan sát cần để tải xuống phản hồi. Như bạn đã đề cập, các phương pháp RPC đang được thử nghiệm là nhẹ nhàng, cả về chi phí tính toán và kích thước dữ liệu. Điều này có nghĩa là các thí nghiệm chủ yếu kiểm tra (1), tức là độ trễ truyền giữa các người quan sát và các máy chủ RPC. Đừng hiểu sai ý tôi - các RPC của MegaETH cũng rất mạnh về (2) và (3) và sẽ thật thú vị khi thấy các thí nghiệm căng thẳng chúng! Vậy, làm thế nào để chúng ta tinh chỉnh độ trễ truyền? Thực ra, không có quá nhiều điều chỉnh. Đầu tiên, chúng ta có thể triển khai các máy chủ RPC ở nhiều khu vực địa lý khác nhau, và tự động định tuyến yêu cầu đến máy chủ gần nhất. Điều này giống như các chuỗi thức ăn nhanh mở cửa hàng khắp nơi - luôn có một chi nhánh gần bên! Cụ thể hơn, việc có các máy chủ phân bố theo địa lý giúp giảm khoảng cách vật lý giữa người dùng và máy chủ. Thứ hai, chúng ta có thể tối ưu hóa cấu trúc mạng. Ngay cả khi nó giữa cùng một cặp người gửi và người nhận, độ trễ truyền thay đổi dựa trên đường đi thực tế của mạng. Ví dụ, giữa Bờ Đông Hoa Kỳ và Châu Á, độ trễ có thể thay đổi gấp 2 lần tùy thuộc vào việc các gói dữ liệu đi qua Thái Bình Dương hay qua Châu Âu. Đôi khi, thậm chí có nhiều đường đi mạng theo cùng một lộ trình địa lý; một số đường bị tắc nghẽn hơn những đường khác, dẫn đến độ trễ cao hơn. Điều này giống như có nhiều xa lộ để chọn từ điểm A đến điểm B. Những lợi thế về độ trễ mà bạn quan sát được có lẽ đến từ việc chúng tôi tối ưu hóa lộ trình.