В тази статия ще разгледаме какво представляват интелигентните договори, какви са те, ще се запознаем с различните платформи за интелигентни договори, техните характеристики, а също така ще обсъдим как работят и какви предимства могат да донесат. Този материал ще бъде много полезен за читатели, които не са добре запознати с темата за интелигентните договори, но искат да се доближат до разбирането й.
Редовен договор срещу. интелигентен договор
Преди да се задълбочим в подробностите, нека вземем пример за разликите между обикновен договор, който е посочен на хартия, и интелигентен договор, който е представен цифрово.
Как работеше това преди появата на интелигентните договори? Представете си група хора, които искат да установят определени правила и условия за разпределение на ценностите, както и определен механизъм, който да гарантира осъществяването на това разпределение според дадените правила и условия. След това се събираха, съставяха лист, на който записваха своите идентификационни данни, условията, включените стойности, поставяха дата и ги подписваха. Този договор също беше заверен от доверена страна, като нотариус. По-нататък тези хора тръгнаха в различни посоки със своето хартиено копие на такъв договор и започнаха да извършват някакви действия, които може и да не отговарят на самия договор, тоест те направиха едно нещо, но на хартия беше удостоверено, че трябва да направят нещо напълно различни. И как да се излезе от тази ситуация? Всъщност един от членовете на групата трябва да вземе този документ, да вземе някои доказателства, да ги отнесе до съда и да постигне съответствие между договора и действителните действия. Доста често е трудно да се постигне справедливо изпълнение на този договор, което води до неприятни последици.
Какво може да се каже за интелигентните договори? Те съчетават както възможността за изписване на условията на договора, така и механизма за стриктното им изпълнение. Ако условията са зададени и съответната транзакция или заявка е подписана, след като тази заявка или транзакция бъде приета, вече не е възможно да промените условията или да повлияете на тяхното изпълнение.
Има един валидатор или цяла мрежа, както и база данни, която съхранява всички интелигентни договори, които са били изпратени за изпълнение в строг хронологичен ред. Също така е важно тази база данни да съдържа всички задействащи условия за изпълнение на интелигентния договор. Освен това трябва да вземе предвид самата стойност, чието разпределение е описано в договора. Ако това се отнася за някаква цифрова валута, тогава тази база данни трябва да го вземе предвид.
С други думи, валидаторите на интелигентни договори трябва да имат достъп до всички данни, с които оперира интелигентният договор. Например, една база данни трябва да се използва за едновременно отчитане на цифрови валути, потребителски баланси, потребителски транзакции и времеви отпечатъци. След това, в интелигентен договор, условието може да бъде балансът на потребителя в определена валута, пристигането на определен час или фактът, че определена транзакция е извършена, но нищо повече.
Дефиниция на интелигентен договор
Като цяло самата терминология е измислена от изследователя Ник Сабо и е използвана за първи път през 1994 г. и е документирана през 1997 г. в статия, която описва самата идея за интелигентни договори.
Интелигентните договори предполагат, че се извършва известна автоматизация на разпределението на стойността, което може да зависи само от онези условия, които са предварително определени. В най-простия си вид изглежда като договор със строго определени условия, който се подписва от определени страни.
Интелигентните договори са предназначени да сведат до минимум доверието в трети страни. Понякога центърът за вземане на решения, от който зависи всичко, е напълно изключен. Освен това такива договори са по-лесни за одит. Това е следствие от някои конструктивни характеристики на такава система, но най-често разбираме под интелигентен договор децентрализирана среда и наличието на функции, които позволяват на всеки да анализира базата данни и да извърши пълен одит на изпълнението на договорите. Това гарантира защита срещу промени в данните със задна дата, които биха довели до промени в изпълнението на самия договор. Дигитализацията на повечето процеси при създаване и стартиране на интелигентен договор често опростява технологията и разходите за тяхното изпълнение.
Прост пример - Escrow услуга
Нека да разгледаме един много прост пример. Това ще ви помогне да се доближите до разбирането на функционалността на интелигентните договори, както и да разберете по-добре в кои случаи трябва да се използват.
Може да се реализира и с помощта на биткойн, въпреки че в момента биткойн все още трудно може да се нарече пълноценна платформа за интелигентни договори. И така, имаме купувач и имаме онлайн магазин. Клиент иска да закупи монитор от този магазин. В най-простия случай купувачът попълва и изпраща плащане, а онлайн магазинът го приема, потвърждава и след това изпраща стоките. В тази ситуация обаче има нужда от голямо доверие - купувачът трябва да се довери на онлайн магазина за цялата цена на монитора. Тъй като онлайн магазинът може да има ниска репутация в очите на купувача, съществува риск по някаква причина след приемане на плащането магазинът да откаже услугата и да не изпрати стоките на купувача. Следователно купувачът задава въпроса (и съответно онлайн магазинът задава този въпрос) какво може да се приложи в този случай, за да се сведат до минимум подобни рискове и да се направят подобни транзакции по-надеждни.
В случая с биткойн е възможно да се позволи на купувача и продавача да избират независимо посредник. Има много хора, които участват в разрешаването на спорни въпроси. А нашите участници могат да изберат от общ списък с медиатори този, на когото ще се доверят. Заедно те създават 2 от 3 адреса с множество подписи, където има три ключа и са необходими два подписа с всеки два ключа, за да харчите монети от този адрес. Единият ключ ще принадлежи на купувача, вторият на онлайн магазина, а третият на посредника. И на такъв адрес с множество подписи купувачът ще изпрати сумата, необходима за плащане на монитора. Сега, когато продавачът види, че парите са блокирани за известно време на адрес с множество подписи, който зависи от него, той може безопасно да изпрати монитора по пощата.
След това купувачът получава пратката, проверява стоките и взема решение за окончателната покупка. Той може напълно да се съгласи с предоставената услуга и да подпише транзакцията с ключа си, където прехвърля монети от адреса с мултиподпис към продавача, или може да е недоволен от нещо. Във втория случай той се свързва с посредник, за да състави алтернативна транзакция, която ще разпредели тези монети по различен начин.
Да кажем, че мониторът пристигна малко надраскан и в комплекта не беше включен кабел за свързване към компютъра, въпреки че в сайта на онлайн магазина пишеше, че кабелът трябва да бъде включен в комплекта. След това купувачът събира необходимите доказателства, за да докаже на посредника, че е бил измамен в тази ситуация: той прави екранни снимки на сайта, прави снимка на разписката, прави снимка на драскотините на монитора и показва, че печатът е бил счупен и кабелът беше изваден. Онлайн магазинът от своя страна събира своите доказателства и ги предава на посредника.
Посредникът е заинтересован едновременно да задоволи както възмущението на купувача, така и интересите на онлайн магазина (по-късно ще стане ясно защо). Това представлява транзакция, при която монети от адрес с множество подписи ще бъдат изразходвани в някаква пропорция между купувача, онлайн магазина и посредника, тъй като той взема част за себе си като награда за работата си. Да кажем, че 90% от общата сума отива за продавача, 5% за посредника и 5% обезщетение за купувача. Посредникът подписва тази сделка със своя ключ, но тя все още не може да бъде приложена, защото изисква два подписа, но само един си струва. Той изпраща такава транзакция както на купувача, така и на продавача. Ако поне един от тях е доволен от тази опция за преразпределяне на монети, транзакцията ще бъде предварително подписана и разпространена в мрежата. За валидирането й е достатъчно една от страните по сделката да се съгласи с опцията на посредника.
Важно е първоначално да изберете медиатор, така че и двамата участници да му имат доверие. В този случай той ще действа независимо от интересите на единия или другия и ще оцени обективно ситуацията. Ако посредникът не предостави опция за разпространение на монети, която да удовлетвори поне един участник, тогава, след като се договорят заедно, както купувачът, така и онлайн магазинът могат да изпратят монетите на нов адрес с множество подписи, като поставят двата си подписа. Новият адрес с множество подписи ще бъде компилиран с различен посредник, който може да е по-компетентен по въпроса и да предостави по-добра опция.
Пример със спално помещение и хладилник
Нека да разгледаме един по-сложен пример, който показва по-ясно възможностите на интелигентен договор.
Да кажем, че има трима момчета, които наскоро са се преместили в една и съща стая в общежитието. Тримата се интересуват от закупуване на хладилник за стаята си, който да ползват заедно. Един от тях доброволно събра необходимата сума за закупуване на хладилник и преговори с продавача. Те обаче се запознаха едва наскоро и между тях няма достатъчно доверие. Очевидно двама от тях рискуват, като дават пари на третия. Освен това те трябва да постигнат споразумение при избора на продавач.
Те могат да използват услугата ескроу, тоест да изберат посредник, който да следи изпълнението на сделката и да разрешава спорни въпроси, ако възникнат такива. След това, след като се съгласиха, те съставят интелигентен договор и предписват определени условия в него.
Първото условие е, че преди определено време, да речем в рамките на една седмица, съответният акаунт за интелигентен договор трябва да получи три плащания от определени адреси за определена сума. Ако това не се случи, интелигентният договор спира да се изпълнява и връща монетите на всички участници. Ако условието е изпълнено, тогава се задават стойностите на идентификаторите на продавача и посредника и се проверява условието, че всички участници са съгласни с избора на продавача и посредника. Когато всички условия са изпълнени, средствата ще бъдат преведени на посочените адреси. Този подход може да защити участниците от измами от всяка страна и като цяло елиминира необходимостта от доверие.
Виждаме в този пример самия принцип, че тази възможност за стъпка по стъпка задаване на параметри за изпълнение на всяко условие ви позволява да създавате системи с всякаква сложност и дълбочина на вложени нива. Освен това можете първо да дефинирате първото условие в интелигентния договор и едва след неговото изпълнение можете да зададете параметри за следващото условие. С други думи, условието е формално написано и параметрите за него могат да бъдат зададени още по време на работата му.
Класификация на интелигентните договори
За класификация можете да зададете различни групи критерии. Но в момента на развитие на технологиите четири от тях са актуални.
Интелигентните договори могат да бъдат разграничени от тяхната среда за изпълнение, която може да бъде централизирана или децентрализирана. В случай на децентрализация имаме много по-голяма независимост и толерантност към грешки при изпълнение на интелигентни договори.
Те могат да бъдат разграничени и от процеса на задаване и изпълнение на условия: могат да бъдат свободно програмируеми, ограничени или предварително дефинирани, т.е. строго типизирани. Когато има само 4 конкретни интелигентни договора на платформата за интелигентни договори, параметрите за тях могат да бъдат зададени по всякакъв начин. Съответно настройката им е много по-проста: избираме договор от списъка и предаваме параметрите.
Според метода на иницииране има автоматизирани интелигентни договори, тоест когато възникнат определени условия, те се изпълняват сами, и има договори, в които условията са посочени, но платформата не проверява автоматично тяхното изпълнение, за това те трябва да се започне отделно.
Освен това интелигентните договори се различават по нивото си на поверителност. Те могат да бъдат напълно открити, частично или напълно поверителни. Последното означава, че наблюдателите от трети страни не виждат условията на интелигентните договори. Темата за поверителността обаче е много обширна и е по-добре да я разгледаме отделно от настоящата статия.
По-долу ще разгледаме по-отблизо първите три критерия, за да внесем повече яснота в разбирането на настоящата тема.
Интелигентни договори по време на изпълнение
Въз основа на средата за изпълнение се прави разлика между централизирани и децентрализирани платформи за интелигентни договори. В случай на централизирани цифрови договори се използва една услуга, където има само един валидатор и може да има услуга за архивиране и възстановяване, която също се управлява централно. Има една база данни, която съхранява цялата необходима информация за определяне на условията на интелигентния договор и разпределяне на стойността, която се взема предвид в тази същата услуга база данни. Такава централизирана услуга има клиент, който поставя условия с определени заявки и използва такива договори. Поради централизирания характер на платформата, механизмите за удостоверяване може да са по-малко сигурни, отколкото при криптовалутите.
Като пример можем да вземем доставчиците на мобилни комуникации (различни мобилни оператори). Да приемем, че даден оператор поддържа централизиран запис на трафика на своите сървъри, който може да се предава в различни формати, например: под формата на гласови повиквания, предаване на SMS, мобилен интернет трафик и според различни стандарти, а също така поддържа записи средства по потребителски баланси. Съответно доставчикът на мобилни комуникации може да изготви договори за отчитане на предоставените услуги и тяхното плащане с различни условия. В този случай е лесно да зададете условия като „изпратете SMS с такъв и такъв код на такъв и такъв номер и ще получите такива и такива условия за разпределение на трафика“.
Може да се даде още един пример: традиционните банки с разширена функционалност на интернет банкирането и много прости договори като редовни плащания, автоматично конвертиране на входящи плащания, автоматично приспадане на лихва към определена сметка и т.н.
Ако говорим за интелигентни договори с децентрализирана среда за изпълнение, тогава имаме група валидатори. В идеалния случай всеки може да стане валидатор. Благодарение на протокола за синхронизиране на базата данни и постигането на консенсус, имаме обща база данни, която вече ще съхранява всички транзакции със строго описани договори, а не някакви условни заявки, чиито формати често се променят и няма отворена спецификация. Тук транзакциите ще съдържат инструкции за изпълнение на договора съгласно строга спецификация. Тази спецификация е отворена и следователно самите потребители на платформата могат да проверяват и валидират интелигентни договори. Тук виждаме, че децентрализираните платформи превъзхождат централизираните по отношение на независимост и устойчивост на грешки, но техният дизайн и поддръжка са много по-сложни.
Интелигентни договори по метода на задаване и изпълнение на условия
Сега нека разгледаме по-отблизо как интелигентните договори могат да се различават по начина, по който задават и изпълняват условия. Тук насочваме вниманието си към интелигентни договори, които са произволно програмируеми и завършени по Тюринг. Интелигентен договор, пълен с Turing, ви позволява да зададете почти всякакви алгоритми като условия за изпълнение на договора: цикли на запис, някои функции за изчисляване на вероятности и други подобни - чак до вашите собствени алгоритми за електронен подпис. В този случай имаме предвид наистина произволно писане на логика.
Има и произволни интелигентни договори, но не и пълни такива на Тюринг. Това включва Bitcoin и Litecoin със собствен скрипт. Това означава, че можете да използвате само определени операции в произволен ред, но вече не можете да пишете цикли и свои собствени алгоритми.
Освен това има платформи за интелигентни договори, които прилагат предварително дефинирани интелигентни договори. Те включват Bitshares и Steemit. Bitshares има набор от интелигентни договори за търговия, управление на акаунти, управление на самата платформа и нейните параметри. Steemit е подобна платформа, но вече не е фокусирана върху издаването на токени и търговията, като Bitshares, а върху блоговете, т.е. съхранява и обработва съдържание по децентрализиран начин.
Произволните пълни договори на Turing включват платформата Ethereum и RootStock, която все още е в процес на разработка. Затова по-долу ще се спрем малко по-подробно на платформата за смарт договори Ethereum.
Интелигентни договори по метод на иницииране
Въз основа на метода на иницииране интелигентните договори също могат да бъдат разделени на поне две групи: автоматизирани и ръчни (неавтоматизирани). Автоматизираните се характеризират с факта, че при всички известни параметри и условия интелигентният договор се изпълнява напълно автоматично, т.е. не изисква изпращане на допълнителни транзакции и изразходване на допълнителна комисионна за всяко следващо изпълнение. Самата платформа разполага с всички данни, за да изчисли как ще завърши интелигентният договор. Логиката там не е произволна, а предопределена и всичко това е предвидимо. Тоест можете предварително да оцените сложността на изпълнението на интелигентен договор, да използвате някаква постоянна комисионна за него и всички процеси за неговото изпълнение са по-ефективни.
За интелигентни договори, които са свободно програмирани, изпълнението не е автоматизирано. За да инициирате такъв интелигентен договор, на практика на всяка стъпка трябва да създадете нова транзакция, която да извика следващия етап на изпълнение или следващия метод на интелигентен договор, да платите съответната комисионна и да изчакате транзакцията да бъде потвърдена. Изпълнението може да завърши успешно или не, тъй като кодът на интелигентния договор е произволен и могат да се появят някои непредвидими моменти, като вечен цикъл, липса на някои параметри и аргументи, необработени изключения и т.н.
Акаунти в Ethereum
Типове акаунти в Ethereum
Нека да разгледаме какви видове сметки може да има в платформата Ethereum. Тук има само два вида акаунти и няма други опции. Първият тип се нарича потребителски акаунт, вторият е договорен акаунт. Нека да разберем как се различават.
Потребителският акаунт се контролира само от персоналния ключ на електронния подпис. Собственикът на акаунта генерира собствена двойка ключове за електронен подпис, използвайки алгоритъма ECDSA (Algorithm за цифров подпис с елиптична крива). Само транзакции, подписани с този ключ, могат да променят състоянието на този акаунт.
За сметката на интелигентния договор е предоставена отделна логика. Той може да се контролира само от предварително дефиниран софтуерен код, който напълно определя поведението на интелигентния договор: как ще управлява своите монети при определени обстоятелства, по инициатива на кой потребител и при какви допълнителни условия тези монети ще бъдат разпределени. Ако някои точки не са предвидени от разработчиците в програмния код, могат да възникнат проблеми. Например интелигентен договор може да получи определено състояние, в което не приема иницииране на по-нататъшно изпълнение от никой от потребителите. В този случай монетите всъщност ще бъдат замразени, тъй като интелигентният договор не предвижда излизане от това състояние.
Как се създават акаунти в Ethereum
В случай на потребителски акаунт, собственикът самостоятелно генерира двойка ключове, използвайки ECDSA. Важно е да се отбележи, че Ethereum използва точно същия алгоритъм и точно същата елиптична крива за електронни подписи като Bitcoin, но адресът се изчислява по малко по-различен начин. Тук резултатът от двойното хеширане вече не се използва, както в биткойн, но се предоставя единично хеширане с функцията Keccak с дължина от 256 бита. Най-малко значимите битове се отрязват от получената стойност, а именно най-малко значимите 160 бита от изходната хеш стойност. В резултат на това получаваме адрес в Ethereum. Всъщност той заема 20 байта.
Моля, имайте предвид, че идентификаторът на акаунта в Ethereum е кодиран в шестнадесетичен без прилагане на контролна сума, за разлика от биткойн и много други системи, където адресът е кодиран в базова 58 числова система с добавяне на контролна сума. Това означава, че трябва да внимавате, когато работите с идентификатори на акаунти в Ethereum: дори една грешка в идентификатора гарантирано ще доведе до загуба на монети.
Има една важна особеност и тя е, че потребителски акаунт на ниво обща база данни се създава в момента, в който той приеме първото входящо плащане.
Създаването на интелигентен договорен акаунт изисква напълно различен подход. Първоначално един от потребителите пише изходния код на интелигентния договор, след което кодът преминава през компилатор, специален за платформата Ethereum, получавайки байт код за собствената си виртуална машина Ethereum. Полученият байт код се поставя в специално поле на транзакцията. Удостоверява се от името на сметката на инициатора. След това тази транзакция се разпространява в цялата мрежа и поставя кода на интелигентния договор. Комисионната за транзакцията и съответно за изпълнението на договора се тегли от баланса на сметката на инициатора.
Всеки интелигентен договор задължително съдържа свой собствен конструктор (на този договор). Може да е празен или да има съдържание. След като конструкторът се изпълни, се създава идентификатор на интелигентен договор, чрез който можете да изпращате монети, да извиквате определени методи на интелигентен договор и т.н.
Структура на транзакцията на Ethereum
За да стане по-ясно, ще започнем да разглеждаме структурата на транзакция в Ethereum и примерен код на интелигентен договор.
Транзакцията на Ethereum се състои от няколко полета. Първият от тях, nonce, е определен сериен номер на транзакцията спрямо самия акаунт, който я разпространява и е неин автор. Това е необходимо, за да се разграничат двойните транзакции, тоест да се изключи случаят, когато една и съща транзакция се приема два пъти. Чрез използването на идентификатор всяка транзакция има уникална хеш стойност.
Следва поле като цена на газа. Това показва цената, на която базовата валута Ethereum се конвертира в газ, който се използва за плащане за изпълнението на интелигентния договор и разпределението на ресурса на виртуалната машина. Какво означава?
В биткойн таксите се плащат директно от основната валута - самия биткойн. Това е възможно благодарение на прост механизъм за тяхното изчисляване: ние плащаме стриктно за количеството данни, съдържащи се в транзакцията. В Ethereum ситуацията е по-сложна, защото е много трудно да се разчита на обема на данните за транзакциите. Тук транзакцията може да съдържа и програмен код, който ще бъде изпълнен на виртуалната машина, като всяка операция на виртуалната машина може да има различна сложност. Има и операции, които разпределят памет за променливи. Те ще имат своя собствена сложност, от която ще зависи плащането за всяка операция.
Цената на всяка операция в газов еквивалент ще бъде постоянна. Въвежда се специално с цел определяне на постоянната цена на всяка операция. В зависимост от натоварването на мрежата цената на газа ще се промени, тоест коефициентът, според който основната валута ще бъде преобразувана в тази спомагателна единица за плащане на комисионната.
Има още една характеристика на транзакция в Ethereum: байт кодът, който тя съдържа за изпълнение във виртуална машина, ще бъде изпълнен, докато не завърши с някакъв резултат (успех или неуспех) или докато определено количество монети, разпределени за плащане на комисионна, изтече . За да се избегне ситуация, при която в случай на грешка всички монети от сметката на подателя са изразходвани за комисионна (например някакъв вид вечен цикъл, стартиран във виртуална машина), съществува следното поле - стартирайте газ (често наричан газов лимит) - той определя максималното количество монети, които подателят е готов да похарчи, за да завърши определена транзакция.
Извиква се следващото поле адрес на дестинацията. Това включва адреса на получателя на монетите или адреса на конкретен интелигентен договор, чиито методи ще бъдат извикани. След него идва полето стойност, където се въвежда количеството монети, които се изпращат до адреса на местоназначение.
Следва едно интересно поле, наречено данни, където се побира цялата конструкция. Това не е отделно поле, а цяла структура, в която се дефинира кодът на виртуалната машина. Можете да поставите произволни данни тук - има отделни правила за това.
И последното поле се извиква подпис. Той едновременно съдържа както електронния подпис на автора на тази транзакция, така и публичния ключ, с който този подпис ще бъде проверен. От публичния ключ можете да получите идентификатора на акаунта на подателя на тази транзакция, тоест да идентифицирате уникално акаунта на подателя в самата система. Разбрахме основното за структурата на сделката.
Примерен код на интелигентен договор за 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);
}
}По-горе е опростен изходен код, който може да съхранява монети на потребителите и да ги връща при поискване.
И така, има интелигентен договор на банката, който изпълнява следните функции: натрупва монети в баланса си, т.е. когато се потвърди транзакция и се постави такъв интелигентен договор, се създава нов акаунт, който може да съдържа монети в баланса си; запомня потребителите и разпределението на монетите между тях; има няколко метода за управление на баланси, т.е. възможно е попълване, теглене и проверка на баланса на потребителя.
Нека да преминем през всеки ред от изходния код. Този договор има постоянни полета. Един от тях, с тип адрес, се нарича собственик. Тук договорът помни адреса на потребителя, създал този интелигентен договор. Освен това има динамична структура, която поддържа съответствие между потребителските адреси и балансите.
Следва Банковият метод - има същото име като договора. Съответно това е неговият конструктор. Тук на променливата собственик се присвоява адресът на лицето, което е поставило този интелигентен договор в мрежата. Това е единственото нещо, което се случва в този конструктор. Тоест, msg в този случай са точно данните, които са прехвърлени към виртуалната машина заедно с транзакцията, съдържаща целия код на този договор. Съответно msg.sender е авторът на тази транзакция, която хоства този код. Той ще бъде собственик на интелигентния договор.
Методът на депозит ви позволява да прехвърлите определен брой монети в договорната сметка чрез транзакция. В този случай интелигентният договор, получавайки тези монети, ги оставя в баланса си, но записва в структурата на балансите кой точно е бил изпращачът на тези монети, за да се знае на кого принадлежат.
Следващият метод се нарича теглене и взема един параметър - количеството монети, които някой иска да изтегли от тази банка. Това проверява дали има достатъчно монети в баланса на потребителя, който извиква този метод, за да ги изпрати. Ако има достатъчно от тях, тогава самият интелигентен договор връща този брой монети на повикващия.
Следва методът за проверка на текущия баланс на потребителя. Който извика този метод, ще бъде използван за извличане на този баланс в интелигентния договор. Струва си да се отбележи, че модификаторът на този метод е изглед. Това означава, че самият метод не променя променливите от своя клас по никакъв начин и всъщност е само метод за четене. Не се създава отделна транзакция за извикване на този метод, не се заплаща такса и всички изчисления се извършват локално, след което потребителят получава резултата.
Методът kill е необходим, за да се унищожи състоянието на интелигентния договор. И тук има допълнителна проверка дали извикващият този метод е собственик на този договор. Ако е така, тогава договорът се самоунищожава и функцията за унищожаване приема един параметър - идентификатора на акаунта, към който договорът ще изпрати всички монети, останали в неговия баланс. В този случай останалите монети автоматично ще отидат на адреса на собственика на договора.
Как работи пълен възел в мрежата Ethereum?
Нека да разгледаме схематично как се изпълняват такива интелигентни договори на платформата Ethereum и как работи пълен мрежов възел.
Един пълен възел в мрежата на Ethereum трябва да има поне четири модула.
Първият, както при всеки децентрализиран протокол, е P2P networking module - модул за мрежова връзка и работа с други възли, където се обменят блокове, транзакции и информация за други възли. Това е традиционен компонент за всички децентрализирани криптовалути.
След това имаме модул за съхраняване на блокчейн данни, обработка, избор на приоритетен клон, добавяне на блокове, премахване на връзките на блокове, валидиране на тези блокове и т.н.
Третият модул се нарича EVM (виртуална машина на Ethereum) - това е виртуална машина, който получава байткод от транзакция в Ethereum. Този модул получава текущото състояние на конкретен акаунт и извършва промени в състоянието въз основа на получения байткод. Версията на виртуалната машина на всеки мрежов възел трябва да бъде идентична. Изчисленията, извършвани на всеки възел в Ethereum, са идентични, но се случват асинхронно: някои първо проверяват и приемат транзакцията, изпълнявайки целия код, съдържащ се в нея, докато други го правят по-късно. Съответно, когато се създаде транзакция, тя се разпространява в мрежата, възлите я приемат и в момента на проверката, точно както се изпълнява Bitcoin Script в Bitcoin, байткодът на виртуалната машина се изпълнява тук.
Транзакцията се счита за верифицирана, ако целият код, който се съдържа в нея, е изпълнен, ново състояние на определен акаунт е генерирано и запазено, докато стане ясно дали тази транзакция е приложена или не. Ако транзакцията е приложена, тогава това състояние се счита не само за завършено, но и за текущо. Има база данни, която съхранява състоянието на всеки акаунт за всеки мрежов възел. Поради факта, че всички изчисления се извършват по един и същи начин и състоянието на блокчейна е едно и също, базата данни, съдържаща състоянията на всички акаунти, също ще бъде една и съща за всеки възел.
Митове и ограничения на интелигентните договори
Що се отнася до ограниченията, които съществуват за платформи за интелигентни договори, подобни на Ethereum, може да се цитира следното:
- изпълнение на код;
- разпределете памет;
- блокчейн данни;
- изпращане на плащания;
- създаване на нов договор;
- обадете се на други договори.
Нека да разгледаме ограниченията, които се налагат на виртуална машина, и съответно да разсеем някои митове за интелигентните договори. На виртуална машина, която може да бъде не само в Ethereum, но и в подобни платформи, можете да извършвате наистина произволни логически операции, тоест да пишете код и той ще бъде изпълнен там, можете допълнително да разпределите памет. Таксата обаче се заплаща отделно за всяка операция и за всяка допълнителна разпределена единица памет.
След това виртуалната машина може да чете данни от блокчейн базата данни, за да използва тези данни като тригер за изпълнение на една или друга логика на интелигентен договор. Виртуалната машина може да създава и изпраща транзакции, може да създава нови договори и да извиква методи на други смарт договори, които вече са публикувани в мрежата: съществуващи, налични и т.н.
Най-често срещаният мит е, че интелигентните договори на Ethereum могат да използват информация от всеки интернет ресурс в техните условия. Истината е, че една виртуална машина не може да изпрати мрежова заявка до някакъв външен информационен ресурс в Интернет, тоест невъзможно е да се напише интелигентен договор, който да разпределя стойност между потребителите в зависимост, да кажем, какво е времето навън, или кой е спечелил някакво първенство, или въз основа на какъв друг инцидент се е случил във външния свят, защото информацията за тези инциденти просто не е в базата данни на самата платформа. Тоест, в блокчейна няма нищо за това. Ако не се появи там, тогава виртуалната машина не може да използва тези данни като тригери.
Недостатъци на Ethereum
Нека изброим основните. Първият недостатък е, че има някои трудности при проектирането, разработването и тестването на интелигентни договори в Ethereum (Ethereum използва езика Solidity за писане на интелигентни договори). Всъщност практиката показва, че много голям процент от всички грешки са на човешкия фактор. Това всъщност е вярно за вече написани смарт договори на Ethereum, които имат средна или по-висока сложност. Ако за обикновените интелигентни договори вероятността от грешка е малка, то при сложните интелигентни договори много често има грешки, които водят до кражба на средства, тяхното замразяване, унищожаване на интелигентни договори по неочакван начин и т.н. Много такива случаи вече са известен.
Вторият недостатък е, че самата виртуална машина не е перфектна, тъй като тя също е написана от хора. Той може да изпълнява произволни команди и в това се крие уязвимостта: редица команди могат да бъдат конфигурирани по определен начин, който ще доведе до последствия, които са били непредвидени предварително. Това е много сложна област, но вече има няколко проучвания, които показват, че тези уязвимости съществуват в текущата версия на мрежата Ethereum и могат да доведат до провал на много интелигентни договори.
Друга голяма трудност, може да се счита за недостатък. Той се крие във факта, че можете практически или технически да стигнете до заключението, че ако компилирате байт кода на договор, който ще бъде изпълнен на виртуална машина, можете да определите някакъв специфичен ред на операциите. Когато се изпълняват заедно, тези операции ще натоварят значително виртуалната машина и ще я забавят непропорционално на таксата, която е била платена за извършването на тези операции.
В миналото вече имаше период в развитието на Ethereum, когато много момчета, които разбираха в детайли работата на виртуална машина, откриха такива уязвимости. Всъщност транзакциите плащат много малка такса, но на практика забавят цялата мрежа. Тези проблеми са много трудни за решаване, тъй като е необходимо, първо, да се определят, второ, да се коригира цената за извършване на тези операции и, трето, да се извърши хард форк, което означава актуализиране на всички мрежови възли до нова версия на софтуера и след това едновременно активиране на тези промени.
Що се отнася до Ethereum, бяха проведени много изследвания, натрупан е много практически опит: както положителен, така и отрицателен, но въпреки това остават трудности и уязвимости, които все още трябва да бъдат решени по някакъв начин.
И така, тематичната част на статията е завършена, нека да преминем към въпроси, които възникват доста често.
Часто задаваемые вопросы
— Ако всички страни по съществуващ интелигентен договор искат да променят условията, могат ли да анулират този интелигентен договор с помощта на multisig и след това да създадат нов интелигентен договор с актуализирани условия за неговото изпълнение?
Отговорът тук ще бъде двоен. Защо? Защото, от една страна, интелигентният договор се дефинира веднъж и вече не предполага никакви промени, а от друга страна, той може да има предварително написана логика, която предвижда пълна или частична промяна на някои условия. Тоест, ако искате да промените нещо във вашия интелигентен договор, тогава трябва да предпишете условията, при които можете да актуализирате тези условия. Съответно само по такъв разумен начин може да се организира подновяването на договора. Но и тук можете да се сблъскате с проблеми: направете грешка и ще получите съответната уязвимост. Следователно такива неща трябва да бъдат много детайлни и внимателно проектирани и тествани.
— Ами ако посредникът сключи споразумение с една от участващите страни: ескроу или интелигентен договор? Изисква ли се посредник в интелигентен договор?
При интелигентен договор не се изисква посредник. Може и да не съществува. Ако в случай на ескроу медиаторът влезе в заговор с една от страните, тогава да, тогава тази схема рязко губи цялата си стойност. Следователно медиаторите се подбират по такъв начин, че да се ползват с доверие от всички страни, участващи в този процес едновременно. Съответно, вие просто няма да прехвърлите монети на адрес с множество подписи с посредник, на който нямате доверие.
— Възможно ли е с една транзакция на Ethereum да прехвърлите много различни токени от вашия адрес към различни целеви адреси, например адреси за обмен, където се търгуват тези токени?
Това е добър въпрос и се отнася до модела на транзакция на Ethereum и как той се различава от модела на Bitcoin. И разликата е радикална. Ако в транзакционния модел на Ethereum просто прехвърляте монети, тогава те се прехвърлят само от един адрес на друг, без промяна, само конкретната сума, която сте посочили. С други думи, това не е модел на неизразходвани изходи (UTXO), а модел на сметки и съответстващи салда. Теоретично е възможно да изпратите няколко различни токена в една транзакция наведнъж, ако напишете хитър интелигентен договор, но все пак ще трябва да направите много транзакции, да създадете договор, след това да прехвърлите токени и монети към него и след това да извикате подходящия метод . Това изисква усилия и време, така че на практика не работи така и всички плащания в Ethereum се извършват в отделни транзакции.
— Един от митовете за платформата Ethereum е, че е невъзможно да се опишат условия, които ще зависят от данните на външен интернет ресурс, така че какво да правим тогава?
Решението е, че самият интелигентен договор може да предостави един или повече така наречени доверени оракули, които събират данни за състоянието на нещата във външния свят и ги предават на интелигентните договори чрез специални методи. Самият договор счита за верни данните, които е получил от доверени лица. За по-голяма надеждност просто изберете голяма група от оракули и сведете до минимум риска от тяхното съгласуване. Самият договор може да не взема предвид данни от оракули, които противоречат на мнозинството.
Една от лекциите на онлайн курса по Blockchain е посветена на тази тема - “".
Източник: www.habr.com
