State of Precompiles in Revive Ecosystem

Ecosystem
1

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).

Today, Asset Hub already exposes several categories of precompiles, including:

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.

2

“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.

3

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.

4

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.

5

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.

6

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.