blockchained

7 лет назад

📝 Сообщение — это медиа (Ian Grigg)

Вступление

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

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

Что такое машина состояний?

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

Представьте себе торговый автомат с напитками и программное обеспечении внутри него, которое должно имитировать саму аппаратную машину, чтобы выяснить, что делать дальше. На словах: «Если мы находимся в Состоянии 1, ждите монеты. Если монета появляется, переходим в Состояние 2. Если мы в Состоянии 2, ждите нажатия кнопки. Если произошло нажатие кнопки, доставьте напиток, перейдите в Состояние 1." По сути, наша машина состоит из кода для обработки этого алгоритма, некоего состояния (памяти), чтобы помнить, где мы находимся, и способности читать входящие сообщения (монета, кнопка) и записывать некоторые инструкции в виде сообщений (напиток!).

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

Выбор

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

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

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

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

Первый способ: думайте о нем как о машине состояний. В таком представлении мы храним Состояние 1. Затем, когда приходит сообщение, машина переходит в Состояние 2, и мы сохраняем это новое состояние. И так много раз! Подумайте о состояниях как о Синих Кругах выше, и можете игнорировать любые другие взгляды на мир.

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

В теории эти взгляды в основном равнозначны, и хитрость в их понимании заключается в том, что машина является детерминированной, т.е. предопределяемой. Как только мы установили, что машина точна и непреклонна в своих действиях, мы знаем, что, например, Сообщение 1 в Состоянии 1 всегда приводит к Состоянию 2 (и выводу Сообщения 2).

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

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

Что же до устройства блокчейна?

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

Что же должен делать блокчейн?

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

... Цель блокчейна состоит в том, чтобы представлять одно состояние, которое параллельно редактируется. Чтобы избежать конфликтов между параллельными изменениями, оно представляет состояние в виде журнала, то есть в виде последовательности преобразований, применяемых к исходному состоянию. Эти преобразования являются «блоками» блокчейна, и - в случае Биткойна - состояние в основном представляет собой набор неизрасходованных выходов.

(курсив — автора этой статьи) LM Goodman, “Tezos: A Self-Amending Crypto-Ledger Position Paper”, 2013 г.

Или вот из недавнего проекта замены Ethereum:

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

«RChain Architecture - Contract Design», 2017 RChain Cooperative

Обратите внимание, как приведенный выше автор определил всё, что нам нужно для хранения сообщения как транзакции, а затем вернулся обратно к канону состояния блокчейна.

Если мы посмотрим на машину состояний Биткойна на рис. 4 ниже в качестве другого примера, мы увидим, что это представление состояния является большой записью в модели UTXO, которая группирует транзакции в виде наборов неиспользованных выходов транзакций (Unspent Transaction Outputs — «UTXO»). Транзакция представляет собой запись состояния, которая содержит вход и выход. В сравнении с приведенным выше рис. 3, подумайте обо всех синих кругах в каждой записи, но без сообщений. Обычно каждая транзакция UTXO представляется как поле со столбцом входов слева и выходов справа, Рисунок 4:

На входной (левой) стороне каждой транзакции представлен список ссылок на предыдущие выходы или «монеты», по которым они затем расходуются, а на выходной стороне (правой) - другой соответствующий список новых монет, в соответствии с которым они теперь созданы и могут быть потрачены в будущем. Вверху «Транзакция 1» создает 0.5BTC монет в качестве выхода, а «Транзакция 2» расходует 0.5BTC монет, цитируя ее как вход.

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

Хрупкость модели UTXO

Это мы уже наблюдали, но стоит повторить: структура Биткойна обладает отличным дизайном, но один из его аспектов заключается в том, что все компоненты тесно связаны друг с другом очень зависимым способом. В его описании говорится:

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

Satoshi Nakamoto, “Bitcoin: A Peer-to-Peer Electronic Cash System”, 2008.

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

Так же и с UTXO. Как уже упоминалось, миссия Биткойн заключалась в создании денег. Каждый (полный) узел должен обладать каждой записью о доступных для него деньгах, чтобы он мог заверять каждую входящую транзакцию и переходить к распределению транзакций в предлагаемый блок для майнинга. Напротив, SPV или удалённые клиенты должны иметь простой способ доказать только их компонент входящих монет, не втягивая в это всю цепочку.

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

Реестр ордеров

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

Собираясь вместе на машине состояний UTXO, неизвестное количество людей хочет принять участие в торгах, разместив позиции на стороне покупки, как и неизвестное количество людей на стороне продажи. Модель UTXO не способна с легкостью поддерживать этот дизайн по двум причинам: 1. взаимодействие многих неизвестных, конкурирующих за один результат, не масштабируется, потому как вся схема должна согласовываться «на ходу» — входы, выходы и цены! - между конкурирующими трейдерами; и 2. торговля чувствительна к информации — если есть способ выйти из согласованной схемы и обрушить ее, трейдеры сделают это, как только обнаружат вашу позицию на рынке. Это фундаментальное противоречие!

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

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

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

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

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

Небольшое возражение

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

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

Заключение

Модель обмена сообщениями по многим причинам превосходит модель состояний, особенно в цели создания блокчейнов с широкими возможностями. Не всё так однозначно — у модели состояний есть преимущество более быстрого обнаружения поломок.

Более развернутый пост включал бы перечисление всех «за» и «против», но сейчас мы просто обратимся к одному крупному профи. Помимо гибкости вышеприведенного примера, цепочки сообщений могут достичь гораздо более высокой производительности. Например, Bitshares и Steem, созданные @dantheman, были построены по этой модели и демонстрируют показатель в 1000 транзакций в секунду. Кстати, такова и моя система Ricardo, которая хоть и не является блокчейном, но объясняет, почему мне это так нравится :-)

На бумаге, по крайней мере, такой подход обещает гораздо более высокую производительность, и вы можете разглядеть намек на то, что EOS будет построен таким же образом! Действительно, именно потребность в скорости в этих системах привела разработчика @dantheman и меня к открытию, что, извиняюсь перед Маршаллом Маклюэном, но

Сообщение — это медиа.

Свежие новости в Телеграм: t.me/EOS_RU

Переведено @rusteemitblog

Оригинал поста: ЗДЕСЬ