You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The upcoming release of ink! v6 (currently available as an alpha for early developers) introduces significant changes, including a migration from pallet-contracts (Wasm-based) to pallet-revive (RISC-V based).
Currently, the api-contracts package only supports interaction with pallet-contracts. To support ink! v6, it will need to be updated to interact with pallet-revive, which also introduces a change in the contract address format (AccountId20).
The main differences involve switching the pallet interaction from pallet-contracts to pallet-revive, and adjusting to the new contract address format (AccountId20).
These changes would make the updated code compatible only with ink! v6, and not with ink! v5 (which depends on pallet-contracts).
Happy to collaborate and help with the implementation but I’d love to hear your thoughts on the best approach moving forward:
Should we update the existing api-contracts to support only ink! v6 (pallet-revive), dropping support for pallet-contracts?
Should we introduce a new package (e.g., api-revive) that mirrors api-contracts but is tailored specifically for ink! v6?
Alternatively, should we add new components for pallet-revive within the same library. For example creating a CodePromiseRevive (similar to CodePromise)?
The text was updated successfully, but these errors were encountered:
Hi @AlexD10S thank you for the initiative, I'd say that ideally we want to keep this backwards compatible so I'd go for alternative 3. Add new code to the contracts package.
Additionally we don't want to mess too much with the interface that is exposed to the developer, that should be abstracted as much as possible, meaning that for example instead of creating a CodePromiseRevive the current CodePromise should be able to handle both cases depending on the version of ink!.
Uh oh!
There was an error while loading. Please reload this page.
The upcoming release of ink! v6 (currently available as an alpha for early developers) introduces significant changes, including a migration from
pallet-contracts
(Wasm-based) topallet-revive
(RISC-V based).Currently, the
api-contracts
package only supports interaction withpallet-contracts
. To support ink! v6, it will need to be updated to interact withpallet-revive
, which also introduces a change in the contract address format (AccountId20
).We’ve started experimenting with the changes internally to get a feel for how things might look.: https://github.com/use-ink/polkadot-js-api/pull/1/files
The main differences involve switching the pallet interaction from
pallet-contracts
topallet-revive
, and adjusting to the new contract address format (AccountId20
).These changes would make the updated code compatible only with ink! v6, and not with ink! v5 (which depends on
pallet-contracts
).Happy to collaborate and help with the implementation but I’d love to hear your thoughts on the best approach moving forward:
Should we update the existing
api-contracts
to support only ink! v6 (pallet-revive
), dropping support forpallet-contracts
?Should we introduce a new package (e.g.,
api-revive
) that mirrorsapi-contracts
but is tailored specifically for ink! v6?Alternatively, should we add new components for
pallet-revive
within the same library. For example creating aCodePromiseRevive
(similar to CodePromise)?The text was updated successfully, but these errors were encountered: