[ETCM-1095] eip2930 receipt #1103
Conversation
strauss-m
changed the title
strauss-m
force-pushed
the
feature/etcm-1095_eip2930_receipt
branch
2 times, most recently
from
b72c25d to
9b04b42
Compare
strauss-m
force-pushed
the
feature/etcm-1095_eip2930_receipt
branch
3 times, most recently
from
2a33d1f to
770f806
Compare
| } | ||
|
|
||
| implicit class TransactionTypeValidator(val transactionType: Byte) extends AnyVal { | ||
| def isValidTransactionType: Boolean = transactionType >= MinAllowedType && transactionType <= MaxAllowedType |
There was a problem hiding this comment.
I'm not really a big fan of implicit conversion if we can avoid it because it can be surprising where it is used. Also, currently only Type01 is allowed. Wouldn't it be more safe to just allow that for now ?
Or maybe we can move that to the encoding/networking part because the fact that a transaction type is encoded as a number from 0 to 0x7f is not really relevant in the domain. We can have transaction types as an enumeration to make it impossible to have an invalid transaction type in the domain part, and let the networking part make the conversion.
There was a problem hiding this comment.
I agree with the TransactionType enum:
- only check when decoding RLP data
- easier validation (transactionTypeByte is one of enum values)
As for the validation not being currently restricted to type01, I got two choices:
- current implementation: can accept un-handled transaction type, but don't need to change for new transaction
- proposed implementation: only valid for supported transaction types, but need to be updated for every new transaction
Your version seems more safe.
strauss-m
force-pushed
the
feature/etcm-1095_eip2930_receipt
branch
from
771aa72 to
b511815
Compare
strauss-m
force-pushed
the
feature/etcm-1095_eip2930_receipt
branch
from
b511815 to
971c033
Compare
Description
Introduce Receipt for Type 01 transactions
Proposed Solution
Type 01 receipt content is the same than legacy ones, but prefixed with the transaction type byte