Tx: Small fixes and improvements #1144
Conversation
…axInteger)` to `_validateCannotExceedMaxInteger(values)`
Codecov Report
Flags with carried forward coverage won't be shown. Click here to find out more. |
ryanio
force-pushed
the
tx-followup-work
branch
from
b50614b
to
405cadf
Compare
| this.transactions.map((tx) => <Buffer[]>tx.raw()), | ||
| this.transactions.map((tx) => | ||
| 'transactionType' in tx && tx.transactionType > 0 ? tx.serialize() : tx.raw() | ||
| ) as Buffer[], |
There was a problem hiding this comment.
Yes, this makes sense. I think this is the right thing to do to get the whole raw and serialized data setup consistent again and avoid this unlucky splitting of the tx.raw() method.
We just should be aware here that this introduces another tx type induced version dependency between the libraries, so block serialization will now be wrong when an old block version is used upon a tx-type-containing tx release (but so be it).
I guess we minimally need to communicate the set of library versions to be used when using typed txs very clearly if we want to stay in the minor release realm (as we've done with the clique changes, these were still a bit better encapsulated by the Common consensusType setting though). 🤔
//cc @cgewecke
|
Argh. Accidentally hit the "close" button and need to wait for the tests again. 😛 |
This PR applies a few small fixes and improvements to the new tx library with EIP2718 and 2930 support:
AccessListEIP2930Transaction- removesasListparameter inraw(), preferring to useserialize()TransactionFactory- for clarity, renamesfromRawDatatofromSerializedData_validateExceedsMaxInteger(validateCannotExceedMaxInteger)to_validateCannotExceedMaxInteger(values)fromRlpSerializedTxtofromSerializedTxcommon.copy()for easier deep copy functionality.