Разработка смарт контрактов по правилам, которые ваша команда может проверить

С чего начать разработку смарт контракта?

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

1. Назовите действие пользователя. Опишите, что нужно сделать, например, получить аллокацию или внести актив.
2. Установите условия. Запишите, когда действие разрешено и что должно произойти, если оно не разрешено.
3. Перечислите роли. Определите, кто может использовать каждую функцию и кто, если вообще кто-то, может управлять настройками.
4. Отметьте зависимости. Укажите связанные контракты, активы, сервисы или работы по интерфейсу.
5. Проверьте поведение. Согласуйте тестовые сценарии, отражающие обычное использование и ограниченные действия.

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

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

Держите контракт близко к тому, как работает ваше сообщество

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

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

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

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

Передача, которой ваша команда может следовать

Вы получаете код и рабочие заметки, необходимые для понимания согласованного поведения контракта. Мы подтверждаем содержимое с вами до разработки, чтобы передача соответствовала продукту, а не следовала общему чек-листу. Для более широких потребностей продукта см. разработка Web3.

Контракт на вестинг может потребовать четкого описания условий аллокации и получения. Стейкинг-контракт может потребовать записи поведения депозита, вывода и вознаграждения. Мы формируем письменные материалы вокруг функций, которые вы одобряете, чтобы рецензенты могли сравнить заявленные правила с тестами и кодом. Это также может помочь вашей команде спланировать работу над интерфейсом с разработкой dApp.

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

Что происходит между первым ревью и выпуском?

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

Мы начинаем с анализа цели продукта, сети, пользователей и связанных систем. Чек-лист на старте помогает нам собрать правила контракта, выявить открытые варианты и подтвердить, кто их одобрит. После того как вы одобрите письменное поведение, мы реализуем согласованные функции и делимся прогрессом с вашим техническим контактом.

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

Сеть и дизайн контракта определяют, какие средства контроля выпуска доступны. Тесты покрывают только те случаи, которые они описывают. Независимый аудит ограничен согласованным ревью. После развертывания возможность изменения кода зависит от дизайна и сети.

Планируйте связанную Web3 работу вокруг границ контракта

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

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

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

• Описание вашего продукта и действия пользователей, которые должен поддерживать контракт.
• Целевая сеть, если выбрана, плюс существующий код или технические заметки.
• Ваши текущие правила вестинга, стейкинга или токенов, включая неотвеченные вопросы.

Отправьте эти материалы на Brand Community. Мы рассмотрим их с вами, определим решения, которые нужно принять, и подготовим четкий план для разработки контракта.

Как мы работаем

1. Определите границы контрактаМы анализируем цель продукта, пользователей, целевую сеть и связанные части. Вы определяете решения, требующие ответа ответственного за продукт.
2. Согласуйте письменное поведениеМы записываем функции, роли, условия и тестовые сценарии. Ваша команда проверяет описание до начала реализации.
3. Создайте и протестируйте функцииМы реализуем согласованное поведение и готовим тесты для ожидаемых и ограниченных действий. Мы делимся прогрессом и открытыми вопросами с вашим техническим контактом.
4. Координируйте независимое ревьюКогда включена координация аудита, мы готовим материалы для ревью и организуем ответы на находки. Мы вносим согласованные изменения и перезапускаем связанные тесты.
5. Подготовьте выпуск и передачуМы предоставляем согласованный код, заметки по тестам и материалы для развертывания. Ваша команда подтверждает ответственность за выпуск и проверяет детали развертывания.