Skip to content

feat(server): support Extrinsic V5 transaction signing - #333

Draft
pgherveou wants to merge 2 commits into
mainfrom
verify/v5-local-stack
Draft

feat(server): support Extrinsic V5 transaction signing#333
pgherveou wants to merge 2 commits into
mainfrom
verify/v5-local-stack

Conversation

@pgherveou

Copy link
Copy Markdown
Collaborator

Summary

  • Accept txExtVersion: 5 in the local signing host while preserving the existing V4 path.
  • Resolve the runtime call and transaction-extension pipeline from metadata through Subxt.
  • Delegate V5 signer-implication and General-extrinsic encoding to frame-decode, with Subxt VerifySignature providing the authorization boundary.
  • Keep only the TrUAPI-specific adapters for caller-supplied SCALE fields and product-account signing.
  • Exercise both V4 and V5 transaction creation in the generated CLI example.

Root cause

The local transaction builder only implemented V4 and rejected every other transaction version at the signing-host gate. V5 also cannot reuse the V4 signer payload: FRAME keeps (transaction_extension_version, call) as an immutable base implication, while VerifyMultiSignature excludes only extension implications that precede it. The frame-decode API previously lost that base when applying the authorization boundary.

This PR consumes the corrected frame-decode semantics through Subxt instead of reproducing the metadata-sensitive implication and encoding logic in TrUAPI.

Dependency chain

  1. Depends on fix!: preserve V5 base implication in signer payloads frame-decode#104.
  2. Depends on build(deps): update frame-decode to 0.18.0 subxt#2268, which updates Subxt to frame-decode 0.18.0.
  3. This PR is the TrUAPI integration layer.

The draft uses immutable Git revisions for both upstream changes so the complete stack can be reviewed and tested before publication. Before merge, replace those pins with published crate versions and refresh Cargo.lock in normal follow-up commits. Keep this PR in draft until both upstream releases are available.

Conformance references

The signer implication follows FRAME TxBaseImplication / ImplicationParts and VerifyMultiSignature semantics documented and linked in paritytech/frame-decode#104. That PR also cross-checks the V5 wire format against PAPI main and the complete implication pipeline against the production substrate-sdk-ios implementation used by polkadot-app-ios-v2.

The focused TrUAPI regression independently constructs the expected blake2_256(extension_version || call || explicit_suffix || implicit_suffix), verifies the embedded product-account signature, and proves that it does not verify against the former call-cleared payload.

Validation

  • cargo fmt --all -- --check
  • cargo check -p truapi-server
  • cargo test -p truapi-server — 417 unit tests plus all integration, wire-shape, and Rust/TypeScript parity tests pass
  • ./scripts/codegen.sh
  • generated examples: npm run typecheck:examples
  • V4/V5 generated example: ESLint passes
  • CLI signing battery entry for Signing/create_transaction: V4 and V5 both pass; V5 produces a General extrinsic with inner prefix 0x45 00

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant