FRAME: Reintroduce `TransactionExtension` as a replacement for `SignedExtension` #3685

georgepisaltu · 2024-03-13T19:39:08Z

Original PR #2280 reverted in #3665

This PR reintroduces the reverted functionality with additional changes, related effort here. Description is copied over from the original PR

First part of Extrinsic Horizon

Introduces a new trait TransactionExtension to replace SignedExtension. Introduce the idea of transactions which obey the runtime's extensions and have according Extension data (né Extra data) yet do not have hard-coded signatures.

Deprecate the terminology of "Unsigned" when used for transactions/extrinsics owing to there now being "proper" unsigned transactions which obey the extension framework and "old-style" unsigned which do not. Instead we have General for the former and Bare for the latter. (Ultimately, the latter will be phased out as a type of transaction, and Bare will only be used for Inherents.)

Types of extrinsic are now therefore:

Bare (no hardcoded signature, no Extra data; used to be known as "Unsigned")
- Bare transactions (deprecated): Gossiped, validated with ValidateUnsigned (deprecated) and the _bare_compat bits of TransactionExtension (deprecated).
- Inherents: Not gossiped, validated with ProvideInherent.
Extended (Extra data): Gossiped, validated via TransactionExtension.
- Signed transactions (with a hardcoded signature).
- General transactions (without a hardcoded signature).

TransactionExtension differs from SignedExtension because:

A signature on the underlying transaction may validly not be present.
It may alter the origin during validation.
pre_dispatch is renamed to prepare and need not contain the checks present in validate.
validate and prepare is passed an Origin rather than a AccountId.
validate may pass arbitrary information into prepare via a new user-specifiable type Val.
AdditionalSigned/additional_signed is renamed to Implicit/implicit. It is encoded for the entire transaction and passed in to each extension as a new argument to validate. This facilitates the ability of extensions to acts as underlying crypto.

There is a new DispatchTransaction trait which contains only default function impls and is impl'ed for any TransactionExtension impler. It provides several utility functions which reduce some of the tedium from using TransactionExtension (indeed, none of its regular functions should now need to be called directly).

Three transaction version discriminator ("versions") are now permissible (RFC here) in extrinsic version 5:

0b00000101: Bare (used to be called "Unsigned"): contains Signature or Extra (extension data). After bare transactions are no longer supported, this will strictly identify an Inherents only.
0b10000101: Old-school "Signed" Transaction: contains Signature, Extra (extension data) and an extension version byte, introduced as part of RFC99.
0b01000101: New-school "General" Transaction: contains Extra (extension data) and an extension version byte, as per RFC99, but no Signature.

For the New-school General Transaction, it becomes trivial for authors to publish extensions to the mechanism for authorizing an Origin, e.g. through new kinds of key-signing schemes, ZK proofs, pallet state, mutations over pre-authenticated origins or any combination of the above.

UncheckedExtrinsic still maintains encode/decode backwards compatibility with extrinsic version 4, where the first byte was encoded as:

0b00000100 - Unsigned transactions
0b10000100 - Old-school Signed transactions, without the extension version byte

Code Migration

NOW: Getting it to build

Wrap your SignedExtensions in AsTransactionExtension. This should be accompanied by renaming your aggregate type in line with the new terminology. E.g. Before:

/// The SignedExtension to the basic transaction logic.
pub type SignedExtra = (
	/* snip */
	MySpecialSignedExtension,
);
/// Unchecked extrinsic type as expected by this runtime.
pub type UncheckedExtrinsic =
	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, SignedExtra>;

After:

/// The extension to the basic transaction logic.
pub type TxExtension = (
	/* snip */
	AsTransactionExtension<MySpecialSignedExtension>,
);
/// Unchecked extrinsic type as expected by this runtime.
pub type UncheckedExtrinsic =
	generic::UncheckedExtrinsic<Address, RuntimeCall, Signature, TxExtension>;

You'll also need to alter any transaction building logic to add a .into() to make the conversion happen. E.g. Before:

fn construct_extrinsic(
		/* snip */
) -> UncheckedExtrinsic {
	let extra: SignedExtra = (
		/* snip */
		MySpecialSignedExtension::new(/* snip */),
	);
	let payload = SignedPayload::new(call.clone(), extra.clone()).unwrap();
	let signature = payload.using_encoded(|e| sender.sign(e));
	UncheckedExtrinsic::new_signed(
		/* snip */
		Signature::Sr25519(signature),
		extra,
	)
}

After:

fn construct_extrinsic(
		/* snip */
) -> UncheckedExtrinsic {
	let tx_ext: TxExtension = (
		/* snip */
		MySpecialSignedExtension::new(/* snip */).into(),
	);
	let payload = SignedPayload::new(call.clone(), tx_ext.clone()).unwrap();
	let signature = payload.using_encoded(|e| sender.sign(e));
	UncheckedExtrinsic::new_signed(
		/* snip */
		Signature::Sr25519(signature),
		tx_ext,
	)
}

SOON: Migrating to `TransactionExtension`

Most SignedExtensions can be trivially converted to become a TransactionExtension. There are a few things to know.

Instead of a single trait like SignedExtension, you should now implement two traits individually: TransactionExtensionBase and TransactionExtension.
Weights are now a thing and must be provided via the new function fn weight.

`TransactionExtensionBase`

This trait takes care of anything which is not dependent on types specific to your runtime, most notably Call.

AdditionalSigned/additional_signed is renamed to Implicit/implicit.
Weight must be returned by implementing the weight function. If your extension is associated with a pallet, you'll probably want to do this via the pallet's existing benchmarking infrastructure.

`TransactionExtension`

Generally:

pre_dispatch is now prepare and you should not reexecute the validate functionality in there!
You don't get an account ID any more; you get an origin instead. If you need to presume an account ID, then you can use the trait function AsSystemOriginSigner::as_system_origin_signer.
You get an additional ticket, similar to Pre, called Val. This defines data which is passed from validate into prepare. This is important since you should not be duplicating logic from validate to prepare, you need a way of passing your working from the former into the latter. This is it.
This trait takes a Call type parameter. Call is the runtime call type which used to be an associated type; you can just move it to become a type parameter for your trait impl.
There's no AccountId associated type any more. Just remove it.

Regarding validate:

You get three new parameters in validate; all can be ignored when migrating from SignedExtension.
validate returns a tuple on success; the second item in the tuple is the new ticket type Self::Val which gets passed in to prepare. If you use any information extracted during validate (off-chain and on-chain, non-mutating) in prepare (on-chain, mutating) then you can pass it through with this. For the tuple's last item, just return the origin argument.

Regarding prepare:

This is renamed from pre_dispatch, but there is one change:
FUNCTIONALITY TO VALIDATE THE TRANSACTION NEED NOT BE DUPLICATED FROM validate!!
(This is different to SignedExtension which was required to run the same checks in pre_dispatch as in validate.)

Regarding post_dispatch:

Since there are no unsigned transactions handled by TransactionExtension, Pre is always defined, so the first parameter is Self::Pre rather than Option<Self::Pre>.

If you make use of SignedExtension::validate_unsigned or SignedExtension::pre_dispatch_unsigned, then:

Just use the regular versions of these functions instead.
Have your logic execute in the case that the origin is None.
Ensure your transaction creation logic creates a General Transaction rather than a Bare Transaction; this means having to include all TransactionExtensions' data.
ValidateUnsigned can still be used (for now) if you need to be able to construct transactions which contain none of the extension data, however these will be phased out in stage 2 of the Transactions Horizon, so you should consider moving to an extension-centric design.

Signed-off-by: georgepisaltu <[email protected]>

… for `SignedExtension` (#2280)" (#3665)" This reverts commit bbd51ce.

Signed-off-by: georgepisaltu <[email protected]>

…tx-ext

Signed-off-by: georgepisaltu <[email protected]>

georgepisaltu · 2024-09-13T17:39:26Z

bot cancel 5-478ae05b-f12d-4078-a562-184d6fbfbb48

command-bot · 2024-09-13T17:39:34Z

@georgepisaltu Command "$PIPELINE_SCRIPTS_DIR/commands/bench-all/bench-all.sh" --target_dir=substrate has finished. Result: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7344421 has finished. If any artifacts were generated, you can download them from https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7344421/artifacts/download.

georgepisaltu · 2024-09-13T18:01:27Z

bot bench-all substrate

command-bot · 2024-09-13T18:01:32Z

@georgepisaltu https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7346730 was started for your command "$PIPELINE_SCRIPTS_DIR/commands/bench-all/bench-all.sh" --target_dir=substrate. Check out https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/pipelines?page=1&scope=all&username=group_605_bot to know what else is being executed currently.

Comment bot cancel 2-5d79bfe9-88ee-4d07-b1ec-c76f92205de0 to cancel this command or bot cancel to cancel all commands in this pull request.

command-bot · 2024-09-13T23:41:26Z

@georgepisaltu Command "$PIPELINE_SCRIPTS_DIR/commands/bench-all/bench-all.sh" --target_dir=substrate has finished. Result: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7346730 has finished. If any artifacts were generated, you can download them from https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/7346730/artifacts/download.

bkchr

Still did not reviewed everything. However, wanting to give you this feedback already to give you time to fix them.

There are a lot of comments that you don't have addressed, from other peoples before. This needs to be done!

I found some extensions which are still written incorrectly, basically rejecting any kid of tx that is not using a system origin.

Cargo.lock

substrate/primitives/runtime/src/traits/transaction_extension/mod.rs

substrate/frame/sudo/src/benchmarking.rs

substrate/frame/transaction-payment/asset-tx-payment/src/lib.rs

substrate/frame/transaction-payment/src/benchmarking.rs

substrate/primitives/runtime/src/traits/transaction_extension/mod.rs

bkchr · 2024-09-17T20:35:13Z

substrate/primitives/runtime/src/traits/mod.rs

+/// Interface to differentiate between Runtime Origins authorized to include a transaction into the
+/// block, and those who aren't.
+///
+/// Typically, upon validation or application of a transaction, the origin resulting from the
+/// transaction extension (see [`TransactionExtension`]) is checked for authorization. Transaction
+/// is then rejected or applied.
+///
+/// In FRAME, an authorized origin is either an `Origin::Signed` System origin or a custom origin
+/// authorized in a `TransactionExtension`.
+pub trait AsAuthorizedOrigin {
+	/// Whether the origin is authorized to include the transaction in a block.
+	///
+	/// In FRAME returns `false` if the origin is a System `Origin::None` variant, `true` otherwise,
+	/// meaning only signed or custom origin resulting from the transaction extension pipeline are
+	/// authorized.
+	fn is_authorized(&self) -> bool;
+}


Do we really need this? Maybe just using Option or a custom enum to represent the initial origin and then at the end just check if this was set?

Yes because at the substrate primitives level where TransactionExtension is defined, there is no concept of what an origin is, it's just a type. This trait is the way to differentiate between what the implementer decides is the "default" origin for their substrate runtime (if they're using a frame_system based runtime, it will probably be frame_system::RawOrigin::None BUT not necessarily). frame_system and frame_support are at a higher level in terms of dependency and we can't use concepts in those crates. As you can see in the VerifyMultiSignature implementation now, this trait is useful.

Yeah, but as I said the initial origin could just be a None? This way, the origin can stay generic and we don't need this trait. Or what do I miss?

I see one drawbacks in using Option<Origin>, transaction extensions can't add stuff on the origin prior to mutate it to an authorized origin.

Like an extension adding some filter.
Or if Origin type get more complex, some additional information on the origin.

That said such extension could always be put after authorizing transaction extensions in the pipeline.
So Option<Origin> is also ok to me.

I think Option<Origin> is redundant because all origin types used in practice, including frame_system as well as downstream custom ones, must have a value equivalent to "no origin" already. This would just introduce a "no origin for extension" (None) and then possibly a "no origin for call" (Some(frame_system::RawOrigin::None)).

In addition to what @gui1117 said, it's just more overhead for people writing extensions because it's explicit in the fn arguments and you have to "unwrap" it all the time and then get your relevant origin. With the trait, the impl is done once and you call it only if you care about this origin being authorized or not. Also, the trait allows users to have more origin values that are not authorized, or values that are authorized only in certain conditions, it's only limited by the trait impl.

Since the origin itself is a generic type, it makes sense we'd have a unifying interface for determining what's authorized and what's not. The trait is simple, the docs are clear, the impl is done for you and you bring it in context only if you use it, I don't see why not use this.

When we remove ValidateUnsigned we get: bare and general extrinsics start with frame system none origin. Bare extrinsics are only inherents, so they are inherently valid, and nodes include them into a block.
General extrinsics needs to be authorized to be valid and get into a block.

Seems coherent.

EDIT: I agree AsAuthorizedOrigin trait is not so much more complicated and probably more future proof.

…extension PR (#5440) * rename metadata stuff from `additional_signed` to `implicit` (doesn't break metadata, only temporary representation in the code) * removed some unused associated type `SignaturePayload` * remove `From<u64>` from transaction payment transaction extension * remove `TransactionExtensionBase`, merged into `TransactionExtension` --------- Co-authored-by: georgepisaltu <[email protected]>

Signed-off-by: georgepisaltu <[email protected]>

…tx-ext Signed-off-by: georgepisaltu <[email protected]>

Signed-off-by: georgepisaltu <[email protected]>

…tx-ext

georgepisaltu · 2024-09-18T17:02:22Z

There are a lot of comments that you don't have addressed, from other peoples before.

I think everything from other reviewers (so far) has been addressed now.

I found some extensions which are still written incorrectly, basically rejecting any kid of tx that is not using a system origin.

As outlined in other comments on the issue, I thought that we would merge this PR without support for "other" custom origins and we would add support for that later. We are not currently using this in our codebase and we will only when we merge phase 2 of Extrinsic Horizon, but regardless I will work on allowing custom origins in all these extensions because it shouldn't be a problem now that we reject transactions without an origin by default.

bkchr · 2024-09-18T20:53:12Z

but regardless I will work on allowing custom origins in all these extensions because it shouldn't be a problem now that we reject transactions without an origin by default.

IMO, if we touch the code now any way and rewrite them as transaction extension, we should make them work properly. Otherwise we will miss them later.

cumulus/parachains/runtimes/starters/shell/src/lib.rs

polkadot/runtime/common/src/claims.rs

substrate/test-utils/runtime/src/lib.rs

substrate/test-utils/runtime/src/extrinsic.rs

substrate/frame/support/procedural/src/construct_runtime/expand/metadata.rs

substrate/primitives/runtime/src/testing.rs

substrate/primitives/runtime/src/generic/unchecked_extrinsic.rs

gui1117 · 2024-09-19T02:15:05Z

substrate/primitives/runtime/src/generic/unchecked_extrinsic.rs

-	pub fn new_unsigned(function: Call) -> Self {
-		Self { signature: None, function }
+	/// Returns `true` if this extrinsic instance is an inherent, `false`` otherwise.
+	pub fn is_inherent(&self) -> bool {


For the record this naming is not meaningful until we remove ValidateUnsigned.

We could name it is_bare during the transition period. But it is also ok to use the final naming.

gui1117 · 2024-09-19T02:26:52Z

substrate/primitives/runtime/src/generic/unchecked_extrinsic.rs

+	/// Create new `SignedPayload` from raw components.
+	pub fn from_raw(call: Call, tx_ext: Extension, implicit: Extension::Implicit) -> Self {
+		Self((call, tx_ext, implicit), EXTRINSIC_FORMAT_VERSION)
+	}
+
+	/// Deconstruct the payload into it's components.
+	pub fn deconstruct(self) -> (Call, Extension, Extension::Implicit) {
+		self.0
+	}


The way this type is used is not so ideal to me.

Like here, executing deconstruct and then from_raw can change the actual value.

And in Encode we also lose the extrinsic format version.

Maybe having 2 types: SignedPayloadV4 and SignedPayloadV5 would make the code safer.

or new_v4, new_v5 etc..

But maybe it is fine as it is.

substrate/frame/support/src/crypto/mock.rs

substrate/frame/system/src/extensions/check_nonce.rs

gui1117

Code is good to me.

But before merging we should find consensus on those discussions:

make all transaction extensions allow not signed origin to go through in this PR.
IMO a follow-up is good. We can have a tracking issue, and it shouldn't be difficult.
- [Based on transaction extension 3685] make transaction extension pipeline not rejecting not signed origins #5612
AsAuthorizedOrigin trait or just using Option<Origin> in transaction extension pipeline.
IMO AsAuthorizedOrigin trait is good, frame system None origin fits our usecase, and it allows us to do more stuff with origin in the pipeline. But I don't mind Option<Origin> either.
~~in frame system offchain rename CreateInherent to CreateBare or something, and also is_inherent to is_bare?~~
~~IMO: CreateBare but~~ overall I don't mind.

And some minor ones:

merge PR docs into one for this PR.
Extrinsic failed and extrinsic success events: use a type to avoid too much breaking change for people using events.

@georgepisaltu

cc @georgepisaltu

gui1117 · 2024-09-20T04:35:34Z

prdoc/pr_3685.prdoc

+  - name: frame
+    bump: major


Suggested change

- name: frame

bump: major

- name: polkadot-sdk-frame

bump: major

For CI

gui1117 · 2024-09-20T04:58:01Z

prdoc/pr_3685.prdoc

+  - name: minimal-runtime
+    bump: major
+  - name: node-template
+    bump: major
+  - name: node-template-runtime
+    bump: major


Suggested change

- name: minimal-runtime

bump: major

- name: node-template

bump: major

- name: node-template-runtime

bump: major

- name: minimal-template-runtime

bump: major

- name: minimal-template-node

bump: major

- name: solochain-template-runtime

bump: major

CI say those crates don't exists.

georgepisaltu added 8 commits March 8, 2024 13:29

Fixes and refactoring after tx ext introduction

e7c6f57

Signed-off-by: georgepisaltu <[email protected]>

Remove bench helper trait from claims

2fa52c8

Signed-off-by: georgepisaltu <[email protected]>

Rename additional_signed to implicit in IR

90819a5

Signed-off-by: georgepisaltu <[email protected]>

Fix imports

9206bea

Signed-off-by: georgepisaltu <[email protected]>

Fix metadata test

611c165

Signed-off-by: georgepisaltu <[email protected]>

Fix unchecked extrinsic signing in tests

6fd6b25

Signed-off-by: georgepisaltu <[email protected]>

Revert "Revert "FRAME: Create TransactionExtension as a replacement…

53c0379

… for `SignedExtension` (#2280)" (#3665)" This reverts commit bbd51ce.

Merge branch 'tx-ext-fixes' into george-tx-ext

ed40294

georgepisaltu requested review from gavofyork and bkchr March 13, 2024 19:39

georgepisaltu requested review from athei, acatangiu, andresilva, cheme and a team as code owners March 13, 2024 19:39

paritytech-review-bot bot requested a review from a team March 13, 2024 19:39

georgepisaltu changed the title ~~George/restore gav tx ext~~ FRAME: Reintroduce TransactionExtension as a replacement for SignedExtension Mar 13, 2024

georgepisaltu added the T1-FRAME This PR/Issue is related to core FRAME, the framework. label Mar 13, 2024

georgepisaltu mentioned this pull request Mar 13, 2024

TransactionExtension follow up refactoring and fixes #3623

Closed

TarikGul mentioned this pull request Mar 13, 2024

[Tracking upstream] Addition of TransactionExtension polkadot-js/api#5820

Open

sinzii mentioned this pull request Mar 14, 2024

Support extrinsic format version v5 dedotdev/dedot#55

Open

georgepisaltu added 8 commits March 14, 2024 15:02

Add docs for impl_tx_ext_default

b6fba4a

Signed-off-by: georgepisaltu <[email protected]>

Remove TransactionExtensionInterior

455b762

Signed-off-by: georgepisaltu <[email protected]>

Merge remote-tracking branch 'origin/master' into george/restore-gav-…

5f6f63b

…tx-ext

Minor fixes for TransactionExtensionInterior

a896a50

Signed-off-by: georgepisaltu <[email protected]>

Fix metadata test

26ea26f

Signed-off-by: georgepisaltu <[email protected]>

Bump tx version in bridges

cde2b1e

Signed-off-by: georgepisaltu <[email protected]>

Missed file in previous commit

4c6f654

Signed-off-by: georgepisaltu <[email protected]>

Merge remote-tracking branch 'origin' into george/restore-gav-tx-ext

c4b522b

Signed-off-by: georgepisaltu <[email protected]>

paritytech deleted a comment from command-bot bot Sep 13, 2024

bkchr reviewed Sep 17, 2024

View reviewed changes

georgepisaltu mentioned this pull request Sep 18, 2024

[To be merged in another PR]: small improvment on top of transaction extension PR #5440

Merged

gui1117 and others added 15 commits September 18, 2024 15:13

Refactoring and renames

4bdda99

Signed-off-by: georgepisaltu <[email protected]>

Other fixes

b0274da

Signed-off-by: georgepisaltu <[email protected]>

Readd removed prdoc

ec3a948

Signed-off-by: georgepisaltu <[email protected]>

Merge remote-tracking branch 'origin/master' into george/restore-gav-…

a72e664

…tx-ext Signed-off-by: georgepisaltu <[email protected]>

Reorganize docs

cc4c3d8

Signed-off-by: georgepisaltu <[email protected]>

Fix compilation after example refactor

ad44e7d

Signed-off-by: georgepisaltu <[email protected]>

Small refactor in sudo extension

95853ad

Signed-off-by: georgepisaltu <[email protected]>

Reintroduce TestXt as a type alias

839a776

Signed-off-by: georgepisaltu <[email protected]>

Remove unused import

cc064c5

Signed-off-by: georgepisaltu <[email protected]>

Small refactor

e0bcda1

Signed-off-by: georgepisaltu <[email protected]>

Update VerifyMultiSignature extension

ff39bc9

Signed-off-by: georgepisaltu <[email protected]>

Remove expect in Extrinsic impl

840b18b

Signed-off-by: georgepisaltu <[email protected]>

Fix compilation

ce577be

Signed-off-by: georgepisaltu <[email protected]>

Merge remote-tracking branch 'origin/master' into george/restore-gav-…

98a0ff4

…tx-ext

gui1117 reviewed Sep 19, 2024

View reviewed changes

substrate/frame/support/src/crypto/mock.rs Show resolved Hide resolved

substrate/frame/system/src/extensions/check_nonce.rs Outdated Show resolved Hide resolved

substrate/frame/system/src/extensions/check_nonce.rs Outdated Show resolved Hide resolved

gui1117 reviewed Sep 19, 2024

View reviewed changes

[to be merged in transaction extension PR] (#5770)

c02478b

cc @georgepisaltu

gui1117 reviewed Sep 20, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

FRAME: Reintroduce `TransactionExtension` as a replacement for `SignedExtension` #3685

FRAME: Reintroduce `TransactionExtension` as a replacement for `SignedExtension` #3685

georgepisaltu commented Mar 13, 2024 •

edited

Loading

georgepisaltu commented Sep 13, 2024

command-bot bot commented Sep 13, 2024

georgepisaltu commented Sep 13, 2024

command-bot bot commented Sep 13, 2024 •

edited

Loading

command-bot bot commented Sep 13, 2024

bkchr left a comment

bkchr Sep 17, 2024

georgepisaltu Sep 18, 2024

bkchr Sep 18, 2024

gui1117 Sep 19, 2024

georgepisaltu Sep 19, 2024

gui1117 Sep 19, 2024 •

edited

Loading

georgepisaltu commented Sep 18, 2024

bkchr commented Sep 18, 2024

gui1117 Sep 19, 2024

gui1117 Sep 19, 2024 •

edited

Loading

gui1117 left a comment •

edited

Loading

gui1117 Sep 20, 2024

gui1117 Sep 20, 2024

FRAME: Reintroduce TransactionExtension as a replacement for SignedExtension #3685

Are you sure you want to change the base?

FRAME: Reintroduce TransactionExtension as a replacement for SignedExtension #3685

Conversation

georgepisaltu commented Mar 13, 2024 • edited Loading

Code Migration

NOW: Getting it to build

SOON: Migrating to TransactionExtension

TransactionExtensionBase

TransactionExtension

georgepisaltu commented Sep 13, 2024

command-bot bot commented Sep 13, 2024

georgepisaltu commented Sep 13, 2024

command-bot bot commented Sep 13, 2024 • edited Loading

command-bot bot commented Sep 13, 2024

bkchr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gui1117 Sep 19, 2024 • edited Loading

Choose a reason for hiding this comment

georgepisaltu commented Sep 18, 2024

bkchr commented Sep 18, 2024

Choose a reason for hiding this comment

gui1117 Sep 19, 2024 • edited Loading

Choose a reason for hiding this comment

gui1117 left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

FRAME: Reintroduce `TransactionExtension` as a replacement for `SignedExtension` #3685

FRAME: Reintroduce `TransactionExtension` as a replacement for `SignedExtension` #3685

georgepisaltu commented Mar 13, 2024 •

edited

Loading

SOON: Migrating to `TransactionExtension`

`TransactionExtensionBase`

`TransactionExtension`

command-bot bot commented Sep 13, 2024 •

edited

Loading

gui1117 Sep 19, 2024 •

edited

Loading

gui1117 Sep 19, 2024 •

edited

Loading

gui1117 left a comment •

edited

Loading