General transactions in extrinsic format #84
Conversation
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
|
No mention of the 2 additional extrinsic types to be introduced? Can we at least have a table like this?
|
|
I agree a table like that could be helpful, but I don't think we need more detail on exactly what |
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
@xlc I added the table. |
|
|
||
| In order to support transactions that use different authorization schemes than currently exist, a new extrinsic type must be introduced alongside the current signed and unsigned types. Currently, an encoded extrinsic's first byte indicate the type of extrinsic using the most significant bit - `0` for unsigned, `1` for signed - and the 7 following bits indicate the extrinsic format version, which has been equal to `4` for a long time. | ||
|
|
||
| By taking one bit from the extrinsic format version encoding, we can support 2 additional extrinsic types while also having a minimal impact on our capability to extend and change the extrinsic format in the future. |
There was a problem hiding this comment.
Going a bit more in the details here. There is a reference below, but what would be good to have right at the RFC (in my opinion):
- What is the concrete usecase/what do we want to achieve and why? What benefits does it bring? "Different authorization" schemes is pretty generic ... what is wrong with the existing ones?
- What other ways of adding these different authorization schemes have been considered? E.g. Why are they not covered by "unsigned"?
There was a problem hiding this comment.
I tried to answer your questions in the new iteration of Motivation. Let me know what you think.
There was a problem hiding this comment.
Thank you! Better proxy accounts, meta data verification, ... - got it ;-) Now that's a good motivation!
| In order to support transactions that use different authorization schemes than currently exist, a new extrinsic type must be introduced alongside the current signed and unsigned types. Currently, an encoded extrinsic's first byte indicate the type of extrinsic using the most significant bit - `0` for unsigned, `1` for signed - and the 7 following bits indicate the extrinsic format version, which has been equal to `4` for a long time. | ||
|
|
||
| By taking one bit from the extrinsic format version encoding, we can support 2 additional extrinsic types while also having a minimal impact on our capability to extend and change the extrinsic format in the future. |
There was a problem hiding this comment.
This is not really the motivation and more an explanation of the current format. Motivation would be more the introduction of the new general transaction and what this can bring. There you can bring the example of the new "meta transaction" that enables people paying for the transaction of other peoples.
There was a problem hiding this comment.
I updated the motivation. Let me know what you think.
|
|
||
| Runtime users. | ||
|
|
||
| ## Explanation |
There was a problem hiding this comment.
You should mention that the transaction version is bumped to 5.
https://spec.polkadot.network/id-extrinsics#id-extrinsics-body also you could link to the description of the format somewhere here.
Signed-off-by: georgepisaltu <george.pisaltu@parity.io>
|
|
||
| "General" transactions, a new type of transaction that this RFC aims to support, are transactions which obey the runtime's extensions and have according extension data yet do not have hard-coded signatures. They are first described in [Extrinsic Horizon](https://github.com/paritytech/polkadot-sdk/issues/2415) and supported in [3685](https://github.com/paritytech/polkadot-sdk/pull/3685). They enable users to authorize origins in new, more flexible ways (e.g. ZK proofs, mutations over pre-authenticated origins). As of now, all transactions are limited to the account signing model for origin authorization and any additional origin changes happen in extrinsic logic, which cannot leverage the validation process of extensions. | ||
|
|
||
| An example of a use case for such an extension would be sponsoring the transaction fee for some other user. A new extension would be put in place to verify that a part of the initial payload was signed by the author under who the extrinsic should run and change the origin, but the payment for the whole transaction should be handled under a sponsor's account. A POC for this can be found in [3712](https://github.com/paritytech/polkadot-sdk/pull/3712). |
There was a problem hiding this comment.
| An example of a use case for such an extension would be sponsoring the transaction fee for some other user. A new extension would be put in place to verify that a part of the initial payload was signed by the author under who the extrinsic should run and change the origin, but the payment for the whole transaction should be handled under a sponsor's account. A POC for this can be found in [3712](https://github.com/paritytech/polkadot-sdk/pull/3712). | |
| An example of a use case for such an extension would be sponsoring the transaction fee for some other user. A new extension would be put in place to verify that a part of the initial payload was signed by the author under whom the extrinsic should run and change the origin, but the payment for the whole transaction should be handled under a sponsor's account. A POC for this can be found in [3712](https://github.com/paritytech/polkadot-sdk/pull/3712). |
Not sure if whom here is really correct :D
There was a problem hiding this comment.
Yeah whom is correct :)
|
it would be good to mention that SignedExtension trait and types will change. The clients look up them in metadata, and this change will affect them. We can see it here in the example |
No, this doesn't change the metadata. Generally it didn't requires any changes so far from the metadata side as the handling is basically the same. Also the encoding of the transaction extensions. The metadata basically just contains the types of signed extra and the type inside the extension itself and the name of the extension to know what it is. Not more. |
|
/rfc propose |
|
Hey @bkchr, here is a link you can use to create the referendum aiming to approve this RFC number 0084. Instructions
It is based on commit hash e403ee81e06fde5dceee1fb906f29fb2e140e51e. The proposed remark text is: |
|
Voting for this referenda is ongoing. Vote for it here |
|
PR can be merged. Write the following command to trigger the bot
|
|
/rfc process 0xdfba8ee9626a5a211a4bbd1bd33a56c1459f4cbccfecf7dcb84cc16be6ccfbf9 |
|
The on-chain referendum has approved the RFC. |
No description provided.