Четири кандидата за архитектурни образац за децентрализоване апликације засноване на Блоцкцхаин-у

Блоцкцхаин има разноврстан низ случајева коришћења, од финансија до децентрализованог Интернета. Међутим, већина случајева употребе блоцкцхаин-а може се применити користећи релативно мало образаца. На пример, Збирка узорака за апликације засноване на Блоцкцхаин-у пружа листу од 15 Блоцкцхаин образаца.

Финозрнати обрасци, као што је горе описано, су корисни. Међутим, за дизајн система потребан је много виши ниво апстракција. Корисно је имати и грубље зрнасте макро обрасце, које називамо архитектонским обрасцима. Овај пост описује четири таква архитектонска обрасца.

Хајде да почнемо. Да бих описао обрасце, послужићу се предлошком који је описала Александра Тешановић у делу Шта је образац?

Архитектонски образац за ИАМ.

Контекст: ИАМ окружења укључују много корисника и добављача услуга. ИАМ системи дају сваком кориснику рачун и скуп могућности које омогућавају корисницима да оду код добављача услуга, покажу своје власништво над рачунима и затим примају услуге на основу њихових могућности.

Снаге: Потребно је применити децентрализовано ИАМ окружење у којем један неваљали корисник или мало корисника не може значајно утицати на систем.

Решење: Предложени кандидат за образац користи ДИД спецификацију Ворлд Виде Веб Цонсортиум (В3Ц) и спецификацију захтева за потврду В3Ц на следећи начин.

Претпоставимо да Алице треба идентитет (ДИД, који је јединствени идентификатор). Као што приказује слика за креирање новог ДИД-а, Алице креира унос у блок ланцу. Овај унос укључује насумично генерисани идентификатор, везу до спремишта са њеним подацима профила и хеш података профила. Кориснички профил садржи јавни кључ и скуп проверивих захтева. Генерисани случајни идентификатор сада постаје Алицеин ДИД, јер само она поседује приватни кључ који одговара јавном кључу.

Потврдиви захтеви су токени за делегирање потписани од надлежног органа. Творац их такође снима у блок ланцу заједно са хешом полагања права на начин сличан ДИД-у.

Алице прво може добити провериве тврдње одласком властима. На пример, одељење за личну регистрацију или еквивалентно тело надлежно је за провериве тврдње о имену, адреси и датуму рођења. Под претпоставком да власти издају провериве тврдње, Алице прво доказује своје власништво над ДИД-ом, користећи протокол изазов-одговор. Затим подноси захтеве за провериве захтеве за своје атрибуте, који могу, на пример, да укључују њено име, адресу, степен и датум рођења. Да би ажурирала своје податке о профилу, Алице ће додати нови унос у блоцкцхаин са новим хешем профила.

У протоколу изазов-одговор, валидатор генерише насумично семе, шифрише га помоћу Алицеиног јавног кључа, а затим изазива Алице да демонстрира да има приватни кључ дешифровањем шифрованог семена. Пошто Алице има приватни кључ, она мора бити власник ДИД-а.

Други корисник или организација (аутентификатор), Боб, који жели да идентификује Алице, прво добија ДИД од Алице, чита све уносе који се односе на тај ДИД из блок ланца, преузима податке Алицеовог профила и верификује их. Боб може поново да провери идентитет Алице (идентификација) користећи протокол изазов-одговор-одговор. Тада Боб може потврдити провериве тврдње и бити уверен да су тврдње о Алице истините.

Већину ИАМ случајева употребе можемо слојити на врх овог архитектонског узорка. На пример, контролу приступа можемо постићи издавањем проверљивих захтева за радње које желимо да корисници изврше или прихватањем само корисника који имају одређена својства (нпр. Старост, опис посла, чланство у групи) у својим проверљивим захтевима. Имплементација може одабрати да кешира релевантне подскупове података профила у бази података ради побољшања перформанси.

Архитектонски образац за историју која се може ревидирати или радни простор

Контекст: Две или више страна заједно обављају трансакције или радове и њихове активности треба евидентирати на неспоран начин.

Снаге: Потребно је применити децентрализовани дневник ревизије или радни простор у којем један неваљали корисник или мало корисника не може значајно утицати на систем.

Решење: Предложени систем бележи активности и креира уносе у блок ланцу за те записе. Унос садржи хеш записе активности, па стога записи не могу бити спорни касније.

На пример, претпоставимо да Алице жели да плати порез. Порески сервер прихвата апликацију за плаћање, креира дигиталну признаницу, бележи свој хеш у блок ланцу и шаље потврду Алице. Алице може да потврди пријем израчунавањем хеша и провером вредности сачуване у блок ланцу. После овога, Боб не може да одбије пријем, јер се хеш и време рачуна рачуна бележе у блок ланцу.

Ако су активности бројне, можда ће бити потребно заобићи ограничења перформанси блок ланца. Због тога неке примене могу снимити хеш од неколико записа активности као блок уместо једног записа активности.

Архитектонски образац за регистар или тржиште

Контекст: Регистар је колекција уноса података који се могу претраживати и дохватити преко мреже. Тржиште је регистар који омогућава корисницима да купе услуге или производе представљене уносима података. На пример, регистар може бити каталог доступних АПИ-ја.

Снаге: Потребно је применити децентрализовано окружење у којем један неваљали корисник или мало корисника не може значајно утицати на систем.

Решење: Предложени образац делује на следећи начин.

Прво размотримо регистар. Са предложеном архитектуром, када корисник изда ажурирање регистра (да би додао или изменио унос), клијент бележи промене у блок ланцу. Ако су подаци у ажурирању велики, запис блок ланца може садржати везу до података и хеш вредност података. Ако податке ускладиштене у регистру треба изменити, клијент регистра додаје нови запис у блок ланац са измењеним информацијама.

На горњем дијаграму, сваки корисник има клијента регистра који ради на локалној машини (нпр. Лаптоп или телефон). Сваки клијент регистра чита записе ажурирања из ланца блокова, верификује податке ажурирања према хешу укљученом у записе и реконструише најновији приказ записа из ажурирања. На пример, читајући записе о блоцкцхаин-у о АПИ-јевима, њиховим додавањима, изменама и уклањањима, клијент регистра може створити приказ који приказује тренутне АПИ-је укључене у регистар. Да не би морали читати и верификовати све записе сваки пут када се користи регистар, клијенти могу податке сместити у базу података и индексирати. Клијент треба да повремено проверава блок ланац и ажурира регистар.

Блоцкцхаин добро функционише као „тржиште услуга“, јер се иста услуга може продати више пута. Међутим, због ограничења перформанси, пијаце засноване на блоцкцхаин-у нису погодне за производе који се могу продати само једном.

Да илуструјемо, функционалност регистра заснованог на блоцкцхаин-у, погледајмо када Алице жели да се претплати на „услугу вести о времену“ на тржишту блоцкцхаин-а. Када преда захтев, регистар креира акредитиве за услугу и дели их са Алице. Уплата се може догодити на један од неколико начина: коришћењем Битцоин-а, путем паметног уговора где се плаћања врше благовремено или неким ванбродским средствима.

Архитектонски образац за паметне уговоре и управљане ствари

Према овом обрасцу, разматрамо два случаја. Прво, разматрамо паметне уговоре, а као друго разматрамо уобичајени специјални случај паметних уговора: „Управљане ствари“.

Узорак паметних уговора

Контекст: Више корисника жели да се придржава уговора, описаног као извршни програм. Уговор пролази кроз транзицију државе према условима дефинисаним у уговору и у датом тренутку сви се могу сложити о тренутном статусу уговора.

Снаге: треба применити окружење у којем један неваљали корисник или мало корисника не може значајно утицати на систем.

Решење: Паметни контакти су део блоцкцхаин технологија и подржани су применом блоцкцхаин-а, као што је Етхереум. Уговор је описан на језику паметног уговора и дистрибуиран свим учесницима. Како се услови дефинисани у уговору мењају, сваки учесник извршава уговор и бележи тренутни статус у блок ланцу користећи консензус алгоритам.

Узорак управљаних ствари

Контекст: Морамо да пратимо власништво над стварним паметним стварима. Овде су паметне ствари објекти из стварног света који су способни да покрећу рачунарску логику у себи. Власнику је дозвољено да контролише и извршава радње на стварима из стварног света. Такође, власник може пренети своје власништво на неког другог.

Снаге: треба применити окружење у којем један неваљали корисник или мало корисника не може значајно утицати на систем.

Решење: Следи опис примене узорка помоћу примера Цар као управљана ствар.

Блокчејн за управљану ствар, у овом случају за аутомобил, можемо применити у два корака. Прво, произвођач бележи ДИД и јавни кључ власника аутомобила. Када се власништво промени, власник додаје нови запис у блок ланац наводећи новог власника. Друго, приликом провере власништва, аутомобил прво преузима све записе у блок ланцу и проверава да ли је сваки запис у то време додао власник. То се постиже проверавањем јавног кључа корисника који је записао запис према јавном кључу обухваћеном претходном евиденцијом власништва. Последњи власник у овом важећем ланцу је тренутни власник.

Након утврђивања власника, аутомобил се пријављује код тренутног власника Алице, преузимањем њеног јавног кључа и извршавањем пријаве засноване на изазову и одговору на основу Алицеиног телефона, који има Алицеин приватни кључ.

Такав систем смањује ризике повезане са даљински контролисаним артефактима. На пример, у примени која није блоцкцхаин, неко са приступом може да промени власништво над вашим аутомобилом. Међутим, са моделом заснованим на блоцкцхаин-у, да би даљински управљао аутомобилом, потенцијални нападач мора променити евиденцију власништва у блоцкцхаин-у, што је врло тешко постићи а да није власник.

Међутим, тешко је зауставити некога ко има приступ „ствари“ да физички промени логику која се изводи (нпр. Заменом фирмвера аутомобила). Једно решење овог проблема је изградња неког облика самоуништења који се активира када се детектује неовлашћено руковање артефактом.

На пример, Алице купује аутомобил од Боба помоћу паметног уговора који плаћа Бобу и ажурира власништво над возилом. Након трансакције, Алице одлази до аутомобила, који са телефона чита Алицеин ДИД, преузима њен јавни кључ, аутентификује је помоћу протокола цхалленге-респонсе комуницирајући са телефоном који има Алицеин приватни кључ, верификује своје власништво и откључава ауто.

Закључак

Разговарали смо о четири узорка архитектуре заснованих на блоцкцхаин-у. ГитХуб документ, Блоцкцхаин-басед Интегратион Усе Цасе, приказује ове обрасце на делу, описујући како се могу применити 30 и више случајева примене блоцкцхаин-а помоћу ова четири обрасца.

Ако имате мишљења о горњим обрасцима или знате о другим обрасцима, заиста бих волео да чујем о њима.

Надам се да је ово било корисно. Ако вам се ово свиђа, можда ће вам се свидети и детаљна анализа блокчејна у нашем недавно објављеном раду „Анкета о блоку вериге усредсређена на употребу: статус куо и будућа упутства“.