Смарт контракты Ethereum пишем простой контракт для ICO

Содержание

Выбор компонентов платформы

  • Наличие развернутой и «самоподдерживающейся» инфраструктуры
  • Открытость для пользователей и возможность контроля операций через альтернативные источники, а не только через предлагаемый банком интерфейс
  • Высокий уровень доверия со стороны пользователей благодаря наличию конкурентных протоколов консенсуса и качественной «не толерантной» сети независимых узлов

  • Блокчейн и смарт-контракты — Ethereum и язык Solidity;
  • Децентрализованные файловые хранилища — Swarm и Storj.io;
  • Сертифицированные СКЗИ — КриптоПРО и КриптоАРМ;
  • Бродкаст-Оракулы — собственной разработки;
  • Провайдеры внешних запросов — собственной разработки;
  • Анализатор документов — на данном этапе было решено не рассматривать, так как принцип взаимодействия с ним смарт-контракта в общем аналогичен Провайдеру внешних запросов, а ресурсы команды исследования — ограничены.

Уязвимые генераторы

Анализ выявил четыре категории уязвимых ГПСЧ:

  • генераторы, использующие переменные блока как источник энтропии;
  • генераторы, использующие хеш предыдущего блока;
  • генераторы, использующие хеш предыдущего блока в сочетании с якобы секретным начальным значением;
  • генераторы, подверженные уязвимости с опережением транзакции (front-running).

Рассмотрим каждую категорию с примерами уязвимого кода.

Генератор, использующий переменные блока

Существует ряд переменных блока, которые могут быть по ошибке использованы как источники энтропии:

  • представляет собой адрес майнера, который майнит данный блок;
  • — относительный показатель того, насколько сложно создать блок;
  • — максимальный расход «газа» на все транзакции в блоке;
  • — высота данного блока;
  • — дата майнинга блока.

Всеми перечисленными переменными могут манипулировать майнеры, поэтому их нельзя использовать как источник энтропии. Более того, очевидно, что эти переменные одинаковы в пределах одного блока. И если контракт злоумышленника вызывает контракт жертвы внутренним сообщением, один и тот же генератор в обоих контрактах выдаст одинаковое значение.

Пример 3 (0xcC88937F325d1C6B97da0AFDbb4cA542EFA70870):

Генератор, использующий хеш блока

У каждого блока в блокчейне Ethereum есть хеш для верификации транзакций. Так называемая виртуальная машина Ethereum (EVM) позволяет получить хеш блока с помощью функции . Функция ожидает числовой аргумент, который обозначает номер блока. Во время исследования мы обнаружили, что результат функции часто некорректно используется при генерации случайных значений.

Существуют три основные уязвимые вариации генераторов, использующих хеш блока:

  • — хеш текущего блока;
  • — хеш последнего блока;
  • — хеш блока, который как минимум на 256 блоков старше.

Рассмотрим каждую из перечисленных вариаций.

block.blockhash(block.number)

Переменная состояния позволяет узнать высоту данного блока. Когда майнер добавляет в блок транзакцию, которая выполняет код контракта, известен будущего блока этой транзакции и контракту доступно его значение. Однако в момент выполнения транзакции в EVM хеш создаваемого блока еще неизвестен по очевидным причинам, и EVM всегда выдает ноль.

Некоторые контракты ошибочно интерпретируют значение выражения . В таких контрактах хеш блока считается известным во время выполнения транзакции и используется как источник энтропии.

Пример 2 (https://github.com/axiomzen/eth-random/issues/3):

block.blockhash(block.number-1)

Некоторые контракты используют генераторы, основанные на хеше последнего блока. Понятно, что такой подход тоже уязвим: злоумышленник может создать контракт-эксплоит с таким же значением генератора, чтобы вызвать атакуемый контракт через внутреннее сообщение. «Случайные» числа обоих контрактов совпадут.

Пример 1 (0xF767fCA8e65d03fE16D4e38810f5E5376c3372A8):

block.blockhash() — хеш будущего блока

Более надежный способ — использовать хеш будущего блока, например следующим образом.

  1. Игрок делает ставку, казино запоминает block.number транзакции.
  2. При втором вызове контракта игрок запрашивает у казино выигрышный номер.
  3. Казино извлекает сохраненный block.number, получает хеш блока по его номеру и затем использует хеш при генерации псевдослучайного числа.

Такой подход работает, только если выполняется одно важное требование. В документации Solidity есть предупреждение об ограниченном числе хешей блоков, которые может хранить EVM

Поэтому, если второй вызов не был сделан в пределах 256 блоков и не было проверки номера блока, псевдослучайное число будет известно заранее — это 0.

Самый нашумевший случай эксплуатации этой уязвимости — взлом лотереи SmartBillions. Контракт неверно проверял возраст block.number, и это привело к тому, что игрок выиграл 400 ETH: после создания 256 блоков он запросил предсказуемый выигрышный номер, который отправил в первой транзакции.

Продолжение доступно только участникам

Вариант 1. Присоединись к сообществу «Xakep.ru», чтобы читать все материалы на сайте

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score!
Подробнее

Вариант 2. Открой один материал

Заинтересовала статья, но нет возможности стать членом клуба «Xakep.ru»? Тогда этот вариант для тебя!
Обрати внимание: этот способ подходит только для статей, опубликованных более двух месяцев назад.

Я уже участник «Xakep.ru»

9. Регулирующее законодательство и территориальная подсудность

Одно из главных обещаний блокчейна, а следовательно, и смарт-контрактов — создание надёжных, децентрализованных глобальных платформ. Но глобальное внедрение означает, что стороны могут использовать смарт-контракты под куда более широким спектром юрисдикций, чем текстовые контракты. Поэтому регулирующее законодательство и территориальная подсудность должны лучшим образом защищать условия, предлагаемые к внесению в смарт-контракт. Положения регулирующего законодательства определяют, суды какой юрисдикции будут рассматривать споры. Если законы и территориальная подсудность не определены, истец может быть относительно не ограничен в выборе места подачи жалобы или в споре о том, какое материальное право следует применять с учётом широкого спектра юрисдикций, под которыми может использоваться смарт-контракт. Учитывая, что многие из первых споров о смарт-контрактах станут разрешаться в ситуации без прецедентов (в США прецедентная судебная система), договаривающиеся стороны захотят получить уверенность относительно выбора юрисдикций, в рамках которых будут рассматриваться дела.

5. Лучшие практики

Мы находимся лишь в начале пути внедрения смарт-контрактов, и лучшие практики ещё не выработаны. Однако этот чек-лист поможет разработчикам создавать эффективные смарт-контракты и консультировать компании, планирующие их использовать.

  • Сейчас сторонам, заключающим любые контрактные договорённости, лучше всего придерживаться гибридного подхода — комбинации текста и кода. Есть сильные аргументы в пользу того, что исключительно программные смарт-контракты должны быть обязательны к исполнению, как минимум в рамках местных законодательств в США. Однако пока не появится большей ясности об их законности и обязательности, исключительно программные смарт-контракты следует использовать только для простых взаимоотношений. Сторонам понадобятся текстовые версии соглашений, чтобы прочитать обсуждённые условия и вписать условия, которые смарт-контракт не учитывает; потребуется, чтобы под рукой был документ, который примут в суде.
  • В гибридном контракте текст должен ясно определять код смарт-контракта, с которым он ассоциирован, а стороны должны видеть все переменные, передаваемые в смарт-контракт, их определения и транзакционные события, инициирующие исполнение кода.
  • Полагаясь в получении сторонних данных на оракулы, стороны должны решить, что будет, если оракул не сможет передавать данные, предоставит ошибочную информацию или просто прекратит работать.
  • Стороны должны понимать распределение рисков при ошибках в коде.
  • Текстовое соглашение, сопровождающее код, должно определять регулирующее законодательство и территориальную подсудность, а также приоритетность кода и текста в случае конфликтов их содержимого.
  • Текстовое соглашение должно включать в себя сообщения обеих сторон о том, что они проанализировали код смарт-контракта и что код отражает условия, описанные в текстовом соглашении. Хотя такое подтверждение не заставит стороны действительно проанализировать код, оно поможет другой стороне защититься от обвинений в том, что код вообще не анализировался. Стороны также могут застраховаться от риска ошибок в коде. Как отмечалось ранее, стороны могут привлечь сторонних экспертов для анализа кода.

6. Будущее смарт-контрактов

Сегодня смарт-контракты представляют собой прототипный пример Amara’s Law — концепции, которую сформулировал Рой Амара, специалист по информатике из Стэнфордского университета. Эта концепция гласит, что мы склонны переоценивать новые технологии в краткосрочной перспективе и недооценивать в долгосрочной. Хотя смарт-контрактам ещё нужно развиваться, прежде чем они станут широко использоваться в сложных коммерческих взаимоотношениях, всё же они влияют на революцию в структуре вознаграждения и стимулирования, которая определит форму контрактов в будущем

При рассмотрении смарт-контрактов важно не просто думать о том, как перенести в эту новую технологию существующие концепции и структуры. Скорее подлинная революция смарт-контрактов будет спровоцирована совершенно новыми парадигмами, которые мы ещё не спрогнозировали

1. Как работают смарт-контракты

Термин «смарт-контракт» описывает компьютерный код, который автоматически исполняет всё соглашение или его части. Код хранится на платформе, построенной на основе блокчейна. Как мы увидим ниже, код бывает единственным объявлением о соглашении между сторонами либо дополняет традиционный текстовый контракт и исполняет лишь определённые положения, такие как перевод денег стороной А стороне Б. Сам код реплицируется на несколько узлов блокчейна, а значит, пользуется преимуществами блокчейна: это безопасность, сохранность и неизменяемость. Реплицирование также означает, что по мере добавления в блокчейн каждого нового блока код, по сути, может исполниться. Если стороны инициировали транзакцию и тем самым показали, что условия соблюдены, это станет триггером, и код выполнит какие-то действия. Если же транзакция не инициирована, то и код ничего не делает. Большинство смарт-контрактов написаны на одном из языков программирования, созданных именно для этих целей (например, Solidity).

Необходимо, чтобы входные параметры и этапы выполнения смарт-контракта были конкретными и объективными. Иными словами, «если произойдёт Х — тогда сделать Y». Следовательно, смарт-контракты выполняют простейшие задачи, например автоматически переводят криптовалюту с кошелька одной стороны на кошелёк другой, если соблюдены нужные условия. По мере распространения блокчейна и увеличения средств, вкладываемых в токены или отправляемых в рамках блокчейна (on-chain), смарт-контракты будут усложняться и получать возможность обрабатывать сложные транзакции. Многие разработчики уже создают более сложные смарт-контракты, объединяя в них несколько этапов транзакций. Тем не менее нам придётся ждать ещё много лет, пока код сможет определять субъективные юридические критерии, такие как «соответствуют ли действия стороны критериям коммерчески оправданных усилий (commercially reasonable efforts)» или «стоит ли выполнить пункт о возмещении и выплатить компенсацию».

Прежде чем скомпилированный смарт-контракт будет исполнен, требуется оплатить транзакционную комиссию за добавление контракта в блокчейн. Например, в блокчейне Ethereum смарт-контракты исполняются в виртуальной машине Ethereum Virtual Machine (EVM), а комиссия в криптовалюте ether (эфир) называется газом (gas, хотя более корректный перевод — «топливо») . Чем сложнее смарт-контракт, тем больше газа нужно заплатить. То есть газ — это своеобразный шлюз, защищающий EVM от исполнения слишком сложных или многочисленных смарт-контрактов .

Пока что смарт-контракты лучше всего подходят для автоматического исполнения транзакций двух типов:

  • оплата, инициируемая определёнными событиями,
  • наложение финансовых санкций при невыполнении объективных условий.

Когда развёрнутый контракт начал действовать, для выполнения этих двух типов транзакций не требуется участие людей, в том числе доверенных держателей условного депонирования или представителей юридической системы. Это позволяет снизить накладные расходы на исполнение и правоприменение при заключении контрактов.

Например, смарт-контракты могут избавить вас от так называемых кассовых разрывов (procure-to-pay gap). Как только товар прибыл на склад и зарегистрирован, смарт-контракт способен мгновенно отправить запросы на подтверждения. Получив их, он сразу же переведёт средства от покупателя продавцу. При этом продавцы получат оплату быстрее, им не придётся напоминать клиентам о необходимости заплатить, а покупатели сэкономят на банковских операциях. Всё это может снизить требования к оборотному капиталу и упростить финансовые операции для обеих сторон. Что касается обязательности исполнения, то смарт-контракт можно запрограммировать таким образом, чтобы он закрывал доступ к подключённым через интернет активам (например, к контенту), пока не получена оплата.

Проблемы безопасности смарт-контрактов

Речь пойдёт о проблемах, с которыми в итоге сталкиваются разработчики смарт-контрактов, а не о безопасности самой платформы (хотя немного и о ней). Условно разделим эти проблемы на следующие типы:

  1. проблемы в коде смарт-контракта;
  2. проблемы в процессе разработки;
  3. проблемы в языке;
  4. проблемы в концепции.

1. Проблемы в коде смарт-контракта

Под проблемами в коде смарт-контракта здесь я подразумеваю такие проблемы, которые решаются редактированием .sol-файла. Это, в частности:

  • Известные уязвимые конструкции (например, ).Пример из жизни: re-entrancy, или, шире, нарушение паттерна Checks-Effects-Interactions — даже широко известные (и ранее проэксплуатированные) уязвимости продолжают встречаться в новых контрактах.
  • Авторские уязвимые конструкции (в частности, ошибки в логике кода).Пример из жизни: MultiSig-кошелёк, который на самом деле не MultiSig. Для того чтобы подписать транзакцию и перевести средства, необходимо количество подписей владельцев кошелька, равное . При этом для того чтобы поменять (например, на единицу, чтобы дальше самому подписывать транзакции), достаточно подписи только одного из владельцев:

  • Неудачная архитектура.Пример из жизни: попытка имплементировать в рамках одного контракта и токен, и кошелёк, и хранилище ключей. Контракт получается чрезмерно усложнённым, код сложно поддерживать, аудировать, модифицировать. В итоге страдает и безопасность.
  • Низкое качество кода.Пример из жизни: контракты с разными отступами, произвольными переходами на новую строку и пробелами. Код трудно читать, а значит, снова страдает безопасность. При том, что для Solidity уже есть линтеры (Solium, Solhit).

Проблемы в коде непосредственно приводят к атакам и потере средств. Хорошая новость в том, что проблемы в коде можно выявить в процессе аудита и устранить

При этом важно понимать, откуда они берутся, чтобы избежать их в дальнейшем. Поэтому переходим к следующему пункту

2. Проблемы в процессе разработки

Проблемы в коде обусловлены в первую очередь неправильно выстроенным процессом разработки. Казалось бы, разработка ПО — дело давно изученное, с устоявшимися best practices. Тем не менее, молодость области смарт-контрактов, непропорционально большие деньги и хайп приводят к тому, что люди по тем или иным причинам пренебрегают стандартными процедурами, что часто приводит к серьёзным проблемам. Из самого типичного стоит упомянуть:

3. Проблемы в языке

Добавляет дёгтя сам язык Solidity. Изначально он был создан скорее для того, чтобы его могли быстро освоить большое количество людей, чем для того, чтобы на нём было удобно писать безопасные смарт-контракты. Вот лишь некоторые его особенности, которые мешают безопасности:

  • Множественное наследование, , / — всё это запускает код не из текущего исходника, а значит, снижает читаемость и, как следствие, безопасность кода.
  • Checks-Effects-Interactions pattern — если конструкции, нарушающие CEI, небезопасны, то почему не запретить их (и многие другие) просто на уровне языка?
  • Вызывая другой контракт, можно внезапно попасть в его fallback-функцию с неожиданными последствиями.

Понятно, что проект Ethereum развивается, и невозможно всё учесть заранее. Но в итоге разработчики вынуждены помнить о многих особенностях и пользоваться , чтобы сделать свой смарт-контракт безопасным.

4. Проблемы в концепции

Однако самая серьёзная проблема ещё глубже — в том, что многие недостаточно хорошо понимают, для чего смарт-контракты нужны, что они могут, чего не могут и как работают. В худшем случае это приводит к тому, что смарт-контракт:

  1. Не смарт:

    • Плохо написан — делает то, что написано, но не то, что задумано.
    • Сильно завязан на backend и/или frontend — а этот код уже не смарт-контракт, он выполняется обычным образом, и его выполнение полностью контролирует администратор сервера.
  2. Не контракт:

    • Не фиксирует обязательства сторон — например, ICO продаёт свои токены за ETH, но токены по сути являются фантиками, т.к. не налагают на того, кто их выпустил, никаких ограничений или обязательств.
    • Допускает односторонние изменения — и получается, что одна из сторон может менять контракт уже после его подписания.Пример из жизни: владелец контракта может произвольно менять капитализацию, курс и продолжительность продажи токена:
  3. Не нужен:

    • Смарт-контракт добавили не потому, что он был технически необходим, а в попытках придумать, что бы сделать на смарт-контрактах, и оседлать волну хайпа;
    • Пытались придумать, как к существующему продукту прикрутить смарт-контракты.

Использование смарт-контрактов в финансовой сфере

В недавней статье под названием «Смарт-контракты и будущее банковской системы», подготовленной Nasdaq, отмечалось, что основная проблема, препятствующая широкому внедрению смарт-контрактов, — это отсутствие интеллектуальных интерфейсов между блокчейнами, в которых работают смарт-контракты, и остальным миром.

Имея это в виду, такие отраслевые группы, как FinTechNetwork и Zerado, по-прежнему считают, что смарт-контракты могут предложить множество полезных приложений для банков, если последние определятся, как эффективно координировать юридические контракты в формате смарт-контрактов. Вероятно, это потребует, чтобы банки применяли смарт-контракты, которые будут соотноситься и с развитием блокчейн-инфраструктуры, и с инфраструктурой устаревших финансовых услуг (банковскими, страховыми сетями и т.д.).

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

Регулирующие органы также смогут получать доступ и считывать записи обо всех транзакциях, проверяя, соблюдены ли все применимые правила. При правильной реализации этот тип системы обеспечит безопасную, приватную и масштабируемую платформу для всех участников транзакций.

Однако на практике всё не так просто; есть проблемы, из-за которых смарт-контракты не используются большинством финансовых компаний.

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

После того как ответы на эти вопросы будут получены, а препятствия в управлении— устранены, мы увидим реальные случаи использования смарт-контрактов в отрасли финансовых услуг.

Для более глубокого понимания этой сложной темы вы можете почитать white paper Cap-Gemini.

Проблема оракулов

Проблема так называемых оракулов — препятствие для широкого внедрения смарт-контрактов. Она заключается в том, что выполнение смарт-контрактов не может быть инициировано в режиме реального времени на основе возникновения событий в физическом мире. Чтобы преодолеть это ограничение, как мы уже писали, блокчейну необходимы оракулы.

Оракулы могут обеспечить смарт-контракты необходимыми данными, но всё усложняется, когда задействованы физические элементы. В отличие от отправки простого потока данных из финансового учреждения или службы программного обеспечения в блокчейн, физическим элементам может потребоваться гораздо больше каналов для отслеживания данных, их обработки и отправки.

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

Тот факт, что оракулы обычно не децентрализованы, означает, что они вводят в блокчейн человеческий фактор. Если данные, представленные оракулом, не будут точны, это может привести к сбою смарт-контрактов.

Использование смарт-контрактов в государственных институтах

Смарт-контракты смогут решить такие задачи правительственных институтов, как управление контрактами, проверка личности или голосование.

Один из примеров — идея использования блокчейнов для записи обещаний, которые дают публичные лица, и последующего использования этих данных для гарантии их соблюдения.

Например, законодатель может согласиться выделить некоторую сумму для решения определённой проблемы. Как только она будет отправлена, контракт будет заключён, а все члены сообщества — проинформированы о состоянии сделки. Если сумма не будет отправлена к указанной дате, смарт-контракт будет действовать иначе, сообщая учредителям, что обещание не соблюдено.

Другой пример: правительство США в настоящее время изучает смарт-контракты, которые могут быть использованы для улучшения системы, используемой для участия в государственных закупках. Также есть мнение, что смарт-контракты могут использоваться для облегчения доступа к анонимному регистру голосования, к которому смогут легко обращаться граждане.

Разумеется, такая система должна быть полностью безопасной и иметь возможность проверять личность человека, не разглашая при этом конфиденциальную информацию в публичном блокчейне.

Проблемы смарт-контрактов

Оракулы

Одна из основных технических преград полномасштабному внедрению блокчейн-реестра и смарт-контрактов — необходимость создать эффективные и надёжные оракулы. Оракулы — это внешние агенты, которые отвечают за достоверность предоставленной информации извне.

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

Оракулами могут быть:

  • измерительные приборы вроде термометра или датчика освещенности;
  • конкретные участники сети, которые оказывают услуги блокчейн-системе;
  • децентрализованные системы с собственными механизмами консенсуса, построенные поверх основного реестра.

В некоторых случаях, как в блокчейне Aeternity, оракулы интегрированы с основным блокчейном и работают в рамках одного механизма консенсуса с остальной сетью. Пользователи сети посылают оракулам запросы посредством транзакций на блокчейне, а оракулы отвечают им соответствующей он-чейн транзакцией. Вопрос и ответ остаются в реестре, а остальные пользователи могут сверяться с этими данными.

Юридическая сила

Другая проблема — необходимость в новой регуляторной среде, которая учитывала бы возможности блокчейна и определила юридическую силу смарт-контрактов и внесенных в реестр данных, таких как права владения недвижимостью или предметами.

Недоверие к блокчейну

Блокчейн-технологии развиваются уже около десяти лет, если считать точкой отсчёта whitepaper Bitcoin, но в сравнении с другими технологиями и методиками, задействованными в современной финансовой системе, блокчейн остается молодой и не до конца зарекомендовавшей себя технологией. Из-за этого консервативные участники рынка относятся к нему скептически.

Смарт-контракт как угроза безопасности блокчейн-стартапа

Что же в итоге? Хотели модно, безопасно, блокчейн, а получаем дорогой неподдерживаемый код, который угрожает безопасности и вообще не нужен. Хотели, чтобы наши смарт-контракты выполнялись «в точности так, как запрограммированы, без какой-либо возможности простоя, цензуры, мошенничества или вмешательства третьей стороны», и в итоге они действительно выполняются так, как написаны — только написаны они с уязвимостью. И нам остаётся лишь помахать ручкой своим средствам. Ну или сделать хардфорк (тем самым вообще-то дискредитировав саму исходную идею), если из-за уязвимости потеряли деньги в том числе создатели Ethereum.

История

Первые идеи умных контрактов были предложены в 1994 году Ником Сабо.
Практические реализации стали возможными, благодаря появлению в 2008 году технологии блокчейн. Некоторые принципы умных контрактов были заложены в протоколе первой блокчейн-валюты Bitcoin, однако они не были реализованы в клиентском программном обеспечении, не обладали полнотой по Тьюрингу из соображений безопасности и не использовались на практике. С появлением технологии, стали высказываться идеи, что поверх протокола биткойна могут быть созданы различные протоколы более высокого уровня, включая полноценные умные контракты, по аналогии с тем как поверх TCP/IP существуют множество протоколов прикладного уровня.

Умные контракты впервые начали применяться на практике в проекте Ethereum. Идея создания проекта появилась в 2013 году. В тот момент основатель журнала Bitcoin Magazine Виталик Бутерин пришёл к выводу, что технология блокчейна может использоваться значительно шире, не только в криптовалютах. Он выдвинул идею универсальной децентрализованной блокчейн-платформы, в которой любой желающий может программно реализовать разные системы хранения и обработки информации. Главное условие — действия должны быть описаны как математические правила.

1. Как далёкие от технологий стороны могут обсуждать, составлять и корректировать смарт-контракты

Главное препятствие на пути широкого внедрения смарт-контрактов: сторонам придётся полагаться на доверенных технических экспертов, которые будут реализовывать соглашения в коде или подтверждать точность кода, написанного третьей стороной. Если вам пришла в голову аналогия с наймом юриста, чтобы тот объяснил юридические термины в обычном текстовом контракте, то она некорректна. Люди без юридического образования способны понять и простые, короткие соглашения, и многочисленные положения более длинных соглашений, особенно тех, которые определяют условия ведения бизнеса. Но если вы не умеете программировать, то вообще не разберётесь даже в самом примитивном смарт-контракте. Поэтому значимость эксперта, способного объяснить, что «говорится» в коде, гораздо выше.

В какой-то степени неспособность сторон разобраться в коде смарт-контракта не помешает им заключать вспомогательные программные соглашения. Дело в том, что можно создать и использовать много базовых функций и текстовых шаблонов, обозначающих, какие параметры нужно ввести и как они будут исполняться. Допустим, простая функция смарт-контракта списывает из кошелька одной из сторон пени за просрочку, если к назначенной дате не получена оплата. Однако стороне может понадобиться подтверждение, что программный код действительно выполнит то, что определено в тексте, и что дополнительных условий и параметров нет, особенно когда шаблон смарт-контракта не предусматривает ответственности за неточность программного кода. Для анализа кода придётся привлечь третью сторону, эксперта в программировании.

Если же шаблона нет и нужно разработать код с нуля, сторонам потребуется объяснить цель соглашения программисту. Просто дать копию юридического документа нецелесообразно, поскольку программисту придётся в нём разбираться. Поэтому сторонам, полагающимся на вспомогательные смарт-контракты, понадобится составить и показать программисту список условий, которые должен исполнять смарт-контракт.

Также стороны могут захотеть письменное подтверждение от программиста, что код работает как задумано. В результате для реализации требований, не учтённых в шаблоне, сторонам понадобится заключить письменное соглашение с программистом смарт-контрактов; это помимо контракта, который стороны могут заключить с поставщиком сервисов электронного обмена данными.

Страховые компании также могут разработать методики защиты сторон от рисков некорректного выполнения смарт-контрактом функций, определённых в текстовом соглашении. Хотя стороны могут проанализировать код (или возложить это на третью сторону), страховка даст дополнительную защиту на случай, если стороны не заметят ошибки при анализе кода. К тому же сторонам будет психологически комфортнее, если страховая компания сама проверит код, прежде чем застраховать их.

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

Наконец, по мере того как законность или действие смарт-контрактов всё чаще будет признаваться юридически, судам может потребоваться система назначаемых экспертов, которые станут помогать разбираться в компьютерном коде. Сегодня стороны прибегают к помощи своих экспертов, когда в центре дискуссии оказываются технические проблемы. Хотя у федеральных судов и судов штатов есть право назначать собственных экспертов, они редко им пользуются . Данный подход может потребовать изменений, если увеличится количество стандартных разбирательств вокруг интерпретации кода смарт-контрактов.

А что в итоге

А теперь давайте посмотрим, что у нас в Waves получилось. Напишем свой первый собственный контракт, пусть это будет стандартный контракт multisig 2-of-3. Для написания контракта можно использовать online IDE (тулинг для языка — тема для отдельной статьи). Создадим новый пустой контракт (New → Empty Contract).

Первым делом объявим публичные ключи Alice, Bob и Cooper, которые будут контролировать аккаунт. Необходимо будет 2 из их 3 подписей:

В документации описана функция , которая позволяет проверить подпись транзакции:

Аргументами функции являются тело транзакции, проверяемая подпись и публичный ключ. В контракте в глобальной области видимости доступен объект , в котором хранится информация о транзакции. У данного объекта есть поле , которое содержит байты отправляемой транзакции. Так же есть массив , в котором хранятся подписи, которых может быть до 8. Стоит отметить, что на самом деле в можно отправлять не только подписи, а любую другую информацию, которая может использоваться контрактом.

Мы можем убедиться, что все подписи представлены и они в верном порядке с помощью 3 простых строк:

Ну и последним шагом будет проверка, что представлено не менее 2 подписей.

Весь контракт мультиподписи 2 из 3 выглядит так:

Обратите внимание: в коде нет ключевых слов вроде , потому что последняя выполняемая строка считается результатом скрипта, и именно поэтому она всегда должна возвращать или

Для сравнения, распространенный контракт Ethereum для мультиподписи выглядит сильно сложнее. Даже относительно простые вариации выглядят так:

В IDE встроена консоль, которая позволяет сразу же компилировать контракт, задеплоить его, создавать транзакции и смотреть результат выполнения. А если вы хотите серьезно работать с контрактами, то рекомендую посмотреть на библиотеки для разных языков и плагин для Visual Studio Code.

Если у вас руки так и чешутся, то в конце статьи есть самые важные ссылки, с которых стоит начать погружение.

Понравилась статья? Поделиться с друзьями:
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: