Update Chain Extension docs #307
Conversation
versioned_docs/version-5.x/macros-attributes/chain-extension.md
Outdated
Show resolved
Hide resolved
versioned_docs/version-5.x/macros-attributes/chain-extension.md
Outdated
Show resolved
Hide resolved
versioned_docs/version-5.x/macros-attributes/chain-extension.md
Outdated
Show resolved
Hide resolved
| | `ink(handle_status = flag: bool)` | Optional | `true` | Assumes that the returned status code of the chain extension method always indicates success and therefore always loads and decodes the output buffer of the call. | | ||
|
|
||
| As with all ink! attributes multiple of them can either appear in a contiguous list: | ||
|
|
||
| ```rust | ||
| type Access = i32; | ||
|
|
||
| #[ink::chain_extension] | ||
| #[ink::chain_extension(extension = 12)] |
There was a problem hiding this comment.
Do we have to consider this for the migration guide? Can you please take a look at the migration guide for chain extensions and see if there's anything to add/change?
There was a problem hiding this comment.
Added the notice in migration guide
versioned_docs/version-5.x/macros-attributes/chain-extension.md
Outdated
Show resolved
Hide resolved
versioned_docs/version-5.x/macros-attributes/chain-extension.md
Outdated
Show resolved
Hide resolved
| ``` | ||
|
|
||
| :::note | ||
| The ink! repository contains the [full example](https://github.com/paritytech/ink/tree/master/integration-tests/combined-extension) illustrating how to combine existing chain extensions |
There was a problem hiding this comment.
We should update this link to ink-examples once we've merged Sebastians PR there.
Co-authored-by: Michael Müller <[email protected]>
| A migration in most cases should just be to rename `#[ink(extension = …)]` to | ||
| `#[ink(function = …)]`. | ||
| `#[ink(function = …)]`, and specifying `extension` argument in top level macro. |
There was a problem hiding this comment.
Since it's a migration guide: how can people find out the number to put into extension? What was "the default" ink! used in 4.x?
There was a problem hiding this comment.
I honestly don't know, but my guess it is 1 or it was ignored, since if the chain extension is not used in a tuple then there is no requirement to specify its ID
There was a problem hiding this comment.
Ok, please try finding it out.
There was a problem hiding this comment.
Okay, I tested, the ID can be anything
| @@ -403,8 +403,21 @@ The argument type changed from `u32` to `u16`: | |||
| +Function, | |||
| ``` | |||
|
|
|||
| The top level macro now accepts (extension = N: u16) argument to support multiple chain extensions. | |||
| If you are using only one extension, the ID can be any `u16` number, | |||
| otherwise please consult [`#[ink::chain_extension]` page](https://use.ink/5.x/macros-attributes/chain-extension) | |||
There was a problem hiding this comment.
| otherwise please consult [`#[ink::chain_extension]` page](https://use.ink/5.x/macros-attributes/chain-extension) | |
| otherwise please consult the [`#[ink::chain_extension]` macro documentation](https://use.ink/5.x/macros-attributes/chain-extension) |
There was a problem hiding this comment.
What happens if
- someone uses only one chain extension in their contract right now
- they put arbitrarily
1there as part of the migration to 5.0 - the chain adds another chain extension in its runtime with
1?
Can we come up with a recommendation of what number people should put there if they right now use only one extension?
Chain specific extensions must use the reserved ID = 0 so that they can’t be registered with the registry.
Thinking out loud, a sensible recommendation could be to
- consult the chain registry repo if they are using something like XCM or
pallet-assets - consult the target chain documentation (Astar, etc.) regarding chain extensions and see if they say anything about the id.
- check the runtime configuration of the target chain.
- If no info is found in any of those places put 0 there?
Do you have an idea what the chain extension id for PSP-22 and the other PSP's would be?
There was a problem hiding this comment.
This will break compatibility for the scenario you described. Consulting the target chain's docs is the most sensible approach, as the chain registry repo appears to be unmaintained (the last changes were 2 years ago).
Until then, if you are sure that the chain only uses a single chain, then putting any number. is fine
versioned_docs/version-5.x/macros-attributes/chain-extension.md
Outdated
Show resolved
Hide resolved
versioned_docs/version-5.x/macros-attributes/chain-extension.md
Outdated
Show resolved
Hide resolved
versioned_docs/version-5.x/macros-attributes/chain-extension.md
Outdated
Show resolved
Hide resolved
Co-authored-by: Michael Müller <[email protected]>
Closes #303