Транзакция блокчейна — это авторизованный запрос на изменение состояния сети
Транзакция блокчейна — не перемещение ценности по невидимому каналу, а структурированные данные с запросом на конкретное изменение. Это может быть перевод нативной монеты, вызов смарт-контракта, передача токена, создание актива или обновление другой части реестра.
Сначала кошелёк формирует объект транзакции. Затем необходимые подписанты авторизуют его цифровыми подписями. Подписанные данные рассылаются сетевым узлам, независимо проверяются по правилам протокола и могут быть включены в принятый блок или упорядоченный пакет.
Только принятое выполнение меняет общее состояние. До этого транзакция остаётся предложением. Она может быть видимой, корректной и широко распространённой, но ещё не менять балансы, права распоряжения или хранилище контрактов в канонической истории.
В Bitcoin транзакции расходуют существовавшие выходы и создают новые. В Ethereum это криптографически подписанные инструкции от аккаунтов. В Solana транзакция объединяет подписи и одну или несколько инструкций. В TON транзакция возникает, когда аккаунт обрабатывает сообщение и меняет состояние. Форматы различаются, но общий принцип сохраняется.
Пользователь задаёт намерение, а кошелёк создаёт объект транзакции
Пользователи формулируют простые задачи: отправить 0,01 BTC, перевести 50 USDT, обменять токен или вызвать контракт. Блокчейн не обрабатывает человеческое намерение напрямую. Кошелёк или приложение должно преобразовать его в строго определённую структуру, понятную выбранной сети.
За простой командой скрываются технические решения. Bitcoin-кошелёк выбирает доступные для расходования выходы и рассчитывает сдачу; Ethereum-кошелёк назначает nonce и оценивает газ. Кошельки Solana и TON подготавливают требуемые аккаунты, ссылки на блоки и сообщения.
Желаемый результат: оплата на адрес или вызов приложения.
Сетевая структура данных с описанием запрошенного изменения.
Доказательство согласия необходимых ключей с точными данными.
Изменение состояния после обработки принятой транзакции.
Таким образом, транзакция — не просто платёжное поручение, а машиночитаемое описание того, что должно измениться, кем это разрешено, какие ресурсы используются и какие правила сети необходимо соблюсти.
Поля у сетей разные, но каждой транзакции нужен контекст для проверки
Единого формата транзакций для всех блокчейнов нет. Однако большинство содержит одни и те же идеи: доступные ресурсы, желаемый результат, авторизацию, защиту от повторного исполнения либо правила последовательности и стоимость обработки, которую принимает отправитель.
| Компонент | Назначение | Типичные примеры |
|---|---|---|
| Исходные ресурсы | Определяют, что разрешено потратить или какой аккаунт начинает операцию. | Входы Bitcoin; отправитель Ethereum; список аккаунтов Solana |
| Желаемый результат | Описывает перевод, инструкцию или вызов контракта. | Выходы, получатель и сумма, инструкции программы, тело сообщения |
| Защита последовательности | Предотвращает нежелательное повторение и устанавливает допустимый порядок. | Outpoint, nonce, недавний хеш блока, номер последовательности |
| Лимиты и комиссии | Ограничивают вычисления или оплачивают обработку. | Ставка комиссии, лимит газа, приоритетная комиссия, вычислительный бюджет |
| Подписи | Подтверждают согласие закрытых ключей без раскрытия самих ключей. | ECDSA, Schnorr, Ed25519, проверка контрактом |
Руководство по транзакциям Bitcoin объясняет, как входы ссылаются на прежние выходы и как новые выходы задают условия будущих расходов. Документация Ethereum описывает получателя, значение, данные, nonce, лимит газа и параметры комиссий.
Цифровая подпись разрешает точные данные, но сама по себе не переводит средства
Кошелёк подписывает определённое представление транзакции одним или несколькими закрытыми ключами. Участники сети могут проверить подпись соответствующим открытым ключом или условием расходования и убедиться в наличии разрешения, не узнавая секретный ключ.
Подпись доказывает право на действие, а не личность человека. Корректная подпись показывает контроль над ключом, требуемым протоколом, но не раскрывает реального подписанта и не доказывает существование коммерческого соглашения или правильность выбранного получателя.
Важна и область подписанных данных. Изменение суммы, адреса назначения, инструкции или другого защищённого поля делает подпись недействительной. Поэтому посредник обычно не может изменить подписанный перевод и сохранить исходную авторизацию.
Модели UTXO и аккаунтов по-разному описывают доступное для расходования состояние
Формат транзакции связан с моделью реестра. Bitcoin использует непотраченные выходы транзакций, или UTXO. Новая транзакция расходует конкретные прежние выходы и создаёт новые. Сеть не обновляет единый глобальный баланс Bitcoin-аккаунта: кошелёк вычисляет доступную сумму по выходам, которые его ключи могут потратить.
Ethereum основан на аккаунтах. У внешнего аккаунта есть баланс и nonce. Транзакции применяются с учётом последовательности nonce и могут менять балансы, код контрактов и их хранилища. Документация аккаунтов Ethereum объясняет, как nonce не допускает многократного исполнения одной и той же подписанной транзакции.
Транзакции Solana явно задают аккаунты, из которых инструкция читает данные или в которые записывает. Программы выполняют инструкции и изменяют доступные для записи аккаунты. Недавний хеш блока ограничивает срок действия запроса. Официальное руководство Solana описывает подписи, инструкции, ключи аккаунтов и хеш блока.
TON использует сообщения. Входящее сообщение может инициировать транзакцию одного аккаунта, изменить его состояние и отправить исходящие сообщения другим аккаунтам. Связь описана в документации TON о сообщениях и транзакциях.
Расходование отдельных выходов и создание новых.
Последовательные изменения балансов, nonce и хранилищ.
Выполнение инструкций, читающих и меняющих объявленные аккаунты.
Обработка сообщений каждым аккаунтом с созданием последующих сообщений.
Рассылка распространяет кандидата, но не означает согласия сети
После подписания кошелёк передаёт сериализованную транзакцию узлу или сервису. Тот проводит базовые проверки и решает, принять ли запрос и переслать ли его другим узлам. Остальные участники повторяют процесс, распространяя транзакцию по сети.
Распространение не мгновенно и не одинаково. У узлов разные соединения, программные политики, лимиты ресурсов и локальные представления состояния. Один обозреватель может показать ожидающую транзакцию раньше другого; некоторые узлы могут отклонить то, что сохраняют остальные.
Руководство по P2P-сети Bitcoin описывает обмен между полными узлами. Следовательно, статус «отправлено в сеть» означает начало распространения, но не общепринятый канонический результат.
Узлы проверяют и данные транзакции, и состояние, в котором она исполнялась бы
Проверка подписи — лишь один этап валидации. Узел проверяет сериализацию, значения полей, ссылки на ресурсы и требования к очередности, после чего сопоставляет запрос со своей актуальной картиной реестра.
В Bitcoin указанные выходы должны существовать и оставаться непотраченными. Разблокирующие данные обязаны удовлетворять условиям расходов, а сумма входов — покрывать выходы и подразумеваемую комиссию. Повторная трата уже использованного выхода недопустима в таком состоянии цепи.
В Ethereum подпись должна однозначно определить отправителя, nonce должен соответствовать порядку аккаунта, а средства покрывать сумму перевода и максимальную стоимость исполнения. Тип транзакции обязан соответствовать действующим правилам. Смарт-контракт проводит дополнительные проверки и может завершиться откатом.
Solana проверяет необходимые подписи, недавний хеш блока, блокировки аккаунтов, структуру инструкций, достаточность комиссий и правила среды исполнения. TON валидирует входящее сообщение и обрабатывает аккаунт по установленным протоколом фазам.
Транзакция-кандидат ├─ корректная структура? ├─ действительны требуемые подписи? ├─ доступны входы или состояние аккаунта? ├─ допустимы порядок / nonce / хеш блока? ├─ достаточно комиссий и ресурсов? └─ операция разрешена протоколом? ├─ нет → отклонить или не пересылать └─ да → сохранить кандидатом на включение
Валидация зависит от контекста. Транзакция может быть корректной при подписании, но потерять пригодность до включения: другой запрос потратит тот же выход Bitcoin, более ранний nonce в Ethereum ещё не поступит или недавний хеш Solana устареет.
Корректная ожидающая транзакция принята локально, но ещё не записана канонически
Многие сети сохраняют локальные наборы транзакций, прошедших проверки допуска, но не вошедших в блок. Термин «мемпул» удобен, однако единого глобального пула обычно нет: каждый узел управляет собственным набором кандидатов по своим правилам и представлению о сети.
Производители блоков выбирают доступные им операции. На выбор влияют вместимость, комиссионные стимулы, зависимости, порядок аккаунтов и ограничения исполнения. Корректный кандидат может ожидать, быть заменённым, устареть или исчезнуть из отдельных локальных пулов.
Статья OxaPay Как работает мемпул подробнее разбирает конкуренцию за вычислительную ёмкость и причины задержек. Здесь мемпул рассматривается как этап жизненного цикла; рынок комиссий и конкуренция за место в блоке заслуживают отдельного исследования.
Включение в блок задаёт позицию исполнения в принятой истории
Майнер, валидатор, лидер или секвенсор выбирает транзакции и предлагает упорядоченный блок либо пакет. Другие участники проверяют предложение по протоколу. Принятый блок становится частью текущей канонической истории или принятой кандидатной истории, прочность которой может расти.
Порядок важен из-за зависимости от предыдущего состояния. Две транзакции могут расходовать один ресурс; контрактные вызовы давать разные результаты при смене очередности; nonce требует строгого порядка; блокировки аккаунтов Solana влияют на параллельное исполнение.
Поэтому включение — не просто добавление времени: транзакция получает конкретную позицию в последовательности переходов состояния и оценивается после всех предыдущих и до всех следующих операций.
Исполнение детерминированно преобразует исходное состояние в итоговое
Когда транзакция достигает своего места, сеть применяет соответствующие правила. Концептуально процесс описывается функцией перехода состояния:
post_state = transition(pre_state, ordered_transaction, protocol_rules)
В Bitcoin успешная проверка удаляет потраченные выходы из набора UTXO и добавляет новые. В Ethereum выполнение может изменить балансы, увеличить nonce отправителя, развернуть контракты, обновить хранилище и сформировать логи. Тесты спецификации исполнения Ethereum сравнивают исходное состояние с ожидаемым итоговым.
В Solana каждая инструкция вызывает программу с перечисленными аккаунтами, а изменения атомарны: транзакция либо проходит целиком, либо её изменения откатываются. В TON обработка сообщения может изменить один аккаунт и создать сообщения, которые позже активируют транзакции других аккаунтов.
Перевод токена показывает различие между транзакцией и перемещением ценности. Во многих сетях нативная транзакция вызывает токен-контракт; контракт обновляет хранящиеся в нём балансы и может создать событие передачи. Отдельный объект-токен физически между адресами не перемещается.
Квитанции, журналы, события и трассировки дают свидетельства исполнения, но не идентичны самому состоянию. Приложение может распознать перевод через события, но должно понимать, какие данные удостоверяют нужное авторитетное изменение состояния.
Отказ, удаление, замена, истечение срока и откат происходят на разных уровнях
Выражение «неуспешная транзакция» слишком расплывчато. Неверно сформированный или неавторизованный запрос отклоняется ещё до распространения. Корректный запрос может не попасть в блок, уступить конкурирующему, устареть; вызов контракта может быть включён в блок, но завершиться откатом при исполнении.
| Результат | Что произошло | Влияние на состояние |
|---|---|---|
| Отклонена | Не прошла правила допуска или консенсуса. | Нет канонического изменения |
| Ожидает или удалена | Осталась кандидатом, не была включена или сохранена. | Нет канонического изменения |
| Заменена или конфликтует | Другая операция заняла ресурс или место в последовательности. | Состояние меняет только принятая альтернатива. |
| Включена и успешна | Исполнение завершено по правилам. | Желаемое итоговое состояние зафиксировано. |
| Включена, но откатилась | Контрактный вызов начался и завершился неудачей. | Прикладные изменения отменены; комиссии и некоторые изменения очередности могут сохраниться. |
Это критично при чтении обозревателей. Включённая транзакция Ethereum может иметь статус ошибки и всё равно расходовать газ. Отсутствующая в принятой цепи транзакция Bitcoin способна появиться вновь при повторной рассылке, если остаётся действительной. Транзакция Solana может истечь из-за устаревшего хеша блока.
Хеш идентифицирует данные, но не объясняет полного смысла операции
Идентификатор транзакции обычно выводится из сериализованных данных и позволяет узлам, обозревателям, кошелькам и приложениям ссылаться на запрос, не повторяя весь его объём. Правила хеширования и идентификации различаются по сетям.
Руководство OxaPay по идентификатору криптотранзакции объясняет использование TXID при проверке платежей и поддержке. Обозреватель блокчейна показывает адреса, суммы, комиссии, позицию в блоке, итог исполнения и подтверждения.
Но хеш не знает, соответствует ли запрос заказу. Он не знает ожидаемый актив, сеть, сумму счёта, срок действия, клиента и правила исполнения заказа. Это сетевая ссылка, а не полноценная коммерческая запись.
Жизненный цикл общий, но смысл и гарантии транзакций зависят от сети
Каждая сеть переходит от предложения операции к принятому состоянию, однако механизмы различаются. Bitcoin расходует выходы, Ethereum переводит ETH или вызывает контракты, Solana выполняет набор инструкций над перечисленными аккаунтами, TON использует сообщения и транзакции отдельных аккаунтов.
Различия влияют на комиссии, размер, порядок, параллельное исполнение, срок действия, обнаружение токенов и смысл успешного результата. Платёжная инфраструктура тоже должна по-разному читать данные: перевод ERC-20 обнаруживается по исполнению и логам контракта, перевод Bitcoin — по выходам, а движение жетона Jetton в TON может потребовать отслеживания цепочки сообщений между контрактами.
Одного символа актива недостаточно: компании необходимо знать и актив, и сеть. Документация OxaPay по поддерживаемым валютам показывает валюты вместе с сетевыми параметрами. Один символ токена может требовать разной интерпретации в разных сетях.
Транзакция блокчейна — лишь одна запись в полноценной платёжной системе
Платёжный запрос начинается с коммерческого контекста: заказа, суммы, выбранного актива, сети, назначения, срока действия и бизнес-идентификатора. Транзакция блокчейна фиксирует фактически отправленное плательщиком, а платёжная система сравнивает ожидаемые условия с наблюдаемыми данными.
Метод Payment Information в OxaPay демонстрирует разделение: платёжная запись может содержать идентификатор отслеживания, данные заказа и общий статус; данные самой транзакции — хеш, сумму, валюту, сеть, адрес, статус и подтверждения.
Статус сетевой операции и статус платежа связаны, но не совпадают. Таблица статусов OxaPay включает ожидание, оплату в процессе, оплачено, недоплату, возврат в процессе, возврат завершён и истечение срока. Сама сеть не создаёт эти коммерческие значения.
Коммерческий запрос
заказ + ожидаемая сумма + актив + сеть + срок
↓
Транзакция блокчейна
хеш + входы/аккаунты + инструкции + подпись + результат
↓
Интерпретация платежа
сопоставление + правила подтверждения + исключения + статусПоэтому понимание транзакций важно торговым компаниям, даже если шлюз скрывает детали протокола. Оно помогает отличать сетевые доказательства от завершения платежа и диагностировать неверную сеть, ошибочную сумму, задержку включения, неудачное исполнение и несопоставленные переводы.
Семь этапов для понимания любой транзакции блокчейна
- Намерение: пользователь или приложение задаёт результат.
- Формирование: кошелёк создаёт объект для конкретной сети.
- Авторизация: необходимые ключи подписывают точные данные или условия расходов.
- Распространение: узлы получают, проверяют и пересылают кандидата.
- Допуск и отбор: кандидаты ожидают с учётом политик, ёмкости, очередности и комиссий.
- Включение и исполнение: запрос получает позицию и применяется к предыдущему состоянию.
- Принятое состояние: результат входит в историю сети и со временем получает более сильное подтверждение.
Пользователи часто приравнивают «отправлено» к «состояние изменилось». Эта схема показывает, почему требуются формирование, подпись, валидация, порядок и исполнение, прежде чем результат появится в реестре.