Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Основы технологии блокчейн и криптовалют для менеджеров. Учебное пособие
.pdf
111
обеспечивает распределенное и децентрализованное выполнение
смарт-контрактов? Чтобы понять это, необходимо рассмотреть виртуальную машину Ethereum. Это сердце Ethereum, которое позволяет программировать блокчейн Ethereum.
Смарт-контракты Ethereum обычно пишутся на языках програм-
мирования высокого уровня. Самым популярным из них является
Solidity, который выглядит как смесь C ++ и JavaScript. Также существует Vyper – новый язык, находящийся в стадии разработки. Смартконтракты, написанные на этих языках программирования высокого
уровня, должны быть скомпилированы до кода виртуальной машины
Ethereum (Ethereum Virtual Machine) – сокращенно кода EVM.
Таким образом, мы переходим с более высокого уровня, удобо-
читаемого языка, и компилируем его в код EVM, который является более простым языком более низкого уровня – гораздо более простым для
понимания и выполнения машиной. После того как код скомпилирован
в код EVM, каждый узел в сети Ethereum выполняет его. И все узлы
выполняют код одинаково, если у них установлена последняя версия
программного обеспечения EVM.
Ethereum – это распределенный компьютер, потому что каждый
узел выполняет смарт-контракты Ethereum. Затем узлы приходят к консенсусу по поводу нового состояния системы. Это должно быть довольно знакомо, поскольку каждый полный узел в биткоин хранит свою
собственную бухгалтерскую книгу, что делает каждый узел банком.
В биткоин узлы приходят к консенсусу относительно того, кто какими
UTXO владеет.
А в Ethereum после выполнения кода EVM узлы приходят к консенсусу в отношении общего состояния сети. И как на самом деле узлы приходят к консенсусу? С помощью Proof-of-Work. Тот же протокол распределенного консенсуса, который используется в биткоин, также используется в Ethereum. Конечно, есть различия между реализациями Proof-ofWork Ethereum и Bitcoin, но общие концепции определенно похожи.
Помните, что Proof-of-Work требует от майнеров расходовать вычислительные мощности, чтобы увеличить свои шансы на предложение
блоков сети. Нет настоящего разумного способа решить хеш-головоломку, поэтому майнерам приходится применять грубую силу, т. е. перебирать все возможные варианты. А связав право голоса с вычислительной мощностью, физическим ресурсом реального мира, мы можем
предотвратить атаки Сибиллы.
112
Вот некоторые различия между алгоритмами Proof-of-Work биткоин и Ethereum. В Ethereum время создания блока составляет 15 секунд, а в биткоине – 10 минут. Это позволяет довольно быстро выполнять и дорабатывать смарт-контракты. Однако такое быстрое время
блока действительно увеличивает количество естественных форков
и потерянных блоков, но это учитывается в протоколе Ethereum.
Ранее мы рассматривали алгоритм доказательства работы биткоин, а также то, как он связан вычислениями и использует sha-256.
В Ethereum алгоритм доказательства работы называется Ethash. Ethash
привязан к памяти и утверждает, что устойчив к ASIC. Однако скорость
хеширования сети Ethereum значительно ниже, чем у биткоин.
Майнеры в Ethereum конкурируют с созданием блоков, выполняя
код EVM и ища решение задачи. Как и раньше, Proof-of-Work – это соревнование, и только один майнер может добавить блок в цепочку блоков
Ethereum и получить соответствующее вознаграждение. Proof-of-Work –
это, по сути, способ случайного выбора в зависимости от доли хеш-мощности, результата выполнения одного узла для добавления в блокчейн.
Каждый узел Ethereum запускает виртуальную машину Ethereum
как часть процедуры проверки блока. Как и прежде, сетевой консенсус
устраняет необходимость в доверенном третьем лице. Чтобы нарушить
смарт-контракты, придется разрушить всю сеть. Таким образом, это
позволяет реализовать одноранговые соглашения, которые навсегда
остаются в цепочке блоков.
Код контракта выполняется виртуальной машиной Ethereum, или
сокращенно EVM, как упоминалось ранее. Код контракта компилируется,
и код, который фактически выполняется на каждом узле, является кодом
EVM. А код EVM – это язык байт-кода на основе стека низкого уровня.
Если вы знакомы с JVM (Java Virtual Machine – виртуальная машина Java, основная часть исполняющей системы Java), это похоже на то,
как языки JVM, такие как Java, Scala и Groovy, компилируются до байткода JVM. Тот факт, что мы можем скомпилировать сложный код смартконтракта в простые понятные для машины инструкции в форме кода
EVM, который все узлы в сети могут выполнять одним и тем же детерминированным образом, обеспечивает основу для консенсуса в Ethereum.
Поскольку каждый узел в сети Ethereum выполняет смарт-контракты, мы сталкиваемся с одной непосредственной проблемой: что,
если контракт имеет бесконечный цикл? Контракт помещается в сеть
Ethereum, и кто-то вызывает функцию, в которой есть бесконечный
цикл, и все узлы видят эту транзакцию и начинают выполнять
113
бесконечно эту функцию. Таким образом, каждый узел в сети застрял
бы в выполнении этого бесконечного цикла.
А благодаря проблеме остановки, когда даны описание процедуры и ее начальные входные данные и требуется определить, завершится ли когда-либо выполнение процедуры с этими данными либо эта
процедура все время будет работать без остановки, мы знаем, что невозможно заранее определить, будет ли когда-либо прекращен данный
контракт. И все это приводит к очень простому способу для злоумышленников запускать атаки отказа в обслуживании: путем захвата компьютеров по всему миру бесконечным циклом, что делает их неспособными выполнять другие, более значимые контракты.
К счастью, разработчики Ethereum подумали об этом и реализовали решение – в виде так называемого газа. До сих пор мы особо не
обсуждали концепцию газа в Ethereum, но она играет центральную роль
в том, как работают транзакции и как майнеры стимулируются для проверки блоков в цепочке блоков Ethereum. Газ – это то, что способствует
выполнению данного контракта. Газ – это схема измерения Ethereum,
которая учитывает используемую полосу пропускания, стоимость хранения и стоимость вычислений в блокчейне Ethereum.
Каждая вычислительная операция в EVM потребляет газ, а различные вычисления, например сложение или умножение, потребляют
разное количество газа. В Ethereum имеется список расхода газа для
различных операций и расчетов. Все операции во время выполнения
транзакции, включая чтение и запись базы данных, сообщения и каждый вычислительный шаг, выполняемый виртуальной машиной, потребляют определенное количество газа. Следовательно, для каждой
инициируемой транзакции должна существовать гарантия, что атаки
типа «отказ в обслуживании» в сети могут быть предотвращены и что
майнеры получат вознаграждение за добавление транзакции в блок. Поэтому каждому операционному коду EVM для выполнения требуется
«газ», тем самым предотвращается упомянутая атака отказа в обслуживании с бесконечным циклом.
Таким образом, каждая транзакция определяет два параметра:
«начальный газ», или максимальное количество «газа», которое транзакция желает потреблять, и «цена газа», или комиссия в монетах
«эфира», которую контракт готов платить за единицу газа. Выглядит
это следующим образом:
1) Каждая транзакция должна указывать количество «газа», кото-
рое она готова потреблять (вызывается startgas), чтобы покрыть
114
использование вычислений EVM и любое используемое хранилище или
полосу пропускания.
2) Отправитель транзакции также должен указать комиссию, которую он готов платить за единицу «газа» (gasprice). В начале выполнения «эфир», как произведение startgas*gasprice, удаляется со счета
отправителя транзакции, чтобы гарантировать, что майнер получит комиссию, даже если учетная запись пользователя обанкротится на полпути во время выполнения.
3) Если операция gas_rem транзакции выполнена полностью,
и при этом было использовано меньше «газа», чем указанный лимит, то
в конце выполнения отправитель транзакции получает возмещение, произведение gas_rem*gasprice, а майнер блока получает награду
произведение (startgas–gas_rem)*gasprice. Как упоминалось ранее, эта
«комиссия майнера» откладывается в самом начале транзакции.
4) Если в середине выполнения транзакции «заканчивается газ»,
то все выполнение возвращается, но транзакция тем не менее действительна, и единственный результат транзакции – передать всю сумму
произведения (startgas * gasprice) майнеру.
Весь этот «газовый бизнес» состоит в том, чтобы убедиться, что
злонамеренный узел или хакер не может просто загрузить сеть
Ethereum вредоносными транзакциями (такими, как бесконечный
цикл), не неся слишком дорогих затрат. Идея здесь заключается в том,
что, хотя выполнение контракта отменяется, кто-то в сети должен был
вложить вычислительную мощность для выполнения кода EVM. И как
только газ израсходован, это доказательство того, что кто-то выполнил
программу. Таким образом, это дает нам два конечных состояния: либо
программа завершается, либо заканчивается «газ». Ethereum по-прежнему позволяет кому-то писать бесконечный цикл в смарт-контракте.
Тем не менее злоумышленник, пытающийся атаковать сеть, должен заплатить достаточно эфира для финансирования DoS-атаки.
В некотором смысле вы можете думать о покупке «газа» как
о цене, которую вы должны заплатить за использование этой распределенной и не требующей наличия чувства доверия вычислительной мощности. Таким образом, это лишает пользователей стимулов к запуску
дорогостоящих вычислений без достаточных средств. Поскольку каждое вычисление требует «газа», злоумышленнику, осуществляющему
DoS-атаку в сети, потребуется абсурдно большое количество эфира,
а поскольку атака настолько дорогостоящая, это в значительной степени препятствует атаке такого типа.
115
Мы упоминали, что узлы приходят к консенсусу по состоянию
сети и выполнение кода в EVM изменяет состояние. В некотором
смысле можно думать о EVM как о базовом механизме перехода между
состояниями. Когда мы выполняем транзакцию, мы переходим из
предыдущего состояния в новое. И в любой момент времени конечное
состояние представляет текущее состояние сети Ethereum.
Итак, вы начинаете с текущего состояния блока, требуемого
«газа», текущей памяти, транзакции, вызывающей контракт, сообщения, которое в основном содержит метаданные транзакции, код контракта, а также счетчик стека и программы – практически все, что
нужно для правильного выполнения транзакции. И вы вводите это
в EVM и получаете новое состояние блокировки со всеми обновленными балансами счетов и внутренним состоянием, а также новой стоимостью «газа», которая возвращается.
Итак, некоторые выводы об архитектуре высокого уровня
Ethereum. Основная цель Ethereum – не оптимизировать вычислительную
эффективность, а обеспечить возможность распределенных вычислений
без необходимости наличия доверия к другой стороне. Каждый узел
в сети должен выполнять одни и те же вычисления, поэтому Ethereum является избыточно параллельным. И все это для эффективного достижения
консенсуса по состоянию системы без использования доверенных третьих сторон. И поскольку выполнение контрактов дублируется на всех
узлах, выполнение является дорогостоящим. Например, вам не следует
обучать модели машинного обучения или делать что-либо еще дорогостоящее с вычислительной точки зрения непосредственно на смарт-контрактах. Можно надеяться, что это не будет стимулом использовать блокчейн для вычислений, которые могут выполняться вне сети.
Далее мы ознакомимся как с базовыми, так и с расширенными
вариантами использования смарт-контрактов. В этих случаях рассмотрим, как можно использовать конкретное свойство цепочки блоков, для
того чтобы продемонстрировать уникальные и значимые функции,
предоставляемые блокчейном.
Первый возможный вариант использования – это интеллектуальный актив, или токен, построенный на основе существующей в настоящее время цепочки блоков. Это буквально создает вашу собственную
валюту поверх другой валюты. Все, что нужно сделать, – это убедиться,
что пользователь, который хочет потратить деньги, имеет средства,
прошел аутентификацию и не тратит дважды.
Протоколы аутентификации и двойного расходования встроены
в Ethereum, поэтому единственная логика, которую должен
116
обрабатывать смарт-контракт, – это проверка средств. Таким образом,
для работы требуются только две основные функции: структура хранения для связывания адресов с активами и функция send () для передачи
активов. Это демонстрирует, что создание приложения на основе блокчейн Ethereum позволяет вам использовать существующие в настоящее
время протокол и процедуры блокчейн. Все, что нужно предоставить
пользователю, – это базовая безопасная логика для воплощения в жизнь
желаемого варианта использования блокчейн.
Следует отметить, что создание функциональных смарт-контрактов и создание безопасных смарт-контрактов – это две совершенно разные вещи. Защита смарт-контрактов невероятно сложна, как вы могли
догадаться из последних новостей о взломах смарт-контрактов.
Еще один значимый вариант использования смарт-контрактов –
кошельки с мультиподписью. Теперь мы можем включить ту же функциональность в Ethereum в удобочитаемой форме. Здесь можем использовать встроенные протоколы аутентификации для создания кошелька
для многосторонней аутентификации. Эта функция позволяет нам
иметь схему подписи m из n, в которой m адресов из общего числа
n владельцев кошелька должны подписываться при каждой транзакции.
Это гарантирует, что никто не может контролировать средства. Несмотря на то что логику достаточно легко описать, реализация Solidity
довольно сложна. Компания Parity, создавшая кошельки с мультиподписью, дважды была взломана из-за необнаруженных уязвимостей.
Допустим, мы придумали новый термин и желаем доказать, что
придумали его раньше всех, но пока не хотим раскрывать это модное
слово публике. Как сделать это, чтобы все доверяли? Можно это сделать, только объединив хеш-функции и надежный блокчейн. Мы храним хеш нашего документа в блокчейне. Поступая таким образом, можем доказать всем в любой момент позже, что именно мы включили
этот хеш в блокчейн и что наша информация не была изменена. Таким
образом, мы «доказали существование» некоторой информации в определенный момент времени.
С Proof-of-Existence (доказательство существования) используем
как публичную возможность аудита, так и неизменяемость блокчейн.
Кроме того, есть возможность внедрить децентрализованную систему
DNS. «DNS» означает «система доменных имен», и его единственная
цель – связать URL-адреса с IP-адресами. В смарт-контракте мы можем
легко разработать схему, которая создает ассоциации между именами
и значениями.
117
Г л а в а 7 . К О Р П О Р А Т И В Н Ы Е Б Л О К Ч Е Й Н - П Л А Т Ф О Р М Ы
Прежде чем оценить возможность создания и сценарии использования корпоративных блокчейн-платформ, необходимо ответить на
множество вопросов, например таких как: Что такое корпоративный
блокчейн? Какие проблемы мы пытаемся решить, используя блокчейнплатформы? И может быть, эти проблемы можно решить, используя
традиционные методы? Что лучше: открытые децентрализованные или
надежные централизованные корпоративные блокчейн-платформы?
Начнем с истории корпоративного блокчейн. По мере того как
блокчейн и созданные на его основе криптовалюты, например биткоин,
становились все более популярными, банки и крупные корпорации
начали обращать внимание на потенциальные возможности применения этой новой технологии. И это несмотря на то что в самой идее биткоин заложено стремление устранить потребность в банках, создав общедоступный распределенный реестр. Банки же хотят использовать ту
же технологию блокчейн, однако сохранив свои экономическую силу
и общественное влияние посредством создания «закрытых блокчейн»
или частных сетей, в которых некий центральный орган контролирует,
кто может, а кто не может принимать участие в консенсусе и подтверждать транзакции в сети, по сути предлагая сохранить существующую
финансовую систему.
Это желание финансовых структур в конечном итоге привело
к появлению «закрытых» корпоративных блокчейн, которые не были
открытыми и не имели экономических стимулов для своего развития.
Однако на самом деле цель создания корпоративных блокчейн-платформ заключалась не в создании еще одной общедоступной сети блокчейн, такой как биткоин, а в отделении технологии блокчейн от криптовалют с целью посмотреть, как технология блокчейн может применяться в бизнесе для повышения его конкурентоспособности. Подходы
были совершенно разные. Одни разработчики в корпоративных блокчейн-платформах увидели только криптографию с открытым ключом,
которая способствовала проведению пиар-мероприятий, повышению
трафика и цен на акции. В то же время другие поощряли исследования
фундаментальных технологий блокчейн, поскольку они более совместимы и лучше подходят для корпоративного использования, чем связанные с ними общедоступные системы блокчейн.
118
Несмотря на то что для корпоративных блокчейн существует
множество вариантов использования, большинство проблем, которые
корпоративный блокчейн пытается решить, попадают в три основные
категории:
– устранение сбоев координации;
– горизонтальная интеграция систем;
– создание самостоятельных децентрализованных систем.
Сейчас множество компаний хотят воспользоваться преимуществами технологии блокчейн, однако пока нет общепризнанных стандартов, а существующие корпоративные блокчейн-решения часто носят ситуационный характер.
В своем текущем состоянии блокчейн делает отдельный компьютер значительно менее эффективным, поскольку каждый компьютер
как узел в сети должен выполнять те же вычисления, что и все остальные узлы сети. Чтобы прийти к консенсусу, эти узлы должны затем связываться с другими узлами по всему миру, что дополнительно вызывает
проблемы с задержкой. В результате блокчейн гораздо менее масштабируем, чем традиционные системы. В итоге это приводит к тому, что
корпоративный блокчейн ограничен определенными требованиями
к масштабированию и вариантам использования, которые сделали бы
решение, не связанное с блокчейн, невозможным.
Существующий опыт применения технологии блокчейн в промышленности показал, что корпоративные блокчейн-платформы наиболее оптимально использовать для устранения сбоев координации, горизонтальной интеграции различных систем (производственных, логистических) и создания самостоятельных распределенных и децентрализованных сетей. Сбои в координации между несколькими сторонами, стремящимися к совместной работе, часто возникают из-за проблем с доверием,
которую можно решить с помощью технологии блокчейн.
Блокчейн также является технологией интеграции – он объединяет
разрозненные хранилища данных в единую интегрированную систему,
которая обеспечивает большую экономию на масштабе. Обеспечивая
неизменность, целостность, возможность аудита подлинности данных,
блокчейны применяют общие стандарты данных (например API), позво-
ляя сразу же взаимодействовать между несколькими системами. Наконец, блокчейн предоставляет новые децентрализованные модели для работы наряду с существующими централизованными, тем самым предотвращая возможность централизованного изменения данных.
119
На самом базовом уровне блокчейн – это просто узкоспециализированная база данных. Рассмотрим очень обобщенную классификацию баз данных. По сути, у нас могут быть централизованные или распределенные базы данных. Централизованные базы данных управляются одной организацией (например, компанией), которая обрабатывает все запросы и данные. Конечно, при наличии централизованной
базы данных мы должны доверять одной базе данных, и здесь консенсуса достичь невозможно, поскольку нет еще как минимум одного источника, подтверждающего подлинность полученных данных.
В случае с распределенными базами данных идея доверия становится более важной. Распределенные базы данных управляются группой узлов хранения данных, которые связаны друг с другом и работают
для поддержания согласованного общего представления всей системы.
В некоторых системах узлы способны полностью доверять друг другу.
В распределенных базах данных может быть реализована сеть надежных отказоустойчивых баз данных. Однако в распределенных базах
данных мы также можем иметь распределенные реестры, которые
обычно подразумевают более слабые гарантии доверия. Они позволяют
сторонам, которые не полностью доверяют друг другу, прийти к консенсусу.
И наконец, блокчейн – это подкласс распределенных реестров.
Распределенные реестры – это определенный тип распределенной базы
данных, в которой информация организована в хронологическом порядке, имитируя традиционный реестр. Чаще всего узлы хранения не
могут полностью доверять друг другу. Вместо этого они должны внедрить некоторую форму консенсусного протокола, чтобы иметь последовательное представление о системе.
Теперь некоторые замечания. Одно замечание заключается в том,
что необходимо отличать термин «распределенный», который характеризует пространственные аспекты базы данных, от термина «централизованный/децентрализованный», который характеризует способы «политического» устройства базы данных. Например, мы можем называть
системы баз данных организации централизованными, потому что все
они управляются одной организацией, а значит, они политически централизованы. А с точки зрения географии и пространства мы могли бы
иметь единую «центральную» базу данных или несколько баз данных,
географически централизованных или децентрализованных.
Централизованные базы данных, такие как сервер с одним паролем, размещаются, хранятся и обслуживаются в одном месте
120
и управляются одной центральной организацией, обрабатывающей все
запросы и обработку данных. В этом есть определенные преимущества:
простота конструкции, немедленное обновление данных, экономическая эффективность и минимальное резервирование. Однако централизованные базы данных также имеют множество недостатков:
– склонны к возникновению узких мест, когда производительность, или пропускная способность системы ограничена одним или несколькими компонентами или ресурсами;
– отсутствуют возможности одновременного доступа нескольких
пользователей для записи к одному и тому же набору данных;
– могут действовать как единая точка отказа, отчего база данных
становится менее отказоустойчивой.
С другой стороны, распределенные базы данных состоят из групп
узлов, которые взаимодействуют и доверяют друг другу, чтобы показать наличие системы в целом и поддерживать ее работу. Поскольку
больше нет единой точки отказа, система становится более отказоустойчивой и может справиться с большим спросом, равномерно распределяя нагрузку по всем узлам. Однако для распределенных баз данных характерны повышенные сложность, стоимость и избыточность,
а также большее количества точек отказа. Все это повышает издержки,
связанные с распространением данных.
Особым типом распределенной базы данных является распределенный реестр. Он содержит узлы, управляемые разными организациями, которые могут доверять или не доверять друг другу. Хотя для распределенных реестров существует множество механизмов консенсуса,
те протоколы консенсуса, которые специально реализуют цепочку бло-
ков в своих записях, известны как блокчейн.
Блокчейны также можно разделить на категории в зависимости
от их архитектуры, а также доверия и доступа – разрешения, которыми
обладает обычный пользователь. В большинстве случаев все блокчейны относятся либо к общедоступной, либо к закрытой категории.
Еще в 2015 г. Виталий Бутерин, один из основателей системы
Ethereum, определил три разных типа блокчейн в зависимости от их типов доступа:
– публичный блокчейн;
– блокчейн консорциума: «цифровая книга», принадлежащая
консорциуму, которая может быть запрограммирована на запись любых
транзакций; все транзакции там координируются узлами, выбранными
консорциумом;
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]