Частные блокчейны - это больше, чем просто общие базы данных.

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

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

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

Вторая ошибка - использование слова «просто». Просто? Были HTML и HTTP всего способ сделать распределенный гипертекст? Гипертекст был изобрел десятилетия назадИтак, являются ли эти технологии второстепенной сноской в ​​компьютерной истории? Ох, но позвольте мне подсчитать, каким образом они заработали свое место: (а) простой язык разметки что любой непрофессионал может узнать, (б) иерархическая схема адресации которая работает как с TCP / IP, так и с нашей концептуальной моделью, (c) простой протокол для извлечения контента без состояния, и (d) оба клиент и сервер программное обеспечение, которое принесло все это к жизни. С таким же успехом можно сказать, что Ньютон был просто ученым, а Достоевский - просто писателем.

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

Что такое база данных?

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

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

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

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

Есть и другие, более эзотерические типы правил, которые я мог бы перечислить, но у них всех есть одна общая черта. Они отвечают на вопрос: База данных в действительном состоянии? Другими словами, они действуют как ограничение на содержимое базы данных. при просмотре в один момент времени, И это прекрасно работает для базы данных, которая находится внутри одной организации, потому что основная задача ограничений - предотвратить ошибки программиста, Если одно из внутренних приложений WidgetCo попытается вставить трехзначный номер телефона в каталог, это будет связано не со злым умыслом, а скорее с ошибкой в ​​мышлении или коде разработчика. Способность базы данных улавливать эти ошибки, несомненно, удобна и помогает предотвратить распространение плохой информации внутри организации, но это не решает проблемы доверия, (Ограничения также могут помочь упростить логику приложения, например, через каскадирование внешнего ключа or по дублирующим пунктам, но это все еще только способы помочь разработчикам.)

Совместное использование базы данных

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

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

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

Все идет нормально. У нас есть общая база данных записи. Это работает, потому что WidgetCo отвечает за базу данных, и телефонная компания получает доступ благодаря милости WidgetCo. Если PhoneCo начал устанавливать телефонные номера случайным образом, WidgetCo может закрыть их доступ, прекратить действие своего контракта и восстановить некоторые старые данные из резервной копии. И если WidgetCo начнет плохо себя вести, скажем, поменяв местами новые телефонные номера, введенные PhoneCo, то это будет совершенно бессмысленно, так как это только навредит WidgetCo, Телефонная компания считает WidgetCo особым клиентом, но не особо заботливым, если оплачивает счет вовремя.

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

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

Реальная общая запись

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

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

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

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

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

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

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

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

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

Когда дело доходит до общих баз данных, частные цепочки блоков делают то же самое.