Jeg har hørt tilbakemeldinger fra mange om at market making har blitt mer konkurransedyktig på Hyperliquid nylig. Dette er flott for sluttbrukere, da det betyr at likviditeten er dypere og mer robust. Rettferdighet er et kjerneprinsipp for Hyperliquid i alle dimensjoner. For market makers betyr dette at blokkjeden er designet med lik tilgang i tankene. Men «lik» betyr ikke «lett». Ettersom protokollen fortsetter å skalere for å møte økende etterspørsel, blir det viktig å forstå vanskelighetene med Hyperliquids tilpassede infrastruktur som driver den største tillatelsesløse handelsplassen. I lang tid var den primære alfaen ganske enkelt å integrere Hyperliquid. API-en er designet for å abstrahere bort de fleste blokkjedekompleksiteter for nye brukere, slik at automatiserte tradere enkelt kan overføre strategier. Selv om den enkle innføringen ikke har endret seg, har viktigheten av ventetid økt. De mest responsive strategiene krever den beste infrastrukturen på klientsiden. Det overordnede prinsippet som styrer latensoptimalisering er at Hyperliquid er en blokkjede, ikke en CEX: 1. De raskeste dataene kommer fra å kjøre en node. - Handlingselement: Kjør mot en pålitelig, statisk node. For eksempel tilbyr Hyper Foundation en peer for ikke-validatorer å koble seg til. 2. De mest komplette dataene kommer fra å kjøre en node. Hver transaksjon strømmes i sanntid, og noden tilbyr ulike formater for inntak. - Merk: Kjør node med utgangsbufring deaktivert. 3. Noder utfører hele blokkjeden, ingen liten ingeniørbragd og i sterk kontrast til CEX-er der kode på klientsiden bare behandler brukerens tilstand. Hyperliquid-noder utfører og verifiserer hele blokkjedetilstanden, inkludert HyperCore og HyperEVM, på en enkelt maskin. Selv om utførelsen kan holde tritt med moderate maskinvarespesifikasjoner, skaleres ventetidsforbedringene med antall kjerner fordi en betydelig del av utførelsen er parallelliserbar. - Handlingselement: dataene som eksponeres av noden er rike og gir mye mer innsikt i hele blokkjedetilstanden. I tillegg til lokale API-servere, kan en full L4-bok bygges. Se eksempel på implementering. - Handlingselement: brukere kan se betydelige gevinster på opptil 32 kjerner, med ytterligere avtagende avkastning utover det. 4. Kanselleringer er designet for å ha en høy suksessrate. Den første ordreeffekten her er innebygd i HyperBFTs mempool-prioritering av kanselleringer. Noen brukere synes imidlertid ytterligere optimaliseringer er nyttige. For eksempel kan en GTC-bestilling om bord "kanselleres" mens den fortsatt er i mempoolen ved å ugyldiggjøre nonce som brukes i bestillingen.