В этой статье мы рассмотрим, что такое смарт-контракты, какие они бывают, познакомимся с различными платформами смарт-контрактов, их особенностями, а также обсудим, как они работают и какие преимущества могут принести.
Этот материал будет очень полезен читателям, которые недостаточно хорошо знакомы с темой смарт-контрактов, но хотят приблизиться к ее пониманию.
Обычный контракт против смарт-контракта
Прежде чем углубиться в детали, давайте рассмотрим пример различий между обычным контрактом, который указан на бумаге, и смарт-контрактом, который представлен в цифровом виде.
Как это работало до появления смарт-контрактов? Представьте себе группу людей, которые хотят установить определенные правила и условия распределения ценностей, а также определенный механизм, гарантирующий осуществление этого распределения по заданным правилам и условиям.
Затем они собирались вместе, составляли документ, в котором записывали свои идентификационные данные, условия и ценности, ставили дату и подписывали его.
Этот договор также был заверен доверенной стороной, например нотариусом.
Далее эти люди разошлись со своей бумажной копией такого договора в разные стороны и начали совершать какие-то действия, которые могли не соответствовать самому договору, то есть они делали одно, а на бумаге было заверено, что они должны что-то делать.
полностью отличается.
И как выйти из этой ситуации? По сути, одному из членов группы необходимо взять эту бумагу, собрать некоторые доказательства, подать в суд и добиться соответствия договора реальным действиям.
Довольно часто добиться добросовестного выполнения данного договора сложно, что приводит к неприятным последствиям.
Что можно сказать о смарт-контрактах? Они сочетают в себе как возможность прописания условий договора, так и механизм их неукоснительного выполнения.
Если условия были установлены и соответствующая транзакция или запрос подписаны, то после принятия этого запроса или транзакции уже невозможно изменить условия или повлиять на их реализацию.
Имеется один валидатор или целая сеть, а также база данных, в которой хранятся все смарт-контракты, отправленные на исполнение, в строгом хронологическом порядке.
Также важно, чтобы эта база данных содержала все триггерные условия для исполнения смарт-контракта.
Кроме того, необходимо учитывать ту самую стоимость, распределение которой описано в договоре.
Если это относится к какой-то цифровой валюте, то эта база данных должна это учитывать.
Другими словами, валидаторы смарт-контрактов должны иметь доступ ко всем данным, с которыми работает смарт-контракт. Например, следует использовать единую базу данных для одновременного учета цифровых валют, балансов пользователей, пользовательских транзакций и временных меток.
Тогда в смарт-контракте условием может быть баланс пользователя в определенной валюте, наступление определенного времени или факт проведения определенной транзакции, но не более того.
Определение смарт-контракта
Вообще, сама терминология была придумана исследователем Ником Сабо и впервые использована в 1994 году, а задокументирована в 1997 году в статье, описывающей саму идею смарт-контрактов.Смарт-контракты подразумевают, что осуществляется некоторая автоматизация распределения стоимости, которая может зависеть только от тех условий, которые заранее определены.
В простейшем виде это выглядит как договор со строго определенными условиями, который подписывают определенные стороны.
Смарт-контракты призваны минимизировать доверие к третьим лицам.
Иногда полностью исключается центр принятия решений, от которого все зависит. Кроме того, такие контракты легче проверять.
Это следствие некоторых конструктивных особенностей такой системы, но чаще всего под смарт-контрактом мы понимаем децентрализованную среду и наличие функций, позволяющих любому человеку анализировать базу данных и проводить полный аудит исполнения контрактов.
Это обеспечивает защиту от ретроактивных изменений данных, которые повлекут за собой изменения в исполнении самого договора.
Цифровизация большинства процессов при создании и запуске смарт-контракта зачастую упрощает технологию и стоимость их реализации.
Простой пример — сервис Эскроу.
Давайте рассмотрим очень простой пример.
Это поможет вам приблизиться к пониманию функциональности смарт-контрактов, а также лучше понять, в каких случаях их следует использовать.
Его также можно реализовать с помощью Биткойна, хотя на данный момент Биткойн пока ещё сложно назвать полноценной платформой для смарт-контрактов.
Итак, у нас есть покупатель и есть интернет-магазин.
Покупатель хочет купить монитор в этом магазине.
В самом простом случае покупатель оформляет и отправляет оплату, а интернет-магазин принимает ее, подтверждает и затем отправляет товар.
Однако в этой ситуации необходимо большое доверие – покупатель должен доверить интернет-магазину всю стоимость монитора.
Поскольку интернет-магазин может иметь низкую репутацию в глазах покупателя, существует риск, что по каким-либо причинам после принятия оплаты магазин откажется от обслуживания и не отправит товар покупателю.
Поэтому покупатель задается вопросом (и, соответственно, интернет-магазин задает этот вопрос), что можно применить в данном случае, чтобы минимизировать подобные риски и сделать подобные сделки более надежными.
В случае с Биткойном можно позволить покупателю и продавцу самостоятельно выбирать посредника.
Есть много людей, которые занимаются решением спорных вопросов.
И наши участники могут выбрать из общего списка посредников того, кому они будут доверять.
Вместе они создают адрес с мультиподписью 2 из 3, где есть три ключа, и для траты монет с этого адреса необходимы две подписи с любыми двумя ключами.
Один ключ будет принадлежать покупателю, второй интернет-магазину, третий посреднику.
И на такой мультиподписной адрес покупатель отправит сумму, необходимую для оплаты монитора.
Теперь, когда продавец видит, что деньги на какое-то время заблокированы по мультиподписному адресу, который зависит от него, он может смело отправлять монитор по почте.
Далее покупатель получает посылку, осматривает товар и принимает решение об окончательной покупке.
Он может полностью согласиться с предоставленной услугой и подписать своим ключом транзакцию, где он передает монеты с мультиподписного адреса продавцу, а может быть чем-то недоволен.
Во втором случае он связывается с посредником, чтобы организовать альтернативную транзакцию, которая будет распределять эти монеты по-другому.
Допустим, монитор приехал немного поцарапанный и в комплекте не было кабеля для подключения к компьютеру, хотя на сайте интернет-магазина было написано, что кабель должен быть в комплекте.
Затем покупатель собирает доказательства, необходимые посреднику, чтобы доказать, что его обманули в данной ситуации: он делает скриншоты сайта, фотографирует почтовую квитанцию, фотографирует царапины на мониторе и показывает, что пломба была снята.
сломался и трос выдернулся.
Интернет-магазин, в свою очередь, собирает свои доказательства и передает их посреднику.
Посредник заинтересован одновременно удовлетворить и возмущение покупателя, и интересы интернет-магазина (почему, станет ясно позже).
Он представляет собой транзакцию, в которой монеты с мультиподписного адреса будут потрачены в некоторой пропорции между покупателем, интернет-магазином и посредником, поскольку часть он забирает себе в качестве вознаграждения за свою работу.
Допустим, 90% от общей суммы достаётся продавцу, 5% посреднику и 5% компенсации покупателю.
Посредник подписывает эту транзакцию своим ключом, но применить ее пока нельзя, поскольку требует двух подписей, а стоит только одна.
Он отправляет такую транзакцию как покупателю, так и продавцу.
Если хотя бы один из них устроит такой вариант перераспределения монет, то транзакция будет предварительно подписана и распространена в сети.
Для ее подтверждения достаточно согласия одной из сторон сделки с вариантом посредника.
Важно изначально выбрать посредника так, чтобы ему доверяли оба участника.
В этом случае он будет действовать независимо от интересов того или иного и объективно оценивать ситуацию.
Если посредник не предоставляет вариант распространения монет, который удовлетворит хотя бы одного участника, то, договорившись между собой, и покупатель, и интернет-магазин могут отправить монеты на новый мультиподписной адрес, поставив свои две подписи.
Новый адрес с мультиподписью будет составлен с помощью другого посредника, который может оказаться более компетентным в этом вопросе и предоставить лучший вариант.
Пример с общежитием и холодильником
Давайте рассмотрим более сложный пример, который более явно отображает возможности смарт-контракта.
Допустим, есть трое парней, которые недавно переехали в одну комнату в общежитии.
Все трое заинтересованы в покупке холодильника для своей комнаты, которым они могли бы пользоваться вместе.
Один из них вызвался собрать необходимую сумму для покупки холодильника и договориться с продавцом.
Однако они познакомились лишь недавно и между ними недостаточно доверия.
Очевидно, двое из них рискуют, отдавая деньги третьему.
Кроме того, им необходимо договориться в выборе продавца.
Они могут воспользоваться услугой эскроу, то есть выбрать посредника, который будет контролировать исполнение сделки и решать спорные вопросы, если таковые возникнут. Затем, договорившись, оформляют смарт-контракт и прописывают в нем определенные условия.
Первое условие заключается в том, что до определенного времени, скажем, в течение одной недели, соответствующий счет смарт-контракта должен получить три платежа с определенных адресов на определенную сумму.
Если этого не происходит, смарт-контракт прекращает выполнение и возвращает монеты всем участникам.
Если условие выполнено, то устанавливаются значения идентификаторов продавца и посредника и проверяется условие согласия всех участников с выбором продавца и посредника.
Когда все условия будут выполнены, то средства будут переведены на указанные адреса.
Такой подход позволяет защитить участников от мошенничества с любой стороны и вообще исключает необходимость доверия.
Мы видим на этом примере тот самый принцип, что эта возможность пошаговой установки параметров выполнения каждого условия позволяет создавать системы любой сложности и глубины вложенности уровней.
Кроме того, вы можете сначала определить первое условие в смарт-контракте и только после его выполнения задать параметры для следующего условия.
Другими словами, условие написано формально, и параметры для него можно задать уже во время его работы.
Классификация смарт-контрактов
Для классификации можно задать разные группы критериев.Однако на момент развития технологий актуальны четыре из них.
Смарт-контракты можно отличить по среде их исполнения, которая может быть централизованной или децентрализованной.
В случае децентрализации мы имеем гораздо большую независимость и отказоустойчивость при выполнении смарт-контрактов.
Их также можно отличить по процессу установки и выполнения условий: они могут быть свободно программируемыми, ограниченными или предопределенными, т.е.
строго типизированными.
Когда на платформе смарт-контрактов всего 4 конкретных смарт-контракта, параметры для них можно задавать любым способом.
Соответственно, задавать их гораздо проще: выбираем контракт из списка и передаем параметры.
По методу инициации есть автоматизированные смарт-контракты, то есть при наступлении определенных условий они самоисполняются, а есть контракты, в которых условия указаны, но платформа не проверяет их выполнение автоматически; для этого их нужно инициировать отдельно.
Кроме того, смарт-контракты различаются по уровню конфиденциальности.
Они могут быть как полностью открытыми, так и частично или полностью конфиденциальными.
Последнее означает, что сторонние наблюдатели не видят условий смарт-контрактов.
Однако тема конфиденциальности очень широкая и ее лучше рассматривать отдельно от данной статьи.
Ниже мы более подробно рассмотрим первые три критерия, чтобы внести больше ясности в понимание текущей темы.
Смарт-контракты по времени выполнения
В зависимости от среды исполнения различают централизованные и децентрализованные платформы смарт-контрактов.
В случае централизованных цифровых контрактов используется единый сервис, где есть только один валидатор и может быть сервис резервного копирования и восстановления, который также управляется централизованно.
Есть одна база данных, в которой хранится вся необходимая информация для установления условий смарт-контракта и распределения учитываемой стоимости в этой самой сервисной базе данных.
У такого централизованного сервиса есть клиент, который задает условия определенными запросами и использует такие контракты.
Из-за централизованного характера платформы механизмы аутентификации могут быть менее безопасными, чем в криптовалютах.
В качестве примера можно взять провайдеров мобильной связи (разных мобильных операторов).
Допустим, некий оператор ведет на своих серверах централизованный учет трафика, который может передаваться в разных форматах, например: в виде голосовых вызовов, передачи СМС, мобильного интернет-трафика и по разным стандартам, а также ведет учет. средств на балансах пользователей.
Соответственно, провайдер мобильной связи может составлять договоры учета оказанных услуг и их оплаты с разными условиями.
В этом случае легко выставить условия типа «отправьте СМС с таким-то кодом на такой-то номер и вы получите такие-то условия распределения трафика».
Можно привести еще один пример: традиционные банки с расширенным функционалом интернет-банкинга и очень простыми договорами, такими как регулярные платежи, автоматическая конвертация входящих платежей, автоматическое отчисление процентов на указанный счет и т. д. Если мы говорим о смарт-контрактах с децентрализованной средой исполнения, то у нас есть группа валидаторов.
В идеале валидатором может стать каждый.
Благодаря протоколу синхронизации баз данных и достижению консенсуса у нас есть некая общая база данных, которая теперь будет хранить все транзакции со строго описанными контрактами, а не какими-то условными запросами, форматы которых часто меняются, и открытой спецификации нет. Здесь транзакции будут содержать инструкции по исполнению контракта в соответствии со строгой спецификацией.
Эта спецификация открыта и, следовательно, пользователи платформы сами могут проводить аудит и проверку смарт-контрактов.
Здесь мы видим, что децентрализованные платформы превосходят централизованные по независимости и отказоустойчивости, но их проектирование и обслуживание гораздо сложнее.
Смарт-контракты по методу задания и выполнения условий
Теперь давайте подробнее рассмотрим, чем могут различаться смарт-контракты по способу установления и выполнения условий.Здесь мы обращаем внимание на смарт-контракты, которые программируются случайным образом и полны по Тьюрингу.
Смарт-контракт, полный по Тьюрингу, позволяет задавать в качестве условий исполнения контракта практически любые алгоритмы: циклы записи, некоторые функции для расчета вероятностей и тому подобное — вплоть до собственных алгоритмов электронной подписи.
В данном случае имеется в виду действительно произвольное написание логики.
Существуют также произвольные смарт-контракты, но не полные по Тьюрингу.
Сюда входят Биткойн и Лайткойн со своим собственным скриптом.
Это означает, что вы можете использовать только определенные операции в любом порядке, но писать циклы и свои алгоритмы уже нельзя.
Кроме того, существуют платформы смарт-контрактов, которые реализуют заранее определенные смарт-контракты.
К ним относятся Bitshares и Steemit. Bitshares имеет ряд смарт-контрактов для торговли, управления счетами, управления самой платформой и ее параметрами.
Steemit — похожая платформа, но она больше ориентирована не на выпуск токенов и торговлю, как Bitshares, а на ведение блогов, т. е.
хранит и обрабатывает контент децентрализованно.
Произвольные Тьюринг-полные контракты включают платформу Ethereum и RootStock, который все еще находится в стадии разработки.
Поэтому ниже мы остановимся немного подробнее на платформе смарт-контрактов Ethereum.
Смарт-контракты по методу инициации
По способу инициации смарт-контракты также можно разделить как минимум на две группы: автоматизированные и ручные (неавтоматизированные).Автоматизированные характеризуются тем, что при всех известных параметрах и условиях смарт-контракт исполняется полностью автоматически, то есть не требует отправки каких-либо дополнительных транзакций и траты дополнительной комиссии при каждом последующем исполнении.
Сама платформа имеет все данные для расчета того, как будет выполняться смарт-контракт. Логика там не произвольная, а предопределённая и всё это предсказуемо.
То есть вы можете заранее оценить сложность исполнения смарт-контракта, использовать за него какую-то постоянную комиссию, и все процессы по его реализации будут более эффективными.
Для свободно программируемых смарт-контрактов исполнение не автоматизировано.
Чтобы инициировать такой смарт-контракт, практически на каждом этапе необходимо создавать новую транзакцию, которая будет вызывать следующий этап исполнения или следующий метод смарт-контракта, платить соответствующую комиссию и ждать подтверждения транзакции.
Выполнение может завершиться успешно или нет, поскольку код смарт-контракта произволен и могут возникнуть некоторые непредсказуемые моменты, такие как вечный цикл, отсутствие некоторых параметров и аргументов, необработанные исключения и т. д.
Счета Эфириума
Типы учетных записей Ethereum
Давайте посмотрим, какие типы учетных записей могут быть на платформе Ethereum. Здесь всего два типа аккаунтов и других вариантов нет. Первый тип называется учетной записью пользователя, второй — контрактной учетной записью.Давайте разберемся, чем они отличаются.
Учетная запись пользователя контролируется только личным ключом электронной подписи.
Владелец учетной записи генерирует собственную пару ключей для электронной подписи с использованием алгоритма ECDSA (алгоритм цифровой подписи с эллиптической кривой).
Только транзакции, подписанные этим ключом, могут изменить состояние этой учетной записи.
Для учетной записи смарт-контракта предусмотрена отдельная логика.
Управлять им может только заранее заданный программный код, который полностью определяет поведение смарт-контракта: как он будет распоряжаться своими монетами при определенных обстоятельствах, по инициативе какого пользователя и при каких дополнительных условиях эти монеты будут распределяться.
Если некоторые моменты не предусмотрены разработчиками в программном коде, могут возникнуть проблемы.
Например, смарт-контракт может получить определенное состояние, в котором он не принимает инициацию дальнейшего исполнения от кого-либо из пользователей.
В этом случае монеты фактически будут заморожены, поскольку выход из этого состояния смарт-контрактом не предусмотрен.
Как создаются учетные записи в 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 является автором этой транзакции, на которой размещен этот код. Он будет владельцем смарт-контракта.
Метод депозита позволяет перевести определенное количество монет на контрактный счет путем транзакции.
В этом случае смарт-контракт, получая эти монеты, оставляет их на своем балансе, но записывает в структуру балансов, кто именно был отправителем этих монет, чтобы знать, кому они принадлежат. Следующий метод называется «вывести» и принимает один параметр — количество монет, которое кто-то хочет вывести из этого банка.
При этом проверяется, достаточно ли монет на балансе пользователя, вызывающего этот метод, для их отправки.
Если их достаточно, то смарт-контракт сам возвращает вызывающему абоненту это количество монет. Далее идет метод проверки текущего баланса пользователя.
Кто бы ни вызвал этот метод, он будет использован для получения этого баланса в смарт-контракте.
Стоит отметить, что модификатором этого метода является view. Это означает, что сам метод никак не меняет переменные своего класса и фактически является только методом чтения.
Для вызова этого метода не создается отдельная транзакция, не взимается комиссия, а все расчеты выполняются локально, после чего пользователь получает результат. Метод kill нужен для уничтожения состояния смарт-контракта.
И здесь происходит дополнительная проверка, является ли вызывающий этот метод владельцем этого контракта.
Если это так, то контракт самоуничтожается, а функция уничтожения принимает один параметр — идентификатор аккаунта, на который контракт отправит все монеты, оставшиеся на его балансе.
В этом случае оставшиеся монеты автоматически перейдут на адрес владельца контракта.
Как работает полный узел в сети Ethereum?
Давайте схематически рассмотрим, как такие смарт-контракты исполняются на платформе Ethereum и как работает полноценный узел сети.
Полный узел в сети Ethereum должен иметь как минимум четыре модуля.
Первым, как и для любого децентрализованного протокола, является сетевой модуль P2P — модуль сетевого подключения и работы с другими узлами, где происходит обмен блоками, транзакциями и информацией о других узлах.
Это традиционный компонент для всех децентрализованных криптовалют. Далее у нас есть модуль хранения данных блокчейна, обработки, выбора приоритетной ветки, добавления блоков, отсоединения блоков, проверки этих блоков и т. д. Третий модуль называется EVM (виртуальная машина Ethereum) — это виртуальная машина, которая получает байт-код от транзакций Ethereum. Этот модуль принимает текущее состояние конкретной учетной записи и вносит изменения в ее состояние на основе полученного байт-кода.
Версия виртуальной машины на каждом узле сети должна быть одинаковой.
Вычисления, которые происходят на каждом узле Ethereum, совершенно одинаковы, но происходят асинхронно: кто-то проверяет и принимает эту транзакцию раньше, то есть выполняет весь содержащийся в ней код, а кто-то позже.
Соответственно, когда транзакция создается, она распространяется по сети, узлы ее принимают, и в момент проверки, так же, как в Биткойне выполняется Bitcoin Script, здесь исполняется байт-код виртуальной машины.
Транзакция считается проверенной, если весь содержащийся в ней код был выполнен, новое состояние определенного аккаунта сгенерировано и сохранено до тех пор, пока оно не станет ясным, например Теги: #информационная безопасность #платежные системы #биткоин #Криптовалюты #Криптография #блокчейн #Solidity #Solidity #Ethereum #криптография #Криптовалюта #эскроу #смарт-контракт #децентрализация
-
Канадская Винтовка Нового Поколения
19 Oct, 24 -
Форд Будет Открывать Патенты За Деньги
19 Oct, 24 -
Алгоритмы Сжатия Изображений
19 Oct, 24 -
Монетизация Приложения Подкастов В Цифрах
19 Oct, 24
