Завершение дебатов о биткойнах и блокчейнах

Есть ли какая-то ценность в блокчейне без криптовалюты?

Дебаты продолжались некоторое время, но в прошлом месяце произошел серьезный подъем. Задаваемый вопрос:

Есть ли какая-то ценность в блокчейне без криптовалюты? И можно ли вообще назвать эти «общие маркеры без учета токенов» блокчейнами?

Итак, я прочитал Статья Бейли, смотрели Видео Тима, Читать этот пост Nasdaqпоследовал за Ричардом каждую словои даже был свой оживленные дебаты (см. комментарии) с Крисом ДеРозом из Фонда контрагента. Так много горячего воздуха.

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

Биткойн-блокчейн был одновременно экономическим и инновации в области компьютерных наук.

Я позволяю «инновации» здесь, чтобы включить новая комбинация существующих методов, а не то, что вообще не имеет прецедентов. Это определение позволяет рассматривать всемирную паутину как новшество, хотя она лишь объединяет гипертекст с изюминкой некоторых существующих Интернет-протоколов. Если вы хотите принять более строгое определение инновации, будь моим гостем, но вы будете удивлены тем, как мало истинных «инноваций» осталось. Перефразировать УчительМало нового под солнцем.

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

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

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

Транзакционная модель Биткойна

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

Биткойн имеет множество дополнительных правил, которые применяются каждым узлом в сети:

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

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

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

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

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

Мы могли бы использовать демократический подход, при котором узлы в сети голосуют за блоки, и большинство выигрывает. К сожалению, как показывает любой интернет-опрос, представительная демократия в Интернете невозможна из-за проблемы подражания (также известной как Сибил атака). Один человек может взять более миллиона компьютеров и решить, как они голосуют, таким образом получив контроль над сетевым консенсусом. Никто другой даже не узнает, что это произошло.

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

Если создать блок так сложно и дорого, зачем кому-то беспокоиться? Ответ кроется в награде за блок. Успешный майнер блока контролирует транзакцию с базой монет, которая награждает его 25 биткойнами (эта сумма уменьшается вдвое каждые четыре года). Они могут продать эти биткойны на открытом рынке за 7,000 долларов (по сегодняшнему курсу), оплатить свои счета за электричество и, надеюсь, получить некоторую прибыль. Майнеры также взимают небольшую дополнительную плату с комиссий, связанных с транзакциями, хотя на данный момент эти комиссии играют второстепенную роль.

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

Многоуровневое управление параллелизмом

А пока я хочу поговорить о чем-то, что может показаться совершенно не связанным.

База данных - это хранилище структурированной информации, сгруппированной в объекты, похожие на электронные таблицы, называемые таблицами. Простым примером такой таблицы является список банковских счетов, в каждой строке которого содержится номер счета вместе с балансом этого счета. Допустим, ваш аккаунт начинает день с балансом в 900 долларов. Сегодня запланирован автоматический платеж по ипотеке в размере 750 долларов США, а также необходимо снять 400 долларов США в банкомате. К сожалению, у вас нет возможности овердрафта, поэтому одна из этих операций настроена на сбой.

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

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

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

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

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

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

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

Важно, что для наших целей MVCC предотвращает конфликты между операциями записи. В частности:

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

Звонят ли колокола? Есть еще один фон, который мы должны обсудить.

Репликация базы данных с несколькими хозяевами

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

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

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

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

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

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

Это кажется простым в теории, но репликация с несколькими мастерами создает новую проблему, потому что могут возникнуть конфликты. Что если две копии базы данных обновляют одну и ту же строку одновременно, а затем пытаются обмениваться этими обновлениями друг с другом? Обе базы данных заметят, что произошло конфликтующее обновление, и должны будут применить некоторую согласованную стратегию для разрешения этих конфликтов. И тут дела обстоят довольно сложный - см. Документы для MySQL, SQL Server or Oracle для некоторых примеров стратегий разрешения конфликтов. (Я игнорирую синхронную или так называемую «активную» репликацию с несколькими хозяевами, в которой все реплики должны выполнять операцию записи, прежде чем она может произойти, потому что это каждую копия базы данных в узкое место.)

Итак, вот к чему ведет весь этот фон:

Разве не было бы неплохо, если бы мы могли распределить управление параллельным выполнением нескольких версий, чтобы предотвратить конфликты, возникающие при репликации с несколькими мастерами?

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

Блокчейн как распределенный MVCC

Давайте скопируем пару предложений, которые я написал жирным шрифтом выше:

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

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

Эти предложения идентичны, за исключением терминов, выделенных жирным шрифтом. Итак, вот что я собираюсь заявить:

Блокчейн предоставляет распределенный MVCC (с несколькими дополнительными функциями).

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

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

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

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

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

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

Блокчейны за пределами MVCC

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

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

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

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

Так где жетон?

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

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

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

Эпилог

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

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

Короткий ответ: кого это волнует? Редко стоит спорить о значении слов, потому что есть нет правильного ответа.

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

Достаточно ли похожи эти общие книги на биткойны, чтобы заслужить название «блокчейн»?

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

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

Вы можете следуй за мной в твиттере здесь, Смотрите также: Доставка против оплаты на блокчейне.

Вот еще пара статей, которые стоит прочитать на эту тему: Петр Пясецкий и Дуг Кэмпбелл.