ERPC publiceert "How to be faster on Solana?" (Hoe word je sneller op Solana?) — een rapport dat aan de hand van live data zichtbaar maakt dat snelheid op Solana wordt bepaald door de fysica van netwerkafstand
ERPC publiceert "How to be faster on Solana?" (Hoe word je sneller op Solana?) — een rapport dat aan de hand van live data zichtbaar maakt dat snelheid op Solana wordt bepaald door de fysica van netwerkafstand
ELSOUL LABO B.V. (hoofdkantoor: Amsterdam, Nederland; CEO: Fumitake Kawasaki) en Validators DAO, die ERPC exploiteren, zijn verheugd de publicatie aan te kondigen van "How to be faster on Solana?" (Hoe word je sneller op Solana?), een rapportpagina die — in één doorlopende route van boven naar beneden die zelfs een niet-gespecialiseerde ontwikkelaar in één oogopslag kan bevatten — uiteenzet hoe je sneller wordt op Solana.
De afgelopen jaren is een groeiend aantal ontwikkelaars en teams begonnen met high-frequency trading (HFT) en realtime financiële infrastructuur op blockchains, en op Solana in het bijzonder. Toch is de kennis achter de meest basale vragen — waarom sommigen sneller zijn, en hoe je sneller wordt — verspreid gebleven over losse technische blogposts en fragmentarische uitleg, met weinig bronnen waarmee je het volledige plaatje snel kunt bevatten. Dit rapport herordent de kern van de technische artikelen die ERPC in de loop der tijd heeft gepubliceerd tot één doorlopende "lijn van fysica".
Dit rapport deelt praktisch inzicht om het netwerk efficiënter en met hogere snelheid te benutten — zelfs op een gedecentraliseerd netwerk waarvan de deelnemers over de hele wereld verspreid zijn. Wij geloven dat het systematisch delen van waar, en waarom, verschillen in snelheid ontstaan, bijdraagt aan de efficiëntie en gezonde groei van het bredere blockchain-ecosysteem, inclusief Solana, voorbij het belang van welke afzonderlijke aanbieder dan ook.
How to be faster on Solana? (het rapport): https://erpc.global/nl/how-to-be-faster/
ERPC officiële site: https://erpc.global/nl
ERPC Dashboard: https://dashboard.erpc.global/nl
Wat de snelheid bepaalt, is niet je code of je machine — het is de onzichtbare derde laag
"Ik draai dezelfde strategie, en toch wordt alleen mijn bot laat gevuld." "Prijzen worden prima geüpdatet, maar alleen mijn transacties komen niet aan." "Ik ben van RPC-aanbieder gewisseld, en er veranderde niets." — de klachten die ontwikkelaars die op snelheid concurreren op Solana uiten, zijn opvallend gelijksoortig.
De eerste verdachte is altijd "misschien is mijn code traag" of "misschien zijn mijn specs niet goed genoeg". Het optimaliseren van je code en je machine helpt natuurlijk wel. Maar in veel gevallen waarin je beide al grondig hebt afgesteld, is wat tot het allerlaatst overblijft — en het meest over het hoofd wordt gezien — een onzichtbare derde laag: je netwerkafstand tot Solana.
Zodra je uitvoeringspad goed is geoptimaliseerd, leeft wat CPU-tuning op instructieniveau nog kan afsnijden in de wereld van nanoseconden tot hooguit een paar microseconden. Netwerkafstand daarentegen bepaalt honderden milliseconden — een hefboom in de orde van ongeveer 1000× ligt te slapen in de laag die mensen het meest over het hoofd zien. Voorbij het punt waarop je je code en je machine hebt gepolijst, zit de grootste resterende ruimte in die derde laag.
Op Solana verplaatst de "snelste plek" zich elke slot over de hele wereld
Op Solana schuift een slot ongeveer elke 400 milliseconden vooruit, en aan elke slot is een validator toegewezen als de "leader" om dat stukje van het block te bouwen. Leaders wisselen razendsnel (dezelfde validator kan meerdere opeenvolgende slots in handen hebben), en de server die het dichtst bij die leader staat, krijgt voor die slot een groot voordeel.
Dit is wat het fundamenteel anders maakt dan traditionele high-frequency trading. Bij aandelen of FX hield het plaatsen van je servers naast de enkele matching engine van de beurs — een vast punt dat niet beweegt — je voorgoed voorop. Op Solana verplaatst de leader zich slot voor slot over de hele wereld. De snelste plek is elke keer ergens anders. Eenmaal naast één plek gaan kamperen en het daarbij laten, werkt hier simpelweg niet.
In het rapport toont een wereldbol, aangedreven door live data uit ERPC's Leader Slot Information API (getLeaderSlots), de huidige leader en zijn duizelingwekkende wisseling, precies zoals het gebeurt. "De snelste plek blijft bewegen" — dit is geen metafoor, maar een feit dat je live kunt waarnemen.
Afstand is latency — van ~0,1ms op hetzelfde netwerk tot 100–300ms over continenten heen
De lichtsnelheid door glasvezel, en het aantal router-hops langs het pad, leggen een ondergrens vast die geen enkele hardware kan verslaan. Afstand laat zich ruwweg in de volgende grootteordes gelden:
- Zelfde netwerk: ~0,1ms
- Zelfde datacenter: ~0,3ms
- Zelfde stad: ~1ms
- Buurland: ~5–10ms
- Over continenten heen: ~100–300ms
Eén slot is maar ongeveer 400 milliseconden. De 100–300 milliseconden van het oversteken van een continent verbruiken in hun eentje al het venster van een hele slot. Wanneer de leader voor je deur staat, kom je binnen het venster; wanneer hij aan de andere kant van de planeet staat, ben je al te laat voordat je verstuurt. Snel zijn voor elke slot betekent altijd "dichtbij" zijn, waar de leader ook landt.
Let wel dat de contrasten in het rapport — "~0,1ms op hetzelfde netwerk" versus "op een omweg loopt het aantal relay-hops (hops = de routers die een signaal passeert) op tot ongeveer 7, en verbreedt de latency tot ongeveer 70×" — afgeronde cijfers zijn die bedoeld zijn om intuïtief het verschil tussen een nabije en een verre route over te brengen. De grote gemeten uitslagen verschijnen in de live data uit ERPC's Leader Slot Information API: de gemeten latency van een gegeven node naar de leader verandert sterk afhankelijk van waar de leader zich bevindt (welke slot), en uitslagen in de orde van tientallen keren tussen nabije en verre slots zijn waargenomen. Eén enkel "gemiddelde latency"-getal is vaak gewoon een snelle slot en een trage slot die elkaar afwisselen; het gemiddelde verbergt de werkelijkheid maar al te vaak.
En een "stadsnaam" is niet het netwerkpad zelf. Zelfs binnen dezelfde stad, als er externe transit of extra hops worden tussengevoegd, stapelt de latency zich alleen daardoor al op. Juist daarom kies je de dichtstbijzijnde node op gemeten aankomsttijd (ping), niet op afstand op een kaart.
Eén stad is niet genoeg — multi-regio, altijd dicht bij de leader
De stad waar Solana's validators het dichtst opeengepakt zijn, is Frankfurt. Toch zijn de validators die in Frankfurt zijn samengekomen, in een gemeten momentopname op het moment van publicatie, goed voor slechts ongeveer een kwart van het netwerk als geheel — zowel naar validatoraantal als naar stake. De resterende ongeveer driekwart van de slots worden van ergens anders dan Frankfurt geleid.
Met andere woorden, zelfs als je je ene beste machine in de drukste stad plaatst, kan dat alleen je nooit "altijd het snelst" maken. Klaarstaan in meerdere regio's (bijvoorbeeld Frankfurt / Amsterdam / New York / Tokyo / Singapore), ontvangen dicht bij welke leader ook live is, en doorgeven naarmate de leader zich verplaatst — dit is de manier om snel te zijn voor elke slot.
Wanneer je transacties niet aankomen, zit je vast in de spam-baan
Snelheid is niet alleen een kwestie van waar je server staat. Via welke baan je je transactie aflevert, bepaalt eveneens succes of falen.
Van de capaciteit van de TPU (Transaction Processing Unit) die transacties ontvangt, wijst de leader tot ongeveer 80% toe aan stake-gewogen prioriteit — dat wil zeggen, aan verbindingen die worden ondersteund door SOL die aan een validator is toegezegd (stake) (SWQoS / Stake-Weighted Quality of Service). De resterende ongeveer 20% wordt gedeeld door alle andere verbindingen. Dat laatste is een drukke baan, volgepropt met spam. Let wel dat deze toewijzing van ~80% aan de leader-kant wordt bepaald als een kwestie van Solana's protocol, niet iets dat ERPC instelt.
Transacties recht op de leader afvuren voelt als de snelste zet. Maar zonder de rugdekking van stake betekent dat in de wachtrij staan in de drukke ~20%-baan, en onder belasting komt je transactie uiteindelijk nooit in het block terecht. Het wezenlijke antwoord is om via een door stake gedekt pad te versturen — vanuit een RPC die verbonden is met een staked validator via een trusted-peer-relatie. ERPC exploiteert een top-tier staked validator, verbonden met hoogwaardige RPC-lijnen, als de rugdekking hiervoor (Shinobi Performance Pool).
Hardware doet er alleen toe wanneer die op volle kracht draait
Zelfs een server die op de juiste plek staat, kan de nabijheid die hij heeft gewonnen niet benutten als de machine zelf niet voluit draait. Een gevirtualiseerde VPS deelt een hypervisor en is daardoor gevoelig voor jitter en haperingen door "noisy neighbors" juist wanneer het het drukst wordt. Dedicated bare metal heeft dat niet. De ondergrens voor klokfrequentie waaraan een Solana validator moet voldoen, is 2,8GHz; ERPC's bare metal draait ver daarboven, op een hoge klok van de 5,7GHz-klasse, terwijl de benutting op 30–40% wordt gehouden — want een CPU die op 95% vastgepind staat, genereert jitter als een verstopte weg.
Dit verschil beperkt zich niet tot top-tier bare metal. In het rapport plaatsen we ERPC's VPS (VPS++) naast een vergelijkbaar gespecificeerde virtuele machine van een major cloud (beide AMD Turin / 4 vCPU) aan de hand van een echte benchmark (node_bench). Dit is geen productie; het is een "meting" die iedereen met dezelfde methode kan reproduceren. ERPC legt consequent de nadruk op het aantonen van leveringskwaliteit en snelheid via meting, niet via subjectieve beweringen of marketingteksten.
Het uiteindelijke antwoord: zelfde netwerk = nul afstand
Waar deze hele redenering bij uitkomt, is één enkel punt: "op hetzelfde netwerk" zijn als Solana's infrastructuur — RPC, validators, en de realtime paden die bij trading betrokken zijn, zoals Jito en Shredstream. Op hetzelfde netwerk is het ~0,1ms, en pakketten steken het publieke internet helemaal niet over. "Over het publieke internet", de standaard voor de meeste mensen, is precies waarom de meeste mensen traag zijn. Nul afstand is de conclusie die locatie, machine en stake aan elkaar bindt.
ERPC — elke optimalisatie die de fysica vereiste, op één platform
Voor elk antwoord dat het rapport als fysica afleidt, heeft ERPC een corresponderend middel paraat: VPS en bare metal op hetzelfde netwerk (nul afstand), klaarstaan in meerdere regio's (FRA / AMS / NY / TYO / SGP) (altijd het snelst), routering op basis van gemeten ping (naar de werkelijk dichtstbijzijnde node naar pad, niet naar kaart), de getLeaderSlots API (de positie van de leader slot voor slot kennen), en bare metal van de 5,7GHz-klasse, afgesteld met het open-source SLV (volle kracht).
ERPC is ontstaan omdat we het in de eerste plaats zelf nodig hadden. Bij het draaien van het open-source Epics DAO (een kaartspel op Solana) konden we dit soort infrastructuur niet kopen, zelfs niet toen we het probeerden, dus hadden we geen andere keuze dan het zelf te bouwen. Nu kun je op datzelfde fundament staan.
Op ERPC kun je Solana RPC, WebSocket, Solana Geyser gRPC, Solana Shredstream, Direct UDP Stream (Raw Shreds), VPS, bare-metal servers, dedicated RPC, SWQoS, een Pyth-enabled Price API, en Jet Analytics & Indexed RPC op één enkel platform combineren.
Gedecentraliseerde netwerken sneller en efficiënter benutten
Er is een deel van snelheid dat verbeterd kan worden door de juiste infrastructuurinvestering. Maar wat dit rapport consequent probeert over te brengen, is dat begrijpen "waar, en waarom, het verschil ontstaat" de echte voorsprong is. Zodra je begrijpt waar je tijd verliest — locatie, pad, machine of stake — kun je vervolgens de juiste resources kiezen en je richten op je kernwerk: strategie, codering en ontwikkeling.
Zelfs op een gedecentraliseerd netwerk kan het netwerk efficiënt worden benut. Het systematisch delen van die werkelijkheid zou moeten bijdragen aan de efficiëntie en groei van het bredere blockchain-ecosysteem, inclusief Solana, voorbij het belang van welke afzonderlijke aanbieder dan ook.
R&D en continue verbetering van Solana-specifieke infrastructuur
Achter ERPC zit de onderzoeks- en ontwikkelingsinspanning op het gebied van Solana-specifieke infrastructuur die ELSOUL LABO blijft nastreven. ELSOUL LABO is sinds 2022 vijf jaar achtereen goedgekeurd onder WBSO, het R&D-stimuleringsprogramma van de Nederlandse overheid. Het zet R&D voort op het gebied van Solana RPC-infrastructuur, validatoroperaties, realtime datalevering en door AI-agents ondersteunde operaties en ontwikkeling, en die resultaten worden weerspiegeld in diensten waaronder ERPC, SLV, SLV AI, en het AS200261 Solana-specifieke datacenter. Ook de publicatie van dit rapport is een inspanning die rechtstreeks voortvloeit uit deze continue onderzoeks- en ontwikkelingsinspanning. ERPC zal zijn resultaten op systematische wijze blijven publiceren.
Gebruik en advies
Voor vragen over de inhoud van dit rapport, advies over het verbeteren van de snelheid van je eigen opstelling, hulp bij het selecteren van resources of het plannen van een migratie, of vragen over benchmarks, maak je een supportticket aan op de officiële Validators DAO Discord.
How to be faster on Solana? (het rapport): https://erpc.global/nl/how-to-be-faster/
ERPC Dashboard: https://dashboard.erpc.global/nl
ERPC officiële site: https://erpc.global/nl
Validators DAO officiële Discord: https://discord.gg/C7ZQSrCkYR
Wij danken al onze gebruikers oprecht voor hun voortdurende gebruik van ERPC.
Links
- How to be faster on Solana? (het rapport): https://erpc.global/nl/how-to-be-faster/
- ERPC officiële site: https://erpc.global/nl
- ERPC Dashboard: https://dashboard.erpc.global/nl
- ERPC prijzen: https://erpc.global/nl/price/
- SLV officiële site: https://slv.dev/nl
- SLV GitHub: https://github.com/validatorsDAO/slv
- Validators DAO officiële Discord: https://discord.gg/C7ZQSrCkYR
Nieuws
