Proof of concept with Ethereum. Solidity workshop. Alex Shkor

Проектирование децентрализованных приложений - детально изложенная тема данной лекции.

Для введения, разберем понятие «Блокчейн» с точки зрения проектирования:

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

При проектировании Блокчейн первый этап - выбор инфраструктуры сети:

Это может быть:

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

Следующий важный момент - масштабируемость сети:

Имеет смысл заранее проанализировать потенциальный рост приложения и предусмотреть:

• Количество транзакций
• Оплату за проведения транзакций
• Размер Блокчейн
• Сжатие контента
• Компактной реализации сообщений между нодами, чтобы им хватило пропускной способности сети
• Масштабируемости Governance протокола или домена - управление параметрами протокола
• Количество пользователей

Для каких целей необходим прототип Блокчейн

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

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

• Доменные контракты транслируются в типы транзакций
• Мембершип заменяется публичными ключами
• Хранилище контрактов трансформируются в локальную базу данных
• Появляется возможность автоматической эмиссии токенов

При проектировании Блокчейн можно выделить две основные категории:

Проектирование инфраструктуры

В дизайн инфраструктуры входят:

• Дизайн протокола домена
  

  

  Для Ethereum это: базовые смарт-контракты для домена и базовое хранилище
  Для нативного Блокчейн: типы транзакций, процессинг и валидация транзакций, база данных

  • Дизайн инфраструктуры поддержки консенсуса

  Выбор алгоритма консенсуса: Proof of work, Proof of Stake, Delegated Proof of Stake и т.д.

  • Параметризация алгоритма

  Возможность изменять параметры алгоритма:
  

  

  • Инфраструктура вне Блокчейн

  Взаимодействие с данными, хранимыми в базах вне системы

  • Интеграция с другими смарт-контрактами
  • Инфраструктура для Oracle

  Важно продумать стимулы для Oracle давать валидную информацию

  • Ноды, которые предоставляют возможность пользователям не разворачивать свои
  • Юзеринтерфейс 

  Создание удобного интерфейса для пользователей

  Дизайн домена

  

  Для дизайна домена необходимо продумать следующие пункты:

  • Бизнес логика смарт-контрактов
  • Логика взаимодействия с базами данных
  • Управление и изменение доменной логики
  • Система идентификации
  • Логика обновления смарт-контрактов
  • Дизайн токена
    Токены могут быть разделены по целям и по свойствам:
    

    

    По целям:

    • Токен нативной платформы
    • Токен, который используется в бизнес-процессе
    • Токен, который подкреплен реальным токеном
    • Ютилити для получения доходов
    • Токен, отображающий традиционные активы

    По свойствам:

    • Ликвидность и неликвидность, то есть возможность или невозможность передать токен
    • Токены, эмиссия которых еще возможна и невозможна

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