Изначально статья была опубликована в Coindesk 14 мая 2019 года.
Есть определенный тип разработчиков, уверяющих, что блокчейны это просто ужасные базы данных. Они говорят почему бы просто не использовать развитый, надежный и эффективный PostgreSQL для вашего приложения? Скептики утверждает, что блокчейны, в сравнении с реляционными базами данных, медленные, запутанные, дорогие и немасштабируемые.
Я предлагаю простое опровержение сторонникам этого мнения: публичные блокчейны - это широкомасштабные мультиклиентские базы данных, в которых каждый пользователь владеет всеми правами в системе. Они удобны для хранения общего состояния пользователей, представляющее собой ценные данные, которые пользователи хотят безопасно экспортировать — например, свои деньги.
Проблемы экспорта/импорта данных
AWS имеет значки для всего, кроме общего состояния между учетными записями.
Есть значки для балансировщиков нагрузки, транскодеров, очередей и лямбда-функций. Существуют значки для VPC и всех типов баз данных на свете, включая новые управляемые блокчейн-сервисы (которые отличаются от публичных блокчейнов, и полезны только при определенных обстоятельствах).
Для состояния между учетными записями значка нету. То есть, все облачные диаграммы неявно предполагают, что один объект и его сотрудники (а именно объект с доступом к корневой учетной записи) являются единственными, кто выкладывает архитектурную диаграмму и считывает или записывает в приложение, которым она поддерживается. Эти диаграммы обычно более точно предполагают наличие одного экономического субъекта, а именно того, кто оплачивает счета за облако.
Если визуализировать облачные диаграммы не для одного, а для сотни корпоративных экономических субъектов одновременно, то сразу же возникает много вопросов. Могут ли эти структуры взаимодействовать? Могут ли их пользователи извлекать свои данные и переносить их в другие приложения? И учитывая, что пользователи сами являются экономическими субъектами, могут ли они быть уверены, что их данные, представляющие собой какую-то денежную ценность, не были изменены во время всего этого экспорта и импорта?
Все эти вопросы возникают, когда мы рассматриваем экспорт и импорт данных каждого субъекта из приложения, как необходимое требование. И (за исключением некоторых примеров которые мы рассмотрим), ответ на эти вопросы сегодня, как правило, нет.
Нет — различные приложения обычно не имеют совместимого программного обеспечения, или не позволяют своим пользователям легко экспортировать/импортировать свои данные в стандартной форме, или не дают пользователям уверенность в том, что их данные не были намеренно подделаны или непреднамеренно повреждены во время всего экспорта и импорта.
Причина этого сводится к стимулам. Для большинства крупных интернет-сервисов просто нету никаких финансовых стимулов для того чтобы их пользователи экспортировали свои данные, не говоря уже о том, чтобы позволять конкурентам быстро импортировать эти же данные. Некоторые называют это проблемой переносимости данных, но мы назовем это проблемой экспорта/импорта данных, чтобы сосредоточить внимание на конкретных механизмах экспорта и импорта.
Как мы экспортируем/импортируем данные APIs, JSON, PDF, CSV, MBOX и/или SFTP на сегодняшний день
Давайте рассмотрим их по очереди, чтобы понять текущее положение дел.
APIs. Одним из наиболее популярных способов экспорта/импорта данных является интерфейс прикладного программирования, более известный как APIs. Некоторые компании позволяют получать часть своих данных или записывать данные в свою учетную запись. Но это не бесплатно. Во-первых, их внутренний формат данных обычно является проприетарным, а не отраслевым стандартом. Во-вторых, иногда APIs не играют основной роли для бизнеса и могут быть отключены. В-третьих, в отдельных случаях APIs могут играть главную роль и цена на них может быть резко повышена. Вообще, если вы читаете или пишете в размещенный API, то находитесь во власти поставщика API. Это называется это риском платформы, и грубое де-платформирование нанесло вред многим стартапам.
JSON. Еще одно сопутствующее решение это разрешить пользователям и скриптам загружать файлы JSON или читать/записывать их в вышеупомянутые APIs. Это отличное решение, вместе с тем, JSON очень свободная форма и может описать практически все. Например, API Graph Facebook и REST API LinkedIn имеют дело с похожими вещами, но приносят очень разные результаты JSON.
PDF. Другое решение - разрешить пользователям экспортировать PDF-файл. Оно работает для документов, так как PDF - это открытый стандарт, который может быть прочитан приложениями, типа Preview, Adobe Acrobat, Google Drive, Dropbox и так далее. PDF-файл является конечным продуктом, предназначенным для чтения человеком. Он не предназначен для ввода ни в какое приложение, кроме программы для просмотра данных файлов.
CSV. Простой файл значений, разделенный запятыми, становится ближе к тому, что мы хотим для решения проблемы импорта/экспорта данных. В отличие от бэкэнда коммерческого API, CSV - это стандартный формат, описанный через RFC 4180. В отличие от JSON, представляющего практически все, CSV это простая таблица. В отличие от PDF, он может быть отредактирован пользователем с помощью электронной таблицы или использован в качестве машиночитаемого ввода в локально установленное или облачное приложение. Большинство видов данных могут быть представлены в реляционной базе данных, а поскольку реляционные базы данных обычно могут быть экспортированы как набор гигантских 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 без централизации. Общедоступные блокчейны предоставляют канонические методы доступа для чтения/записи, такие как размещенный корпоративный API, но без такого же риска для платформы. Ни один хозяйствующий субъект не может закрыть или отказать в обслуживании клиентам децентрализованного публичного блокчейна типа Bitcoin или Ethereum.
Импорт/экспорт без потерь. Публичные блокчейны также позволяют отдельным пользователям экспортировать критически важные данные на свой локальный компьютер или в новое приложение, такое как JSON/CSV/MBOX (либо путем отправки средств, либо путем экспорта закрытых ключей), обеспечивая при этом криптографические гарантии целостности данных.
Стимулирование взаимодействия. Публичные блокчейны обеспечивают произвольные экономические субъекты (будь то корпорации, отдельные пользователи или программы) беспрепятственным взаимодействием. Каждый хозяйствующий субъект, читающий из публичного блокчейна, видит один и тот же результат, и любой хозяйствующий субъект с достаточными средствами может написать в публичный блокчейн точно так же. Настройка учетной записи не требуется, и ни одному пользователю не может быть заблокирован доступ на чтение и запись.
Целостность криптографических данных. И, пожалуй, самое главное, публичные блокчейны дают финансовые стимулы для совместимости и целостности данных.
Последний момент заслуживает дальнейшего разъяснения. Публичный блокчейн, типа Bitcoin или Ethereum, обычно фиксирует передачу вещей с денежной ценностью. Это может быть собственная криптовалюта цепи, токен, выпущенный поверх цепи, или другой вид цифрового актива.
Поскольку данные, связанные с публичным блокчейном, представляют какую-то денежную ценность, это и является финансовым стимулом для совместимости. Ведь любое веб-приложение или мобильное приложение, желающее получить (скажем) BTC, должно соблюдать условное обозначение Bitcoin блокчейна. Действительно, у разработчиков приложений не было бы выбора из-за того, что Bitcoin по дизайну имеет единую, каноническую самую длинную цепь доказательств выполненных работ с криптографической проверкой каждого блока в этой цепи.
Вот такой финансовый стимул для импорта.
Что касается стимула для экспорта, то, когда речь идет в частности о деньгах, пользователи требуют возможность экспортировать с абсолютной точностью, причем очень быстро. Это не старые фотографии котов, которые могут быть утеряны из-за неудобств или технических проблем. Это их деньги, их биткоин, их криптовалюта. Любое приложение, которое хранит ценности, должно быть доступным для экспорта, когда пользователи захотят их снять, будь то поддержка функциональности отправки, предложение резервных копий с закрытым ключом или и то, и другое. Если нет, то приложение вряд ли когда-нибудь получит вклады изначально.
Так вот, в этом и заключается финансовый стимул для экспорта.
Таким образом, публичный блокчейн экономически стимулирует каждый субъект, который взаимодействует с ним, использовать тот же формат импорта/экспорта, что и любой другой субъект, будь то корпорация, пользователь или программа. Иными словами, публичные блокчейны - это открытые базы данных состояний. Это следующий шаг после открытого исходного кода, так как он обеспечивает открытый доступ ко всем данным. Любой желающий может прочитать все данные из публичного блокчейна, чтобы создать блокпроверку, и любой может написать в публичный блокчейн с собственным кошельком. Это сильно отличается от того, как работает, скажем, база данных Facebook или Twitter!
Публичные блокчейны - это широкомасштабные мультиклиентские открытые базы данных
Это настоящий прорыв. Теперь у нас есть надежный способ стимулировать использование общего состояния, одновременно предоставляя миллионам людей и компаний доступ к чтению (и тысячам для записи) из одного и того же хранилища данных, одновременно обеспечивая соблюдение общего стандарта и поддерживая высокую уверенность в целостности данных.
Это значительно отличается от статуса-кво. Обычно вы не предоставляете общий доступ к корневому паролю для базы данных в Интернете, поскольку база данных, позволяющая читать и записывать в нее, обычно коррумпируется. Публичные блокчейны решают эту проблему с помощью криптографии, а не разрешений, значительно увеличивая количество одновременных пользователей.
Другими словами, публичные блокчейны являются широкомасштабными мультиклиентскими открытыми базами данных, где каждый пользователь владеет всеми правами в системе.
Один из способов понять это изнутри - посмотреть на btc.com, blockchair.com и blockcypher.com - все они одновременно читают с одного Bitcoin-блокчейна. А затем посмотрите на coinbase.com, binance.com и kraken.com - все они также одновременно читают и пишут транзакции в один Bitcoin-блокчейн. И, наконец, посмотрите на таких майнеров, как AntPool, F2Pool и ViaBTC - все они читают и записывают блоки в один Bitcoin-блокчейн.
Любой пользователь с некоторым BTC может читать, писать транзакции и майнить блок биткоина при подключении к интернету. Вот что означает публичный блокчейн: каждый пользователь владеет всеми правами в системе.
Любой пользователь имеет полный доступ для чтения к Bitcoin-блокчейну, что демонстрируют три исследователя блоков.
Любой пользователь с BTC может писать транзакции в Bitcoin-блокчейн, что демонстрируют три биржи.
Сегодня публичные блокчейны сосредоточены на денежных и финансовых приложениях, где базовый набор данных представляет собой историю транзакций только для добавления с неизменяемыми записями. Это ограничивает их универсальность для решения всех различных версий проблемы импорта/экспорта данных. На данный момент, идет разработка публичных версий блокчейна, таких как OpenStreetMaps, Википедия и Twitter, а также систем, таких как Filecoin/IPFS. Они не просто представляют записи финансовых операций, в которых неизменность является обязательным требованием, но могут представлять другие типы данных (например, записи карты или энциклопедии), которые будут регулярно обновляться.
Действительно, эти новые типы публичных систем на основе блокчейна могут позволить любому хозяйствующему субъекту, имеющему достаточные средства и/или криптографические учетные данные, не только читать и писать, но и редактировать свои собственные записи, сохраняя при этом целостность данных. Учитывая эту возможность, нет причин ставить SQL-слой поверх общедоступного блокчейна для работы с общим состоянием, которое он предоставляет, точно так же, как старомодная реляционная база данных. Это приводит к новому типу базы данных без привилегированного владельца, где все семь миллиардов людей на планете (и их скрипты!) являются авторизованными пользователями, которые могут быть записаны в любой объект с достаточными средствами.
Это имело бы мощные последствия второго порядка. Обход общедоступных блокчейнов ("цепной обход") проще, чем веб-обход, поскольку веб-сайты имеют файлы robots.txt, которые не позволяют обычным людям индексировать их. Но если больше данных хранится на публичных блокчейнах, то поверх этих открытых государственных баз данных можно построить больше новых сервисов. Действительно, это обеспечивает долгосрочное видение для открытия бэкендов социальных сетей и поисковых систем в режиме защиты конфиденциальности и сохранения целостности данных.
Этот день еще не наступил. Остается ждать, насколько далеко мы можем продвинуть варианты использования публичных цепей и сложностей с их масштабированием. Но, надеюсь, ясно, что, хоть публичные блокчейны действительно являются новым видом базы данных, они предлагают что-то совсем другое, в отличии от традиционной базы данных. Это база данных, в которой каждый пользователь является корневым пользователем.
Исключение составляет так называемая функция "Requester Pays", которую предлагает Amazon и другие облачные сервисы. Это классная функция, которая позволяет кому-то платить за запись в ваше S3-корзину. Но он все еще требует, чтобы каждый будущий автор открыл счет AWS, и владелец корзины должен быть готов позволить им всем писать в нее, так что есть еще один авторитетный владелец.
Вместо заключения
Мнения, выраженные в этой статье, являются мнениями Balaji S. Srinivasan, цитируемого выше, и не обязательно соответствуют мнениям NEAR.
NEAR – это блокчейн протокол и платформа для разработки децентрализованных приложений с акцентом на простоту разработки, и простоту использования для конечных пользователей.
Код NEAR открыт, наша реализация написана на Rust, её можно найти тут.
Если у вас есть идеи сервисов, управляемых сообществом, и вы хотите над ними работать, приходите в нашу программу поддержки предпринимателей.
Если вы разработчик, присоединяйтесь к экосистеме.