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

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

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

1. Двухэтапный рабочий процесс

Обычно у нас есть два фактических этапа разработки смарт-контрактов NEO: Кодирование и Тестирование. Это официальное руководство предоставляет более подробную информацию об этом рабочем процессе.

На этапе кодирования NEO официально поддерживает C # (примеры ЗДЕСЬ). Также мы можем разработать смарт-контракт с Java и Python. Поскольку мы можем легко найти страницы руководств и примеров кода, чтобы рассказать, как кодировать смарт-контракты NEO в Google и Youtube, я бы пропустил эту часть в этом руководстве.

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

Общедоступные тестовые сети

Наиболее распространенный подход - использовать общедоступные тестовые сети. NEO Smart Economy, CoZ и NEL поддерживают три основных общедоступных тестовых сети соответственно. Учебник Алекса Губы подробно описывает, как синхронизировать блоки и запрашивать GAS перед тестированием в тестовых сетях NEO и CoZ, в то время как Тестовая сеть NEL более удобна для китайских разработчиков благодаря поддержке локализации.

Во многих случаях вы можете запускать RPC-вызовы через NEO API (Полная справка) для взаимодействия с блокчейном. Некоторые API доступны только при наличии работающего узла NEO-CLI с открытым кошельком. Однако, если тестовая сеть оснащена Neo-Scan, вы можете вместо этого вызывать аналогичные службы, не запуская такой узел. Например, API getBalance требует наличия работающего узла, но вы можете использовать get_balance Neo-Scan для аналогичной функциональности. Я создал коллекцию почтальонов, чтобы помочь протестировать эти удаленные процедуры. Просто измените значения доменов тестовой сети (или Neo-Scan), чтобы поиграть с ней.

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

Частные тестовые сети

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

Официальный сайт NEO предоставляет пошаговое руководство по настройке частной сети на облачных сервисах. Но после проверки счета в Azure я бы не рекомендовал его, если вам не нужно делиться данными цепочки с другими людьми. Neo-privatenet-docker отлично подходит для создания частной тестовой сети на вашем локальном компьютере, экономя при этом ваше время из-за тонны настройки и инструкций. Если вы запускаете его на ноутбуке, ну ... также полезно поддерживать температуру тела зимой.

Ограничение двухэтапного рабочего процесса

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

byte[] ba0 = CallSomeFunction();
byte[] ba1 = CallAnotherFunction();
//Print out the value of ba0 and ba1 to ApplicationhLog
Runtime.Notify(ba0, ba1);

Даже на удачном пути нам все равно нужно перекомпилировать проект с помощью neon, затем обеспечить достаточное количество GAS для повторного развертывания, затем составить правильные параметры с правильным форматом, затем вызвать контракт и подождать 20–30 секунд для генерации следующий блок, затем вызовите API getapplicationlog для получения журнала в формате JSON, затем распечатайте ответ в удобном формате, чтобы найти зарегистрированные значения (проверьте полужирным шрифтом часть в следующем примере отклик). Поскольку обычно регистрируемые значения выражаются в байтовых массивах, нам также необходимо преобразовать их обратно в Strings или BigIntegers. Что ж, всего 7 шагов.

[
  {
    "jsonrpc": "2.0",
    "id": 5,
    "result": {
      "txid": "0x7e3f08a8af4290693184b413ba1d58bede8462cb565baba8ffcc380bf947e317",
      "executions": [
        {
          "trigger": "Application",
          "contract": "0x32682404d4313ecf80b70e1323ccf908a80fdfc0",
          "vmstate": "HALT, BREAK",
          "gas_consumed": "0.039",
          "stack": [],
          "notifications": [
            {
              "contract": "0xaeccdcf6d7ecf827e7e6baec3c233eca08c27ee3",
              "state": {
                "type": "Array",
                "value": [
                  {
                    "type": "ByteArray",
                    "value": "010203"
                  },
                  {
                    "type": "ByteArray",
                    "value": "04090d"
                  }
                ]
              }
            }
          ]
        }
      ]
    }
  }
]

В официальном документе есть глава Модульное тестирование, но приведенные там примеры по-прежнему требуют предварительной компиляции и / или развертывания .avm.

Моя команда norchain.io сильно ощутила это ограничение, когда мы разрабатывали блокчейн-игру CarryBattle на основе NEO. С помощью сообщества мы начали опробовать четырехэтапный рабочий процесс, что значительно повысило эффективность разработки.

2. Четырехэтапный рабочий процесс

Этот рабочий процесс состоит из четырех этапов: Редактирование, Отладка, Частное тестирование и Бета-тестирование. Основные идеи:

  1. Использование некоторых новых инструментов для разделения этапа Кодирования на Редактирование и Отладку. На этапе отладки мы переходим или запускаем локальные тестовые примеры, как обычные программные проекты, насколько это возможно, без взаимодействия с блокчейном.
  2. Разделите этап тестирования на частное тестирование и бета-тестирование, используя privateNet / NeoCompiler Eco для частного тестирования и общедоступные testNets для бета-тестирования соответственно. При таком подходе мы можем наилучшим образом обеспечить гибкость и совместимость с минимальными усилиями.

Для фаз редактирования и отладки я рекомендую два подхода: Neo-Debugger и Neunity.

Нео-отладчик

Проект Neo-Debugger разработан компанией Relfos. С помощью специальной версии Neon и файла отладки json вы можете написать тестовые примеры уровня вызова и пошагово запускать исходный код в среде IDE, отслеживая использование GAS и журналы приложений без взаимодействия с блокчейном. Еще одна приятная особенность Neo-Debugger заключается в том, что он может переходить через OpCode при проверке стека. У Николая-К есть видеоурок по Neo-Debugger.

Fabio также сделал хороший проект SCTracker с похожей идеей, но он решил пропустить, когда узнал о существовании Neo-Debugger. Но все же спасибо ему за вклад.

Neunity.Adapter

Neo-Debugger отлично справился с отладкой на уровне NeoVM, однако он все еще имеет некоторые ограничения. Например, он еще не поддерживает мониторинг переменных, точки останова или тестовые примеры на уровне функций.

Адаптерный слой фреймворка Neunity, созданный Norchain.io, использует другой способ локальной отладки. Идея Neunity.Adapter:

  1. Создайте уровень адаптера, чтобы изолировать различия между NeoVM и обычными проектами .Net. У нас есть два адаптера Neunity.Adapter.NEO и Neunity.Adapter.Unity с одинаковым набором сигнатур функций, но с разными пространствами имен и реализациями. Они используются для смарт-контрактов NEO и проектов Unity (на самом деле также применимы для многих других проектов .Net) соответственно. Большинство этих функций связано с преобразованием типов, операторами или эмуляциями системных вызовов.
  2. Затем мы можем написать логику приложения над уровнем адаптера. Очевидно, что, просто изменив пространство имен, эту логику приложения можно будет использовать либо в смарт-контракте, либо в обычных проектах .Net.
  3. Теперь мы можем использовать разработку, управляемую тестированием (TDD) на функциональном уровне, и даже поделиться логикой с клиентом C # Dapp.

У меня есть Видеоурок, чтобы продемонстрировать, как использовать Neunity.Adapter для выполнения TDD функционального уровня, выполнения пошаговых тестов с переменными мониторами и стеками вызовов.

По сравнению с таблицей ниже мы видим преимущества Neo-Debugger и Neunity.Adapter соответственно. По нашему опыту, Neo-Debugger больше подходит для проектов меньшего масштаба, поскольку он потребляет нулевые накладные расходы GAS, в то время как Neunity.Adapter больше подходит для более масштабных или более сложных проектов, поскольку он лучше поддерживает TDD, несколько классов, точки останова, отслеживание переменных и т. Д. .

При разработке Neunity используются методологии крупномасштабных программных проектов (я имею в виду масштаб системной логики. Это не означает, что единичный вызов должен быть сложным или дорогостоящим). Вот почему заполнение разрыва между разработчиками .Net и разработчиками NEO с помощью уровня адаптера - важный первый шаг. Между тем, Neunity также предоставляет уровень Neunity.Tools с гибкой сериализацией (NuSD), HTTP-подобным протоколом связи (NuTP), URI-подобным управлением хранилищем (NuIO) и т. Д. Мы надеемся, что усилия чтобы помочь большему количеству блокчейн-приложений NEO, стали практичными для приземления.

Частное тестирование

После завершения логики, повторяя этапы кодирования и отладки, мы можем перейти к частной фазе тестирования и начать взаимодействие с блокчейном. Мы предлагаем использовать частную testNet или NeoCompiler Eco для частного тестирования, поскольку их среда проста и удобна для взаимодействия и управления.

Публичная тестовая сеть NeoCompiler Eco, разработанная NeoResearch, является новой и особенной. Он не требует применения GAS, но предоставляет целый спектр инструментов графического интерфейса на основе веб, включая компиляцию, импорт кода операции, развертывание, вызовы, транзакции, преобразование и т. Д. NeoResearch также недавно интегрировал gitter.im для мгновенного общения в чате, чтобы лучше общаться с разработчиками. . У Игоря есть хороший учебник, чтобы изучить его основные функции.

Еще одна приятная вещь в этой testNet - то, что блоки генерируются каждые 5–7 секунд, что почти в 5 раз быстрее, чем обычно. Это сокращает время ожидания, и вы почти не можете столкнуться с вызовами других разработчиков в том же блоке, что делает тест почти таким же простым, как частные тестовые сети. Поэтому мы предлагаем рассмотреть его как вариант частного тестирования.

Бета-тестирование

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

Резюме

NEO имеет много преимуществ по сравнению со многими другими публичными блокчейн-проектами: например, высокая скорость транзакций, относительно дружественные языки разработки (C #, Python), международная и активная атмосфера сообщества.

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

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

Получайте лучшие предложения по программному обеспечению прямо в свой почтовый ящик