Det här är några intressanta resultat. Det är alltid trevligt att se MegaETH kommer på toppen :) För att sätta data i ett sammanhang består svarstiden från slutpunkt till slutpunkt för en RPC-begäran av tre komponenter: (1) fördröjning av ljusets spridningshastighet från/till observatören till/från servern, (2) den tid det tar för servern att hämta och efterbehandla begärda data, (3) den tid det tar för observatören att ladda ned svaret. Som du nämnde är de RPC-metoder som testas på den lättare sidan, både när det gäller beräkningskostnader och när det gäller datastorlek. Detta innebär att experimenten huvudsakligen testades (1), dvs. utbredningslatensen mellan observatörer och RPC-servrarna. Missförstå mig inte – MegaETH:s RPC:er är också ganska starka på (2) och (3) och det skulle vara intressant att se experiment som stressar dem! Så, hur finjusterar vi utbredningslatensen? Egentligen finns det inte så många knoppar. För det första kan vi distribuera RPC-servrar i flera geografiska regioner och automatiskt dirigera begäran till den närmaste servern. Det är som snabbmatskedjor som öppnar butiker överallt – det finns alltid en filial i närheten! Mer exakt, att ha geodistribuerade servrar minskar det fysiska avståndet mellan användare och servrar. För det andra kan vi optimera nätverkstopologin. Även om det är mellan samma par av avsändare och mottagare varierar spridningsfördröjningen beroende på den faktiska nätverkssökvägen som korsas. Mellan USA:s östkust och Asien kan latensen till exempel variera med 2 gånger beroende på om datapaketen går genom Stilla havet eller genom Europa. Ibland finns det till och med flera nätverksvägar som följer samma geografiska väg. Vissa är mer överbelastade än andra, vilket inducerar högre latens. Det är som att ha flera motorvägar att välja mellan från punkt A till punkt B. De latensfördelar du observerade kom troligen från att vi optimerade rutten.