Dette er noen interessante resultater. Det er alltid hyggelig å se at MegaETH kommer på topp :) For å sette dataene i en viss kontekst, består ende-til-ende-ventetiden til en RPC-forespørsel av tre komponenter: (1) latens for lysets hastighet fra/til observatøren til/fra serveren, (2) tiden det tar for serveren å hente og etterbehandle de forespurte dataene, (3) tiden det tar for observatøren å laste ned svaret. Som du nevnte, er RPC-metodene som testes på den lettere siden, både når det gjelder beregningskostnader og når det gjelder datastørrelse. Dette betyr eksperimentene som hovedsakelig ble testet (1), det vil si forplantningsforsinkelsen mellom observatører og RPC-serverne. Misforstå meg rett – MegaETHs RPC-er er også ganske sterke på (2) og (3), og det ville vært interessant å se eksperimenter som stresser dem! Så, hvordan finjusterer vi forplantningsforsinkelsen? Egentlig er det ikke for mange knotter. For det første kan vi distribuere RPC-servere i flere geografiske regioner, og automatisk rute forespørsel til nærmeste server. Dette er som hurtigmatkjeder som åpner butikker overalt – det er alltid en filial i nærheten! Mer presist, å ha geodistribuerte servere reduserer den fysiske avstanden mellom brukere og servere. For det andre kan vi optimalisere nettverkstopologien. Selv om det er mellom samme par av avsender og mottaker, varierer forplantningsforsinkelsen basert på den faktiske nettverksbanen som krysses. For eksempel, mellom USAs østkyst og Asia, kan ventetiden variere med 2x avhengig av om datapakkene går gjennom Stillehavet eller gjennom Europa. Noen ganger er det til og med flere nettverksbaner som følger samme geografiske rute; noen er mer overbelastet enn andre, noe som induserer høyere latens. Dette er som å ha flere motorveier å velge fra punkt A til punkt B. Latensfordelene du observerte kom mest sannsynlig fra at vi optimaliserte ruten.