Detsentraliseeritud rakenduste arhitektuur: tagumine osa, turva- ja kujundusmustrid

Detsentraliseeritud rakendused või rakendused vajavad kõrge turvalisuse ja usaldusväärsuse saavutamiseks spetsiaalset süsteemi disaini. Selles artiklis käsitlen mitut peamist põhimõtet, kuidas detsentraliseeritud rakenduste jaoks taguotsasid ja nutikaid lepinguid korralikult kujundada ja rakendada, võttes esmase näitena Ethereumi, kuigi suur osa sellest kehtiks EOS-i, Troni ja muude detsentraliseeritud andmeplatvormide jaoks.

Artikli esiletõstmine :

  • Kuidas salvestada privaatvõtmeid tagaküljele ilma turvaprobleemideta
  • Kuidas arukaid lepinguid õigesti kujundada ja mida "detsentraliseerida"
  • Detsentraliseeritud ja pooltsentraliseeritud rakenduste arhitektuuri näited
  • Kuidas toime tulla madala taseme asjadega, nagu võrgu koormus ja tõrked

See saab olema suur, teeme ära!

Detsentraliseeritud programmid ja plokiahel

Hoolimata asjaolust, et plokiahel seisab tänapäeval silmitsi paljude vastuvõtmis- ja reguleerimisraskustega, on see omamoodi tehnoloogia, mis jääb siia püsima, olgu see siis plokiahel, räsigraafik, tempo või mõni muu hajutatud pearaamatute tehnoloogia, mis algoritmist hoolimata veel ees on.

Peamise väärtuse, mida plokiahel ja muud sarnased tehnoloogiad toovad, saab üldistada järgmiselt: need võimaldavad inimestel kirjutada ja käitada programme, mida praktiliselt ei saa pärast loomist muuta ega neid täitmise ajal muuta. Teisisõnu, need programmid töötavad alati kavandatud viisil ja ükski osapool ei saa nende käitumist mõjutada.

See määratlus kehtib paljude tänapäeval eksisteerivate krüptovaluutade kohta, kui me peame neid programmideks, mis määratlevad müntide edasi-tagasi ülekandmise viisi. See seletab ka seda, miks krüptovaluutadel ja mitut tüüpi žetoonidel on tõeline väärtus: neid ei saa luua õhust, nende määratletud "aluseks olevate programmide" abil.

Ethereumi / EOS / Troni /… platvormid rakendavad erinevalt Bitcoinist keerukamat programmikihti, mis omakorda rakendab rakenduskeskkonda, võimaldades kõigil platvormi peale oma detsentraliseeritud programme kirjutada. Selle kasutaja määratletud programmid töötavad alati kavandatult, ilma eranditeta ja nende turvalisuse tagab platvorm.

Detsentraliseeritud rakendused

Need detsentraliseeritud võrgus töötavad turvalised ja muutmatud programmid koos traditsiooniliste esi- ja tagatehnoloogiatega on need, mida me tänapäeval nimetame detsentraliseeritud rakendusteks (ÐApps). Mõne neist kaudu saab neid osaliselt tsentraliseerida, kuid suurem osa tõeliselt detsentraliseeritud rakenduse tegevustest peaks toimuma keskerakonna kontrolli alt väljas.

Ette kujutada, mida me nimetame detsentraliseeritud rakendustes täna võtta kõik olemasolevad tsentraliseeritud web ressurss nagu _YouTube_ või _Instagram_ näitena ja kujutan ette, et selle asemel, parooliga kaitstud tsentraliseeritud konto olete oma " krüpto identiteedi " seotud veebi / mobile ressurss.

Seda pakub teile Walleti tarkvara. Selle identiteedi privaatvõti (saladus, mille olemasolu korral saate tegutseda selle identiteedi nimel) salvestatakse teie kohalikku seadmesse ja see ei lähe kunagi võrku, mistõttu keegi ei saa teie identiteeti kontrollida. Selle identiteedi, siis saab sooritada erinevaid tegevusi nii tsentraliseeritud (web ressurss kontrollib keskne asutus) ja detsentraliseeritud (mis on erinevate võrgu traditsioonilise www, mille eesmärgiks on kõrvaldada keskasutus) võrgud , kasutades veebilehel pöörduspunktina ja / või graafilise kasutajaliidesena. Selle „krüptoidentiteedi“ mõte seisneb selles, et teie toimingud on krüptograafiliselt turvatud ja keegi ei saa muuta seda, mida olete allkirjastanud ega allkirja.

Tänapäeval on rikketaluvate detsentraliseeritud võrkude nagu Ethereum, EOS või Tron arvutus- ja salvestusvõimalused piiratud. Kui need oleksid skaleeritavad, saaksime kogu detsentraliseeritud rakenduse, sealhulgas selle graafilise kasutajaliidese, andmete ja äriloogika salvestamiseks kasutada detsentraliseeritud võrke. Sellisel juhul nimetaksime neid rakendusi tõeliselt detsentraliseeritud / hajutatud.

Kuid kuna need võrgud ei ole täna skaleeritavad, kombineerime oma rakenduste maksimaalse detsentraliseerimistaseme saavutamiseks erinevaid lähenemisviise. Traditsiooniline tagumine ots, nagu me teame, ei lähe kuhugi. Näiteks:

  • Detsentraliseeritud rakenduse jaoks kasutame esiotsa hostimiseks taguotsi.
  • Kasutame taguotsi integreerimiseks mis tahes muu olemasoleva tehnoloogia ja teenustega. Päris maailmatasemel rakendused ei saa elada eraldatud keskkonnas.
  • Detsentraliseeritud võrgu jaoks piisavalt suurte andmete salvestamiseks ja töötlemiseks (eriti plokiahelaks) kasutame tagaosa. Praktiliselt on kogu rakendus ja selle äriloogika kuskil maailmas salvestatud, välja arvatud ainult plokiahela osa. Rääkimata sellest, et IPFS ja muud sarnased salvestuskihid ei saa tagada failidele ligipääsetavust, seega ei saa me neile loota ka ise faile majutamata. Teisisõnu, alati on vaja spetsiaalset töötavat serverit.

Turvalist ja osaliselt detsentraliseeritud rakendust ei saa tänapäevani kasutada ilma tugevat taguotsa kasutamata ja selle artikli eesmärk on selgitada, kuidas seda õigust teha.

(De) tsentraliseerimine ja märgid

Nii juhtub, et tänapäeval on peaaegu kõik detsentraliseeritud rakendused ehitatud nn märkide - kohandatud (või lihtsalt lihtsalt kloonitud) krüptorahade ümber, mis juhivad konkreetset detsentraliseeritud rakendust. Märgid on lihtsalt programmeeritav valuuta või vara, see selleks.

Tavaliselt on märgiks “tark leping” (kohandatud programm), mis on kirjutatud detsentraliseeritud platvormi peale nagu Ethereum. Mõne märgi omamise kaudu saate põhimõtteliselt veebiressursist või mobiilirakendusest erinevaid teenuseid hankida ja vahetada selle märgi millegi muu vastu. Põhipunkt on siin see, et märgis elab iseseisvalt ja seda ei kontrolli keskasutus.

Märkide ümber üles ehitatud rakenduste kohta on palju näiteid: alates paljudest kollektsioneeritavatest mängudest nagu CryptoKitties (ERC721 märgid) kuni teenusele orienteeritud rakendusteni nagu LOOM Network või isegi brauseritest nagu Brave ja mänguplatvormidena nagu DreamTeam (ERC20-ga ühilduvad märgid).

Arendajad ise määravad ja otsustavad, kui suurt kontrolli nad oma rakenduste üle saavad (või mitte) omavad. Nad saavad arukate lepingute peale üles ehitada kogu rakenduse äriloogika (nagu tegi CryptoKitties), või ei saa nutikaid lepinguid üldse kasutada, koondades kõik oma serveritesse. Parim lähenemine on siiski kuskil keskel.

Detsentraliseeritud võrkude tagumine osa

Tehnilisest vaatenurgast peab olema sild, mis ühendab märgid ja muud nutikad lepingud veebi / mobiilirakendusega.

Tänapäevastes täielikult detsentraliseeritud rakendustes, kus kliendid suhtlevad nutikate lepingutega otse, kitseneb see sild JSON RPC API võimekuseks avalikele API-dele või sõlmpunktidele nagu Infura, mis on omakorda sunnitud eksisteerima, kuna mitte iga seade ei saa käivitage ja toetage oma individuaalset võrgusõlme. Kuid see API pakub ainult põhilisi ja väga kitsaid funktsioone, mis vaevalt võimaldavad teha lihtsaid päringuid ega andmeid tõhusalt koondada. Seetõttu jõuab lõpuks kohandatud tagumine ots, mis muudab rakenduse pooltsentraliseeritud.

Kogu interaktsiooni detsentraliseeritud võrguga saab kitsendada vaid ühe või kahe punktini, sõltuvalt rakenduse vajadustest:

  1. Võrgusündmuste (nt märkide ülekandmine) kuulamine/ võrgu oleku lugemine .
  2. Tehingute avaldamine (olekut muutvate tarkade lepingute funktsioonide kasutamine, näiteks märgilevi)

Mõlema punkti rakendamine on üsna keeruline, eriti kui tahame luua turvalise ja usaldusväärse tagalahenduse. Siin on peamised punktid, mida me allpool jaotame:

  • Esiteks ei ole Ethereumis sündmuste otsimine kastist väljavalmis. Mitmel põhjusel: võrgusõlmed võivad suure hulga sündmuste toomisel ebaõnnestuda, võrgu kahvlite jms tõttu võivad sündmused kaduda või muutuda. Peame ehitama abstraktsioonikihi, et sünkroonida sündmused võrgust ja tagada nende usaldusväärne edastamine.
  • Sama tehingute avaldamise puhul peame abstraktseks saama Ethereumi madala taseme asjad, näiteks nonce'i loendurid ja gaasihinnangud, samuti tehingute uuesti avaldamise, pakkudes usaldusväärset ja stabiilset liidest. Veelgi enam, tehingute avaldamine tähendab privaatvõtmete kasutamist, mis nõuab täiustatud tagatisturvet.
  • Turvalisus. Võtame seda tõsiselt ja seisame silmitsi sellega, et on võimatu tagada, et privaatvõtmeid ei kahjustataks kunagi tagatipus. Õnneks on olemas lähenemisviis detsentraliseeritud rakenduse kujundamiseks, ilma et oleks vaja isegi tagakontosid kõrgelt kaitsta.

Meie praktikas pani see kõik meid looma Ethereumile tugeva tagalahenduse, mida nimetame Ethereumi väravaks . See võtab Ethereumi lõbustusest muid mikroteenuseid ja pakub sellega töötamiseks usaldusväärset API-d.

Kiiresti kasvava käivitusprogrammina ei saa me täielikku lahendust (veel) ilmselgetel põhjustel avaldada, kuid jagan kõike, mida peate teadma, et teie detsentraliseeritud rakendus toimiks laitmatult. Kui teil on siiski konkreetseid küsimusi või päringuid, võtke minuga julgelt ühendust. Ka selle artikli kommentaarid on väga hinnatud!

Detsentraliseeritud rakenduste arhitektuur

Artikli see osa sõltub suuresti konkreetse detsentraliseeritud rakenduse vajadustest, kuid proovime välja selgitada mõned põhilised koostoimemustrid, millele need rakendused on ehitatud (ÐPlatform = Detsentraliseeritud platvorm = Ethereum / EOS / Tron / Mis iganes):

Klient ⬌ ÐPlatform : täielikult detsentraliseeritud rakendused .

Klient (brauser või mobiilirakendus) suhtleb detsentraliseeritud platvormiga otse Ethereumi “rahakoti” tarkvara abil nagu Metamask, Trust või riistvarakotid nagu Trezor või Ledger. Sellisel viisil loodud DApps-i näited on CryptoKitties, Loomi delegeeritud kõne, krüpto-rahakotid ise (Metamask, Trust, Tron Wallet jt), detsentraliseeritud krüptovahetused nagu Etherdelta ja nii edasi.

ÐPlatformClientBack End lat latPlatform : tsentraliseeritud või pooltsentraliseeritud rakendused .

Kliendi suhtlemisel detsentraliseeritud platvormi ja serveriga on vähe ühist. Hea näide selle kohta on tänapäeval ükskõik milline ( tsentraliseeritud ) krüptovahetus, näiteks BitFinex või Poloniex: valuutad, millega börsil kaubeldakse, registreeritakse lihtsalt traditsioonilises andmebaasis. Saate oma andmebaasi saldot "täiendada", saates varad kindlale aadressile (latPlatvorm ⬌ klient) ja seejärel pärast rakenduses toiminguid (Back End ⬌ ÐPlatform) varasid tagasi võtta, kuid kõik, mida teete "ppApp" mõttes ise (klient ⬌ tagumine osa) ei tähenda teie otsest suhtlust latPlatformiga.

Teine näide on Etherscan.io, mis kasutab osaliselt tsentraliseeritud lähenemisviisi: saate teha kõik kasulikud detsentraliseeritud meetmeid seal, kuid rakendus ise lihtsalt ei ole mõtet ilma nende terviklik kolp (Etherscan pidevalt sünkroonib tehingute sõelub andmed ja salvestab selle, pakkudes lõpuks terviklikku API / kasutajaliidest).

Midagi vahepealset: endiselt, tsentraliseeritud või pooltsentraliseeritud rakendused .

Ülaltoodud lähenemised koos. Näiteks võib meil olla rakendus, mis pakub krüptoteenuse eest erinevaid teenuseid, võimaldades teil sisse logida ja oma krüptotunnusega teavet allkirjastada.

Loodetavasti ei tekita täielikult detsentraliseeritud rakenduste (Client ⬌ ÐPlatform) interaktsioonimuster küsimusi. Tuginedes sellistele hämmastavatele teenustele nagu Infura või Trongrid, saab lihtsalt luua rakenduse, mis serverit üldse ei vaja. Peaaegu kõik kliendipoolsed teegid, nagu Ethereum.js Ethereumile või Tron-Web Tronile, saavad nende avalike teenustega ühenduse luua ja võrguga suhelda. Keerukamate päringute ja ülesannete lahendamiseks peate võib-olla siiski oma serveri eraldama.

Ülejäänud suhtlusmustrid, mis hõlmavad taguotsa, muudavad asja huvitavamaks ja keerulisemaks. Kõigi nende pildile panemiseks kujutame ette juhtumit, kus meie tagumine ots reageerib mõnele võrgus toimuvale sündmusele. Näiteks avaldab kasutaja saastekvooditehingu, mis annab meile loa nende eest tasu võtta. Tasu võtmiseks peame avaldama tasutehingu vastusena eraldatud saastekvoodile:

Tagantpoolt vaadates juhtub järgmine:

  1. Kuulame konkreetset võrgusündmust, küsitledes pidevalt võrku.
  2. Kui oleme sündmuse kätte saanud, täidame mõne äriloogika ja otsustame seejärel vastuseks tehingu avaldada.
  3. Enne tehingu avaldamist soovime tagada, et see tõenäoliselt kaevandatakse (Ethereumis tähendab edukas tehingugaasi hindamine, et praeguse võrguseisundi suhtes pole vigu ). Kuid me ei saa garanteerida, et tehing õnnestub edukalt kaevandada .
  4. Privaatvõtit kasutades allkirjastame ja avaldame tehingu. Ethereumis peame kindlaks määrama ka tehingu gaasihinna ja gaasilimiidi.
  5. Pärast tehingu avaldamist küsitleme võrgu olekut pidevalt.
  6. Kui see võtab liiga kaua aega ja me ei saa tehingu olekut, peame selle uuesti avaldama või käivitama ebaõnnestumise stsenaariumi. Tehinguid võib kaotada erinevatel põhjustel: võrgu ülekoormatus, kaaslaste langetamine, võrgu koormuse suurenemine jne. Ethereumis võite kaaluda ka tehingu uuesti allkirjastamist erineva (tegeliku) gaasihinnaga.
  7. Pärast seda, kui oleme lõpuks oma tehingu kaevandanud, saame vajadusel teha rohkem äriloogikat. Näiteks võime tehingu lõpuleviimisest teavitada teisi taguotsa teenuseid. Mõelge ka enne tehingu lõplike otsuste tegemist paari kinnituse ootamisele: võrk on jaotatud ja seega võib tulemus muutuda mõne sekundiga.

Nagu näete, toimub palju! Kuid teie rakendus ei pruugi nõuda mõnda neist toimingutest, sõltuvalt sellest, mida proovite saavutada. Tugeva ja stabiilse tagumise otsa ehitamine eeldab kõigi eespool nimetatud probleemide lahendamist. Lammutame selle.

Detsentraliseeritud rakenduste tagumine osa

Siinkohal tahan välja tuua mõned punktid, mis tekitavad enamuse küsimustest, nimelt:

  • Võrgusündmuste kuulamine ja võrgust andmete lugemine
  • Tehingute avaldamine ja kuidas seda turvaliselt teha

Võrgusündmuste kuulamine

Nii Ethereumis kui ka teistes detsentraliseeritud võrkudes võimaldab nutikate lepinguliste sündmuste (või sündmuste logide või lihtsalt logide) kontseptsioon ahelavälistel rakendustel olla plokiahelas toimuvast teadlik. Nutikad lepingute arendajad saavad neid sündmusi luua nutika lepingukoodi mis tahes punktis.

Näiteks peab iga tunnuse ülekandmine tuntud ERC20 märgistandardis logima ülekande sündmuse, andes seega ahelavälistele rakendustele teada, et märgendi ülekanne on toimunud. Neid sündmusi “kuulates” saame teha mis tahes (uuesti) toiminguid. Näiteks saadavad mõned mobiilsed krüpto-rahakotid teile push / e-kirja teatise, kui märgid teie aadressile edastatakse.

Tegelikult pole usaldusväärset lahendust võrgusündmuste kastist väljas kuulamiseks. Erinevad raamatukogud võimaldavad teil jälgida / kuulata sündmusi, kuid on palju juhtumeid, kui midagi võib valesti minna, mille tulemuseks on kaotatud või töötlemata sündmused. Sündmuste kaotamise vältimiseks peame ehitama kohandatud taguotsa, mis säilitab sündmuste sünkroonimise protsessi.

Sõltuvalt teie vajadustest võib rakendus olla erinev. Kuid siin pildile panemine on üks võimalustest, kuidas luua usaldusväärset Ethereumi sündmuste edastamist mikroteenuste arhitektuuri osas:

Need komponendid töötavad järgmisel viisil:

  1. Sündmuste sünkroonimise teenus küsitleb võrku pidevalt, proovides uusi sündmusi hankida. Kui mõni uus sündmus on saadaval, saadab ta need sündmused sõnumibussi. Sündmuse eduka edastamise korral sõnumibussile, nagu ka plokiahelale, võime viimase sündmuse ploki salvestada, et järgmisel korral sellest plokist uusi sündmusi taotleda. Pidage meeles, et liiga paljude sündmuste korraga allalaadimine võib põhjustada alati ebaõnnestunud taotlusi, seega peate piirama võrgu kaudu taotletud sündmuste / blokeeringute arvu.
  2. Sõnumibuss (näiteks Rabbit MQ) suunab sündmuse igasse järjekorda, mis loodi iga tagateenuse jaoks eraldi. Enne sündmuste avaldamist määrab sündmuste sünkroonimise taustateenus marsruutimisvõtme (näiteks nutika lepingu aadress + sündmuse teema), samal ajal kui tarbijad (muud taustateenused) loovad järjekorrad, mis on tellitud ainult konkreetsete sündmuste jaoks.

Selle tulemusena saab iga tagateenus ainult neid sündmusi, mida ta vajab. Pealegi tagab sõnumibuss kõigi sündmuste kättetoimetamise pärast nende avaldamist.

Muidugi võite sõnumibussi asemel kasutada midagi muud: HTTP tagasihelistamised, pistikupesad jne. Sellisel juhul peate välja mõtlema, kuidas tagasihelistamised ise tagada: hallake eksponentsiaalseid / kohandatud tagasihelistamise katseid, juurutage kohandatud jälgimist ja nii edasi.

Tehingute avaldamine

Tehingu avaldamiseks detsentraliseeritud võrgus peame sooritama paar sammu:

  1. Tehingu ettevalmistamine. Koos tehinguandmetega tähendab see samm võrguoleku taotlemist, et teada saada, kas see tehing on kehtiv ja seda kavatsetakse kaevandada (gaasi hinnang Ethereumis) ja tehingu järjekorranumber (nonce Ethereumis). Mõni raamatukogu üritab seda teha kapoti all, kuid need sammud on olulised.
  2. Tehingu allkirjastamine. See samm tähendab privaatvõtme kasutamist. Tõenäoliselt soovite siin manustada kohandatud privaatvõtmete koostamise lahenduse (näiteks).
  3. Tehingu avaldamine ja uuesti avaldamine . Siinkohal on üks põhipunkte see, et teie avaldatud tehingul on alati võimalus eksida või detsentraliseeritud võrgust välja langeda. Näiteks Ethereumis saab avaldatud tehingu tühistada, kui võrgu gaasihind järsku tõuseb. Sellisel juhul peate tehingu uuesti avaldama. Lisaks võite tehingu uuesti avaldada muude parameetritega (vähemalt kõrgema gaasihinnaga), et see võimalikult kiiresti kaevandada. Seega võib tehingu uuesti avaldamine tähendada selle uuesti allkirjastamist, kui asendustehing ei olnud varem eelnevalt alla kirjutatud (erinevate parameetritega).

Kasutades ülaltoodud lähenemisviise, võite lõpuks ehitada midagi sarnast sellele, mis on esitatud allpool olevas järjestusdiagrammil. Sellel konkreetsel järjestusdiagrammil näitan (üldiselt!) Kuidas töötab plokiahela korduv arveldus (lingitud artiklis on rohkem):

  1. Kasutaja täidab nutilepingus funktsiooni, mis võimaldab lõppkokkuvõttes edukalt tasumistehingu sooritada.
  2. Konkreetse ülesande eest vastutav tagateenus kuulab tasude hüvitamise juhtumit ja avaldab tasutehingu.
  3. Kui laadimistehing on kaevandatud, saab see konkreetse ülesande eest vastutav tagateenus Ethereumi võrgult sündmuse ja täidab teatud loogikat (sealhulgas määrab järgmise laadimiskuupäeva).

Turvalisus ja nutikad lepingud

Tehingute avaldamine hõlmab alati privaatvõtme kasutamist . Võib tekkida küsimus, kas privaatvõtmeid on võimalik turvaliselt hoida. Noh, jah ja ei. On palju keerukaid strateegiaid ja erinevat tüüpi tarkvara, mis võimaldavad privaatvõtmeid tagaküljele üsna turvaliselt salvestada. Mõni privaatvõtme salvestuslahendus kasutab geograafiliselt hajutatud andmebaase, teised soovitavad kasutada isegi spetsiaalset riistvara. Igal juhul on pooltsentraliseeritud rakenduse kõige haavatavam koht, kus privaatne võti on kokku pandud ja seda kasutatakse tehingu allkirjastamiseks (või spetsiaalse riistvara korral tehingu allkirjastamise protseduuri käivitamise punkt). Seega pole teoreetiliselt 100% usaldusväärset lahendust, mis võimaldaks kuulikindlat kaitset salvestatud privaatvõtmete kahjustamise eest.

Mõelge nüüd nii. Paljudel juhtudel pole vaja isegi nii sageli tagaküljel privaatvõtmeid turvata. Selle asemel saate arukaid lepinguid ja kogu rakendust kujundada nii, et privaatvõtme leke ei mõjutaks nende tavapärast käitumist . Selle lähenemisviisi puhul pole oluline, kuidas volitatud kontod nutika lepinguga suhtlevad. Nad lihtsalt käivitavad nutika lepingu tavapärase töö tegemiseks ja nutikas leping ise täidab kõik nõutavad valideerimised. Ma nimetan seda operatiivkontode mustriks.

Nii saab hädaolukorras:

  • Ainus asi, mida ründaja saab varastada, on väike kogus eetrit (Ethereumi seisuga), mis on deponeeritud operatsioonikontodele tehingute avaldamiseks
  • Ründaja ei saa kahjustada arukat lepinguloogikat ega kedagi, kes selles protsessis osaleb
  • Ohustatud operatiivkontosid saab kiiresti asendada teistega, kuid see nõuab kas käsitsi asendamist (uute kontode loomine ja kontode autoriseerimine kõigis nutikates lepingutes) või täiendava lahenduse väljatöötamist, mis teeb kogu võluväel ühe supertehingu tehingu -turvaline (riistvara või multi-sig) põhikonto.

Näiteks Ethereumi lahenduse korduvas arveldamises, olenemata sellest, mis juhtub tagatipus, on korduv arvelduse nutikas leping loodud nii, et meil on terve kuu aega rikutud kontode väljavahetamiseks, kui mõni neist on ohustatud .

Kuid ikkagi, kui soovite oma taguotsaga privaatvõtmete salvestamise võimalikult turvaliseks saada, võite proovida kasutada Vault koos Ethereumi suurepärase pistikprogrammiga, mis salvestab ja haldab Ethereumi kontosid (jälgige ka meie avatud lähtekoodiga mooduleid - me varsti midagi sarnast välja andma). Ma ei hakka siin üksikasjadesse süvenema, ehkki võite külastada lingitud projekte ja ise sealt õppida.

See pole isegi kõik, mis mul öelda on. See artikkel osutus aga palju pikemaks, kui ma ootasin, nii et pean peatuma. Telli minu Medium / muud võrgud, kui olete huvitatud tarkvarast, krüptost, reisinõuannetest või soovite lihtsalt midagi huvitavat jälgida. Loodan, et olen andnud suure väärtusliku teabe ja leiate, et see on kasulik. Kommenteerige julgelt ja levitage seda artiklit!