Gedecentraliseerde applicaties, of ÐApps, vereisen een speciaal systeemontwerp om hoge veiligheid en betrouwbaarheid te bereiken. In dit artikel ga ik verschillende hoofdprincipes behandelen voor het correct ontwerpen en implementeren van back-end en slimme contracten voor gedecentraliseerde applicaties, waarbij ik Ethereum als primair voorbeeld neem, hoewel veel ervan van toepassing zou zijn op EOS, Tron en andere gedecentraliseerde dataplatforms.
Hoogtepunten van artikel :
- Hoe u privésleutels op de achterkant kunt opslaan zonder zorgen over de beveiliging
- Hoe slimme contracten goed te ontwerpen en wat te 'decentraliseren'
- Voorbeelden van gedecentraliseerde en semi-gecentraliseerde applicaties
- Hoe om te gaan met zaken op laag niveau, zoals netwerkbelasting en storingen
Het wordt groot, laten we het doen!
Gedecentraliseerde programma's en blockchain
Ondanks het feit dat blockchain tegenwoordig met veel adoptie- en reguleringsproblemen wordt geconfronteerd, is het een soort technologie die er is om te blijven, of het nu gaat om blockchain, hashgraph, tempo of een andere gedistribueerde grootboektechnologie die nog moet komen, ongeacht het algoritme.
De belangrijkste waarde die blockchain en andere vergelijkbare technologieën bieden, kan als volgt worden gegeneraliseerd: ze stellen mensen in staat om programma's te schrijven en uit te voeren die praktisch niet kunnen worden gewijzigd nadat ze zijn gemaakt of waarmee tijdens de uitvoering kan worden geknoeid. Met andere woorden, deze programma's werken altijd zoals ze zijn ontworpen en geen enkele partij kan hun gedrag beïnvloeden.Deze definitie is geldig voor veel cryptocurrencies die tegenwoordig bestaan, als we ze beschouwen als programma's die bepalen hoe munten heen en weer kunnen worden overgedragen. Dit verklaart ook waarom cryptocurrencies en vele soorten tokens echte waarde hebben: ze kunnen niet uit het niets worden gegenereerd door hun gedefinieerde "onderliggende programma's".
Ethereum / EOS / Tron /… -platforms implementeren, in tegenstelling tot Bitcoin, een meer complexe programmalaag, die op zijn beurt de uitvoeringsomgeving implementeert waardoor iedereen zijn eigen gedecentraliseerde programma's bovenop het platform kan schrijven. Deze door de gebruiker gedefinieerde programma's werken altijd zoals ze zijn ontworpen, zonder enige uitzondering, en hun veiligheid wordt gegarandeerd door het platform.
Gedecentraliseerde applicaties
Deze veilige en onveranderlijke programma's die op een gedecentraliseerd netwerk draaien in combinatie met traditionele front-end en back-end technologieën zijn wat we tegenwoordig gedecentraliseerde applicaties (ÐApps) noemen . Doordat sommige ervan semi-gecentraliseerd kunnen zijn, zou een groot deel van de activiteiten in de echt gedecentraliseerde applicatie buiten de controle van een centrale partij moeten plaatsvinden.
Om je voor te stellen wat we tegenwoordig gedecentraliseerde applicaties noemen, neem dan een bestaande gecentraliseerde webresource zoals _YouTube_ of _Instagram_ als voorbeeld en stel je voor dat je in plaats van een met een wachtwoord beveiligd gecentraliseerd account je " crypto-identiteit " gebonden hebt aan de web- / mobiele bron.
Dat is wat Wallet Software u biedt. De privésleutel van deze identiteit (een geheim waarmee u namens deze identiteit kunt handelen) wordt opgeslagen op uw lokale apparaat en gaat nooit online, waardoor niemand anders dan u in staat is om deze identiteit te controleren. Met deze identiteit kunt u verschillende acties uitvoeren in zowel gecentraliseerde (webresource gecontroleerd door een centrale autoriteit) als gedecentraliseerde (wat een ander netwerk is dan het traditionele www, met als doel om de centrale autoriteit te elimineren) netwerken , met behulp van de website als toegangspunt en / of als grafische gebruikersinterface. Het hele punt van deze "crypto-identiteit" is dat uw acties cryptografisch beveiligd zijn, en dat niemand kan veranderen wat u heeft ondertekend of uw handtekening.
Tegenwoordig zijn de reken- en opslagmogelijkheden van fouttolerante gedecentraliseerde netwerken zoals Ethereum, EOS of Tron beperkt. Als ze schaalbaar waren, zouden we gedecentraliseerde netwerken kunnen gebruiken om de hele gedecentraliseerde applicatie op te slaan, inclusief de grafische gebruikersinterface, gegevens en bedrijfslogica. In dit geval zouden we deze applicaties echt gedecentraliseerd / gedistribueerd noemen.
Omdat die netwerken tegenwoordig echter niet schaalbaar zijn, combineren we verschillende benaderingen om het maximale decentralisatieniveau voor onze applicaties te bereiken. De "traditionele" achterkant zoals we die kennen, gaat nergens heen. Bijvoorbeeld:
- We gebruiken back-end om front-end te hosten voor een gedecentraliseerde applicatie.
- We gebruiken back-end voor integraties met andere bestaande technologieën en services. Echte applicaties van wereldklasse kunnen niet in een geïsoleerde omgeving leven.
- We gebruiken back-end om alles op te slaan en te verwerken dat groot genoeg is voor een gedecentraliseerd netwerk (met name blockchain). Praktisch gezien wordt de hele applicatie en zijn bedrijfslogica ergens in de wereld opgeslagen, met uitzondering van alleen het blockchain-gedeelte. Om nog maar te zwijgen, IPFS en vergelijkbare opslaglagen kunnen de toegankelijkheid van bestanden niet garanderen, daarom kunnen we er ook niet op vertrouwen zonder de bestanden zelf te hosten. Met andere woorden, er is altijd een speciale actieve server nodig.
Er is geen manier om een veilige en gedeeltelijk gedecentraliseerde applicatie te bouwen zonder vanaf vandaag een solide back-end te gebruiken, en het hele punt van dit artikel is om uit te leggen hoe je dit goed kunt doen.
(De) centralisatie en tokens
Het gebeurt zo dat bijna alle gedecentraliseerde applicaties tegenwoordig zijn gebouwd rond zogenaamde tokens - op maat gemaakte (of gewoon gekloonde) cryptocurrencies die een bepaalde gedecentraliseerde applicatie aansturen. Tokens zijn gewoon een programmeerbare valuta of activa, dat is alles.
Gewoonlijk is een token een 'smart contract' (een aangepast programma) dat bovenop het gedecentraliseerde platform zoals Ethereum is geschreven. Door een aantal tokens te bezitten, kunt u in principe verschillende services krijgen op een webresource of mobiele app en dit token inruilen voor iets anders. Het belangrijkste punt hier is dat het token op zichzelf leeft en niet wordt gecontroleerd door een centrale autoriteit.
Er zijn veel voorbeelden van applicaties die rond tokens zijn gebouwd: van talloze verzamelspellen zoals CryptoKitties (ERC721-tokens) tot meer servicegerichte apps zoals LOOM Network, of zelfs browsers zoals Brave en gamingplatforms zoals DreamTeam (ERC20-compatibele tokens).Ontwikkelaars bepalen en beslissen zelf hoeveel controle ze wel of niet hebben over hun applicaties. Ze kunnen de bedrijfslogica van de hele applicatie bovenop slimme contracten bouwen (zoals CryptoKitties deed), of ze kunnen helemaal geen gebruik maken van slimme contracten door alles op hun servers te centraliseren. De beste aanpak is echter ergens in het midden.
Back-end voor gedecentraliseerde netwerken
Vanuit technisch oogpunt moet er een brug zijn die tokens en andere slimme contracten verbindt met de web- / mobiele applicatie.
In de volledig gedecentraliseerde applicaties van vandaag, waar klanten rechtstreeks communiceren met slimme contracten, wordt deze brug beperkt tot JSON RPC API-mogelijkheden van openbare API's of knooppuntpools zoals Infura, die op hun beurt moeten bestaan vanwege het feit dat niet elk apparaat dat kan draaien en ondersteunen zijn individuele netwerkknooppunt. Deze API biedt echter slechts een basis en zeer beperkte set functies, die het nauwelijks mogelijk maken om eenvoudige zoekopdrachten uit te voeren of gegevens efficiënt samen te voegen. Hierdoor treedt uiteindelijk een aangepaste back-end op, waardoor de applicatie semi-gecentraliseerd wordt.
De hele interactie met het gedecentraliseerde netwerk kan worden teruggebracht tot slechts één of twee punten, afhankelijk van de toepassingsbehoeften:
- Luisteren naar de netwerkgebeurtenissen (zoals tokenoverdrachten)/ lezen van de netwerkstatus .
- Transacties publiceren (het aanroepen van statusveranderende slimme contractfuncties zoals tokenoverdracht).
Het implementeren van beide punten is best lastig, vooral als we een veilige en betrouwbare back-endoplossing willen bouwen. Hier zijn de belangrijkste punten die we hieronder zullen uiteenzetten:
- Allereerst is het ophalen van evenementen in Ethereum niet direct klaar voor productie. Om verschillende redenen: netwerkknooppunten kunnen falen tijdens het ophalen van een groot aantal gebeurtenissen, gebeurtenissen kunnen verdwijnen of veranderen door netwerkforks, enz. We moeten een abstractielaag bouwen om gebeurtenissen van het netwerk te synchroniseren en hun betrouwbare levering te garanderen.
- Hetzelfde geldt voor het publiceren van transacties, we moeten de low-level dingen van Ethereum, zoals nonce-tellers en gasschattingen, abstraheren, evenals het opnieuw publiceren van transacties, wat een betrouwbare en stabiele interface oplevert. Bovendien impliceert het publiceren van transacties het gebruik van privésleutels, wat geavanceerde back-endbeveiliging vereist.
- Veiligheid. We gaan het serieus nemen en onder ogen zien dat het onmogelijk is om te garanderen dat privésleutels nooit zullen worden aangetast op een back-end. Gelukkig is er een benadering om een gedecentraliseerde applicatie te ontwerpen zonder dat back-end-accounts zelfs sterk moeten worden beveiligd.
In onze praktijk zorgde dit alles ervoor dat we een robuuste back-endoplossing voor Ethereum creëerden die we Ethereum Gateway noemen . Het abstraheert andere microservices van het plezier van Ethereum en biedt een betrouwbare API om ermee te werken.
Als snelgroeiende startup kunnen we om voor de hand liggende redenen (nog) niet de complete oplossing onthullen, maar ik ga alles delen wat je moet weten om je gedecentraliseerde applicatie vlekkeloos te laten werken. Als u echter specifieke vragen of opmerkingen heeft, neem dan gerust contact met mij op. Reacties op dit artikel worden ook zeer gewaardeerd!
Gedecentraliseerde applicatiearchitectuur
Dit deel van het artikel is sterk afhankelijk van de behoeften van een bepaalde gedecentraliseerde applicatie, maar we zullen proberen een aantal basisinteractiepatronen op te lossen waarop deze applicaties zijn gebouwd (ÐPlatform = Decentralized Platform = Ethereum / EOS / Tron / Whatever):
Klant ⬌ ÐPlatform : volledig gedecentraliseerde applicaties .
De client (browser of mobiele applicatie) praat rechtstreeks met het gedecentraliseerde platform met behulp van Ethereum "wallet" -software zoals Metamask, Trust of hardware wallets zoals Trezor of Ledger. Voorbeelden van DApps die op een dergelijke manier zijn gebouwd, zijn CryptoKitties, Loom's Delegated Call, crypto-wallets zelf (Metamask, Trust, Tron Wallet, anderen), gedecentraliseerde crypto-uitwisselingen zoals Etherdelta enzovoort.
ÐPlatform ⬌ Client ⬌ Back End ⬌ ÐPlatform : gecentraliseerde of semi-gecentraliseerde applicaties .
De interactie tussen de klant en het gedecentraliseerde platform en de server heeft weinig gemeen. Het goede voorbeeld hiervan is elke ( gecentraliseerde ) crypto-uitwisseling van vandaag, zoals BitFinex of Poloniex: de valuta's die u verhandelt op beurzen worden eenvoudigweg geregistreerd in de traditionele database. U kunt uw databasesaldo "aanvullen" door activa naar een specifiek adres (ÐPlatform ⬌ Client) te sturen en vervolgens activa op te nemen na een aantal acties in de app (Back End ⬌ ÐPlatform), maar alles wat u doet in termen van een "ÐApp" zelf (Client ⬌ Back End) impliceert niet uw directe interactie met het ÐPlatform.
Een ander voorbeeld is Etherscan.io, dat een semi-gecentraliseerde aanpak gebruikt: je kunt daar alle nuttige gedecentraliseerde acties uitvoeren, maar de applicatie zelf heeft gewoon geen zin zonder hun uitgebreide back-end (Etherscan synchroniseert continu transacties, analyseert gegevens en slaat deze op, uiteindelijk een uitgebreide API / UI bieden).
Iets ertussenin: stilstaande, gecentraliseerde of semi-gecentraliseerde applicaties .
De bovenstaande benaderingen gecombineerd. We kunnen bijvoorbeeld een applicatie hebben die verschillende diensten levert in ruil voor crypto, waarmee u kunt inloggen en informatie kunt ondertekenen met uw crypto-identiteit.
Hopelijk roept het interactiepatroon van volledig gedecentraliseerde applicaties (Client ⬌ ÐPlatform) geen vragen op. Door te vertrouwen op zulke geweldige diensten als Infura of Trongrid, kan men eenvoudig een applicatie bouwen die helemaal geen server nodig heeft. Bijna alle client-side bibliotheken zoals Ethers.js voor Ethereum of Tron-Web voor Tron kunnen verbinding maken met deze openbare diensten en communiceren met het netwerk. Voor complexere vragen en taken moet u wellicht toch uw eigen server toewijzen.
De rest van de interactiepatronen met back-end maken de dingen interessanter en complexer. Om dit allemaal in een plaatje te plaatsen, stellen we ons een geval voor waarin onze back-end reageert op een gebeurtenis in het netwerk. De gebruiker publiceert bijvoorbeeld een emissierechtentransactie die ons toestemming geeft om deze in rekening te brengen. Om een vergoeding in rekening te brengen, moeten we de afschrijvingstransactie publiceren als reactie op de emissierechtengebeurtenis:
Vanuit het oogpunt van de achterkant is dit wat er gebeurt:
- We luisteren naar een bepaalde netwerkgebeurtenis door continu het netwerk te pollen.
- Zodra we een evenement hebben ontvangen, voeren we een aantal zakelijke logica uit en besluiten vervolgens om als reactie een transactie te publiceren.
- Voordat we de transactie publiceren, willen we ervoor zorgen dat deze waarschijnlijk wordt gedolven (in Ethereum betekent de succesvolle schatting van het transactiegas dat er geen fouten zijn ten opzichte van de huidige netwerkstatus ). We kunnen echter niet garanderen dat de transactie met succes zal worden gewonnen .
- Met behulp van een privésleutel ondertekenen en publiceren we de transactie. In Ethereum moeten we ook de gasprijs en gaslimiet van de transactie bepalen.
- Na het publiceren van de transactie, vragen we continu het netwerk naar de status ervan.
- Als het te lang duurt en we de status van de transactie niet kunnen krijgen, moeten we deze opnieuw publiceren of een "mislukking scenario" activeren. Transacties kunnen om verschillende redenen verloren gaan: netwerkcongestie, het laten vallen van peers, toename van de netwerkbelasting, etc. In Ethereum kunt u ook overwegen om een transactie opnieuw te ondertekenen met een andere (werkelijke) gasprijs.
- Nadat we eindelijk onze transactie hebben gewonnen, kunnen we indien nodig meer bedrijfslogica uitvoeren. We kunnen bijvoorbeeld andere back-endservices informeren over het feit dat de transactie is voltooid. Overweeg ook om te wachten op een aantal bevestigingen voordat u definitieve beslissingen neemt over de transactie: het netwerk is gedistribueerd en daarom kan het resultaat binnen enkele seconden veranderen.
Zoals u kunt zien, gebeurt er veel! Het is echter mogelijk dat uw toepassing sommige van deze stappen niet nodig heeft, afhankelijk van wat u probeert te bereiken. Maar het bouwen van een robuuste en stabiele back-end vereist een oplossing voor alle bovengenoemde problemen. Laten we dit opsplitsen.
Gedecentraliseerde applicaties Back-end
Hier wil ik enkele punten naar voren halen die bij de meeste vragen opkomen, namelijk:
- Luisteren naar netwerkgebeurtenissen en gegevens uit het netwerk lezen
- Transacties publiceren en hoe u dit veilig kunt doen
Luisteren naar netwerkevenementen
In Ethereum, evenals in andere gedecentraliseerde netwerken, zorgt een concept van slimme contractgebeurtenissen (of gebeurtenislogboeken, of gewoon logboeken) ervoor dat off-chain-applicaties op de hoogte zijn van wat er in de blockchain gebeurt. Deze evenementen kunnen op elk punt van de slimme contractcode door slimme contractontwikkelaars worden gemaakt.
Binnen de bekende ERC20-tokenstandaard moet bijvoorbeeld elke tokenoverdracht de Transfer-gebeurtenis loggen, zodat off-chain applicaties weten dat er een tokenoverdracht heeft plaatsgevonden. Door naar deze gebeurtenissen te “luisteren” kunnen wij eventuele (re) acties uitvoeren. Sommige mobiele crypto-wallets sturen u bijvoorbeeld een push / e-mailmelding wanneer tokens naar uw adres worden overgebracht.
In feite is er geen betrouwbare oplossing om out-of-the-box naar netwerkgebeurtenissen te luisteren. Met verschillende bibliotheken kunt u gebeurtenissen volgen / beluisteren, maar er zijn veel gevallen waarin er iets mis kan gaan, wat resulteert in verloren of niet-verwerkte gebeurtenissen. Om te voorkomen dat we gebeurtenissen verliezen, moeten we een aangepaste back-end bouwen die het synchronisatieproces van de gebeurtenissen in stand houdt.
Afhankelijk van uw wensen kan de implementatie variëren. Maar om u hier in beeld te brengen, is een van de opties om een betrouwbare levering van Ethereum-evenementen te bouwen in termen van microservice-architectuur:
Deze componenten werken op de volgende manier:
- Gebeurtenissynchronisatie back-end-service controleert voortdurend het netwerk en probeert nieuwe gebeurtenissen op te halen. Zodra er enkele nieuwe gebeurtenissen beschikbaar zijn, worden deze gebeurtenissen naar de berichtenbus gestuurd. Na succesvolle indiening van een evenement naar de berichtenbus, zoals voor blockchain, kunnen we het laatste evenementblok opslaan om de volgende keer nieuwe evenementen van dit blok aan te vragen. Houd er rekening mee dat het ophalen van te veel gebeurtenissen tegelijk kan resulteren in altijd mislukte verzoeken, dus u moet het aantal gebeurtenissen / blokkeringen dat u van het netwerk aanvraagt, beperken.
- De berichtenbus (bijvoorbeeld Rabbit MQ) stuurt de gebeurtenis naar elke wachtrij die voor elke back-endservice afzonderlijk is ingesteld. Voorafgaand aan het publiceren van gebeurtenissen, specificeert de back-endservice voor de synchronisatie van gebeurtenissen de routingsleutel (bijvoorbeeld een smart contractadres + een gebeurtenisonderwerp), terwijl consumenten (andere back-endservices) wachtrijen creëren die alleen voor bepaalde gebeurtenissen zijn geabonneerd.
Als gevolg hiervan krijgt elke back-endservice alleen die gebeurtenissen die hij nodig heeft. Bovendien garandeert de berichtenbus de aflevering van alle gebeurtenissen zodra ze erop zijn gepubliceerd.
U kunt natuurlijk iets anders gebruiken in plaats van de berichtenbus: HTTP-callbacks, sockets, etc. In dit geval moet u zelf uitzoeken hoe u de levering van callbacks kunt garanderen: beheer exponentiële / aangepaste callback-pogingen, implementeer aangepaste monitoring en spoedig.
Transacties publiceren
Er zijn een aantal stappen die we moeten uitvoeren om een transactie naar het gedecentraliseerde netwerk te publiceren:
- De transactie voorbereiden. Samen met transactiegegevens houdt deze stap in dat de netwerkstatus wordt aangevraagd om erachter te komen of deze transactie geldig is en zal worden gedolven (gasschatting in Ethereum) en het sequentiële nummer van de transactie (nonce in Ethereum). Sommige bibliotheken proberen dit onder de motorkap te doen, maar deze stappen zijn belangrijk.
- De transactie ondertekenen. Deze stap impliceert het gebruik van de privésleutel. Hoogstwaarschijnlijk wilt u hier de aangepaste oplossing voor het samenstellen van persoonlijke sleutels insluiten (bijvoorbeeld).
- De transactie publiceren en opnieuw publiceren . Een van de belangrijkste punten hier is dat uw gepubliceerde transactie altijd de kans heeft om verloren te gaan of te vallen van het gedecentraliseerde netwerk. In Ethereum kan de gepubliceerde transactie bijvoorbeeld worden geschrapt als de gasprijs van het netwerk plotseling stijgt. In dat geval moet u de transactie opnieuw publiceren. Bovendien wilt u misschien de transactie opnieuw publiceren met andere parameters (in ieder geval met een hogere gasprijs) om deze zo snel mogelijk te ontginnen. Het opnieuw publiceren van de transactie kan dus een nieuwe ondertekening inhouden, als de vervangende transactie niet eerder vooraf ondertekend was (met andere parameters).
Door de bovenstaande benaderingen te gebruiken, kunt u uiteindelijk iets bouwen dat lijkt op het ding dat in het onderstaande sequentiediagram wordt gepresenteerd. Op dit specifieke sequentiediagram laat ik (in het algemeen!) Zien hoe de blockchain-terugkerende facturering werkt (er is meer in een gelinkt artikel):
- De gebruiker voert een functie uit in een smart contract, waardoor de back-end uiteindelijk een succesvolle laadtransactie kan uitvoeren.
- Een back-endservice die verantwoordelijk is voor een bepaalde taak, luistert naar het geval van vergoeding en publiceert een betalingstransactie.
- Zodra de betalingstransactie is gedolven, ontvangt deze back-endservice die verantwoordelijk is voor een bepaalde taak een gebeurtenis van het Ethereum-netwerk en voert hij enige logica uit (inclusief het instellen van de volgende betalingsdatum).
Back-end beveiliging en slimme contracten
Bij het publiceren van transacties wordt altijd een privésleutel gebruikt . U vraagt zich misschien af of het mogelijk is om privésleutels veilig te houden. Nou ja en nee. Er zijn talloze complexe strategieën en verschillende soorten software waarmee privésleutels vrij veilig op de back-end kunnen worden opgeslagen. Sommige opslagoplossingen voor privésleutel gebruiken geografisch gedistribueerde databases, terwijl andere zelfs het gebruik van speciale hardware suggereren. In ieder geval is het meest kwetsbare punt van een semi-gecentraliseerde applicatie echter waar de privésleutel wordt samengesteld en gebruikt om een transactie te ondertekenen (of, in het geval van speciale hardware, een punt waarop een transactieondertekeningsprocedure wordt gestart). Daarom is er theoretisch geen 100% betrouwbare oplossing die kogelvrije bescherming mogelijk maakt tegen het compromitteren van opgeslagen privésleutels.
Denk nu op deze manier. In veel gevallen hoeft u zelfs niet zo vaak privésleutels aan de achterkant te beveiligen. In plaats daarvan kunt u slimme contracten en de hele applicatie zo ontwerpen dat een lek van een privésleutel hun normale gedrag niet beïnvloedt . Met deze aanpak maakt het niet uit hoe geautoriseerde accounts omgaan met het slimme contract. Ze 'triggeren' gewoon een slim contract om zijn gebruikelijke werk te doen, en het slimme contract voert zelf de vereiste validatie uit. Ik noem het het "operationele rekeningenpatroon".
Op deze manier in geval van nood:
- Het enige dat de aanvaller kan stelen, is een kleine hoeveelheid Ether (vanaf Ethereum) die op de operationele accounts wordt gestort voor het publiceren van transacties
- De aanvaller zal de slimme contractlogica noch iemand die bij het proces betrokken is, kunnen schaden
- Gecompromitteerde operationele accounts kunnen snel worden vervangen door andere, maar dit vereist ofwel handmatige vervanging (nieuwe accounts genereren en accounts opnieuw autoriseren in alle slimme contracten) of een extra oplossing ontwikkelen die alle magie doet met een enkele transactie van een super -veilige (hardware of multi-sig) master-account.
Bijvoorbeeld, in onze terugkerende facturering voor Ethereum-oplossing, wat er ook gebeurt op een back-end, is het slimme contract voor terugkerende facturering zo ontworpen dat we een hele maand de tijd hebben om de gecompromitteerde accounts te vervangen als een van hen gecompromitteerd is .
Maar toch, als u uw back-end privésleutelopslag zo veilig mogelijk wilt krijgen, kunt u proberen Vault te gebruiken met een geweldige plug-in voor Ethereum die Ethereum-accounts opslaat en beheert (houd ook onze open-source modules in de gaten - we binnenkort iets soortgelijks uitbrengen). Ik ga hier niet diep in de details duiken, maar je kunt de gekoppelde projecten bezoeken en daar zelf van leren.
Dit is niet eens alles wat ik te zeggen heb. Dit artikel bleek echter veel langer te zijn dan ik had verwacht, dus ik moet stoppen. Abonneer je op mijn Medium / andere netwerken als je geïnteresseerd bent in software, crypto, reistips of gewoon iets interessants wilt volgen. Ik hoop dat ik een groot waardevol stuk informatie heb verstrekt en je zult het nuttig vinden. Voel je vrij om commentaar te geven en dit artikel te verspreiden!