Questi sono alcuni risultati interessanti. È sempre bello vedere MegaETH in cima : ) Per contestualizzare i dati, la latenza end-to-end di una richiesta RPC è composta da tre componenti: (1) la latenza di propagazione della velocità della luce da/per l'osservatore al/server, (2) il tempo necessario al server per acquisire e post-elaborare i dati richiesti, (3) il tempo necessario all'osservatore per scaricare la risposta. Come hai menzionato, i metodi RPC testati sono più leggeri, sia in termini di costo computazionale che di dimensione dei dati. Questo significa che gli esperimenti hanno principalmente testato (1), cioè la latenza di propagazione tra gli osservatori e i server RPC. Non fraintendermi: gli RPC di MegaETH sono anche piuttosto forti su (2) e (3) e sarebbe interessante vedere esperimenti che li mettano alla prova! Quindi, come possiamo ottimizzare la latenza di propagazione? In realtà, non ci sono molte leve. Prima di tutto, possiamo distribuire i server RPC in più regioni geografiche e instradare automaticamente le richieste al server più vicino. È come se le catene di fast food aprissero negozi ovunque: c'è sempre un ramo nelle vicinanze! Più precisamente, avere server geo-distribuiti riduce la distanza fisica tra utenti e server. In secondo luogo, possiamo ottimizzare la topologia di rete. Anche se si tratta della stessa coppia di mittente e destinatario, la latenza di propagazione varia in base al percorso di rete effettivamente percorso. Ad esempio, tra la costa est degli Stati Uniti e l'Asia, la latenza può variare di 2x a seconda che i pacchetti di dati passino attraverso il Pacifico o attraverso l'Europa. A volte, ci sono anche più percorsi di rete che seguono la stessa rotta geografica; alcuni sono più congestionati di altri, il che induce una latenza più alta. È come avere più autostrade tra il punto A e il punto B. I vantaggi di latenza che hai osservato sono probabilmente derivati dall'ottimizzazione del percorso da parte nostra.