Добрый день! Ранее у нас в блоге были посты на блокчейн темы, в которых нередко возникали дискуссии о распределенных вычислениях в блокчейне. По мотивам этих дискуссий и возник этот пост.

Итак давайте попробуем сегодня разобраться, что такое смарт-контракты (умные контракты). Сначала мы достаточно общо обсудим сам концепт, а потом немного копнем в реализацию смарт-контрактов на примере блокчейна Ethereum.

О концепте смарт-контрактов


Термин «смарт-контракт» уже устоялся и по сути обозначает определенный код, который выполняется на какой-либо блокчейн-платформе таким образом, что его выполнение проверяется независимыми сторонами.

Что это значит? Это распределенные вычисления? В привычном нам понимании все же нет.

image

Когда мы говорим о распределенных вычислениях, обычно подразумевается распределение нагрузки. Скажем, у нас есть задача посчитать в огромном текстовом файле вхождения определенного слова. Мы режем файл на несколько частей, раздаем эти части на разные ноды (например, используя Hadoop), каждая выполняет подсчет и выдает ответ. Мы суммируем ответы и получаем результат. Таким образом мы значительно ускоряем выполнение задачи.

Если же говорить о смарт-контрактах, то тут совсем другая ситуация. Тут мы не режем файл на отдельные части, мы каждой ноде отдаем весь файл целиком, и каждая нода выдает нам один и тот же результат (в идеале). Вернемся к нашему вопросу: попадает ли такое действие под определение распределенных вычислений? Ну в целом почему нет? Они же распределены и они же вычисления? Только в данном случае мы говорим не о распределении нагрузки, а о распределении доверия.

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

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

Здесь необходимо сделать уточнение, что текущие реализации смарт-контрактов (далее мы будем говорить о сети Ethereum) все же по сути история, замкнутая в блокчейн-среде. Что это значит? Нельзя написать контракт, который будет получать данные извне (например, от поставщиков данных о погоде) и реализовывать логику на этих данных. Тут есть определенный подвижки, например Microsoft работает над концептом криплетов или существуют, так называемые, ораклы, но пока, думаю, там есть куда расти.

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

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

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

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

Техническая сторона вопроса


Теперь попробуем поговорить о технической стороне реализации смарт-контрактов на примере блокчейн Ethereum. Как выглядит процесс написания, публикации и выполнения смарт-контракта?

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

Сам код выполняется в так называемом Ethereum Virtual Machine (EVM). Надо обратить внимание, что код выполняется и проверяется всеми участниками системы, потому необходим некий механизм, который как-то ограничит потребление ресурсов каждым смарт-контрактом (иначе можно бесконечный цикл написать). Потому в Ethereum введена сущность gas (топливо). Контракт в Ethereum может выполнять любые инструкции, вызывать другие контракты, писать и читать данные и так далее. Все эти операции потребляют топливо, топливо оплачивается криптовалютой (Ether). Цена на топливо криптовалюты Ethеr формируется динамически рынком. Триггером выполнения контракта является транзакция. Стоимость топлива, которое сжигается в определенной транзакции, снимается с аккаунта, который транзакцию запустил. Кроме того, есть лимит потребления топлива, сделан он для того, чтобы защитить аккаунт от ошибок в написании контракта, которые могут привести к бесконтрольному сгоранию всей криптовалюты на данном аккаунте.

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

Комментарии (14)


  1. reinvent
    15.09.2017 14:17

    В связи с чем у Лаборатории Касперского такой интерес к блокчейну?
    Блокчейн влияет (или может повлиять) на рынок антивирусов?


    1. Ramon Автор
      15.09.2017 14:50

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


      1. Coffin
        15.09.2017 15:36
        +1

        Секркретная разрбатока антивируса на блокчейней и предстоящее его ICO :)


  1. Dronsky
    15.09.2017 17:03

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


    1. Ramon Автор
      15.09.2017 17:05

      вы конкретно про банки или вообще? я вообще отвечу. на вскидку вот список обширный: www.cryptocoinsnews.com/smart-contracts-12-use-cases-for-business-and-beyond

      другой пример: голосование акционеров и контроль подсчета голосов.

      но надо, конечно, отдавать отчет, что во многих случаях очень часто все упирается у регуляторку и опасения участников.


      1. AlexeyVPolunin
        19.09.2017 03:01

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


        1. Ramon Автор
          19.09.2017 03:03

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


          1. AlexeyVPolunin
            19.09.2017 08:10

            Насчет вагона с сахаром я погорячился. Это несколько неудачный пример. Но вот пример, который уже давно функционирует и имеет много признаков «настоящего» смарт-контракта. Я имею ввиду покупку товара на Алиэкспрессе. Выбрав товар, мы его оплачиваем, деньги поступают на аккаунт продавца, но пока ему недоступны. Средства разблокируются либо спустя определенное число дней после отправки товара, либо после подтверждения покупателем получение товара и удовлетворенностью его качеством. Иногда посылки не доходят и часто качество страдает, но покупатель имеет возможность выставить претензию, которую рассматривает уже администрация Алиэкспресса.
            Другими словами, в этой схеме велико значение человеческого фактора. Махинации возможны со стороны всех участников процесса, хотя, на первый взгляд, процесс достаточно формализован.
            Поясните, как можно уменьшить значение человеческого фактора в смарт-контрактах, например, на базе Эфириума?


  1. potan
    15.09.2017 17:20

    На сколько я понимаю, ошибки в разработке смартконтрактов будут обходится очень дорого. Может кто-нибудь занимается применением к ним систем формальной верификации? Мне попадался backend Idris (языка с зависимыми типами, позволяющего доказывать корректность программ), компилирующий в Solidity, но мне он показался сырым.


    1. Ramon Автор
      15.09.2017 17:43
      +1

      да, есть такое, вот например исследование: www.cs.umd.edu/~aseem/solidetherplas.pdf

      Несколько месяцев назад общались с сингапурскими студентами на эту тему, вот их проект тут на тему формальной верификации: www.comp.nus.edu.sg/~loiluu/oyente.html

      Плюс пока искал наткнулся на еще один проект: securify.ch

      А еще есть Tezos, которые обещают вставить формальную верификацию в протокол. Но обещанного три года ждут )


  1. Pro100Oleh
    16.09.2017 15:09

    Имхо неудачный пример с лотереей. Главное требование к смарт контрактам — что следующее состояние для нового блока вычисляется однозначно. Когда одна нода майнит следующий блок, то все остальные ноды перепроверяют транзакции внутри нового блока — повторяют вычисления смарт контрактов. При этом состояние транзакций обязано совпасть. Не понимаю как в данной модели можно впихнуть функцию «рандом» в вычисления.


    1. Ramon Автор
      16.09.2017 15:13

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

      1. игроки генерят N и «прикапывают»
      2. хэшируют N и присылают хэши и депозиты в контракт
      3. по достижению критерия (достаточно игроков или депозит достиг чего-то), N раскрывают и тоже присылают
      4. каждая N проверяется на соответствие хэшу
      5. дальше скажем все N как-нибудь обрабатываются. xor или еще можно что-то придумать
      6. получаем в итоге некое случайное число и уже в зависимости от него решаем, кто победит.

      схема может быть не идеальной, но варианты возможны.


    1. itforge
      17.09.2017 02:02
      -1

      Банально смотрим хэш предыдущего блока, это будет рэндомное число.


      1. Ramon Автор
        19.09.2017 03:01

        ну он виден всем, нужен все же вариант, который никому заранее не виден.