Типы данных: чем описать кампанию

Solidity - язык строгий: у каждой переменной заранее известен тип, и никаких «ну, там где-то число». Разберём базовые типы и тут же опишем ими цель, дедлайн и создателя нашей кампании.

• целые числа, bool, address, байты и строки - и когда что брать;
• чем constant и immutable отличаются от обычных переменных;
• что такое storage, memory и calldata и почему это не придирка, а вопрос газа.

uint256 goal = 10 ether;   // то же самое, что 10 * 10**18 вей
uint256 tip  = 100 gwei;   // 100 * 10**9 вей

Вспомните механический счётчик пробега: докрутили до 999 999 - и снова нули. С uint256 то же самое: прибавьте 1 к максимуму, и число «провернётся» в 0. Это переполнение. До версии 0.8 оно происходило молча и стоило немало взломанных контрактов. С версии 0.8 компилятор по умолчанию проверяет каждую арифметическую операцию и откатывает транзакцию при переполнении. Мы пишем под 0.8+, так что защита включена сама собой, но помнить о ней всё равно нужно (подробно - в курсе по аудиту).

address owner;                  // кому-то принадлежит кампания
address payable recipient;      // сюда можно будет перечислить сбор

// нулевой адрес - «ничей», часто признак ошибки
address zero = address(0);

address(0) - двадцать нулевых байт, «адрес никого». Неинициализированная переменная-адрес равна именно ему. Перевод токенов на нулевой адрес обычно означает их «сжигание», а деньги, пришедшие «от нулевого адреса», - почти всегда признак бага.

Проверка «а не ноль ли это?» - классический защитный приём.

В EVM нет операций над строками: нельзя узнать длину в символах, сравнить две строки напрямую или дёшево их склеить. Строки там - гости, которых пустили без особой радости. Сравнивают их обычно по хешу: keccak256(bytes(a)) == keccak256(bytes(b)). Поэтому текст в контрактах держат по минимуму, вроде короткого названия кампании, а всё остальное выносят за пределы блокчейна.

- А зачем вообще помечать то, что я и так не собираюсь менять?

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

uint256 public constant MIN_CONTRIBUTION = 0.01 ether; // задано навсегда
address public immutable owner;                        // задаётся при деплое
uint256 public immutable goal;
uint256 public immutable deadline;

Вот и первые настоящие поля нашего контракта. owner, goal и deadline у каждой кампании свои, но после запуска не меняются - значит, это immutable. А минимальный вклад одинаков для всех кампаний и зашит в код - это constant. Заполнять immutable-поля будем в конструкторе из модуля 3.

struct Contributor {
    uint256 amount;      // сколько внёс
    uint256 lastDonation; // время последнего вклада
}

enum State { Active, Succeeded, Failed }
State public state;   // по умолчанию - первое значение, Active

// аргумент только читаем - берём calldata, это дешевле всего
function setName(string calldata newName) external { ... }

// временная копия для вычислений внутри функции - memory
function build() internal {
    Contributor memory c = Contributor(0, block.timestamp);
    ...
}

Если взять из storage структуру в переменную с пометкой memory, вы получите копию, и изменения в блокчейн не попадут. Пометка storage даёт ссылку - правки сохранятся. Перепутать эти два случая - классика жанра: код компилируется, функция отрабатывает без ошибок, вы довольны… а в хранилище всё по-старому.

Деньги в контракте считаются целыми числами вей; дробей нет. Адрес - ключевой тип, а address payable нужен для переводов. Неизменные величины помечают constant и immutable - так дешевле. У сложных типов всегда указывают, где они живут: storage сохраняется, memory временна, calldata - дешёвые входные данные только для чтения. Поля owner, goal, deadline и перечисление State - уже часть нашего краудфандинга.

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