Door: Brett McLain, Director of Engineering – Crypto, Fiat, Staking
Als u geïnteresseerd bent in cryptocurrencies, betalingen of staking en wilt helpen bij het bouwen van het financiële systeem van de toekomst, neemt het financieringsengineeringteam @ Kraken aan!
Toen Kraken tien jaar geleden werd gelanceerd, werden slechts drie cryptocurrencies ondersteund: BTC, LTC en XRP.
Tegenwoordig ondersteunt Kraken 82 activa op 33 blockchains en stakingsdiensten voor 8 cryptocurrencies.
Om de miljoenen stortingen, opnames en stakingstransacties per jaar bij Kraken te vergemakkelijken, exploiteert het crypto-engineeringteam honderden diensten om een vlotte geldstroom in en uit de beurs te verzekeren. De blockchain-software die aan deze services ten grondslag ligt, wordt regelmatig bijgewerkt; voor sommige van de meer actieve blockchains kunnen harde en zachte vorken maandelijks van aard zijn, terwijl andere, zoals Ethereum, tweejaarlijkse evenementen zijn. Over het algemeen zijn er wekelijks minstens enkele software-updates voor onze blockchain-infrastructuur.
De uitdaging om zo'n groot aantal verschillende services te ondersteunen en te updaten, en tegelijkertijd nieuwe te bouwen, kan ontmoedigend zijn.
In de afgelopen 12 maanden heeft ons team ondersteuning toegevoegd voor:
- 60 nieuwe cryptocurrencies:
- 39 x ERC20-tokens
- Polkadot (bij lancering van het mainnet)
- Kusama
- Filecoin (bij lancering van mainnet)
- Flow (bij lancering van het mainnet)
- Kava
- Energy Web Token (bij lancering van het mainnet)
- USDT (TRC20)
- 10 x Parachain Crowdleningen
- solarium
- 1 x SPL-token (serum)
- Mina
- 8 nieuwe inzetmiddelen:
- Polkadot (bij lancering van het mainnet)
- Kusama
- Ethereum 2.0 (bij lancering van het mainnet)
- Flow (bij lancering van het mainnet)
- Cardano
- Kosmos
- Kava
- solarium
Deze prestaties zijn gerealiseerd naast het onderhoud van onze bestaande integraties. De ingenieurs van het crypto-team zijn niet alleen verantwoordelijk voor de gateway-software die in eigen huis is geschreven, maar ook voor het onderhoud en de implementatie van onze blockchain-infrastructuur waarop onze gateways vertrouwen. De cadans van blockchain-ontwikkeling op deze projecten kan een zinderende zijn, met baanbrekende veranderingen en nieuwe nieuwe functies die vaak en soms met weinig waarschuwing verschijnen.
Dus, hoe slaagt Kraken erin om elk jaar tientallen nieuwe producten uit te brengen en tegelijkertijd het hoge tempo van de blockchain-ontwikkeling bij te houden?
End-to-end (E2E)-tests!
Waarom we E2E-tests waarderen en mocks vermijden
Sinds de begindagen bij Kraken ligt de nadruk erop dat E2E-tests de meest waardevolle soort tests zijn die een ingenieur kan bouwen. Unit-tests hebben hun plaats, maar veel ontwikkelaars die geen ervaring hebben met complexe integraties, hebben de neiging om unit-tests te schrijven voor elk stukje code dat ze bouwen in de overtuiging dat ze de algehele kwaliteit van de software die ze ontwikkelen verbeteren.
Dit pad, vol goede bedoelingen, kan op den duur vaak tot veel pijn leiden. Te veel vertrouwen op unit-tests heeft de neiging om uw architectuur te versterken; het is alsof je een laag epoxy op je hele codebasis giet. Je koppelt de code nauw aan de tests, waardoor de code stijver, inflexibeler en beter bestand is tegen refactoring. Als u een wijziging moet aanbrengen, moet u waarschijnlijk belangrijke wijzigingen in de tests aanbrengen en in sommige gevallen zelfs helemaal weggooien. Refactoring-code is een belangrijke mogelijkheid voor een engineeringteam om in hun toolkit te hebben en alles dat wrijving toevoegt aan het gemak van refactoring, moet zorgvuldig worden geëvalueerd voordat het wordt geïntroduceerd. Bij het refactoren van code vereist een goed ontworpen E2E-test vaak niet veel wijzigingen en biedt het flexibiliteit bij het aanpassen van de interne lef van een applicatie terwijl het ervoor zorgt dat het blijft werken zoals verwacht.
Betekent dit dat je geen unit-tests moet schrijven? Helemaal niet! Er zijn veel scenario's waarin unit-tests de perfecte oplossing zijn, maar we hebben geconstateerd dat voor complexe integraties E2E-tests beter werken. Over het algemeen zijn unit-tests het meest effectief wanneer ze zijn geschreven voor code die aan de volgende criteria voldoet:
- Algoritmisch complex met veel randgevallen.
- Strakke scope met goed gedefinieerde vereisten.
- Voltooit een enkele werkeenheid.
- Staatloos.
Deze kleine, strakke stukjes complexe code zijn vaak de bouwstenen van een grotere applicatie en zelfs als er een refactor zou plaatsvinden, zouden deze functies waarschijnlijk niet veranderen. In onze wereld zou dit zaken zijn als adresafleiding, adresvalidatie, ondertekening van transacties, enz.
De belangrijkste conclusie hier is dat we als klein engineeringteam nooit het volume aan services dat we momenteel ondersteunen, kunnen handhaven, en nieuwe producten bouwen zonder end-to-end tests. Unit-tests moeten worden beschouwd als tafelstakes, maar op zichzelf zouden ze niet voldoende zijn om bij te blijven in deze evoluerende ruimte. In plaats daarvan hebben we ervoor gekozen om zwaar te investeren in robuuste sets van integratie en E2E-tests die valideren dat onze services met succes zullen werken in hun meest gebruikelijke bedrijfsmodi.
Uitdagingen van E2E-tests
Hoewel E2E-tests krachtig kunnen zijn, zijn ze geen wondermiddel. Bij integratie met services van derden verliezen dit soort tests vaak een groot deel van hun waarde, omdat bepaalde eindpunten of interfaces moeten worden bespot om de stroom van een specifieke functie of aanroep volledig te testen. Spotten zijn slechts zo goed als uw begrip van de service die u bespot, en als gevolg daarvan kunnen ze foutgevoelig zijn wanneer updates frequent en groot van aard zijn. Het onderhouden van zowel je eigen code als je spot is een schending van het DRY-principe (herhaal jezelf niet), een term die is bedacht door David Thomas en Andrew Hunt in 'The Pragmatic Programmer'. In hun boek stellen ze dat "elk stukje kennis een enkele, ondubbelzinnige, gezaghebbende representatie binnen een systeem moet hebben." Het maken van een bespotte versie van een service betekent dat er nu twee mogelijk afwijkende exemplaren van die service zijn: uw bespotte versie en de daadwerkelijke versie. Fouten bij het vertalen van het gedrag van de bespotte afhankelijkheid is nu een andere zorg om rekening mee te houden.
Spijt te hulp
Gelukkig voor ons ondersteunen de meeste blockchains de mogelijkheid om tijdelijke privénetten te gebruiken die kunnen worden gebruikt als onderdeel van ons proces voor continue integratie (CI) / continue implementatie (CD). Het meest populaire voorbeeld hiervan is de regressietest (regtest) modus van Bitcoin. Wanneer je bitcoind start met de `-regtest` optie, creëert het een nieuwe lokale blockchain-omgeving waar je volledige controle over hebt. Het belangrijkste kenmerk van de regtest-modus is dat je een willekeurig aantal blokken naar believen kunt minen, waardoor je E2E-tests roundtrips kunnen voltooien voor stortingen en opnames van alle soorten en variaties, waarbij honderden scenario's binnen enkele seconden worden gesimuleerd. Edge-cases en andere unieke scenario's kunnen eenvoudig worden gesimuleerd in regtest-modus, zoals multisig-transacties, re-orgs, vervangen door vergoeding (RBF), kind betaalt voor ouder (CPFP) en meer! Deze tests zorgen er niet alleen voor dat onze code geen fouten bevat, maar valideert ook de eindstatus van de blockchain en onze grootboeken om ervoor te zorgen dat alles werkt zoals verwacht.
Als onderdeel van het proces om ondersteuning toe te voegen voor een nieuwe cryptocurrency op Kraken, bouwt het financieringsteam een regtest-raamwerk uit voor alle nieuwe vermeldingen. Deze code vormt de basis van ons onderhoudsregime: elke keer dat er een nieuwe versie wordt uitgebracht, is het gewoon een kwestie van de versie van de blockchain-node bij te werken en onze CI-pipeline opnieuw uit te voeren om ervoor te zorgen dat er geen ingrijpende wijzigingen zijn. Het zorgvuldig lezen van de release-opmerkingen en samenwerking met de community is nog steeds erg noodzakelijk, maar deze tests geven ons vertrouwen in het uitbrengen van nieuwe versies die we anders niet zouden hebben.
Creatieve oplossingen
Helaas voor ons zijn niet alle blockchains zo beproefd als Bitcoin. Nieuwe blockchains introduceren vaak nieuwe concepten en om onze klanten toegang te bieden tot de meest opwindende nieuwe technologieën, geeft Kraken er de voorkeur aan om ondersteuning voor nieuwe blockchains zo dicht mogelijk bij de start van het mainnet te lanceren. Om een nieuwe asset veilig te ondersteunen op of dicht bij de lanceringsdatum, moet Kraken soms complexe testharnassen ontwikkelen om vertrouwen te krijgen in de integratie en om ervoor te zorgen dat het geld van de klant geen risico loopt.
Een perfecte illustratie hiervan is toen Kraken ondersteuning voor Ethereum 2.0 lanceerde slechts 3 dagen nadat het mainnet op 1 december 2020 live ging. Hoewel duizenden individuen en bedrijven over de hele wereld Ethereum 2.0 hebben helpen testen op meerdere testnetten zoals Medalla en Spadina, zijn we nog steeds besloten om het concept van regtests naar een heel ander niveau te tillen met deze integratie. We wisten al vroeg dat Ethereum 2.0 een belangrijke ontwikkeling zou zijn, en dat geloof is waar gebleken, aangezien tot nu toe miljoenen ETH op de bakenketen zijn ingezet, waaronder meer dan 800,000 ETH die zijn ingezet door Kraken-klanten.
Hieronder ziet u een diagram van de reeks services die onze pijplijn voor continue integratie (CI) elke keer dat een ontwikkelaar code invoert in een van onze ETH2-coderepository's op en neer draait.
Op een hoog niveau is de teststroom:
- Start de primaire en alternatieve knooppunten van ETH1 (elk om de beurt minen voor consensus) met een genese die een initiële hoeveelheid ETH bevat om te testen.
- Start het ETH2-beacon-ketenknooppunt als een privéketen met behulp van een speciale minimale configuratiemodus waarbij slechts 16 validators nodig zijn om genesis te activeren.
- Implementeer ETH2 smart contract op de ETH1-blockchain.
- Stort ETH in het ETH2-depositocontract waar het geld wordt verbrand en validators worden gemaakt op het ETH2-externe validatorknooppunt. Dit zijn validators die alleen het ETH2-netwerk bedienen en worden behandeld alsof ze extern zijn aan Kraken-validators.
- Start ETH1- en ETH2-blokverkenners.
- Database starten.
- Start Gateway en ondertekenaars.
- Voeg klantverzoeken in om ETH -> ETH2 in te zetten.
- Gateway pikt klantverzoeken op en stuurt ETH naar het depositocontract op de ETH1-blockchain en creëert een overeenkomstig aantal validators op het ETH2-interne validatorknooppunt. Validators zijn gescheiden in interne en externe validatorsets, zodat we kunnen testen wat er gebeurt als onze validators uitvallen (om slashing, sancties, verloren beloningen te testen) en om te zien wat er gebeurt als de rest van het netwerk uitvalt of offline gaat, maar onze validators blijf op.
- Controleer totdat de validators actief zijn in de ETH2-keten, begin met het volgen van beloningen, uitbetalingen, slashing van tests en boetes, detectie van verloren beloningen en betaal beloningen aan klanten.
- Voer ons afzonderlijke financiële afstemmingsproces uit voor alle transacties om ervoor te zorgen dat alles in al onze grootboeken correct overeenkomt.
Het bovenstaande is slechts een samenvatting op hoog niveau van wat er gaande is binnen ons testkader; er zijn een aantal andere tests, controles en validaties die plaatsvinden. Als een ontwikkelaar iets moet debuggen of naar de status van een van beide netwerken moet kijken, kunnen ze de blokverkenners raadplegen om in één oogopslag te zien wat er precies is gebeurd. Normaal gesproken nemen we geen blokverkenners op in onze CI-pijplijn, maar gezien de complexiteit van de integratie, was het nuttig om tijdens de ontwikkelingsfase te visualiseren wat er in de keten gebeurde.
Je zou denken dat dit een enorme vertraging toevoegt aan onze CI-pijplijn, maar dat is gelukkig niet het geval. Momenteel duurt de volledige CI-pijplijn voor onze Ethereum 2.0-repo slechts 14 minuten om te draaien. Dit omvat het controleren / bouwen van alle afhankelijkheden, het starten van alle services, het implementeren van verschillende slimme contracten op de blockchain, het minen van blokken, het maken van validators en het doorlopen van alle 100+ testscenario's.
Conclusie
Het ontwikkelen van uitgebreide E2E-tests voor elke afzonderlijke blockchain-integratie bij Kraken kost een aanzienlijke hoeveelheid technische middelen. Het is een prijs die we graag betalen, omdat onze grootste zorg de veiligheid van het geld van onze klanten is en ervoor te zorgen dat ze een kwaliteitservaring op ons platform hebben. Zou ons team meer producten kunnen uitbrengen als we minder tijd aan tests zouden besteden bij het bouwen van nieuwe integraties? Zonder vraag. Dit zou echter indruisen tegen het ethos en de waarden van niet alleen het technische team, maar het bedrijf als geheel. Deze tests zorgen ervoor dat we veilig kunnen updaten naar nieuwe versies van blockchain-software, het vertrouwen vergroten tijdens hard/soft forks en de stress van ontwikkelaars verminderen bij het implementeren van wijzigingen.
Waarom zijn Kraken-ingenieurs enkele van de meest gerespecteerde in de branche? Dit bericht van Steve Hunt, Kraken's VP of Engineering, schetst onze waarden en toewijding om andere blockchain-ingenieurs te helpen.
Bron: https://blog.kraken.com/post/10227/testing-crypto-payments-staking-at-kraken/
- &
- 000
- 11
- 2020
- toegang
- Account
- actieve
- Alles
- Alle transacties
- Het toestaan
- Aanvraag
- architectuur
- rond
- aanwinst
- Activa
- Strijd
- baken ketting
- Bitcoin
- blockchain
- BTC
- bouw
- Gebouw
- Bellen
- gevallen
- uitdagen
- verandering
- Controles
- kind
- code
- samenwerking
- komst
- Gemeen
- gemeenschap
- Bedrijven
- afstand
- vertrouwen
- Overeenstemming
- blijft
- contract
- contracten
- Wij creëren
- crypto
- cryptocurrencies
- cryptogeld
- Database
- transactie
- vertraging
- Opsporing
- ontwikkelen
- Ontwikkelaar
- ontwikkelaars
- Ontwikkeling
- Director
- Vroeg
- rand
- effectief
- ingenieur
- Engineering
- Ingenieurs
- Milieu
- ERC20
- ETH
- ethereum
- Ethereum 2.0
- Ethos
- EVENTS
- uitwisseling
- SNELLE
- Kenmerk
- Voordelen
- Fiat
- financieel
- Flexibiliteit
- stroom
- Achtergrond
- vol
- functie
- financiering
- fondsen
- toekomst
- Algemeen
- Genesis
- goed
- groot
- hier
- Hoge
- Huis
- Hoe
- HTTPS
- Honderden
- Inclusief
- Laat uw omzet
- -industrie
- Infrastructuur
- integratie
- integraties
- isolatie
- IT
- houden
- sleutel
- kennis
- Kraken
- Groot
- lancering
- leiden
- Niveau
- Meldingen
- lokaal
- LTC
- maken
- Mijnbouw
- maanden
- Meest populair
- multisig
- netwerk
- Nieuwe mogelijkheden
- nieuwe producten
- knooppunten
- bieden
- werkzaam
- Keuze
- bestellen
- Overige
- Pijn
- Betaal
- betalingen
- platform
- Populair
- prijs
- privaat
- Producten
- projecten
- kwaliteit
- lezing
- verminderen
- vertrouwen
- Voorwaarden
- Resources
- REST
- Beloningen
- Risico
- lopen
- lopend
- Veiligheid
- scherm
- Diensten
- reeks
- Klein
- slim
- slim contract
- Slimme contracten
- So
- Software
- Tussenruimte
- inzet
- staking
- begin
- Land
- spanning
- ondersteuning
- ondersteunde
- steunen
- system
- Technologies
- tijdelijk
- proef
- Testen
- testen
- niet de tijd of
- teken
- top
- Tracking
- transactie
- Transacties
- bijwerken
- updates
- us
- waarde
- volume
- web
- week
- binnen
- Mijn werk
- wereld
- X
- XRP
- jaar