Разработка смарт-контрактов для Web3-проектов

Что включает разработка смарт-контрактов?

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

• Собственные контракты: перевод действий пользователей, разрешений и изменений состояния в документированный объем.
• Вестинг: определение того, кто получает распределения, когда они становятся доступными и какие действия разрешены.
• Стейкинг: документирование процесса участия и правил, которые контракт должен обеспечивать.
• Координация аудита: подготовка реализации и вспомогательных материалов для внешней проверки.

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

AEOTech фиксирует согласованные поведения и исключения в Launch Spec. Это дает вашим заинтересованным сторонам по продукту и разработке общий справочный документ до написания кода.

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

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

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

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

Что вы получаете по итогам проекта смарт-контракта?

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

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

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

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

Как проект смарт-контракта проходит путь от брифа до передачи?

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

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

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

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

Какие риски смарт-контрактов требуют четких границ?

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

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

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

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

Цены

Стартовые цены в долларах США. Индивидуальные пакеты и скидки за объём — по запросу. Оплата в USDT, USDC, BTC, ETH, SOL, TON или токеном проекта.

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

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