Вскрытие показало, что у вас спагетти код

4 years ago

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

1. License, version, imports

Сначала указывается тип лицензии. Это стало строгим требованием совсем недавно. Предположительно на версии Solidity 0.7.6 (на данный момент последняя 0.8.4). Конечно я задал вопрос главному архитектору - в чем же важность этого пункта? На что он ответил якобы это элементарное требование, которым нельзя пренебречь. Вот так. Следом мы указываем версию языка, которую хотим использовать. Это важно, так как контракты с версии 0.4.0 будут точно отличатся от контрактов версии 0.8.4. Можете сравнить, или поверить мне на слово (лучше сравнить, конечно). Далее импортим библиотеки и наследуемые контракты.

2. Storage

После ключевого слово contract и прописанных наследников мы попадаем в пространство контракта. Далее идет storage, или же хранилище на языке смертных. Это переменные, массивы, мэппинги, структуры, обьекты, перечисления которые будет хранится в памяти. Запись в хранилище стоит копеечку. Старайся по минимуму взаимодействовать со стораджем. Выставляем идентификаторы доступа по порядку. Public->external->internal->private. Если попросишь, то я углубленно расскажу про уровни доступа в следующий раз.

3. Events

Ивенты выполняют примитивную роль. Эта штука нужна для бэкэнда сервиса в основном, что б после срабатывания какого либо метода он триггерил нужный тебе ивент с указанными тобой значениями. К примеру Transferred(address from, address to, uint amount). Значения из ивента можно будет перехватить извне и использовать на свое усмотрение.

4. Modifiers

Модификаторы используются как ограничители. Зачем они? К примеру у тебя есть 5 функций доступные только владельцу контракта. Вместо того что б перед выполнением каждой раз проверять, является ли адрес отправителя адресом владельца, можно просто сделать модификатор onlyOwner и подвязать его к нужным функциям. Реализация такого модификатора уже есть в OpenZeppelin::Ownable. Кстати, Vyper, в отличии от Solidity, отказался от модификаторов, объясняя это тем что лишние переборы по коду не позволительны и контракт должен читаться сверху вниз.

5. Constructor

Далее следует конструктор. Или initializer, если ты уже знаешь что такое proxy контракт. Ладно, не грузись, я просто хочу казаться умным. Конструктор играет роль... конструктора. Он срабатывает лишь один раз при загрузке контракта в мэйннэт и инициализирует нужный тебе сторадж.

6. Functions

Очень грубо говоря, при помощи методов юзернейм, или другие контракты будет взаимодействовать с нашим контрактом. Распологаем функции так. Public-> external-> public view-> external view-> public pure-> external pure-> internal-> private-> internal view-> private view-> internal pure-> private pure.

Вот так выглядит общая структура контракта. Пример был показан на Solidity и не факт что он подойдет для других языков, но на порядок отличаемой от этой структуры схемы проектирования ты вряд ли найдешь. Я бы хотел задать тебе вопрос, юзернейм. Нравится ли тебе способ изложения? Что бы ты хотел видеть в постах? О чем тебе интересно было бы услышать в следующий раз? Твое мнение для меня крайне важно. Свидимся).

164

7 comments