Коллекции, события и глобальные переменные

Пора научить контракт помнить вкладчиков, сообщать новости внешнему миру и понимать, кто к нему пришёл и с какими деньгами. Это сердце учёта нашей кампании.

• mapping и динамические массивы - как хранить «кто сколько внёс»;
• события (events) - как сообщать об изменениях интерфейсу и индексаторам;
• msg.sender, msg.value, block.timestamp и другие глобальные значения.

// адрес → сумма вклада в вей
mapping(address => uint256) public contributions;

function contribute() external payable {
    contributions[msg.sender] += msg.value;  // накапливаем вклад
}

- Как это «нельзя перебрать»? А если я хочу показать всех вкладчиков?

- Тогда придётся завести рядом обычный список адресов (об этом следующий урок). Mapping похож на гардероб с номерками: по номерку куртку выдадут мгновенно, а вот на вопрос «какие куртки у вас вообще висят?» гардеробщик только разведёт руками.

Mapping бывает вложенным: mapping(address => mapping(address => uint256)) - «кто → кому → сколько». Так, например, в токенах ERC-20 хранят разрешения (продвинутый курс).

Для краудфандинга хватит простого одноуровневого.

address[] public contributors;   // список уникальных вкладчиков
function contribute() external payable {
    if (contributions[msg.sender] == 0) {
        contributors.push(msg.sender);   // первый вклад - добавим в список
    }
    contributions[msg.sender] += msg.value;
}

Перебор массива в цикле стоит газа пропорционально его длине. Пока вкладчиков десять, всё прекрасно. Когда их станет несколько тысяч, функция с циклом может перестать помещаться в лимит газа - и застрять навсегда, вместе с деньгами. Это целый класс уязвимостей (отказ в обслуживании), его мы разберём в курсе по аудиту. Правило наперёд: избегайте неограниченных циклов по данным, которые наполняют посторонние.

Если контракт A вызывает контракт B, то внутри B msg.sender - это A, а tx.origin - исходный пользователь. Проверять права по tx.origin - всё равно что пускать в квартиру любого, кто правильно назвал имя хозяина. Пользователя можно обманом заставить вызвать вредоносный контракт, и тот от его имени дёрнет ваш. Это известная уязвимость, разберём её в аудите. Правило простое: для прав всегда берите msg.sender.

Раз все узлы должны получить один результат, источника случайных чисел внутри контракта быть не может. block.timestamp, хеш блока и подобное - псевдослучайность, которую можно предсказать или подтолкнуть. Для честного случая используют внешние оракулы (например, Chainlink VRF). Пока просто запомните: не делайте жребий на блок-данных.

event Contributed(address indexed who, uint256 amount, uint256 total);
event Refunded(address indexed who, uint256 amount);

function contribute() external payable {
    require(block.timestamp < deadline, "campaign ended");
    require(msg.value >= MIN_CONTRIBUTION, "too small");

    if (contributions[msg.sender] == 0) contributors.push(msg.sender);
    contributions[msg.sender] += msg.value;

    emit Contributed(msg.sender, msg.value, address(this).balance);
}

Mapping хранит «адрес → сумма» и служит главным учётом; массив рядом нужен, когда требуется перечень (но берегитесь циклов). Права проверяем по msg.sender, приём денег - через msg.value, дедлайн - через block.timestamp; случайности в EVM нет. Обо всех изменениях контракт сообщает событиями. Наш краудфандинг теперь принимает вклады, ведёт учёт и логирует историю - остаётся самое ответственное: деньги на выход.

В следующем модуле контракт начнёт отдавать эфир. Там же разберём, как две строки, поставленные в неправильном порядке, стоили The DAO около 60 миллионов долларов.