Wszystko, co musisz wiedzieć o Ethereum RPC w praktyce

Dobrze, że ktoś wspomniał w innych komentarzach o bezpieczeństwie RPC, bo moim zdaniem to faktycznie jest spory temat – ale widzę, że nikt nie napisał o tej irytacji, kiedy trzeba debugować błędy RPC. Ja miałem sytuację, że komunikaty były totalnie niejasne i rozwiązywanie problemu zajęło mi o wiele więcej czasu niż powinno. Przydałoby się, żeby te narzędzia do debugowania RPC były bardziej dopracowane, bo na razie to często łamigłówka.

Ja wogule sory ale te narzedzia np. Ganache czy web3.js, to naprawde czesto cieżko ogarnac, bo sa caly czas updejty i nagle interfejs inny, nie znajdziesz wszystkiego co bylo w tutorialach dwa miesiace temu, masakra. Ktos wogole sprawdzil jak Postman sie sypie przy wiekszej liczbie rzadani? Prubowalem cos wiekszego na nim robic i mi sie pousuwaly requesty albo odpowiedzi sie nie zgadzaly z tym co na blockchainie szlo. Ciezko powiedziec czy to wina RPC czy narzedzi czasami. Alchemy Monitor to tez chyba placone juz na powaznie cos, wiec dla zwyklego czlowieka to nie ewidentnie. Duzo rzeczy jest “dla dewelopera”, ale jak ktos chce tylko sobie sprawdzic saldo portfela to sie zgubi przy tej ilosci parametersow. I niby wszystko “latwe” jak pisza ale potem szukasz bloku i sobie patrzysz na etherscan bo szybciej. Swoja droga bylo by fajnie jak by do hardhata zrobili taki guzik “testuj” bez konsoli, bo nie kazdy umie linijke wpisac zwlaszcza na windowsie jak sie jeszcze python odpala czy cos. Takie mam wrazenie ze zrobili narzedzia ale nie zawsze pamietaja o normalnych ludziach.

Fajne są te dyskusje poniżej, bo każdy coś ciekawego zauważa – i mam wrażenie że mamy tu sporo ludzi, którzy faktycznie na co dzień grzebią w kodzie. Chciałem się odnieść do kwestii testowania RPC, bo nikt o tym jeszcze nie pisał. Z własnego doświadczenia powiem, że używanie tych wszystkich narzędzi typu Postman czy Ganache niby ułatwia życie, ale czasem wyłapują się na nich zupełnie inne problemy, niż potem w realnej sieci. Różnice między np. Ganache a mainnetem Ethereum potrafią być znaczące, szczególnie jeśli ktoś robi coś bardziej niestandardowego ze smart kontraktami.

Często jest tak, że wszystko śmiga lokalnie, a potem wrzucasz na produkcję i buuum – coś się sypie, bo na publicznych węzłach albo inne limity, albo giveaway error totally nie na temat. Trochę mało jest materiałów (albo ja nie znalazłem), jak dobrze testować scenariusze z udziałem dużej liczby żądań, żeby te przeciążenia i limity API wyłapać odpowiednio wcześnie.

Kolejny temat – cieszę się, że ktoś wspomniał o alatologii (Hardhat, Ethers.js itd), bo im więcej tych narzędzi, tym szybciej idzie robota, ale czy ktoś ma doświadczenie z większym monitoringiem w produkcji? Ja korzystałem z Alchemy Monitor i jest ok, ale nie łapie wszystkich edge-case'ów. Ciekaw jestem, czy komuś się udało zbudować taki system do monitorowania, który powiadomi nie tylko o awarii, ale np. o powolnych żądaniach albo dziwnych anomaliach w ruchu?

No i na koniec: to, że RPC jest fundamentem rozwoju Web3 wiadomo, ale nie można zapominać jak bardzo upierdliwe jest czasem szukanie źródeł problemu przy tej warstwie komunikacji. Brakuje lepszych, wygodnych narzedzi do tego. Może z czasem się coś poprawi, bo branża się mega rozwija, ale póki co trzeba sporo pokombinować samemu.

Trochę się dziwię, że nikt jeszcze nie poruszył tematu kosztów korzystania z komercyjnych dostawców RPC. Gdy projekt zaczyna rosnąć, limity API potrafią szybko zacząć uwierać, a ceny za zwiększenie limitów są czasem zaskakująco wysokie. Dla mniejszych aplikacji to może być spore wyzwanie, więc warto o tym pamiętać zanim się całkiem uzależnimy od jednego dostawcy.

Fajnie by byo jakby ktores narzedzi wyjasnialo bardziej co znaczy dany blad bo czasem jak robie cos w Postmanie z RPC to w ogole nie wiadomo skad sie problem bierze i jestem zgubiony.