Release of smart contracts on Polkadot

Tech Talk
1

And we’re live! As of today, the Revive smart contract functionality has been released on Polkadot.

This initial Polkadot release focuses on correctness and reliability. Revive supports smart contracts running either on the EVM for full Ethereum compatibility or on Polkadot’s novel PVM for maximum performance. Developers can use familiar Solidity workflows or write Rust-based contracts, depending on their needs. All type of contracts are fully interoperable.

Polkadot Hub provides a solid, production-grade smart contracts platform: low latency, fast finality, access to assets and cross-chain messaging via precompiles, and both EVM and PVM execution paths are available with shared infrastructure.

:construction_worker: Start building

There are areas we plan to expand and optimize in upcoming releases, particularly around performance and tooling, but having this foundation live allows us to iterate based on real-world usage.

For developers considering where to deploy next, this is a good point to start kicking the tires and providing feedback. We’ve published a short overview that outlines what’s available today and how the pieces fit together:

:backhand_index_pointing_right: Why Developers Should Deploy Smart Contracts on Polkadot

Hands-on testing and practical feedback will be incredibly valuable as we move into the next phase. Please share any feedback on our tester form here.

I want to thank the community for its patience, positive outlook, and willingness to help with testing.

This is the start of a simpler, more attractive developer experience on Polkadot. Tell a friend, tell your leader, tell the world! Native smart contract functionality on Polkadot is here.

33 Likes
PixelProof, and the Cost of a Careless Aye
2

This release while truly monumental still presents a few DX problems for developers. We’re already playing with contracts on testnet and we’ve experienced a few issues.

  1. Still can’t deploy legacy transactions with hardcoded gas prices/gas limits Eg. https://github.com/Arachnid/deterministic-deployment-proxy
  2. The Eth rpc sidecar should be unified behind the same rpc endpoint for the substrate rpc endpoint. Having to run a seperate binary means more overhead for rpc providers who will most likely not run the side car
  3. Transaction receipts seem to be ephemeral if even available. And you can see the consequences of this on the testnet explorer https://polkadot.testnet.routescan.io/tx/0xf41a36f6578f3771a270cd6db23da30d86ee75e38af77747427377f75f32c879. Some txs no longer have a transaction details page. I don’t think theres any reasonable “optimization” for an ethereum chain to not serve transaction receipts for any reason whatsoever
  4. Contract verification is also broken on foundry. It seems routescan doesn’t support verifying contracts on Polkadot testnet.

These are just the few issues we’ve discovered at Polytope Labs. Once fixed, I believe will put asset hub in a position to properly compete in the Evm landscape.

Hoping these issues get fixed soon!

17 Likes
3

Thanks @seunlanlege for the feedback

@torsten answered here, We have a PR for Nick’s method that was merged here but unfortunately given the difference in gas model, this won’t work if the transaction strongly limits both the gas and the gas price.

Until now, to iterate fast , it was easier to have the RPC outside of the client, but indeed we should consider merging it into the client now that it’s more feature complete.

the eth-rpc needs to be configured with a database_url or env setting to maintain a permanent index, it also needs to point to an archive node if there is a need to fetch old receipts. This is probably mis-configured here, we will look into it and fix this.

We will check it out :eyes:

2 Likes