-
Notifications
You must be signed in to change notification settings - Fork 0
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
Re-implement the blob tx parser in a lower-level style #7
Conversation
1da40bc
to
2136e4d
Compare
f60f47c
to
e29d808
Compare
…necessary byte copying.
e29d808
to
24538dd
Compare
func (s wrapperKzgSequence) At(i int) eth.KZGCommitment { | ||
kzg := eth.KZGCommitment{} | ||
if i >= s.num { | ||
return kzg |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we return a reference for the function? this way you can return nil and make it easier for caller to distinguish return?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this is part of the interface expected by the eth. library in go-kzg -- it's idiomatic in geth code at least to always pass small fixed length arrays like these by value.
@@ -80,6 +79,28 @@ func NewTxParseContext(chainID uint256.Int) *TxParseContext { | |||
return ctx | |||
} | |||
|
|||
// recover sender address after appropriately populating ctx.Sighash, ctx.R & ctx.S | |||
func (ctx *TxParseContext) RecoverSender(vByte byte, sender []byte) error { | |||
binary.BigEndian.PutUint64(ctx.Sig[0:8], ctx.R[3]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
curious about the general encoding choices, I saw both LittleEndian & BigEndian used, is that right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately yes.. ssz uses the opposite of RLP/legacy encoding.
…necessary byte copying. (#7)
…necessary byte copying. (#7)
…necessary byte copying. (#7)
…necessary byte copying. (#7)
This implementation is more consistent with the existing parsing code: it avoids instantiating new objects and instead grabs data directly from the payload buffer as needed.