erigon-pulse/core/error.go

99 lines
4.1 KiB
Go
Raw Normal View History

2015-07-07 00:54:22 +00:00
// Copyright 2014 The go-ethereum Authors
// This file is part of the go-ethereum library.
2015-07-07 00:54:22 +00:00
//
// The go-ethereum library is free software: you can redistribute it and/or modify
2015-07-07 00:54:22 +00:00
// it under the terms of the GNU Lesser General Public License as published by
// the Free Software Foundation, either version 3 of the License, or
// (at your option) any later version.
//
// The go-ethereum library is distributed in the hope that it will be useful,
2015-07-07 00:54:22 +00:00
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
2015-07-07 00:54:22 +00:00
// GNU Lesser General Public License for more details.
//
// You should have received a copy of the GNU Lesser General Public License
// along with the go-ethereum library. If not, see <http://www.gnu.org/licenses/>.
2015-07-07 00:54:22 +00:00
2014-12-04 09:28:02 +00:00
package core
2014-02-14 22:56:09 +00:00
all: add support for EIP-2718, EIP-2930 transactions (#21502) This adds support for EIP-2718 typed transactions as well as EIP-2930 access list transactions (tx type 1). These EIPs are scheduled for the Berlin fork. There very few changes to existing APIs in core/types, and several new APIs to deal with access list transactions. In particular, there are two new constructor functions for transactions: types.NewTx and types.SignNewTx. Since the canonical encoding of typed transactions is not RLP-compatible, Transaction now has new methods for encoding and decoding: MarshalBinary and UnmarshalBinary. The existing EIP-155 signer does not support the new transaction types. All code dealing with transaction signatures should be updated to use the newer EIP-2930 signer. To make this easier for future updates, we have added new constructor functions for types.Signer: types.LatestSigner and types.LatestSignerForChainID. This change also adds support for the YoloV3 testnet. Co-authored-by: Martin Holst Swende <martin@swende.se> Co-authored-by: Felix Lange <fjl@twurst.com> Co-authored-by: Ryan Schneider <ryanleeschneider@gmail.com> # Conflicts: # accounts/abi/bind/backends/simulated.go # cmd/evm/internal/t8ntool/execution.go # cmd/evm/internal/t8ntool/transition.go # cmd/geth/main.go # cmd/geth/usage.go # core/bench_test.go # core/state/statedb.go # core/state_prefetcher.go # core/state_processor.go # core/state_transition.go # core/tx_pool.go # core/types/block.go # core/types/derive_sha.go # core/types/gen_tx_json.go # core/types/receipt.go # core/types/receipt_test.go # core/types/transaction.go # core/types/transaction_signing.go # core/types/transaction_test.go # ethclient/ethclient.go # ethclient/signer.go # graphql/graphql.go # internal/ethapi/api.go # internal/guide/guide_test.go # les/benchmark.go # les/odr_test.go # light/odr_test.go # light/txpool.go # miner/worker.go # miner/worker_test.go # signer/core/api.go # tests/state_test_util.go # trie/stacktrie_test.go # turbo/stages/blockchain_test.go
2021-02-25 14:26:57 +00:00
import (
"errors"
"github.com/ledgerwatch/erigon/core/types"
all: add support for EIP-2718, EIP-2930 transactions (#21502) This adds support for EIP-2718 typed transactions as well as EIP-2930 access list transactions (tx type 1). These EIPs are scheduled for the Berlin fork. There very few changes to existing APIs in core/types, and several new APIs to deal with access list transactions. In particular, there are two new constructor functions for transactions: types.NewTx and types.SignNewTx. Since the canonical encoding of typed transactions is not RLP-compatible, Transaction now has new methods for encoding and decoding: MarshalBinary and UnmarshalBinary. The existing EIP-155 signer does not support the new transaction types. All code dealing with transaction signatures should be updated to use the newer EIP-2930 signer. To make this easier for future updates, we have added new constructor functions for types.Signer: types.LatestSigner and types.LatestSignerForChainID. This change also adds support for the YoloV3 testnet. Co-authored-by: Martin Holst Swende <martin@swende.se> Co-authored-by: Felix Lange <fjl@twurst.com> Co-authored-by: Ryan Schneider <ryanleeschneider@gmail.com> # Conflicts: # accounts/abi/bind/backends/simulated.go # cmd/evm/internal/t8ntool/execution.go # cmd/evm/internal/t8ntool/transition.go # cmd/geth/main.go # cmd/geth/usage.go # core/bench_test.go # core/state/statedb.go # core/state_prefetcher.go # core/state_processor.go # core/state_transition.go # core/tx_pool.go # core/types/block.go # core/types/derive_sha.go # core/types/gen_tx_json.go # core/types/receipt.go # core/types/receipt_test.go # core/types/transaction.go # core/types/transaction_signing.go # core/types/transaction_test.go # ethclient/ethclient.go # ethclient/signer.go # graphql/graphql.go # internal/ethapi/api.go # internal/guide/guide_test.go # les/benchmark.go # les/odr_test.go # light/odr_test.go # light/txpool.go # miner/worker.go # miner/worker_test.go # signer/core/api.go # tests/state_test_util.go # trie/stacktrie_test.go # turbo/stages/blockchain_test.go
2021-02-25 14:26:57 +00:00
)
2014-02-14 22:56:09 +00:00
2015-02-18 15:08:51 +00:00
var (
// ErrKnownBlock is returned when a block to import is already known locally.
ErrKnownBlock = errors.New("block already known")
2014-06-13 10:45:11 +00:00
// ErrBlacklistedHash is returned if a block to import is on the blacklist.
ErrBlacklistedHash = errors.New("blacklisted hash")
all: seperate consensus error and evm internal error (#20830) * all: seperate consensus error and evm internal error There are actually two types of error will be returned when a tranaction/message call is executed: (a) consensus error (b) evm internal error. The former should be converted to a consensus issue, e.g. The sender doesn't enough asset to purchase the gas it specifies. The latter is allowed since evm itself is a blackbox and internal error is allowed to happen. This PR emphasizes the difference by introducing a executionResult structure. The evm error is embedded inside. So if any error returned, it indicates consensus issue happens. And also this PR improve the `EstimateGas` API to return the concrete revert reason if the transaction always fails * all: polish * accounts/abi/bind/backends: add tests * accounts/abi/bind/backends, internal: cleanup error message * all: address comments * core: fix lint * accounts, core, eth, internal: address comments * accounts, internal: resolve revert reason if possible * accounts, internal: address comments # Conflicts: # accounts/abi/abi.go # accounts/abi/bind/backends/simulated.go # cmd/geth/retesteth.go # core/state/snapshot/difflayer_test.go # core/state/snapshot/disklayer_test.go # core/state/snapshot/iterator_test.go # core/state_processor.go # core/state_transition.go # core/vm/evm.go # core/vm/instructions.go # core/vm/jump_table.go # eth/api_tracer.go # internal/ethapi/api.go # les/odr_test.go # light/odr_test.go # tests/state_test_util.go
2020-04-22 08:25:36 +00:00
// ErrNoGenesis is returned when there is no Genesis Block.
ErrNoGenesis = errors.New("genesis not found in chain")
// ErrTipAboveFeeCap is a sanity error to ensure no one is able to specify a
// transaction with a tip higher than the total fee cap.
ErrTipAboveFeeCap = errors.New("tip higher than fee cap")
// ErrTipVeryHigh is a sanity error to avoid extremely big numbers specified
// in the tip field.
ErrTipVeryHigh = errors.New("tip higher than 2^256-1")
// ErrFeeCapVeryHigh is a sanity error to avoid extremely big numbers specified
// in the fee cap field.
ErrFeeCapVeryHigh = errors.New("fee cap higher than 2^256-1")
all: seperate consensus error and evm internal error (#20830) * all: seperate consensus error and evm internal error There are actually two types of error will be returned when a tranaction/message call is executed: (a) consensus error (b) evm internal error. The former should be converted to a consensus issue, e.g. The sender doesn't enough asset to purchase the gas it specifies. The latter is allowed since evm itself is a blackbox and internal error is allowed to happen. This PR emphasizes the difference by introducing a executionResult structure. The evm error is embedded inside. So if any error returned, it indicates consensus issue happens. And also this PR improve the `EstimateGas` API to return the concrete revert reason if the transaction always fails * all: polish * accounts/abi/bind/backends: add tests * accounts/abi/bind/backends, internal: cleanup error message * all: address comments * core: fix lint * accounts, core, eth, internal: address comments * accounts, internal: resolve revert reason if possible * accounts, internal: address comments # Conflicts: # accounts/abi/abi.go # accounts/abi/bind/backends/simulated.go # cmd/geth/retesteth.go # core/state/snapshot/difflayer_test.go # core/state/snapshot/disklayer_test.go # core/state/snapshot/iterator_test.go # core/state_processor.go # core/state_transition.go # core/vm/evm.go # core/vm/instructions.go # core/vm/jump_table.go # eth/api_tracer.go # internal/ethapi/api.go # les/odr_test.go # light/odr_test.go # tests/state_test_util.go
2020-04-22 08:25:36 +00:00
)
// List of evm-call-message pre-checking errors. All state transition messages will
all: seperate consensus error and evm internal error (#20830) * all: seperate consensus error and evm internal error There are actually two types of error will be returned when a tranaction/message call is executed: (a) consensus error (b) evm internal error. The former should be converted to a consensus issue, e.g. The sender doesn't enough asset to purchase the gas it specifies. The latter is allowed since evm itself is a blackbox and internal error is allowed to happen. This PR emphasizes the difference by introducing a executionResult structure. The evm error is embedded inside. So if any error returned, it indicates consensus issue happens. And also this PR improve the `EstimateGas` API to return the concrete revert reason if the transaction always fails * all: polish * accounts/abi/bind/backends: add tests * accounts/abi/bind/backends, internal: cleanup error message * all: address comments * core: fix lint * accounts, core, eth, internal: address comments * accounts, internal: resolve revert reason if possible * accounts, internal: address comments # Conflicts: # accounts/abi/abi.go # accounts/abi/bind/backends/simulated.go # cmd/geth/retesteth.go # core/state/snapshot/difflayer_test.go # core/state/snapshot/disklayer_test.go # core/state/snapshot/iterator_test.go # core/state_processor.go # core/state_transition.go # core/vm/evm.go # core/vm/instructions.go # core/vm/jump_table.go # eth/api_tracer.go # internal/ethapi/api.go # les/odr_test.go # light/odr_test.go # tests/state_test_util.go
2020-04-22 08:25:36 +00:00
// be pre-checked before execution. If any invalidation detected, the corresponding
// error should be returned which is defined here.
//
// - If the pre-checking happens in the miner, then the transaction won't be packed.
// - If the pre-checking happens in the block processing procedure, then a "BAD BLOCk"
// error should be emitted.
var (
// ErrNonceTooLow is returned if the nonce of a transaction is lower than the
// one present in the local chain.
ErrNonceTooLow = errors.New("nonce too low")
// ErrNonceTooHigh is returned if the nonce of a transaction is higher than the
// next one expected based on the local chain.
ErrNonceTooHigh = errors.New("nonce too high")
// ErrNonceMax is returned if the nonce of a transaction sender account has
// maximum allowed value and would become invalid if incremented.
ErrNonceMax = errors.New("nonce has max value")
all: seperate consensus error and evm internal error (#20830) * all: seperate consensus error and evm internal error There are actually two types of error will be returned when a tranaction/message call is executed: (a) consensus error (b) evm internal error. The former should be converted to a consensus issue, e.g. The sender doesn't enough asset to purchase the gas it specifies. The latter is allowed since evm itself is a blackbox and internal error is allowed to happen. This PR emphasizes the difference by introducing a executionResult structure. The evm error is embedded inside. So if any error returned, it indicates consensus issue happens. And also this PR improve the `EstimateGas` API to return the concrete revert reason if the transaction always fails * all: polish * accounts/abi/bind/backends: add tests * accounts/abi/bind/backends, internal: cleanup error message * all: address comments * core: fix lint * accounts, core, eth, internal: address comments * accounts, internal: resolve revert reason if possible * accounts, internal: address comments # Conflicts: # accounts/abi/abi.go # accounts/abi/bind/backends/simulated.go # cmd/geth/retesteth.go # core/state/snapshot/difflayer_test.go # core/state/snapshot/disklayer_test.go # core/state/snapshot/iterator_test.go # core/state_processor.go # core/state_transition.go # core/vm/evm.go # core/vm/instructions.go # core/vm/jump_table.go # eth/api_tracer.go # internal/ethapi/api.go # les/odr_test.go # light/odr_test.go # tests/state_test_util.go
2020-04-22 08:25:36 +00:00
// ErrGasLimitReached is returned by the gas pool if the amount of gas required
// by a transaction is higher than what's left in the block.
ErrGasLimitReached = errors.New("gas limit reached")
// ErrMaxInitCodeSizeExceeded is returned if creation transaction provides the init code bigger
// than init code size limit.
ErrMaxInitCodeSizeExceeded = errors.New("max initcode size exceeded")
all: seperate consensus error and evm internal error (#20830) * all: seperate consensus error and evm internal error There are actually two types of error will be returned when a tranaction/message call is executed: (a) consensus error (b) evm internal error. The former should be converted to a consensus issue, e.g. The sender doesn't enough asset to purchase the gas it specifies. The latter is allowed since evm itself is a blackbox and internal error is allowed to happen. This PR emphasizes the difference by introducing a executionResult structure. The evm error is embedded inside. So if any error returned, it indicates consensus issue happens. And also this PR improve the `EstimateGas` API to return the concrete revert reason if the transaction always fails * all: polish * accounts/abi/bind/backends: add tests * accounts/abi/bind/backends, internal: cleanup error message * all: address comments * core: fix lint * accounts, core, eth, internal: address comments * accounts, internal: resolve revert reason if possible * accounts, internal: address comments # Conflicts: # accounts/abi/abi.go # accounts/abi/bind/backends/simulated.go # cmd/geth/retesteth.go # core/state/snapshot/difflayer_test.go # core/state/snapshot/disklayer_test.go # core/state/snapshot/iterator_test.go # core/state_processor.go # core/state_transition.go # core/vm/evm.go # core/vm/instructions.go # core/vm/jump_table.go # eth/api_tracer.go # internal/ethapi/api.go # les/odr_test.go # light/odr_test.go # tests/state_test_util.go
2020-04-22 08:25:36 +00:00
// ErrInsufficientFunds is returned if the total cost of executing a transaction
// is higher than the balance of the user's account.
ErrInsufficientFunds = errors.New("insufficient funds for gas * price + value")
// ErrGasUintOverflow is returned when calculating gas usage.
ErrGasUintOverflow = errors.New("gas uint64 overflow")
// ErrIntrinsicGas is returned if the transaction is specified to use less gas
// than required to start the invocation.
ErrIntrinsicGas = errors.New("intrinsic gas too low")
all: add support for EIP-2718, EIP-2930 transactions (#21502) This adds support for EIP-2718 typed transactions as well as EIP-2930 access list transactions (tx type 1). These EIPs are scheduled for the Berlin fork. There very few changes to existing APIs in core/types, and several new APIs to deal with access list transactions. In particular, there are two new constructor functions for transactions: types.NewTx and types.SignNewTx. Since the canonical encoding of typed transactions is not RLP-compatible, Transaction now has new methods for encoding and decoding: MarshalBinary and UnmarshalBinary. The existing EIP-155 signer does not support the new transaction types. All code dealing with transaction signatures should be updated to use the newer EIP-2930 signer. To make this easier for future updates, we have added new constructor functions for types.Signer: types.LatestSigner and types.LatestSignerForChainID. This change also adds support for the YoloV3 testnet. Co-authored-by: Martin Holst Swende <martin@swende.se> Co-authored-by: Felix Lange <fjl@twurst.com> Co-authored-by: Ryan Schneider <ryanleeschneider@gmail.com> # Conflicts: # accounts/abi/bind/backends/simulated.go # cmd/evm/internal/t8ntool/execution.go # cmd/evm/internal/t8ntool/transition.go # cmd/geth/main.go # cmd/geth/usage.go # core/bench_test.go # core/state/statedb.go # core/state_prefetcher.go # core/state_processor.go # core/state_transition.go # core/tx_pool.go # core/types/block.go # core/types/derive_sha.go # core/types/gen_tx_json.go # core/types/receipt.go # core/types/receipt_test.go # core/types/transaction.go # core/types/transaction_signing.go # core/types/transaction_test.go # ethclient/ethclient.go # ethclient/signer.go # graphql/graphql.go # internal/ethapi/api.go # internal/guide/guide_test.go # les/benchmark.go # les/odr_test.go # light/odr_test.go # light/txpool.go # miner/worker.go # miner/worker_test.go # signer/core/api.go # tests/state_test_util.go # trie/stacktrie_test.go # turbo/stages/blockchain_test.go
2021-02-25 14:26:57 +00:00
// ErrTxTypeNotSupported is returned if a transaction is not supported in the
// current network configuration.
ErrTxTypeNotSupported = types.ErrTxTypeNotSupported
// ErrFeeCapTooLow is returned if the transaction fee cap is less than the
// the base fee of the block.
ErrFeeCapTooLow = errors.New("fee cap less than block base fee")
// ErrSenderNoEOA is returned if the sender of a transaction is a contract.
// See EIP-3607: Reject transactions from senders with deployed code.
ErrSenderNoEOA = errors.New("sender not an eoa")
)