Contracts on AssetHub Roadmap

We are already in talks about deploying Uniswap on the AH. More DeFi products could also follow through. Will update the forum in the coming days.

However, liquidity is the primary concern everyone has when deploying those contracts. We either have to invest heavily ourselves or run these infrastructures as a public good.

3 Likes

Hi everyone, Iā€™m Yakio from Subscan Explorer. Iā€™m really excited about the progress and updates shared here. I completely agree with the points raised about the need for robust tools to support both developers and users. Weā€™re very interested in this development.

With our experience in supporting EVM contracts, weā€™ve provided services like contract transactions, read/write functionality, and contract verification for over 20 networks, including Moonbeam, Astar, and Darwinia.

Subscan also has a strong track record in enabling seamless interactions with AssetHub pallets and facilitating cross-chain contract calls between parachains and the relay chain, offering a comprehensive, one-stop service.

At the same time, we know that improving the user experience and integrating deeper EVM/PVM functionalities is essential. Weā€™re eager to work closely with Parity, stay in sync with development progress, and make sure we align with the PVM rollout to provide efficient and user-friendly tools for the community and developers.

Feel free to reach out to me on Element: @yakio:matrix.org

4 Likes

Thanks for raising this point! I think Subscan could also be a strong choice as a block explorer solution for AssetHub. We have extensive experience supporting both EVM and Substrate-based networks, and weā€™re already providing comprehensive services like contract verification, read/write interactions, and cross-chain functionality across more than 20 networks, including Moonbeam, Astar, and Darwinia.

Given that Subscan is already deeply integrated with both EVM and Substrate ecosystems, we could offer a highly customizable and cost-effective solution for Polkadot AssetHub, Kusama, and Westend as well. Our flexibility and experience in managing similar challenges make us well-suited for supporting the specific needs of AssetHub while keeping the user experience smooth and developer-friendly.

Would love to hear your thoughts on this!

1 Like

JAM implementers like us are definitely going to want to use this revive Solidity-to-PVM compiler for refine-accumulate (and transfer) code. Right now we are hand assembling code like this fibonacci refine-accumulate and using @koute 's assembler here to build test JAM ā€œservicesā€ as if its 1964.

We request a Revive Solidity-to-PVM compiler that would not only target pallet-revive for Polkadot developers but also target JAM services. An MVP would be ideally usable by JAM implementers in early 2025.

JAM services require host function calls, and thankfully revive already maps opcodes that interact with the runtime with a EVM compatible ecalli, managed by pallet-revive. A similar ā€œhookā€ within Solidity to access 2 dozen or so host functions in GPā€™s Appendix B (import, export, read, write, lookup, etc.) within reviveā€™s ecalli would be transformational.

There are early efforts for C/C++ already by JAM Brains from @OliverTY @francisco.aguirre et al ā€“ it would be natural to have a parallel one for Solidity from revive to match C and C++.

It would be bad to have pallet-revive appearing on PAH delayed, but if its only slightly more work to add JAM Services as a target, it will make a difference to Polkadotā€™s JAM future :sweat_smile: :smiling_face_with_tear: :grinning:

Honestly, thatā€™s probably a bad idea. (:

My assembler isnā€™t meant for actual end user use and pretty much only exists to make testing and generating test programs easier. If you donā€™t want to assemble services like its 1964 you can just useā€¦ normal Rust.

Take a look at the guest programs in the PolkaVM repository. Those are all valid JAM programs, with the only difference being that they are packaged in a .polkavm container (and they donā€™t have the hardcoded JAM dispatch table at the start, so theyā€™re not valid JAM toplevel services, but they can be executed in an inner JAM VM). You can trivially extract the code section from a .polkavm blob and run it on your own PVM implementation (currently this requires writing a tiny bit of Rust code to call ProgramParts::from_bytes and extract the code_and_jump_table field, but I suppose we could add a subcommand to the polkatool to make it possible to do it on the command line; although ideally everyone would standardize on a single program interchange format so that all of the tooling can be shared and things like debug info can be supported).

Calling JAM-specific hostcalls is also easy. Hereā€™s a snippet with a few JAM host functions defined (calling these from Rust will trigger the appropriate ecalli instruction):

#[polkavm_derive::polkavm_import]
extern "C" {
	#[polkavm_import(index = 0)]
	pub fn gas() -> i64;
	#[polkavm_import(index = 1)]
	pub fn lookup(service: u32, hash_ptr: *const u8, out: *mut u8, out_len: u32) -> u32;
	#[polkavm_import(index = 2)]
	pub fn read(service: u32, key_ptr: *const u8, key_len: u32, out: *mut u8, out_len: u32) -> u32;
	#[polkavm_import(index = 3)]
	pub fn write(key_ptr: *const u8, key_len: u32, value: *const u8, value_len: u32) -> u32;
}

Anyway, this is completely off topic here. If you want to talk about this either make a new topic, or create an issue in the PolkaVM repo, or message me on Element and I can help you out to get the toolchain going.

2 Likes

Another update since we are still not on Westend. It is basically almost done but we were hitting a few minor issues we are resolving.

REMIX

The compiler backend for REMIX was hanging when multiple requests came in. Needed to add some basic load balancing. Also some other minor issues with REMIX where when the backend was busy it was failing to initialize. That said, the backend is now working and the code can be found here. We are still cleaning up and fixing some minor issues in the frontend. Please note that the original REMIX doesnā€™t have any backend since it runs the compiler inside the browser. This wasnā€™t trivial in our case because our compiler is based on LLVM which was too heavy weight to run in the browser (because of 3GB memory limit). However, we plan to get rid of the backend as a next step and move the compiler into the browser. There are probably some optimisations to be had to make this possible.

For the frontend we currently maintain a fork so that it can talk to our backend. There not too many other changes apart from deactivating features we do not support yet.

Eth compatability

We were going back and forth with the design of how to package Eth transaction into extrinsics. The original approach wasnā€™t working too well. We know more or less dump the Eth tranaction as-is in an unsigned extrinsic. Makes it easier for eth block explorers to decode it. This took a lot of time and iteration. We are planning to merge this into polkadot-sdk very soon (i.e this week) and then add pallet_revive to the Westend runtime.

pallet_revive

We realized that some features are needed to be implemented before we can launch a test net because almost every contract makes use of them. A lot of changes were made to pallet_revive since the last update. But those should be the last before we can launch a test net:

The latest one adds support for immutable variables in Solidity which is kind of tricky to support since we deploy code differently from EVM (we have on-chain constructors). This is the last change to the pallet before we think it can run enough contracts to be ready for a test net.

revive

@Cyrill was mainly busy implementing the above features in pallet_revive as he discovered that he needs them to implement all the EVM opcodes. We are still missing some auxiliary opcodes (like GASPRICE) and pre-compiles. But those can come after the testnet is deployed as not every contract needs them.

PolkaVM

We hired two new people to work on PolkaVM. The highest priority right now is to get 64bit support implemented as this is what we deem necessary for a Kusama deployment. Otherwise we would need to be backwards compatible to 32bit which we would like to avoid. @koute is mostly busy implementing/debugging advanced features for JAM (use space page faulting). He also had an idea on how to get rid of our custom toolchain which we plan to give to our new joiner as an onboarding task.

tl;dr

Our first mile stone is still to have a Westend deployment + REMIX instance for people to experiment and give feedback. It is as close as it gets to be done.

11 Likes

Regarding PolkaVM, when can we expect it to be standardized with a full spec?

1 Like

Parts of PolkaVM are/will be standardized in the JAM graypaper; the rest of the stuff which is PolkaVM-specific and not specced by the GP (the container format, the debug info format, etc.) I am planning to eventually spec out; I donā€™t have a timeline as to when exactly that will happen.