Разработка смарт-контрактов: от правил до запуска

Какие решения по контракту должны быть в первом документе об объеме?

Первый артефакт — это документ об объеме, а не оценка кода. Он связывает каждое действие продукта с участником, правом и ожидаемым результатом в блокчейне. Мы используем 6 полей: участник, действие, право, изменение состояния, ответ на ошибку и событие. Эти поля делают пропущенные решения видимыми до начала реализации.

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

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

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

Для функций токенов согласуйте объем контракта с созданием и развертыванием токена. Более широкий объем Web3-разработки может включать связанные компоненты продукта.

Как спецификация становится тестируемым поведением контракта?

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

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

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

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

Что должны указывать правила вестинга и стейкинга?

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

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

Используйте это сравнение для подготовки обсуждения продукта:

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

Какие материалы передаются вместе с кодом контракта?

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

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

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

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

Как отслеживается разработка от получения заявки до передачи?

Проектный документ отслеживает решения на 5 этапах: получение заявки, спецификация, реализация, тестирование и передача. Каждый этап имеет артефакт, который ваша команда может проверить. График согласовывается после того, как мы понимаем границы контракта, интеграции, потребности в одобрении и зависимости от внешней проверки.

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

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

Контракт, связанный с веб-сайтом или лендингом, может потребовать параллельного планирования. См. разработка Web3-сайтов и лендингов для интерфейсной работы. Для более широкого технического объема ознакомьтесь с Web3-разработкой.

Что показывает документ о релизе относительно рисков, связанных с сетью?

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

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

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

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

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

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