revm_optimism/transaction/
error.rs

1use core::fmt::Display;
2use revm::context_interface::{
3    result::{EVMError, InvalidTransaction},
4    transaction::TransactionError,
5};
6
7/// Optimism transaction validation error.
8#[derive(Debug, Clone, PartialEq, Eq, Hash)]
9#[cfg_attr(feature = "serde", derive(serde::Serialize, serde::Deserialize))]
10pub enum OpTransactionError {
11    Base(InvalidTransaction),
12    /// System transactions are not supported post-regolith hardfork.
13    ///
14    /// Before the Regolith hardfork, there was a special field in the `Deposit` transaction
15    /// type that differentiated between `system` and `user` deposit transactions. This field
16    /// was deprecated in the Regolith hardfork, and this error is thrown if a `Deposit` transaction
17    /// is found with this field set to `true` after the hardfork activation.
18    ///
19    /// In addition, this error is internal, and bubbles up into a [OpHaltReason::FailedDeposit][crate::OpHaltReason::FailedDeposit] error
20    /// in the `revm` handler for the consumer to easily handle. This is due to a state transition
21    /// rule on OP Stack chains where, if for any reason a deposit transaction fails, the transaction
22    /// must still be included in the block, the sender nonce is bumped, the `mint` value persists, and
23    /// special gas accounting rules are applied. Normally on L1, [EVMError::Transaction] errors
24    /// are cause for non-inclusion, so a special [OpHaltReason][crate::OpHaltReason] variant was introduced to handle this
25    /// case for failed deposit transactions.
26    DepositSystemTxPostRegolith,
27    /// Deposit transaction haults bubble up to the global main return handler, wiping state and
28    /// only increasing the nonce + persisting the mint value.
29    ///
30    /// This is a catch-all error for any deposit transaction that is results in a [OpHaltReason][crate::OpHaltReason] error
31    /// post-regolith hardfork. This allows for a consumer to easily handle special cases where
32    /// a deposit transaction fails during validation, but must still be included in the block.
33    ///
34    /// In addition, this error is internal, and bubbles up into a [OpHaltReason::FailedDeposit][crate::OpHaltReason::FailedDeposit] error
35    /// in the `revm` handler for the consumer to easily handle. This is due to a state transition
36    /// rule on OP Stack chains where, if for any reason a deposit transaction fails, the transaction
37    /// must still be included in the block, the sender nonce is bumped, the `mint` value persists, and
38    /// special gas accounting rules are applied. Normally on L1, [EVMError::Transaction] errors
39    /// are cause for non-inclusion, so a special [OpHaltReason][crate::OpHaltReason] variant was introduced to handle this
40    /// case for failed deposit transactions.
41    HaltedDepositPostRegolith,
42}
43
44impl TransactionError for OpTransactionError {}
45
46impl Display for OpTransactionError {
47    fn fmt(&self, f: &mut core::fmt::Formatter<'_>) -> core::fmt::Result {
48        match self {
49            Self::Base(error) => error.fmt(f),
50            Self::DepositSystemTxPostRegolith => {
51                write!(
52                    f,
53                    "deposit system transactions post regolith hardfork are not supported"
54                )
55            }
56            Self::HaltedDepositPostRegolith => {
57                write!(
58                    f,
59                    "deposit transaction halted post-regolith; error will be bubbled up to main return handler"
60                )
61            }
62        }
63    }
64}
65
66impl core::error::Error for OpTransactionError {}
67
68impl From<InvalidTransaction> for OpTransactionError {
69    fn from(value: InvalidTransaction) -> Self {
70        Self::Base(value)
71    }
72}
73
74impl<DBError> From<OpTransactionError> for EVMError<DBError, OpTransactionError> {
75    fn from(value: OpTransactionError) -> Self {
76        Self::Transaction(value)
77    }
78}