Ethereum network error

Ethereum 2.0 ,

27 авг 2021, 18:40 

0 

Крупная реорганизации блоков в сети альткоина могла стать причиной разветвления блокчейна

В сети Ethereum произошла крупная ошибка, которая затрагивает около 54% узлов сети, пишет The Block. По информации издания, ошибка была обнаружена в старых версиях (v1.10.7 и ниже) сетевого клиента Ethereum Geth. Узлы, на которых использовались старые версии клиента, отделялись от основной сети Ethereum.

Разработчики Ethereum были уведомлены о последствиях ошибки еще 24 августа. Об этом их оповестили аудитор Sentnl Гвидо Вранкен, который проводил проверку виртуальной машины Ethereum. После этого разработчики альткоина выпустили обновление, которое исправляет ошибку, однако для этого узлы должны обновить свое программное обеспечение. До тех пор они рекомендовали воздержаться от проведения транзакций.

Благодаря обновлению удалось избежать серьезного разветвления блокчейна. Один из разработчиков альткоина сообщил в Twitter, что большинство майнеров обновили свои узлы, поэтому критическая ошибка не привела к разветвления блокчейна. Узлы, которые не обновили программное обеспечение, больше не имеют доступа к основной сети Ethereum.

5 августа в сети вышло обновление London, которое полностью изменило механизм начисления комиссий за транзакции. Часть комиссий, которую ранее получали майнеры в качестве вознаграждения, теперь сжигается.

С момента активации обновления в сети альткоина было сожжено более 109,5 тыс. Ethereum на сумму $353,5 млн, по данным сервиса ultrasound.money, который отслеживает уничтожение монет в сети альткоина. Средняя скорость сжигания в минуту составляет 3,44 Ethereum.

— За последние три недели было сожжено Ethereum на $309 млн

— Инвестиции Grayscale в Ethereum превысили $10 млрд

— «Ethereum подорожает в 10 тыс. раз». Почему криптовалюта продолжит рост

Больше новостей о криптовалютах вы найдете в нашем телеграм-канале РБК-Крипто.

Blockchain technology gives users the freedom to transact in ways they’ve never been able to before. Rather than the rigid transactions expected in the formal financial world, Web3 offers users access to programmable transactions through smart contracts. 

However, Web3 also introduces a host of complications and uncertainties to the transaction lifecycle. At every step of the Web3 transaction lifecycle, there is the potential for the transaction to go sideways, resulting in stuck, dropped, or failed transactions. These risks begin with creating a transaction and setting the gas price and continue until the transaction is confirmed on-chain. Users new to Decentralized Finance (DeFi) will not be accustomed to these errors. 

To reduce user friction, a successful Dapp or wallet needs to make the different steps in the transaction lifecycle as transparent and accurate as possible. This will allow users to accurately compose their transaction and monitor its progress through the mempool to detect any potential issues before it is finalized. Successful transaction orchestration results in a growing user base for both the Web3 project and the crypto ecosystem as a whole as decentralized finance becomes more user-friendly. Moreover, reducing the number of stuck, dropped, or failed transactions will generally increase the metrics you care about, including Volume or TVL for your protocol.

Components of an Ethereum transaction

To best understand common transactions errors on Ethereum, you first need to understand the different components that comprise a transaction. These components directly impact the probability of the transaction being confirmed rapidly or not. 

All Ethereum transactions will contain the following:

nonce: the transaction nonce dictates the order in which the transactions from a given account (ethereum address) need to be executed. Every account starts with a nonce of 0 and increases by 1 each time a user sends a transaction. Crucially, when you have multiple pending transactions, they are confirmed in the order of their nonce. If a lower nonce transaction gets stuck or dropped, your higher nonce transactions cannot confirm.

baseFee (type2 transactions): this gas fee is determined by the network itself. Depending on how full the new block is, the Base Fee is automatically increased or decreased.

MaxPriorityFee (type2 transactions): also known as the miner tip, this fee is determined by the user and is paid directly to miners. Blocknative provides industry-leading PriorityFee estimations available on our Browser Extension.

MaxFeePerGas (type2 transactions): the absolute maximum you are willing to pay per unit of gas to get the transaction included in a block. Any leftover gas will be refunded to your wallet.

gasLimit: Maximum amount of gas the transaction is authorized to consume.  

to: The address to which you are directing the transaction.

value: Total ETH you want to send. Note that this field is for ETH only; ERC-20 or NFT transaction amounts don’t count towards the value field.

10 Common Ethereum Transaction Errors

The most common Ethereum transaction errors are:

1. ErrAlreadyKnown
2. ErrInvalidSender
3. ErrNonceTooLow
4. ErrNonceTooHigh
5. ErrUnderpriced
6. ErrReplaceUnderpriced
7. ErrInsufficientFunds
8. ErrIntrinsicGas
9. ErrNegativeValue
10. ErrOversizedData

1. ErrAlreadyKnown

The ErrAlreadyKnown transaction error occurs when users try to re-submit a transaction that was previously submitted and now resides in the mempool. 

If you received “ErrAlreadyKnown,” you generally won’t need to do anything.  If you made a mistake in the original transaction, you may wish to submit a replacement (i.e. a “speedup” or “cancel” transaction).

2. ErrInvalidSender

The ErrInvalidSender transaction error occurs when the signature from the address from which you are sending the transaction is invalid.

To fix the ErrInvalidSender error, sign the transaction from the correct address and try submitting the transaction again.

3. & 4. ErrNonceTooLow & ErrNonceTooHigh

ErrNonceTooLow and ErrNonceTooHigh are deceptively straightforward.

On the surface, ErrNonceTooLow occurs when the nonce value is less than or equal to the corresponding value of your last submitted transaction.

ErrNonceTooHigh, on the other hand, occurs when the Ethereum node detects a “nonce gap”, meaning it detected a transaction with a nonce that is greater than the nonce of your previous transaction plus 1.  

Recall that the nonce is an integer associated with each address, which increases monotonically with each transaction submitted from that address. Thus, NonceTooLow and NonceTooHigh respectively point to insufficient and excessive nonce-increments.

But what exactly do we mean by “insufficient” and “excessive” here?  Insufficient and excessive relative to what? This is where things get hairy.

Informally, the nonce increment is validated against the last transaction originating from a given address that is known by the Ethereum node that is processing the new transaction. That sentence is somewhat of a mouthful, so let us introduce some simple notation to help keep track of things. 

Let’s refer to the most recent transaction you have submitted t, and let’s refer to the transaction you are currently submitting as t’.  Because you are a sensible person, you have taken care to increment the nonce for t’, so nonce(t’) = nonce(t) + 1. But much to your dismay, the Ethereum node to which you submit t’ responds with ErrNonceTooHigh. What happened?

Blockchains are eventually consistent systems, and this has two important consequences. At the consensus level, a given Ethereum node may be looking at stale or invalid chain states at any given time. 

Therefore, even if t is technically “on-chain”, some nodes may not observe t  for some time, perhaps even several seconds.  At the pre-consensus level – i.e., in the mempool – the situation is even worse; there are no consistency guarantees whatsoever, eventual or otherwise.

As such, even a correct transaction can produce ErrNonceTooHigh if t’ was submitted to a node other than the one that processed t .  Similarly, NonceTooLow can fail to occur when transactions are spread across different nodes, depending on how they propagate.

The failure modes that produce ErrNonceTooHigh and ErrNonceTooLow are manifold and warrant an in-depth analysis in a separate article.

In practice, though, it’s not always obvious what to do about them.  ErrNonceTooLow can usually be remedied by incrementing the nonce (though, beware of the nonce-gap!). 

ErrNonceTooHigh, on the other hand, is more ambiguous. It frequently resolves on its own, as transactions propagate through the network, but may also require decrementing the nonce. Blocknative’s Mempool Explorer and Simulation Platform can help you diagnose the issue.

5. ErrUnderpriced

ErrUnderpriced occurs when a transaction’s gas price is below the minimum amount that the node has been configured to accept.

To fix this error, increase the gas price for the transaction and try again.  One small caveat:  to avoid denial-of-service due to bidding wars, the Ethereum nodes require such “replacement transactions” to increase the gas price by a minimum amount, typically 10%.

6. ErrReplaceUnderpriced

ErrReplaceUnderpriced occurs when a user tries to replace or cancel a transaction and the amount of gas is not higher than the original transaction. If the replacement transaction’s gas is lower than the original transaction, the new transaction will not replace the original transaction.

To resolve  ErrReplaceUnderpriced, increase the gas price or MaxPriorityFee of the replacement transaction, such that their aggregate value exceeds that of the original transaction by the minimum increment, typically 10%.

7. ErrInsufficientFunds

The ErrInsufficientFunds error is a common Ethereum transaction failure that occurs when the sending wallet does not have enough funds (ETH) to cover the maximum gas the transaction can consume plus any ETH funds directly sent in the transaction.

To fix ErrInsufficientFunds, either add more funds to the wallet, or lower the gas settings and/or value transferred until the transaction fits within the wallet’s available funds.

8. ErrIntrinsicGas

Before a smart contract can be executed on Ethereum, there is a fixed cost—known as the intrinsic gas—that must be paid. This cost is calculated dynamically and depends on both the transaction type and the number of bytes in the transaction payload.  If the gas limit is less than the intrinsic fee, miners will reject the transaction.

To fix an ErrIntrinsicGas error, increase the transaction gas limit and submit the transaction again. 

9. ErrNegativeValue

The ErrNegativeValue error occurs when trying to send a negative amount of funds. Need we say more?

10. ErrOversizedData

ErrOversizedData occurs when the size of input data results in a transaction whose total size is above 128KB.  This transaction failure is not caused by a consensus error but is implemented as a measure to protect the network against Denial-of-Service (DoS) attacks.

To fix the ErrOversizedData error, reduce the size of your input and ensure the transaction’s total size does not exceed 128KB.

Do I get my ETH back from a failed transaction?

If a transaction fails, the ETH in the value field of the transaction will remain available to the originator, and will not be sent or consumed

Do I get my gas back from a failed transaction?

Each operation executed by the Ethereum Virtual Machine (EVM) consumes some amount of gas. Despite a transaction failing, computational power was still used to make this determination, so you will still pay some gas for a failing result.

However, miners are only paid for the actual gas consumed by a transaction and any unused gas is refunded to the originator. We highly recommend simulating your transactions using Transaction Preview before submitting them to the network in order to avoid on-chain failures that cost gas.

Nonce Gaps and Transaction Errors

For an Ethereum transaction to be confirmed, its nonce value must be one more than the nonce value of the last confirmed transaction for the given account. For example, if the last confirmed transaction in an account had a nonce value of 3, a transaction with a nonce value of 5 cannot be accepted until a transaction with a nonce value of 4 is confirmed. 

As a result of this feature, when transactions are dropped from the mempool new transactions from a given account cannot be processed until the original nonce gap has been resolved. As the Ethereum network becomes increasingly more congested, dropped transactions are becoming more common. 

This is because times of extreme network congestion can lead to underpriced transactions being dropped from mempools. Since the dropped transactions are unable to get back into the mempool by themselves, they cannot span the transaction nonce gap, preventing wallets from completing new transactions until the nonce gap has been resolved.

How to Fix Nonce Gaps 

To fix errors resulting from dropped transactions and nonce gaps, users should:

1. Identify the first missing transaction in the nonce gap.
2. Send a replacement transaction with the same nonce value (and enough gas to prevent it from getting stuck). 
3. Monitor the replacement transaction as it moves through the mempool.
4. Repeat steps 1-4 until all stuck transactions have been replaced and confirmed on-chain.

Utilize Mempool Data for Measurable Results

Transaction errors result in lost gas fees, missed trades, and general confusion. Preventing failed transactions is one of the most frustrating challenges users face when interacting with Web3. 

To grow your active users and succeed in this competitive industry, integrating mempool data and transaction monitoring APIs is one of the most important blockchain developer tools you can add to your Web3 tech stack. 

Integrating real-time mempool transaction event data streams into your engineering efforts is a straightforward and seamless process with Blocknative APIs like Mempool Explorer, Notify, and real-time gas data with the Gas Platform API. Integrating these tools into your projects can help users identify and mitigate common Ethereum transaction errors before they become systemic issues.

For more information, keep up with us on Twitter and join our community in Discord!


В данной статьи речь будет идти о нодах. Это узлы сети, которые хранят данные блокчейна, включая транзакции в нём и прочие мелочи. Ноды отвечают за верификацию транзакций и блоков в соответствии с правилами сети. Чем больше нод, тем безопаснее является сеть криптовалюты.

Что случилось с Эфириумом?

По словам тимлида Ethereum Foundation Петера Силадьи, давним багом не занимались более двух лет. Аспирант в Software Platform Lab Джон Ёнгсок Ян заметил баг и получил 20 тысяч баллов (на сумму 20 тысяч долларов США, обычно выплачиваемых в ETH) за обнаружение двух серьезных уязвимостей. При этом сама ошибка затронула клиент сети под названием Go-Ethereum или Geth. Несколько месяцев назад разработчики криптовалюты представили исправление ошибки, и многие узлы с последней версией клиента были защищены от неё. Однако технические детали бага так и не были раскрыты, чтобы предотвратить его использование злоумышленником.

Что более важно, некоторые узлы сети Эфириума не обновились до последней версии клиента. Infura использовала версию Geth 1.9.9, выпущенную ещё 6 декабря 2019 года. И тут баг дал о себе знать.

В 7:10 по UTC блокчейн разделился на более длинную и более короткую цепочки. В некоторой степени это происходит постоянно, и узлы придерживаются более длинной версии. Но в данном случае узлы, которые не обновились, остались в более короткой цепочке. Это означало, что они взаимодействовали с разными блоками и не синхронизировались с другими версиями блокчейна. То есть участники сети считали актуальными и правильными разные цепочки.

Последствия инцидента сказались и на обычных пользователях. В частности, крупнейшая криптовалютная биржа Binance заметила проблему и на некоторое время приостановила вывод ETH с площадки. Обозреватель блокчейна Blockchair начал показывать неправильную информацию с меньших цепей блоков, а MetaMask попросту не работал.

Больше всего неприятностей произошло в круге клиентов Infura. Напомним, платформа запускает ноды Ethereum от имени централизованных и децентрализованных проектов, поэтому в некотором роде она является одной из главных составляющих экосистемы криптовалюты. Многие крупные проекты используют Infura: к ним в том числе относятся кошельки MetaMask и Coinbase Wallet, популярное децентрализованное приложение CryptoKitties и кредитная платформа Compound. Когда у Infura случились проблемы, многие из этих сервисов не смогли взаимодействовать с блокчейном. Ну а пользователи MetaMask не могли провести свои транзакции в ETH.

Исключением были пользователи, вручную указывающие данные другого узла сети, который не был затронут в инциденте. Этим воспользовались сторонние провайдеры инфраструктуры для собственной рекламы.

Сразу после всего произошедшего Infura резко раскритиковали за излишнюю централизацию. Однако Силадьи поспешил защитить платформу от негативных комментариев, оставив следующий твит. Его приводит Decrypt.

Эй, интернет. Прекратите тыкать пальцем на Infura за использование старых версий Geth. С точки зрения оператора совершенно разумно не просматривать новейшие версии клиентов.

То есть он считает, что обвинять в происходящем компанию можно, но не слишком активно. Всё же у представителей команды было право использовать подходящую версию клиента — просто в данном случае у этого неожиданно появилось много последствий.


Из произошедшего действительно можно вынести пару важных уроков. Во-первых, в экосистеме Эфириума все-таки есть слабые места. К счастью, вчера все обошлось и события никак не отразились на рыночных настроениях. Во-вторых, при выпуске обновлений Ethereum должно быть больше прозрачности, поскольку в данном случае представители Infura явно не осознавали важность апдейта.

Вот что по этому поводу думает Петер Силадьи.

Тем не менее, молчаливое исправление бага, бездействующего в течение более двух лет, имеет гораздо меньший шанс вызвать проблемы, чем повышение осведомленности о нем. Мы стремимся минимизировать потенциальный ущерб.


Мы считаем, что ситуация выдалась интересной. Многие пользователи сети Эфириума не могли с ней взаимодействовать — а это далеко от нормы. И хотя всё закончилось хорошо, владельцы криптовалют явно ощутили ограниченность своих возможностей при работе с монетами.

Согласны ли вы с этим утверждением? Поделитесь своей точкой зрения в нашем крипточате. Также заглядывайте в Яндекс Дзен за добавкой материалов, которых нет на сайте.

ПОДПИСЫВАЙТЕСЬ НА НАШ КАНАЛ В ТЕЛЕГРАМЕ. КРИПТА — ЭТО БУДУЩЕЕ!

В рамках перевода Ethereum на алгоритм Proof-of-Stake сегодня на блоке 12244000 состоялся хардфорк Berlin. Проблемы начались уже через 294 блока после обновления — произошел сбой на узлах клиента Open Ethereum. Как отмечает CoinTelegraph, цепочка блоков Ethereum должна работать в обычном режиме, поскольку проблема затрагивает пока только Open Ethereum и связана, вероятно, с ошибкой хеш-дерева Меркла.

Проблемы зафиксировали в системе криптокошельков Ledger и на бирже Bitstamp, которая в настоящее время приостановила снятие и депозит токенов ETH и ERC20 из-за проблем в блокчейне Ethereum. Проблемы затронули сервис-обозреватель блоков Etherscan.io. Его разработчики сейчас заняты выявлением причин сбоя.

Хардфорк Berlin включает 4 обновления: EIP-2565, EIP-2929, EIP-2930 для корректировки комиссий за транзакции и снижения рисков при разрыве смарт-контрактов, а также EIP-2718 для возможности комбинирования транзакций.

Источники: CoinTelegraph, Cryptopotato