Деньги: приём, вывод и возврат

Самая ответственная часть контракта - та, где двигаются деньги. Разберём, как принимать эфир, как безопасно его отправлять и почему порядок двух строк здесь важнее всего остального кода.

• функции receive и fallback - как контракт получает «просто перевод»;
• три способа отправить эфир: transfer, send, call - и почему сегодня выбирают call;
• паттерн «вывод по запросу» (pull) и правило «проверки - эффекты - взаимодействие».

// позволяет вносить вклад обычным переводом на адрес контракта
receive() external payable {
    contribute();
}

Если у контракта нет ни одной payable-функции и нет receive, любой обычный перевод эфира на него откатится. Это защита: деньги не застрянут случайно. Но она же означает, что приём средств надо предусмотреть осознанно. Оговорка: эфир всё же можно зачислить принудительно, через selfdestruct другого контракта, и тогда никакой ваш код не выполнится. Поэтому не стройте логику на address(this).balance, а ведите собственный счётчик собранного. В нашем краудфандинге это будет переменная totalRaised.

// рекомендуемый способ перевода эфира сегодня
(bool ok, ) = recipient.call{value: amount}("");
require(ok, "transfer failed");

Лимит в 2300 газа задумывался как защита, но он жёстко привязан к стоимости операций EVM. После изменений в стоимости газа контракты-получатели с чуть более сложной логикой приёма (например, кошельки-контракты) стали не вписываться в 2300 - и переводы к ним начали срываться. Поэтому современная практика - call с явной проверкой результата. Но у call есть своя цена: он передаёт управление получателю, и тут возникает риск повторного входа - об этом урок 5.4. С версии 0.8.31 компилятор прямо помечает transfer и send как устаревшие, а в версии 0.9 их уберут из языка.

- Но рассылать деньги самому удобнее: пользователю не нужно ничего нажимать.

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

function refund() external {
    require(block.timestamp >= deadline, "too early");
    require(totalRaised < goal, "goal reached");  // провал сбора

    uint256 amount = contributions[msg.sender];
    require(amount > 0, "nothing to refund");

    contributions[msg.sender] = 0;            // СНАЧАЛА обнуляем долг
    (bool ok, ) = msg.sender.call{value: amount}("");  // ПОТОМ отправляем
    require(ok, "refund failed");
    emit Refunded(msg.sender, amount);
}

Когда вы шлёте эфир через call, управление на миг переходит к получателю. А если получатель - вредоносный контракт? Прямо в этот момент он снова вызывает ваш refund(). Вклад ещё не обнулён, проверка amount > 0 снова проходит - и он вытягивает деньги ещё раз. И ещё. И ещё, пока контракт не опустеет. Именно так в 2016 году был взломан The DAO на 60 млн долларов.

bool public withdrawn;
function withdraw() external onlyOwner {
    require(block.timestamp >= deadline, "too early");
    require(totalRaised >= goal, "goal not reached");
    require(!withdrawn, "already withdrawn");
    withdrawn = true;                         // эффект до взаимодействия
    uint256 amount = address(this).balance;
    (bool ok, ) = owner.call{value: amount}("");
    require(ok, "withdraw failed");
}

Эфир принимают payable-функции и receive; отправляют сегодня через call с проверкой результата. Деньги раздают по модели pull - каждый забирает своё сам. И главное правило безопасности: Checks-Effects-Interactions - сначала проверки, потом изменение своего состояния, и лишь в самом конце внешний вызов. Теперь у нас есть все части краудфандинга - в следующем модуле собираем их в единый контракт.

Все детали собраны по отдельности. Дальше соединим их в один контракт, пройдём его строка за строкой и развернём в Remix с настоящими кнопками и тестовым эфиром.