Какво ни струва да построим блокчейн?

Цялата история на човечеството е непрекъснато освобождаване от веригите и създаване на нови, още по-здрави. (Анонимен автор)

Анализирайки многобройните блокчейн проекти (Bitshares, Hyperledger, Exonum, Ethereum, Bitcoin и др.), разбирам, че от техническа гледна точка всички те са изградени на едни и същи принципи. Блокчейн мрежите напомнят на къщи, които, въпреки разнообразието от конструкции, декор и предназначение, имат фундамент, стени, покрив, прозорци и врати, свързани помежду си по определени начини. И ако разберем основните принципи на проектиране на сгради и знаем свойствата на използваните материали, можем да определим целевото предназначение на конкретната къща. В момента, по отношение на блокчейна, ситуацията е такава, че всички вече знаят за него, но малко хора разбират архитектурата и принципите на работа. Поради това възниква неразбиране относно това защо и как има смисъл да се използват блокчейн технологии.

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

И така, нека си припомним какви проблеми първоначално реши блокчейн.

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

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

Задача на блокчейна

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

Проблемите, които решава блокчейнът

Представете ли си една финансова организация, която твърди, че е построила мрежа по целия свят, чрез която можете да изпращате пари на всеки човек? Ще и се доверите ли? Ако това е организация като Visa или MasterCard, вероятно ще се доверите, но ако, да речем, е AnonymousWorldMoney, вероятно не. Защо? Защото знаем как частните компании изграждат разпределени системи, с какви цели и до какво може да доведе това. Нека разгледаме по-подробно проблемите на такива системи и как могат да бъдат решени с помощта на блокчейн технологии.

Да предположим, че в условната AnonymousWorldMoney има сървъри с бази данни, и би било добре да има няколко в различни дата центрове. Когато подателят изпрати пари, транзакцията се регистрира и репликира на всички сървъри, а парите достигат до получателя.

В идеалния свят тази схема работи отлично, но нашият свят среща следните проблеми:

1. Проблемът с идентификацията на участниците от една страна и необходимостта от анонимност на транзакциите от друга. Т.е. трябва да се изпратят пари на конкретен получател, така че никой да не знае за тази транзакция, освен участниците в сделката. Банките имат номера на сметки и банкови карти, които са свързани с конкретно физическо или юридическо лице, а банковата тайна защитава информацията за транзакциите. Но кой гарантира, че условната AnonymousWorldMoney не използва лични данни и информация за транзакциите за свои цели?
2. Как да бъдете сигурни, че получателят е получил точно тази сума, която му е изпратена? Да речем, подателят е изпратил $100, а получателят е получил $10. Подателят отива в офиса на AnonymousWorldMoney със своята разписка, а служителят показва своята версия, където е записано, че подателят е изпратил само $10.
3. Проблемът с недоверието в средата, например измама, наречена двудупение. Некоректен участник може да разходва своя баланс няколко пъти, преди плащането да бъде репликирано на всички сървъри. Теоремата CAP, разбира се, не е отменена и консенсус в крайна сметка ще бъде постигнат, но някой няма да получи парите за предоставените услуги или стоки. Следователно, ако няма пълно доверие в платежната организация или участниците в сделките, трябва да изградим мрежа, основаваща се не на доверие, а на криптография.
4. Условната AnonymousWorldMoney има крайно число сървъри, които могат да станат недостъпни по невнимание или злонамерено.
5. AnonymousWorldMoney ще вземе своя осезаема такса.
6. Възможност за управление. При експлоатацията на Биткойн стана ясно, че хората искат не само да прехвърлят монети помежду си, но и да проверяват различни условия на транзакцията, да програмират сценарии на работа, автоматично да извършват действия в зависимост от условията и т.н.

Как блокчейн решава тези проблеми

1. Идентификацията на участниците се осъществява чрез двойка ключове: частен и публичен, а алгоритъмът за цифров подпис недвусмислено идентифицира изпращача и получателя, оставяйки техните самоличности анонимни.
2. Транзакциите се събират в блокове, изчислява се хеш на блока, който се записва в следващия блок. Тази последователност от записване на хешове в блоковете даде името на технологията блокчейн, и именно тя прави невъзможно незабележимото изменение / изтриване на блокове или отделни транзакции от блоковете. Така, ако транзакцията е в блокчейн, може да се бъде сигурен, че нейните данни ще останат непроменени.
3. Измамата с двойно изразходване се предотвратява чрез постигане на консенсус в мрежата, какви данни да се смятат за верни, а какви да се отхвърлят. В мрежата Биткойн консенсусът се постига чрез доказателство за работа PoW (Proof-of-Work).
4. Надеждността на функционирането на мрежата се постига чрез това, че блокчейнът е публичен, където всеки участник може да стартира своя нода, да получи пълна копия на блокчейна и, освен това, самостоятелно да започне да проверява транзакциите за коректност. Трябва да се отбележи, че съвременните блокчейни позволяват изграждане не само на публични (открити), но и частни (затворени) блокчейни, както и удвоени схеми.
5. Напълно да се освободи от такса в блокчейна не е възможно, тъй като трябва да се плаща на хората, които поддържат мрежата, но в блокчейна необходимостта от такса се доказва толкова убедително, че не остава съмнение в нейната необходимост.
6. Съвременните блокчейни имат възможност да реализират бизнес логика, която в блокчейна се нарича Смарт Контракти. Логиката на смарт контрактите се реализира на различни езици от висок порядък.

Нека разгледаме тези решения по-подробно.

Архитектура на блокчейна

Съставни части на блокчейна

Все участници могат да стартират собствен възел с пълна копия на блокчейна (full node). Пълните възли, които могат да записват транзакции в блокчейна, се наричат възли на консенсуса (witness) или миньори (miner). Пълните възли, които само проверяват правилността на транзакциите, се наричат възли на одит (audit). Леките клиенти (light clients) не съхраняват пълни копия на блокчейна, а взаимодействат с мрежата, използвайки пълни възли.
Повечето потребители за извършване на транзакции използват именно леките клиенти или уеб портфейли. Всички възли са свързани помежду си. При такъв набор от елементи архитектурата на мрежата става по-устойчива:

Животен цикъл на транзакцията

Нека разгледаме жизнения цикъл на транзакцията и да го анализираме на части:

Технологии на блокчейна

Нека се спрем по-подробно на техническите решения и техните връзки помежду си.

Идентификация

Всяка транзакция в блокчейна трябва да бъде подписана с цифров подпис. Затова, за извършване на транзакция, всеки участник трябва да има двойка ключове: private / public. Понякога двойката ключове се нарича портфейл (wallet), тъй като ключовете са недвусмислено свързани с уникален цифров адрес и баланс на участника. В действителност ключовете и адресите са просто стрингове от цифри в различни системи на численост. Примери за ключове и адрес на портфейл:

Частен ключ: 0a78194a8a893b8baac7c09b6a4a4b4b161b2f80a126cbb79bde231a4567420f
Публичен ключ: 0579b478952214d7cddac32ac9dc522c821a4489bc10aac3a81b9d1cd7a92e57ba
Адрес: 0x3814JnJpGnt5tB2GD1qfKP709W3KbRdfb27V

За създаване на цифров подпис в блокчейните се използва алгоритъм, основан на елиптични криви: Elliptic Curve Digital Signature Algorithm (ECDSA). За работата му частният ключ (256-битово число) обикновено се взима на случаен принцип. Броят на вариантите на ключовете представлява 2 на степен 256, затова можем да говорим за практическа невъзможност за съвпадение на стойностите на частните ключове.

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

Има много статии с подробности по криптографията, използвана в блокчейна, например: Bitcoin in a nutshell — Cryptography

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

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

Транзакции

По-подробно за структурата на транзакцията можете да прочетете в статията Bitcoin в общи линии — Транзакция. За нас е важно да разберем, че всяка транзакция съдържа поне следните данни:

От: 0x48C89c341C5960Ca2Bf3732D6D8a0F4f89Cc4368 - цифров адрес на подателя
До: 0x367adb7894334678b90аfe7882a5b06f7fbc783a - цифров адрес на получателя
Стойност: 0.0001 - сума на транзакцията
Транзакционен хаш: 0x617ede331e8a99f46a363b32b239542bb4006e4fa9a2727a6636ffe3eb095cef - хаш на транзакцията

След това транзакцията се подписва с приватния ключ и се разпространява (вижте подробности за работата на протокола Bitcoin в общи линии - Протокол) до всички нодове в блокчейна, които проверяват транзакциите за валидност. Алгоритъмът за проверка на транзакцията не е тривиален и включва два десетки стъпки.

Блокове на транзакции

След като проверят валидността на транзакциите, нодовете ги формират в блокове. Освен транзакциите, в блока се записва хешът на предишния блок, числото (броячът Nonce), и се извършва изчислението на хеша на текущия блок по алгоритъма SHA-256. Хешът трябва да отговаря на установените условия за трудност. Например, в мрежата Bitcoin трудността на хеша автоматично се променя на всеки 2 седмици в зависимост от мощността на мрежата, така че блокът да се генерира приблизително на всеки 10 минути. Трудността се определя от следното условие: намереният хеш трябва да бъде по-малък от предварително зададено число. Ако това условие не е изпълнено, Nonce се увеличава с 1, и работата по изчисляването на хеша се повтаря. За подбора на хеша се използва полето Nonce, тъй като това е единствената информация в блока, която може да бъде променена, останалите трябва да останат неизменни. Правилният хеш трябва да има определено количество нули в началото, например, един от реалните хешове:

000000000000000000000bf03212e7dd1176f52f816fa395fc9b93c44bc11f91

Успешното намиране на хеш е доказателство за извършената работа (Proof-of-Work, PoW) за мрежите Bitcoin или Ethereum. Процесът на намиране на хешове се нарича минно дело (mining), подобно на извличането на злато. Името доста точно определя същността на процеса, тъй като се извършва просто избиране на варианти, и ако някой е намерил подходящ хеш, то наистина е късмет. Това е като да намериш истински самородно злато в тонове безполезна руда. Наградата за блок в момента е 12.5 BTC и ако я умножим по актуалната цена на биткойна $3900, то се получава повече от килограм чисто злато. Има за какво да се борим!

След успешното намиране на хеш, блокът и самият намерен хеш се записват в блокчейна в следващия блок. Повече за структурата на блоковете можете да видите в статията Bitcoin в резюме - Блокчейн, а по-долу ще представя опростена схема:

Блокчейнът започва с блок, който все още няма хеш на предишния блок. Този блок в блокчейна е единствен и има собствено имя - Genesis block. Останалите блокове имат еднаква структура, но се различават само по броя на транзакциите. Реалните транзакции и блокове, които се създават в момента в Bitcoin или Ethereum, можете да видите в Block Explorer.

Размерът на блоковете в Bitcoin е ограничен до 1MB и при минимален обем информация в транзакция от около 200 байта, в блока могат да бъдат около 6000 транзакции. Оттук и производителността на Bitcoin, над която всички се присмиват: блокът се генерира приблизително на всеки 10 минути * 60 секунди = 600 секунди, което дава формална производителност от около 10 TPS. Въпреки това, всъщност – това не е производителност, а съзнателно реализиран алгоритъм на работа. В Ethereum за конкуренция просто увеличиха времето за генериране на блока до 15 секунди и формалната производителност рязко скочи. Затова в блокчейните, използващи PoW като консенсус, е абсолютно безсмислено да се сравнява производителността, тъй като тя пряко зависи от сложността на изчислението на кеша, което може да бъде зададено произволно.

Форкове

Какво се случва, ако например, няколко възли намерят хешове, които отговарят на условията за сложност, но са различни по стойност (с други думи, достигнали са до различни консенсуси) и запишат блоковете в блокчейн? Нека да разгледаме как блокчейнът се защитава от тази ситуация. В такъв случай настъпва т. нар. форк (‘вилка’), и блокчейнът има две версии на веригата:

Какво се случва по-нататък? След това част от мрежата започва да работи по блок N+2 от една верига, а част от друга:

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

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

Същата картина с форка на блоковете ще се наблюдава и при т. нар. атака от 51% — това е, когато група миньори се опитва да създаде алтернативна верига от блокове, стремейки се да анулират веригата с мошеническите си транзакции. Въпреки това в момента, вместо мошеничество, е по-изгодно да се използват мощностите за честен майнинг.

Консенсус

За да бъде записан блок в блокчейн, мрежата трябва да достигне до консенсус. Нека си припомним задачата за достигане на консенсус в компютърните мрежи за връзка. Проблемът се формулира като задача на византийските генерали BFT (Византийска устойчивост на грешки). Пропускайки живописното описание на проблемите на византийската армия, задачата може да бъде формулирана така: как възлите на мрежата да достигнат до общ резултат, ако част от възлите на мрежата могат съзнателно да ги изкривяват. Съществуващите алгоритми за решаване на задачата BFT показват, че мрежата може да функционира правилно, ако мошениците са по-малко от 1/3. Защо в мрежата Bitcoin не е приложен консенсус BFT? Защо е нужно да се използва PoW? Има няколко причини:

• BFT работи добре с малък фиксиран набор от нодове, а в публичната блокчейн броят на нодовете е непредсказуем и освен това, нодовете могат произвольно да се включват и изключват.
• Необходимо е да се мотивират хората да стартират блокчейн нодове. За това хората трябва да получават награда. В BFT формално няма за какво да се получават награди, а наградата в PoW е интуитивно разбираема: за електричеството, консумирано от процесора при намирането на хеш на блока.

Освен PoW съществуват и няколко други консенсуса, които се използват в съвременните блокчейни, например:

• PoS (Proof-of-Stake) — в блокчейна Hyperledger
• DPoS (Delegated Proof-of-Stake) — в блокчейна BitShares
• Модификации на BFT: SBFT (Simplified BFT) и PBFT (Practical BFT), например, в блокчейна Exonum

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

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

• Консенсусът Delegated PoS (DPoS) разделя участниците на 'гласуващи' и 'валидиращи'. Държателите на монети (гласуващи участници) делегират правото си да проверяват и записват транзакции в блокчейна на други участници. Така валидаторите извършват цялата изчислителна работа и получават награда за това, а наличието на гласуващи участници гарантира добросъвестността на валидаторите, тъй като те могат да бъдат сменени по всяко време.
• Консенсус LPoS (Leased Proof-of-Stake) позволява да отдавате средствата си под наем на други възли, така че те да имат повече шансове за проверка на блокове. По този начин можете да получавате такса за транзакции, без да участвате в самата проверка на транзакциите и в миньорството на блокове.

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

• PoET (Proof-of-Elapsed Time)
• PoC (Proof-of-Capacity)
• PoB (Proof-of-Burn)
• PoWeight (Proof-of-Weight)
• PoA (Proof-of-Activity) — PoW + PoS
• PoI (Proof-of-Importance)

Надеждност и модели на разгръщане на блокчейни

Публичен блокчейн

Устойчивост Public или друго наименование Permissionless blockchain се постига с това, че всеки може да се свърже и преглежда информация или дори да свърже собствен възел, а доверието се изгражда на базата на консенсуса PoW.

Приватен блокчейн

Private или Private Permissioned blockchain. В тези блокчейни само определена група участници (организации или хора) има достъп до информацията. Такива блокчейни изграждат организации с цел увеличаване на общата печалба или ефективността. Тяхната надеждност се осигурява от общите цели на участниците и алгоритмите на консенсуса PoS и BFT.

Блокчейн-консорциум

Съществуват Consortium или Public Permissioned blockchain. Това са такива блокчейни, към които всеки може да се свърже за преглед, но добавянето на информация или свързването на собствен възел е възможно само с разрешение от други участници. Такива блокчейни изграждат организации с цел повишаване на доверието от страна на клиентите или потребителите на продукта или обществото като цяло. Тук надеждността също се постига с присъствието на доверие между участниците и същите алгоритми на консенсуса PoS и BFT.

Умни Договори

В блокчейни, реализирани след Bitcoin, до известна степен е добавена възможността за изпълнение на умни договори. Всъщност, умният договор е транзакция, в която е включен програмен код за изпълнение. Умните договори в мрежата Ethereum се изпълняват в EVM (Ethereum Virtual Machine). За да стартирате изпълнението на умния договор, той трябва да бъде явно задействан с друга транзакция или трябва да се изпълнят предварителните условия за изпълнение. Резултатите от изпълнението на умния договор също ще бъдат записани в блокчейна. Получаването на данни извън блокчейна е възможно, но е крайно ограничено.

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

Класическият пример за функционалност, която се реализира с използване на смарт-контракти, е емитирането на токени за провеждане на ICO. Например, аз реализирах смарт-контракт за емитирането на скромните 500 000 000 AlexToken. По връзката в Etherscan се намира

изходен код на смарт-контракта на езика Solidity

pragma solidity ^0.4.23;

library SafeMath {
    /**
     * @dev Multiplies two numbers, throws on overflow.
     **/
    function mul(uint256 a, uint256 b) internal pure returns (uint256 c) {
        if (a == 0) {
            return 0;
        }
        c = a * b;
        assert(c / a == b);
        return c;
    }
    
    /**
     * @dev Integer division of two numbers, truncating the quotient.
     **/
    function div(uint256 a, uint256 b) internal pure returns (uint256) {
        // assert(b > 0); // Solidity automatically throws when dividing by 0
/**
 * @title SafeMath
 * @dev Math operations with safety checks that throw on error
 */
        // uint256 c = a / b;
        // assert(a == b * c + a % b); // There is no case in which this doesn't hold
        return a / b;
    }
    
    /**
     * @dev Subtracts two numbers, throws on overflow (i.e. if subtrahend is greater than minuend).
     **/
    function sub(uint256 a, uint256 b) internal pure returns (uint256) {
        assert(b <= a);
        return a - b;
    }
    
    /**
     * @dev Adds two numbers, throws on overflow.
     **/
    function add(uint256 a, uint256 b) internal pure returns (uint256 c) {
        c = a + b;
        assert(c >= a);
        return c;
    }
}

/**
 * @title Ownable
 * @dev The Ownable contract has an owner address, and provides basic authorization control
 * functions, this simplifies the implementation of "user permissions".
 **/
 
contract Ownable {
    address public owner;
    event OwnershipTransferred(address indexed previousOwner, address indexed newOwner);

    /**
     * @dev The Ownable constructor sets the original `owner` of the contract to the sender account.
     **/
   constructor() public {
      owner = msg.sender;
    }
    
    /**
     * @dev Throws if called by any account other than the owner.
     **/
    modifier onlyOwner() {
      require(msg.sender == owner);
      _;
    }
    
    /**
     * @dev Allows the current owner to transfer control of the contract to a newOwner.
     * @param newOwner The address to transfer ownership to.
     **/
    function transferOwnership(address newOwner) public onlyOwner {
      require(newOwner != address(0));
      emit OwnershipTransferred(owner, newOwner);
      owner = newOwner;
    }
}

/**
 * @title ERC20Basic interface
 * @dev Basic ERC20 interface
 **/
contract ERC20Basic {
    function totalSupply() public view returns (uint256);
    function balanceOf(address who) public view returns (uint256);
    function transfer(address to, uint256 value) public returns (bool);
    event Transfer(address indexed from, address indexed to, uint256 value);
}

/**
 * @title ERC20 interface
 * @dev see https://github.com/ethereum/EIPs/issues/20
 **/
contract ERC20 is ERC20Basic {
    function allowance(address owner, address spender) public view returns (uint256);
    function transferFrom(address from, address to, uint256 value) public returns (bool);
    function approve(address spender, uint256 value) public returns (bool);
    event Approval(address indexed owner, address indexed spender, uint256 value);
}

/**
 * @title Basic token
 * @dev Basic version of StandardToken, with no allowances.
 **/
contract BasicToken is ERC20Basic {
    using SafeMath for uint256;
    mapping(address => uint256) balances;
    uint256 totalSupply_;
    
    /**
     * @dev total number of tokens in existence
     **/
    function totalSupply() public view returns (uint256) {
        return totalSupply_;
    }
    
    /**
     * @dev transfer token for a specified address
     * @param _to The address to transfer to.
     * @param _value The amount to be transferred.
     **/
    function transfer(address _to, uint256 _value) public returns (bool) {
        require(_to != address(0));
        require(_value <= balances[msg.sender]);
        
        balances[msg.sender] = balances[msg.sender].sub(_value);
        balances[_to] = balances[_to].add(_value);
        emit Transfer(msg.sender, _to, _value);
        return true;
    }
    
    /**
     * @dev Gets the balance of the specified address.
     * @param _owner The address to query the the balance of.
     * @return An uint256 representing the amount owned by the passed address.
     **/
    function balanceOf(address _owner) public view returns (uint256) {
        return balances[_owner];
    }
}

contract StandardToken is ERC20, BasicToken {
    mapping (address => mapping (address => uint256)) internal allowed;
    /**
     * @dev Transfer tokens from one address to another
     * @param _from address The address which you want to send tokens from
     * @param _to address The address which you want to transfer to
     * @param _value uint256 the amount of tokens to be transferred
     **/
    function transferFrom(address _from, address _to, uint256 _value) public returns (bool) {
        require(_to != address(0));
        require(_value <= balances[_from]);
        require(_value <= allowed[_from][msg.sender]);
    
        balances[_from] = balances[_from].sub(_value);
        balances[_to] = balances[_to].add(_value);
        allowed[_from][msg.sender] = allowed[_from][msg.sender].sub(_value);
        
        emit Transfer(_from, _to, _value);
        return true;
    }
    
    /**
     * @dev Approve the passed address to spend the specified amount of tokens on behalf of msg.sender.
     *
     * Beware that changing an allowance with this method brings the risk that someone may use both the old
     * and the new allowance by unfortunate transaction ordering. One possible solution to mitigate this
     * race condition is to first reduce the spender's allowance to 0 and set the desired value afterwards:
     * https://github.com/ethereum/EIPs/issues/20#issuecomment-263524729
     * @param _spender The address which will spend the funds.
     * @param _value The amount of tokens to be spent.
     **/
    function approve(address _spender, uint256 _value) public returns (bool) {
        allowed[msg.sender][_spender] = _value;
        emit Approval(msg.sender, _spender, _value);
        return true;
    }
    
    /**
     * @dev Function to check the amount of tokens that an owner allowed to a spender.
     * @param _owner address The address which owns the funds.
     * @param _spender address The address which will spend the funds.
     * @return A uint256 specifying the amount of tokens still available for the spender.
     **/
    function allowance(address _owner, address _spender) public view returns (uint256) {
        return allowed[_owner][_spender];
    }
    
    /**
     * @dev Increase the amount of tokens that an owner allowed to a spender.
     *
     * approve should be called when allowed[_spender] == 0. To increment
     * allowed value is better to use this function to avoid 2 calls (and wait until
     * the first transaction is mined)
     * From MonolithDAO Token.sol
     * @param _spender The address which will spend the funds.
     * @param _addedValue The amount of tokens to increase the allowance by.
     **/
    function increaseApproval(address _spender, uint _addedValue) public returns (bool) {
        allowed[msg.sender][_spender] = allowed[msg.sender][_spender].add(_addedValue);
        emit Approval(msg.sender, _spender, allowed[msg.sender][_spender]);
        return true;
    }
    
    /**
     * @dev Decrease the amount of tokens that an owner allowed to a spender.
     *
     * approve should be called when allowed[_spender] == 0. To decrement
     * allowed value is better to use this function to avoid 2 calls (and wait until
     * the first transaction is mined)
     * From MonolithDAO Token.sol
     * @param _spender The address which will spend the funds.
     * @param _subtractedValue The amount of tokens to decrease the allowance by.
     **/
    function decreaseApproval(address _spender, uint _subtractedValue) public returns (bool) {
        uint oldValue = allowed[msg.sender][_spender];
        if (_subtractedValue > oldValue) {
            allowed[msg.sender][_spender] = 0;
        } else {
            allowed[msg.sender][_spender] = oldValue.sub(_subtractedValue);
        }
        emit Approval(msg.sender, _spender, allowed[msg.sender][_spender]);
        return true;
    }
}

/**
 * @title Configurable
 * @dev Configurable varriables of the contract
 **/
contract Configurable {
    uint256 public constant cap = 1000000000*10**18;
    uint256 public constant basePrice = 100*10**18; // tokens per 1 ether
    uint256 public tokensSold = 0;
    
    uint256 public constant tokenReserve = 500000000*10**18;
    uint256 public remainingTokens = 0;
}

/**
 * @title CrowdsaleToken 
 * @dev Contract to preform crowd sale with token
 **/
contract CrowdsaleToken is StandardToken, Configurable, Ownable {
    /**
     * @dev enum of current crowd sale state
     **/
     enum Stages {
        none,
        icoStart, 
        icoEnd
    }
    
    Stages currentStage;
    /**
     * @dev constructor of CrowdsaleToken
     **/
    constructor() public {
        currentStage = Stages.none;
        balances[owner] = balances[owner].add(tokenReserve);
        totalSupply_ = totalSupply_.add(tokenReserve);
        remainingTokens = cap;
        emit Transfer(address(this), owner, tokenReserve);
    }
    
    /**
     * @dev fallback function to send ether to for Crowd sale
     **/
    function () public payable {
        require(currentStage == Stages.icoStart);
        require(msg.value > 0);
        require(remainingTokens > 0);
        
        uint256 weiAmount = msg.value; // Calculate tokens to sell
        uint256 tokens = weiAmount.mul(basePrice).div(1 ether);
        uint256 returnWei = 0;
        
        if(tokensSold.add(tokens) > cap){
            uint256 newTokens = cap.sub(tokensSold);
            uint256 newWei = newTokens.div(basePrice).mul(1 ether);
            returnWei = weiAmount.sub(newWei);
            weiAmount = newWei;
            tokens = newTokens;
        }
        
        tokensSold = tokensSold.add(tokens); // Increment raised amount
        remainingTokens = cap.sub(tokensSold);
        if(returnWei > 0){
            msg.sender.transfer(returnWei);
            emit Transfer(address(this), msg.sender, returnWei);
        }
        
        balances[msg.sender] = balances[msg.sender].add(tokens);
        emit Transfer(address(this), msg.sender, tokens);
        totalSupply_ = totalSupply_.add(tokens);
        owner.transfer(weiAmount);// Send money to owner
    }
    

    /**
     * @dev startIco starts the public ICO
     **/
    function startIco() public onlyOwner {
        require(currentStage != Stages.icoEnd);
        currentStage = Stages.icoStart;
    }
    

    /**
     * @dev endIco closes down the ICO 
     **/
    function endIco() internal {
        currentStage = Stages.icoEnd;
        // Transfer any remaining tokens
        if(remainingTokens > 0)
            balances[owner] = balances[owner].add(remainingTokens);
        // transfer any remaining ETH balance in the contract to the owner
        owner.transfer(address(this).balance); 
    }

    /**
     * @dev finalizeIco closes down the ICO and sets needed varriables
     **/
    function finalizeIco() public onlyOwner {
        require(currentStage != Stages.icoEnd);
        endIco();
    }
    
}
 
/**
 * @title LavevelToken 
 * @dev Contract to create the Lavevel Token
 **/
contract AlexToken is CrowdsaleToken {
    string public constant name = "AlexToken";
    string public constant symbol = "ALT";
    uint32 public constant decimals = 18;
}

и бинарно представяне, каквото го вижда мрежата

60806040526000600355600060045533600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff1602179055506000600560146101000a81548160ff021916908360028111156200006f57fe5b0217905550620001036b019d971e4fe8401e74000000600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546200024a6401000000000262000b1d179091906401000000009004565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550620001986b019d971e4fe8401e740000006001546200024a6401000000000262000b1d179091906401000000009004565b6001819055506b033b2e3c9fd0803ce8000000600481905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef6b019d971e4fe8401e740000006040518082815260200191505060405180910390a362000267565b600081830190508281101515156200025e57fe5b80905092915050565b611cb880620002776000396000f300608060405260043610610112576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff16806306fdde03146104c7578063095ea7b31461055757806318160ddd146105bc57806323b872dd146105e7578063313ce5671461066c578063355274ea146106a3578063518ab2a8146106ce57806366188463146106f957806370a082311461075e57806389311e6f146107b55780638da5cb5b146107cc578063903a3ef61461082357806395d89b411461083a578063a9059cbb146108ca578063bf5839031461092f578063c7876ea41461095a578063cbcb317114610985578063d73dd623146109b0578063dd62ed3e14610a15578063f2fde38b14610a8c575b60008060008060006001600281111561012757fe5b600560149054906101000a900460ff16600281111561014257fe5b14151561014e57600080fd5b60003411151561015d57600080fd5b600060045411151561016e57600080fd5b3494506101a7670de0b6b3a764000061019968056bc75e2d6310000088610acf90919063ffffffff16565b610b0790919063ffffffff16565b9350600092506b033b2e3c9fd0803ce80000006101cf85600354610b1d90919063ffffffff16565b111561024c576101f66003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b915061022e670de0b6b3a764000061022068056bc75e2d6310000085610b0790919063ffffffff16565b610acf90919063ffffffff16565b90506102438186610b3990919063ffffffff16565b92508094508193505b61026184600354610b1d90919063ffffffff16565b6003819055506102886003546b033b2e3c9fd0803ce8000000610b3990919063ffffffff16565b6004819055506000831115610344573373ffffffffffffffffffffffffffffffffffffffff166108fc849081150290604051600060405180830381858888f193505050501580156102dd573d6000803e3d6000fd5b503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef856040518082815260200191505060405180910390a35b610395846000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055503373ffffffffffffffffffffffffffffffffffffffff163073ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef866040518082815260200191505060405180910390a361045184600154610b1d90919063ffffffff16565b600181905550600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc869081150290604051600060405180830381858888f193505050501580156104bf573d6000803e3d6000fd5b505050505050005b3480156104d357600080fd5b506104dc610b52565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561051c578082015181840152602081019050610501565b50505050905090810190601f1680156105495780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b34801561056357600080fd5b506105a2600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610b8b565b604051808215151515815260200191505060405180910390f35b3480156105c857600080fd5b506105d1610c7d565b6040518082815260200191505060405180910390f35b3480156105f357600080fd5b50610652600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050610c87565b604051808215151515815260200191505060405180910390f35b34801561067857600080fd5b50610681611041565b604051808263ffffffff1663ffffffff16815260200191505060405180910390f35b3480156106af57600080fd5b506106b8611046565b6040518082815260200191505060405180910390f35b3480156106da57600080fd5b506106e3611056565b6040518082815260200191505060405180910390f35b34801561070557600080fd5b50610744600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291908035906020019092919050505061105c565b604051808215151515815260200191505060405180910390f35b34801561076a57600080fd5b5061079f600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506112ed565b6040518082815260200191505060405180910390f35b3480156107c157600080fd5b506107ca611335565b005b3480156107d857600080fd5b506107e16113eb565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34801561082f57600080fd5b50610838611411565b005b34801561084657600080fd5b5061084f6114ab565b6040518080602001828103825283818151815260200191508051906020019080838360005b8381101561088f578082015181840152602081019050610874565b50505050905090810190601f1680156108bc5780820380516001836020036101000a031916815260200191505b509250505060405180910390f35b3480156108d657600080fd5b50610915600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803590602001909291905050506114e4565b604051808215151515815260200191505060405180910390f35b34801561093b57600080fd5b50610944611703565b6040518082815260200191505060405180910390f35b34801561096657600080fd5b5061096f611709565b6040518082815260200191505060405180910390f35b34801561099157600080fd5b5061099a611716565b6040518082815260200191505060405180910390f35b3480156109bc57600080fd5b506109fb600480360381019080803573ffffffffffffffffffffffffffffffffffffffff16906020019092919080359060200190929190505050611726565b604051808215151515815260200191505060405180910390f35b348015610a2157600080fd5b50610a76600480360381019080803573ffffffffffffffffffffffffffffffffffffffff169060200190929190803573ffffffffffffffffffffffffffffffffffffffff169060200190929190505050611922565b6040518082815260200191505060405180910390f35b348015610a9857600080fd5b50610acd600480360381019080803573ffffffffffffffffffffffffffffffffffffffff1690602001909291905050506119a9565b005b600080831415610ae25760009050610b01565b8183029050818382811515610af357fe5b04141515610afd57fe5b8090505b92915050565b60008183811515610b1457fe5b04905092915050565b60008183019050828110151515610b3057fe5b80905092915050565b6000828211151515610b4757fe5b818303905092915050565b6040805190810160405280600981526020017f416c6578546f6b656e000000000000000000000000000000000000000000000081525081565b600081600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925846040518082815260200191505060405180910390a36001905092915050565b6000600154905090565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff1614151515610cc457600080fd5b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d1157600080fd5b600260008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020548211151515610d9c57600080fd5b610ded826000808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610e80826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550610f5182600260008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b600260008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff168473ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a3600190509392505050565b601281565b6b033b2e3c9fd0803ce800000081565b60035481565b600080600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019081526020016000205490508083111561116d576000600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611201565b6111808382610b3990919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b8373ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008873ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a3600191505092915050565b60008060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549050919050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561139157600080fd5b60028081111561139d57fe5b600560149054906101000a900460ff1660028111156113b857fe5b141515156113c557600080fd5b6001600560146101000a81548160ff021916908360028111156113e457fe5b0217905550565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1681565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff1614151561146d57600080fd5b60028081111561147957fe5b600560149054906101000a900460ff16600281111561149457fe5b141515156114a157600080fd5b6114a9611b01565b565b6040805190810160405280600381526020017f414c54000000000000000000000000000000000000000000000000000000000081525081565b60008073ffffffffffffffffffffffffffffffffffffffff168373ffffffffffffffffffffffffffffffffffffffff161415151561152157600080fd5b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054821115151561156e57600080fd5b6115bf826000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b3990919063ffffffff16565b6000803373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002081905550611652826000808673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b6000808573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167fddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef846040518082815260200191505060405180910390a36001905092915050565b60045481565b68056bc75e2d6310000081565b6b019d971e4fe8401e7400000081565b60006117b782600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508273ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff167f8c5be1e5ebec7d5bd14f71427d1e84f3dd0314c0f7b2291e5b200ac8c7c3b925600260003373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020546040518082815260200191505060405180910390a36001905092915050565b6000600260008473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002060008373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054905092915050565b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff163373ffffffffffffffffffffffffffffffffffffffff16141515611a0557600080fd5b600073ffffffffffffffffffffffffffffffffffffffff168173ffffffffffffffffffffffffffffffffffffffff1614151515611a4157600080fd5b8073ffffffffffffffffffffffffffffffffffffffff16600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff167f8be0079c531659141344cd1fd0a4f28419497f9722a3daafe3b4186f6b6457e060405160405180910390a380600560006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff16021790555050565b6002600560146101000a81548160ff02191690836002811115611b2057fe5b021790555060006004541115611c0a57611ba5600454600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054610b1d90919063ffffffff16565b600080600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b600560009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166108fc3073ffffffffffffffffffffffffffffffffffffffff16319081150290604051600060405180830381858888f19350505050158015611c89573d6000803e3d6000fd5b505600a165627a7a723058205bbef016cc7699572f944871cb6f05e69915ada3a92a1d9f03a3fb434aac0c2b0029

Повече подробности за смарт договорите можете да намерите в статията: Какво представляват смарт договорите в Ethereum.

Заключение

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

• Транзакциите се извършват в доверителна среда;
• Наличието на такси от посредниците не влошава живота на участниците;
• Участниците нямат собственост, която може да бъде представена като цифрови активи;
• Няма разпределеност в цифровите активи, т.е. стойността притежава или осигурява само един участник.

Какво бъдеще очаква блокчейн? Сега можем само да предполагаме възможните пътища на развитие на блокчейн технологиите:

• Блокчейн ще стане толкова обичайна технология за бази данни, както например SQL или NoSQL за решаване на своя определен кръг задачи;
• Блокчейн ще стане широко разпространен протокол, подобно на HTTP за Интернет;
• Блокчейн ще стане основа за нова финансова и политическа система на планетата!

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

Това е само началото!

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