Decentralizirane aplikacije ili ÐApps zahtijevaju poseban dizajn sustava za postizanje visoke sigurnosti i pouzdanosti. U ovom ću članku pokriti nekoliko glavnih principa kako pravilno dizajnirati i implementirati pozadinske i pametne ugovore za decentralizirane aplikacije, uzimajući Ethereum kao primarni primjer, iako bi se velik dio toga odnosio na EOS, Tron i druge decentralizirane podatkovne platforme.
Izdvajamo iz članka :
- Kako pohraniti privatne ključeve na stražnjoj strani bez sigurnosnih razloga
- Kako pravilno dizajnirati pametne ugovore i što "decentralizirati"
- Primjeri arhitekture decentraliziranih i polucentraliziranih aplikacija
- Kako se nositi s niskorazinskim stvarima poput mrežnog opterećenja i kvarova
Bit će veliko, učinimo to!
Decentralizirani programi i Blockchain
Unatoč činjenici da se blockchain danas suočava s puno poteškoća u usvajanju i regulaciji, to je vrsta tehnologije koja će ostati ovdje, bilo da se radi o blockchainu, hashgraphu, tempu ili bilo kojoj drugoj tehnologiji distribuirane knjige koja tek dolazi, bez obzira na algoritam.
Glavna vrijednost koju blockchain i druge slične tehnologije donose može se generalizirati na sljedeći način: oni omogućuju ljudima da pišu i pokreću programe koji se praktički ne mogu mijenjati nakon stvaranja niti mijenjati tijekom izvršenja. Drugim riječima, ti se programi uvijek pokreću onako kako su dizajnirani i niti jedna strana ne može utjecati na njihovo ponašanje.Ova definicija vrijedi za mnoge kriptovalute koje danas postoje ako ih smatramo programima koji definiraju kako se kovanice mogu prenositi naprijed-nazad. To također objašnjava zašto kriptovalute i mnoge vrste tokena imaju stvarnu vrijednost: ne mogu se generirati iz zraka, prema definiranim "osnovnim programima".
Ethereum / EOS / Tron /… platforme, za razliku od Bitcoina, implementiraju složeniji programski sloj, koji zauzvrat implementira izvršno okruženje omogućavajući bilo kome da napiše vlastiti decentralizirani program na vrh platforme. Ovi korisnički definirani programi uvijek se izvode prema dizajnu, bez ikakvih izuzetaka, a njihovu sigurnost jamči platforma.
Decentralizirane aplikacije
Ovi sigurni i nepromjenjivi programi koji se izvode na decentraliziranoj mreži u kombinaciji s tradicionalnim front-end i back-end tehnologijama danas nazivamo decentraliziranim aplikacijama (ÐApps). Kroz neke od njih mogu biti polucentralizirani, veći dio aktivnosti u doista decentraliziranoj aplikaciji trebao bi se odvijati izvan kontrole središnje stranke.
Da biste zamislili ono što danas nazivamo decentraliziranim aplikacijama, uzmite bilo koji postojeći centralizirani web resurs poput _YouTube_ ili _Instagram_ kao primjer i zamislite da umjesto centraliziranog računa zaštićenog lozinkom imate svoj " kripto identitet " vezan za web / mobilni resurs.
To vam nudi softver Novčanik. Privatni ključ ovog identiteta (tajna, čiji možete i djelovati u njegovo ime) pohranjuje se na vašem lokalnom uređaju i nikad ne ide na mrežu, što nikoga ne može kontrolirati osim vas. S ovim identitetom, možete obavljati različite akcije u oba centralizirano (web resurs pod kontrolom središnje vlasti) i decentraliziranog (koji je različit mreža od tradicionalnih www, cilj kojih je da se eliminiraju središnje tijelo) mreže , pomoću web stranice kao pristupna točka i / ili kao grafičko korisničko sučelje. Cijela poanta ovog "kripto identiteta" je u tome što su vaše akcije kriptografski zaštićene i nitko nije u stanju promijeniti ono što ste potpisali niti vaš potpis.
Danas su računske i skladišne mogućnosti decentraliziranih mreža otpornih na kvarove poput Ethereuma, EOS-a ili Trona ograničene. Da su skalabilne, mogli bismo koristiti decentralizirane mreže za pohranu cijele decentralizirane aplikacije, uključujući njezino grafičko korisničko sučelje, podatke i poslovnu logiku. U ovom bismo slučaju te programe nazvali uistinu decentraliziranima / distribuiranima.
Međutim, budući da te mreže danas nisu skalabilne, kombiniramo različite pristupe kako bismo postigli maksimalnu razinu decentralizacije naših aplikacija. "Tradicionalni" kraj, kakav znamo, ne ide nikamo. Na primjer:
- Stražnji kraj koristimo za hostiranje prednjeg kraja za decentraliziranu aplikaciju.
- Koristimo pozadinu za integraciju s bilo kojom drugom postojećom tehnologijom i uslugom. Prave aplikacije svjetske klase ne mogu živjeti u izoliranom okruženju.
- Koristimo back end za pohranu i obradu bilo čega dovoljno velikog za decentraliziranu mrežu (posebno blockchain). Praktički, cijela aplikacija i njena poslovna logika pohranjeni su negdje u svijetu, isključujući samo blockchain dio. Da ne spominjem, IPFS i slični slojevi za pohranu ne mogu jamčiti pristup datotekama, stoga se na njih ne možemo osloniti bez da sami hostiramo datoteke. Drugim riječima, uvijek postoji potreba za namjenskim poslužiteljem koji radi.
Od danas ne postoji način za izgradnju sigurne i djelomično decentralizirane aplikacije bez upotrebe solidne pozadine, a cijela poanta ovog članka je objasniti kako to ispravno učiniti.
(De) centralizacija i tokeni
Dogodi se da su gotovo sve decentralizirane aplikacije danas izgrađene oko takozvanih tokena - prilagođenih (ili samo jednostavno kloniranih) kripto valuta koje pokreću određenu decentraliziranu aplikaciju. Tokeni su jednostavno programabilna valuta ili imovina, to je to.
Obično je token "pametni ugovor" (prilagođeni program) napisan na vrhu decentralizirane platforme poput Ethereuma. Posjedujući neke tokene, u osnovi možete dobiti različite usluge na web resursima ili mobilnim aplikacijama i zamijeniti ovaj token za nešto drugo. Ključna stvar ovdje je da token živi sam od sebe i da ga ne kontrolira središnja vlast.
Mnogo je primjera aplikacija koje se grade oko tokena: od brojnih kolekcionarskih igara poput CryptoKitties (ERC721 tokeni) do više orijentiranih na usluge poput LOOM Network ili čak preglednika poput Brave i igraćih platformi poput DreamTeam (ERC20 kompatibilni tokeni).Programeri sami određuju i odlučuju koliko će imati (ili neće) kontrolu nad svojim aplikacijama. Oni mogu graditi poslovnu logiku cijele aplikacije na vrhu pametnih ugovora (kao što su to radili CryptoKitties) ili, uopće ne mogu koristiti pametne ugovore, centralizirajući sve na svojim poslužiteljima. Međutim, najbolji je pristup negdje u sredini.
Pozadina za decentralizirane mreže
S tehničkog gledišta, mora postojati most koji povezuje tokene i druge pametne ugovore s web / mobilnom aplikacijom.
U današnjim potpuno decentraliziranim aplikacijama, gdje klijenti izravno komuniciraju s pametnim ugovorima, ovaj je most sužen na mogućnosti JSON RPC API-ja javnih API-ja ili spremišta čvorova poput Infure, koji su zauzvrat prisiljeni postojati zbog činjenice da ne može svaki uređaj pokrenite i podržite svoj pojedinačni mrežni čvor. Međutim, ovaj API pruža jedini osnovni i vrlo uski skup funkcija, koji jedva omogućuju izradu jednostavnih upita niti učinkovito objedinjavanje podataka. Zbog toga se na kraju pokreće prilagođeni stražnji kraj, što čini aplikaciju polucentraliziranom.
Cjelokupna interakcija s decentraliziranom mrežom može se suziti na samo jednu ili dvije točke, ovisno o potrebama aplikacije:
- Slušanje mrežnih događaja (poput prijenosa tokena)/ očitavanje stanja mreže .
- Objavljivanje transakcija (pozivanje na funkcije pametnog ugovora koje mijenjaju državu poput prijenosa tokena).
Provedba obje ove točke prilično je nezgodna, pogotovo ako želimo izgraditi sigurno i pouzdano pozadinsko rješenje. Evo glavnih točaka koje ćemo razbiti u nastavku:
- Prije svega, u Ethereumu pronalaženje događaja nije spremno za proizvodnju. Iz više razloga: mrežni čvorovi mogu zakazati tijekom dohvaćanja velikog broja događaja, događaji mogu nestati ili se promijeniti zbog mrežnih račvanja itd. Moramo izgraditi apstraktni sloj za sinkronizaciju događaja iz mreže i zajamčiti njihovu pouzdanu isporuku.
- Isto za objavljivanje transakcija, moramo apstrahirati Ethereumove niske razine poput brojača bez broja i procjene plina, kao i ponovno objavljivanje transakcija, pružajući pouzdano i stabilno sučelje. Štoviše, objavljivanje transakcija podrazumijeva upotrebu privatnih ključeva, što zahtijeva naprednu pozadinsku sigurnost.
- Sigurnost. Shvatit ćemo to ozbiljno i suočiti se s tim da je nemoguće garantirati da privatni ključevi nikada neće biti ugroženi na pozadini. Srećom, postoji pristup dizajniranju decentralizirane aplikacije bez potrebe za visokim osiguranjem pozadinskih računa.
U našoj praksi sve nas je to natjeralo da stvorimo robusno pozadinsko rješenje za Ethereum kojega nazivamo Ethereum Gateway . Apstrahira druge mikroservise iz zabave Ethereuma i pruža pouzdan API za rad s njim.
Kao brzorastući startup, iz očiglednih razloga ne možemo otkriti cjelovito rješenje (još uvijek), ali podijelit ću sve što trebate znati kako bi vaša decentralizirana aplikacija funkcionirala besprijekorno. Međutim, ako imate bilo kakvih konkretnih pitanja ili upita, slobodno me kontaktirajte. I komentari na ovaj članak su vrlo zahvalni!
Arhitektura decentraliziranih aplikacija
Ovaj dio članka u velikoj mjeri ovisi o potrebama određene decentralizirane aplikacije, ali pokušat ćemo riješiti neke osnovne obrasce interakcije povrh kojih su te aplikacije izgrađene (ÐPlatform = Decentralizirana platforma = Ethereum / EOS / Tron / Whatever):
Klijent Ð ÐPlatform : potpuno decentralizirane aplikacije .
Klijent (preglednik ili mobilna aplikacija) razgovara s decentraliziranom platformom izravno uz pomoć Ethereum softvera "novčanika" poput Metamaske, Trusta ili hardverskih novčanika poput Trezora ili Ledgera. Primjeri DApps-a izgrađenih na takav način su CryptoKitties, Loomov delegirani poziv, sami kripto novčanici (Metamask, Trust, Tron Wallet, drugi), decentralizirane kripto razmjene poput Etherdelte i tako dalje.
ÐPlatform ⬌ Klijent ⬌ Back End ⬌ ÐPlatform : centralizirane ili polucentralizirane aplikacije .
Interakcija klijenta s decentraliziranom platformom i poslužiteljem ima malo zajedničkog. Dobar primjer za to je bilo koja ( centralizirana ) kripto razmjena danas, poput BitFinexa ili Poloniexa: valute kojima trgujete na burzama jednostavno se bilježe u tradicionalnoj bazi podataka. Saldo baze podataka možete "nadopuniti" slanjem sredstava na određenu adresu (ÐPlatform ⬌ Klijent), a zatim povući sredstva nakon nekih radnji u aplikaciji (Back End ⬌ ÐPlatform), međutim, sve što radite u smislu "ÐApp" sam (Klijent ⬌ Back End) ne podrazumijeva vašu izravnu interakciju s ÐPlatformom.
Drugi primjer je Etherscan.io, koji koristi polu-centralizirana pristup: možete učiniti sve korisne decentralizirane akcije tamo, ali sama aplikacija jednostavno nema smisla bez njihovog sveobuhvatnog stražnjem kraju (Etherscan kontinuirano sinkronizira transakcija, analizira podatke i pohranjuje ga, u konačnici pružajući sveobuhvatan API / UI).
Nešto između: mirne, centralizirane ili polucentralizirane aplikacije .
Gore navedeni pristupi kombinirani. Na primjer, možemo imati aplikaciju koja pruža razne usluge u zamjenu za kripto, što vam omogućuje da se prijavite i potpišete podatke svojim kripto identitetom.
Nadamo se da obrazac interakcije potpuno decentraliziranih aplikacija (klijent P ÐPlatform) ne nameće nikakva pitanja. Oslanjanjem na tako nevjerojatne usluge kao što su Infura ili Trongrid, jednostavno se može izraditi aplikacija za koju uopće nije potreban poslužitelj. Gotovo sve knjižnice na strani klijenta, poput Ethers.js za Ethereum ili Tron-Web za Tron, mogu se povezati s tim javnim uslugama i komunicirati s mrežom. Međutim, za složenije upite i zadatke možda ćete ionako trebati dodijeliti vlastiti poslužitelj.
Ostali obrasci interakcije koji uključuju pozadinu čine stvari zanimljivijima i složenijima. Da bismo sve to stavili u sliku, zamislimo slučaj kada naš zadnji kraj reagira na neki događaj u mreži. Na primjer, korisnik objavljuje transakciju odobrenja koja nam daje dopuštenje da ih naplaćujemo. Da bismo izvršili naplatu, moramo objaviti transakciju naplate kao odgovor na emitirani dodatak:
Sa stražnje krajnje točke gledišta evo što se događa:
- Slušamo određeni mrežni događaj kontinuiranim anketiranjem mreže.
- Nakon što dobijemo događaj, izvodimo neku poslovnu logiku, a zatim odlučujemo objaviti transakciju kao odgovor.
- Prije objavljivanja transakcije želimo osigurati da će vjerojatno biti iskopana (u Ethereumu uspješna procjena plina za transakciju znači da nema pogrešaka u odnosu na trenutno stanje mreže ). Međutim, ne možemo jamčiti da će transakcija biti uspješno minirana .
- Koristeći privatni ključ, potpisujemo i objavljujemo transakciju. U Ethereumu također moramo odrediti cijenu i ograničenje plina za transakciju.
- Nakon objavljivanja transakcije kontinuirano anketiramo mrežu radi utvrđivanja njezina statusa.
- Ako traje predugo i ne možemo dobiti status transakcije, moramo je ponovno objaviti ili pokrenuti „scenarij neuspjeha“. Transakcije se mogu izgubiti iz različitih razloga: zagušenja mreže, padajućih partnera, povećanja opterećenja mreže itd. U Ethereumu također možete razmotriti ponovno potpisivanje transakcije s drugom (stvarnom) cijenom plina.
- Nakon što napokon miniramo transakciju, možemo izvesti više poslovne logike ako je potrebno. Na primjer, možemo obavijestiti druge pozadinske usluge o činjenici da je transakcija dovršena. Također, razmislite o čekanju nekoliko potvrda prije donošenja konačnih odluka u vezi s transakcijom: mreža se distribuira i stoga se rezultat može promijeniti u nekoliko sekundi.
Kao što vidite, događa se puno! Međutim, vaša aplikacija možda neće zahtijevati neke od ovih koraka, ovisno o tome što pokušavate postići. Ali, izgradnja robusne i stabilne pozadine zahtijeva rješenje svih gore spomenutih problema. Razdvojimo ovo.
Decentralizirane aplikacije Natrag
Ovdje želim istaknuti neke točke koje nameću većinu pitanja, a to su:
- Slušanje mrežnih događaja i čitanje podataka s mreže
- Objavljivanje transakcija i kako to učiniti sigurno
Slušanje mrežnih događaja
U Ethereumu, kao i u drugim decentraliziranim mrežama, koncept događaja pametnih ugovora (ili zapisnici događaja ili samo zapisnici) omogućuje izvanlančanim aplikacijama da budu svjesni što se događa u blockchainu. Te događaje mogu stvoriti programeri pametnih ugovora u bilo kojoj točki koda pametnog ugovora.
Na primjer, unutar dobro poznatog standarda ERC20 tokena, svaki prijenos tokena mora prijaviti događaj Prijenos, na taj način dajući izvanlančanim aplikacijama do znanja da se dogodio prijenos tokena. "Slušajući" ove događaje možemo izvršiti bilo kakve (ponovne) radnje. Na primjer, neki mobilni kripto-novčanici šalju vam obavijest push / e-poštom kada se tokeni prenose na vašu adresu.
Zapravo nema pouzdanog rješenja za preslušavanje mrežnih događaja izravno. Različite knjižnice omogućuju vam praćenje / preslušavanje događaja, međutim, postoje mnogi slučajevi kada nešto može poći po zlu, što rezultira izgubljenim ili neobrađenim događajima. Da bismo izbjegli gubitak događaja, moramo izraditi prilagođeni back end, koji će održavati postupak sinkronizacije događaja.
Ovisno o vašim potrebama, provedba može varirati. Ali da biste nas stavili na sliku ovdje je jedna od mogućnosti kako možete izgraditi pouzdanu isporuku Ethereum događaja u smislu arhitekture mikro usluga:
Te komponente djeluju na sljedeći način:
- Usluga sinkronizacije događaja na kraju neprestano anketira mrežu, pokušavajući dohvatiti nove događaje. Nakon što su dostupni neki novi događaji, šalje ih u sabirnicu poruka. Nakon uspješnog predavanja događaja na sabirnicu poruka, kao i za blockchain, možemo spremiti zadnji blok događaja kako bismo sljedeći put zatražili nove događaje iz ovog bloka. Imajte na umu da preuzimanje previše događaja odjednom može rezultirati uvijek neuspjelim zahtjevima, tako da morate ograničiti broj događaja / blokova koje zatražite od mreže.
- Sabirnica poruka (na primjer, Rabbit MQ) usmjerava događaj u svaki red koji je postavljen pojedinačno za svaku pozadinsku uslugu. Prije objavljivanja događaja, pozadinska usluga sinkronizacije događaja navodi ključ usmjeravanja (na primjer, adresa pametnog ugovora + tema događaja), dok potrošači (ostale pozadinske usluge) stvaraju redove koji su pretplaćeni samo za određene događaje.
Kao rezultat toga, svaka pozadinska usluga dobiva samo one događaje koji su joj potrebni. Štoviše, sabirnica poruka jamči isporuku svih događaja nakon što im se objave.
Naravno, umjesto sabirnice poruka možete koristiti nešto drugo: HTTP povratne pozive, utičnice itd. U ovom ćete slučaju sami morati shvatiti kako zajamčiti isporuku povratnih poziva: upravljati eksponencijalnim / prilagođenim ponovnim pokušajima povratnog poziva, implementirati prilagođeno praćenje i tako dalje.
Izdavačke transakcije
Postoji nekoliko koraka koje moramo obaviti kako bismo objavili transakciju u decentraliziranoj mreži:
- Priprema transakcije. Zajedno s podacima o transakcijama, ovaj korak podrazumijeva zahtjev za mrežnim stanjem kako bi se saznalo je li ta transakcija valjana i hoće li se minirati (procjena plina u Ethereumu) i sekvencijalni broj transakcije (nonce u Ethereumu). Neke knjižnice pokušavaju to učiniti ispod haube, međutim, ovi su koraci važni.
- Potpisivanje transakcije. Ovaj korak podrazumijeva upotrebu privatnog ključa. Najvjerojatnije, ovdje ćete htjeti ugraditi prilagođeno rješenje sklopa privatnog ključa (na primjer).
- Objavljivanje i ponovno objavljivanje transakcije. Jedna od ključnih točaka ovdje je da vaša objavljena transakcija uvijek ima priliku izgubiti se ili izbaciti iz decentralizirane mreže. Na primjer, u Ethereumu objavljena transakcija može pasti ako mrežna cijena plina naglo poraste. U tom slučaju morate ponovo objaviti transakciju. Štoviše, možda ćete htjeti ponovno objaviti transakciju s drugim parametrima (barem s višom cijenom plina) kako biste je što prije iskopali. Prema tome, ponovno objavljivanje transakcije može značiti njeno ponovno potpisivanje, ako zamjenska transakcija nije bila prethodno potpisana prije (s različitim parametrima).
Koristeći gornje pristupe možete na kraju izgraditi nešto slično onome što je prikazano na dijagramu nizova u nastavku. Na ovom određenom dijagramu sekvence demonstriram (općenito!) Kako funkcionira ponavljajuća naplata u blockchainu (u povezanom članku ima više):
- Korisnik izvršava funkciju u pametnom ugovoru, što u konačnici omogućuje stražnjem kraju da izvrši uspješnu transakciju naplate.
- Back end služba odgovorna za određeni zadatak preslušava slučaj naknade i objavljuje transakciju naplate.
- Jednom kada se transakcija naplate minira, ova pozadinska usluga odgovorna za određeni zadatak prima događaj iz mreže Ethereum i izvodi neku logiku (uključujući postavljanje sljedećeg datuma punjenja).
Sigurnost i pametni ugovori na kraju
Objavljivanje transakcija uvijek uključuje upotrebu privatnog ključa . Možda se pitate je li moguće zaštititi privatne ključeve. Pa, da i ne. Brojne su složene strategije i različite vrste softvera koji omogućuju sasvim sigurno pohranjivanje privatnih ključeva na stražnjoj strani. Neka rješenja za pohranu privatnih ključeva koriste geo-distribuirane baze podataka, dok druga čak predlažu upotrebu posebnog hardvera. Međutim, u svakom slučaju, najranjivija točka polucentralizirane aplikacije je mjesto na kojem se privatni ključ sastavlja i koristi za potpisivanje transakcije (ili, u slučaju posebnog hardvera, točka pokretanja postupka potpisivanja transakcije). Stoga teoretski ne postoji 100% pouzdano rješenje koje će omogućiti neprobojnu zaštitu od ugrožavanja pohranjenih privatnih ključeva.
Sada razmišljajte na ovaj način. U mnogim slučajevima ne trebate tako često osiguravati privatne ključeve na stražnjoj strani. Umjesto toga, pametne ugovore i cijelu aplikaciju možete dizajnirati na takav način da curenje privatnog ključa neće utjecati na njihovo uobičajeno ponašanje . Ovim pristupom nije važno kako autorizirani računi komuniciraju s pametnim ugovorom. Oni samo "pokreću" pametni ugovor da obavi svoj uobičajeni posao, a sam pametni ugovor izvršava sve potrebne provjere valjanosti. Ja to zovem "obrazac operativnih računa".
Na ovaj način, u slučaju nužde:
- Jedino što napadač može ukrasti je mala količina Etera (kao Ethereum) položena na operativne račune za objavljivanje transakcija
- Napadač neće moći naštetiti logici pametnog ugovora niti bilo kome tko je uključen u postupak
- Kompromitirani operativni računi mogu se brzo zamijeniti drugima, međutim, to zahtijeva ili ručnu zamjenu (generiranje novih računa i ponovnu autorizaciju računa u svim pametnim ugovorima) ili razvijanje dodatnog rješenja koje će učiniti svu čaroliju jednom transakcijom super -siguran (hardverski ili multi-sig) glavni račun.
Na primjer, u našoj ponovljenoj naplati za rješenje Ethereum, bez obzira što se događa na pozadini, pametni ugovor s ponovljenom naplatom osmišljen je na takav način da imamo cijeli mjesec vremena za zamjenu ugroženih računa ako je bilo koji od njih ugrožen .
No, ipak, ako želite osigurati što sigurniju pohranu privatnog ključa, pokušajte upotrijebiti Vault s izvrsnim dodatkom za Ethereum koji pohranjuje i upravlja Ethereum računima (također, pripazite na naše module otvorenog koda - mi uskoro izdaju nešto slično). Ovdje neću zalaziti duboko u detalje, iako možete posjetiti povezane projekte i sami naučiti odatle.
To nije ni sve što moram reći. Međutim, pokazalo se da je ovaj članak mnogo duži nego što sam očekivao pa moram prestati. Pretplatite se na moj Medium / druge mreže ako vas zanima softver, kripto, savjeti za putovanja ili samo želite slijediti nešto zanimljivo. Nadam se da sam pružio veliku vrijednu informaciju i da će vam biti korisni. Slobodno komentirajte i širite ovaj članak!