Токенизация активов – модное слово сегодня! Но что стоит за всей этой шумихой? Может ли основная идея быть сформулирована независимо от конкретного блокчейна или даже конкретной концепции или документа?
Идея
Я постараюсь сформулировать эту идею в этой статье в несколько упрощенной форме, но я это делаю намеренно, чтобы каждый мог дать свои замечания: я открыт для всевозможных дискуссий. Это будет не что иное, как просто идея, мечта, видение – короче просто желание, если вас интересуют идеи больше, чем деньги.
Основная идея токенизации активов довольно проста: вы можете осуществлять торговые операции в блокчейне. Но необходимо так осуществлять механизм перевода активов, чтобы блокчейн-технологией была реализована только та часть перевода активов, которая связана с делегированием доверия, и больше ничего.
А все потому, что любой блокчейн, и на момент написания статьи тоже, может рассматриваться лишь как распределенный публичный реестр, и никак иначе!
Это означает, что блокчейн не может рассматриваться как база данных или «полноценная» платформа для приложений. Напротив, он должен использоваться только для «заручившейся доверием» части переводимых активов и связанных с ним приложений.
У нас пять действующих лиц:
- Продавец – может идентифицировать по смарт-контракту
- Покупатель (один или несколько) – может идентифицировать по смарт-контракту
- Смарт-контракт на активы (регистрирует продавцов, покупателей, торговую платформу, запускает продажу, регистрирует менеджера паролей)
- Менеджер паролей: (поддерживает доступ, может идентифицировать по смарт-контракту)
- Торговая платформа: (может идентифицировать по смарт-контракту, запускает продажу)
В следующем сценарии мы будем использовать (несколько общую) концепцию инфраструктуры открытых ключей. Поэтому вы уже должны знать, что такое пара криптографических ключей или как-то понимать концепцию асимметричного шифрования и передачи сообщений.
Также важно понимать, что смарт-контракт сам по себе не должен хранить описание актива или любой другой тип обычных данных.
Для идентификации действующего лица в смарт-контракте будет храниться открытый ключ или блокчейн-адрес этого лица.
Для ссылки на какой-либо документ в смарт-контракте будет храниться только его хэш-код, а не сам документ, и даже не место его хранения. В последующем, говоря «Регистрация», мы будем иметь в виду, что блокчейн-адрес действующего лица хранится внутри смарт-контракта, соответствующего роли этого лица.
В итоге мы получим следующую схему работы, представляющую вариант использования активов:
- Продавец регистрируется в смарт-контракте (блокчейн-адрес Продавца и для любого потенциального покупателя: хэш документа продажи).
- Покупатели, менеджер паролей и торговая платформа регистрируются в смарт-контракте.
- Продажа: торговая платформа «жмет на рычаг» внутри смарт-контракта, подтверждая продажу
- Менеджер паролей в действии (извлекает информацию о статусе передачи актива из смарт-контракта. Может проверить любое действующее лицо в любое время по его или ее блокчейн-адресам, зарегистрированным в смарт-контракте. Так как для каждого покупателя индивидуальный документ наследования регистрируется в смарт-контракте по его хэш-коду, менеджер паролей отправит покупателю зашифрованный документ, содержащий информацию о наследовании (может включать пароли или любые другие конфиденциальные данные ).
Реализация
Каждое действующее лицо …
- Продавец
- Покупатель
- Смарт-контракт
- Менеджер паролей
- Торговая платформа
... может рассматриваться как программный модуль, который может быть реализован независимо от других модулей.
Смарт-контракт
Единственный компонент блокчейна. Каждый другой компонент зависит от него (нет других зависимостей между компонентами в этом проекте).
Продавец
Продавец просто свидетельствует о своем желании продать актив защищенным от вмешательства способом.
Менеджер паролей
Это должен быть внешний компонент, подключенный к интерфейсу блокчейна.
Торговая платформа
Можно подключить любую существующую торговую платформу.
Покупатель
Покупатели должны быть зарегистрированы и идентифицированы. Один документ должен сопоставляться с одним конкретным покупателем (Хэширование).
Будет еще один программный компонент, не показанный на схеме: интерфейс к смарт-контракту. Будет несложно спроектировать этот интерфейс, если принять во внимание некоторые важные предпосылки. Интерфейс …
- Должен быть «функциональным» в смысле парадигмы функционального программирования.
- Взаимодействие со смарт-контрактом должно быть асинхронным («управляемым событиями»).
- Нет необходимости в сложных структурах данных или в больших объемах данных, которыми обмениваются смарт-контракт и другие компоненты. Всегда достаточно общаться с помощью базовых типов данных (логических значений, чисел или строк, представляющих блокчейн-адреса или открытые ключи).
- Благодаря этому интерфейс может быть легко разработан и реализован для любого блокчейна.
Безопасность
Уровень безопасности для этого применения будет в основном определяться безопасностью внутри блокчейна и смарт-контракта, а также уровнем безопасности менеджера паролей.
Поскольку очень трудно написать безопасное программное обеспечение, часто приходится прибегать к использованию специализированных инструментов. Это одна из причин, почему менеджер паролей (и торговая платформа) должны быть внешними компонентами.
Смарт-контракт, с другой стороны, может быть только надежной частью программного обеспечения, пока остается очень простым. Согласно этой концепции это было бы именно так.