В последние месяцы в криптовалютном сообществе и не только развернулась дискуссия о том, есть ли какая-либо ценность в блокчейне самом по себе, без криптовалюты. Можно ли вообще называть такие “общедоступные журналы транзакций без токенов” блокчейнами?
Чтобы лучше разобраться в теме, я прочитал статью Бэйли, просмотрел видео с Тимом, ознакомился со статьей от Nasdaq, изучил работы Ричарда (одну и вторую) и даже поучаствовал в дебатах (см. комментарии) с Крисом Дероузом (Chris DeRose) из фонда Counterparty. Уф…
Как хорошо заметил Крис, суть разногласий можно свести к вопросу, является ли блокчейн экономической или технологической инновацией. Если блокчейн — исключительно экономическая инновация, то блокчейны без криптовалют не имеют смысла. Поэтому позвольте мне с самого начала объявить о своей позиции:
Блокчейн Биткойна — это и экономическая, и технологическая инновация.
Под “инновациями” я понимаю не только то, чего никогда не существовало, но и новые сочетания имеющихся технологий. Например, такое определение позволяет считать инновацией WWW, хотя, по большому счету, это всего лишь сочетание гипертекста с немного измененными интернет-протоколами. Если такое определение кажется вам недостаточно жестким, можете предложить свое, более строгое, но вы будете удивлены, насколько мало тогда останется “настоящих инноваций”. Как гласит древняя мудрость, “ничто не ново под луной”.
В общем, я утверждаю, что блокчейны без токенов ценности полезны, но в ином отношении, чем блокчейн Биткойна. Многие энтузиасты криптовалют смеются над блокчейнами без токенов — мол, они не обеспечивают защиту от цензуры и децентрализованную безопасность, основанную на подтверждении работы. С другой стороны, профессионалы из мира финансов смеются над общедоступными блокчейнами, потому что они медленны, дороги и плохо подходят для решения традиционынх финансовых задач. Что касается меня, то я считаю, что правы обе стороны.
Я собираюсь продемонстрировать, что блокчейны без токенов полезны для синхронизации децентрализованных БД, причем полезны даже в организациях с идеальным доверием. А затем мы увидим, какие другие возможности предлагают блокчейны для обеспечения консенсуса при специфичных транзакциях между сторонами с ограниченным доверием друг к другу.
Чтобы адекватно разобрать эту тему, мы должны обсудить модель транзакций в Биткойне, управление конкурентным доступом к БД с помощью многоверсионности (MVCC) и проблему разрешения конфликтов при репликации БД с несколькими главными репликами (multi-master replication). Я постараюсь объяснить все доступным языком, но без технических деталей не обойтись.
Модель транзакций Биткойна
Модель транзакций Биткойна совсем проста, но при этом очень эффективна. Каждая биткойн-транзакция может иметь несколько входов и несколько выходов, при этом каждый вход “тратит” выход предыдущей транзакции. Все биткойны, поступившие на входы транзакции, распределяются между выходами согласно заданным параметрам. Так транзакции формируют распределенные цепочки, которые уходят в прошлое и завершаются coinbase-транзакциями, которые когда-то сгенерировали соответствующие биткойны.
В Биткойне также есть несколько дополнительных правил, за соблюдением которых следят узлы сети.
- К каждому входу транзакции должно прилагаться подтверждение права потратить соответствующий выход предыдущей транзакции. Это право ограничено условиями, закодированными в выходе предыдущей транзакции.
- Количество биткойнов на входах транзакции должно превышать ее суммарный выход. Единственное исключение из этого правила — coinbase-транзакции, которые генерируют новые биткойны.
- Каждый выход можно потратить только один раз — иначе говоря, он может быть связан с единственным входом единственной последующей транзакции.
Для соблюдения последнего правила необходим механизм достижения консенсуса по поводу того, какие транзакции действительны, и как раз для этого используется блокчейн. Точнее говоря:
Если предпринимаются попытки потратить один выход в двух транзакциях, в итоге будет принята только одна из них. Блокчейн работает как унифицированный механизм выявления и предотвращения таких конфликтов в сети.
Блокчейн структурирован как цепь связанных блоков, каждый из которых содержит набор транзакций, не конфликтующих ни между собой, ни с предыдуими блоками, начиная с самого первого блока, созданного в 2009 году. Теоретически блокчейн мог бы содержать отдельные транзакции, но группировка транзакций в блоки делает его более эффективным и практичным.
Какова же роль криптовалюты в этой схеме? Она сводится к вопросу о том, кто решает, какие блоки будут добавлены в блокчейн. Биткойн децентрализован, и никто не обладает полномочиями принимать это решение единолично, так что нам нужен какой-то другой способ достижения консенсуса.
Мы могли бы попробовать демократический подход, чтобы решение о добавлении блока в блокчейн принималось большинством голосов. К сожалению, как видно по интернет-опросам, представительная демократия в Интернете невозможна из-за проблемы имперсонации (или так называемой атаки Сибиллы). Иначе говоря, один человек может голосовать со многих компьютеров, манипулируя консенсусом в своих интересах.
Для устранения этой проблемы добавление блока в блокчейн в Биткойне целенаправленно затруднено с помощью так называемого “майнинга”. Чтобы создать блок, вы должны решить сложную, но бессмысленную математическую проблему, требующую затратить много вычислительных ресурсов (а, следовательно, электричества и денег). Не помешает и немного удачи, потому что вам придется конкурировать со многими другими майнерами по всему миру.
Если создать блок трудно и дорого, почему этим кто-то занимается? Все просто: удачливый майнер блока получает право выполнить coinbase-транзакцию и выписать себе 25 биткойнов (эта сумма уменьшается вдвое каждые 4 года). Далее он может продать эти биткойны на бирже, оплатить счета за электричество и получить некоторую прибыль. Кроме того, майнеры получают небольшой доход в виде комиссий за транзакции, но они пока совсем малы.
Итак, консенсус в Биткойне достигается благодаря подтверждению работы. Биткойн-энтузиасты утверждают, что без криптовалюты невозможно мотивировать децентрализованный майнинг блоков и, соответственно, защитить блокчейн от атак Сибиллы. Без криптовалюты кто угодно сможет монополизировать контроль над консенсусом, что сделает блокчейн бесполезным. С этим трудно спорить.
Управление конкурентным доступом к БД с помощью многоверсионности
А теперь давайте отвлечемся на минутку и поговорим о БД.
Грубо говоря, БД — это хранилище структурированной информации, сгруппированной в таблицы. Примером таблицы может служить список банковских счетов, каждая строка которого содержит номер счета и его баланс. Пусть в начале дня баланс вашего счета составляет 900 долларов. Если бы вы захотели заплатить 750 долларов по ипотеке и снять 400 долларов в банкомате, то без овердрафта вам пришлось бы отказаться от одной из операций.
Платежи по ипотеке и снятие денег в банкомате обрабатываются разными системами, но обе они обращаются к единой БД банковских счетов. Немного упрощая, можно сказать, что каждая из этих систем считывает баланс счета, проверяет, достаточно ли на нем средств, в случае успеха инициирует операцию, проверяет ее результат, вычисляет новый баланс и, наконец, сохраняет его в БД. Пока ипотечный платеж и снятие денег в банкомате не перекрываются по времени, эта логика работает отлично. Одна из операций будет выполнена успешно, а во второй будет отказано, потому что для двух операций средств на счете недостаточно. В зависимости от порядка операций вы или получите сердитый звонок из отдела кредитования, или увидите безрадостное сообщение на экране банкомата.
Но что произойдет, если оба процесса начнутся примерно одновременно? В этом случае каждая из систем прочитает баланс вашего счета и сочтет его достаточным. Когда платеж по ипотеке завершится, в БД будет записан новый баланс, 150 долларов США. Когда завершится снятие денег в банкомате, в БД будет записан баланс 500 долларов. Одна из этих операций перезапишет другую, и, в зависимости от того, насколько вы удачливы, вы получите в подарок от банка 750 или 400 долларов.
Конечно, в реальности это не случится — благодаря технологии, которая называется управлением конкурентным доступом к БД. Она обеспечивает целостность и безопасность наших данных (особенно финансовых) и имеет целый ряд разновидностей. Все они, однако, разделяют тот принцип, что операции над БД группируются в “транзакции”, которые обрабатываются атомарно, т. е. завершаются успехом или неудачей как одно целое. Управление конкурентным доступом поддерживает согласованность данных, блокируя части БД на срок транзакции, чтобы другие транзакции не могли в это время получить доступ к тем же данным.
Если бы нам не нужно было выполнять транзакции параллельно, мы могли бы заблокировать всю БД на срок выполнения всех транзакций, но в реальном мире это непрактично. Эффективная схема управления конкурентным доступом допускает параллельные операции, блокируя как можно меньше данных на как можно меньшее время. В приведенном примере можно было бы заблокировать в БД только строку вашего счета и только на долю секунды, нужную для окончательной проверки и вычитания суммы из баланса. Параллельной транзакции пришлось бы дожидаться освобождения блокировки совсем недолго.
Один из популярных способов параллельной обработки транзакций называется управлением конкурентным доступом с помощью многоверсионности, или MVCC. В MVCC каждой транзакции доступен согласованный снимок данных в определенный момент времени, даже если часть этих данных параллельно обрабатывается другой транзакцией. Это свойство изоляции снимков гарантирует, например, что выписка, показывающая общий баланс по нескольким счетам, всегда будет правильной, даже если некоторые суммы в данный момент перемещаются с одного счета на другой. Одна транзакция повлияет на данные, доступные другой транзакции, только если вторая транзакция начинается после успешного применения всех изменений в рамках первой транзакции.
За кулисами MVCC поддерживает несколько версий строки вместе с данными о времени последнего изменения каждой версии. Когда строка БД изменяется, текущая версия строки помечается как подлежащая удалению, при этом изменение применяется к копии строки, для которой также обновляется метка времени. С точки зрения хранилища изменений строки “на месте” просто не существует. Каждой транзакции точно известно, когда она началась, и доступны только те версии строк, временные метки которых предшествуют этому моменту. Как только текущих транзакций, которым могут потребоваться старые версии строк, не остается, эти версии можно удалить из хранилища.
Для нас важно то, что MVCC предотвращает конфликты операций записи, а именно:
Если две транзакции пытаются удалить одну и ту же версию строки, в конечном итоге будет принята только одна из этих транзакций. MVCC работает как унифицированный механизм выявления и предотвращения таких конфликтов в БД.
Начали догадываться, к чему я клоню? Но для начала нам надо обсудить еще кое-что.
Репликация БД с несколькими главными репликами
Давайте теперь поговорим о репликации БД при наличии нескольких ее копий. Есть целый ряд причин для репликации БД, например:
- Для повышения надежности, чтобы при утрате одной копии БД (например, из-за сбоя диска) можно было мгновенно переключиться на другую.
- Для повышения пропускной способности, если ресурсов сервера не хватает для обслуживания всех запросов.
- Для сокращения задержек, чтобы процессам в сингапурском офисе не приходилось дожидаться ответов от БД в Торонто.
Если речь идет о чтении данных из БД, репликация подходит идеально, потому что все реплики БД содержат одну и ту же информацию. Что касается записи данных, то в этом случае все не так однозначно, потому что мы должны решить, где выполнять эти операции записи и как передавать их в другие копии БД.
Чаще всего используется репликация по принципу “главный-подчиненный”, при которой одна БД считается авторитетным источником. Любые изменения данных выполняются исключительно в ней, а затем распространяются по всем остальным (подчиненным) БД с помощью журнала транзакций. Это обеспечивает синхронизацию всех копий БД.
К сожалению, если операции записи выполняются часто, репликация по принципу “главный-подчиненный” возвращает нас к проблеме, которую репликация как раз и должна была решить. Главная БД становится “узким местом” в плане надежности, пропускной способности и задержек, потому что все операции записи выполняются только в ней.
Существует более сложная стратегия — так называемая репликация с несколькими главными репликами, при которой можно выполнять запись в любую копию БД. В этом случае синхронизация копий БД выполняется в пиринговом стиле.
В теории все просто, но при такой репликации возможны конфликты. Что, если две копии БД одновременно обновляют одну и ту же строку, а затем пытаются обменяться этими обновлениями? Обе БД зарегистрируют конфликт и должны будут как-то разрешить его. Стратегии разрешения таких конфликтов довольно сложны — можете ознакомиться с некоторыми примерами в документации по MySQL, SQL Server или Oracle. Вот мы и добрались до главного вопроса:
Разве не было бы здорово получить распределенный механизм управления конкурентным доступом к БД с помощью многоверсионности, предотвращающий конфликты при репликации с несколькими главными репликами?
Не знаю как вы, а я в восторге от такой идеи. И мне кажется, что именно это делают блокчейны.
Блокчейн как распределенная система MVCC
Давайте повторим пару фраз, которые я выше выделил полужирным шрифтом.
Если две транзакции пытаются потратить один выход, то в итоге будет принята только одна из них. Блокчейн выполняет функцию унифицированного механизма выявления и предотвращения этих конфликтов во всей сети.
Если две транзакции пытаются удалить одну и ту же версию строки, то в итоге будет принята только одна из них. Управление конкурентым доступом с помощью многоверсионности выполняет функцию унифицированного механизма выявления и предотвращения этих конфликтов в базе данных.
Эти фрагменты почти идентичны, что дает мне право заявить следующее:
Блокчейн — это распределенная система MVCC (с несколькими нюансами).
Давайте немного развернем сравнение. Для биткойн-узла текущий набор непотраченных выходов биткойн-транзакций представляет собой БД, в которой каждой строкой является один непотраченный выход. Она похожа на БД банковских счетов, которую мы описали выше, с тем небольшим отличием, что в данном случае баланс каждого счета может быть разделен на несколько строк, помеченных одним номером счета.
Биткойн-транзакция тратит один или несколько этих выходов и создает один или несколько новых выходов. Это ничем не отличается от транзакции БД, которая удаляет одну или несколько версий строк и создает одну или несколько новых строк (напомню, что в MVCC нет никаких изменений строк “на месте”). Блокчейн Биткойна гарантирует, что один выход нельзя потратить более чем в одной транзакции — это эквивалентно той гарантии, что одну версию строки можно удалить в единственной транзакции БД.
Думаю, нужно кое-что пояснить. Я не утверждаю, что блокчейн — прекрасная технология общего назначения для синхронизации распределенных баз данных в среде с полным доверием. Есть много других технологий, которые хорошо справляются с этой задачей, таких как Paxos, Raft и протокол двухфазной фиксации. Однако я считаю, что у блокчейнов есть своя сфера применения, для которой характерны следующие признаки.
- Нас устраивает небольшая задержка между вероятным моментом приема транзакции и моментом, когда она принята наверняка (эта задержка может составлять от нескольких секунд до 10 минут и больше в Биткойне).
- Конфликтующие транзакции должны быть невозможны (при условии, что все участники честны и их ПО работает правильно).
- Каждая транзакция изменяет одновременно всего лишь несколько строк (в противном случае блокчейн-транзакции будут иметь слишком много входов).
- Размер каждой строки в базе данных довольно мал (это также нужно, чтобы не раздувать блокчейн-транзакции).
Финансовые приложения соответствуют всем этим критериям. Финансовый мир привык к задержкам (до 3 дней!) между выполнением транзакции и ее окончательным согласованием. Что касается конфликтов, то в финансовом мире есть контракты и регуляторные процедуры выявления мошенничества, которое наказывается. Объем данных, задействованных в каждой транзакции, также довольно мал (можете вспомнить пример с банковским счетом).
Пока что я лишь продемонстрировал, что блокчейн — это один из механизмов синхронизации распределенных баз данных (кто бы мог подумать!), но по-настоящему интересное начинается только тогда, когда мы принимаем во внимание дополнительные возможности блокчейнов.
Другие возможности блокчейнов
Биткойн-транзакция не просто указывает на выходы некоторой предыдущей транзакции и создает новые выходы вместо них — это было бы слишком грубым упрощением. Даже простейшая биткойн-транзакция выполняет две дополнительные функции.
Во-первых, правила проверки транзакций содержат некоторую прикладную логику БД Биткойна, а именно требование, что суммарный объем средств на входах транзакции должен превышать суммарный выход. Иными словами, биткойн-транзакции (за исключением coinbase-транзакций) не могут увеличивать общее количество биткойнов в БД. Такое ограничение превосходит хранимые процедуры обычной БД, потому что оно не может быть нарушено ни при каких обстоятельствах.
Во-вторых, каждый выход биткойн-транзакции кодирует условия, согласно которым он может быть потрачен. Для обычных выходов эти условия основаны на криптографии с открытым ключом: общедоступный адрес встраивается в “сценарий” выхода, чтобы его можно было потратить только с помощью закрытого ключа, соответствующего этому адресу. В аналогии с БД такому выходу соответствует строка с заданными для нее криптографическими разрешениями. Более того, каждая транзакция предоставляет открытое подтверждение того, что ее создатель имел право удалить или изменить предыдущие строки. Я считаю это подлинной инновацией в мире СУБД.
Обе эти возможности невероятно полезны и в финансовых приложениях. То, что БД на самом низком уровне гарантирует, что деньги не могут быть созданы из воздуха, не может не нравиться. Очень полезен и неопровержимый журнал аудита, показывающий, что каждая транзакция была авторизована владельцем средств. В некоторых сценариях нам также могут пригодиться пиринговые атомарные безопасные транзакции обмена (“поставка против платежа” на финансовом жаргоне) без знания контрагента.
А что же токены?
Конечно, описанные выше достоинства вовсе не случайны, потому что сам Биткойн — великолепное пиринговое финансовое приложение. И все же никакие из этих достоинств блокчейна не зависят от токена. Если изменить схему БД так, чтобы каждая строка могла представлять разные активы, а не изначальную валюту блокчейна, можно совсем избавиться от этой валюты. Это оставляет нам блокчейн как способ достижения консенсуса и обеспечения безопасности в пиринговом финансовом приложении для работы с любыми активами.
Осталось ответить на один небольшой, но важный вопрос: кто выполняет майнинг для обеспечения этого консенсуса? В Биткойне консенсус обеспечивают анонимные майнеры, которые выполняют для этого ресурсоемкие бесполезные вычисления. На то их мотивируют награды за найденные блоки (и комиссии за транзакции), номинированные в валюте блокчейна. Возможны ли другие варианты?
Оказывается, что да. Можно составить закрытый список утвержденных майнеров, которые будут подписывать создаваемые блоки. Правила распределенного консенсуса никак не мешают использовать этот способ защиты блокчейна, если вы способны смириться с предварительным утверждением майнеров. Конечно, для Биткойна это неприемлемо, потому что анонимный майнинг, исключающий централизованную цензуру транзакций, — это фундаментальный элемент его дискурса. Однако в жестко регулируемой финансовой системе предварительно утвержденный список майнеров уже не вызвал бы нареканий, разве нет? Если бы их было достаточно, если бы эти роли были достаточно хорошо распределены между организациями и с ними были заключены юридические соглашения, вероятность того, что они вступили бы в сговор, чтобы подорвать работу сети (и, возможно, угодить за решетку), была бы минимальной.
Эпилог
Надеюсь, мне удалось показать, что у блокчейнов без токенов есть полезные способы применения, пусть даже они сильно отличаются от блокчейна Биткойна. Другой вопрос, заслуживают ли такие общедоступные журналы без токенов названия “блокчейн”, но я считаю, что это не важно. Споры о смысле слов редко заслуживают трат времени, потому что они не имеют правильного ответа. Скажем, я принимаю предпосылку, что блокчейн Биткойна является “архетипичным” блокчейном. В этом случае нам на самом деле следует задаться вопросом, достаточно ли эти общедоступные журналы похожи на Биткойн, чтобы их можно было называть “блокчейнами”. Я считаю, что да, потому что они имеют много технологических сходств, хотя и различаются моделями разрешений и экономической мотивации. Но важнее всего то, что они генерируют консенсус в распределенной базе данных с помощью цепи блоков.
Благодарю за внимание.
Гидеон Гринспен (Gideon Greenspan)
Источник: multichain.com
Categories: Альткойны, Сообщество, Технологии
Опрос: Масштабирование Биткойна 
SegWit: безразличие со стороны Биткойн-майнеров и активация на базе Litecoin 
Как подготовиться к хард-форку Биткойна 
Почему я зашортил эфир и закупился биткойном 
bitnovosti.wordpress.com 
да я давно уже об этом говорю – уже привлекаю инвесторов в блокчейн-стартап
http://datachains.world/
Натяжки и искажения, натяжки и искажения. За перевод +1.
“Разве не было бы здорово получить распределенный механизм управления конкурентным доступом к БД с помощью многоверсионности, предотвращающий конфликты при репликации с несколькими главными репликами?
Не знаю как вы, а я в восторге от такой идеи. И мне кажется, что именно это делают блокчейны.”
Вам не кажется. Блокчейны это делают. В том числе.
Но использовать блокчейны для решения ТОЛЬКО этой задачи – это всё равно, что микроскопом гвозди забивать.
Да – можно. Да – микроскоп тяжёлый.
Но неудобно ведь. Молотком сподручнее будет!
Вот вы же сами пишете:
“Есть много других технологий, которые хорошо справляются с этой задачей, таких как Paxos, Raft и протокол двухфазной фиксации”
Таки да! Но не будем вдаваться в тонкости. Задача контроля для исключения ошибок общего доступа, наложений и т.п. даже в распределенных системах – это не бог весть какая сложная задача. Её способен решить любой программист с приличным фундаментальным образованием. И решают. Есть куча p2p-ситем без блокчейна и в каждой из них эта задача так или иначе решается. Задача-то очень распространенная. Даже каждый PHP-программер в более-менее сложных системах постоянно с подобными задачами сталкивается.
При чем здесь блокчейны? Это лишь одна из их функций и решают они её далеко не лучшим образом, а говоря откровенно – довольно дерьмовым и медленным способом в силу своей природы.
Дело в том, что решение этой задачи обеспечивает только технический уровень защиты данных. Обеспечивает защиту от технически сбоев и наложений.
Блокчейн же ценен тем, что, помимо вышеупомянутой задачи, решает задачу социальную. Задачу подавления систематической подтасовки данных на математическом уровне. Работающий блокчейн практически решает эту задачу с чрезвычайно высокой достоверностью.
Задача эта в криптологии известна как “Задача византийских генералов”.
А в своей работе это важнейшее свойство блокчейна вы попросту молчаливо обошли.
Ссылка русская:
http://dic.academic.ru/dic.nsf/ruwiki/638598
для любителей первоисточников:
http://dealbook.nytimes.com/2014/01/21/why-bitcoin-matters/?_r=0 (от Марка Андрессена)
http://research.microsoft.com/en-us/um/people/lamport/pubs/pubs.html#byz (классическое решение задачи от Лампорта)
Блокчейн – это не только распределённая база данных. Это также методика устранения коллизий на уровне транзакций (технический уровень), а также методика выработки консенсуса без доверия к участникам в пиринговой системе.
Иначе говоря, полноценный блокчейн принципиально должен работать так, чтобы даже заведомо лживые участники пиринговой сети приходили к консенсусу.
Отсюда очень простой вывод.
В частных компаниях выработка консенсуса не имеет места быть и не имеет смысла. Они централизованы по природе. Там практикуется совершенно другой способ принятия и реализации решений – директивный.
Основное свойство блокчейна востребовано в компаниях не будет, а другие задачи (о которых вы и писали) намного эффективнее решаются другими методами.
Частный блокчейн – это классический оксюморон.
Это перевод статьи. Автор – Гидеон Гринспен (Gideon Greenspan)
“Частный блокчейн – это классический оксюморон.”
!!! Блин! Админ! Где тут кнопка “поставить 10 плюсов” ? !!!
” Автор – Гидеон Гринспен (Gideon Greenspan)”
Простите, не разобрался.
Значит, отвечал Гринспену. Жаль, что не услышит)))