Распространение RWA за пределы Fintech на каждый физический и цифровой продукт, сертификат и т. д.*
Авторы: Дэвид Беберман и Майкл Холдманн
Переосмысление концепции учетной записи Blockchain
Биткойн представил концепцию децентрализованного реестра, основанного на консенсусе, и способы его использования для представления криптовалюты. Биткойн использовал простой язык сценариев, чтобы обеспечить управление концепцией реестра, обеспечивая обмен криптовалютой между записями в реестре (т. е. учетными записями).
Эфириум дополнил концепцию децентрализованного, основанного на консенсусе реестра, обобщив простой язык сценариев до полного по Тьюрингу языка, одновременно используя концепцию «газа» для решения проблемы непрекращения завершения, присущей полным по Тьюрингу языкам.
Я думаю, все согласятся, что эти две концепции оказали потрясающее влияние во всем мире. Но какими бы великими ни были эти концепции, возможно, это переломный момент в истории, мы думаем, что существует еще один эволюционный этап в технологии блокчейна, который еще больше увеличит ее распространение.
Чтобы объяснить концепцию нашей новой технологии, давайте начнем с упрощенной, несколько неточной аналогии между технологией блокчейна и более понятной технологией — электронными таблицами (например, MS Excel, Google Sheets).
Аналогия с электронными таблицами
Если мы рассматриваем Биткойн как одну (виртуальную) электронную таблицу, мы можем рассматривать каждую учетную запись как строку в электронной таблице. Переводы биткойнов между счетами — это переводы между строками. Хэш платежа по сценарию («P2SH») можно рассматривать как наличие сценария, связанного с отдельной ячейкой в строке отдельной учетной записи. Поскольку это виртуальная электронная таблица, одной из ее полезных особенностей является то, что количество строк практически бесконечно. Это означает, что пользователи могут создавать столько учетных записей, сколько пожелают, что концептуально представляет собой столько строк, сколько они хотят в виртуальной электронной таблице. Я хотел бы отметить, что, за исключением P2SH, который связан с индивидуальной передачей биткойнов, концепция состояния хранения учетной записи не является частью Биткойна.
Ethereum представил концепцию смарт-контракта. Если Биткойн — это одна виртуальная электронная таблица, мы можем рассматривать смарт-контракт Ethereum как введение нескольких виртуальных электронных таблиц. Каждый смарт-контракт представляет собой собственную виртуальную таблицу. Смарт-контракт токена (т. е. ERC 20) имеет массив, содержащий учетные записи и количество токенов, которыми владеет каждая учетная запись. Таким образом, каждый смарт-контракт токена можно рассматривать как имеющий строку для каждой учетной записи и связанное с ней количество токенов. Поскольку смарт-контракт токена представлен отдельной учетной записью в блокчейне, а количество учетных записей по сути не ограничено, в блокчейне Ethereum может существовать неограниченное количество отдельных учетных записей смарт-контрактов, представляющих уникальные типы токенов. Следует понимать, что каждый смарт-контракт по сути автономен, изолирован. То есть, хотя один смарт-контракт может явно вызывать другой смарт-контракт, в частности, как вызов библиотеки, не существует универсального способа совместного использования кода. Чтобы создать новый токен или другое представление данных в Ethereum, необходимо зарегистрировать новый смарт-контракт.
В итоге. с точки зрения учетной записи, Биткойн представил учетную запись как запись в единой глобальной виртуальной электронной таблице. Ethereum представил учетную запись смарт-контракта, которая позволяет использовать несколько виртуальных таблиц, в то время как обычные учетные записи по-прежнему больше похожи на учетные записи Биткойн.
Что, если мы пересмотрим концепцию учетной записи и сделаем все учетные записи умными?
В Ethereum со смарт-контрактом связаны данные о состоянии. Что, если с каждой учетной записью связано состояние?
Что, если учетная запись может создавать и содержать произвольные объекты в своем состоянии?
Что, если, используя объектно-ориентированную парадигму, код для таких объектов будет получен из классов, и эти классы будут один раз зарегистрированы в блокчейне и повторно использованы учетными записями?
Что, если бы поддерживалась объектно-ориентированная концепция наследования, при которой объекты были бы экземплярами классов, которые, в свою очередь, могли бы наследовать большую часть своего кода от классов-предков.
Разветвления
Каковы последствия того, что учетные записи владеют объектами вместо количества собственных токенов?
Каковы последствия создания (создания экземпляров) новых объектов без необходимости регистрации нового кода?
Каковы последствия того, что новые классы, однажды зарегистрированные в блокчейне, становятся немедленно пригодной для использования, по сути, неотъемлемой частью блокчейна для всех пользователей?
Чтобы рассмотреть это, нам нужно предложить новые способы использования блокчейна:
Как пользователь блокчейна, я хотел бы иметь возможность создавать новые активы в своей учетной записи на блокчейне и продавать их. Точно так же я хотел бы иметь возможность покупать другие активы и перепродавать их. Я хотел бы иметь возможность совершать такие транзакции как на торговых площадках и биржах, так и между людьми (т. е. от кошелька к кошельку).
Поскольку я не могу заранее знать, какой тип актива я могу купить или продать, я хочу, чтобы все активы имели некоторую общность между собой, но при этом поддерживали уникальные функции для каждого типа активов. Я хочу, чтобы моя учетная запись поддерживала все активы независимо от типа, и я хочу, чтобы мой кошелек мог поддерживать все активы независимо от типа. Как пользователь и владелец активов я не хочу знать или прикасаться к программному коду. Мне нужны гарантии того, что код, управляющий моими активами, действителен, но я не хочу смотреть или трогать этот код больше, чем код, который запускает мой мобильный телефон или ноутбук. Как оказалось, в информатике мы решили эту проблему с помощью объектно-ориентированной концепции и наследования классов.
Если с учетными записями могут быть связаны произвольные объекты активов, а объекты являются экземплярами классов, которые содержат код для управления активами, то мы можем предоставить пользователю эти возможности. Это прямой результат разветвления учетных записей, владеющих объектами, объектов как экземпляров классов и классов как основной концепции кода в блокчейне.
Модель учетной записи SagaChain
Модель учетной записи SagaChain обобщает концепцию учетной записи, впервые представленную в Биткойне и расширенную за счет включения учетных записей смарт-контрактов с Ethereum на все записи учетных записей, включая данные о состоянии, а не только на смарт-контракты. В SagaChain каждая запись учетной записи теперь включает хеш состояния, а не только учетные записи смарт-контракта. По сути, это делает каждую учетную запись «умной». Каждая учетная запись теперь может включать объекты, которые могут представлять активы.
Кроме того, посредством объектно-ориентированного наследования все объекты активов могут наследовать общее поведение родительского класса (например, Class Asset). Сложные отношения можно легко представить с помощью информации о состоянии каждого экземпляра объекта, которая фиксируется в информации о состоянии каждой учетной записи. Поскольку учетные записи по сути не ограничены, может быть неограниченное количество учетных записей, содержащих как экземпляры объектов, так и код для наследуемых классов, хранящихся в блокчейне.
Возвращаясь к моему желанию пользователя никогда не прикасаться к коду и не знать его явно, с помощью магии наследования я могу просто создавать новые объекты активов известного типа (т. е. класса), отправляя транзакции на принадлежащую мне учетную запись, ссылаясь на тип объекта, который я хочу создать. Кроме того, я могу покупать и продавать такие объекты активов, отправляя транзакции, ссылающиеся на эти объекты. Мне как пользователю не нужно знать о языке сценариев Forth Биткойна или языке смарт-контрактов Solidity Ethereum.
PraSaga SagaChain создает новый подход к блокчейнам, токенам и владению активами посредством внедрения следующих дополнительных технологий:
1.Системная расширяемая объектная модель блокчейна SagaChain (SagaOS)
2.Классы расширяемых смарт-объектов («SagaSA»)
3.Алгоритм масштабируемого шардинга SagaChain (SagaScale) и протокол гибридного консенсуса
Чтобы узнать больше о запатентованной технологии PraSaga, свяжитесь с нами через наш сайт prasaga.com.
Объекты, классы и потоки передачи
Поток транзакции: явный продавец и покупатель
1.Учетная запись создателя создает объект актива. Этот объект актива может относиться к виртуальному или физическому активу.
2.Учетная запись продавца активов создает объект котировки с адресом учетной записи покупателя. (Покупателю предоставляется ссылка на объект котировки извне)
3.Учетная запись покупателя активов создает объект заказа на покупку со ссылкой на объект котировки. (Продавец предоставляет ссылку на объект заказа на покупку извне)
4.Аккаунт продавца активов принимает заказ на покупку, передавая заказ на заказ Qoubojteect
а)Объект Quote отправляет объекту заказа на заказ ссылку на актив
б)и получает сообщение с суммой SagaCoin от заказа на заказ. объект.
5.Объект Quote увеличивает счет SagaCoin и удаляет себя.
6.Объект PO сохраняет ссылку на объект актива и удаляет себя.
Безопасность транзакций с помощью подписей
1.Все учетные записи содержат увеличивающееся значение nonce.
2.Все транзакции на счете используют увеличивающееся значение nonce.
3.Все транзакции хешируются и подписываются с использованием закрытого ключа учетной записи.
4.К каждой транзакции дополнительно может быть добавлен случайный одноразовый номер для дополнительной защиты подписи закрытого ключа.
5.Результат: все транзакции по передаче активов проверяют участвующие счета с помощью подписей.
Объекты смарт-активов и дробление
Многоуровневое дробление активов
1.Объект фракционирования содержит ссылку на актив. Актив может принадлежать учетной записи, содержащей объект дробления, или может ссылаться на другую учетную запись.
2.Объект фракционирования содержит общее количество созданных фракций и количество оставшихся фракций, которые не были проданы другим учетным записям.
3.Учетная запись, содержащая экземпляр ссылки на дробный объект, имеет ссылку на объект дробления. Экземпляр ссылки на дробный объект может иметь счетчик, равный одной или нескольким дробям.
Многоуровневое фракционирование
1.Любая учетная запись, содержащая ссылку на объект актива, может использовать ссылку на объект актива в качестве актива для объекта фракционирования и, таким образом, создавать возможность продавать части объекта актива.
2.Любая учетная запись, содержащая ссылку на дробный объект, может использовать ссылку на дробный объект в качестве актива для нового объекта фракционирования и, таким образом, создать возможность для вложенной серии дробей объектов активов.
3.Для такого дробления нет логического ограничения, однако мы можем наложить какое-то произвольное ограничение в случае исчерпания вычислительных ресурсов (скажем, 256 уровней или что-то подобное).
Дробная структура классов
1.Актив фракционирования классов
2.Члены
3.Содержит ссылку на объект актива или ссылку на дробный актив.
4.Общее количество фракций (т.е. долей)
5.Текущее количество оставшихся нереферентных акций (т.е. непроданных акций)
6.Должно быть больше или равно нулю
7.Методы
8.Уменьшить неиспользуемые акции
9.Увеличение неиспользуемых акций
10.Класс Дробный актив
11.Члены
12.Ссылка на объект актива дробления
13.Общее количество фракций (т.е. долей)
14.Должно быть меньше или равно общему количеству дробей в объекте актива фракционирования.
Дробные группы активов
1.Объект актива фракционирования группировки может содержать несколько ссылок на объект актива.
2.Каждый объект актива фракционирования группировки содержит общее количество фракций (т. е. долей) и текущие доступные доли. Это идентично объекту актива фракционирования без группировки.
3.Объект актива фракционирования группировки содержит как ссылки на объект актива, так и ссылки на дробный объект актива. Таким образом, могут возникнуть сложные отношения владения активами.
Группировка дробной структуры классов
1.Группа классов Фракционализация Актив
Члены
а)Список ссылок на объект актива и дробный объект актива. Ссылки
б)Общее количество дробей
в)Текущее количество оставшихся неупомянутых акций (т.е. непроданных акций)
г)Должно быть больше или равно нулю
2.Методы
а)Уменьшить неиспользуемые общие ресурсы.
б)Увеличить нессылочные общие ресурсы.
Дробные денежные потоки
Модель притяжения денежного потока
1.Денежный поток начинается с распределения SagaCoin по объекту актива
1.1.Этот SagaCoin можно извлечь только через ссылку на объект актива или ссылку на объект актива дробления.
2.Распределение денежного потока происходит, когда ссылка на долю активов определяет его распределение.
2.1.Он отправляет сообщение с запросом на распределение денежных потоков в эталонный объект фракционирования активов
2.2.Справочный объект фракционирования активов запрашивает объект актива через ссылку на его объект актива на предмет любых новых распределений
2.3.Затем он распределяет долю, соответствующую объекту ссылки на долю активов.
3.Вложенные денежные потоки возникают естественным образом, когда объект ссылки на актив дробления активов ссылается на объект ссылки на долю активов, который, в свою очередь, ссылается на другой объект ссылки на актив фракционирования активов.
4.Каждое распределение денежных потоков по активу представляет собой отдельный объект
4.1.Запрос на распределение денежных потоков может объединять отдельные денежные потоки или предоставлять их как уникальные потоки.
5.Группирование объектов фракционирования активов запрашивает все содержащиеся в них ссылочные объекты активов для всех распределений и предоставляет дробные денежные потоки.
Класс с несколькими активами и справочник по классам с несколькими активами
Класс MultiAsset
1.Члены
1.1.Вид актива
1.2.Подсчет активов
- Методы
2.1.Увеличение количества активов
2.2.Уменьшить количество активов
Ссылка на класс MultiAsset
3.Члены
3.1.Справочник по объекту MultiAsset
3.2.Подсчет активов
4.Методы
4.1.Увеличение количества активов
4.2.Уменьшить количество активов
Источник передачи нескольких активов: явный покупатель и продавец
1.Аккаунт создателя создает объект с несколькими активами. Этот объект актива может относиться к виртуальному или физическому активу. Инициализируется количество нескольких активов.
2.Учетная запись продавца активов создает объект котировки с адресом учетной записи покупателя. Число объектов с несколькими активами уменьшается, а ссылка на объект котировки увеличивается на сумму актива, выставленного на продажу. (Покупателю предоставляется внешняя ссылка на объект котировки)
3.Учетная запись покупателя активов создает объект заказа на покупку со ссылкой на объект котировки. (Продавец предоставляет ссылку на объект заказа на покупку извне)
4.Учетная запись продавца активов принимает заказ на покупку, передавая его объекту Quote.
4.1.Объект Quote отправляет объекту PO ссылку на объект с несколькими активами и счетчик
4.2.и получает сообщение с суммой SagaCoin от объекта PO.
5.Объект Quote увеличивает счет SagaCoin и удаляет себя.
6.Объект PO сохраняет ссылку и счетчик объекта актива и удаляется.
Вторичные переводы нескольких активов: явный покупатель и продавец
1.Учетная запись продавца активов создает объект котировки с адресом учетной записи покупателя. Уменьшает количество объектов ссылки на несколько активов, а ссылка на объект котировки увеличивается на количество актива, выставленного на продажу. (Покупателю предоставляется ссылка на объект котировки извне)
2.Учетная запись покупателя активов создает объект заказа на покупку со ссылкой на объект котировки. (Продавец предоставляет ссылку на объект заказа на покупку извне)
3.Учетная запись продавца активов принимает заказ на покупку, передавая заказ на объект котировки
3.1. Объект Quote отправляет объекту PO ссылку на объект мультиактива и счетчик
3.2. и получает сообщение с суммой SagaCoin от объекта PO.
4.Объект Quote увеличивает счет SagaCoin и удаляет себя.
5.Объект PO сохраняет ссылку и счетчик объекта актива и удаляется.
Вторичная передача нескольких активов: любой покупатель
1.Учетная запись продавца активов создает объект котировки без ссылки на учетную запись покупателя. Уменьшает количество объектов ссылки на несколько активов и увеличивает ссылку на объект котировки, увеличивая ее на количество актива, выставленного на продажу. (Ссылка на объект цитаты указана каким-то внешним способом)
2.Учетная запись покупателя активов создает объект заказа на покупку со ссылкой на объект котировки. (Продавец предоставляет ссылку на объект заказа на покупку извне)
3.Учетная запись продавца активов принимает заказ на покупку, передавая заказ на объект котировки
3.1. Акцепт связывает конкретного покупателя с продавцом для этого обмена котировками/заказами.
3.2. Объект Quote отправляет объекту PO ссылку и количество объектов с несколькими активами.
3.3. и получает сообщение с суммой SagaCoin от объекта PO.
4.Объект Quote увеличивает счет SagaCoin и удаляет себя.
5.Объект PO сохраняет ссылку и счетчик объекта актива и удаляет себя.
Источник перевода - https://prasaga-ceo.medium.com/programmable-smart-assets-real-world-assets-rwa-digitized-future-a52340a9697d
PraSaga official Linktree: https://linktr.ee/prasaga
