Въведение в смарт-контрактите

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

Обикновен контракт vs. смарт-контракт

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

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

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

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

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

Определение на смарт договора

В действителност, самата терминология е измислена от изследователя Nick Szabo и за първи път е приложена през 1994 година, а документирана е през 1997 година в статия, която описва самата идея на смарт договорите.

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

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

Прост пример — Escrow услуга

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

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

В случай на Биткойн може да се предостави възможност на купувача и продавача независимо един от друг да изберат медиатор. Има много хора, които се занимават с решаване на спорове. И нашите участници могат да изберат от общ списък медиатора, на когото едновременно ще се доверят. Заедно те създават multisignature адрес 2 от 3, където има три ключа и са необходими два подписа от произволни два ключа, за да се изразходват монетите от този адрес. Един ключ ще принадлежи на купувача, вторият — на онлайн магазина, а третият — на медиатора. И на този multisignature адрес купувачът ще изпрати сумата, необходима за плащането на монитора. Сега, когато продавачът вижда, че парите са блокирани за известно време на multisignature адреса, който зависи от него, той спокойно може да изпрати монитора по пощата.

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

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

Медиаторът има интерес да удовлетвори едновременно гнева на купувача и интересите на интернет магазина (по-късно ще стане ясно защо). Той съставя такава транзакция, в която монетите от multisignature адреса ще се използват в някаква пропорция между купувача, интернет магазина и медиатора, тъй като той взема част от сумата като награда за своята работа. Да предположим, че 90% от цялата сума ще отиде на продавача, 5% на медиатора и 5% като компенсация на купувача. Тази транзакция медиаторът подписва със своя ключ, но тя все още не може да бъде приложена, тъй като за това са нужни два подписа, а има само един. Такова транзакция той изпраща на купувача и на продавача. Ако поне един от тях бъде удовлетворен от този вариант за преразпределение на монетите, транзакцията ще бъде до-подписана и разпространена в мрежата. За нейната валидизация е достатъчно един от участниците в сделката да се съгласи с предложението на медиатора.

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

Пример с общежитие и хладилник

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

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

Те могат да използват escrow услуга, тоест да изберат медиатор, който да контролира изпълнението на сделката и да разрешава споровете, ако възникнат. След това, договорявайки се, те съставят смарт договор и записват в него определени условия.

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

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

Класификация на смарт-контрактите

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

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

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

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

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

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

Смарт контракти по среда на изпълнение

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

Като пример можем да вземем доставчици на мобилни услуги (различни мобилни оператори). Да предположим, че определен оператор води на своите сървъри централизирано отчитане на трафика, който може да се предава в различни формати, например: под формата на гласови обаждания, предаване на SMS, трафик от мобилен интернет и по различни стандарти, а също така води отчети за средства в балансите на потребителите. Според това, доставчикът на мобилни услуги може да съставя контракти за отчитане на предоставените услуги и тяхното заплащане с различни условия. В такъв случай лесно се задават условия от типа “изпрати SMS с такъв код на такъв номер и ще получиш такива условия за разпределение на трафика”.

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

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

Смарт договорите по начина на задаване и изпълнение на условията

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

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

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

Към произволните смарт контракти, които са изцяло по Тюринг, можем да отнесем платформата Ethereum и RootStock, която все още е в етап на разработка. Следователно, по-нататък ще се спрем по-подробно на платформата за смарт контракти Ethereum.

Смарт контракти по начин на иницииране

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

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

Акаунти в Ethereum

Типове акаунти на Ethereum

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

Акаунтът на потребителя се управлява само от личния ключ за електронен подпис. Собственикът на акаунта генерира своя чифт ключове за електронен подпис по алгоритъма ECDSA (Elliptic Curve Digital Signature Algorithm). Състоянието на този акаунт може да бъде променяно само от транзакции, подписани с този ключ.

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

Как се създават акаунти в Ethereum

В случай на акаунта на потребителя, собственикът самостоятелно генерира чифта ключове по ECDSA. Важно е да се отбележи, че Ethereum използва за електронно подписване точно същия алгоритъм и точно същата елиптична крива като Bitcoin, но адресът се изчислява по малко различен начин. Тук не се използва резултатът от двойно хеширане, както в Bitcoin, а е предвидено еднократно хеширане с функцията Keccak на дължина 256 бита. От получения резултат се отрязват по-малките битове, а именно 160 по-малките бита от изходното значение на хеш функцията. В крайна сметка получаваме адрес в Ethereum. Фактически той заема 20 байта.

Обратите внимание, че идентификатор на акаунта в Ethereum е кодирано в hex без прилагане на контрольна сума, за разлика от Bitcoin и много други системи, в които адресът е кодирано в числовата система с база 58 с добавяне на контрольна сума. Това означава, че трябва да се работи с идентификаторите на акаунти в Ethereum внимателно: дори една грешка в идентификатора гарантировано ще доведе до загуба на монети.

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

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

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

Структура на транзакцията Ethereum

За да стане по-ясно, ще преминем към разглеждане на структурата на транзакцията Ethereum и пример на код на смарт-контракт.

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

Следва такова поле, като gas price. Цената, по която базовата валута Ethereum се преобразува в gas, който се използва за плащане на изпълнението на смарт договора и разпределянето на ресурса на виртуалната машина, се посочва тук. Какво означава това?

При Биткойн таксите се плащат директно с основната валута — самия биткойн. Това е възможно благодарение на прост механизъм за тяхното изчисляване: плащаме строго на обема на данните, съдържащи се в транзакцията. В Ethereum ситуацията е по-сложна, тъй като е изключително трудно да се определи обемът на данните за транзакцията. Тук транзакцията може дори да съдържа код, който ще се изпълнява на виртуалната машина, а всяка операция на виртуалната машина може да има различна сложност. Има също операции, които выделят памет за променливи. Те ще имат своя собствена сложност, от която ще зависи плащането за всяка операция.

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

Има още една особеност на транзакцията в Ethereum: байт кодът, който тя съдържа за изпълнение на виртуалната машина, ще бъде изпълняван, докато не завърши с некотор резултат (успех-неуспех) или докато не свършат определеното количество монети, заделени за плащането на таксата. За да се избегне ситуация, при която от акаунта на подателя в случай на грешка се изразходват всички монети за такса (например, заради вечен цикъл, който е стартиран във виртуалната машина), съществува следното поле — start gas (често се нарича gas limit) — то определя максималния обем монети, които подателят е готов да похарчи за изпълнението на определена транзакция.

Следващото поле се нарича destination address. Тук се записва адресът на получателя на монетите или адресът на конкретен смарт договор, методите на който ще бъдат извиквани. След него следва поле, value, където се записва сумата на монетите, които се изпращат на destination address.

Следва поле с интересното име data, където се вписва цялата структура. Това не е отделно поле, а цяла структура, в която се определя кодът за виртуалната машина. Тук могат да се поставят произволни данни — за това съществуват отделни правила.

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

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

Сега нека разгледаме по-подробно най-простия смарт-контракт на примера.

contract Bank {
    address owner;
    mapping(address => uint) balances;
    
    function Bank() {
        owner = msg.sender;
    }

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint amount) public {
        if (balances[msg.sender] >= amount) {
            balances[msg.sender] -= amount;
            msg.sender.transfer(amount);
        }
    }

    function getMyBalance() public view returns(uint) {
        return balances[msg.sender];
    }

    function kill() public {
        if (msg.sender == owner)
            selfdestruct(owner);
    }
}

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

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

Нека преминем през всяка линия на изходния код. В този контракт има константни полета. Едно от тях, с тип address, се нарича owner. Тук контрактът запомня адреса на потребителя, създател на този смарт-контракт. След това има динамична структура, която запазва съответствията между адресите на потребителите и балансите.

След това следва метод Bank — той се нарича така, както и контрактът. Съответно, това е неговият конструктор. Тук се извършва присвояване на променливата owner на адреса на онзи, който е публикувал този смарт-контракт в мрежата. Това е единственото, което се случва в този конструктор. Тоест msg в този случай — това са именно онези данни, които са били предадени на виртуалната машина заедно с транзакцията, съдържаща целия код на този контракт. Съответно, msg.sender — това е авторът на тази транзакция, която публикува този код. Той ще бъде собственикът на смарт-контракта.

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

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

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

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

Как работи пълен възел на мрежата Ethereum?

Нека разгледаме схемата, как се извършват такива смарт-контрактни операции на платформата Ethereum и как работи пълен възел на мрежата.

Пълният възел на мрежата Ethereum поне трябва да има четири модула.
Първият, както е при всякакъв децентрализиран протокол, е модул за P2P мрежа — модул за свързване и работа с други възли, където става обмен на блокове, транзакции и информация за други възли. Това е традиционен компонент за всички децентрализирани криптовалути.

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

Третият модул се нарича EVM (Ethereum виртуална машина) — това е виртуална машина, която приема байт-код от Ethereum транзакция. Този модул приема текущото състояние на определен акаунт и извършва промени в неговото състояние на базата на получения байт-код. Версията на виртуалната машина на всеки от възлите в мрежата трябва да бъде еднаква. Изчисленията на всеки от възлите на Ethereum се извършват абсолютно идентично, но те се случват асинхронно: някой по-напред проверява и приема тази транзакция, т.е. изпълнява целия код, съдържащ се в нея, а някой по-късно. Съответно, при създаването на транзакцията, тя се разпространява в мрежата, възлите я приемат и в момента на верификация точно така, както в Bitcoin се изпълнява Bitcoin Script, тук се изпълнява байт-кодът на виртуалната машина.

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

Митове и ограничения на смарт-контрактите

Що се отнася до ограниченията, които съществуват за платформи за смарт-контракти, подобни на Ethereum, могат да се посочат следните:

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

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

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

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

Недостатъци на Ethereum

Нека да изброим основните от тях. Първият недостатък е, че съществуват някои затруднения при проектирането, разработването и тестването на смарт-контрактите в Ethereum (в Ethereum за написването на смарт-контракти се използва езикът Solidity). Всъщност, практиката показва, че много голям процент от всички грешки принадлежат на човешкия фактор. Това е валидно и за вече написаните смарт-контракти в Ethereum, които имат средна или по-висока трудност. Ако за простите смарт-контракти вероятността за грешка е малка, то в сложните смарт-контракти много често се срещат грешки, които водят до кражба на средства, замразяване на средства, унищожаване на смарт-контракти по непредвидим начин и т.н. Вече има много известни случаи на такива инциденти.

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

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

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

Що се отнася до Ethereum, са проведени много изследвания и е получен голям практически опит: както положителен, така и отрицателен, но, въпреки това, остават сложности и уязвимости, с които все още предстои да се борим.

И така, тематичната част на статията приключи, да преминем към въпросите, които възникват доста често.

Често задавани въпроси

— Ако всички страни на действащия смарт-контракт искат да променят условията, могат ли да анулират този смарт-контракт с помощта на мултиподпис и след това да създадат нов смарт-контракт с обновените условия за изпълнението му?

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

— А какво ако медиаторът се споразумее с едната от страните участници: escrow или смарт-контракта? Задължителен ли е медиаторът в смарт-контракта?

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

— Възможно ли е с една транзакция на Ethereum да се прехвърлят много различни токени от своя адрес на различни целеви адреси, например на бордови адреси, където се търгуват тези токени?

Това е добър въпрос и засяга модела на транзакциите в Ethereum и неговите разлики от модела на Bitcoin. И разликата е съществена. Ако в модела на транзакциите в Ethereum просто прехвърляте монети, те се прехвърлят само от един адрес на друг, без връщане, просто конкретна сума, която вие посочите. С други думи, това не е модел на непреработени изходи (UTXO), а модел на акаунти и съответстващи баланси. Теоретично, може да се изпрати с една транзакция няколко различни токена, ако напишите сложен смарт договор, но все пак ще трябва да извършите много транзакции, да създадете договора, след това да му предадете токени и монети и след това да извикате съответния метод. Това изисква усилия и време, съответно, на практика така не работи и всички плащания в Ethereum се извършват с отделни транзакции.

— Един от митовете за платформата Ethereum е, че е невъзможно да се опишат условия, които да зависят от данни от външен интернет ресурс, какво да правим тогава?

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

Темата е посветена на една от лекциите на онлайн курса по Blockchain — “Въведение в смарт-контрактите".

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