Blockchain ima raznolik niz slučajeva korištenja, od financija do decentraliziranog Interneta. Međutim, većina slučajeva uporabe blockchaina može se implementirati koristeći relativno malo uzoraka. Na primjer, Zbirka uzoraka za aplikacije temeljene na Blockchainu nudi popis od 15 uzoraka Blockchaina.
Sitnozrnati uzorci, kao što je gore opisano, korisni su. Međutim, za dizajn sustava potrebna je mnogo viša razina apstrakcija. Korisno je imati i grublje zrnaste makro uzorke, koje nazivamo arhitektonskim uzorcima. Ovaj post opisuje četiri takva arhitektonska uzorka.
Započnimo. Da bih opisao obrasce, poslužit ću se predloškom koji je opisala Aleksandra Tešanović u Što je uzorak?
Arhitektonski obrazac za IAM.
Kontekst: IAM okruženja uključuju mnoge korisnike i pružatelje usluga. IAM sustavi daju svakom korisniku račun i skup mogućnosti koje omogućuju korisnicima da odu do davatelja usluga, pokažu svoje vlasništvo nad računima i zatim primaju usluge na temelju njihovih mogućnosti.
Snage: Treba implementirati decentralizirano IAM okruženje u kojem jedan nevaljali korisnik ili malo korisnika ne može značajno utjecati na sustav.
Rješenje: Predloženi kandidat za obrazac koristi DID specifikaciju World Wide Web Consortium (W3C) i specifikaciju W3C provjerljivih zahtjeva na sljedeći način.
Pretpostavimo da Alice treba identitet (DID, što je jedinstveni identifikator). Kao što prikazuje slika za stvaranje novog DID-a, Alice stvara unos u blockchainu. Ovaj unos uključuje nasumično generirani identifikator, vezu do spremišta s njezinim podacima profila i hash podataka profila. Korisnički profil sadrži javni ključ i skup provjerljivih zahtjeva. Generirani slučajni identifikator sada postaje Alicein DID jer samo ona posjeduje privatni ključ koji odgovara javnom ključu.
Potvrdivi zahtjevi su tokeni za delegiranje potpisani od nadležnog tijela. Stvoritelj ih također bilježi u blockchain-u, zajedno s raspršenim potraživanjem, na način sličan DID-u.
Alice prije svega dolazi do provjerljivih zahtjeva odlaskom vlastima. Na primjer, odjel za osobnu registraciju ili ekvivalent odgovarajuće je tijelo za provjerljive tvrdnje o imenu, adresi i datumu rođenja. Pod pretpostavkom da vlasti izdaju provjerljive tvrdnje, Alice prvo pokazuje kako posjeduje DID koristi protokol izazov-odgovor-odgovor. Zatim podnosi zahtjeve za provjerljive zahtjeve za svoje atribute, koji mogu, na primjer, uključivati njezino ime, adresu, stupanj i datum rođenja. Da bi ažurirala svoje podatke o profilu, Alice će dodati novi unos u blockchain s novim hashom profila.
U protokolu izazov-odgovor, validator generira slučajno sjeme, šifrira ga pomoću Aliceinog javnog ključa, a zatim izaziva Alice da demonstrira da ima privatni ključ dešifriranjem šifriranog sjemena. Budući da Alice ima privatni ključ, ona mora biti vlasnica DID-a.
Drugi korisnik ili organizacija (autentifikator), Bob, koji želi identificirati Alice, prvo prima DID od Alice, čita sve unose koji se odnose na taj DID iz blockchaina, dohvaća podatke Aliceinog profila i provjerava ih. Bob može ponovno provjeriti identitet Alice (identifikacija) pomoću protokola challenge-response-protocol. Tada Bob može potvrditi provjerljive tvrdnje i biti uvjeren da su tvrdnje o Alice istinite.
Na ovaj arhitektonski obrazac možemo slojiti većinu slučajeva upotrebe IAM-a. Primjerice, kontrolu pristupa možemo postići izdavanjem provjerljivih zahtjeva za radnje koje želimo da korisnici izvrše ili prihvaćanjem samo korisnika koji imaju određena svojstva (npr. Dob, opis posla, članstvo u grupi) u svojim provjerljivim zahtjevima. Implementacija može odabrati predmemoriranje relevantnih podskupova podataka profila u bazu podataka radi poboljšanja izvedbe.
Arhitektonski obrazac za provjerljivu povijest ili radni prostor
Kontekst: Dvije ili više strana obavljaju transakcije ili rade zajedno, a njihove aktivnosti moraju biti evidentirane na nesporan način.
Snage: Treba implementirati decentralizirani dnevnik revizije ili radni prostor u kojem jedan nevaljali korisnik ili malo korisnika ne može značajno utjecati na sustav.
Rješenje: Predloženi sustav bilježi aktivnosti i stvara unose u blockchainu za te zapise. Unos sadrži raspršenu evidenciju aktivnosti, stoga se zapisi ne mogu kasnije osporavati.
Na primjer, pretpostavimo da Alice želi platiti porez. Porezni poslužitelj prihvaća zahtjev za plaćanje, stvara digitalnu potvrdu, bilježi svoj hash u blockchain i šalje potvrdu Alice. Alice može potvrditi primitak izračunavanjem hasha i provjerom vrijednosti pohranjene u blockchainu. Nakon toga, Bob ne može odbiti primitak, jer se hash i vrijeme primitka bilježe u blockchainu.
Ako su aktivnosti brojne, možda će trebati zaobići ograničenja izvedbe blockchaina. Stoga neke implementacije mogu snimiti raspršivanje nekoliko zapisa aktivnosti kao blok umjesto jednog zapisa aktivnosti.
Arhitektonski obrazac za registar ili tržište
Kontekst: Registar je skup unosa podataka koji se mogu pretraživati i dohvatiti putem mreže. Tržište je registar koji korisnicima omogućuje kupnju usluga ili proizvoda predstavljenih unosima podataka. Na primjer, registar može biti katalog dostupnih API-ja.
Snage: Treba implementirati decentralizirano okruženje u kojem jedan nevaljali korisnik ili malo korisnika ne može značajno utjecati na sustav.
Rješenje: Predloženi obrazac djeluje na sljedeći način.
Prvo razmotrimo registar. Uz predloženu arhitekturu, kada korisnik izda ažuriranje registra (za dodavanje ili izmjenu unosa), klijent bilježi promjenu u blockchainu. Ako su podaci u ažuriranju veliki, zapis blockchaina može sadržavati vezu do podataka i hash vrijednost podataka. Ako podatke koji su pohranjeni u registru treba izmijeniti, klijent registra dodaje novi zapis u blockchain s izmijenjenim informacijama.
U gornjem dijagramu svaki korisnik ima klijenta registra koji radi na lokalnom računalu (npr. Prijenosnom računalu ili telefonu). Svaki klijent registra čita zapise ažuriranja iz blockchaina, provjerava podatke ažuriranja prema hashu uključenom u zapise i rekonstruira najnoviji prikaz zapisa iz ažuriranja. Na primjer, čitanjem blokchain zapisa o API-ima, njihovim dodavanjima, izmjenama i uklanjanjima, klijent registra može stvoriti prikaz koji prikazuje trenutne API-je uključene u registar. Da ne bi morali čitati i provjeravati sve zapise svaki put kada se koristi registar, klijenti mogu podatke pohraniti u bazu podataka i indeksirati. Klijent bi trebao povremeno provjeravati blockchain i ažurirati registar.
Blockchain dobro funkcionira kao "tržište usluga", jer se ista usluga može prodati više puta. Međutim, zbog ograničenja izvedbe, tržišta temeljena na blockchainu nisu prikladna za predmete koji se mogu prodati samo jednom.
Da ilustriramo, funkcionalnost registra temeljenog na blockchainu, pogledajmo kada se Alice želi pretplatiti na "vremensku uslugu vijesti" na tržištu blockchaina. Kad preda zahtjev, registar stvara vjerodajnice za uslugu i dijeli ih s Alice. Plaćanje se može dogoditi na jedan od nekoliko načina: korištenjem Bitcoina, putem pametnog ugovora gdje se plaćanja vrše pravodobno ili na neki drugi način.
Arhitektonski obrazac za pametne ugovore i upravljane stvari
Prema ovom uzorku razmatramo dva slučaja. Prvo razmatramo pametne ugovore, a kao drugo razmatramo uobičajeni poseban slučaj pametnih ugovora: "Upravljane stvari".
Uzorak pametnih ugovora
Kontekst: Više korisnika želi se pridržavati ugovora, opisanog kao izvršni program. Ugovor prolazi kroz državne prijelaze prema uvjetima definiranim u ugovoru i u određeno se vrijeme svatko može dogovoriti o trenutnom statusu ugovora.
Snage: treba implementirati okruženje u kojem jedan nevaljali korisnik ili malo korisnika ne može značajno utjecati na sustav.
Rješenje: Pametni kontakti dio su blockchain tehnologija i podržani implementacijama blockchaina, poput Ethereuma. Ugovor je opisan na jeziku pametnog ugovora i distribuiran svim sudionicima. Kako se uvjeti definirani u ugovoru mijenjaju, svaki sudionik izvršava ugovor i bilježi trenutni status u blockchainu koristeći algoritam konsenzusa.
Uzorak upravljanih stvari
Kontekst: Moramo pratiti vlasništvo nad stvarnim pametnim stvarima. Ovdje su pametne stvari objekti iz stvarnog svijeta koji u sebi mogu pokretati računalnu logiku. Vlasniku je dopušteno kontrolirati i izvoditi radnje na stvarima iz stvarnog svijeta. Također, vlasnik može svoje vlasništvo prenijeti na nekoga drugog.
Snage: treba implementirati okruženje u kojem jedan nevaljali korisnik ili malo korisnika ne može značajno utjecati na sustav.
Rješenje: Slijedi opis provedbe uzorka koristeći Car kao primjer kao upravljanu stvar.
Blokchain za upravljanu stvar, u ovom slučaju automobil, možemo implementirati u dva koraka. Prvo, proizvođač bilježi DID i javni ključ vlasnika automobila. Kada se promijeni vlasništvo, vlasnik dodaje novi zapis u blockchain navodeći novog vlasnika. Drugo, prilikom provjere vlasništva, automobil prvo preuzima sve zapise u blockchainu i provjerava je li svaki zapis tada dodao vlasnik. To se postiže provjerom javnog ključa korisnika koji je zapisao zapis s javnim ključem uključenim u prethodnu evidenciju vlasništva. Posljednji vlasnik u ovom važećem lancu je trenutni vlasnik.
Nakon što je odredio vlasnika, automobil se prijavljuje u trenutnu vlasnicu Alice, dohvaćajući njezin javni ključ i izvršavajući prijavu zasnovanu na izazovu i odgovoru s Aliceinim telefonom koji ima Alicein privatni ključ.
Takav sustav smanjuje rizike povezane s daljinski upravljanim artefaktima. Na primjer, u implementaciji koja nije blockchain, netko s pristupom može promijeniti vlasništvo vašeg automobila. Međutim, s modelom temeljenim na blockchainu, da bi daljinski upravljao automobilom, potencijalni napadač mora promijeniti evidenciju vlasništva u blockchainu, što je vrlo teško postići bez da je vlasnik.
Međutim, teško je spriječiti nekoga tko ima pristup "stvari" da fizički promijeni logiku koja se izvodi (npr. Zamjenom firmvera automobila). Jedno rješenje ovog problema je izgradnja nekog oblika samouništenja koji se aktivira kada se otkrije neovlašteno miješanje u artefakt.
Na primjer, Alice kupuje automobil od Boba pomoću pametnog ugovora koji plaća Bobu i ažurira vlasništvo nad vozilom. Nakon transakcije, Alice odlazi do automobila, koji s telefona čita Alicein DID, dohvaća njezin javni ključ, ovjerava je pomoću protokola challenge-response komunicirajući s telefonom koji ima Alicein privatni ključ, potvrđuje njezino vlasništvo i otključava automobil.
Zaključak
Razgovarali smo o četiri uzorka arhitekture temeljenih na blockchainu. GitHub dokument, Blockchain-based Integration Use Case, prikazuje ove obrasce na djelu, opisujući kako se mogu primijeniti 30 i više slučajeva uporabe blockchaina pomoću ova četiri uzorka.
Ako imate mišljenja o gornjim uzorcima ili znate o drugim uzorcima, stvarno bih volio čuti o njima.
Nadam se da je ovo bilo korisno. Ako vam se ovo sviđa, možda će vam se svidjeti i detaljna blockchain analiza u našem nedavno objavljenom radu "Anketa usmjerena na primjenu Blockchaina: status quo i buduće upute."