Вы здесь

Как переводить активы в блокчейне

Токенизация активов – модное слово сегодня! Но что стоит за всей этой шумихой? Может ли основная идея быть сформулирована независимо от конкретного блокчейна или даже конкретной концепции или документа?

Как переводить активы в блокчейне

Идея

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

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

А все потому, что любой блокчейн, и на момент написания статьи тоже, может рассматриваться лишь как распределенный публичный реестр, и никак иначе!

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

У нас пять действующих лиц:

  1. Продавец – может идентифицировать по смарт-контракту
  2. Покупатель (один или несколько) – может идентифицировать по смарт-контракту
  3. Смарт-контракт на активы (регистрирует продавцов, покупателей, торговую платформу, запускает продажу, регистрирует менеджера паролей)
  4. Менеджер паролей: (поддерживает доступ, может идентифицировать по смарт-контракту)
  5. Торговая платформа: (может идентифицировать по смарт-контракту, запускает продажу)

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

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

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

В итоге мы получим следующую схему работы, представляющую вариант использования активов:

  1. Продавец регистрируется в смарт-контракте (блокчейн-адрес Продавца и для любого потенциального покупателя: хэш документа продажи).
  2. Покупатели, менеджер паролей и торговая платформа регистрируются в смарт-контракте.
  3. Продажа: торговая платформа «жмет на рычаг» внутри смарт-контракта, подтверждая продажу
  4. Менеджер паролей в действии (извлекает информацию о статусе передачи актива из смарт-контракта. Может проверить любое действующее лицо в любое время по его или ее блокчейн-адресам, зарегистрированным в смарт-контракте. Так как для каждого покупателя индивидуальный документ наследования регистрируется в смарт-контракте по его хэш-коду, менеджер паролей отправит покупателю зашифрованный документ, содержащий информацию о наследовании (может включать пароли или любые другие конфиденциальные данные ).

Реализация

Каждое действующее лицо …

  1. Продавец
  2. Покупатель
  3. Смарт-контракт
  4. Менеджер паролей
  5. Торговая платформа

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

Смарт-контракт
Единственный компонент блокчейна. Каждый другой компонент зависит от него (нет других зависимостей между компонентами в этом проекте).

Продавец
Продавец просто свидетельствует о своем желании продать актив защищенным от вмешательства способом.

Менеджер паролей
Это должен быть внешний компонент, подключенный к интерфейсу блокчейна.

Торговая платформа
Можно подключить любую существующую торговую платформу.

Покупатель
Покупатели должны быть зарегистрированы и идентифицированы. Один документ должен сопоставляться с одним конкретным покупателем (Хэширование).

Будет еще один программный компонент, не показанный на схеме: интерфейс к смарт-контракту. Будет несложно спроектировать этот интерфейс, если принять во внимание некоторые важные предпосылки. Интерфейс …

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

Безопасность

Уровень безопасности для этого применения будет в основном определяться безопасностью внутри блокчейна и смарт-контракта, а также уровнем безопасности менеджера паролей.

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

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

Категория: 
Tutorial
Технология: 
1
Ваша оценка: Нет Средняя: 1 (1 оценка)
2437 / 0
Аватар пользователя Daritas
Публикацию добавил: Daritas
Дата публикации: ср, 04/03/2019 - 13:10

Что еще почитать:

Добавить комментарий