Контекст
Блокчейн — это распределённый реестр, в котором данные хранятся в последовательных блоках, связанных криптографическими хэшами. Каждый блок содержит заголовок с хэшем предыдущего блока, Merkle-корнем транзакций, timestamp и nonce. Для QA это означает, что изменение любой транзакции в блоке изменит хэш всей цепочки — это фундаментальный инвариант для проверки целостности данных.
- Блок состоит из заголовка (header) и тела (body со списком транзакций)
- Хэш блока зависит от содержимого: изменение одного байта меняет весь хэш
- Консенсус (PoW, PoS) — механизм согласования, кто имеет право добавить следующий блок
- Finality означает, что блок признан необратимым после N подтверждений
- Форк — временное расхождение цепочек, критически важное для тестирования edge-cases
Рабочий алгоритм
Чтобы эффективно тестировать блокчейн-продукт, QA должен уметь проверять данные через публичные и приватные источники и понимать жизненный цикл блока.
- Шаг 1: откройте block explorer (Etherscan, Blockchair) и найдите последний блок сети
- Шаг 2: проверьте структуру блока — block number, hash, parent hash, timestamp, количество транзакций
- Шаг 3: убедитесь, что parent hash текущего блока совпадает с hash предыдущего блока
- Шаг 4: выберите произвольную транзакцию и проверьте её включение через Merkle proof
- Шаг 5: проверьте количество confirmations для транзакции — сравните с порогом finality продукта
- Шаг 6: запишите наблюдаемый block time и сравните с документированными параметрами сети
Пример из практики
На проекте криптовалютной биржи QA-инженер обнаружил, что депозиты зачислялись после 1 подтверждения вместо задокументированных 6 для Bitcoin. Это создавало риск double-spend атаки.
- Тест-кейс: отправить транзакцию и зафиксировать статус депозита при 1, 3 и 6 подтверждениях
- Баг: депозит отображался как завершённый при 1 confirmation вместо 6
- Риск: злоумышленник мог инициировать double-spend до достижения финальности
- Фикс: команда обновила пороговое значение confirmations в конфигурации сервиса зачисления
Частые ошибки
Начинающие QA в блокчейн-проектах совершают типичные ошибки, которые приводят к пропуску критических дефектов.
- Считать, что транзакция финальна сразу после появления в mempool — она ещё не включена в блок
- Путать block time с transaction confirmation time — это разные метрики
- Игнорировать тестирование поведения системы при форках и реорганизациях цепи
- Не проверять соответствие данных в block explorer и данных в БД продукта
- Пренебрегать тестированием граничных значений: транзакции в первом и последнем блоке сессии