Ini adalah beberapa hasil yang menarik. Selalu menyenangkan melihat MegaETH berada di atas: ) Untuk menempatkan data dalam beberapa konteks, latensi end-to-end dari permintaan RPC terdiri dari tiga komponen: (1) latensi propagasi kecepatan cahaya dari/ke pengamat ke/dari server, (2) waktu yang dibutuhkan server untuk mengambil dan memproses data yang diminta, (3) waktu yang dibutuhkan pengamat untuk mengunduh respons. Seperti yang Anda sebutkan, metode RPC yang diuji berada di sisi yang lebih ringan, baik dalam hal biaya komputasi maupun dalam hal ukuran data. Ini berarti eksperimen terutama diuji (1), yaitu, latensi propagasi antara pengamat dan server RPC. Jangan salah paham–RPC MegaETH juga cukup kuat pada (2) dan (3) dan akan menarik untuk melihat eksperimen yang membuat mereka stres! Jadi, bagaimana kita menyempurnakan latensi propagasi? Sebenarnya, kenop tidak terlalu banyak. Pertama, kita dapat menyebarkan server RPC di beberapa wilayah geografis, dan secara otomatis merutekan permintaan ke server terdekat. Ini seperti rantai makanan cepat saji yang membuka toko di mana-mana – selalu ada cabang di dekatnya! Lebih tepatnya, memiliki server yang didistribusikan secara geografis mengurangi jarak fisik antara pengguna dan server. Kedua, kita dapat mengoptimalkan topologi jaringan. Bahkan jika itu antara pasangan pengirim dan penerima yang sama, latensi propagasi bervariasi berdasarkan jalur jaringan aktual yang dilalui. Misalnya, antara Pantai Timur AS dan Asia, latensi dapat bervariasi 2x tergantung pada apakah paket data melewati Pasifik atau melalui Eropa. Terkadang, bahkan ada beberapa jalur jaringan yang mengikuti rute geografis yang sama; beberapa lebih padat daripada yang lain yang menginduksi latensi yang lebih tinggi. Ini seperti memiliki banyak jalan raya untuk dipilih dari titik A ke titik B. Keuntungan latensi yang Anda amati kemungkinan besar berasal dari kami yang mengoptimalkan rute.