Расширение смарт-контрактов с помощью SQL

Особая благодарность Цзюнь Цзяну из DePHY Network и Райану Соури из Usher Labs за отзывы и идеи. В 2008 году на Уолл-стрит зазвонили тревожные сигналы, когда искушенные трейдеры впали в первобытное безумие. Финансовые учреждения с избыточным кредитованием, рухнувшие под тяжестью ценных бумаг, обеспеченных субстандартной ипотекой, оставили жадных банкиров беззащитными и молящими о спасении. Центральные банки, отчаянно пытающиеся удержать свою власть, заплатили за грехи банкиров из чековой книжки простого человека. Это предательство обнажило недостатки централизованной денежной системы, показав необходимость в более новой, более свободной и справедливой финансовой системе. Так же, как Американская революция и последовавшая за ней конституция разделили церковь и государство, возникла новая революция под названием Биткоин, чтобы разделить деньги и государство, обеспечив многие из тех же самых свобод и свобод, которые являются основополагающими для самоопределения. Технология блокчейн — это технология свободы. Она позволяет нам создавать финансовые, идентификационные, информационные и социальные системы координации, которые не требуют доверия к централизованному посреднику. Индивидуальные свободы процветают в мире, где центральный банк не контролирует поток денег, единая платформа не контролирует социальный дискурс, а единая компания не контролирует цифровые идентичности. Многие различия между этим новым миром и тем, где мы находимся сегодня, заключаются в технических возможностях блокчейн-платформ. Первое поколение смарт-контрактов было вершиной айсберга, который сделал возможными эти системы свободы; однако их возможности принципиально ограничены. В этой статье я объясняю некоторые критические ограничения в текущих смарт-контрактах и то, как новая система, «SQL Smart Contracts», обеспечивает более технически эффективную основу для разблокирования человеческих свобод и реализации потенциала блокчейна как новой вычислительной платформы. Смарт-контракты: программирование машины правды «Корень проблемы... в доверии, которое необходимо для того, чтобы все это работало». - Сатоши Накамото Первоначальное основное свойство блокчейна — неизменность; как только определенный порог заинтересованных сторон (или «узлов») в сети соглашается, что что-то является правдой, блокчейн будет сохранять постоянную запись этой истины. Блокчейны используют различные механизмы «доказательств», в которых узлы тратят большие суммы в форме вычислительной мощности, финансовой доли или репутации, чтобы гарантировать, что злоумышленники не смогут манипулировать правдой. Если Bitcoin — это «машина истины» для цифровой валюты, Ethereum — это «машина истины» для более сложных финансовых продуктов. Ethereum расширяет возможности Bitcoin, создавая программируемое пространство проектирования, где разработчики могут реализовать любую логику для развертывания, проверки и выполнения в серии узлов. Это означает, что теперь мы можем создавать системы, которые устраняют необходимость доверия к центральному органу за пределами только валюты! Любая система, требующая центральных органов власти, — например, кредитование, сделки с недвижимостью, идентификационная информация, социальные сети, экономические показатели и т. д. — теперь может работать без центральных посредников. Это совершенно новый мир! Смарт-контракт — это программа, которую разработчики пишут и развертывают на блокчейне, холсте для разработчиков, чтобы создавать децентрализованные приложения. Термин «смарт-контракт» не означает юридический договор, в котором две стороны связаны определенными правами и обязательствами. Вместо этого «смарт-контракт» просто означает, что приложение гарантированно будет функционировать именно так, как написан код, на неопределенный срок. Кредитные договоры гарантируют, что заемщики и кредиторы всегда могут совершать сделки. Договоры о недвижимости гарантируют, что люди всегда могут проверить и передать право собственности на имущество. Смарт-контракт — это приложение, в котором код становится законом. Стив Джобс назвал компьютер «велосипедом для ума». Смарт-контракты гарантируют, что колеса никогда не отвалятся. Смарт-контракты Ethereum: вершина айсберга «Крипто — это не просто торговля токенами, это часть более широкой идеи защиты свободы и конфиденциальности, а также сохранения власти в руках простых людей». — Виталик Бутерин Хотя смарт-контракты Ethereum открыли совершенно новый мир децентрализованных продуктов, фундаментальные ограничения в их конструкции и возможностях манипулирования данными не позволяют им быть эффективными во многих приложениях за пределами криптовалюты. В Solidity (язык программирования для Ethereum) данные контракта хранятся в парах ключ-значение. Хотя (группировки переменных) и (коллекции пар ключ-значение) представляют собой полезные способы организации данных, все данные можно извлечь только по их ключу. Рассмотрим теоретический контракт для хранения данных идентификации пользователя: структуры сопоставления contract IdentityStorage { // Struct to store KYC details struct identity { string fullName; string dateOfBirth; string residentialAddress; } // mapping a country to its citizens to their info // "Canada" => 0x123… => {Vitalik Buterin, 01/31/1994, ...} mapping(string => mapping(address => identity)) public idData; //...rest of contract } В этом контракте запись личности пользователя может быть получена только при знании страны и адреса кошелька пользователя. Если только разработчик контракта не перепроектирует смарт-контракт для манипуляции данными с высокой стоимостью газа, у пользователя контракта нет других способов получить запись личности. Хранение данных в парах ключ-значение в конечном итоге ограничивает то, как можно получить доступ к данным и манипулировать ими. В частности, управление данными в смарт-контрактах Ethereum сопряжено с двумя фундаментальными проблемами: зависимостью от индекса и зависимостью от пути доступа. Индексная зависимость Зависимость от индекса означает, что для доступа к определенной части данных данные должны быть доступны в индексе. Индекс — это структура данных, которая эффективно ищет уникальный идентификатор в коллекции. В примере контракта KYC выше записи доступны только через точный адрес Ethereum, используемый для ключа. Эта жесткая структура индексации не позволяет пользователям контракта запрашивать данные на основе других критериев, таких как «Какие пользователи имеют этот адрес проживания?» или «Какой процент пользователей с этим национальным идентификатором родился после 1 января 1970 года?» Без возможности выполнять такие запросы разработчикам не хватает гибкости для агрегирования, анализа и построения логики приложения вокруг данных контракта. Когда разработчикам требуется эта дополнительная гибкость, например, получение записи идентификации по полному имени, необходимо реструктурировать весь контракт. В Ethereum реструктуризация индексов также может увеличить стоимость газа контракта, что еще больше затрудняет удобство использования контракта. Зависимость пути доступа Зависимость от пути доступа означает, что данные доступны и понятны только через определенный путь извлечения. В примере контракта знание страны и адреса кошелька Виталика позволит разработчику получить его идентификационную запись. Однако знание только адреса кошелька не позволит разработчику получить страну происхождения Виталика. Более того, даже если у разработчика есть адрес кошелька Виталика, он не сможет получить его идентификационную запись, если он также не знает страну происхождения (ключ «Канада»). Путь доступа к идентификационной записи Виталика фиксирован; если разработчику нужно попытаться получить свою запись только по адресу кошелька, весь контракт необходимо будет реструктурировать. Зависимость от пути доступа означает, что данные доступны и значимы только в одном направлении, что ограничивает возможность запрашивать или интерпретировать данные с разных точек зрения. Индекс и зависимость от пути доступа создают значительные проблемы для приложений, требующих сложной или развивающейся модели данных. Хотя криптовалюты имеют простые структуры данных, которые могут быть реализованы в Ethereum (токены ERC20 по сути являются просто отображением адресов на балансы), эти проблемы становятся проблематичными для приложений с большим объемом данных. Когда приложению необходимо хранить, запрашивать и манипулировать сложной моделью данных, базовое хранилище ключей и значений Ethereum значительно ограничивает управление данными, что усложняет создание и поддержку приложений, требующих сложного управления данными. Краткий урок истории: реляционная модель «История не повторяется, но часто рифмуется» – Марк Твен В 1970 году Эдгар Ф. Кодд, компьютерный ученый из IBM, опубликовал статью под названием «Реляционная модель данных для больших общих банков данных». В то время самым популярным типом прикладной базы данных была «иерархическая база данных», которая использовала жесткую древовидную структуру, где каждый фрагмент данных хранился в родительском каталоге, подобно тому, как организованы файлы на компьютере. Кодд выступил против иерархической базы данных, предложив более новую, более простую и гораздо более функциональную реляционную базу данных с табличной структурой. Древовидная структура иерархической базы данных означает, что доступ к данным возможен только через жесткую систему понимания родительско-дочерних отношений каждой части данных. В частности, Кодд выделил три ключевые проблемы иерархической системы: Результат запроса часто зависит от того, как организованы данные в хранилище. Если приложение создано с учетом того, что данные будут запрашиваться в том же порядке, в котором они хранятся, то этот порядок не может быть изменен в будущем. Зависимость от порядка: Чтобы получить доступ к определенной части данных, приложение должно знать родителя (т.е. индекс). В противном случае извлечение запрошенных данных невозможно. Зависимость от индекса: доступ к данным или их понимание требуют следования определенному пути извлечения. Если приложение предназначено для извлечения данных с использованием одного конкретного шаблона доступа, оно не может извлекать или интерпретировать те же данные с использованием альтернативных путей. Зависимость от пути доступа: Знакомо? Хотя смарт-контракты Ethereum не имеют зависимости от порядка (карты не упорядочены), те же ограничения зависимости от индекса и пути доступа, которые сдерживали базы данных в 1960-х и 1970-х годах, сдерживают платформы смарт-контрактов сегодня. Ограничения на уровне базы данных — это больше, чем просто незначительная неудача; они в корне ограничивают разработчиков и ограничивают типы приложений, созданных на платформе. Вместо того чтобы сосредоточиться на внедрении новых функций, разработчики, борющиеся с зависимостью от индекса и пути доступа, должны тратить огромные усилия на поддержание функциональности существующего приложения. В 1960-х и 1970-х годах использование базы данных в основном было зарезервировано для жестких бизнес-задач, таких как управление запасами, бухгалтерский учет и общая обработка данных; у разработчиков не было гибкости данных для создания более сложных приложений. Однако после внедрения реляционных баз данных появились значительно более выразительные и ресурсоемкие приложения, что привело к появлению систем ERP, CRM и инструментов бизнес-аналитики. Кроме того, с появлением Интернета эти достижения проложили путь платформам электронной коммерции и приложениям социальных сетей. Разработчики могли реализовывать функции, которые ранее требовали реструктуризации всей базы данных всего несколькими строками SQL. Реляционная база данных была больше, чем сдвигом парадигмы; это была платформа создания категорий, которая позволила появиться принципиально новым приложениям. Сегодня блокчейн-платформы похожи на компьютеры и базы данных в 1970-х годах. Отсутствие эффективной обработки данных на уровне блокчейна означает, что разработчики не могут реализовать более сложные, интенсивно использующие данные децентрализованные приложения. Если основной вариант использования блокчейнов когда-либо выйдет за рамки криптовалюты, нам понадобятся блокчейн-платформы с более эффективной функциональностью обработки данных. Смарт-контракты SQL: более гибкая парадигма «Мера интеллекта — это способность меняться» — Альберт Эйнштейн Так же, как коммерциализация реляционных баз данных в 1980-х годах привела к появлению новых приложений, интеграция реляционных баз данных в блокчейн-платформы имеет тот же потенциал для изменения типов децентрализованных приложений, которые могут быть созданы. В Kwil мы создаем платформу блокчейна и язык смарт-контрактов, которые позволяют разработчикам создавать децентрализованные приложения, использующие полную выразительность SQL. С Kwil разработчики могут использовать гибкость реляционной модели для создания более эффективных, интенсивно использующих данные децентрализованных приложений. Рассмотрим тот же пример хранения идентификаторов, что и ранее. Вместо того, чтобы хранить записи идентификаторов в карте, где каждая запись доступна только по ее ключу, Kwil позволяет разработчикам хранить записи в таблице и использовать гибкий синтаксис SQL для запросов к таблице: database user_registry; table identities { address uuid primary key, name text notnull, date_of_birth int notnull, residential_address text notnull, national_id int notnull, #country_index index(national_id) } action query_by_national_id ($id) public view { SELECT * FROM identities WHERE national_id = $id; } action query_by_dob ($dob) public view { SELECT * FROM identities WHERE date_of_birth > $dob; } В оригинальном смарт-контракте Ethereum не было возможности поиска по идентификаторам и возврата всех пользователей с заданным условием (например, национальный идентификатор) или привязки кошелька на основе определенного атрибута (например, даты рождения). Для включения такой функциональности потребовалась бы реструктуризация контракта для добавления дорогостоящих, газоемких функций. Однако с реляционной моделью разработчики могут выполнять эти запросы без какой-либо реструктуризации, тем самым получая большую гибкость в обработке данных без дополнительных затрат. Например, — это суверенный блокчейн, созданный с помощью Kwil, позволяющий пользователям и dApps хранить учетные данные пользователей. Использование SQL в сети idOS позволяет: сеть idOS Пользователи будут связаны и доступны для извлечения по нескольким кошелькам, учетным данным и атрибутам. Протоколы DeFi выполняют совокупный анализ местонахождения своих пользователей. Протоколы стейблкоинов для оценки пользователей из зон повышенного риска. Использование реляционной модели и SQL на децентрализованной блокчейн-платформе позволяет нам создавать принципиально новые приложения, которые не могут существовать на существующих смарт-контрактах Ethereum. Заключение Реляционная модель, которая произвела революцию в компьютерной индустрии 40 лет назад, имеет те же возможности, которые сегодня революционизируют индустрию блокчейна. В 1960-х и 1970-х годах зависимость индекса и пути доступа ограничивала полезность иерархической базы данных в приложениях с интенсивным использованием данных. Сегодня та же зависимость индекса и пути доступа ограничивает смарт-контракты Ethereum и их способность обеспечивать работу децентрализованных платформ со сложными моделями данных. Однако, интегрируя реляционную модель в блокчейн и предоставляя разработчикам тот же выразительный диалект SQL, мы можем открыть новые типы приложений. Так же, как реляционная база данных ускорила спрос бизнеса и помогла компьютерам достичь массового принятия, она может помочь платформам блокчейна сделать то же самое, тем самым открыв более свободный, более децентрализованный, более заслуживающий доверия цифровой мир.