Support transaction extensions that authorize over the inherited implication

Aperta
  • Qualcosa non va?
#2,295 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

@TarikGul ci sta già lavorando.

Dal 27/10/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

Context

FRAME passes every transaction extension an inherited implication: the extension version, the call, the explicit values of every extension after it, then their implicit values. Authorization extensions like pallet_people::AsPerson prove over its hash instead of carrying a signature, and require a None origin, so they appear in V5 general transactions next to a disabled VerifyMultiSignature.

paritytech/frame-decode#110 asks frame-decode to expose that implication. subxt cannot build these transactions yet. custom_extension takes a fixed scale_value::Value and never authorizes (#2276), a custom Config still cannot see the implication, and signing always injects a signature into VerifyMultiSignature.

What I'd like
  1. Bump frame-decode and forward its implication support through DefaultTransactionExtensions and subxt's own extensions, since the set routes by name and would otherwise drop it.
  2. Compute implication based values once per build and keep them on SignableTransaction, so the signer payload and the submitted transaction carry identical bytes. Ring proofs are randomized, so computing them twice breaks the signature.
  3. A two step path next to signer_payload and sign_with_account_and_signature: get the implication for a named extension, then inject its value. Proofs often come from a device or a remote prover, the same reason signing works this way today.
  4. A way to build a V5 general transaction with VerifyMultiSignature disabled, so an extension like AsPerson can be the only authorizer.
  5. A way for a chain to add a typed extension next to the defaults without rewriting the default tuple, for example DefaultTransactionExtensions<T, Extra = ()> named in its Config. Open to a closure based slot instead.
  6. Let those typed extensions report is_authorization_extension once the signer payload cut follows the signing extension, which addresses #2276 for typed extensions. Values from custom_extension stay non authorizing.
Compatibility

Additive. Transactions that use none of this encode exactly as they do now.

Lingua principale
Rust
Stelle
490
Fork
288
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di paritytech/subxt

Tutte le issue di paritytech/subxt

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.