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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот это и есть финансовый стимул для импорта.

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

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

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

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

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

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

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

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

Изображение базы данных через Shutterstock