Добрый день! Ранее у нас в блоге были посты на блокчейн темы, в которых нередко возникали дискуссии о распределенных вычислениях в блокчейне. По мотивам этих дискуссий и возник этот пост.
Итак давайте попробуем сегодня разобраться, что такое смарт-контракты (умные контракты). Сначала мы достаточно общо обсудим сам концепт, а потом немного копнем в реализацию смарт-контрактов на примере блокчейна Ethereum.
О концепте смарт-контрактов
Термин «смарт-контракт» уже устоялся и по сути обозначает определенный код, который выполняется на какой-либо блокчейн-платформе таким образом, что его выполнение проверяется независимыми сторонами.
Что это значит? Это распределенные вычисления? В привычном нам понимании все же нет.
Когда мы говорим о распределенных вычислениях, обычно подразумевается распределение нагрузки. Скажем, у нас есть задача посчитать в огромном текстовом файле вхождения определенного слова. Мы режем файл на несколько частей, раздаем эти части на разные ноды (например, используя Hadoop), каждая выполняет подсчет и выдает ответ. Мы суммируем ответы и получаем результат. Таким образом мы значительно ускоряем выполнение задачи.
Если же говорить о смарт-контрактах, то тут совсем другая ситуация. Тут мы не режем файл на отдельные части, мы каждой ноде отдаем весь файл целиком, и каждая нода выдает нам один и тот же результат (в идеале). Вернемся к нашему вопросу: попадает ли такое действие под определение распределенных вычислений? Ну в целом почему нет? Они же распределены и они же вычисления? Только в данном случае мы говорим не о распределении нагрузки, а о распределении доверия.
И да, необходимо отметить, что такой концепт сложно масштабируется, потому что в него изначально не заложены необходимые механизмы. Для чего же может быть нужна такая конструкция? Наиболее очевидный пример — это создание общественного договора (контракта) между двумя и более сторонами. Отсюда и название концепта — «смарт-контракт». Стороны фиксируют договоренности и условия выполнения того или иного сценария развития отношений между собой, при помощи языка программирования, таким образом, что наступление определенных событий будет автоматически вызывать выполнение предопределенного кода.
Классический пример подобного контракта, описанный еще в 1996 году Ником Сабо, — вендинг-машина. Она работает всегда автоматически по строгому набору правил: вы вносите деньги, делаете выбор — машина отдает товар. Внеся деньги, вы не можете передумать и попросить их вернуть. В случае с умным контрактом код становится своего рода законом, его нельзя оспорить, и он всегда будет выполняться при наступлении необходимых условий.
Здесь необходимо сделать уточнение, что текущие реализации смарт-контрактов (далее мы будем говорить о сети Ethereum) все же по сути история, замкнутая в блокчейн-среде. Что это значит? Нельзя написать контракт, который будет получать данные извне (например, от поставщиков данных о погоде) и реализовывать логику на этих данных. Тут есть определенный подвижки, например Microsoft работает над концептом криплетов или существуют, так называемые, ораклы, но пока, думаю, там есть куда расти.
Потому предложу другой пример смарт-контракта, который замкнут полностью в блокчейне. Лотерея, причем абсолютно честная и прозрачная. Вы отправляете транзакцию на адрес смарт-контракта, и он по заранее заложенной в нем логике (пусть в ней будет какой-то рандомизатор) принимает решение, выиграли вы или нет. Если вы выиграли, вы получаете весь накопленный в смарт-контракте куш, а если проиграли, то ваша транзакция идет в общую копилку для будущих игроков.
Все эти примеры относительно просты и несколько оторваны от реальной жизни. Какую же пользу можно извлечь из работы умных контрактов, если подходить к ним серьезно? Сам концепт проверяемого исполнения кода позволяет строить системы, которые ранее были недоступны или же их создание было сильно затруднено.
Положим, у вас есть определенное сообщество, в котором необходимо принять какое-то решение. Допустим, это решение крайне важное, и сообщество не склонно просто так довериться отдельным своим членам. Возьмем как пример консорциум банков. Логично предположить, что ни один член консорциума не захочет делегировать проведение вычислений одному банку, особенно когда на основании этих вычислений будет приниматься наше «самое важное решение». Ведь, отдав и данные, и возможность проводить эти вычисления в одни руки, вы можете поставить свой бизнес в рискованное положение, и даже открытый код вычислений не убедит вас в правильности выполнения этого кода на чужом сервере. Вы захотите это выполнение проверить. И вот тут мы получаем ту самую пользу из концепта проверяемого исполнения: участники способны объединяться для выполнения общей задачи или принятия решения без центрального оператора и таким образом повышать эффективность своих бизнесов.
Да, смарт-контракты не слишком-то масштабируются в текущих реализациях, потому что в них это не заложено. Но даже сейчас можно тяжелые вычисления проводить вне среды смарт-контрактов и фиксировать в них лишь определенные опорные точки, о которых стороны могут договориться на берегу, таким образом достигнув в каких-то сценариях необходимой скорости работы.
Техническая сторона вопроса
Теперь попробуем поговорить о технической стороне реализации смарт-контрактов на примере блокчейн Ethereum. Как выглядит процесс написания, публикации и выполнения смарт-контракта?
В этой сети для написания смарт-контрактов используется язык Solidity, который несколько похож на JS, и он является Тьюринг-полным (то есть на нем можно реализовать любую вычислимую функцию).
Сам код выполняется в так называемом Ethereum Virtual Machine (EVM). Надо обратить внимание, что код выполняется и проверяется всеми участниками системы, потому необходим некий механизм, который как-то ограничит потребление ресурсов каждым смарт-контрактом (иначе можно бесконечный цикл написать). Потому в Ethereum введена сущность gas (топливо). Контракт в Ethereum может выполнять любые инструкции, вызывать другие контракты, писать и читать данные и так далее. Все эти операции потребляют топливо, топливо оплачивается криптовалютой (Ether). Цена на топливо криптовалюты Ethеr формируется динамически рынком. Триггером выполнения контракта является транзакция. Стоимость топлива, которое сжигается в определенной транзакции, снимается с аккаунта, который транзакцию запустил. Кроме того, есть лимит потребления топлива, сделан он для того, чтобы защитить аккаунт от ошибок в написании контракта, которые могут привести к бесконтрольному сгоранию всей криптовалюты на данном аккаунте.
Важно отметить, что среда смарт-контрактов все же сильно отличается от привычной нам среды выполнения кода. Ошибка может стоить очень дорого, сами операции дорогие и медленные. Затруднен механизм обновления смарт-контракта. Вы, по сути, пишете новый и должны убедить стороны использовать этот новый смарт-контракт. Нельзя сказать, что никак не перейти на новую версию своего контракта, но это часто новый общественный договор. Если вдуматься — разительное отличие, когда вы привыкли просто выкатывать апдейты вашей централизованной системы потребителям, не слишком интересуясь их мнением. Строя какую-то систему для работы в реальных жизненных сценариях на смарт-контрактах, стоит понимать эти ограничения.
Автор: Ramon
