Acestea sunt câteva rezultate interesante. Este întotdeauna plăcut să vezi că MegaETH este pe primul loc :) Pentru a pune datele într-un anumit context, latența end-to-end a unei cereri RPC constă din trei componente: (1) latența de propagare a vitezei luminii de la/către observator la/de la server, (2) timpul necesar serverului pentru a prelua și postprocesa datele solicitate, (3) timpul necesar observatorului pentru a descărca răspunsul. După cum ați menționat, metodele RPC testate sunt mai ușoare, atât în ceea ce privește costul de calcul, cât și în ceea ce privește dimensiunea datelor. Aceasta înseamnă că experimentele au fost testate în principal (1), adică latența de propagare între observatori și serverele RPC. Nu mă înțelegeți greșit – RPC-urile MegaETH sunt, de asemenea, destul de puternice pe (2) și (3) și ar fi interesant să vedem experimente care să le streseze! Deci, cum reglam fin latența de propagare? De fapt, nu sunt prea multe butoane. În primul rând, putem implementa servere RPC în mai multe regiuni geografice și putem direcționa automat cererea către cel mai apropiat server. Este ca și cum lanțurile de fast-food deschid magazine peste tot – există întotdeauna o sucursală în apropiere! Mai exact, a avea servere geo-distribuite reduce distanța fizică dintre utilizatori și servere. În al doilea rând, putem optimiza topologia rețelei. Chiar dacă este între aceeași pereche de emițător și receptor, latența de propagare variază în funcție de calea reală a rețelei parcursă. De exemplu, între Coasta de Est a SUA și Asia, latența poate varia de 2 ori în funcție de faptul că pachetele de date trec prin Pacific sau prin Europa. Uneori, există chiar mai multe căi de rețea care urmează aceeași rută geografică; unele sunt mai congestionate decât altele, ceea ce induce o latență mai mare. Este ca și cum ai avea mai multe autostrăzi de ales din punctul A în punctul B. Avantajele de latență pe care le-ați observat cel mai probabil au venit din optimizarea rutei.