With the introduction of pallet-revive, smart contracts have become first-class citizens within the Polkadot ecosystem. One of the most interesting aspects of Revive is its ability to expose native runtime functionality directly to Solidity contracts through precompiles (and/or host functions).
System and cryptographic functionality, among others
In addition, there have been discussions around introducing further runtime-backed capabilities through new precompiles, such as staking-related functionality and additional cryptographic operations.
While exploring the current landscape, I noticed that discussions around precompiles tend to happen independently and are often tied to specific use cases. This made me wonder whether there is a broader picture that could benefit from ecosystem-wide discussion.
Some questions I would like to gather feedback on:
Current State
What is the intended long-term strategy for precompiles within Revive? There is talk about Host functions, should they be used to implement advanced runtime computations
Should precompiles generally live alongside the pallets they expose (e.g. XCM within pallet-xcm, Assets within pallet-assets)?
Are there existing guidelines for implementing new runtime-backed precompiles?
Documentation and Discoverability
The current documentation provides a useful overview of existing precompiles, but as more runtime capabilities become available, discoverability may become increasingly important.
Would it make sense to establish a canonical location documenting:
Available precompiles
Addresses
Input/output formats
SCALE encoding requirements
Weight calculation methodology
Version compatibility considerations
Future Direction
As Revive adoption grows, it seems likely that more pallets will expose functionality through precompiles.
Is there interest in defining a more standardized approach to:
Precompile implementation patterns
Address allocation
Documentation requirements
Testing and benchmarking expectations
My goal with this post is primarily to understand the current thinking around precompiles and gather context from runtime engineers and ecosystem teams before proposing tooling improvements around the developer experience of consuming these capabilities.
I would be interested in hearing how others see the future of precompiles within the Revive ecosystem.
“As Revive adoption grows, it seems likely that more pallets will expose functionality through precompiles.”
This is a big IF, a massive IF. Not only for the unclear growth in Revive adoption (does anyone have current metrics around this?), but because every new exposed functionality through precompiles will require a chain upgrade with all the painstaking workflow this implies (proposal, review, debate, voting…). My botomline is, I dont see pallets going into the precomplie race anytime. It is just about having some well-known standarized precompiles and we are good-to-go.
I agree with this, not all pallets will need to expose precompiles (as the bulk of precompiles will come from crypto primitives such as ZK hashing , signature verification among others). Outside assets, xcm, staking, there may not be many other pallet that need to expose their functionalities. But there is no visible limits to the amount of crypto primitives that can be exposed as precompiles.
Precompiles should go into their own crates. We have done the mistake of putting them into the same crates as the pallets at the beginning, but we started to clean this up.
Personally I’m still in favor of having some “unstable_dispatch” that enables contracts to call any Call. So, we could devs experiment faster to give better decisions on what we need/want stable precompiles.
This is interesting but would ABI-encoded Solidity contracts seamlessly integrate with SCALE-encoded runtime Call? If this tooling is in progress, could you share to for study.
They could. Just send the SCALE encoded bytes and decode them on the runtime side. Not the most elegant way, but enables you to experiment very quickly.
“just” use XCM::Transact and put a call into it. Can be any pallet. In my case it is `referenda::submit`. You an see the TX here, `revive::eth_transact` goes in and `referenda::submitted` event comes out.
I think it only makes sense to add precompiles to every pallet once it becomes clear which patterns the pallets are being used in. If we add precompiles for every pallet now, then we lock in their API for all eternity. And the chances are high that they don’t actually cover the usage patterns of developers.
I would personally wait to see how people use xcm::transact to interact with pallets, and then extract the most common patterns into shared contract libraries (not precompiles).
have you looked into this? Sol-XCM | A typed interface for interoperability from Solidity some other team tried to abstract pre compile calls, scale encoding is the tricky. shield.markets use several precompiles(for pallet assets and some cryptography stuff to speed things up)to function with a great performance boost for its smart contracts.
Hey there, I’ve been working on a implementation of the SCALE codec in solidity, GitHub - LucasGrasso/solidity-scale-codec: An implementation of Polkadot's Scale-Codec in Solidity · GitHub.
It currently does not support encoding/decoding of an arbitrary pallet call, but it provides the necessary primitives for it, and encoding/decoding for XCM v5 instructions.
Im interested in listening to your feedback, I think it plays nicely with the XCM precompile and can be extended to more use cases.
I did not thought about it. Then we don’t need what I said.