Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add tipping tx subtype #260

Closed
wants to merge 41 commits into from
Closed

Add tipping tx subtype #260

wants to merge 41 commits into from

Conversation

magicxyyz
Copy link
Contributor

@magicxyyz magicxyyz commented Oct 2, 2023

  • adds new transaction type which allows creating new subtypes of the transaction (ArbitrumSubtypedTx)
  • adds new transaction subtype that wraps DynamicFeeTx and supports collection of the priority fee (ArbitrumTippingTx)

@cla-bot cla-bot bot added the s CLA signed label Oct 2, 2023
core/types/transaction.go Outdated Show resolved Hide resolved
@magicxyyz magicxyyz requested a review from PlasmaPower January 9, 2024 04:05
Copy link
Contributor

@tsahee tsahee left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a few cpmments.
overall - looking good

}

func (tx *ArbitrumSubtypedTx) txType() byte { return ArbitrumSubtypedTxType }
func (tx *ArbitrumSubtypedTx) TxSubtype() byte { return tx.TxData.txType() }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I get it but I still find it kind of confusing and a room for error..
could we add a separate subtype field in SubtypedTx and use that?

Copy link
Contributor Author

@magicxyyz magicxyyz Jan 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be great to keep the subtype a constant, but adding a field invalidates the property

Maybe I should add a func (tx *ArbitrumSubtypedTx) SubTx() TxData method, and then we'd use it this way: tx.SubTx().Type(), would it be better?

core/types/transaction.go Outdated Show resolved Hide resolved
@@ -244,6 +244,10 @@ func (tx *Transaction) decodeTyped(b []byte, arbParsing bool) (TxData, error) {
var inner BlobTx
err := rlp.DecodeBytes(b[1:], &inner)
return &inner, err
case ArbitrumSubtypedTxType:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this belongs a few lines up - under
if arbParsing

Copy link
Contributor Author

@magicxyyz magicxyyz Jan 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we need to parse ArbitrumSubtypedTxType even when arbParsing is false to be able to decode binary encoding with UnmarshalBinary to support SendRawTransaction and SendRawTransactionConditional. If we don't want to support it, then we probably need to add custom RPC method to allow sending subtyped txes (?).

core/types/transaction_marshalling.go Outdated Show resolved Hide resolved
@@ -48,6 +48,7 @@ type txJSON struct {
YParity *hexutil.Uint64 `json:"yParity,omitempty"`

// Arbitrum fields:
Subtype *hexutil.Uint64 `json:"subtype,omitempty"` // ArbitrumSubtypedTx
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why uint64 and not byte?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. to make it consistent with type of "type" field which is also hexutil.Uint64
  2. there's no hexutil.Byte, and hexautil.Uint64 does all format checking and decoding from string

core/types/transaction_marshalling.go Outdated Show resolved Hide resolved
core/types/transaction_marshalling.go Outdated Show resolved Hide resolved
internal/ethapi/api.go Show resolved Hide resolved
case *ArbitrumSubtypedTx:
switch inner.TxData.(type) {
case *ArbitrumTippingTx:
V, R, S := tx.RawSignatureValues()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

3 options, I'm o.k. with any:

  1. add a comment that this comes from london signer as these are assentially DynamicFeeTxType
  2. create a fake DynamicFeeTx and use the internal signer, similar to ArbitrumLegacyTx
  3. separate the code that extract the sender inside london-signer (without checking tx type), call this func from both london signer after checking type and from here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2 - we can't make fake DynamicFeeTx and pass it to londonSigner because Hash method must be called on arbitrumSigner to include transaction subtype in hashed data
3 - probably would create some unnecessary merge conflicts against upstream

so I went with 1 and added a comment.

In SignatureValues method I used the fake tx pattern, as there it was possible.

@magicxyyz magicxyyz requested a review from tsahee January 13, 2024 02:13
@magicxyyz magicxyyz marked this pull request as draft November 18, 2024 13:46
@magicxyyz
Copy link
Contributor Author

we went with a different approach for now

@magicxyyz magicxyyz closed this Nov 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
s CLA signed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants