Не, стартирането на децентрализирано приложение (dapp) на блокчейн няма да доведе до успешен бизнес. Всъщност, повечето потребители дори не се замислят дали приложението работи на блокчейн — те просто избират продукт, който е по-евтин, по-бърз и по-лесен за използване.

За съжаление, дори и да има уникални характеристики и предимства на блокчейн, повечето приложения, които работят на него, са значително по-скъпи, по-бавни и по-малко разбираеми от техните централизирани конкуренти.

Сравнително често в whitepaper-ите на приложенията, построени на блокчейн, може да срещнете абзац, в който се казва: "блокчейн е скъп и не е способен да поддържа нужното количество транзакции в секунда. За щастие, много умни хора работят върху мащабирането на блокчейн и до момента на стартиране на нашето приложение той ще бъде достатъчно мащабируем".

В един прост абзац разработчикът на dapp може да се откаже от по-дълбокото обсъждане на проблемите с мащабируемостта и алтернативни решения на проблемите. Това често води до неефективна архитектура, където бекендът и ядрото на приложението служат за смарт-контракти, работещи на блокчейн.

Въпреки това, все още съществуват непроверени подходи в архитектурата на децентрализирани приложения, които позволяват много по-добра мащабируемост, благодарение на намалената зависимост от блокчейн. Например, Blockstack работи върху архитектура, в която повечето данни и логика на приложението се съхраняват извън блокчейн.

Нека първо погледнем на по-традиционния подход, при който блокчейн се използва като директен посредник между потребителите на приложението и който не се мащабира особено добре.

Подход #1: Блокчейн като бекенд

За да бъде по-очевидно, нека вземем хотелиерството за пример. Това е огромна индустрия, в която посредниците като Booking.com, вземат огромни такси за свързването на гости и хотели.

В всяка ситуация, в която искаме да победим такъв посредник, използвайки този подход, ще се опитаме да повторим неговата бизнес логика, използвайки смарт-контракти на блокчейн като Ethereum.

Смарт договори с отворен код, стартирани на "глобалния компютър", могат да свързват продавачи с потребители без посредник, в крайна сметка намалявайки таксите и комисиите, начислявани от посредника.

Както е показано на изображението по-долу, хотелите използват децентрализирано приложение за публикуване в блокчейна на информация за стаите, тяхната наличност и цени през делнични или почивни дни, и възможно дори описание на стаите с всяка друга подходяща информация.

Всеки, който желае да резервира стая, използва това приложение, за да търси хотели и стаи, публикувани в блокчейна. След като потребителят избере стая, резервацията се осъществява чрез изпращане на нужната сума токени на хотела като депозит. В отговор, смарт договорът актуализира информацията в блокчейна, показвайки, че стаята вече не е налична.

В този подход съществуват два аспекта на проблема със мащабируемостта. Първо, максималният брой транзакции в секунда. Второ, обемът данни, който може да се съхранява в блокчейна.

Нека направим приблизителни изчисления. Booking.com заявява, че имат регистрирани почти 2 милиона хотела. Да предположим, че в средата един хотел има 10 стаи и всяка се резервира само 20 пъти на година — това ни дава средно 13 резервации в секунда.

За оценка на това число е важно да се отбележи, че Ethereum може да обработи около 15 транзакции в секунда.

При това трябва да се има предвид, че в нашето приложение също ще има транзакции от хотелите — за качване и постоянно обновление на информацията за техните стаи. Хотелите обновяват цените на стаите много често, понякога дори ежедневно, и всяка промяна в цената или описанието изисква транзакция в блокчейна.

Тук също съществуват проблеми с размера — теглото на блокчейна на Ethereum наскоро надвиши 2TB. Ако приложенията с подобен подход станат наистина популярни, мрежата Ethereum ще стане изключително нестабилна.

Такава система, основана на блокчейн, може да изключи външни лица заради нейния неутралитет и липса на централизация — основни предимства на технологията блокчейн. Но блокчейнът има и други характеристики — той е разпределен и не перезаписваем, това са отличителни качества, но за тях се плаща с бавност и комисионни за транзакции.

Затова разработчиците на dapp'ове трябва внимателно да оценят дали наистина всяка характеристика, която използва блокчейн, се нуждае от разпределение и неперезаписваемост.

Например: какво е предимството на разпределението на данните на всеки хотел по стотици машини по целия свят и постоянното им съхранение там? Наистина ли е важно историческите данни за цените и наличността на стаите винаги да се включват в блокчейн? Вероятно, не.

Ако започнем да задаваме такива въпроси, ще започнем да виждаме, че не е задължително да имаме всички скъпи характеристики на блокчейн за всички наши функции. Така че каква е алтернативата?

Подход #2: Архитектура, вдъхновена от Blockstack

Въпреки че основният акцент Blockstack е върху приложения, в които потребителите притежават своите данни (например такива като Airtext, BentenSound, ImageOptimizer или Graphite), Blockstack също така има философия за малкото използване на блокчейн — само когато това е абсолютно необходимо. Основният им аргумент е, че блокчейнът е бавен и скъп, което означава, че трябва да се използва само за индивидуални или рядко срещани операции. Всички останали взаимодействия с приложения трябва да протичат чрез peer-to-peer, т.е. потребителите на децентрализирани приложения трябва да споделят данни директно помежду си, а не чрез блокчейн. В крайна сметка, най-старите и успешни децентрализирани приложения, като BitTorrent, имейл и Tor, са създадени още преди самата концепция за блокчейн.

Вляво: първият подход, при който потребителите взаимодействат чрез блокчейн. Вдясно: потребителите взаимодействат директно помежду си, а блокчейнът се използва само за идентификация и подобни.

Нека се върнем на примера с резервиране на хотели. Искаме безпристрастен, независим и отворен протокол за свързване на гости с хотели. С други думи, искаме да премахнем централизирания посредник. Нямаме нужда, например, постоянно да съхраняваме цените на стаите в общ разпределен регистър.

Защо да не позволим на гостите и хотелите да взаимодействат директно помежду си, вместо през блокчейн? Хотелите могат да съхраняват цените си, наличността на стаите и всяка друга информация някъде, където тя ще бъде достъпна за всички — например, IPFS, Amazon S3 или дори собствен сървър. Това е точно това, което предлага децентрализирана система за съхранение от Blockstack, наречена Gaia. Тя позволява на потребителите да избират къде искат да съхраняват данните си и да контролират кой може да има достъп до тях чрез подхода, наречен многопотребителско хранилище.

За да се установи доверие, всички данни от хотела се подписват криптографски от самия хотел. Независимо къде се съхраняват тези данни, тяхната интегритет може да бъде проверена с помощта на публични ключове, свързани с идентификационната информация на този хотел, съхранявана в блокчейн.

В случая с Blockstack, в блокчейна се съхранява само вашата идентификационна информация. Информацията за това как да се получат данните на всеки потребител се съхранява в файлове за зони (zone files) и се разпространява чрез пиринговата мрежа с помощта на възли. И отново — не е необходимо да вярвате на данните, предоставяни от възлите, защото можете да проверите тяхната автентичност, сравнявайки ги с хешовете, съхранявани в блокчейна и у други потребители.

В опростената версия на системата, гостите ще използват пиринговата мрежа на Blockstack за намиране на хотели и получаване на информация за техните стаи. А автентичността и интегритетът на всички данни, които ще получите, могат да бъдат проверени с помощта на публични ключове и хешове, съхранявани в виртуалната верига Blockstack.

Тази архитектура е по-сложна от първоначалния подход и изисква по-комплексна инфраструктура. Всъщност, точно тук идва Blockstack, предоставяйки всички необходими компоненти за изграждане на такава децентрализирана система.

При такава архитектура, ние съхраняваме в блокчейна само данните, които наистина трябва да бъдат разпространявани и не сменяеми. При Blockstack ви трябват транзакции в блокчейна само за да се регистрирате и да посочите къде трябва да се съхраняват данните ви. Може да ви бъдат необходими още транзакции, ако решите да промените нещо от тази информация, но това не е повтарящо се събитие.

Освен това, логиката на приложението, в противовес на първия подход, работи на страната на клиента, а не на смарт-контрактите. Това позволява на разработчика да променя тази логика без скъпи или понякога дори невъзможни актуализации на смарт-контракта. А като държи данните и логиката на приложението извън блокчейна, децентрализирани приложения могат да постигнат ниво на производителност и мащабируемост, съпоставимо с традиционните централизирани системи.

Заключение

Приложенията, работещи на Blockstack, могат да се мащабират значително по-добре от обикновените блокчейн приложения, но това е по-млад подход с собствени проблеми и нерешени въпроси.

Например, ако децентализираното приложение не работи на смарт-контрактите, това намалява необходимостта от утилити токени. Това може да създаде проблеми за бизнеса, като се има предвид, че ICO бяха основният източник на финансиране за децентрализираните приложения (включително самия Blockstack).

Тук също така има технически проблеми. Например, е относително лесно да се реализира функция за резервации на хотели в смарт-контракт, където при атомарна операция резервацията на стаи се извършва в замяна на токени. И не е много очевидно как резервацията ще работи в приложение на Blockstack без смарт-контракти.

Приложенията, които целят глобални пазари с потенциал за милиони потребители, трябва да се мащабират много добре, за да бъдат успешни. Грешно е да се разчита изцяло на блокчейн технологии за достигане на такова ниво на мащабируемост в близко бъдеще. За да могат да се конкурират с големите централизирани играчи на пазара, като Booking.com, разработчиците на децентрализирани приложения трябва да обмислят алтернативни подходи за проектиране на своите приложения, като този, който предлага Blockstack.

Източник: habr.com