Radix (EXRD) - единственное реальное решение проблем DeFi

Radix (EXRD) - единственный протокол, который использует сегментирование для обеспечения линейной масштабируемости - без нарушения возможности компоновки. Это означает, что Radix может удовлетворить потребности в пропускной способности любого количества dApp по мере роста сети, и все эти dApps могут продолжать взаимодействовать без ограничений.

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

Radix (EXRD) разработанный специально для приложений DeFi, Radix Engine обеспечивает безопасную разработку с использованием «компонентов» конечного автомата, а не полных смарт-контрактов Тьюринга.

Компонентность создала современный Интернет

Начнем с истории успеха компоновки, которая, возможно, лежит в основе использования Интернета сегодня.

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

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

Как REST этого добился? Он установил простой набор компонентов, ориентированных на сообщения. Эти компоненты побуждали разработчиков думать о функциональности своего приложения в терминах простых сообщений, которые оно может отправлять и получать. Любое приложение, предлагающее такой «RESTful API», абстрагируется как «услуга» (отсюда и распространенное сегодня облачное предложение «программное обеспечение как услуга»). Любой разработчик может быстро использовать и комбинировать сервисы RESTful, независимо от того, насколько сложен сервис внутри.

Составная разработка функциональности, ориентированной на сообщения, с использованием конечных точек RESTful API Составная разработка функциональности, ориентированной на сообщения, с использованием конечных точек RESTful API

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

Этот подход полезен не только в открытом Интернете, но и внутри компаний. Концепция «микросервисов» охватила большую часть разработки серверных систем, поскольку она очень похожа на REST. Функциональные возможности серверной части объединены в простые абстрактные API обмена сообщениями, что обеспечивает быструю интеграцию и предсказуемое добавление новых и незапланированных функций в будущем.

Проблема с составными смарт-контрактами

Сегодня в мире блокчейнов и DLT распространено предположение, что приложения DLT должны создаваться с использованием смарт-контрактов, каждый из которых представляет собой черный ящик функциональности. Здесь «компонуемость» принимает форму связи между смарт-контрактами, которые принимают сообщения в цепочке (или в реестре) и обрабатывают их. Это очень похоже на модель компонуемости REST для Интернета - просто перемещено в блокчейн или другой DLT. Типичные смарт-контракты DLT поощряют ориентированный на сообщения шаблон взаимодействия, аналогичный веб.

Типичные смарт-контракты DLT поощряют ориентированный на сообщения шаблон взаимодействия, аналогичный веб.

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

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

Соединения для обмена сообщениями, которые разработчик должен поддерживать для выполнения одной транзакции «поезд и отель».

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

Пример составного обмена сообщениями смарт-контракта из вики Ethereum

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

Недавно в сообществе Ethereum возникли дополнительные дебаты по поводу возможности компоновки. Разработчики предпочли бы, чтобы все необходимые сообщения запроса / получения передавались быстро и синхронно, эффективно работая как единая система. Однако предложенный Eth2 сегмент состояния заставит смарт-контракты жить в разных сегментах, и поэтому сообщения, передаваемые между ними, будут асинхронными. Хотя модель компоновки, ориентированная на сообщения, по-прежнему будет функционировать, сегментирование добавит дополнительную нагрузку на разработчика и увеличит задержки транзакций.

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

Компоновка, ориентированная на активы для DLT

Как показывает пример REST, чтобы сделать DLT действительно компонуемым, нам нужен «родной» lingua franca (краткий язык-мост для определенной цели), который использует простые компоненты, чтобы побудить разработчиков «прямо говорить» о том, для чего DLT лучше всего подходит. Интернет - это технология общения, для которой нужен язык сообщений. DLT - это технология транзакций, которая требует нового языка ресурсов, чтобы сделать взаимодействие между приложениями DLT естественным, простым и интуитивно понятным.

Говорим ли мы о криптовалютах или выпуске облигаций, CryptoKitties или цепочках поставок в реальном времени, DeFi или IoT, суверенной идентичности или национальных выборах - все эти приложения интуитивно разбиваются на транзакции с активами, такими как монеты, облигации, предметы коллекционирования, продукты, ссуды, пакеты данных, удостоверения личности или голоса. Работа DLT должна заключаться в проведении транзакций в соответствии с уникальными правилами каждого актива, которые моделируют ожидания разработчиков относительно того, как они должны себя вести.

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

Благодаря саморегулирующимся активам, выпущенным на DLT, создание новых функциональных возможностей для разных предприятий, таких как покупка в поезде и гостинице, является простым и прямым. Разработчик может запросить единую интуитивно понятную «атомарную» транзакцию, которая включает в себя как билет, так и комнату, используя соответствующую валюту для каждого, даже если активы определены и контролируются разными эмитентами. Затем DLT может правильно принять или отклонить всю запрошенную транзакцию сразу, по желанию разработчика, без каких-либо специальных усилий разработчика. Выполнение транзакции «поезд и отель» между компаниями за один интуитивно понятный шаг.

Выполнение транзакции «поезд и отель» между компаниями за один интуитивно понятный шаг

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

Как и в случае с REST, этот подход полезен не только для транзакционных систем на публичных или консорциумных платформах DLT, но и для частных развертываний. Это связано с тем, что объединяемость ресурсов позволяет интегрировать не только несколько предприятий, но и позволяет нескольким системам в рамках сложного предприятия использовать единый «источник истины» и создавать на его основе новые функции. Например, компания может быстро создать внутреннюю систему бухгалтерского учета между отделами, а затем расширить ее до платформы платежей клиентов без рефакторинга всей серверной части. Настоящая компоновка делает DLT мощной технологией интеграции следующего поколения.

Radix (EXRD)

Подобно блокчейну или другим технологиям DLT, Radix в конечном итоге представляет собой часть программного обеспечения, работающего на узлах (обычно на разных компьютерах), которые вместе составляют сеть; это по своей сути распределенная система, независимо от того, работают ли эти узлы внутри компании или в открытом Интернете. Использование Radix Network означает общение с узлом. Radix упрощает это, предоставляя библиотеки API на Java и Javascript, которые можно интегрировать в приложение разработчика.

Radix Engine и Radix Ledger - это два уровня, которые составляют программное обеспечение, работающее на каждом узле. По идее, это похоже на другие платформы DLT, такие как Ethereum или Hyperledger, у которых есть какой-то уровень приложений (обычно виртуальная машина, которая запускает смарт-контракты) и уровень реестра (обычно блокчейн).

Чтобы получить оптимальную производительность от обоих, Radix Engine и Radix Ledger были созданы с нуля; вместе взятые, они обеспечивают действительно строимую и масштабируемую платформу приложений DLT.

Radix Engine: Прикладной уровень, ориентированный на ресурсы. Вместо запуска кода смарт-контракта для реализации функциональности приложения он содержит безопасные готовые компоненты строительных блоков, которые настраиваются, выпускаются и управляются через Radix API.

Radix Ledger: Уникальный сегментированный дизайн DLT, который проверяет транзакции и операции для каждой транзакции и допускает полное сегментирование состояния. Вместо того, чтобы фиксировать последовательность монолитных блоков, транзакция Radix Engine позволяет Radix Ledger безопасно обрабатывать транзакции параллельно, что означает, что он может достичь чрезвычайно высокой пропускной способности и параллелизма.

Хотя концепция Radix Engine похожа на виртуальную машину, предоставляемую платформами смарт-контрактов, такими как Ethereum или Hyperledger, она представляет собой сдвиг парадигмы от традиционной разработки смарт-контрактов.

Альтернатива смарт-контрактам в стиле Ethereum

«Смарт-контракт» стал общим термином для обозначения кода приложения, который разработчик пишет для развертывания в распределенном реестре. Вслед за новаторским использованием смарт-контрактов Ethereum для повышения программируемости блокчейнов произошел взрывной рост новых платформ блокчейнов смарт-контрактов, которые в значительной степени копируют конкретную реализацию, принятую Ethereum: то есть универсальный язык Тьюринга и виртуальная машина, работающая на бухгалтерская книга. Этой модели следуют Tezos, EOS, NEO, Tron, Hashgraph, Hyperledger и другие.

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

Среда разработки Radix Engine разработана специально для создания логики, которая определяет предсказуемые и правильные результаты в бухгалтерской книге в ответ на запросы. Эта форма программируемости DLT основана на машинах с конечными состояниями (FSM), классе решений, которые распространены в критически важных встроенных системах, где предсказуемая корректность является первым приоритетом. Чтобы прояснить отличие от традиционных смарт-контрактов в стиле Ethereum, мы даем смарт-контрактам Radix Engine имя, более напоминающее их функцию: Компоненты.

Давайте сравним типичный подход смарт-контракта к компонентам Radix Engine.

Смарт-контракт / модель метода Ethereum

Смарт-контракт Ethereum можно рассматривать как черный ящик, развернутый разработчиком в сети. Внутри этого ящика вы можете представить себе небольшой компьютерный сервер общего назначения, на котором выполняется некоторый код. Чтобы заставить этот сервер-в-коробке что-то делать, он предлагает «методы», которые пользователи или другие приложения могут вызывать, отправляя подписанное сообщение. Контракт имеет свои собственные внутренние переменные внутри поля, которые он может обновлять в зависимости от сообщений, которые он получает через его методы.

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

Эта модель является довольно гибкой, теоретически позволяя работать на децентрализованной платформе всему, - отсюда и видение Ethereum «мирового компьютера».

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

Например, даже простой смарт-контракт «пула» ликвидности может быстро стать сложным, и результаты будут разбросаны по нескольким контрактам. Если мы хотим, чтобы наш пул принимал существующий (ERC-20) TokenA в пул и чеканил соответствующее рассчитанное количество TokenS, представляющее долю пула, мы получаем что-то вроде этого:

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

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

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

Модель компонента / действия Radix Engine

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

Более конкретно, это означает, что Компоненты определяются тем, что этот Компонент может делать через свои Действия. Определяя компоненты по их действиям таким образом, мы получаем два важных атрибута, пытаясь избежать плохих результатов.

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

Объяснить, как работают Компоненты и Действия, возможно, лучше всего на нескольких примерах:

Токен, созданный пользователем

Снова возьмем пример с токеном. В Radix разработчикам не нужно использовать монолитный смарт-контракт в стиле ERC-20, который хранит список всех балансов; мы моделируем каждый отдельный неделимый токен (каждый «сатоши» в терминах биткойнов) как отдельный независимый компонент. Основное доступное действие этого компонента токена: «смени моего владельца, если у вас есть на это право». Так, например, входное состояние «до» может принадлежать Алисе, выходное состояние «после» - Бобу - если выполняются условия смены владельца, определенные в действии компонента токена. Это означает, что компонент токена определяется тем, что он может делать: принадлежать разным людям.

Используя модель Radix Component на основе FSM, каждый токен может быть отдельным независимым компонентом с действиями (например, «изменить владельца»), которые определяют их поведение в соответствии с интуитивными ожиданиями.

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

Запас этих токенов может быть создан другим компонентом, который управляет всей поставкой, позволяя отправлять каждый отдельный токен свободно и интуитивно.

Пул ликвидности, который атомарно работает с другими компонентами

Компоненты и их действия могут использоваться не только по отдельности, но и несколько из них могут быть объединены в одной транзакции. В этом случае отображение от ввода к выводу является коллективным, определяемым всеми включенными Действиями одновременно. Например, давайте рассмотрим Компонент «пул ликвидности». Простая версия может быть определена этими Действиями:

  • Действие по депозиту: «Я являюсь владельцем некоторых резервов TokenA и чеканю пропорциональную долю TokenS в пуле всем, кто отправляет TokenA».
  • Действие по выводу средств: «Я являюсь владельцем некоторых резервов TokenA и отправляю пропорциональную сумму TokenA любому, кто отправляет мне токены с долей пула (которые я сжигаю)».

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

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

Для сравнения с приведенным выше случаем Ethereum транзакция депозита в пул Radix Engine выглядит примерно так:

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

Это больше похоже на открытую платформу с интуитивно понятными компонентами, которые нам нужны!

С точки зрения внешнего разработчика, использование действия «депонирование» компонента пула не сложнее, чем использование метода в традиционном смарт-контракте. Но это действие само по себе может определять другие компоненты, которые должны быть задействованы (некоторые конкретные TokensA и TokensS), то есть какие компоненты должны соединить свои механизмы вместе для успешной транзакции.

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

Запрос на транзакцию с ограничениями безопасности потребителей

Чтобы увидеть, как потребитель Component Actions может явно предотвратить плохие результаты, давайте рассмотрим пример компонента Token Swap. Этот Компонент принимает TokenA и возвращает количество TokenB, равное рыночной цене (возможно, предоставленной оракулом или какой-то логикой маркет-мейкера - детали здесь не имеют значения). Его основное действие может выглядеть так:

  • Действие обмена: «Любое получение TokenA приведет к отправке TokenB по формуле: TokenA * [текущая определенная ставка B / A]»

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

Модель действия позволяет пользователю (т. е. Потребителю действия «обмен токенами» «свопинг») также указывать свои собственные правила стиля действия для отображения ввода → вывода следующим образом:

  • Запрос пользователя: «Я отправляю TokenA в действие« swap »компонента Token Swap, что должно привести к отправке мне TokenB не менее [желаемого лимита]»

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

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

Создание компонентов Radix

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

В совокупности мы считаем, что модель Component, наконец, предоставляет специально созданную среду разработки, которая нужна разработчикам DeFi.

Возможность построения Radix

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

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

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

Важность транзакционных систем

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

  • «Каков остаток на текущих счетах наших клиентов?»
  • «Где находятся наши продукты и у кого они есть?»
  • «Кто санкционировал эти транзакции и когда?»

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

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

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

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

Первой транзакционной системой DLT была Биткойн, и она проста: она обеспечивает соблюдение транзакционных правил источника истины «цифровых денег». Как предоставить разработчикам DLT инструменты для создания мира других, более сложных транзакционных систем - для создания лучших источников достоверной информации для мировых предприятий и приложений?

Умный контракт

Обеспечение выполнения транзакционных правил DLT - это роль его прикладного уровня. Уровень приложения находится над уровнем реестра (например, блокчейн) и определяет, как DLT настраивается и используется разработчиками. Он определяет, какие транзакции являются действительными, а уровень бухгалтерской книги разрешает любые конфликты между транзакциями и записывает окончательный достоверный результат. Структура уровня приложения DLT определяет, какие типы транзакционных систем могут быть построены, и насколько сложно это сделать.

На прикладном уровне цифровой наличности Биткойн транзакции выражаются как изменения в «машинах состояний», называемых UTXO. Конечные автоматы мощны, потому что они описывают систему с точки зрения того, что может происходить, а не того, что запрещено . Короче говоря, вместо того, чтобы выполнять проверки «если-то», чтобы избежать неправильных действий, конечные автоматы просто не способны делать неправильные действия по своему определению. Это дает Биткойну присущую ему безопасность как источник правды в цифровой форме.

Платформы блокчейнов после Биткойна стремились обобщить модель прикладного уровня Биткойна, чтобы сделать возможным любое приложение, а не только цифровые деньги. Ethereum предлагал разработку приложений через виртуальную машину, которая запускает специализированный код смарт-контракта , при этом каждый смарт-контракт представлен как единый комплексный конечный автомат. Таким образом, Ethereum создает «мировой компьютер», в котором любые вычисления («завершение по Тьюрингу») выполняются как дискретные обновления одного состояния. Эта же общая модель смарт-контрактов сегодня применяется практически во всех блокчейнах, ориентированных на приложения, включая частные DLT, такие как Hyperledger.

платформы смарт-контрактов

 

Однако подход смарт-контрактов внес тонкое, но важное изменение в модель безопасности. Конечные автоматы Биткойн UTXO довольно просты и напрямую моделируют отдельные транзакции биткойнов. Но конечные автоматы смарт-контрактов больше похожи на сложные черные ящики, где мы гарантируем, что код внутри ящика будет выполняться правильно, но нет никаких гарантий, что код правильно моделирует желаемое поведение . Мы вернулись к написанию проверок « если-то», где ошибки приводят к «правильным» обновлениям состояния, которые могут быть ошибками, так же легко, как и желаемое поведение.

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

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

Путь Radix Engine

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

Давайте еще раз вернемся к вопросам, на которые всегда должен ответить хороший деловой источник правды:

  • «Каков остаток на текущих счетах наших клиентов?»
  • «Где находятся наши продукты и у кого они есть?»
  • «Кто санкционировал эти транзакции и когда?»

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

Родным языком разработки на основе Radix Engine являются активы, и разработка на Radix начинается не с кода смарт-контракта, а с определения активов желаемой транзакционной системы - короче говоря, четкого определения бизнес-потребностей. Сделав активы бизнеса основными строительными блоками для разработки с использованием Radix Engine, транзакции Radix становятся интуитивно понятными:

  • Перемещать деньги между счетами клиентов ( при наличии достаточного баланса);
  • Управлять отгрузкой товаров между перевозчиками ( при соблюдении цепочки поставок);
  • Обработка транзакции в текущее время ( если запрашивающая сторона имеет соответствующие полномочия).

Ограничения «если» должны быть неотъемлемой частью определения активов: деньги - это актив, который может быть движим только при наличии; поставки - это активы, которые могут передать ответственное лицо только следующей стороне в цепочке; Для определенных транзакций определенного типа может потребоваться конкретное одобрение с отметкой времени авторизованными пользователями.

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

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

Сравнительная диаграмма блокчейна и движка Radix

После того, как активы настроены и выпущены, транзакции Radix с их использованием выглядят аналогично интуитивно понятным бизнес-запросам транзакций, подобным тем, которые указаны выше. Radix Engine автоматически гарантирует, что принимаются только действительные транзакции, которые соответствуют правилам всех задействованных активов. Затем действительные транзакции обрабатываются Radix Ledger для разрешения конфликтов и фиксации окончательного обновления состояния источника истины.

Определение, выпуск, управление и транзакции активов Radix Engine осуществляются через Radix API. Библиотеки Radix на широко используемых языках, таких как Java и JavaScript, максимально упрощают использование Radix API. Код смарт-контракта не требуется.

«Ориентированный на ресурсы» подход Radix Engine к разработке приложений DLT имеет множество преимуществ.

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

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

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

Результатом является изначально простой и прямой метод определения транзакционной системы, которая является надежным источником истины для бизнеса. Традиционная система баз данных, обеспечивающая такую ​​функциональность для бизнеса любого масштаба, обычно является предметом работы группы профессионалов, которые создают, поддерживают, отлаживают и проверяют ее. Radix Engine устраняет значительную часть разработки и риска создания такой системы, в то время как его реестр позволяет системе безопасно работать с огромным масштабом, избыточностью и параллелизмом без рефакторинга основного кода приложения.

Как работает Radix Engine

Под Radix API, Radix Engine выражает все эти активы и транзакции как дискретные конечные автоматы, каждый из которых автоматически и индивидуально имеет вид гарантированной действительности, как транзакции на основе конечного автомата Биткойн UTXO. Мы называем это «моделью атома», где «атомы» - это запрошенные транзакции, которые содержат несколько «частиц», которые, если все правильно и неконфликтно, будут индивидуально обновлять все конечные автоматы, представляющие активы бизнеса. Компоненты моделирования ресурсов, представленные в библиотеке Radix Engine, выражаются «под капотом» с помощью этих конечных автоматов частиц.

В большинстве случаев компонентов Radix Engine Library достаточно для моделирования наиболее распространенных активов транзакционной системы. Однако, если более продвинутые разработчики требуют большей настройки, новые типы ресурсов могут быть созданы и развернуты в библиотеке Radix Engine как пользовательские частицы и машины ограничений (правила, которые определяют допустимые изменения состояния частиц). 

Radix шардинг

Шардинг - это когда большая база данных разбивается на множество более мелких баз данных, поэтому узлы обрабатывают только часть реестра, а не целиком. Многие DLTS используют сегментирование , чтобы увеличить скорость и масштабируемость сети , как это менее интенсивно обрабатывать 1/100 в DLT , чем во всей ее полноте. Это означает, что сеть выигрывает, потому что:

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

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

Однако сегментирование имеет недостатки и должно быть реализовано таким образом, чтобы не открывать новые направления атак и не нарушать целостность реестра. Шард, которому посвящена 1/100 часть общей хэш-мощности сети, требует только 1/100 хеш-мощности для атаки, что увеличивает вероятность атаки 51%. Сети должны избегать таких проблем, избегая централизованных решений, таких как главные узлы или координирующие органы.

Шардинг с первого дня для удовлетворения будущего спроса

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

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

Однако Radix с самого начала полностью сегментирован. Он будет запущен с уже существующим максимальным количеством 18,4 квинтиллионов шардов. Это сделано для того, чтобы мы могли достичь того масштаба, который в конечном итоге понадобится для глобальной платформы. Каждый шард сможет обрабатывать 2000 транзакций в секунду, что соответствует общей гипотетической пропускной способности 36,8 секстиллионов транзакций в секунду при полной загрузке. Каждый узел поддерживает как можно больше осколков, сбрасывая слишком тяжелые осколки, чтобы в нем могли участвовать даже маломощные устройства. Для обеспечения высокой доступности система перемещает узлы в недостаточно обслуживаемые сегменты.

Если бы каждый осколок содержал 0,5 байта, то сеть могла бы хранить то, что Рэндалл Манро оценил в 2014 году как совокупность данных Google, 10 эксабайт. На самом деле, конечно, нам не нужно хранить где-то рядом с этим количеством - Google хранит огромное количество видео и других мультимедийных файлов с большим объемом памяти, тогда как Radix будет хранить более простую текстовую информацию, такую ​​как истории транзакций.

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

Детерминированные данные

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

Почему это индексирование имеет значение? Что ж, представьте, что у вас очень большая коллекция книг, и каждый раз, когда вы покупаете новую книгу, вам нужно переиндексировать всю полку, потому что что-то изменилось. Однако, учитывая объем данных, обрабатываемых DLT, более подходящей аналогией было бы предположить, что вы должны хранить каждую когда-либо созданную книгу, но при этом знать, где находится каждое слово из каждой из этих книг. И каждый раз, когда добавлялась новая книга, каждое слово из каждой книги было реорганизовано, но вам приходилось (мгновенно) отслеживать новый порядок. На это, мягко говоря, уйдет много времени.

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

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

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

Группировка транзакций для увеличения пропускной способности

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

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

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