Ink! vs Bare Rust Smart Contracts

Tech Talk
1

Hey everyone

The ink! Alliance would like to share the results of a recent benchmark comparing a smart contract written in Bare Rust vs ink!, using the exact same contract: Mixocracy, a decentralized DJ voting platform with 25 public functions.

The results show where ink! shines, where it still needs refinement, and most importantly how it’s evolving to deliver a world-class Rust smart contract language with supreme developer experience and high performance, within the Polkadot ecosystem.

TL;DR Benchmark Results

Note: Both contracts were not built with optimization in mind, so the results should be taken with care. Probably the Bare Rust contract could win more from those optimisation gaines.

Category Winner Notes
Code Size ink! 3x fewer lines of code
Binary Size ink! 11% smaller
Instructions ink! 12% fewer RISC-V instructions
Deployment Cost ink! 11% cheaper
Gas Usage ~Draw Only ~1% difference
Build Time Bare Rust 7x faster clean build
Dependencies Bare Rust 20x fewer crates
Boilerplate ink! 45% of Bare Rust was boilerplate auto-generated by ink!
Type Safety ink! Compile-time safety vs runtime panics
Testing Support ink! Built-in #[ink::test] and e2e
Control/Flexibility Bare Rust Full low-level access

Full report: BENCHMARK_REPORT.md

What This Means

ink! makes building smart contracts simpler, safer, and faster (except compile time) without sacrificing performance.

The ink! implementation was 3x smaller in code, had fewer instructions, and still deployed more cheaply, all while providing auto-generated dispatch, ABI encoding, storage keys, and metadata that Bare Rust requires you to do yourself.

Over 40% of the Bare Rust implementation was just dispatch logic and storage boilerplate. With ink!, that’s gone.

This is a huge win for onboarding, productivity, and long-term maintainability.

Developer Experience: Built for Productivity

Using ink! instead of plain Rust dramatically reduces friction and the potential for errors.

ink! provides built‑in support for:

  • ABIs (both native SCALE and Solidity)

  • Typed storage and contract‑optimized data structures

  • Dispatch code generation and cross‑contract calls

  • Event handling and metadata generation

  • A full tooling ecosystem for compilation, testing, and front‑end integration

On top of this, the ink! e2e testing framework makes it easy to write end‑to‑end tests in pure Rust (including interaction with the runtime), and Pop CLI provides a seamless workflow for building, testing, deploying, and interacting with contracts.

In contrast, a low‑level Rust contract on pallet‑revive leaves all of that to you; storage layout, ABI handling, metadata, serialization, and even tooling integration must be implemented manually.

For most developers and most use‑cases, this makes ink! far more productive, safer, and maintainable than “rolling your own” with raw Rust and FFI. The result is faster iteration, fewer bugs, and a significantly better developer experience.

What’s Next for ink!

Our focus this past year has been on PolkaVM support and developer experience, and that work is still ongoing. But as ink! stabilizes, we’re also starting to explore language-level optimizations (e.g. reducing compile times).

The goal is clear: make ink! not just easier to use, but faster, smaller, and more powerful!

15 Likes
Ink!: Status, Context, and Why It Matters for Polkadot
2

Hey @Daanvdplas, thank you for creating this report. However, I find these numbers below irritating.

I think you do not have done a fair comparison. You probably have written a highly optimized version of the same contract with ink! and comparing it to the rust contract written by claude. As ink! can not do any magic, it needs to generate the same kind of code that the pure rust contract will need to write manually. I would even expect that the pure rust contract could be smaller than the ink! contract because you could optimize it more easily to fit exactly your needs. That said, I think you should remove this from your comparison.

For the record, I also think that writing contracts with ink! is much easier than to write them as pure rust contracts. Especially for new joiners it will be much easier to write these with ink! than with pure rust.

3 Likes
3

Hi Basti,

Please don’t get irritated. I recreated the Bare Rust contract with AI in ink! and ran the benchmarks explained in the repository, nothing more fancy than that.

You probably have written a highly optimized version of the same contract with ink! and comparing it to the rust contract written by claude.

Claude wrote it too, I just checked that the contract worked the same, nothing more. The fact that I didn’t do this only makes another good case for ink!. By default these contracts have good performance, and developers or AI can focus on code that matters (in the majority of the cases) in stead of boiler plate code.

As ink! can not do any magic, it needs to generate the same kind of code that the pure rust contract will need to write manually.

I don’t understand this, could you explain?

I would even expect that the pure rust contract could be smaller than the ink! contract because you could optimize it more easily to fit exactly your needs. That said, I think you should remove this from your comparison.

Yes maybe, and this is also an advantage I give to writing Bare Rust contracts, mentioned in the results: Control/Flexibility

I don’t understand why this post irritates you, I’m not attacking anyone or anything, just sharing some cool stats in light of ink!.
4

He is just pointing out that, if this benchmark was executed more carefully, the bare Rust contract would never be worse those metrics. In other words, if the code generated by the ink macros would be the optimal form to express the desired semantics, the bare Rust code would be the exact same code. In all other cases, the bare Rust version would be a more optimized form of what ink emits.

See also for example core Solidity, where they deem it important to allow pay for what you use.

5

Fair. To give context that I should have added (and added it now): Both contracts were not built with optimization in mind, so the results should be taken with care. Probably the Bare Rust contract could win more from those optimisation gaines.

2 Likes
6

I think the only fair comparison and crucial point is ease of development and maintenance. That’s what matters.

I agree with the other commenters about that Rust can’t only be at least as good as ink! for the other metrics. For those metric this benchmark says way more about the AI you use than about Rust vs ink!

1 Like