Decentralizirana arhitektura aplikacija: obrasci stražnjeg dijela, zaštita i dizajn

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 back end i pametne ugovore za decentralizirane aplikacije, uzimajući Ethereum kao primarni primjer, premda će se veliki dio primjenjivati ​​na EOS, Tron i ostale decentralizirane platforme podataka.

Članci u tekstu:

  • Kako pohraniti privatne ključeve na stražnjem kraju bez brige o sigurnosti
  • Kako pravilno dizajnirati pametne ugovore i što „decentralizirati“
  • Primjeri decentralizirane i polucentralizirane arhitekture aplikacija
  • Kako se nositi s stvarima niske razine poput opterećenja i kvarova na mreži

Bit će velika, hajde da učinimo!

Decentralizirani programi i Blockchain

Unatoč činjenici da se blockchain danas suočava s mnogim poteškoćama u donošenju i reguliranju, to je vrsta tehnologije koja ostaje ovdje, bilo da je u pitanju blockchain, hashgraph, tempo ili bilo koja druga tehnologija distribuirane knjige, koja dolazi, bez obzira na algoritam.

Glavna vrijednost koju blockchain i druge slične tehnologije donose mogu se generalizirati na sljedeći način: omogućavaju ljudima pisanje i pokretanje programa koji se, praktično, ne mogu mijenjati nakon kreiranja niti se mijenjaju tijekom izvođenja. Drugim riječima, ti se programi uvijek izvode kako su zamišljeni, a niti jedna stranka ne može utjecati na njihovo ponašanje.

Ova definicija vrijedi za mnoge kripto valute koje postoje danas ako ih smatramo programima koji definiraju kako se kovanice mogu prenositi naprijed i nazad. To također objašnjava zašto kripto valute i mnoge vrste tokena imaju stvarnu vrijednost: ne mogu se generirati iz zraka, pomoću njihovih definiranih "temeljnih programa".

Platforme Ethereum / EOS / Tron /…, za razliku od Bitcoina, implementiraju složeniji programski sloj, koji zauzvrat implementira okruženje izvršenja omogućujući svakome da napiše svoje decentralizirane programe na vrh platforme. Ovi programi definirani od strane korisnika uvijek se izvode kako su dizajnirani, 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 su ono što danas nazivamo decentraliziranim aplikacijama (ÐApps). Kroz neke od njih mogu se polucentralizirati, glavni dio aktivnosti u zaista decentraliziranoj aplikaciji trebao bi se odvijati izvan kontrole središnje stranke.

Da me netko pitao da nacrtam kako rade DApps danas, to bih vjerojatno nacrtao

Da biste zamislili kako danas nazivamo decentralizirane aplikacije, 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 resurs web / mobilne mreže.

To vam pruža Softver za novčanike. Privatni ključ ovog identiteta (tajna, vlasništvo koje možete raditi u ime tog identiteta) pohranjuje se na vašem lokalnom uređaju i nikada ne ulazi u mrežu, zbog čega nitko ne može kontrolirati taj identitet osim vas. Pomoću ovog identiteta možete izvoditi različite akcije i u centraliziranim (web resurs koji kontrolira središnje tijelo) i u decentraliziranim (što je različita mreža od tradicionalnog www, čiji je cilj eliminacija središnje vlasti), koristeći web mjesto kao pristupna točka i / ili kao grafičko korisničko sučelje. Čitav smisao ovog "kripto identiteta" jest u tome što su vaši postupci kriptografski osigurani i nitko ne može promijeniti ono što ste potpisali niti svoj potpis.

Danas su mogućnosti proračuna i skladištenja decentraliziranih mreža otpornih na greške poput Ethereuma, EOS-a ili Trona ograničene. Ako su skalabilni, mogli bismo koristiti decentralizirane mreže za spremanje cijele decentralizirane aplikacije, uključujući njeno grafičko korisničko sučelje, podatke i poslovnu logiku. U ovom slučaju bismo ove aplikacije nazvali doista decentraliziranim / distribuiranim.

Međutim, budući da te mreže danas nisu skalabilne, kombiniramo različite pristupe kako bismo postigli maksimalnu razinu decentralizacije za naše aplikacije. "Tradicionalni" krajnji dio za koji znamo da ne ide nikuda. Na primjer:

  • Za decentraliziranu aplikaciju koristimo stražnji kraj da ugostimo prednji kraj.
  • Koristimo back end za integraciju s bilo kojim drugim postojećim tehnologijama i uslugama. Prave aplikacije svjetske klase ne mogu živjeti u izoliranom okruženju.
  • Povratni kraj koristimo za spremanje i obradu svega dovoljno velikog za decentraliziranu mrežu (posebno blockchain). Praktično se cijela aplikacija i njena poslovna logika pohranjuju negdje u svijetu, isključujući samo blockchain dio. Da i ne spominjemo, IPFS i slični slojevi za pohranu ne mogu jamčiti dostupnost datoteka, stoga se i mi ne možemo pouzdati bez da ih sami ugostimo. Drugim riječima, uvijek postoji potreba za posvećenim pokrenutim poslužiteljem.

Nema načina za izgradnju sigurne i djelomično decentralizirane aplikacije bez korištenja čvrste stražnje strane od današnjeg dana, a smisao ovog članka je objasniti kako to ispravno napraviti.

(De) centralizacija i tokeni

Događa se da su gotovo sve decentralizirane aplikacije danas izgrađene oko takozvanih tokena - kripto valuta po mjeri (ili jednostavno jednostavno kloniranih) koja pokreću određenu decentraliziranu aplikaciju. Tokeni su jednostavno programirana valuta ili imovina, to je to.

Dok pametni ugovori s tokenom određuju kako korisnici mogu prenijeti tokene, pametni aplikacije mogu produljiti sve što nedostaje u pametnim ugovorima s tokenom. Oba pametna ugovora vrše se na vrhu decentraliziranih mreža

Token je obično "pametni ugovor" (prilagođeni program) napisan preko decentralizirane platforme poput Ethereuma. Posjedovanjem nekih tokena u osnovi ste u mogućnosti dobiti različite usluge na web resursu ili mobilnoj aplikaciji i trgovati ovaj token nečim drugim. Ključna je točka to što žeton živi sam i to ne kontrolira središnje tijelo.

Postoji mnogo primjera aplikacija koje se grade oko tokena: od brojnih kolekcionarskih igara poput CryptoKitties (ERC721 tokena) do više orijentiranih servisa kao što su LOOM Network ili čak preglednici poput Brave i igraćih platformi poput DreamTeam-a (ERC20-kompatibilnih tokena).

Programeri sami određuju i odlučuju koliki će nadzor imati (ili neće) nad svojim aplikacijama. Oni mogu graditi poslovnu logiku cijele aplikacije na temelju pametnih ugovora (kao što je to činio CryptoKitties) ili, pametnim ugovorima, uopšte ne mogu koristiti, centralizirajući sve na svojim poslužiteljima. Međutim, najbolji je pristup negdje u sredini.

Stražnji kraj za decentralizirane mreže

S tehničkog stajališta, mora postojati most koji povezuje žetone i ostale pametne ugovore s web / mobilnom aplikacijom.

U današnjim potpuno decentraliziranim aplikacijama, gdje klijenti izravno komuniciraju sa pametnim ugovorima, ovaj se most sužava na JSON RPC API mogućnosti javnih API-ja ili baze čvorova poput Infure, koji su zauzvrat prisiljeni da postoje zbog činjenice da ne mogu svi uređaji pokrenuti i podržavati njegov pojedinačni mrežni čvor. Međutim, ovaj API pruža samo osnovni i vrlo uski skup funkcija, koji jedva dopuštaju postavljanje jednostavnih upita niti učinkovito agregiranje podataka. Zbog toga, na kraju, počinje prilagođeni back end, što aplikaciju čini polucentraliziranom.

Cjelokupna interakcija s decentraliziranom mrežom može se smanjiti na samo jednu ili dvije točke, ovisno o potrebama aplikacije:

  1. Slušanje mrežnih događaja (poput prijenosa tokena) / čitanje stanja mreže.
  2. Objavljivanje transakcija (pozivanje na funkcije pametnog ugovora koje mijenjaju državu poput prijenosa tokena).

Primjena obje ove točke prilično je škakljiva, posebno ako želimo izgraditi sigurno i pouzdano back-end rješenje. Ovdje su glavne točke koje ćemo u nastavku raščlaniti:

  • Prije svega, u Ethereumu pronalaženje događaja nije spremno za proizvodnju. Zbog više razloga: mrežni čvorovi mogu propasti tijekom preuzimanja velikog broja događaja, događaji mogu nestati ili se promijeniti zbog mrežnih vilica itd. Moramo izgraditi sloj apstrakcije za sinkronizaciju događaja iz mreže i jamčiti njihovu pouzdanu isporuku.
  • Isto kao i za objavljivanje transakcija, moramo apstrahirati Ethereumove stvari na niskoj razini kao što su brojači i procjene potrošnje goriva, kao i ponovno objavljivanje transakcija, pružajući pouzdano i stabilno sučelje. Nadalje, objavljivanje transakcija podrazumijeva korištenje privatnih ključeva, što zahtijeva naprednu sigurnosnu zaštitu.
  • 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 stražnjoj strani. Srećom, postoji pristup dizajniranju decentralizirane aplikacije, bez čak i potrebe da se back-end računi visoko osiguraju.

U našoj praksi, sve ovo natjeralo nas je da stvorimo robusno back-end rješenje za Ethereum koje nazivamo Ethereum Gateway. Održava druge mikroservise iz zabave Ethereuma i pruža pouzdan API za rad s njim.

Kao brzorastući startup ne možemo otkriti cjelovito rješenje (samo još) iz očitih razloga, ali podijelit ću sve što trebate znati kako bi vaša decentralizirana aplikacija funkcionirala besprijekorno. Ako imate bilo kakvih konkretnih pitanja ili upita, slobodno me kontaktirajte. Komentari na ovaj članak također su vrlo cijenjeni!

Back End Monitoring za Ethereum. Monitor demonstrira aktivnosti uglavnom u vezi s našom značajkom naplate (iako možete vidjeti vrhove svakog sata).

Decentralizirana arhitektura aplikacija

Ovaj dio članka uvelike ovisi o potrebama određene decentralizirane aplikacije, ali pokušat ćemo razvrstati neke osnovne obrasce interakcije na čijim se površinama ugrađuju ove aplikacije (ÐPlatform = Decentralizirana platforma = Ethereum / EOS / Tron / god.):

Klijent P ÐPlatform: potpuno decentralizirane aplikacije.

Klijent (preglednik ili mobilna aplikacija) izravno razgovara s decentraliziranom platformom pomoću Ethereumovog „novčanika“ softvera poput Metamask, Trust ili hardverskih novčanika poput Trezor ili Ledger. Primjeri izrade DApps-a na takav način su CryptoKitties, Loomov delegirani poziv, sami kripto novčanici (Metamask, Trust, Tron Wallet, drugi), decentralizirane kripto razmjene poput Etherdelta 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) razmjena kriptovaluta danas, poput BitFinexa ili Poloniexa: valute kojima trgujete na razmjeni jednostavno se bilježe u tradicionalnoj bazi podataka. Stanje baze podataka možete „nadopuniti“ slanjem imovine na određenu adresu (ÐPlatform ⬌ klijent), a zatim povući imovinu nakon nekih radnji u aplikaciji (Back End ⬌ ÐPlatform), međutim, sve što napravite u vezi s „ÐApp“ Sam (klijent ⬌ Back End) ne podrazumijeva vašu izravnu interakciju s ÐPlatformom.

Drugi primjer je Etherscan.io, koji koristi polucentralizirani pristup: tamo možete raditi sve korisne decentralizirane radnje, ali sama aplikacija jednostavno nema smisla bez njihovog sveobuhvatnog stražnjeg dijela (Etherscan kontinuirano sinkronizira transakcije, analizira podatke i pohranjuje ih, u konačnici pruža sveobuhvatni API / korisničko sučelje).

Nešto između: još uvijek, centralizirane ili polucentralizirane aplikacije.

Gore navedeni pristupi kombinirani. Na primjer, možemo imati aplikaciju koja pruža različite usluge u zamjenu za kriptovalute, omogućavajući vam prijavu i potpisivanje podataka sa svojim kripto identitetom.

Nadamo se da obrazac interakcije potpuno decentraliziranih aplikacija (klijent ⬌ ÐPlatform) ne postavlja pitanja. Oslanjajući se na nevjerojatne usluge poput Infura ili Trongrid, jednostavno možete napraviti aplikaciju za koju uopće nije potreban poslužitelj. Gotovo sve biblioteke na strani klijenta poput Ethers.js za Ethereum ili Tron-Web for Tron mogu se povezati s tim javnim servisima i komunicirati s mrežom. Međutim, za složenije upite i zadatke možda ćete možda morati dodijeliti vlastiti poslužitelj.

Ostali obrasci interakcije koji uključuju i krajnje stvari čine stvari zanimljivijim i složenijim. Da bismo sve to stavili u sliku, zamislimo slučaj gdje naš stražnji dio reagira na neki događaj u mreži. Na primjer, korisnik objavljuje transakciju naknada koja nam daje dozvolu za naplatu. Da bismo izvršili naplatu, moramo objaviti transakciju naplate kao odgovor na događaj emisije emisijskih jedinica:

Primjer reakcije poslužitelja na korisnikovu radnju u decentraliziranoj mreži

S zadnjeg krajnjeg stajališta, evo što se događa:

  1. Slušamo određeni mrežni događaj neprestano pretražujući mrežu.
  2. Jednom kada se dogodi događaj, izvodimo neku poslovnu logiku i nakon toga odlučimo objaviti transakciju.
  3. Prije objave transakcije želimo osigurati da se ona vjerojatno minira (u Ethereumu, uspješna procjena plina transakcije znači da nema grešaka u odnosu na trenutno stanje mreže). Međutim, ne možemo jamčiti da će transakcija biti uspješno minirana.
  4. Privatnim ključem potpisujemo i objavljujemo transakciju. U Ethereumu također moramo odrediti cijenu plina i ograničenje plina u transakciji.
  5. Nakon objavljivanja transakcije, kontinuirano vršimo anketu putem mreže.
  6. Ako traje predugo i ne možemo dobiti status transakcije, morat ćemo je ponovo objaviti ili pokrenuti "neuspjeli scenarij". Transakcije se mogu izgubiti iz različitih razloga: zagušenja mreže, pada vršnjaka, povećanja mrežnog opterećenja itd. U Ethereumu također možete razmotriti ponovni potpisivanje transakcije s drugačijom (stvarnom) cijenom plina.
  7. Nakon što konačno izvučemo svoju transakciju, po potrebi možemo izvesti više poslovne logike. Na primjer, možemo obavijestiti ostale back-end usluge o činjenici da je transakcija zaključ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, puno se toga događa! Međutim, vaš zahtjev možda neće zahtijevati neke od ovih koraka, ovisno o tome što pokušavate postići. No, izgradnja stabilnog i stabilnog stražnjeg dijela zahtijeva rješenje za sve gore navedene probleme. Raščlanimo ovo

Strani kraj decentraliziranih aplikacija

Ovdje želim istaknuti neke točke koje postavljaju većinu pitanja, a to su:

  • Slušanje mrežnih događaja i čitanje podataka s mreže
  • Objavljivanje transakcija i kako to sigurno učiniti

Slušanje mrežnih događaja

U Ethereumu, kao i u ostalim decentraliziranim mrežama, koncept događaja pametnih ugovora (ili dnevnika događaja ili samo dnevnika) omogućava izvanprosječnim aplikacijama da budu svjesni što se događa u blockchainu. Te događaje mogu stvoriti programeri pametnih ugovora u bilo kojem trenutku koda pametnog ugovora.

Na primjer, unutar dobro poznatog standarda tokena ERC20 svaki prijenosni token mora zabilježiti događaj prijenosa, što znači da aplikacije izvan lanca znaju da se dogodio prijenos tokena. Slušajući ove događaje možemo izvoditi sve (ponovne) radnje. Na primjer, neki mobilni kripto-novčanici šalju vam push / e-mail obavijest kada se tokeni prebace na vašu adresu.

U stvari, ne postoji pouzdano rješenje za slušanje mrežnih događaja izvan okvira. Različite knjižnice omogućuju vam praćenje / slušanje 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 ne bismo izgubili događaje, moramo izraditi prilagođeni zadnji dio koji će održavati proces sinkronizacije događaja.

Ovisno o vašim potrebama, implementacija može varirati. Ali, da biste vas slikali ovdje jedna je od opcija kako možete izgraditi pouzdanu isporuku Ethereum događaja u smislu arhitekture mikroservisa:

Pouzdana isporuka Ethereum događanja za sve back end usluge

Te komponente djeluju na sljedeći način:

  1. Usluga sinkronizacije događaja na kraju konstantno anketira mrežu pokušavajući dohvatiti nove događaje. Kad su dostupni neki novi događaji, ona šalje te događaje u sabirnicu poruka. Nakon uspješnog slanja događaja na magistralnu poruku, što se tiče blockchaina, možemo spremiti blok posljednjeg događaja kako bismo sljedeći put zatražili nove događaje iz ovog bloka. Imajte na umu da preuzimanja previše događaja odjednom mogu rezultirati uvijek neuspjelim zahtjevima, tako da morate ograničiti broj događaja / blokova koje tražite od mreže.
  2. Sabirnica poruka (na primjer, Rabbit MQ) usmjerava događaj u svaki red koji je postavljen pojedinačno za svaku zadnju uslugu. Prije objavljivanja događaja usluga sinkronizacije događaja na kraju određuje ključ za usmjeravanje (na primjer, pametna adresa ugovora + tema događaja), dok potrošači (ostale back end usluge) stvaraju redove koji su pretplaćeni samo za određene događaje.

Kao rezultat, svaka pomoćna usluga dobiva samo one događaje koji su joj potrebni. Štoviše, voditelj poruke garantira isporuku svih događaja nakon što su objavljeni na njemu.

Naravno, možete koristiti nešto drugo umjesto sabirnice poruka: HTTP povratne poruke, utičnice itd. U ovom slučaju morat ćete sami smisliti kako zajamčiti isporuku povratnih poziva: upravljati eksponencijalnim / prilagođenim pokušajima povratnog poziva, implementirati prilagođeni nadzor i tako dalje.

Transakcije izdavanja

Moramo obaviti nekoliko koraka kako bismo objavili transakciju u decentraliziranoj mreži:

  1. Priprema transakcije. Uz podatke o transakcijama, ovaj korak podrazumijeva zatraženje stanja mreže kako bi se utvrdilo je li ta transakcija valjana i hoće li se minirati (procjena plina u Ethereumu) i redni broj transakcije (ne u Ethereumu). Neke biblioteke pokušavaju to učiniti pod kapom, međutim, ovi koraci su važni.
  2. Potpisivanje transakcije. Ovaj korak podrazumijeva upotrebu privatnog ključa. Najvjerojatnije, ovdje ćete htjeti ugraditi prilagođeno rješenje za sastavljanje privatnog ključa (na primjer).
  3. Objavljivanje i ponovno objavljivanje transakcije. Jedna od ključnih stvari ovdje je da objavljena transakcija uvijek ima priliku izgubiti se ili odustati od decentralizirane mreže. Na primjer, u Ethereumu, objavljena transakcija može biti odbačena ako cijena plina mreže naglo poraste. U tom slučaju morate ponovo objaviti transakciju. Nadalje, možda želite objaviti transakciju s drugim parametrima (barem s višom cijenom plina) kako biste je što prije minirali. Stoga ponovno objavljivanje transakcije može podrazumijevati ponovno potpisivanje ako zamjenska transakcija nije prethodno potpisana (s različitim parametrima).
Vizualno je prikazano gore navedeno u vezi s izdavanjem transakcija Ethereum

Korištenjem gore navedenih pristupa, možete završiti nešto slično onome što je prikazano u dijagramu niza. Na ovom posebnom dijagramu slijeda pokazujem (općenito!) Kako ponavljajući obračun blokade (postoji više u povezanom članku):

  1. Korisnik izvršava funkciju pametnim ugovorom, što u konačnici omogućuje pozadini da izvrši uspješnu transakciju naplate.
  2. Usluga rezervnog dijela odgovorna za određeni zadatak preslušava događaj naknade i objavljuje transakciju naplate.
  3. Nakon što se transakcija naplate minira, ova pomoćna usluga odgovorna za određeni zadatak prima događaj iz mreže Ethereuma i provodi određenu logiku (uključujući postavljanje sljedećeg datuma naplate).
Opći dijagram slijeda kako djeluje ponavljajuće obračunavanje blockchaina, demonstrirajući interakciju između back-end usluga i Ethereum mreže

Sigurnosni i pametni ugovori

Objavljivanje transakcija uvijek uključuje korištenje privatnog ključa. Možda se pitate je li moguće čuvati privatne ključeve. Pa, da i ne. Postoje brojne složene strategije i različite vrste softvera koji omogućuju pohranjivanje privatnih ključeva na stražnjoj strani prilično sigurno. Neka rješenja za pohranu privatnih ključeva koriste geo-distribuirane baze podataka, dok druge čak predlažu uporabu posebnog hardvera. Međutim, u svakom slučaju, najosjetljivija točka polucentralizirane aplikacije je tamo gdje se privatni ključ sastavlja i koristi za potpisivanje transakcije (ili, u slučaju posebnog hardvera, točka pokretanja postupka potpisivanja transakcije). Dakle, teoretski, ne postoji 100% pouzdano rješenje koje će omogućiti zaštitu od metaka od ugrožavanja pohranjenih privatnih ključeva.

Sad razmislite ovako. U mnogim slučajevima čak ne morate često učvrstiti privatne ključeve sa stražnje strane. Umjesto toga, pametne ugovore i cijelu aplikaciju možete osmisliti na način da curenje privatnog ključa neće utjecati na njihovo uobičajeno ponašanje. Uz ovaj pristup, nije važno na koji način ovlašteni računi komuniciraju sa pametnim ugovorom. Oni samo „pokreću“ pametni ugovor da radi svoj uobičajeni posao, a sam pametni ugovor provodi bilo koju potrebnu provjeru. Ja to nazivam „obrascem operativnih računa“.

Obrazac operativnih računa za decentralizirane aplikacije, gdje vam ne treba sigurnosna sigurnost za rezervne račune

Na ovaj način, u hitnim slučajevima:

  • Jedino što napadač može ukrasti je malena količina Etera (od Ethereuma) deponiranog 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 s drugim, no za to je potrebna ručna zamjena (generiranje novih računa i ponovno ovlaštenje računa u svim pametnim ugovorima) ili razvijanje dodatnog rješenja koje će s makro transakcijom učiniti super -osiguran (hardverski ili višestruki) glavni račun.

Na primjer, u našem ponavljajućem nalogu za Ethereum rješenje, bez obzira na ono što se događa na zadnjoj strani, ponavljajući pametni ugovor o naplati je dizajniran na takav način da imamo cijeli mjesec vremena za zamjenu kompromitiranih računa ako je bilo koji od njih ugrožen. ,

Ali ipak, ako želite što sigurnije pohraniti privatni ključ, pokušajte koristiti Vault s sjajnim dodatkom za Ethereum koji pohranjuje i upravlja Ethereum računima (također, pazite na naše module otvorenog koda - mi uskoro objavljuju nešto slično). Ovdje neću zaroniti duboko u detalje, iako sami možete posjetiti povezane projekte i od tamo učiti.

Ovo čak 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 moje srednje / druge mreže ako vas zanima softver, kriptovalute, savjeti za putovanja ili samo želite slijediti nešto zanimljivo. Nadam se da sam pružio veliki vrijedan podatak i smatrat ćete ga korisnim. Slobodno komentirajte i širite ovaj članak!