Да, вам может понадобиться блокчейн

  • HLCS 

Источник · Перевод автора

Баладжи С. Шринивасан (Balaji S. Srinivasan) — бывший технический директор Coinbase, партнер Совета директоров Andreessen Horowitz и член консультативного совета CoinDesk.

Следующая статья первоначально была опубликована в журнале Consensus Magazine и распространялась исключительно среди участников мероприятия CoinDesk Consensus 2019.

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

Хотя некоторые критические замечания по этой критике уже есть (1, 2), я бы предложил простое опровержение в одно предложение: публичные цепочки блоков полезны для хранения общего состояния, особенно когда это общее состояние представляет ценные данные, которые пользователи хотят экспортировать / импортировать без ошибок — нравятся их деньги.

Проблема экспорта / импорта данных

Посмотрите на облачные диаграммы для Amazon Web Services, Microsoft Azure или Google Cloud. Существуют значки для балансировщиков нагрузки, транскодеров, очередей и лямбда-функций.

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

Для этого нет значка общего состояния между учетными записями. То есть все эти облачные диаграммы неявно предполагают, что единственная сущность и ее сотрудники (а именно сущность, имеющая доступ к корневой учетной записи облака) — единственная, которая представляет диаграмму архитектуры и читает или записывает в приложение, на котором она основана. Точнее, эти диаграммы обычно предполагают наличие одного экономического субъекта, а именно субъекта, оплачивающего счета в облаке. *

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

Это те типы вопросов, которые возникают, когда мы думаем об экспорте и импорте данных из приложения каждого субъекта как о первоклассном требовании. И (за исключением тех случаев, в которые мы попадем), как правило, сегодня на эти вопросы обычно нет ответа.

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

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

Современные подходы к проблеме экспорта / импорта данных

Хотя финансовых стимулов для общего решения проблемы экспорта / импорта данных пока нет, механизмы были созданы для многих важных особых случаев. Эти механизмы включают в себя API, экспорт JSON / PDF / CSV, файлы MBOX и (в банковском контексте) SFTP.

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

  • API-интерфейсы. Один из самых популярных способов экспорта / импорта данных — через интерфейсы прикладного программирования, более известные как API. Некоторые компании позволяют вам вывести часть ваших данных или дают вам возможность записывать данные в вашу учетную запись. Но есть цена. Во-первых, их внутренний формат данных, как правило, является собственностью, а не отраслевым стандартом. Во-вторых, иногда API не являются центральными для их основного бизнеса и могут быть отключены. В-третьих, иногда API-интерфейсы играют центральную роль в их основной деятельности, и цена может быть значительно повышена. В общем, если вы читаете или пишете в размещенный API, вы зависите от поставщика API. Мы называем этот риск платформой, и бесцеремонное снятие платформ нанесло вред многим стартапам.
  • JSON. Другое связанное решение — позволить пользователям или сценариям загружать файлы JSON или считывать / записывать их в вышеупомянутые API. Это хорошо, насколько это возможно, но JSON является очень свободной формой и может описывать практически все, что угодно. Например, API Graph Facebook и REST API LinkedIn имеют дело с похожими вещами, но дают очень разные результаты JSON.
  • PDF. Другое очень частичное решение — разрешить пользователям экспортировать PDF. Это работает для документов, так как PDF является открытым стандартом, который может быть прочитан другими приложениями, такими как Preview, Adobe Acrobat, Google Drive, Dropbox и т. Д. Но PDF должен быть конечным продуктом, который должен читать человек. Он не предназначен для ввода в любое приложение, кроме просмотра PDF.
  • CSV. Скромный файл значений, разделенных запятыми, становится ближе к тому, что мы хотим для общего решения проблемы импорта / экспорта данных. В отличие от серверной части проприетарного API, CSV — это стандартный формат, описанный в RFC 4180. В отличие от JSON, который может представлять почти все, CSV обычно представляет собой просто таблицу. И в отличие от PDF, CSV обычно может редактироваться пользователем локально через электронную таблицу или использоваться в качестве машиночитаемого ввода в локальном или облачном приложении. Поскольку большинство видов данных могут быть представлены в реляционной базе данных, а реляционные базы данных обычно можно экспортировать в виде набора возможно гигантских CSV-файлов, это также довольно общий характер. Тем не менее, CSV находятся в невыгодном положении по нескольким причинам. Во-первых, в отличие от проприетарного API, они не размещаются. То есть, нет единственного канонического места для чтения или записи CSV, представляющего (скажем) запись транзакций или таблицу метаданных карты. Во-вторых, CSV не защищены от несанкционированного доступа. Если пользователь экспортирует запись транзакций из службы A, изменяет ее и повторно загружает ее в службу B, вторая служба не будет мудрой. В-третьих, CSV не имеют встроенных проверок целостности для защиты от случайных ошибок. Например, столбцы CSV не имеют явной информации о типе, что означает, что столбец, содержащий месяцы года от 1 до 12, может автоматически преобразовывать свой тип при импорте в простое целое число, что вызывает путаницу.
  • MBOX. Хотя формат MBOX для представления коллекций сообщений электронной почты менее известен, чем CSV, он ближе всего подходит к стандартизированной структуре данных, созданной для импорта и экспорта между основными платформами и независимыми приложениями. Действительно, были статьи, предлагающие использование MBOX в контекстах вне электронной почты. В то время как CSV представляет табличные данные, MBOX представляет тип данных с лог-структурой. По сути, это один огромный текстовый файл сообщений электронной почты в хронологическом порядке, но он также может представлять изображения / вложения файлов через MIME. Как и CSV, файлы MBOX являются открытым стандартом и могут быть экспортированы, отредактированы локально и повторно импортированы. Как и CSV, MBOX имеет недостатки, заключающиеся в отсутствии канонического хоста или внутренней проверки целостности данных.
  • SFTP. Прежде чем мы продолжим, есть еще один механизм экспорта / импорта данных, который заслуживает упоминания: протокол безопасной передачи файлов или SFTP. Будучи почтенным, именно так люди отправляют друг другу платежи ACH. По сути, финансовые учреждения используют серверы SFTP для получения данных электронных транзакций в специально отформатированных файлах и передачи их в Федеральный резерв каждый день для синхронизации дебетов и кредитов ACH друг с другом.

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

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

  • Публичные цепочки блоков предоставляют канонические методы доступа для чтения / записи, такие как размещенный корпоративный API, но без того же риска для платформы. Ни один экономический субъект не может закрыть или отказать в обслуживании клиентам децентрализованного публичного блокчейна, такого как биткойн или эфириум.
  • Они также позволяют отдельным пользователям экспортировать критически важные данные на свой локальный компьютер или в новое приложение, такое как JSON / CSV / MBOX (путем отправки средств или экспорта закрытых ключей), обеспечивая при этом криптографические гарантии целостности данных.
  • Они дают возможность произвольно взаимодействовать произвольным субъектам экономической деятельности (будь то корпорации, отдельные пользователи или программы). Каждый субъект экономической деятельности, который читает из публичной блокчейн, видит тот же результат, и любой субъект экономической деятельности, обладающий достаточными средствами, может писать в публичную блокчейн таким же образом. Нет настройки учетной записи не требуется, и ни один актер не может быть заблокирован от чтения / записи доступа.
  • И, возможно, самое главное, публичные цепочки блоков дают финансовые стимулы для взаимодействия и целостности данных.

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

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

Итак, это финансовый стимул для импорта.

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

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

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

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

Это правда, что сегодня публичные цепочки блоков обычно ориентированы на денежные и финансовые приложения, где базовый набор данных представляет собой историю транзакций только для добавления с неизменяемыми записями. Это ограничивает их общность с точки зрения решения всех различных версий проблемы импорта / экспорта данных. Но продолжается разработка общедоступных блочных версий таких вещей, как OpenStreetMaps, Wikipedia и Twitter, а также таких систем, как Filecoin / IPFS. Они не просто представляют записи финансовых транзакций, где требовалась неизменность, но могут представлять другие типы данных (например, записи на карте или в энциклопедии), которые будут регулярно обновляться.

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

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

* — Единственное исключение — это так называемая функция «Requester Pays», которую предлагают Amazon и другие облачные сервисы. Это классная функция, которая позволяет кому-то платить, чтобы написать в вашу корзину S3. Но это разрешено — ему по-прежнему требуется, чтобы каждый потенциальный писатель открыл учетную запись AWS, и владелец корзины должен быть готов разрешить им всем писать в свое ведро, так что по-прежнему существует один выдающийся владелец.