

Ethereum удобнее представлять не как «монету с дополнительными функциями», а как распределённую вычислительную систему. ETH в ней служит нативным активом, gas измеряет объём работы, а смарт-контракты задают правила изменения состояния сети.
Главные выводы
- ETH и Ethereum — не одно и то же. Ethereum — сеть и среда выполнения программ, ETH — её нативный актив.
- Gas не является отдельной монетой. Это единица вычислительной работы; комиссия за использованный gas оплачивается в ETH.
- Смарт-контракт — программа по конкретному адресу. Он выполняет заложенный код, но сам по себе не гарантирует честность, безопасность или экономическую выгоду.
- Кошелёк не «пересылает монеты» напрямую. Он формирует и подписывает инструкцию, после чего узлы сети проверяют её, а валидатор включает транзакцию в блок.
- Результат можно проверять независимо. Блокчейн-эксплорер показывает статус транзакции, адреса, использованный gas, комиссию, вызванный контракт и журналы событий.
Минимальный словарь Ethereum
ETH: нативный актив сети
Ether, или ETH, учитывается непосредственно в состоянии Ethereum. Он используется для перевода стоимости, оплаты сетевых вычислений и обеспечения механизма Proof of Stake. Комиссии за транзакции в основной сети Ethereum номинируются и оплачиваются в ETH. [1]
Это отличает ETH от токенов ERC-20. Баланс обычного токена хранится внутри смарт-контракта, тогда как баланс ETH относится непосредственно к аккаунту Ethereum. Обёрнутый ETH, известный как WETH, уже является токеном и подчиняется логике своего контракта.
Практический смысл: наличие DAI, USDT или другого токена в кошельке не всегда означает, что им можно оплатить gas. Если приложение не использует специальный механизм спонсирования комиссии, для записи изменений в Ethereum понадобится ETH.
Аккаунт, адрес и кошелёк
В Ethereum есть пользовательские аккаунты, контролируемые приватными ключами, и аккаунты смарт-контрактов, контролируемые кодом. Оба типа могут хранить ETH и токены, но обычную транзакцию инициирует пользовательский аккаунт; контракт выполняет действия в ответ на вызов. [2]
Адрес — публичный идентификатор аккаунта. Приватный ключ — средство управления им. Кошелёк представляет собой интерфейс, который хранит или подключает ключи, показывает балансы, готовит данные транзакции и предлагает пользователю поставить цифровую подпись.
Подпись подтверждает разрешение выполнить конкретную операцию. Она не раскрывает приватный ключ, однако подпись вредоносной транзакции всё равно может привести к потере активов. Поэтому проверять нужно не только адрес сайта, но и содержание запроса в кошельке.
Транзакция: подписанная команда
Транзакция — это криптографически подписанная инструкция, способная изменить состояние Ethereum. Простой перевод уменьшает баланс отправителя и увеличивает баланс получателя. Вызов контракта может изменить записи в его хранилище, переместить токены, создать другой контракт или завершиться ошибкой. [3]
У транзакции есть отправитель, получатель, подпись, порядковый номер nonce, параметры gas и, при необходимости, поле данных. Если получатель — обычный аккаунт, операция обычно передаёт ETH. Если это адрес контракта, поле данных указывает, какую функцию и с какими аргументами нужно выполнить.
Смарт-контракт: код плюс состояние
Смарт-контракт — программа и связанные с ней данные, размещённые по определённому адресу. Пользователь вызывает доступную функцию, а Ethereum Virtual Machine, или EVM, исполняет скомпилированный код одинаково на узлах сети. [4]
Контракт не ищет «справедливое» решение и не исправляет замысел разработчика. Он следует коду с учётом текущего состояния и входных данных. Ошибка в логике, опасные права администратора или подмена адреса интерфейсом остаются реальными рисками.
Gas: мера вычислительной работы
Каждая операция EVM имеет стоимость в единицах gas. Простое изменение балансов требует меньше вычислений, чем сложная последовательность вызовов нескольких контрактов. Такая система ограничивает объём работы одной транзакции, затрудняет спам и не позволяет программе бесконечно занимать ресурсы сети. [5]
Итоговая комиссия зависит от количества фактически использованного gas и цены его единицы:
комиссия = использованный gas × эффективная цена gas
Gas limit задаёт максимум вычислительных единиц, доступных операции. Это не обязательно сумма, которая будет израсходована полностью: неиспользованный остаток не списывается как выполненная работа. Но если лимита не хватит, исполнение остановится, изменения контракта откатятся, а ETH за уже выполненные вычисления будет потрачен.
Базовая и приоритетная части комиссии
В современной модели комиссий транзакция задаёт максимальную общую цену единицы gas и максимальную приоритетную надбавку. Протокол устанавливает базовую цену, которая меняется в зависимости от загрузки блоков. Базовая часть сжигается, а приоритетная часть служит вознаграждением за включение операции в блок. [6]
Указанный кошельком максимум — это потолок, а не обещание списать всю сумму. Фактическая цена зависит от базовой комиссии блока, установленной надбавки и заданного ограничения. Если допустимая цена слишком низкая для текущих условий, транзакция может долго оставаться в ожидании.
Карта механизма: от нажатия кнопки до записи в блокчейне
| Действие пользователя | Что делает приложение | Что происходит в сети | Что можно проверить |
|---|---|---|---|
| Пользователь выбирает перевод или функцию контракта. | Интерфейс определяет адрес назначения, сумму или аргументы функции и формирует черновик транзакции. | Изменений в блокчейне пока нет. | Выбранную сеть, адрес получателя или контракта, передаваемую сумму и тип операции. |
| Пользователь запрашивает расчёт комиссии. | Кошелёк моделирует выполнение, оценивает gas limit и предлагает параметры цены gas. | Узлы предоставляют сведения о состоянии сети и возможном результате выполнения. | Оценку комиссии, предупреждения об ошибке симуляции и максимальную сумму списания. |
| Пользователь подтверждает операцию. | Кошелёк подписывает транзакцию приватным ключом и отправляет её через подключённый узел. | Транзакция распространяется по сети и попадает в пул ожидающих операций. | Хеш транзакции, адрес отправителя, nonce и статус ожидания. |
| Транзакция ожидает включения. | Приложение следит за её статусом. | Валидатор выбирает операцию для блока с учётом её действительности и параметров комиссии. | Находится ли транзакция в ожидании, была ли заменена и достаточна ли предложенная комиссия. |
| Валидатор включает транзакцию в блок. | Интерфейс получает квитанцию об исполнении. | EVM выполняет инструкции: переводит ETH либо запускает код контракта и связанные внутренние вызовы. | Номер блока, статус успеха или ошибки, использованный gas, эффективную цену gas и вызванный адрес. |
| Пользователь проверяет результат. | Кошелёк или приложение обновляет баланс и состояние операции. | Узлы принимают новое состояние; последующие блоки повышают уверенность в окончательности результата. | Новые балансы, события контракта, внутренние действия и число подтверждений. |
Хеш транзакции появляется после отправки и служит главным идентификатором проверки. Само наличие хеша ещё не означает успешное выполнение: операция может ожидать включения, завершиться ошибкой либо быть заменена другой транзакцией с тем же nonce. Жизненный цикл и итоговый статус видны в эксплорере. [3]
Чтение и запись: почему не каждое действие требует gas
Интерфейс децентрализованного приложения может просто запросить уже существующие данные: баланс токена, параметры пула или значение переменной контракта. Такой запрос не создаёт транзакцию и не меняет состояние блокчейна, поэтому пользователь не платит сетевую комиссию.
Запись работает иначе. Перевод токена, обмен активов, выдача разрешения на расходование или выпуск NFT изменяют состояние Ethereum. Для этого нужна транзакция, которую сеть должна выполнить и включить в блок. Такое действие расходует gas. [7]
Отсюда простой диагностический признак: если кошелёк просит подпись транзакции с комиссией, приложение намерено изменить состояние сети. Если предлагается только подписать сообщение, сетевой транзакции может не быть — но подпись сообщения также требует проверки, поскольку она способна подтверждать авторизацию или намерение пользователя.
Реалистичный сценарий: обмен токена через смарт-контракт
Пользователь открывает децентрализованное приложение и хочет обменять токен ERC-20 на ETH. Кошелёк подключён к Ethereum, в нём есть обмениваемый токен и ETH для оплаты сетевых операций.
Шаг 1. Интерфейс получает данные
Приложение читает баланс токена, доступные параметры контракта и ожидаемый результат операции. Это запросы к существующему состоянию. Пока пользователь ничего не подписал и не отправил, блокчейн не изменился.
Шаг 2. Контракту может понадобиться разрешение
Контракт обмена не получает автоматического права распоряжаться токенами пользователя. Если разрешения ещё нет, интерфейс предлагает транзакцию approve. Она записывает в контракт токена, сколько активов выбранный адрес вправе расходовать.
Такое разрешение — отдельное изменение состояния, поэтому оно может потребовать отдельной комиссии. Пользователю стоит проверить адрес получателя разрешения и установленный лимит. Неограниченный allowance удобен для повторных операций, но увеличивает последствия компрометации или уязвимости одобренного контракта.
Шаг 3. Пользователь подписывает обмен
Приложение кодирует вызов функции обмена и передаёт его кошельку. Кошелёк показывает сеть, вызываемый контракт, оценку комиссии и, если декодирование поддерживается, предполагаемое действие.
После подписи транзакция отправляется в сеть. Валидатор включает её в блок, EVM запускает код, проверяет условия и выполняет связанные вызовы контрактов.
Шаг 4. Контракт либо завершает всю последовательность, либо откатывает изменения
Если условия функции соблюдены и gas достаточно, состояние обновляется: списывается токен, выполняется логика обмена, а пользователь получает предусмотренный результат. Если проверка контракта не проходит, изменения этой транзакции откатываются. Однако комиссия за фактически проведённые вычисления остаётся списанной. [5]
Шаг 5. Результат проверяется по данным сети
В эксплорере нужно смотреть не только зелёную метку успеха. Полезны адрес вызванного контракта, функция, журналы событий, перемещения токенов, фактическая комиссия и итоговые балансы. Успешный технический статус означает, что EVM выполнила транзакцию без отката, но не доказывает выгодность курса, безопасность приложения или соответствие результата ожиданиям пользователя.
Где эта модель работает, а где нужны уточнения
Описанная цепочка применима к операциям, которые исполняются непосредственно в Ethereum: переводам ETH, развёртыванию контрактов и вызовам функций, меняющим состояние основной сети.
В других EVM-совместимых сетях адреса могут выглядеть так же, а приложения — использовать знакомые кошельки. Но это отдельные блокчейны со своими идентификаторами сети, комиссиями, валидаторами, контрактами и эксплорерами. Совпадение формата адреса не делает активы взаимозаменяемыми между сетями.
На решениях второго уровня логика «подпись — выполнение — проверяемый результат» сохраняется, однако порядок публикации данных, окончательность, способы вывода и структура комиссии могут отличаться. Нельзя автоматически переносить условия основной сети Ethereum на роллап или сайдчейн.
Есть и исключения из правила «для записи пользователю нужен ETH». Некоторые приложения используют смарт-аккаунты, пакетные операции или paymaster, который оплачивает gas за пользователя на заданных условиях. Это функция конкретной инфраструктуры, а не универсальное свойство любого кошелька или контракта. [7]
По одной успешной транзакции нельзя заключить, что контракт безопасен, приложение не будет изменено, разрешение на токены безвредно или следующая операция пройдёт по той же цене gas. Состояние сети, код вызываемых контрактов, параметры операции и условия интерфейса необходимо оценивать заново.
Точки отказа и их наблюдаемые признаки
Выбрана неверная сеть
Признаки: баланс отсутствует, приложение показывает неподдерживаемую сеть, адрес контракта не находится в ожидаемом эксплорере или история операций выглядит пустой.
Что проверить: название и идентификатор сети в кошельке, сеть получения у сервиса или биржи, адрес нужного контракта именно в этой сети. Отправка актива по неподдерживаемой сети может потребовать сложного восстановления или оказаться необратимой.
Ошибочный адрес или подмена контракта
Признаки: адрес в кошельке отличается от выбранного в приложении, контракт создан недавно, его код не верифицирован, название токена совпадает с известным активом, но адрес другой.
Что проверить: адрес посимвольно или с помощью доверенного источника, сеть, данные контракта и смысл вызываемой функции. Название и логотип токена не являются доказательством его подлинности.
Недостаточно ETH для комиссии
Признаки: кошелёк сообщает о недостаточном балансе, кнопка подтверждения недоступна либо транзакция не формируется.
Что проверить: есть ли нативный ETH именно в выбранной сети и хватает ли его на максимально допустимую комиссию вместе с переводимой суммой ETH.
Транзакция долго остаётся в ожидании
Признаки: хеш существует, но номера блока и квитанции об исполнении ещё нет. Более поздние операции того же аккаунта также могут не проходить из-за последовательности nonce.
Что проверить: текущий статус, nonce и предложенную цену gas. Кошелёк может позволить ускорить или отменить ожидающую транзакцию, фактически отправив замену с тем же nonce и более подходящей комиссией.
Исполнение завершилось ошибкой
Признаки: эксплорер показывает неуспешный статус, баланс токена не изменился, но комиссия списана.
Возможные причины: недостаточный gas limit, изменившиеся условия контракта, истёкший срок операции, недостаточное разрешение на токены, нарушение ограничения результата или внутренняя ошибка вызванного контракта.
Точный диагноз зависит от данных транзакции и причины отката. Сам факт ошибки не доказывает мошенничество: контракт мог отклонить операцию именно потому, что встроенная проверка защитила заданное пользователем условие.
Интерфейс показывает один результат, эксплорер — другой
Признаки: приложение зависло на статусе обработки, не обновило баланс или сообщило об ошибке после успешного включения транзакции.
Что проверить: статус по хешу, адреса, журналы событий и балансы в независимом эксплорере. Интерфейс может потерять соединение или не получить ответ, хотя сеть уже завершила выполнение.
Фишинг и опасные разрешения
Признаки: неожиданный запрос на approve, неограниченный лимит, незнакомый spender, требование ввести seed-фразу или приватный ключ, давление с просьбой немедленно подписать операцию.
Что делать: не раскрывать seed-фразу и ключ, отменить непонятный запрос, сверить домен и адрес контракта. После взаимодействия имеет смысл проверить действующие разрешения и отозвать ненужные — само отключение сайта от кошелька allowance не отменяет.
Практический следующий шаг
Если для перевода или взаимодействия с приложением нужен ETH, можно проверить доступное направление обмена ETH. Перед созданием заявки следует отдельно уточнить поддерживаемую сеть, направление операции и актуальные требования проверки: они зависят от выбранной операции и результатов compliance-процедур.
Памятка: что теперь можно объяснить и проверить
- Отличить Ethereum как сеть от ETH как нативного актива.
- Объяснить, почему gas измеряется отдельно, но комиссия оплачивается в ETH.
- Определить, когда приложение только читает данные, а когда создаёт транзакцию.
- Понять разницу между переводом ETH и вызовом смарт-контракта.
- Проверить перед подписью сеть, адрес, сумму, функцию, разрешение и максимальную комиссию.
- Найти транзакцию по хешу и различить ожидание, успех, замену и ошибку.
- Объяснить, почему неуспешное исполнение может израсходовать ETH на gas.
- Не путать успешный статус EVM с безопасностью контракта или выгодностью операции.
- Распознать риски неверной сети, подмены адреса, фишинга и чрезмерного allowance.
- Проверить наблюдаемый результат по блоку, фактической комиссии, событиям и итоговым балансам.
Рабочая ментальная модель Ethereum укладывается в одну цепочку: пользователь разрешает действие подписью, приложение превращает намерение в транзакцию, EVM выполняет код за измеряемый gas, сеть фиксирует новое состояние, а результат подтверждается не сообщением интерфейса, а данными блокчейна.
























