Reaaliaikainen seuranta Solanalla: miksi omat solmut ovat ainoa vakava vaihtoehto

Johdanto

Solana käsittelee uuden lohkon 400 millisekunnin välein. Kaupankäyntijärjestelmiä, likvidaatiomoottoreita tai salkkunäyttöjä kehittäville tiimeille tämä nopeus on koko arvolupaus. Se on myös syy siihen, miksi jaetut RPC-päätelaitteet epäonnistuvat reaaliaikaisessa seurannassa. Kun sovelluksesi tarvitsee nähdä jokaisen tilimuutoksen, jokaisen token-siirron ja jokaisen ohjelmatapahtuman heti, kun ne tapahtuvat, yhteytesi taustalla oleva infrastruktuuri määrää, näetkö ne ensimmäisenä vai viimeisenä. RPC Fastin kaltaiset palveluntarjoajat (lue lisää täältä: https://rpcfast.com/dedicated-solana-nodes) on luotu nimenomaan tätä käyttötapausta varten, jossa millisekuntien ero datan tuoreudessa erottaa toimivan järjestelmän toimimattomasta.

Tässä artikkelissa selitetään, mitä reaaliaikainen seuranta Solanalla vaatii, miksi jaettu infrastruktuuri ei riitä ja miten erilliset solmut täyttävät aukon.

Mitä ”reaaliaikainen” tarkoittaa 400 ms:n ketjussa

Ethereumissa 12 sekunnin lohkoaika antaa sovelluksille mukavan ikkunan tilan muutosten tarkistamiseen. Solanassa tämä ikkuna on 30 kertaa pienempi. Lohko tuotetaan, käsitellään ja korvataan ennen kuin suurin osa HTTP-kierroksista on suoritettu.

Reaaliaikainen seuranta Solanalla tarkoittaa tilipäivitysten, transaktiovahvistusten ja slot-etenemisten vastaanottamista samassa slotissa, jossa ne tapahtuvat. Ei seuraavassa slotissa. Ei kahta slotia myöhemmin. Samassa.

Tätä varten on olemassa kolme tiedonsiirtomenetelmää, joista jokaisella on erilaiset viiveprofiilit.

Tavallinen JSON-RPC-kysely on yksinkertaisin. Sovelluksesi kutsuu getAccountInfo- tai getTransaction-funktiota silmukassa. Ongelmana on, että jokainen kutsu on erillinen HTTP-pyyntö, ja vastaus heijastaa sitä tilaa, jonka solmu oli tallentanut välimuistiin pyynnön hetkellä. Kuormituksen alla jaetut solmut jäävät 1–3 slotia jälkeen ketjun päästä, mikä tarkoittaa, että ”reaaliaikaiset” tietosi ovat 400–1200 ms vanhoja ennen kuin sovelluksesi edes käsittelee niitä.

WebSocket-tilaukset parantavat kyselyä ylläpitämällä pysyvää yhteyttä. Solmu lähettää päivitykset sovellukseesi, kun tilit muuttuvat tai transaktiot vahvistuvat. Helius raportoi, että heidän LaserStream-pohjaiset WebSocketit toimittavat päivitykset jopa 200 ms nopeammin kuin tavalliset RPC-pohjaiset toteutukset. Mutta WebSocketin suorituskyky riippuu edelleen yhteyden takana olevasta solmusta. Jaettu solmu, joka palvelee tuhansia samanaikaisia tilauksia, heikkenee kuormituksen alla.

Yellowstone gRPC on tuotantokäyttöön sopiva vaihtoehto. Triton One on kehittänyt sen avoimen lähdekoodin Geyser-laajennukseksi, joka suoratoistaa tilipäivityksiä, transaktioita, sloteja ja lohkoja suoraan validaattorin muistista käyttäen tyypitettyjä Protobuf-viestejä HTTP/2:n kautta. Ei JSON-sarjoituksen ylimääräistä kuormitusta. Ei polling-silmukoita. Tiedot saapuvat heti, kun solmu käsittelee ne ketjussa.

Menetelmä	Viive	Luotettavuus kuormituksen alla	Sopii parhaiten
JSON-RPC-kysely	400–1200 ms+	Heikkenee jaetuissa solmuissa	Kojelaudat, harvoin toistuvat lukemiset
WebSocket-tilaukset	200–600 ms	Riippuu solmun kapasiteetista	Käyttöliittymät, lompakkoseurannat
Yellowstone gRPC	Alle 100 ms	Vakaa erillisillä solmuilla	Kaupankäynti, likvidaatiot, indeksointi

Mitä omistettu solmu muuttaa

Erillinen Solana-solmu toimii eristetyssä laitteistossa, joka on varattu yhdelle käyttäjälle. Ei häiritseviä naapureita. Ei jaettuja yhteysjonoja. Ei hiljaista nopeuden rajoittamista.

Reaaliaikaisessa seurannassa kolme ominaisuutta on tärkeintä.

Slotin tuoreus. Erillinen solmu, jolla on suora yhteys validaattoriin, ylläpitää nollaviivettä sloteissa normaaleissa olosuhteissa. Sovelluksesi näkee ketjun kärjen, ei sen välimuistissa olevaa arvioitua versiota. Kun tilaat tilin muutokset gRPC:n kautta, päivitys saapuu samassa slotissa, jossa muutos tapahtui.

Läpimenokapasiteetin yläraja. Erillinen laitteisto tarkoittaa, että tilauskuormasi on ainoa kuorma. Voit käyttää 50 samanaikaista gRPC-tilausta eri ohjelmatilien seurantaan, ja solmu käsittelee ne kaikki ilman suorituskyvyn heikkenemistä. Jaetulla solmulla sama työmäärä joutuisi kilpailemaan tuhansien muiden käyttäjien pyyntöjen kanssa.

Mukauttaminen. Dedicated-solmut mahdollistavat konfiguraation hienosäätöä, jota jaetut päätepisteet eivät tarjoa. Voit valita alueen, jolla fyysinen viive sovellusservereihisi on mahdollisimman pieni. Voit ottaa käyttöön tai poistaa käytöstä tiettyjä Geyser-laajennuksia. Voit hallita välimuistin toimintaa, yhteysrajoituksia ja uudelleenkäynnistyskäytäntöjä.

Kustannuskysymys

Dedikoituja Solana-solmuja ei ole halpoja. Palveluntarjoajat hinnoittelevat ne 500–3 000 dollarin välillä alueesta, laitteistotasosta ja mukana tulevista ominaisuuksista riippuen.

Kysymys ei ole siitä, maksavatko omat solmut enemmän kuin jaetut päätepisteet. Ne maksavat. Kysymys on siitä, ylittävätkö vanhentuneiden tietojen kustannukset solmun kustannukset.

Liquidation-moottorille, joka käsittelee päivittäin 10 miljoonan dollarin volyymiä, 2 slotin viive, joka aiheuttaa 5 %:n epäonnistumisasteen likvidaatioissa, merkitsee 500 000 dollarin vuotuista tulonmenetystä. Solmu maksaa itsensä takaisin ensimmäisen viikon aikana.

Vähittäiskäyttäjille palveluja tarjoavalle salkunseurannalle riittävät jaetut päätepisteet, joissa on WebSocket-tilaukset. Tietojen tuoreusvaatimus on sekunteja, ei millisekunteja.

Käyttötapaus	Tietojen ajantasaisuus vaaditaan	Jaettu päätepiste riittää	Vaaditaan oma solmu
Lompakon saldon näyttö	2–5 sekuntia	Kyllä	Ei
Salkun hallintapaneeli	1–2 sekuntia	Enimmäkseen	Ei
DEX-reititysmooduuli	Alipaikka	Ei	Kyllä
Likvidaatiobotti	Alipaikka	Ei	Kyllä
Ketjussa tapahtuva analytiikka	Slot-kohtainen, aukoton	Ei	Kyllä
Vaatimustenmukaisuuden seuranta	Slot-kohtainen, aukoton	Ei	Kyllä

Kuinka arvioida seurantavaatimuksesi

Aloita kahdella kysymyksellä. Kuinka tuoreita tietojesi on oltava? Ja mitä tapahtuu, jos päivitys jää väliin?

Jos vastaus ensimmäiseen kysymykseen on ”samassa aikavälissä” ja vastaus toiseen on ”menetämme rahaa tai rikomme säännöksiä”, erillinen infrastruktuuri ei ole valinnainen. Se on vähimmäisvaatimus arkkitehtuurille.

Jos seuranta sietää 1–2 sekunnin viiveen ja satunnainen päivityksen menettäminen tarkoittaa hieman vanhentunutta hallintapaneelia, jaetut päätepisteet WebSocket-tilauksilla palvelevat sinua hyvin murto-osalla kustannuksista.

Tiimit, jotka ymmärtävät tämän väärin, aloittavat yleensä jaetuilla päätepisteillä, laajentavat tuotantoon ja huomaavat rajoitukset ensimmäisen ruuhka-tilanteen aikana, jolloin vaihtamisen kustannukset ovat korkeimmillaan ja vaihtamatta jättämisen kustannukset välittömiä.