Ankr ylitti äskettäin 1 biljoonan RPC-pyynnön kuukaudessa, mikä tukee valtavaa osaa Web3-liikenteestä. Heidän RPC-alustansa toimii siltana sovellusten ja lohkoketjujen välillä ja käsittelee puheluita lompakoista, dAppeista, boteista, indeksoijista, rollupeista ja muista. 🧵

Mutta mistä kaikki tämä liikenne on peräisin? Keskeisiä lähteitä ovat: • Lompakot ja käyttöliittymät • Indeksoijat / analytiikka • Botit ja MEV-järjestelmät • Rollupit, L2:t, sillat (raskaat ketjujen väliset puhelut) • Pitkä häntä pienempiä dAppeja 80+ verkossa

Entä millaiset RPC-menetelmät ovat kovassa käytössä? • Toistuvat lukemat: eth_call, eth_getBalance, eth_getBlockByNumber jne. • Alue- ja lokikyselyt (eth_getLogs) ja jäljitys-/virheenkorjauskutsut • Tilaukset WebSocketin kautta (uudet päät, lokit, odottavat tx:t) • Kirjoitukset (esim. eth_sendRawTransaction) – volyymiltaan vähemmän, mutta toiminnan kannalta kriittiset

Miten Ankr skaalautuu pitääkseen asiat nopeina ja luotettavina? Jotkut heidän strategioistaan: • Globaali anycast + alueellinen reititys viiveen vähentämiseksi • Lohkoketjutietoinen kuormituksen tasapainotus • Laivaston erikoistuminen: erilliset kuumalukemiset, arkistointi, jäljitys/virheenkorjaus, kirjoituspolut Ankr • Nopeuden muotoilu, metodien painotus ja vikasietologiikka viritetty lohkoketjun semantiikkaan • Oma infrastruktuuri yritysasiakkaille, joilla on suuri suorituskykytarve

RPC on Web3:n elintärkeä "luku/kirjoitushana" - ei saldoja, ei vaihtoja, ei siltoja ilman sitä. Ankrin biljoonan pyynnön virstanpylväs ei ole hypeä; Se on jokaisen tilapuhelun, lokien, tilausten ja tapahtumien summa 80+ ketjussa. Parhaan suorituskyvyn saavuttamiseksi kehittäjien tulee käyttää välimuistia, eräkutsuja, kiinnittää alueisiin, noudattaa menetelmän painoarvoja ja seurata käyttöä ketjuittain/menetelmäkohtaisesti.