Open
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #3566 +/- ##
==========================================
+ Coverage 75.76% 75.84% +0.08%
==========================================
Files 386 380 -6
Lines 33748 33713 -35
==========================================
+ Hits 25569 25571 +2
+ Misses 6394 6361 -33
+ Partials 1785 1781 -4 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
dc3b80b to
b7e166b
Compare
Move `Base64` from `utils/base64.go` to `core/transaction.go`, closer to its semantic home as a Starknet transaction wire-format type. Drop the custom `MarshalJSON`/`UnmarshalJSON` methods — they were functionally identical to the default encoding/json behavior for named string types. Also drop the `RegisterCustomTypeFunc(core.Base64)` blocks in the v8, v9, and v10 validators. The go-playground/validator `base64` tag applies natively to named string types (`reflect.Kind() == String`), so the registration was redundant. In v8 and v9 the registration was doubly dead since no field of that type exists in those packages. Updates the 8 call sites in mempool, p2p2mempool adapter, and the v8/v9/v10 RPC validators and transaction types accordingly.
Move `BlockSignFunc` from `utils/sign.go` to `core/block.go`, and move the signer factory to `sequencer/sequencer_utils.go` as the unexported `newBlockSigner` — the sequencer is the only creator; every other package just consumes the type. Update the consumers in `builder`, `blockchain`, and `blockchain/statebackend` accordingly, and delete `utils/sign.go`. While relocating, fix a pre-existing bug in the signer: the chunking loop sliced `signatureBytes[start:step]` instead of `[start:start+step]`, so the second iteration read an empty slice ([32:32]) and produced a zero felt in place of the S component of the signature. For a 64-byte stark-curve ECDSA signature the result was always `[R, 0]` — the signature was malformed and would fail verification. Replace the loop with a direct two-felt construction since the signature size is fixed at the algorithm level. Strengthen the unit test to reconstruct the signature and round-trip it through `PublicKey.Verify`, which catches this exact class of bug.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Related to #1198
A refactor in the 'log' and 'network' files will be made in follow-up PRs.
Cleanup of the
utils/package: move domain types closer to their semantic homes, replace small wrappers with stdlib equivalents, and remove dead code.Relocated
utils.DataSize+ byte-size constants (Kilobyte,Megabyte, …) →db/utils.Base64→core/transaction.go. Dropped redundantMarshalJSON/UnmarshalJSONmethods — they were functionally identical to the default encoding/json behavior for named string types. Also dropped theRegisterCustomTypeFunc(Base64)blocks in the v8/v9/v10 validators: thevalidate:"base64"tag applies natively to named string types (in v8/v9 the type wasn't even used — doubly dead code).BlockSignFunc→core/block.go;Sign→sequencer/as unexportednewBlockSigner. The sequencer is the only creator; other consumers (builder, blockchain, statebackend) only need the type.NonNilSlice/DerefSliceconsolidated intoutils/slices.go.Replaced with stdlib / language builtins
utils.RunAndWrapOnError(fn, err)→errors.Join(err, fn())at 28 call sites.errors.Joinis strictly better: it preserves both errors forerrors.Is/errors.As(the old impl used%von the run error, making it unreachable viaUnwrap). Here are some tests comparing both: ref.utils.HeapPtr(x)→ Go 1.26'snew(x)(now accepts expressions).utils.Map(s, utils.HeapPtr[T])→ newutils.ToPtrSlice(s)helper (7 call sites in RPC trace adapters).utils.ToHex(*big.Int)→fmt.Sprintf("0x%x", …).github.com/pkg/errorsdependency in favor of stdliberrors.Join.Deleted
utils/bigint.go,utils/const.go,utils/zero_value.go,utils/maps.go(unusedToMap/ToSlice), and the now-emptyutils/wrap.go,utils/sign.go,utils/base64.go.Incidental bug fix (sequencer block signer) - Me & my friend Claude Code
While relocating
Sign, it was noticed that the signature-chunking loop slicedsignatureBytes[start:step]instead of[start:start+step]. For a 64-byte stark-curve ECDSA signature (felt.Bytes = 32), the second iteration readsignatureBytes[32:32]— an empty slice — so theScomponent was silently dropped and replaced withfelt(0). Every block signature produced by the sequencer was malformed and would fail cryptographic verification.The loop was replaced with a direct two-felt construction (signature size is fixed at the algorithm level) and the test was strengthened to reconstruct the signature and round-trip it through
PublicKey.Verify.