Умные контракты: хорошие, плохие и ленивые

Почему частные блокчейны не должны стремиться запускать код

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

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

Так ли светлое будущее для умных контрактов в частных блокчейнах? Ну, вроде как, но не совсем. Вы видите, проблема в том, что:

В частных блокчейнах умные контракты объединяют четыре хорошие идеи с одной плохой.

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

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

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

Понимание Эфириума

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

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

Приняв участие в некоторых из этих проектов, Виталик Бутерин поставил простой, но блестящий вопрос: почему бы не создать единую общедоступную цепочку блоков, которая может быть запрограммирована, вместо множества цепочек блоков для конкретных приложений? все, что мы могли бы хотеть? Этот über-blockchain был бы бесконечно расширяемым, ограниченным только воображением тех, кто его использует. Мир крипто-энтузиастов был почти единодушно убежден этой мощной идеей. И так, с 18 миллионов долларов в виде краудфандинга и с большим волнением родился Эфириум.

Ethereum - это новый публичный блокчейн со связанной криптовалютой под названием «эфир», например сотни который был до него. Но в отличие от других блокчейнов, Ethereum позволяет любому создать «контракт» внутри блокчейна. Контракт - это компьютерная программа со связанной миниатюрной базой данных, которая может быть изменен только программой, которой он принадлежит. Если пользователь блокчейна хочет изменить базу данных, он должен отправить в свой контракт сообщение с цифровой подписью. Код в контракте проверяет это сообщение, чтобы решить, как реагировать. (Этот "инкапсуляции»Кода и данных также является основой объектно-ориентированный программирование.)

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

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

Чтобы привести пример, простой Ethereum договор субкурса поддерживает базу данных пользовательских балансов для конкретного актива. Если он получит сообщение о переводе средств от Алисы к Бобу, он (а) проверит, что сообщение было подписано Алисой, (б) проверит, достаточно ли у Алисы средств, (в) переведет средства с Алисы на счет Боба в базе данных и (г) ответить, что операция прошла успешно. Конечно, нам не нужен Ethereum для этого, потому что простой блокчейн в биткойн-стиле с поддержка собственных активов может сделать то же самое. Ethereum действительно вступает в свои права в отношении сложной многоэтапной бизнес-логики, такой как краудфандинг, децентрализованные обмены и иерархические структуры управления. Или, по крайней мере, обещание идет.

Разбить его

Теперь, когда мы знаем, как работают умные контракты Ethereum, мы можем разбить их на пять составных частей:

1. Выражение бизнес-логики в виде компьютерных программ.
2. Представление событий, которые запускают эту логику в виде сообщений в программы.
3. Использование цифровых подписей, чтобы доказать, кто отправил сообщения.
4. Размещение программ, сообщений и подписей на блокчейне.
5. Выполнение каждой программы для каждого сообщения на каждом узле.

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

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

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

Проблема с вычислениями

Если не имеет значения, где происходит вычисление, почему не делать это везде? Ну получается что компьютерные программы непредсказуемы. Какими бы невинными они ни казались, им может потребоваться много времени, чтобы бежать. А иногда они продолжают бежать вечно. Рассмотрим следующий классический пример (известный как LCG):

1. Поставьте x на однозначное число по вашему выбору
2. Поставьте y в 123 * х + 567
3. Поставьте x до двух последних цифр yт.е. у по модулю 100
4. If x больше чем 2 затем вернитесь к шагу 2
5. В противном случае остановите и выведите значение x

Достаточно просто, правда? Итак, вот вам вопрос: завершится ли когда-нибудь эта программа? Или он застрянет в бесконечная петля? Не уверен? Хорошо, позвольте мне избавить вас от ваших страданий: Это зависит от начального значения х.

If x is 0, 1, 2, 5, 6, 7 or 8программа останавливается довольно быстро. Но если x is 3, 4 or 9, это продолжается бесконечно. Не верите мне? Откройте Excel и попробуйте сами (вам понадобится функция «MOD»).

Если вы не можете предсказать это, просто взглянув на код, не расстраивайтесь. Потому что людям это тяжело не только, это невозможно для компьютеров, Проблема определения того, завершится ли выполнение данной программы, называется проблема остановки. В 1936 г. Алан Тьюринг, полного Тьюринга и Имитация игры известность, доказал, что ее невозможно решить в общем случае. За исключением тривиальных исключений, единственный способ узнать, завершит ли программа выполнение это запустить его столько, сколько потребуется, и это могло быть навсегда.

Для тех из нас, кто предпочел бы жить без синие экраны смерти и спиннинг пляжные мячи, это все довольно неудобно. Но мы живем с этим, и, что примечательно, большую часть времени большинство программ работает без сбоев. А если нет, современные операционные системы, такие как Windows, защищают нас от неконтролируемого кода, позволяя завершать программы вручную. Однако то же самое нельзя сделать в такой блокчейне, как Ethereum. Если бы мы позволили отдельным узлам прекращать вычисления по своему усмотрению, разные узлы имели бы разные мнения о результате этих вычислений. Другими словами, сетевой консенсус сломался бы, Так что же делать с блокчейном?

Ответ Эфириума основан на плате за транзакцию, также известной как газ. Отправитель каждой транзакции страна для вычислений, которые он запускает, и этот платеж собирается майнером, который подтверждает его в блоке. Точнее, в каждой транзакции Ethereum заранее указано, сколько «эфира» отправителя можно потратить на его обработку. Плата постепенно расходуется по мере выполнения контракта, шаг за шагом, в виртуальной машине Ethereum. Если у транзакции заканчивается комиссия до ее завершения, все изменения в базе данных отменяются, и комиссия не возвращается. Если транзакция завершается успешно, оставшаяся комиссия возвращается отправителю. Таким образом, транзакции могут обременять сеть только в той степени, в которой они готовы за это платить. Несомненно, это отличное экономическое решение, но для работы требуется собственная валюта блокчейна.

Умные контракты против параллелизма

Если газ может предотвратить неконтролируемые вычисления, получают ли смарт-контракты зеленый свет? Что ж, не так быстро, потому что есть еще одна проблема со смарт-контрактами, о которой нам нужно поговорить:

Смарт-контракты плохо работают при высокой пропускной способности транзакций.

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

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

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

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

Так что же такого особенного в модели транзакций Биткойна, которое делает возможным выполнение вне очереди? В биткойнах каждая транзакция прямо заявляет его отношение к другим транзакциям. У него есть набор входов и выходов, в котором каждый вход связан с выходом предыдущей транзакции, которую он «тратит». Нет никаких других зависимостей, о которых нужно беспокоиться. Пока (а) две транзакции биткойнов не пытаются использовать один и тот же вывод, и (б) вывод одной не приводит к вводу другой, узел биткойнов может быть уверен, что транзакции независимы, и он может обрабатывать их в любом порядке, Их конечные позиции в блокчейне не имеют никакого значения.

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

Если взглянуть на это с практической точки зрения, на предприятии было много разговоров о частных блокчейнах. Но частный блокчейн - это всего лишь распределенная база данных с некоторыми дополнительными функциями. И если вы сегодня попытались продать базу данных корпоративного класса, которая не поддерживает параллелизм, вы бы смеялись из комнаты, Столь же нелепым было бы предположение, что отдельный узел должен подождать 12 секунд, чтобы увидеть результат своих собственных транзакций. Как сам Виталик недавно в твиттере:

Ключ pt о dapp dev, который я недооценил: главная проблема не в стоимости передачи; госзакупки могут обрабатывать $ 0.001. Проба латентная; PPL хотят 500 мс, а не 17 с.

- Виталик Бутерин (@VitalikButerin) 27 сентября, 2015

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

В пользу Эфириума

Если вас интересует только одна сторона аргументации, можете перестать читать здесь. Но вы можете задаться вопросом: неужели создатели Ethereum глупы? Зачем им требуется глобальное выполнение в общедоступной распределенной базе данных, если каждый узел может просто выбирать, какие программы ему нужно запускать? Есть ли веские причины для использования Ethereum?

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

Предотвращение спама транзакции

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

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

Но как узел узнает, достаточно ли у отправителя средств для покрытия предлагаемой комиссии? В случае Ethereum на баланс «эфира» каждого пользователя влияет результат предыдущих транзакций, поскольку контракты могут как тратить, так и выплачивать эфир, Таким образом, фактически не выполняя все программы для всех предыдущих сообщений, узел Ethereum не сможет узнать о текущем балансе пользователя. Следовательно, он не может оценить, должна ли транзакция передаваться на другие узлы. А без этого открытая сеть может быть тривиально разрушена.

Компактные доказательства данных

В блокчейне блоки заполняются в основном транзакциями, которые они подтверждают. Однако каждый блок также имеет компактный «заголовок», который содержит важную информацию, такую ​​как временная метка и ссылка на предыдущий блок. Для публичных блокчейнов на основе доказательство работы хеширования, входом для алгоритма хеширования является только этот заголовок блока. Это означает, что авторитет цепочки может быть оценен «легковесным клиентом» без загрузки большей части ее контента. Например, по состоянию на ноябрь 2015 г. полный набор заголовков биткойнов имел размер 30 МБ по сравнению с 45 GB для полной цепи. Это соотношение 1500: 1, что очень важно для мобильных устройств с ограниченной пропускной способностью и хранилищем.

Заголовок каждого блока Ethereum содержит «корень состояния», который определяет состояние цепочки после обработки транзакций в этом блоке. Среди прочего, это состояние охватывает содержимое базы данных каждого контракта, при этом отпечаток пальца вычисляется эффективно с использованием дерево односторонних хеш-функций. Малейшее изменение базы данных любого контракта привело бы к совершенно другому состоянию корня, поэтому корень «связывает» содержимое базы данных. (Эквивалентное понятие «обязательства UTXO» для биткойнов было обсуждается но пока не реализовано.)

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

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

Приговор для частных блокчейнов

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

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

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

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

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

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

Двухэтажные блокчейны

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

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

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

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

Умные контракты в публичных блокчейнах

Как я уже говорил ранее, в что такое варган? Полные блокчейны Тьюринга, такие как Ethereum, есть Он веские причины для глобального исполнения. Но вот еще вопрос: в чем предприятие вариант использования для этих цепочек? Давайте представим какое-то будущее время, когда предприятия будут достаточно уверены в публичных блокчейнах, чтобы использовать их в реальных бизнес-процессах. Если группа компаний хочет встроить вычислительную логику в публичный блокчейн, у них есть два варианта: (1) использовать блокчейн в стиле Ethereum с глобальным исполнением или (2) использовать любой блокчейн как простой слой хранения и выполнения кода самостоятельно. И учитывая эти варианты, почему они выбрали (1)?

Рациональным выбором будет публичный блокчейн с (а) самой дешевой ценой за байт хранилища и / или (б) наивысшим уровнем безопасности, основанным на общей мощности майнинга. Поскольку вычисления являются детерминированными, компаниям нужно только заплатить сети за магазин их контракт и сообщения, а не на самом деле процесс их. Кроме того, используя блокчейн только для хранения, они могут использовать любой язык программирования, который они хотят. Это может быть байт-код Ethereum, JavaScript / ECMAScript для удобочитаемости или даже Машинный код для высокой производительности. Фактически, Ethereum сжимается уже можно хранить использование метаданных в цепочке биткойнов. Это именно двухуровневый подход, который я предложил.

Это обсуждение связано с понятием слои абстракции, прославленный Сетевая модель OSI. Для оптимальной надежности и гибкости каждый уровень системы должен быть максимально абстрагированным (т. Е. Независимым) от других уровней. Например, мы не хотели бы, чтобы наши контроллеры жестких дисков содержали код для рендеринга изображений JPEG. Так зачем нам нужно, чтобы блокчейн выполнял программы, которые он хранит? В большинстве случаев мы не получаем от этого никакой выгоды, и это требует значительных затрат.

Эпилог

Если глобальное выполнение не имеет смысла в частных блокчейнах, почему все работают над этим? Я думаю, что это можно объяснить, по крайней мере частично, непониманием того, что могут делать блокчейны. в реальном мире, Видите ли, публичные цепочки блоков, такие как биткойны, могут напрямую переместить реальный актив (а именно, их собственная валюта), потому что блокчейн определяет владение этой валютой. Это объединяет два аспекта активов, которые обычно различаются между собой: (а) бухгалтерская книга, в которой указывается, кто владеет активом, и (б) его фактическое физическое местонахождение. Это делает криптовалюту идеальной инструмент на предъявителясоздание дивного нового мира или рая отмывания денег, в зависимости от того, кого вы спрашиваете.

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

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

Если смарт-контракты не могут выполнить свое обещание, почему мы платим за них цену?

Спасибо за чтение.