Parity Technologies, the company behind the Polkadot blockchain, has announced a key update to its Rust-based ink! Programming language for writing smart contracts.
The new update, ink! 3.0, is designed to make ink! look and feel much more like the Rust programming language it’s based on. It now comes with all of the same features that Rust programmers are familiar with, which Parity says will be a big help when it comes to writing, updating, and reasoning with complex smart contracts.
ink! is the most commonly used programming language by developers in the Polkadot and Substrate ecosystems as it’s one of the best for writing efficient, high-performance Web Assembly (Wasm) smart contracts, which are an alternative to Ethereum’s Solidity-based smart contracts. With ink!, developers can write smart contracts for blockchains using the Substrate framework’s Contracts pallet – a key building block for Polkadot-compatible blockchains.
ink! is based on Rust because the latter is an extremely efficient programming language that prioritizes correctness, prevents software bugs and has an extensive community that includes support from firms such as Amazon Web Services, Google and Microsoft. So it means ink! benefits from the exact same correctness guarantee Rust has, as well as any improvements the Rust community adds through its constant updates of that language.
In a blog post, Parity said the ink! 3.0 update was a time-consuming endeavor that involved rewriting all of its major components, including changing its syntax to better map code from ink! to the generated Rust code. It was worth the effort though. With ink!’s syntax now more or less identical to Rust, developers gain access to the exact same tooling, such as rust-analyzer and Clippy, that are available on the language they’re most familiar with.
New Features in ink! 3.0
That’s far from the only thing that’s changed in ink!. The new version brings the highly anticipated Trait Support that allows developers to define their very own trait definitions, then implement these in ink! smart contracts. With this, developers can define shared smart contract interfaces to different implementations, Parity said, which is especially useful for community-defined smart contract standards.
Other improvements in ink! 3.0 include smaller contract sizes, leading to higher performance and lower gas fees, and the addition of Delegate Calls, which gives smart contracts a way to forward calls they receive to another contract. This will enable developers to implement Proxy Upgrade Patterns for multiple smart contracts, among other things, Parity said.
The new Chain Extensions feature meanwhile enables developers to call Substrate pallets directly from a smart contract and access its rich ecosystem of developer tooling.
Wait, There’s More!
As well as ink! 3.0, Parity said it has made some improvements to the Contracts pallet that aim to boost parachain performance, along with new features that promise better cross-contract calls and performance. With `cargo-contract` 1.0., Parity said developers will find it much simpler to write more complex logic in their smart contracts.
`cargo-contract` is a developer tool that can be used to build, test and deploy ink!-based contracts. The new version adds three command-line interface commands that make it easier to interact with smart contracts on chains – namely, upload, instantiate and call! This, Parity said, makes life a lot easier as it means developers no longer need to click through a browser UI to interact with such contracts, instead of doing it directly from the command line. In the future, this will enable scripting and integrations into Continuous Integration development environments too, Parity said.
A second new capability of ‘cargo-contract’ is its ability to automatically check source code for programmatic and stylistic errors and provide alerts when common errors are found. Parity said its aim with this is to slowly build a collection of linting rules for ink! smart contracts, guiding developers to reduce gas costs, create smaller smart contract footprints, and correct API usage patterns while identifying security vulnerabilities.
Substrate’s Contracts pallet, which is the execution environment for Wasm-based smart contracts, also gets an update. For instance, the state rent mechanism that’s used to handle state bloat has been replaced by an automatic deposit collection feature. Prior to this, smart contracts were required to always have enough balance to pay for their storage, or else they would be disabled until someone came along to revive it. So eliminating this reduces a lot of burden on developers, Parity said.
With automatic deposit collection, storage costs are paid by the caller of each smart contract as opposed to the contract itself. The caller pays a deposit, then new storage is created as a result of that call. Parity explained this mechanism will eliminate any possibility of smart contracts being made inactive. Even so, Parity said contract authors should still work to use as little storage as possible by creating ways to remove storage when it’s no longer needed, so as to keep storage costs down.