Heya everyone, a heads up that if you wish to give targeted feedback in purely written (or attachment) format, you can now also submit it to the email address feedback@kusama.network which has been set up specifically for this.
To set expectations:
the best/fastest way to get issues and bugs in front of developers is still to log them directly in Github here
we don’t have a lot of capacity to necessarily answer every email (but we are still reading and collating them).
If you have 5 minutes, we’d still really appreciate your help in giving us your feedback via the form, so we can understand what else / where we should prioritise to improve the developer experience as much as possible.
Revive/EVM-style substrate-address (keccak padded with 0xee):
5G73DAYUhs2fH1xnsaTTMYgF8TAEkxdRrCnNwgBkAEYU11HB
Key point: Funds in the EVM-style address can only be moved via pallet-revive’s unsigned EVM transactions, there’s no “normal” way to control that address using an “orthodox” signed-transaction AFAIK. Traditional signed-transactions can only control the blake2 based account.
The teleport risk
Suppose you fund 5G73…11HB so that it can be accessed via Metamask/EVM, then teleport those assets out to, say, Hydration.
If the XCM destination uses the same SS58 address, did you just lost control of those funds?
Bottom line
Would it be wise to enable XCM from the EVM layer before this discrepancy is ironed out?
Am I missing something here, or is this a real gap that needs addressing before we roll out XCM support into EVM contracts?
Good to know that this is being addressed! However, it’s important to note that until that change has been merged and adopted by enough parachains, then we will still be in a rather risky situation… Meaning that enabling XCM precompiles from the EVM layer before that is merged and enough chains have adopted it, is kinda dangerous IMO.
Also, FWIW I really don’t think that a new variant is needed at all. The reason being that the extrinsic already contains the multi-address of the sender. So, it should be technically possible to have the ECDSA variant check against both account-ids, before deeming the signature as invalid.
EDIT: actually, it’s even more straightforward, in the ECDSA path simply check if the last 12 bytes of the the multi-address of the sender are padded with 0xee, and if they are then use the eth/keccak option, otherwise the “traditional” one.
There is some risk involved. But I can’t tell if it is enough to justify not adding XCM.
I think it is more straightforward in theory, only. In the actual code that will be a more invasive change. You would need to add some branching to the unchecked extrinsic implementation. While the current change gets away with a local change to the IdentifyAccount trait.
We should flag the folks responsible for the docs (paper moon?) for adding this step into their docs for deploying to Kusama Asset Hub. Connect to Kusama | Polkadot Developer Docs
Hi everyone, I’m excited to update you all that the next exciting feature of Solidity smart contracts on PolkaVM is now available on the testnet (Passet Hub on Paseo).
You can now utilise smart contracts to begin interacting with a key Polkadot feature, XCM, through the new precompile.
Great! What does this mean for me?
This marks a significant step forward in introducing new possibilities to the blockchain space, and we’re excited to see what you all start to achieve with this new functionality.
Find the initial documentation here to start experimenting.
We know that some of you are eagerly awaiting this XCM functionality, so we are sharing it as soon as possible. Please note that this XCM precompile is a low-level abstraction that is robust.
We plan to create high-level abstractions to make the XCM precompile more user-friendly. We will start by simplifying cross-chain transfers, and we want to learn from you (via this feedback form or feedback@kusama.network) about how else you are using XCM in your dApps so that we can prioritise next steps.
The XCM precompile can also be used with Ink!-based smart contracts (in addition to Solidity smart contracts).
As in the previous update, if you identify any bugs, please log them directly in GitHub here.
Next steps for Solidity smart contracts on PolkaVM
The PolkaVM preview will be complete with:
extra memory capacity and
improved gas mapping.
These parts are coming soon, so keep an eye out for an announcement that these have hit the testnet, and then Kusama, over the next few months!
The docs are great and all, but they kinda skip over the most important bit, right?
How do you actually assemble an XCM message and get the raw binary data you need to send it?
Worry not, brave explorer… PAPI to the rescue!
You can use the PAPI typed-codecs for nice, strongly-typed interfaces that make building any kind of XCM message a walk in the park. Check out this handy gist or jump straight into this StackBlitz sandbox to play around with it live.
If you prefer a more UI-driven experience, check out the PAPI-dev console where you can build the call-data of an XcmExecute and easily grab the encoded bytes you need (the message, basically, omitting the max_weight). Sadly, this kind of byte-level spelunking isn’t really doable in the PJS dev console, since it doesn’t let you fiddle with or copy the inner guts of the encoded data.
Have fun, and may your messages always route true.
