C++, Rust ja hajautetut salausvaihdot: sovellettavuus ja tehokkuus

Johdanto

Kieliargumentit tulevat erityisen harhaanjohtaviksi kryptokirjoissa, koska itse järjestelmät ovat niin helppoja kuvata väärin. Ihmiset sanovat "rakenna DEX" ikään kuin hajautettu vaihto olisi yksi suoritettava ohjelma yhdellä latenssiprofiililla, yhdellä luottamusmallilla ja yhdenlaisella epäonnistumisella. Todellisuudessa vakava DEX on kerrostettu organismi. Se voi sisältää ketjun sisäistä logiikkaa, validaattorin tai solmun vuorovaikutusta, tietoisuutta lohkojen rakentamisesta, mempool-valvontaa, markkinatietojen keräämistä, tilasimulaatiota, hinnoittelua, reititystä, riskitarkistuksia, operaattorin kojetauluja ja joskus tilauskirjaa tai vastaavia viereisiä palveluita, jotka näyttävät epäilyttävästi perinteiseltä lohkoketjun sanastoa käyttävältä vaihtoinfrastruktuurilta.

Kun tunnustamme tämän kerrostetun todellisuuden, C++:n ja Rust:n välisestä väitteestä tulee rauhallisempi ja paljon hyödyllisempi. Oikea kysymys ei ole se, mikä kieli ansaitsee koko arkkitehtuurin kunniakohteena. Oikea kysymys on, mitkä kerrokset hyötyvät Rust:n turvallisuudesta ja ekosysteemin sopivuudesta, mitkä kerrokset palkitsevat edelleen C++:n alhaisen suorituskyvyn hallinnan ja missä hybridisuunnittelu lakkaa olemasta kompromisseja ja alkaa olla yksinkertaista järkevää.

Tällä kehyksellä on merkitystä, koska hajautetut vaihtojärjestelmät elävät sekalaisten paineiden alaisena. Joitakin tasoja rangaistaan ​​kovimmin virheellisyydestä, tarkastettavissa olevista ongelmista ja vaarallisista tilasiirtymistä. Muita tasoja rangaistaan ​​latenssista, suorituskyvystä ja kyvyttömyydestä arvioida mahdollisuuksia riittävän nopeasti. Toiset taas ovat operatiivisia palveluita, joissa todelliset kustannukset ovat pitkäaikainen ylläpito ja tiimin nopeus. Yksi kieli voi olla erinomainen yhdelle näistä rasitteista ja vain riittävä toiselle. Kypsä arkkitehtuuri alkaa, kun tunnustamme sen avoimesti.

DEX on pino, ei henkilöllisyystodistus

Ensimmäinen ja tärkein korjaus on käsitteellinen. DEX ei ole yksi asia. EVM-suuntautunut AMM-protokolla, Solana-alkuperäinen ohjelmaekosysteemi, sovellusketjujen perpetuals-vaihto ja markkinaolosuhteisiin reagoiva hakujärjestelmä ansaitsevat kaikki erilaiset insinöörivaistot. Ketjun AMM-logiikka elää yhden rajoitusjoukon sisällä. Ketjun ulkopuoliset simulaattorit ja reitin arvioijat asuvat toisessa. Tilauskirjamaiset komponentit tai korkeataajuuksiset hakuinfrastruktuurit voivat näyttää järjestelmien näkökulmasta paljon lähempänä klassista vaihto-ohjelmistoa kuin tavallista verkkosovelluskehitystä.

Tästä syystä kielikeskustelut menevät harhaan niin nopeasti. Insinööri osoittaa Solana ja huomaa oikein, että Rust on luonnollinen polku ohjelmien kehittämiseen siellä. Toinen viittaa latenssiherkkään reititys- tai simulointimoottoriin ja huomauttaa oikein, että C++ on edelleen raa'an vahva valinta. Molemmat ovat oikeassa kontekstissa. Ongelma alkaa, kun jokainen havainto on paisutettu koko pinon kokonaisteoriaksi.

Hyödyllinen henkinen palautus on kysyä jokaiselta alajärjestelmältä, millaisesta kivusta sitä rangaistaan. Jos jokin komponentti on väärä, onko kipu ensisijaisesti julkinen virhe? Onko kyseessä yksityiset käyttökustannukset? Onko se kyvyttömyys vastata nopeasti muuttuvaan tilaan ennen kuin tilaisuus sulkeutuu? Onko se tarkastustaakka, rekrytointitaakka vai infrastruktuuritaakka? Eri tasot vastaavat näihin kysymyksiin eri tavalla, minkä vuoksi kypsät DEX-järjestelmät päätyvät usein kielellisesti sekoittuneiksi, vaikka julkiset keskustelut kaipaavat puhtautta.

Missä Rust ottaa oikeutetusti johtoaseman

Rust ansaitsee paikkansa luonnollisimmin siellä, missä tilasiirtymät, turvallisuuskuri ja ekosysteemisovitus hallitsevat arkkitehtuuria. Rust-ensimmäisissä lohkoketjuympäristöissä, kuten Solana, tämä ei ole marginaalinen etu. Se on painopiste. Kielen ympärillä on kehyksiä, esimerkkejä, turvallisuustottumuksia ja työkaluja, jotka auttavat protokollaryhmiä liikkumaan ekosysteemin jyvässä sen sijaan, että se vastaisi sitä. Ketjuohjelmissa sopivuudella on enemmän merkitystä kuin abstraktilla kielen vertailulla. Paras kieli paperilla on usein huonompi kieli, jos jokainen vakava toimintapolku sen ympärillä odottaa jotain muuta.

Rust on houkutteleva myös DEX:ää ympäröivissä greenfield-palveluissa, kun pitkän aikavälin oikeellisuus ja huollettavuus ovat päävihollisia. Ohjaustason palvelut, koordinointikerrokset ja tietyt protokollakohtaiset työkalut voivat aidosti hyötyä Rustin kannustamasta kurinalaisuudesta. Kääntäjä havaitsee virheluokat, jotka muutoin vaatisivat prosessia, valppautta ja tarkistuskulttuuria hallittavaksi C++issa. Se ei ole romanttinen väite. Se on käytännöllinen. Tiimit, joilla on vahva Rust-kyky, voivat vähentää tiettyjä riskiluokkia varhaisessa vaiheessa ja pitää palvelurajoja rauhallisempina ajan myötä.

Hyödyllinen vastaesimerkki pitää tämän maassa. Joskus tiimit päättelevät Rust:n vahvuudesta ketjun alkuperäisessä työssä, että jokaisen ympäröivän ketjun ulkopuolisen alijärjestelmän tulisi olla oletuksena Rust. Mutta se tapahtuu vain, jos ympäröivillä järjestelmillä on sama hallitseva kipu. Kuuman polun simulaattori tai hakukone, joka toistuvasti arvioi markkinatilannetta tiukan ajoituspaineen alla, pysyy suorituskyvylle herkänä natiivijärjestelmänä kryptotuotteen sisällä. Ketju voi olla Rust-muotoinen, kun taas ympäröivä suorituspolku pysyy hyvin C++-muotoisena.

Missä C++ ansaitsee edelleen säilytyksensä

C++ on vaikea korvata aina, kun DEX alkaa käyttäytyä vähemmän kuin sovellusalusta ja enemmän kuin vaihtoinfrastruktuuri. Markkinatietojen käsittely, muistin kuuntelu, normalisointiputket, reitin arviointi, tilan simulointi, arbitraasihaku, likvidaatiokoneet ja tilauskirjan viereiset palvelut jakavat kaikki yhteisen ominaisuuden: ne tekevät toistuvia, matalan tason töitä paineen alaisena, ja työ on usein lähellä muistin asettelua, allokointistrategiaa, jäsentimen tehokkuutta, jonokäyttäytymistä tai [TECH:CPU]][TECH:CPU.

Tässä C++:n pitkällä historialla järjestelmissä ja kaupankäynnissä on edelleen merkitystä. Kieli antaa insinööreille suoran hallinnan tietorakenteista, säikeistysmalleista, objektien käyttöiästä, mukautetuista allokoijista, vektoriystävällisistä asetteluista ja suorituskykytyökaluista, jotka on testattu taistelussa juuri tällaisissa ympäristöissä. Se hyötyy myös vanhemmasta ja tiheämästä esimerkkiekosysteemistä suorituskykyisille verkkojärjestelmille, simulaattoreille, jäsentimille, alkuperäisille yhdyskäytäville ja laitteistotietoiselle koodille. Aikakaudella, jolloin AI-avustajia pyydetään auttamaan myös näihin ongelmiin, tiheys lisää etua.

Harkitse etsijää, joka kuuntelee markkinoiden signaaleja, simuloi polkuja ja päättää, kannattaako mahdollisuus tavoittaa. Mielenkiintoinen hinta on harvoin yksi kaava erikseen. Mielenkiintoinen hinta on monien kaavojen toistuva, tilallinen käyttö, jota ympäröivät käsittely-, dekoodaus-, reititys- ja päätöslogiikka. Muutama vältettävä kopio, yksi huonosti sijoitettu lukko tai kuriton jono voivat muuttaa koko polun taloutta. C++ tarjoaa insinööreille syvästi tutun kielen kysyäkseen koneelta tarkkoja kysymyksiä. Järjestelmissä, jotka elävät ja kuolevat toistamalla aikapaineen alla, sillä on silti merkitystä.

Taloustiede muuttaa kielen vastausta

Yksi syy näiden keskustelujen kuumenemiseen on se, että insinöörit puhuvat ikään kuin voiton ehto olisi eleganssi. DEX-järjestelmissä voittoehto on yleensä taloudellinen. Latenssilla on merkitystä, koska menetetyillä mahdollisuuksilla on hintansa. Tehokkuudella on väliä, koska toistuva mittakaavasimulointi maksaa. Turvallisuus on tärkeää, koska virheellisillä tilasiirtymillä on hintansa. Toiminnan yksinkertaisuudella on merkitystä, koska jatkuvasti käyttäjiään pelottavalla järjestelmällä on hintansa. Kun argumentti ilmaistaan ​​näillä termeillä, kielenvalinta lakkaa olemasta symbolinen ja muuttuu taloudelliseksi.

Rust maksaa usein itsensä takaisin, jos suurimmat tulevaisuuden kustannukset aiheutuvat kovan tilallisen logiikan virheellisyydestä tai monimutkaisten palveluiden ylläpidosta ilman riittävää rakenteellista kurinalaisuutta. C++ maksaa usein itsensä takaisin, jos suurimmat tulevaisuuden kustannukset aiheutuvat kuuman polun tehottomuudesta, liian suuresta abstraktiosta toistuvassa laskennassa tai vaikeudesta integroida korkean suorituskyvyn alkuperäiseen infrastruktuuriin. Järkevä tiimi kysyy, mitkä kustannukset hallitsevat osajärjestelmän käyttöikää, ja valitsee sen mukaan.

Tämä näkökulma auttaa myös yhdessä yleisessä sekaannuksessa: selvitysnopeus ja suorituspolun nopeus eivät ole sama asia. Lohkoketjulla voi olla yksi sarja ajoitusominaisuuksia protokollatasolla, kun taas sitä ympäröivät ketjun ulkopuoliset järjestelmät elävät täysin erilaisessa latenssimaailmassa. Hidas ketjun sovitus ei tee nopeasta ketjun ulkopuolisesta arvioinnista merkityksetöntä. Itse asiassa, kun mahdollisuuksista kilpaillaan, ketjun ulkopuolisesta nopeudesta voi tulla vieläkin arvokkaampi, koska se muokkaa sitä, kuka reagoi, kuka hinnoittelee tarkasti ja kuka tekee hyödyllisen toiminnan ensin. Insinöörit, jotka tasoittavat nämä kaksi ajoitusaluetta yhdeksi nopeudeksi kutsutuksi konseptiksi, päätyvät yleensä laiminlyömään vaivaa.

Hybridiarkkitehtuuri on usein aikuisten vastaus

Monia vakavimpia DEX-arkkitehtuureja on helpompi perustella, kun hybridisuunnittelun annetaan olla kunnioitettavaa. Ketjulogiikka voi elää siinä kieli- ja kehysympäristössä, jota ketju odottaa. Ohjaustaso ja tuotepalvelut voivat valita kielen, joka pitää ylläpidon järkevänä. Hot-path-simulaatio, reititys, markkinatietojen käsittely tai viereisten komponenttien yhteensovittaminen voivat pysyä lähellä suoritusperinteitä, mikä helpottaa niiden viritystä ja tarkistamista. Tulos ei ole ideologinen kompromissi. Se on järjestelmä, jossa jokainen osa voi optimoida sen todellisen taakan mukaan.

Tämä vaatii kypsyyttä. Hybridijärjestelmät ovat terveitä vain, kun rajat ovat selvät. Tiimit tarvitsevat selkeitä käyttöliittymiä, kapeaa vastuunjakoa ja rehellisyyttä siitä, mihin monimutkaisuus kuuluu. Mutta se on totta kielestä riippumatta. Yksikielinen arkkitehtuuri hämmentyneillä rajoilla ei ole yksinkertaisempaa kuin kaksikielinen arkkitehtuuri, jossa on puhtaat arkkitehtuurit. Joskus se on vain yksikielinen ilmaus samasta sekaannuksesta.

Tässä on myös henkilöstöulottuvuus. Tiimit kuvittelevat usein, että heidän on valittava yksi kieli, koska useiden natiiviverkkotunnusten palkkaaminen tuntuu vaikealta. Tämä huoli on ymmärrettävää, mutta siitä voi tulla tekosyy arkkitehtoniselle laiskuudelle. Parempi kysymys on, tarvitseeko suorituskykyherkin kerros todella oman kielen vai eikö profiloija ole vielä perustellut tätä hintaa. Joidenkin joukkueiden tulisi ehdottomasti pysyä enimmäkseen Rustissa ja esitellä C++ vain, kun kuuma polku on sen ansainnut. Toisilla on jo syvää C++-asiantuntemusta, ja he vahingoittaisivat itseään pakottamalla kaiken Rust-muotoiseen työnkulkuun, joka ei vastaa heidän vahvimpia järjestelmävaistojaan. Konteksti taas on tärkeämpää kuin arvovalta.

Mitä AI-avusteisia suunnittelumuutoksia

AI-koodausjärjestelmien saapuminen itse asiassa vahvistaa kontekstuaalisen kielen valinnan perustetta sen sijaan, että se heikentäisi sitä. Rust-ensimmäisissä lohkoketjuekosysteemeissä agentit voivat auttaa kehystietoisten rakennustelineiden, rutiinipalvelukoodien ja joidenkin refactor-luokkien kanssa entistä mukavammin. Mutta matalan tason, suorituskykyisissä alkuperäisissä alijärjestelmissä tasapaino kallistuu edelleen kohti C++ yksinkertaisesta syystä: julkinen koodi, julkinen työkalut ja julkiset integraatioesimerkit ovat siellä paljon tiheämpiä. Agenteilla on tällä hetkellä enemmän historiallista materiaalia, josta voidaan tuottaa hyödyllisiä luonnoksia sellaisiin hot-path-infrastruktuureihin, joita DEX-järjestelmät usein tarvitsevat.

Tämä ei tarkoita, että AI tekisi C++:sta yleisesti ylivoimaisen. Se tarkoittaa, että vanhan ekosysteemin painovoima on nyt vahvistettu uudella työkalulla. Kun avustaja auttaa virheenkorjauksessa CMake-integraatiossa, ehdottaa jonon uudelleensuunnittelua, parantaa jäsennintä tai luonnostelee vertailukohtaa simulaatiosilmukalle, se hyötyy julkisen C++-maailman syvästä alkuperäisestä muistista. Kun avustaja työskentelee Rust-ensimmäisen ketjun ympäristössä, voi olla päinvastoin. Kielipäätös kuuluu edelleen työmäärään, mutta AI-aikakausi tekee ympäristön tiheydestä entistäkin tärkeämpää.

Käytännön suositukseni

Jos rakennat ketjun alkuperäisiä ohjelmia Rustensimmäisessä ekosysteemissä, älä taistele maastoa vastaan ​​kieliretoriikan vuoksi. Antaa Rust:n johtaa sinne, missä se on jo luonnollinen paikka oikealle, työkaluille ja yhteisölliselle käytännölle. Jos rakennat ketjun ulkopuolista infrastruktuuria, joka käyttäytyy suorituskykyherkän vaihtotekniikan tavoin, pidä C++ salaustoimialueen pöydällä. Anna C++:n tehdä työ, jota se edelleen tekee poikkeuksellisen hyvin: nopea käsittely, toistuva simulointi, tiukka reitityslogiikka ja matalan tason järjestelmäohjaus.

Ja jos arkkitehtuurisi todella kattaa molemmat maailmat, ota tämä tosiasia ilman hämmennystä. Hyvä suunnittelu ei tee puhtaampaa teeskentelemällä jokaisen komponentin kärsivän samanlaisesta viasta. Sitä vahvistetaan antamalla jokaiselle komponentille kieli, joka kunnioittaa sen todellisen työn fysiikkaa.

On hiljaista optimismia lähestyä ongelmaa tällä tavalla. Se muistuttaa insinöörejä siitä, että arkkitehtuuri voi olla rauhallisempaa kuin julkinen keskustelu. Meidän ei tarvitse valita yhtä kieltä voittaaksemme kiistan ikuisesti. Meidän on vain valittava oikea työkalu järjestelmän seuraavaa rehellistä kerrosta varten. Se on paljon kannattavampaa älykkyyttä.

Käytännön laboratorio: Rakenna pieni AMM-reitin arvioija

Rakentakaamme jotain tarpeeksi pientä ymmärtääksemme ja tarpeeksi todellista kosketeltavaksi.

Tavoitteena ei ole luoda Uniswapia uudelleen. Tavoitteena on tuntea kuinka nopeasti DEX-työstä tulee toistuvaa simulointia ja vertailua.

main.cpp

#include <cmath>
#include <iomanip>
#include <iostream>
#include <string>
#include <vector>

struct Pool {
    std::string name;
    double reserve_in;
    double reserve_out;
    double fee; // 0.003 for 0.3%
};

double swap_out(const Pool& p, double amount_in) {
    const double effective_in = amount_in * (1.0 - p.fee);
    return (effective_in * p.reserve_out) / (p.reserve_in + effective_in);
}

double two_hop(const Pool& a, const Pool& b, double amount_in) {
    const double mid = swap_out(a, amount_in);
    return swap_out(b, mid);
}

int main() {
    Pool eth_usdc_a{"ETH/USDC pool A", 500.0, 1750000.0, 0.003};
    Pool eth_usdc_b{"ETH/USDC pool B", 650.0, 2262000.0, 0.0005};
    Pool usdc_dai{"USDC/DAI stable pool", 900000.0, 901200.0, 0.0001};

    const double trade_eth = 4.0;

    const double direct_a = swap_out(eth_usdc_a, trade_eth);
    const double direct_b = swap_out(eth_usdc_b, trade_eth);
    const double routed = two_hop(eth_usdc_b, usdc_dai, trade_eth);

    std::cout << std::fixed << std::setprecision(4);
    std::cout << "Input: " << trade_eth << " ETH\n";
    std::cout << "Direct via " << eth_usdc_a.name << ": " << direct_a << " USDC\n";
    std::cout << "Direct via " << eth_usdc_b.name << ": " << direct_b << " USDC\n";
    std::cout << "Two-hop via " << eth_usdc_b.name << " -> " << usdc_dai.name
              << ": " << routed << " DAI\n";

    if (direct_b > direct_a) {
        std::cout << "Best direct route: " << eth_usdc_b.name << "\n";
    } else {
        std::cout << "Best direct route: " << eth_usdc_a.name << "\n";
    }
}

Rakentaa

Linux tai macOS:

g++ -O2 -std=c++20 -o amm_router main.cpp
./amm_router

Windows:

cl /O2 /std:c++20 main.cpp
.\main.exe

Miksi tällä on väliä

Tämäkin pieni ohjelma vihjaa jo ketjun ulkopuolisen DEX-työn todelliseen muotoon:

• toistuva polun arviointi
• maksullinen vertailu
• tilariippuvainen lähtö
• jatkuva jännite oikeellisuuden ja nopeuden välillä

Skaalaa tämä satoihin pooleihin, toistuviin tilapäivityksiin ja vastakkaiseen ajoituspaineeseen, niin alat ymmärtää, miksi kielen valinta lakkaa olemasta abstraktia hyvin nopeasti.

Testitehtävät harrastajille

1. Lisää liukastumistoleranssi ja hylkää reitit, joiden tehollinen tuotos alittaa määritetyn kynnyksen.
2. Laajenna ohjelmaa vertaamaan viittä tai kymmentä allasta kahden sijasta ja profiloi minne aika menee.
3. Lisää silmukka, joka arvioi reitin miljoona kertaa uudelleen hieman muuttuvilla varauksilla ja mittaa kuinka "lelu" reititin alkaa muistuttaa todellista kuumaa polkua.
4. Korvaa liukulukumuotoilu strukturoidulla numeerisella lokikirjauksella ja tarkkaile, kuinka paljon "ei-matemaattista" työtä esiintyy todellisen reittilogiikan ympärillä.
5. Lisää toinen versio Rust-kielellä tai muulla kielellä ja vertaa raakaa suoritusaikaa siihen, kuinka mukava kieli tuntuu, kun simulaatiosilmukasta tulee työn keskipiste.

Tämä on hyvä harjoitus, koska se paljastaa jotain hienovaraista: vaihto-ohjelmistoissa mielenkiintoinen vaikeus on usein useiden tavallisten kaavojen toistuvassa, tilapitoisessa, latenssiherkässä käytössä kerralla.

Yhteenveto

C++ ja Rust kuuluvat molemmat hajautettuun vaihtotekniikkaan, mutta ne kuuluvat sinne eri syistä. Rust ansaitsee luottamusta ekosysteemeihin ja kerroksiin, joissa valtion turvallisuus, tarkastettavuus ja ketjun natiivi työnkulku ovat keskeisiä. C++ ansaitsee luottamuksen kerroksille, joissa työ alkaa jälleen näyttää vaihtoinfrastruktuurilta: toistuva simulointi, markkinatietojen käsittely, reititys, haku ja muut hot-path-järjestelmät, jotka palkitsevat tiukasta muistin hallinnasta, ajoituksesta ja suorituskyvyn tarkistamisesta.

Hyödyllisin kysymys ei siis ole se, mikä kieli voittaa koko pinon. Se on se, mitä kerrosta todella suunnittelemme ja millaiseen epäonnistumiseen tällä kerroksella on vähiten varaa. Kun tämä kysymys kysytään rehellisesti, arkkitehtuurista tulee yleensä paljon selkeämpi ja väitteestä tulee vähemmän ideologinen. Hyvin suunniteltu DEX on harvoin kielen puhtauden muistomerkki. Se on käytännöllinen järjestely komponenteista, joista jokainen on kirjoitettu kielellä, joka parhaiten kunnioittaa sen kantamaa taakkaa.

Viitteet

1. Uniswap v3 whitepaper: https://uniswap.org/whitepaper-v3.pdf
2. Uniswap v3 -ydinvarasto: https://github.com/Uniswap/v3-core
3. Ethereum.org MEV-dokumentaatio: https://ethereum.org/developers/docs/mev/
4. Solana ohjelmien yleiskatsaus: Solana
5. Solana Rust-ohjelman kehitys: Solana
6. Ankkuridokumentaatio: https://www.anchor-lang.com/docs
7. dYdX-ketjun dokumentaatio: https://docs.dydx.exchange/
8. dYdX-integraatiodokumentaatio: https://docs.dydx.xyz/
9. dYdX ketjun ulkopuolisissa tilauskirjoissa ketjun sisäisellä tilityksellä: https://integral.dydx.exchange/dydx-closes-10m-series-b-investment/
10. Cosmos SDK dokumentaatio: SDK

    Miltä tämä näyttää, kun järjestelmä on jo paineen alainen

Kielen valinta dex-infrastruktuurissa on yleensä kiireellinen juuri sillä hetkellä, kun tiimi toivoi hiljaisempaa neljännestä. Ominaisuus on jo asiakkaiden edessä tai alustalla on jo sisäinen riippuvuus, ja järjestelmä on valinnut kyseisen viikon paljastaakseen, että sen elegantti teoria ja sen ajonaikainen käyttäytyminen ovat eläneet kohteliaasti erillistä elämää. Tästä syystä niin moni vakava insinöörityö alkaa sovinnolla. Tiimin on sovitettava yhteen se, mitä se uskoo järjestelmän tekevän, sen kanssa, mitä järjestelmä todella tekee kuormitettuna, muutoksen aikana ja sellaisissa määräajoissa, jotka tekevät kaikista hieman luovempia ja hieman vähemmän viisaita.

Salausjärjestelmien suunnittelussa tärkeimmät tapaukset ovat yleensä haku- ja simulaattoritaustajärjestelmät, latenssiherkät reitityspalvelut ja ketjun ulkopuolinen riski- ja selvitysinfrastruktuuri. Näillä tilanteilla on teknisiä, budjetti-, luottamus-, tiekartta- ja joskus mainevaikutuksia. Tekninen ongelma kasvaa poliittisesti suuremmiksi sillä hetkellä, kun useat tiimit ovat riippuvaisia ​​siitä, eikä kukaan voi selittää, miksi se käyttäytyy edelleen kuin pesukarhu seinien sisällä: meluisa yöllä, vaikea paikantaa ja kallis jättää huomiotta.

Siksi suosittelemme lukemaan ongelman käyttöpaineen ja toimitustodellisuuden linssin läpi. Suunnittelu voi olla teoreettisesti kaunis ja toiminnallisesti tuhoisa. Toinen malli voi olla melkein tylsä ​​ja silti viedä tuotetta eteenpäin vuosia, koska se on mitattavissa, korjattavissa ja rehellinen kompromissiensa suhteen. Vakavat insinöörit oppivat pitämään parempana toista luokkaa. Se tekee vähemmän eeppisiä puheita, mutta myös vähemmän hätätapahtumia, joissa kaikki puhuvat passiivisella äänellä eikä kukaan muista, kuka hyväksyi pikakuvakkeen.

Käytännöt, jotka vanhenevat jatkuvasti hyvin

Ensimmäinen kestävä käytäntö on pitää yksi edustava polku jatkuvassa mittauksessa. Ryhmät keräävät usein liian paljon epämääräistä telemetriaa ja liian vähän päätöslaatuista signaalia. Valitse polku, jolla on aidosti merkitystä, mittaa sitä toistuvasti ja kieltäydy antamasta keskustelua ajautua koristeelliseen tarinankerrontaan. DEX-infrastruktuurin kielenvalintatyössä hyödyllisiä toimenpiteitä ovat yleensä kuumapolun determinismi, toiminnan selkeys, interop-pinta ja simulaatiorealismi. Kun ne ovat näkyvissä, loput päätökset muuttuvat inhimillisemmiksi ja vähemmän mystisiksi.

Toinen kestävä käytäntö on erottaa todiste lupauksesta. Insinöörejä painostetaan usein sanomaan, että suunta on oikea, ennen kuin järjestelmä on ansainnut tämän johtopäätöksen. Vastusta sitä painetta. Rakenna ensin kapea todiste, varsinkin kun aihe on lähellä asiakkaita tai rahaa. Pienellä todennetulla parannuksella on enemmän kaupallista arvoa kuin suurella todentamattomalla kunnianhimolla. Tämä kuulostaa itsestään selvältä, kunnes vuosineljänneksen lopun tarkastelu muuttaa hypoteesin määräajaksi ja koko organisaatio alkaa kohdella optimismia kuin aikataulutusartefaktia.

Kolmas kestävä käytäntö on kirjoittaa suositukset omistajakielellä. Kappale, jossa sanotaan "parantaa suorituskykyä" tai "vahvistaa rajoja", on emotionaalisesti miellyttävä ja toiminnallisesti hyödytön. Kappale, joka kertoo kuka muuttaa mitä, missä järjestyksessä, millä palautusehdon kanssa, on se, joka todella selviää maanantaiaamuna. Täällä monet tekniset kirjoittamiset epäonnistuvat. Se haluaa kuulostaa enemmän edistyneeltä kuin se haluaa olla aikataulutettu.

Vastaesimerkkejä, jotka säästävät aikaa

Yksi yleisimmistä vastaesimerkeistä näyttää tältä: tiimillä on jyrkkä paikallinen menestys, oletetaan, että järjestelmä on nyt ymmärretty, ja sitten skaalaa idean paljon vaativampaan ympäristöön ilman, että mittauskuria päivitetään. Se on tekninen vastine, kun opetellaan uimaan hotellin uima-altaassa ja sitten pidettäisiin itsevarma TED-puhe meren säästä. Vesi on vettä, kunnes sitä ei ole.

Toinen vastaesimerkki on työkalujen inflaatio. Uusi profiloija, uusi ajonaika, uusi kojelauta, uusi agentti, uusi automaatiokerros, uusi kääre, joka lupaa harmonisoida vanhan kääreen. Mikään näistä asioista ei ole luonnostaan ​​huono. Ongelmana on, mitä tapahtuu, kun heitä pyydetään kompensoimaan rajaa, jota kukaan ei ole nimennyt selvästi. Järjestelmästä tulee sitten instrumentoidumpi, vaikuttavampi ja vain toisinaan ymmärrettävämpi. Ostajat tuntevat tämän hyvin nopeasti. Jopa ilman tätä ilmaisua he voivat haistaa, kun pinosta on tullut kallis korvike päätökselle.

Kolmas vastaesimerkki on ihmisen tarkastelun käsitteleminen automaation epäonnistumisena. Todellisissa järjestelmissä ihmisen tarkastelu on usein ohjaus, joka pitää automaation kaupallisesti hyväksyttävänä. Aikuiset tiimit tietävät, missä automatisoida aggressiivisesti ja missä pitää hyväksyntä tai tulkinta näkyvänä. Epäkypsät tiimit haluavat koneen tekevän kaiken, koska "kaikki" kuulostaa tehokkaalta diassa. Sitten tapahtuu ensimmäinen vakava tapaus, ja yhtäkkiä manuaalinen tarkistus löydetään uudelleen konversiokokemuksen vilpittömästi.

Suosittelemamme toimitusmalli

Jos työ on tehty hyvin, ensimmäisen suorituksen pitäisi vähentää stressiä antamalla tiimille riittävän vahva tekninen lukema, jotta se lopettaa kiistelyn. Sen jälkeen seuraavan rajoitetun toteutuksen pitäisi parantaa yhtä ratkaisevaa polkua, ja uudelleentestauksen pitäisi tehdä suunta luettavaksi sekä suunnittelulle että johdolle. Tämä järjestys on tärkeämpi kuin tarkka työkaluvalinta, koska se muuttaa teknisen taidon eteenpäinliikkeeksi.

Käytännössä suosittelemme kapeaa ensimmäistä sykliä: kerää esineitä, tee yksi kova diagnoosi, lähetä yksi rajoitettu muutos, testaa todellinen polku uudelleen ja kirjoita seuraava päätös selkeällä kielellä. Selkeällä kielellä on väliä. Ostaja harvoin katuu selkeyttä. Ostaja katuu usein olevansa vaikuttunut ennen kuin kuitit saapuvat.

Tässä myös sävyllä on väliä. Vahvan teknisen työn pitäisi kuulostaa siltä kuin se on kohdannut tuotannon ennenkin. Rauhallinen, tarkka ja hieman huvittunut hypeistä sen sijaan, että se ravitsee sitä. Tämä ääni välittää toimintasignaalin. Se osoittaa, että tiimi ymmärtää järjestelmäsuunnittelun vanhan totuuden: koneet ovat nopeita, tiekartat ovat hauraita, ja ennemmin tai myöhemmin lasku saapuu jokaisesta olettamuksesta, jonka annettiin pysyä runollisena.

Tarkistuslista, jota käyttäisimme ennen kuin kutsumme tämän valmiiksi

Salausjärjestelmäsuunnittelussa valmius ei ole mieliala. Se on tarkistuslista, jolla on seurauksia. Ennen kuin kutsumme DEX-infrastruktuurin kielenvalintaa valmiiksi laajempaan käyttöönottoon, haluamme, että muutama asia on tylsää parhaalla mahdollisella tavalla. Haluamme yhden polun, joka käyttäytyy ennustettavasti edustavan kuormituksen alla. Haluamme yhden mittasarjan, joka ei ole ristiriidassa itsensä kanssa. Haluamme joukkueen tietävän, missä raja menee ja mitä sen rikkominen merkitsisi. Ja haluamme työn tulosten olevan riittävän selkeitä, jotta joku toteutushuoneen ulkopuolella voi silti tehdä siitä järkevän päätöksen.

Tämä tarkistuslista koskettaa yleensä kuuman polun determinismia, toiminnan selkeyttä, yhteentoimivaa pintaa ja simulaatiorealismia. Jos luvut liikkuvat oikeaan suuntaan, mutta tiimi ei silti osaa selittää järjestelmää improvisoimatta, työ ei ole valmis. Jos arkkitehtuuri kuulostaa vaikuttavalta, mutta ei kestä vaatimatonta vastaesimerkkiä kentältä, teos ei ole valmis. Jos toteutus on olemassa, mutta palautustarina kuulostaa rukoukselta aikaleimoineen, teos ei ole valmis. Mikään näistä ei ole filosofisia vastaväitteitä. Ne ovat yksinkertaisesti muotoja, joissa kalliilla yllätyksillä on tapana esitellä itsensä.

Täällä myös tiimit huomaavat, ratkoivatko he todellista ongelmaa vai vain harjoittelivat osaamista sen yleisessä läheisyydessä. Monet tekniset ponnistelut tuntuvat onnistuneilta, kunnes joku pyytää toistettavuutta, tuotantotodisteita tai päätöstä, joka vaikuttaa budjettiin. Sillä hetkellä heikko työ hämärtyy ja vahva työ muuttuu oudon selväksi. Plain on hyvä. Pelkkä tarkoittaa yleensä sitä, että järjestelmä on lakannut luottamasta karismaan.

Kuinka suosittelemme puhumaan tuloksista

Lopullisen selityksen tulee olla riittävän lyhyt selviytyäkseen johtajuuden kokouksesta ja riittävän konkreettinen selviytyäkseen teknisestä katsauksesta. Se on vaikeampaa kuin miltä se kuulostaa. Liian tekninen kieli piilottaa järjestyksen. Liian yksinkertaistettu kielenkäyttö piilottaa riskin. Oikea keskitie on kuvata polkua, todisteita, rajallista muutosta ja seuraavaa suositeltua askelta tavalla, joka kuulostaa mieluummin rauhalliselta kuin voittoisalta.

Suosittelemme tällaista rakennetta. Sano ensin, mitä polkua arvioitiin ja miksi sillä oli merkitystä. Toiseksi sano, mikä oli vialla tai epävarmaa kyseisessä polussa. Kolmanneksi sano, mitä muutettiin, mitattiin tai vahvistettiin. Neljänneksi sano, mikä on vielä ratkaisematta ja mitä seuraava sijoitus ostaisi. Tämä rakenne toimii, koska se kunnioittaa sekä suunnittelua että ostokäyttäytymistä. Insinöörit haluavat yksityiskohtia. Ostajat haluavat sekvensoinnin. Kaikki haluavat vähemmän yllätyksiä, myös ihmiset, jotka teeskentelevät nauttivansa niistä.

Tällä tavalla puhumisen piilotettu hyöty on kulttuurinen. Tiimit, jotka selittävät teknisen työn selkeästi, tekevät sen yleensä myös selkeämmin. He lakkaavat käsittelemästä monitulkintaisuutta hienostuneisuutena. Heihin on vaikeampi tehdä vaikutuksen ammattikieltä ja helpompi luottaa vaikeiden järjestelmien kanssa. Se on yksi insinööritaidon aliarvostetuimmista muodoista.

Mitä emme edelleenkään kieltäytyisi väärentämästä

Jopa järjestelmän parantumisen jälkeen kypsät tiimit pitävät epävarmuuden rehellisenä kryptojärjestelmien suunnittelussa. Heikko mittaus vaatii selkeämpää näyttöä, kovat rajat selkeää kieltä ja rauhallisemmat demot todellista toimintavalmiutta. Epävarmuutta on vähennettävä; jotkut on nimettävä rehellisesti. Nämä kaksi tehtävää sekoitetaan siinä, kuinka kunniallisista projekteista tulee kalliita vertauksia.

Sama sääntö pätee kielenvalintaa koskeviin päätöksiin DEX-infrastruktuurissa. Jos tiimiltä puuttuu edelleen toistettava vertailukohta, luotettava palautuspolku tai selkeä omistaja kriittiselle käyttöliittymälle, hyödyllisin tulos voi olla terävämpi ei tai kapeampi seuraava askel suuremman lupauksen sijaan. Tämä kurinalaisuus pitää teknisen työn linjassa sen todellisuuden kanssa, jota sen on tarkoitus parantaa.

Tällä työskentelyllä on outo helpotus. Kun järjestelmä ei enää ole riippuvainen optimistisesta tarinankerronnasta, insinöörikeskustelu yksinkertaistuu, vaikka työ olisikin kovaa. Ja tuotannossa se on usein vähäistä armon muotoa.

Lisähuomautuksia Dex-infrastruktuurin suunnittelusta

Hyvä kielijako DEX-infrastruktuurissa näyttää yleensä vaatimattomalta paperilla. Yksi kieli omistaa paikan, jossa ennustettavuus, perinnöllinen vipuvaikutus tai raakajärjestelmien tuntemus ovat tärkeimpiä. Toinen omistaa paikan, jossa rajakuri ja uudempi komponenttien eristäminen tekevät toimitustarinasta terveellisemmän. Virhe on yrittää muuttaa kielenvalinta ideologiaksi. Kaupankäyntijärjestelmät eivät välitä ideologiasta. He välittävät menetetyistä paketeista, epävakaista jonoista, väärästä simulaatioluottamuksesta ja laskusta, joka teeskentelee muuta.

Siksi suosittelemme arkkitehtuurikarttoja, jotka osoittavat tarkalleen, missä kielet kohtaavat, kuinka ne saumat testataan ja mitkä toimintamittarit kuuluvat kummallekin puolelle. Jos sekalaista C++/Rust-pinoa ei voida selittää toiminnoille yhdessä rauhallisessa kaaviossa, se ei todennäköisesti ole valmis. Ja jos se voidaan selittää selkeästi, sekoitettu pino lakkaa usein näyttämään eksoottiselta. Se näyttää yksinkertaisesti tekniikalta, joka oli valmis valitsemaan istuvuuden muodin sijaan.

Kentän muistiinpanot todellisesta teknisestä katsauksesta

C++-järjestelmätoimituksessa työ muuttuu vakavaksi, kun demo kohtaa todellisen toimituksen, todelliset käyttäjät ja todelliset käyttökustannukset. Se on hetki, jolloin siisti idea alkaa käyttäytyä kuin järjestelmä, ja järjestelmillä on tunnetusti kuiva huumorintaju. He eivät välitä siitä, kuinka tyylikkäältä aloituspakka näytti. He välittävät rajoista, vikatiloista, käyttöönottopoluista ja siitä, voiko kukaan selittää seuraavan vaiheen keksimättä uutta mytologiaa pinon ympärille.

C++, Rust, and Decentralized Crypto Exchanges: Applicability and Efficiency:n kohdalla käytännön kysymys on, luoko se vahvemman toimituspolun ostajalle, jolla on jo paineita etenemissuunnitelman, alustan tai tietoturvatarkastuksen suhteen. Tuo ostaja ei tarvitse sumuksi kiillotettua luentoa. He tarvitsevat teknisen luennon, jota he voivat käyttää.

Mitä tarkastaisimme ensin

Aloitamme yhdellä edustavalla polulla: natiivi päättely, profilointi, HFT-polut, DEX-järjestelmät ja C++/Rust-modernisointivaihtoehdot. Tuon polun tulee olla tarpeeksi kapea mitatakseen ja riittävän leveä paljastaakseen totuuden. Ensimmäisen läpimenon pitäisi tallentaa allokointikäyttäytyminen, p99-viive, profiilin todisteet, ABI kitka ja vapauttaa luottamus. Jos nämä signaalit eivät ole saatavilla, projekti on edelleen enimmäkseen mielipidettä laboratoriotakissa, ja mielipiteellä on pitkä historia laskuttaa itsensä strategiana.

Ensimmäinen hyödyllinen artefakti on alkuperäisten järjestelmien luku, jossa on vertailuarvoja, profilointitodistusta ja laajennettu toteutussuunnitelma. Sen pitäisi näyttää järjestelmä sellaisena kuin se käyttäytyy, ei niin kuin kaikki toivoivat sen käyttäytyvän suunnittelukokouksessa. Jäljitys, toisto, pieni benchmark, politiikkamatriisi, jäsennyslaite tai toistettava testi kertovat usein tarinan nopeammin kuin toinen abstrakti arkkitehtuurikeskustelu. Hyvät esineet ovat hämmästyttävän töykeitä. Ne keskeyttävät toiveajattelua.

Vastaesimerkki, joka säästää aikaa

Kallis virhe on vastata ratkaisulla, joka on suurempi kuin ensimmäinen hyödyllinen todiste. Tiimi näkee riskin tai viiveen ja tavoittaa välittömästi uuden alustan, uudelleenkirjoituksen, laajan refaktorin tai hankintaystävällisen kojelaudan, jonka nimi kuulostaa siltä kuin se tekee joogaa. Joskus tämä mittakaava on perusteltu. Hyvin usein se on tapa lykätä mittausta.

Parempi liike on pienempi ja terävämpi. Nimeä raja. Ota todisteet talteen. Muuta yksi tärkeä asia. Testaa samaa polkua uudelleen. Päätä sitten, kannattaako seuraava investointi olla suurempi. Tämä rytmi on vähemmän dramaattinen kuin muutosohjelma, mutta sillä on taipumus selviytyä kosketuksista budjetteihin, julkaisukalentereihin ja tuotantotapahtumiin.

Suosittelemamme toimitustapa

Luotettavimmassa mallissa on neljä vaihetta. Kerää ensin edustavia esineitä. Toiseksi, muuta nämä esineet yhdeksi vaikeaksi tekniseksi diagnoosiksi. Kolmanneksi lähetä yksi rajoitettu muutos tai prototyyppi. Neljänneksi, testaa uudelleen samalla mittauskehyksellä ja dokumentoi seuraava päätös selkeällä kielellä. Tässä työluokassa CMake-kalusteet, profilointivaljaat, pienet alkuperäiset reprot ja kääntäjä/ajonaikaiset muistiinpanot ovat yleensä arvokkaampia kuin toinen tapaus yleisestä suunnasta.

Selkeällä kielellä on väliä. Ostajan tulee pystyä lukemaan tulos ja ymmärtämään, mikä muuttui, mikä on edelleen riskialtista, mikä voi odottaa ja mitä seuraava askel ostaisi. Jos suositusta ei voida ajoittaa, testata tai määrittää omistajalle, se on silti liian koristeellinen. Koristeellinen tekninen kirjoittaminen on miellyttävää, mutta tuotantojärjestelmiä ei tunneta miellyttävyyden palkitsemisesta.

Kuinka arvioida, auttoiko tulos

Kohdassa C++, Rust, and Decentralized Crypto Exchanges: Applicability and Efficiency tuloksen pitäisi parantaa ainakin yhtä kolmesta asiasta: toimitusnopeus, järjestelmän luottamus tai kaupallinen valmius. Jos se ei paranna mitään näistä, tiimi on saattanut oppia jotain, mutta ostaja ei ole vielä saanut hyödyllistä tulosta. Sillä erolla on merkitystä. Oppiminen on jaloa. Myös palkallisen toimeksiannon pitäisi siirtää järjestelmää.

Vahvin tulos voi olla kapeampi tiekartta, kieltäytyminen vaarallisen polun automatisoinnista, parempi raja mallin ympärille, puhtaampi natiiviintegraatio, mitattu todiste siitä, että uudelleenkirjoitusta ei vielä tarvita, tai lyhyt korjauslista, jonka johto voi todella rahoittaa. Vakava suunnittelu on sarja parempia päätöksiä, ei pukukilpailua työkaluista.

Miten SToFU suhtautuisi asiaan

SToFU käsittelee tätä ensin toimitusongelmana ja sitten teknologiaongelmana. Tuomme asiaan liittyvän suunnittelusyvyyden, mutta pitäisimme sitoutumisen ankkuroituna todisteisiin: polkuun, rajaan, riskiin, mittaukseen ja seuraavaan tekemisen arvoiseen muutokseen. Tarkoitus ei ole saada kovaa työtä kuulostamaan helpolta. Tarkoitus on tehdä seuraavasta vakavasta liikkeestä riittävän selkeä suoritettavaksi.

Sitä osaa ostajat yleensä arvostavat eniten. He voivat palkata mielipiteitä missä tahansa. He tarvitsevat tiimin, joka voi tarkastaa järjestelmän, nimetä todellisen rajoitteen, rakentaa tai vahvistaa oikean osion ja jättää taakseen artefakteja, jotka vähentävät sekaannusta puhelun päätyttyä. Meluisillä markkinoilla selkeys ei ole pehmeä taito. Se on infrastruktuuri.