Contracts on AssetHub Roadmap

Tech Talk
1

After #855 passing I would like take the time to lay out what Parity is planning to deliver and when it will be delivered approximately. I also try to elaborate on how the community can contribute.

Deliverables

  • pallet_revive: A heavily stripped down and simplified fork of pallet_contracts. The obvious change is that it uses PolkaVM instead of wasmi to execute contracts. But it will also include a lot of other changes that make executing cross compiled YUL much easier. For example, it will use AccountID20 instead of the runtime native address type including all the necessary mappings to AccountID32 to support AssetHub. Types like the block number and balance will also be fixed to uint256. Chain extensions will be replaced by the ability to declare custom pre-compiles. Much like it is the case on pallet_evm.
  • PolkaVM: The VM to be used by pallet_revive to run the contracts.
  • revive: Our YUL to EVM recompiler that will be used by contract developers in place of solc. This includes a javascript version of this compiler to be used by Web based IDEs.
  • ether-js-revive: A ether.js wrapper meant as a drop-in replacement for ether.js. To be used to write Dapps.
  • revive-ethereum-rpc: A proxy that translates Ethereum RPCs to Polkadot native RPC. It will enable using Metamask with AssetHub.
  • REMIX Instance: We will host a REMIX instance that can be used to experiment with the new contract environment. It will not be fully functional (no debugging support) but will be enough to have a zero setup way to experiment against a soon to be launched test net: Compiling and deploying contracts.
  • Validation testsuite: We will have a validation test suite written against ether-js-revive to make sure that existing popular contracts and artificial test cases are working.

Roadmap

Deployment to Westend AssetHub + REMIX instance (End of August)

Our current focus is to deploy pallet_revive to the westend AssetHub as quickly as possible. To allow people to experiment we will also host a REMIX instance against this AssetHub. This test net will experience breaking changes and resets while we are ironing out bugs and make necessary changes. But it will allow for people to start hacking.

This version will use an in-runtime PolkaVM interpreter. If 64bit support is finished in time we will use that. If not it will use 32bit and will be upgraded later.

This is also when we kick off the audit of the new pallet and PolkaVM. We mostly removed functionality from the already audited pallet_contracts. So we can focus on the changed parts like account mapping here.

Deployment on Kusama AssetHub (End of October)

Once all the on-chain behaviour is finalized we can deploy on Kusama to verify economic security. This is a big step since we are dealing with immutable code here. We need to be sure that the defined interfaces are how we want them to be since we need to support them forever once deployed here.

This version will use an in-runtime PolkaVM interpreter 64bit interpreter as this is the final byte code we will be using.

We will disable all functionality that we don’t deem secure enough and launch with very strict limits. We can always relax later.

This is also when we start adding functionality to ether-js-revive that is unique to pallet_revive vs. original ethereum. Like for example, management of code hashes and setting explicit weights (vs. a flat gas).

Deployment on Polkadot AssetHub (December)

If everything goes to plan and the audit is finished we can deploy to Polkadot. At this time in point we will have ether-js-revive that can be used to develop Dapps. REMIX for ad-hoc deployment.

Enabling of JIT compilation and further optimizations (end Q2 2025)

The next step is to add the necessary host functions to allow JIT compiled contracts in addition to the interpreter. This will unlock the performance benefits of using PolkaVM. The interpreter will still be around to support for running contracts which are not worth compiling. The idea is that the dry-run will tell you which execution path is cheaper. This information can then be used to specify that in the transaction: call(contract_addr, input, Execution::{Interpreted, JIT}).

We will also add the possibility to optionally store contract code on the relay chain. Trading a higher deposit for cheaper execution so the code doesn’t have to be included into the PoV.

We will also optimize the gas model to take into account warm and cold accesses.

How the community can help with tooling

After 903 referendum (Smart Contracts Plaza Tooling) - report, learnings and a new proposal failing it become clear that it might be too early to tell on what exactly we want to fund at this point.

The absolute essentials will be delivered by us (eth-js-revive). What we need in addition to that is hard to know. But to me it seems pretty clear that providing a HardHat based development environment is a safe bet. The following reasons:

  • It is javascript based and can be developed on top of eth-js-revive.
  • It is the most popular environment as of right now.
  • Web based IDE’s are more for experimentation and we already have that covered with our REMIX instance.

My advice to anyone wanting to build something right now is to wait at least until we have our testnet and the eth-js-revive ready. And then work out a minimal proposal that focuses just on providing a minimal HardHat based development flow.

17 Likes
2

Wonderful! For a Etherscan block explorer integration with contract verification, we require the equivalent of this
Verify & Publish Contract Source Code | Etherscan
using the revive equivalent of this
Helper for contract verification · Issue #27 · xermicus/revive · GitHub
which at the end of the day results in
UniswapV3:PositionsNFTUNI-V3-POSTokenTracker|Etherscan
That is, having the same kind of familiar (a) code (b) “Verified” and (c) ABIs all loaded into the right spot for the Read+Write interactions in the same way as EVM Contracts.

If there are any gotchas on Solidity versions, we should get all the minimums and known gotchas between what you ended up with the “revive” vs wished you ended up with on “contracts”. Not obvious from your description?

But awesome that we have the timing clear, we’ll be able to run with this.

Is having only { Kusama, Polkadot } block explorers ok or do you need Westend as well long-term?

1 Like
3

Contract verification is just a matter of supporting deterministic compilation. This essentially requires agreeing on a “canonical build” of the compiler. I just posted in the issue you mentioned. I think the easiest way could be to use the javascript version as this canonical build since it will run everywhere.

So yes this will work. We use the original solc as frontend which will also produce the ABI for us. We merely recompile the YUL it outputs and keep the rest.

I don’t fully understand your question. But let me say this: AFAIK there are no restrictions on the Solidity version we support. We use the original solc compiler to parse the Solidity. Since solc is backwards compatible we can support old Solidity versions. However, we won’t be able to support all the old solc versions as we require proper YUL support for our compiler to work. However, this shouldn’t be a problem since contracts have to be re-compiled anyways. You would just re-compile with a newer solc version but keep the original Solidity version as specified in the solc file. @Cyrill should know better.

Known gotchas are basically contracts which modify contract code. This is not supported in Solidity but requires dropping down to YUL assembly. Examples would be factory contracts specialized to deploy other contracts as cheaply as possible. This pattern wouldn’t work and have to be implemented differently (in a much easier way).

I wouldn’t say it is a requirement. But if you have a working version it should be easy to just also deploy it for Westend?

1 Like
4

Awesome!! I have a bunch of questions, I hope this is not off topic :sweat_smile:

  • can a smart contract on asset-hub do cross-chain extrinsic calls to relay chain or system’s parachain(collective,coretime,people etc)?
  • how can a smart contract interact with asset-hub pallets? Moonbeam has something called precompiles, will it be the same case here?
1 Like
5

Yes. We will be using the same system of exposing additional functionality via pre-compiles. Generally, everything that is not part of Solidity itself should be exposed as pre-compile as this is the easiest way to consume those API’s (you just provide an interface file).

Yes pallet_contracts already has xcm support. It is just a matter of configuration and exposing it as pre_compile.

1 Like
6

The minimum supported version will be 0.4.12. YUL yields better code and is considered mature since 0.8 and production ready (through --via-ir) on ethereum since version 0.8.13 released years ago.

There will be minor things not supported because of the underlying bytecode and runtime differences. Things that either don’t exist, or would break existing contract code, or are long depricated and so forth. Like type(T).runtimeCode, the PC instruction, CALLCODE etc. However from what I can tell and as Alex pointed out, those are mostly used for niche EVM specific optimizations and can be worked out around if ultimately required for some reason.

We will provide documentation regarding what exactly isn’t supported or works differently with the first stable release of the compiler.

7

The Etherscan team is mainly concerned about the breadth of customization needed to integrate PolkaVM – even though it sounds like not an issue, a lot of little things tend to come up. So perhaps the most cost effective solution in the expectation that a Asset Hub block explorer should have Etherscan, given the relative costs of blockscout vs Etherscan, is:

  • Etherscan for Polkadot Asset Hub
  • blockscout for Westend+Kusama Asset Hub

What do you think?

8

I think that sounds reasonable.

1 Like
9

Can a pallet extrinsic call a smart contract via pallet_revive?

Possible scenarios are:

  • schedule to call a smart contract
  • Pallet functionalities are fixed, use smart contract for extending or customization
10

Yes this is possible. Another pallet would just call the bare_call public function of a contract. Those contracts you designated to be called just by the runtime would rather written in ink! than Solidity because they use the same type system.

2 Likes
11

bare_call isn’t safe to call a smart contract.
I’m wondering about a typed and safe interface.

I hope we can have this Add a pallet to demonstrate calling into a contract by ascjones · Pull Request #228 · paritytech/substrate-contracts-node · GitHub
I also see you have an issue for Ink Make ink! contracts viable dependencies for the runtime · Issue #1674 · use-ink/ink · GitHub

12

The first version will be RISCV on WASM?
Is there a plan that migrates the Substrate runtime to RISCV?

13

Definitely coming with Jam. I, personally would love to get PolkaVM to Polkadot even before, as it is the last missing ingredient, after off-chain runtime upgrades to bring down deposit costs for PVFs by orders of magnitude.

14

Well, I pointed out the low level interface that will be used. Being untyped doesn’t make it unsafe. Being typed doesn’t make it safe either. Adding some macro magic to it will not give you more guarantees. It just makes it more convenient to use. You still need to make sure that you are actually calling into the code you think you calling into and that it does what you think it does with your input. So let’s be fair here and call it inconvenient instead of unsafe.

That said, asking for a more convenient interface is a reasonable demand. There are codecs for Ethereum ABI in the frontier repository that can be used to ease the coding. Mainly for implementing pre-compiles. We will try to re-use as much code as possible.

The equivalent would probably be to parse a Solidity file and output some Rust bindings. It’s not really a priority right now but it seems like a perfect project for an external team.

It will be PolkaVM = RISC-V. We are launching with an in-runtime interpreter and later upgrade to a client resident JIT.

Agreed. It would also solve all the headache with the pre-checking and we are almost there anyways. Why would it bring down the deposits, though?

15

The long compile times of wasm are just the last piece which make an increasing number of registered PVFs problematic at some point. With compile times out of the way and off-chain runtime upgrades, costs for the network are low enough to have a very large number of PVFs registered without any expected slow down/side effects.

As long has PVFs impose high (potential) costs on the network, we just have to be careful with bringing deposit costs down.

1 Like
16

GM.

We are all looking forward to the ability to deploy contracts on asset hub. Having pallet_revive ready on Westend at the end of August is really soon. This month basically. Seems the test version of plaza goes live then.
End of October, it will be live on Kusama as well.
End of December it will be live on Polkadot.

Wow, that is impressive and not what anyone would assume following recent discussions around 903, which closed with the comment Plaza is immature and very far away.

After positive feedback for proposal 903 and the request to split into milestones and having read the recent post 903 referendum (Smart Contracts Plaza Tooling) - report, learnings and a new proposal which got positive support from Shawn and Thibaut, why the sudden change of strategy?

Who will maintain the fork of a REMIX instance?

Or is that the project you will be working on with the team that proposed 903?

17

The REMIX fork will be very minimal. Just something to get going. Only compiling and deployment against Westend. PolkaVM doesn’t have debugging support, yet.

Especially because the timeline is so tight it is just faster to do it in-house. There is not too much coding work to do. Basically mostly integration work.

Parity. Don’t expect us to continually improve the REMIX fork, though. It is more meant as a launchpad to easy the development of further tooling (HardHat plugin would be welcome as I pointed out). I think for 903 the timing wasn’t very good. I am not against an improved rewritten WebIDE but I think it is too early. We need a test net first. But that testnet doesn’t make sense without any easy way to deploy against it: REMIX fork is just the lowest effort way to provide that.

1 Like
18

Since it is September now and the test net is still not live I would like to explain where we stand and why the delay.

My team just held a retreat last week and we were trying to cut enough corners to get something working on Westend. We were able to resolve all our known problems but we didn’t finish to get everything done in time.

Mainly because getting the address mapping (Address32 ↔ Address20) right was harder than expected. We didn’t want to go with the frontier solution where you can’t use existing AccountId32 accounts. But we also didn’t want to go with the Acala solution where a single Account is controlled by two keys and where this binding can potentially change. We think we came up with something simpler but it took up a lot of time to design this. I will post a complete writeup about this solution once we have the test net online and people can see it working.

What is open so far and what we hope to get done this week so we can launch on Westend:

  • Open and merge the Address Mapping PR + another minor PRs around address derivation
  • Add pallet_revive to Westetend and upgrade Westend
  • Deploy our REMIX compiler backend to Parity’s infrastructure
  • Deploy our REMIX frontend to github pages
12 Likes