Decentralizovaná architektúra aplikácií: back-end, bezpečnostné a návrhové vzory

Decentralizované aplikácie alebo ÐApps vyžadujú na dosiahnutie vysokej bezpečnosti a spoľahlivosti špeciálny systémový dizajn. V tomto článku sa budem zaoberať niekoľkými hlavnými princípmi toho, ako správne navrhnúť a implementovať back-end a inteligentné zmluvy pre decentralizované aplikácie, pričom ako primárny príklad uvádzam Ethereum, aj keď sa väčšina z nich bude vzťahovať na EOS, Tron a ďalšie decentralizované dátové platformy.

Hlavné body článku:

  • Ako ukladať súkromné ​​kľúče na pozadí bez bezpečnostných problémov
  • Ako správne navrhnúť inteligentné zmluvy a čo „decentralizovať“
  • Príklady decentralizovanej a čiastočne centralizovanej aplikácie
  • Ako sa vysporiadať s materiálmi nízkej úrovne, ako je zaťaženie siete a zlyhanie

Bude to veľké, poďme na to!

Decentralizované programy a blockchain

Napriek tomu, že blockchain v súčasnosti čelí mnohým ťažkostiam s prijatím a reguláciou, je to druh technológie, ktorá tu ostane, či už je to blockchain, hashgraph, tempo alebo akákoľvek iná technológia distribuovanej knihy, ktorá príde, bez ohľadu na algoritmus.

Hlavná hodnota, ktorú blockchain a iné podobné technológie prinášajú, sa dá zovšeobecniť takto: umožňujú ľuďom písať a spúšťať programy, ktoré po vytvorení prakticky nemožno zmeniť ani s nimi počas vykonávania nemanipulovať. Inými slovami, tieto programy vždy fungujú tak, ako boli navrhnuté a žiadna strana nemôže ovplyvniť ich správanie.

Táto definícia je platná pre mnohé kryptomeny, ktoré dnes existujú, ak ich považujeme za programy, ktoré definujú, ako sa dajú mince prenášať tam a späť. To tiež vysvetľuje, prečo majú kryptomeny a mnoho druhov tokenov skutočnú hodnotu: nemôžu byť generované z ovzdušia pomocou ich definovaných „základných programov“.

Platformy Ethereum / EOS / Tron /…, na rozdiel od Bitcoinov, implementujú zložitejšiu programovú vrstvu, ktorá zase implementuje prostredie vykonávania, ktoré každému umožňuje písať svoje vlastné decentralizované programy na platformu. Tieto programy definované používateľom vždy fungujú tak, ako boli navrhnuté, bez akýchkoľvek výnimiek a ich bezpečnosť je zaručená platformou.

Decentralizované aplikácie

Tieto zabezpečené a nemenné programy bežiace na decentralizovanej sieti v kombinácii s tradičnými front-end a back-end technológiami dnes nazývame decentralizované aplikácie (ÐApps). Niektoré z nich môžu byť čiastočne centralizované, hlavná časť aktivít v skutočne decentralizovanej aplikácii by sa mala stať mimo kontroly centrálnej strany.

Keby ma niekto požiadal, aby som nakreslil, ako DApps dnes funguje, pravdepodobne by som to nakreslil

Ak si chcete predstaviť, čo dnes nazývame decentralizovanými aplikáciami, vezmite ako príklad akýkoľvek existujúci centralizovaný webový prostriedok, ako napríklad _YouTube_ alebo _Instagram_, a predstavte si, že namiesto centralizovaného účtu chráneného heslom je vaša „kryptoidentita“ viazaná na webový / mobilný prostriedok.

To vám poskytuje softvér Peňaženky. Súkromný kľúč z tejto identity (tajomstvo, s ktorým môžete konať v mene tejto identity) je uložený vo vašom miestnom zariadení a nikdy nie je online, takže nikto nie je schopný túto identitu ovládať, ale vy. S touto identitou môžete pomocou webových stránok vykonávať rôzne akcie v centralizovaných (webových zdrojoch riadených ústredným orgánom) a decentralizovaných (čo je iná sieť ako tradičné siete www, ktorej cieľom je vylúčiť ústredné orgány). ako prístupový bod a / alebo ako grafické užívateľské rozhranie. Celým zmyslom tejto „krypto identity“ je to, že vaše akcie sú kryptograficky zabezpečené a nikto nie je schopný zmeniť to, čo ste podpísali, ani váš podpis.

Výpočtové a ukladacie schopnosti decentralizovaných sietí odolných voči poruchám, ako sú Ethereum, EOS alebo Tron, sú dnes obmedzené. Keby boli škálovateľné, mohli by sme pomocou decentralizovaných sietí uložiť celú decentralizovanú aplikáciu vrátane jej grafického užívateľského rozhrania, údajov a obchodnej logiky. V takom prípade by sme tieto aplikácie nazvali skutočne decentralizovanými / distribuovanými.

Pretože však tieto siete dnes nie sú škálovateľné, kombinujeme rôzne prístupy na dosiahnutie maximálnej úrovne decentralizácie našich aplikácií. „Tradičný“ koniec, ako vieme, že nikam nevedie. Napríklad:

  • Používame back-end na hosťovanie front-endov pre decentralizovanú aplikáciu.
  • Používame back-end pre integráciu s inými existujúcimi technológiami a službami. Skutočné aplikácie na svetovej úrovni nemôžu žiť v izolovanom prostredí.
  • Používame back-end na ukladanie a spracovanie všetkého dostatočne veľkého pre decentralizovanú sieť (najmä blockchain). Prakticky je celá aplikácia a jej obchodná logika uložená niekde na svete, okrem časti blockchain. Nehovoriac o tom, IPFS a podobné úložné vrstvy nemôžu zaručiť prístupnosť súborov, a preto sa na ne nemôžeme spoľahnúť bez toho, aby sme ich sami hostili. Inými slovami, vždy existuje potreba vyhradeného bežiaceho servera.

Neexistuje žiadny spôsob, ako vytvoriť bezpečnú a čiastočne decentralizovanú aplikáciu bez použitia spoľahlivého koncového rozhrania k dnešnému dňu. Cieľom tohto článku je vysvetliť, ako to urobiť správne.

(De) centralizácia a tokeny

Stáva sa tak, že takmer všetky decentralizované aplikácie sú dnes postavené na tzv. Tokenoch - kryptomenách vytvorených na mieru (alebo jednoducho klonovaných), ktoré poháňajú konkrétnu decentralizovanú aplikáciu. Žetóny sú jednoducho programovateľnou menou alebo aktívami, to je všetko.

Kým kontrakty inteligentných tokenov určujú, ako môžu používatelia prenášať tokeny, zmluvy inteligentných aplikácií môžu rozšíriť všetko, čo chýba v inteligentných zmluvách o tokene. Obidve inteligentné zmluvy prebiehajú nad decentralizovanými sieťami

Zvyčajne je token „inteligentný kontrakt“ (vlastný program) napísaný na vrchole decentralizovanej platformy, ako je napríklad Ethereum. Vlastníctvom niektorých tokenov v podstate dokážete získať rôzne služby vo webovom zdroji alebo mobilnej aplikácii a tento token vymieňať za niečo iné. Kľúčovým bodom je, že token žije sám a nie je riadený ústredným orgánom.

Existuje mnoho príkladov aplikácií, ktoré sú zostavené okolo tokenov: od mnohých zbierateľných hier, ako sú CryptoKitties (tokeny ERC721), až po aplikácie orientované na služby, ako je sieť LOOM, alebo dokonca prehliadače ako Brave a herné platformy ako DreamTeam (tokeny kompatibilné s ERC20).

Vývojári sami určujú a rozhodujú o tom, akú kontrolu nad svojimi aplikáciami budú mať (alebo nebudú). Dokážu vybudovať obchodnú logiku celej aplikácie na základe inteligentných kontraktov (ako to urobili CryptoKitties), alebo vôbec nemôžu využívať inteligentné kontrakty a centralizovať všetko na svojich serveroch. Najlepším prístupom je však niekde uprostred.

Koniec pre decentralizované siete

Z technického hľadiska musí existovať most, ktorý spája tokeny a iné inteligentné zmluvy s webovou / mobilnou aplikáciou.

V dnešných plne decentralizovaných aplikáciách, kde klienti priamo komunikujú s inteligentnými zmluvami, je tento most zúžený na možnosti JSON RPC API verejných API alebo združení uzlov ako je Infura, ktoré sú naopak nútené existovať, pretože nie všetky zariadenia môžu spustiť a podporovať jeho jednotlivé sieťové uzly. Toto rozhranie API však poskytuje iba základné a veľmi úzke sady funkcií, ktoré sotva umožňujú vytváranie jednoduchých dopytov ani efektívne agregovanie údajov. Z tohto dôvodu sa nakoniec prispôsobí zadné rozhranie, vďaka čomu je aplikácia čiastočne centralizovaná.

Celú interakciu s decentralizovanou sieťou je možné zúžiť na jeden alebo dva body, v závislosti od potrieb aplikácie:

  1. Počúvanie sieťových udalostí (napríklad tokenové prenosy) / čítanie stavu siete.
  2. Publikovanie transakcií (vyvolávanie inteligentných kontraktných funkcií, ako je prenos tokenov).

Implementácia oboch týchto bodov je pomerne zložitá, najmä ak chceme vybudovať bezpečné a spoľahlivé riešenie typu back-end. Nižšie uvádzame hlavné body, ktoré tu zhrnieme:

  • Po prvé, v Ethereum nie je vyhľadávanie udalostí pripravené na výrobu z krabice. Z viacerých dôvodov: sieťové uzly môžu zlyhať pri získavaní veľkého počtu udalostí, udalosti môžu zmiznúť alebo sa zmeniť z dôvodu sieťových vidlíc atď. Musíme vytvoriť vrstvu abstrakcie, ktorá synchronizuje udalosti zo siete a zaručuje ich spoľahlivé doručenie.
  • To isté platí pre zverejňovanie transakcií, musíme abstraktne analyzovať nízkoúrovňové položky spoločnosti Ethereum, ako sú počítadlá nonce a odhady plynu, ako aj opätovné zverejňovanie transakcií, ktoré poskytujú spoľahlivé a stabilné rozhranie. Zverejňovanie transakcií navyše vyžaduje použitie súkromných kľúčov, čo vyžaduje pokročilé zabezpečenie back-end.
  • Bezpečnosť. Budeme to brať vážne a budeme čeliť tomu, že nie je možné zaručiť, že súkromné ​​kľúče nebudú nikdy na pozadí ohrozené. Našťastie existuje prístup k navrhovaniu decentralizovanej aplikácie bez potreby vysoko zabezpečeného záložného účtu.

V našej praxi to všetko viedlo k vytvoreniu robustného back-end riešenia pre Ethereum, ktoré nazývame Ethereum Gateway. Abstraktuje ďalšie mikroskopické služby od zábavy spoločnosti Ethereum a poskytuje spoľahlivé rozhranie API na prácu s ním.

Ako rýchlo sa rozvíjajúci startup nemôžeme zo zrejmých dôvodov zverejniť úplné riešenie (zatiaľ), ale ja sa podelím o všetko, čo potrebujete vedieť, aby vaša decentralizovaná aplikácia fungovala bezchybne. Ak však máte nejaké konkrétne otázky alebo otázky, neváhajte ma kontaktovať. Komentáre k tomuto článku sa tiež veľmi cenia!

Back-end monitoring pre Ethereum. Monitor demonštruje aktivity týkajúce sa hlavne našej opakujúcej sa fakturácie (každú hodinu však môžete vidieť vrcholy).

Decentralizovaná architektúra aplikácií

Táto časť článku vo veľkej miere závisí od potrieb konkrétnej decentralizovanej aplikácie, ale pokúsime sa vyriešiť niektoré základné vzorce interakcie, na ktorých sú tieto aplikácie postavené (ÐPlatform = Decentralizovaná platforma = Etereum / EOS / Tron / Čokoľvek):

Klient ⬌ latPlatforma: plne decentralizované aplikácie.

Klient (prehliadač alebo mobilná aplikácia) hovorí s decentralizovanou platformou priamo pomocou softvéru „peňaženky“ spoločnosti Ethereum, ako je Metamask, Trust alebo hardvérových peňaženiek, ako je Trezor alebo Ledger. Príklady DApps zostavených takýmto spôsobom sú CryptoKitties, Loom's Delegated Call, samotné kryptomenné peňaženky (Metamask, Trust, Tron Wallet, iní), decentralizované výmeny kryptom ako Etherdelta atď.

ÐPlatform ⬌ Klient ⬌ Back End ⬌ ÐPlatform: centralizované alebo semi-centralizované aplikácie.

Interakcia klienta s decentralizovanou platformou a serverom má málo spoločného. Dobrým príkladom je akákoľvek (centralizovaná) kryptomena v súčasnosti, napríklad BitFinex alebo Poloniex: meny, s ktorými obchodujete na burzách, sa jednoducho zaznamenávajú v tradičnej databáze. Zostatok databázy môžete „dobiť“ zaslaním podkladov na konkrétnu adresu (ÐPlatform ⬌ Klient) a po niektorých akciách v aplikácii (Back End ⬌ ÐPlatform) potom môžete vybrať prostriedky, avšak všetko, čo robíte v súvislosti s „pApp“ Samotný klient (klient) back end) neznamená vašu priamu interakciu s formulárom Ð.

Ďalším príkladom je Etherscan.io, ktorý používa semi-centralizovaný prístup: tam môžete robiť všetky užitočné decentralizované akcie, ale samotná aplikácia jednoducho nedáva zmysel bez ich komplexného zadného konca (Etherscan nepretržite synchronizuje transakcie, analyzuje údaje a ukladá ich, v konečnom dôsledku poskytuje komplexné rozhranie API / UI).

Niečo medzi tým: nehybné, centralizované alebo čiastočne centralizované aplikácie.

Vyššie uvedené prístupy sa kombinujú. Napríklad môžeme mať aplikáciu, ktorá poskytuje rôzne služby výmenou za krypto, čo vám umožní prihlásiť sa a podpísať informácie s vašou kryptoidentitou.

Dúfajme, že spôsob interakcie plne decentralizovaných aplikácií (klient lat „forma“) nevyvoláva žiadne otázky. Spoliehaním sa na také úžasné služby, ako sú Infura alebo Trongrid, môžete jednoducho vytvoriť aplikáciu, ktorá vôbec nevyžaduje server. Takmer všetky knižnice na strane klienta ako Ethers.js pre Ethereum alebo Tron-Web pre Tron sa môžu pripojiť k týmto verejným službám a komunikovať so sieťou. Pre zložitejšie otázky a úlohy však možno bude potrebné prideliť vlastný server.

Zvyšok interakčných vzorcov, ktoré zahŕňajú zadný koniec, robí veci zaujímavejšími a zložitejšími. Aby sme to všetko uviedli do obrazu, predstavme si prípad, keď náš koniec reaguje na nejakú udalosť v sieti. Napríklad používateľ zverejní transakciu s povolenkami, ktorá nám dáva povolenie na ich účtovanie. Ak chcete vykonať poplatok, musíme zverejniť transakciu s poplatkami v reakcii na emitovanú emisnú udalosť:

Príklad toku reakcie servera na činnosť používateľa v decentralizovanej sieti

Čo sa týka zadného pohľadu:

  1. Počúvame konkrétnu sieťovú udalosť nepretržitým prieskumom siete.
  2. Keď dostaneme nejakú udalosť, vykonáme nejakú obchodnú logiku a potom sa rozhodneme ako odpoveď zverejniť transakciu.
  3. Pred zverejnením transakcie sa chceme ubezpečiť, že sa bude ťažiť (úspešný odhad plynu transakcie v systéme Ethereum znamená, že neexistujú žiadne chyby oproti súčasnému stavu siete). Nemôžeme však zaručiť, že sa transakcia bude ťažiť úspešne.
  4. Pomocou súkromného kľúča transakciu podpíšeme a zverejníme. V spoločnosti Ethereum musíme tiež určiť cenu plynu a limit transakcie.
  5. Po zverejnení transakcie neustále zisťujeme jej stav.
  6. Ak to trvá príliš dlho a nemôžeme získať stav transakcie, musíme ju znova zverejniť alebo spustiť „scenár zlyhania“. Transakcie sa môžu stratiť z rôznych dôvodov: preťaženie siete, prerušenie spojenia, zvýšenie sieťového zaťaženia atď. V sieti Ethereum môžete tiež zvážiť opätovné podpísanie transakcie s inou (skutočnou) cenou plynu.
  7. Keď konečne začneme ťažiť naše transakcie, môžeme v prípade potreby vykonať ďalšiu obchodnú logiku. Môžeme napríklad informovať ďalšie služby typu back-end o skutočnosti, že transakcia bola dokončená. Zvážte tiež čakanie na pár potvrdení pred prijatím konečných rozhodnutí týkajúcich sa transakcie: sieť je distribuovaná a výsledok sa teda môže zmeniť v priebehu niekoľkých sekúnd.

Ako vidíte, je toho veľa! Vaša aplikácia však nemusí vyžadovať niektoré z týchto krokov v závislosti od toho, čo sa snažíte dosiahnuť. Budovanie robustného a stabilného operačného systému si však vyžaduje riešenie všetkých vyššie uvedených problémov. Poďme to rozobrať.

Koniec decentralizovaných aplikácií

Tu by som rád zdôraznil niektoré body, ktoré vynárajú väčšinu otázok, konkrétne:

  • Počúvanie sieťových udalostí a čítanie údajov zo siete
  • Publikovanie transakcií a ako to bezpečne robiť

Počúvanie sieťových udalostí

V spoločnosti Ethereum, ako aj v iných decentralizovaných sieťach, umožňuje koncepcia inteligentných zmluvných udalostí (alebo protokolov udalostí, alebo iba protokolov) vedieť, že aplikácie mimo reťazca majú prehľad o tom, čo sa deje v blockchainu. Tieto udalosti môžu vytvárať vývojári inteligentných kontraktov v ktoromkoľvek bode inteligentného zmluvného kódu.

Napríklad v rámci dobre známeho štandardu tokenov ERC20 musí každý prenos tokenov protokolovať udalosť Transfer, a tým oznámiť aplikáciám mimo reťazca, že došlo k prenosu tokenu. „Počúvaním“ týchto udalostí môžeme vykonať akékoľvek (opakované) akcie. Napríklad niektoré mobilné krypropeňaženky vám pošlú oznámenie push / e-mail, keď sa tokeny prenesú na vašu adresu.

V skutočnosti neexistuje spoľahlivé riešenie na počúvanie sieťových udalostí hneď po vybalení. Rôzne knižnice vám umožňujú sledovať / počúvať udalosti, existuje však veľa prípadov, keď sa niečo môže pokaziť, čo vedie k stratám alebo nespracovaniu udalostí. Aby sme sa vyhli strate udalostí, musíme si vytvoriť vlastný back-end, ktorý bude udržiavať proces synchronizácie udalostí.

V závislosti od vašich potrieb sa môže implementácia líšiť. Tu je však jedna z možností, ako môžete vybudovať spoľahlivé doručovanie udalostí Ethereum z hľadiska architektúry mikroprocesov:

Spoľahlivé doručovanie udalostí Ethereum všetkým back-end službám

Tieto komponenty fungujú nasledujúcim spôsobom:

  1. Služba back-end synchronizácie udalostí neustále oslovuje sieť a snaží sa načítať nové udalosti. Keď sú k dispozícii nejaké nové udalosti, odošle tieto udalosti do zbernice správ. Po úspešnom odoslaní udalosti na zbernicu správ, rovnako ako v prípade blockchainu, môžeme uložiť blok poslednej udalosti, aby sme mohli nabudúce požiadať o nové udalosti z tohto bloku. Majte na pamäti, že načítanie príliš veľkého počtu udalostí naraz môže mať za následok vždy zlyhávajúce žiadosti, takže musíte obmedziť počet udalostí / blokov, ktoré požadujete zo siete.
  2. Zbernica správ (napríklad Rabbit MQ) smeruje udalosť do každej fronty, ktorá bola nastavená individuálne pre každú službu typu back-end. Pred publikovaním udalostí služba back-end synchronizácie udalostí určuje smerovací kľúč (napríklad inteligentnú adresu kontraktu + tému udalosti), zatiaľ čo zákazníci (iné služby back-end) vytvárajú fronty, ktoré sú predplatené iba na konkrétne udalosti.

Výsledkom je, že každá služba typu back-end dostane iba tie udalosti, ktoré potrebuje. Navyše zbernica správ zaručuje doručenie všetkých udalostí po ich uverejnení.

Namiesto zbernice správ môžete samozrejme použiť aj niečo iné: spätné volania HTTP, sokety atď. V tomto prípade musíte zistiť, ako zaručiť doručenie spätných volaní sami: spravujte opakované / vlastné spätné volania, implementujte vlastné monitorovanie a tak ďalej.

Publikovanie transakcií

Aby sme mohli zverejniť transakciu v decentralizovanej sieti, musíme vykonať niekoľko krokov:

  1. Príprava transakcie. Spolu s údajmi o transakciách znamená tento krok vyžiadanie stavu siete, aby sa zistilo, či je táto transakcia platná a či sa bude ťažiť (odhad plynu v Ethereum) a poradové číslo transakcie (nonce in Ethereum). Niektoré z knižníc sa snažia to urobiť pod kapotou, tieto kroky sú však dôležité.
  2. Podpisovanie transakcie. Tento krok predpokladá použitie súkromného kľúča. S najväčšou pravdepodobnosťou tu budete chcieť vložiť vlastné riešenie zostavy súkromného kľúča (napríklad).
  3. Zverejnenie a opätovné publikovanie transakcie. Jedným z kľúčových bodov je, že vaša zverejnená transakcia má vždy šancu sa stratiť alebo vypadnúť z decentralizovanej siete. Napríklad v sieti Ethereum môže byť zverejnená transakcia zrušená, ak sa cena plynu náhle zvýši. V takom prípade musíte transakciu opätovne zverejniť. Okrem toho možno budete chcieť transakciu znovu publikovať s inými parametrami (aspoň s vyššou cenou plynu), aby sa čo najskôr ťažila. Opätovné publikovanie transakcie teda môže znamenať opätovné podpísanie, ak náhradná transakcia nebola predtým podpísaná (s rôznymi parametrami).
Vizualizované vyššie uvedené body týkajúce sa publikovania transakcií Ethereum

Použitím vyššie uvedených prístupov môžete nakoniec vytvoriť niečo podobné tomu, čo je uvedené v sekvenčnom diagrame nižšie. Na tomto konkrétnom sekvenčnom diagrame ukážem (všeobecne!), Ako funguje opakovaná fakturácia blockchainu (viac nájdete v prepojenom článku):

  1. Užívateľ vykonáva funkciu v inteligentnej zmluve, ktorá nakoniec umožňuje zadnému koncu vykonať úspešnú transakciu účtovania.
  2. Služba koncového operátora zodpovedná za konkrétnu úlohu počúva prípad pripočítania poplatku a zverejňuje transakciu poplatkov.
  3. Akonáhle je transakcia s poplatkami vyťažená, táto koncová služba zodpovedná za konkrétnu úlohu dostane udalosť zo siete Ethereum a vykonáva určitú logiku (vrátane nastavenia nasledujúceho dátumu nabíjania).
Všeobecná sekvenčná schéma fungovania opakovanej fakturácie blockchainu, demonštrujúca interakciu medzi back-end službami a sieťou Ethereum

Zabezpečenie koncových zariadení a inteligentné zmluvy

Publikovanie transakcií vždy zahŕňa použitie súkromného kľúča. Možno sa pýtate, či je možné zaistiť bezpečnosť súkromných kľúčov. Áno, aj nie. Existuje mnoho komplexných stratégií a rôznych typov softvéru, ktoré umožňujú pomerne bezpečne ukladať súkromné ​​kľúče na zadnej strane. Niektoré riešenia ukladania súkromných kľúčov používajú geograficky distribuované databázy, zatiaľ čo iné dokonca navrhujú použitie špeciálneho hardvéru. V každom prípade je však najzraniteľnejším bodom semi centralizovanej aplikácie to, kde je súkromný kľúč zostavený a použitý na podpísanie transakcie (alebo v prípade špeciálneho hardvéru bod spustenia postupu podpisovania transakcií). Teoreticky teda neexistuje žiadne stopercentné spoľahlivé riešenie, ktoré umožní ochranu pred guľkami pred narušením uložených súkromných kľúčov.

Teraz premýšľajte týmto spôsobom. V mnohých prípadoch dokonca nemusíte často zabezpečovať súkromné ​​kľúče na pozadí. Namiesto toho môžete navrhnúť inteligentné zmluvy a celú aplikáciu tak, aby únik súkromného kľúča neovplyvnil ich obvyklé správanie. Pri tomto prístupe nezáleží na tom, ako autorizované účty interagujú s inteligentnou zmluvou. Iba „spúšťajú“ inteligentnú zmluvu, aby vykonali svoju obvyklú prácu, a samotná inteligentná zmluva vykonáva všetky potrebné validácie. Hovorím tomu „vzor prevádzkových účtov“.

Vzor operačných účtov pre decentralizované aplikácie, kde pre svoje záložné účty nepotrebujete zabezpečenie na vojenskej úrovni

Takto v prípade núdze:

  • Jediné, čo môže útočník ukradnúť, je malé množstvo éteru (od Ethereum) uloženého na prevádzkové účty na zverejnenie transakcií.
  • Útočník nedokáže poškodiť inteligentnú zmluvnú logiku ani nikoho, kto je do procesu zapojený
  • Kompromitované operačné účty sa dajú rýchlo nahradiť inými účtami, čo si však vyžaduje buď manuálne nahradenie (vygenerovanie nových účtov a opätovnú autorizáciu účtov vo všetkých inteligentných zmluvách) alebo vyvinutie dodatočného riešenia, ktoré urobí všetko kúzlo jednou transakciou zo super -zabezpečený (hardvérový alebo multi-sig) hlavný účet.

Napríklad v našom opakujúcom sa fakturovaní za riešenie Ethereum, bez ohľadu na to, čo sa stane na konci, je opakujúca sa inteligentná zmluva o fakturácii navrhnutá tak, aby sme mali celý mesiac na výmenu kompromitovaných účtov, ak dôjde ku kompromitácii niektorého z nich. ,

Ak však chcete zaistiť čo najbezpečnejšie ukladanie súkromných kľúčov typu back-end, môžete skúsiť použiť trezor s vynikajúcim doplnkom pre Ethereum, ktorý ukladá a spravuje účty Ethereum (tiež sledujte naše open-source moduly - my čoskoro vydáme niečo podobné). Nebudem sa ponoriť hlboko do detailov, aj keď môžete navštíviť súvisiace projekty a učiť sa odtiaľ sami.

To nie je ani všetko, čo musím povedať. Tento článok sa však ukázal byť omnoho dlhšie, ako som očakával, takže musím prestať. Ak sa zaujímate o softvér, kryptografiu, tipy na cestovanie alebo ak chcete sledovať niečo zaujímavé, prihláste sa na odber mojich stredných / iných sietí. Dúfam, že som poskytol veľké hodnotné informácie a zistíte, že sú užitočné. Neváhajte komentovať a šíriť tento článok!