Nämä ovat mielenkiintoisia tuloksia. On aina mukavaa nähdä MegaETH:n nousevan kärkeen :) Tietojen asettamiseksi johonkin kontekstiin, RPC-pyynnön päästä päähän -latenssi koostuu kolmesta osasta: (1) valonnopeuden etenemisviive havaitsijalta palvelimelle/palvelimelta, (2) aika, joka palvelimelta kuluu pyydetyn datan nappaamiseen ja jälkikäsittelyyn, (3) aika, joka havaitsijalta kuluu vastauksen lataamiseen. Kuten mainitsit, testattavat RPC-menetelmät ovat kevyempiä sekä laskentakustannusten että datakoon suhteen. Tämä tarkoittaa, että kokeissa testattiin pääasiassa (1) eli etenemisviivettä tarkkailijoiden ja RPC-palvelimien välillä. Älä ymmärrä minua väärin – MegaETH:n RPC:t ovat myös melko vahvoja kohdissa (2) ja (3), ja olisi mielenkiintoista nähdä kokeita, jotka rasittavat niitä! Joten miten hienosäädämme etenemisviivettä? Itse asiassa nuppeja ei ole liikaa. Ensinnäkin voimme ottaa käyttöön RPC-palvelimia useilla maantieteellisillä alueilla ja reitittää pyynnön automaattisesti lähimmälle palvelimelle. Tämä on kuin pikaruokaketjut, jotka avaisivat kauppoja kaikkialle – lähellä on aina sivuliike! Tarkemmin sanottuna maantieteellisesti hajautetut palvelimet vähentävät fyysistä etäisyyttä käyttäjien ja palvelimien välillä. Toiseksi voimme optimoida verkkotopologian. Vaikka se olisi saman lähettäjän ja vastaanottajan parin välillä, etenemisviive vaihtelee todellisen verkkopolun mukaan. Esimerkiksi Yhdysvaltain itärannikon ja Aasian välillä latenssi voi vaihdella 2x riippuen siitä, kulkevatko datapaketit Tyynenmeren vai Euroopan kautta. Joskus samaa maantieteellistä reittiä seuraa jopa useita verkkopolkuja; jotkut ovat ruuhkaisempia kuin toiset, mikä aiheuttaa suuremman latenssin. Tämä on kuin olisi useita moottoriteitä, joista voit valita pisteestä A pisteeseen B. Havaitsemasi latenssiedut tulivat todennäköisesti siitä, että optimoimme reitin.