-
Notifications
You must be signed in to change notification settings - Fork 721
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
[Tx ext stage 2: 2/4] Introduce #[pallet::authorize(...)]
macro attribute and AuthorizeCall
system transaction extension
#6324
base: master
Are you sure you want to change the base?
Conversation
#[pallet::authorize(...)]
macro attribute and AuthorizeCall
system transaction extension#[pallet::authorize(...)]
macro attribute and AuthorizeCall
system transaction extension
#[pallet::authorize(...)]
macro attribute and AuthorizeCall
system transaction extension#[pallet::authorize(...)]
macro attribute and AuthorizeCall
system transaction extension
…tionExtension::validate` (#6323) ## Meta This PR is part of 4 PR: * #6323 * #6324 * #6325 * #6326 ## Description One goal of transaction extension is to get rid or unsigned transactions. But unsigned transaction validation has access to the `TransactionSource`. The source is used for unsigned transactions that the node trust and don't want to pay upfront. Instead of using transaction source we could do: the transaction is valid if it is signed by the block author, conceptually it should work, but it doesn't look so easy. This PR add `TransactionSource` to the validate function for transaction extensions
…tionExtension::validate` (#6323) ## Meta This PR is part of 4 PR: * #6323 * #6324 * #6325 * #6326 ## Description One goal of transaction extension is to get rid or unsigned transactions. But unsigned transaction validation has access to the `TransactionSource`. The source is used for unsigned transactions that the node trust and don't want to pay upfront. Instead of using transaction source we could do: the transaction is valid if it is signed by the block author, conceptually it should work, but it doesn't look so easy. This PR add `TransactionSource` to the validate function for transaction extensions
…tionExtension::validate` (#6323) ## Meta This PR is part of 4 PR: * #6323 * #6324 * #6325 * #6326 ## Description One goal of transaction extension is to get rid or unsigned transactions. But unsigned transaction validation has access to the `TransactionSource`. The source is used for unsigned transactions that the node trust and don't want to pay upfront. Instead of using transaction source we could do: the transaction is valid if it is signed by the block author, conceptually it should work, but it doesn't look so easy. This PR add `TransactionSource` to the validate function for transaction extensions (cherry picked from commit 8e3d929)
…tionExtension::validate` (#6323) ## Meta This PR is part of 4 PR: * #6323 * #6324 * #6325 * #6326 ## Description One goal of transaction extension is to get rid or unsigned transactions. But unsigned transaction validation has access to the `TransactionSource`. The source is used for unsigned transactions that the node trust and don't want to pay upfront. Instead of using transaction source we could do: the transaction is valid if it is signed by the block author, conceptually it should work, but it doesn't look so easy. This PR add `TransactionSource` to the validate function for transaction extensions (cherry picked from commit 8e3d929)
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.
Looks great, just some comments and questions
fn authorize( | ||
&self, | ||
source: TransactionSource, | ||
) -> Option<Result<(ValidTransaction, Weight), TransactionValidityError>>; |
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.
Worth mentioning that generally when we have an Option<Result<(...
we should have a dedicated type for the return, but I think this will never be manually implemented and having it like this makes it easier to work with in the macros. Users get to see TransactionValidityWithRefund
as the authorize
closure return type, so in terms of UX it's good.
PR is green, but semver is failing with:
|
Meta
This PR is part of 4 PR:
TransactionSource
as argument inTransactionExtension::validate
#6323#[pallet::authorize(...)]
macro attribute andAuthorizeCall
system transaction extension #6324#[pallet::authorize(...)]
to migrate unsigned in system: tasks + apply_authorized_call #6325#[pallet::authorize(...)]
to migrate all unsigned in polkadot-sdk #6326Description
#[pallet::authorize(..)]
, this attributes takes a function which returns the validity of the call.#[pallet::weight_of_authorize(..)]
, same as#[pallet::weight(..)]
defines the pre dispatch weight of theauthorize
function. It can also be retrieved fromWeightInfo
under the name:authorize_$call_name
.Authorize
in frame-support: implemented on the call for pallets and runtime, and used byAuthorizeCall
transaction extension in frame-system.Origin::Authorized
: a bit similar toUnsigned
but used for general transactions.AuthorizeCall
in frame system. This is meant to be used first in the transaction extension pipeline. It will call the authorize function and change the origin to authorizedensure_authorized
.Usage