[Feature] Constructor in primitive data type traits (TxReceipt
, TransactionResponse
, etc.)
#1315
Labels
debt
Tech debt which needs to be addressed
Component
node-bindings
Describe the feature you would like
Op-reth, will always have the problem with the primitive data types, that it won't be able to implement any conversions from reth/op-reth types to op-alloy types, on the op-alloy type directly. Another type must always be defined in op-reth, and added to the node at sdk level, i.e. generalised (for reth too). That means, each primitive data type added at sdk level, must be paired with a new conversion type. This gets quite heavy to maintain! And is only useful for rollups that have its primitive data types implemented in a different crate than the node components (like op-reth and op-alloy).
This also applies for conversions from op-alloy types to other op-alloy types in reth/op-reth, when the only view of them that reth/op-reth sees, is through the alloy primitive traits (e.g.
TxReceipt
,TransactionResponse
, etc.)The goal:
We want to add a trait bound at sdk level for conversion from reth/op-reth type:
NodePrimitives::Transaction: From<TransactionSigned<T>>
.The problem:
TransactionSigned<T>
is a reth type. We can't import it into op-alloy to implement the conversion.NodePrimitives::Transaction: FromTransactionSigned
, then we have the next problem.FromTransactionSigned
can only be implemented on foreign types (op-alloy) in the crate it is defined - but then we would be importing op-alloy types into reth, that's the opposite of what we want!NodePrimitives::Transaction
like this. We would need it on a new associated typeNodePrimitives::TransactionCompat: TransactionSignedToRpcConverter
(or as associated type on some reth component).NodePrimitives::TransactionCompat
can be defined in op-reth. However, the decoupling of a type from its constructor, gets very complex, since the reth/op-reth node builder already has a bunch of components as associated types to keep track of.The solution:
Move primitive data type construction into alloy primitive traits.
For example
TransactionResponse
, can be updated toor, more granular generics for guidance, without loss of generality (ref #1173 (review))
Additional context
No response
The text was updated successfully, but these errors were encountered: