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}