To są interesujące wyniki. Zawsze miło widzieć, że MegaETH jest na szczycie : ) Aby umieścić dane w kontekście, opóźnienie end-to-end żądania RPC składa się z trzech komponentów: (1) opóźnienie propagacji prędkości światła od/do obserwatora do/z serwera, (2) czas, jaki zajmuje serwerowi pobranie i przetworzenie żądanych danych, (3) czas, jaki zajmuje obserwatorowi pobranie odpowiedzi. Jak wspomniałeś, testowane metody RPC są lżejsze, zarówno pod względem kosztów obliczeniowych, jak i rozmiaru danych. Oznacza to, że eksperymenty głównie testowały (1), tj. opóźnienie propagacji między obserwatorami a serwerami RPC. Nie zrozum mnie źle – RPC MegaETH są również dość mocne w (2) i (3) i byłoby interesujące zobaczyć eksperymenty, które je obciążają! Jak więc możemy dostroić opóźnienie propagacji? Właściwie nie ma zbyt wielu pokręteł. Po pierwsze, możemy wdrożyć serwery RPC w wielu regionach geograficznych i automatycznie kierować żądania do najbliższego serwera. To jak sieci fast food otwierające lokale wszędzie – zawsze jest jakaś placówka w pobliżu! Dokładniej mówiąc, posiadanie serwerów rozproszonych geograficznie zmniejsza fizyczną odległość między użytkownikami a serwerami. Po drugie, możemy zoptymalizować topologię sieci. Nawet jeśli jest to między tą samą parą nadawcy i odbiorcy, opóźnienie propagacji różni się w zależności od rzeczywistej ścieżki sieciowej. Na przykład, między wschodnim wybrzeżem USA a Azją, opóźnienie może się różnić o 2x w zależności od tego, czy pakiety danych przechodzą przez Pacyfik, czy przez Europę. Czasami istnieje nawet wiele ścieżek sieciowych podążających tą samą trasą geograficzną; niektóre są bardziej zatłoczone niż inne, co powoduje wyższe opóźnienie. To jak posiadanie wielu autostrad do wyboru z punktu A do punktu B. Korzyści z opóźnienia, które zaobserwowałeś, najprawdopodobniej pochodziły od nas, optymalizujących trasę.