# The Future of ink!

In our call in February we discussed that I will lie out anything that we are working on/have planned. This is done with the intention of MarComms being able to provide input on where and how MarComms resources could help us get there.

## Current State of ink!

We are live on three production parachains:

* Polkadot: Astar
* Kusama: Shiden
* Standalone: Aleph Zero

Upcoming ones which already have us on their testnest:

* Polkadot: Phala, Pendulum, Watr, bit.country, t3rn, Enjin, peaq.
* Kusama: Amplitude

In talks with: Encointer, Interlay, OriginTrail, Acala, Moonbeam.

## Strategy Canvas

In Sardinia I gave a talk about the roadmap for ink!, this is an updated version of the strategy canvas I presented there. It guides the big picture of what we are working on.

In the following chart you can see how I assess ink! in comparison to:
* Solidity
* Other Wasm Contracts: I just threw everything (CosmWasm, NEAR, Soroban, …) in one bucket and took the average.


The Y-axis has the best rating at Y: 0 (Great) and the worst at Y: 5 (Bad).

So in a perfect world, our lila ink! line would be fully flat at "Great" for all those characteristics.

### The Road to "Great"

In the following I'll go through our plans to put us on "Great" for each of those characteristics.

#### Technical Sophistication

There's ~200 issues in ink! and its related GitHub repositories. Those issues form a clear plan how to get there. It's mostly about "just" working on those.

I'm in the process of hiring two additional developers and a TPM. The TPM should take some of the organizational workload from me and take care of outsourcing some of these issues to the community, as well as writing and overseeing W3F grants for those issues. So it's about getting us there faster.

The next major ink! release (5.0) will be OpenZeppelin flavoured, based on what they suggested in their engagement with us. We are targetting mid-June, before Decoded. [This](https://github.com/orgs/paritytech/projects/81/views/1) is the GitHub board tracking the progress.

#### Testing Story

ink! has a mature story how contract developers can test their contracts. There are some things that can be improved and OpenZeppelin suggested a number of features that make it easier for auditors to test behavior of a contract. Those needs are persisted in GitHub issues (in the above board) and are actively worked on.

#### Language Design

It's mostly about some tweaking here and there. Exists in GitHub issues. We are in a good place and think we have the most advanced Rust domain-specific language for smart contracts.

The Solidity roadmap for the coming future contains mostly features that Rust invented, to improve the safety of Solidity contracts. We already have those, as we use Rust for ink!.

#### Branding

We've created a welcoming, easy to approach, playful brand. This is different from the intentionally agnostic, neutral, polished Polkadot. Removing this character from ink! would be throwing away what makes the appeal. It's about more than just removing some pretty pictures or changing the name. We want to retain our own branding.

We have gotten immensely good feedback for our branding. There are some adaptions that we will be making going forward though:

* We will simplify the narrative.
* We will create a positive brand association to Polkadot.

There will be no more mention of "Parity's ink!", "eDSL", "domain-specific language" or "Substrate". In the past we emphasized that ink! is a smart contract programming language based on Rust. But this messaging was sometimes mistaken by people as "I have to learn a whole new language that is just based on Rust" and it sabotaged our "easy to approach" narrative.

Instead the messsaging will be changed to:

* ink! – Smart contracts for Polkadot.
* Write smart contracts with Rust.
* ink! is a smart contract toolkit.

We have started including the Polkadot logo and references to it in all relevant places.



We started emphasizing Polkadot in our documentation and will do more in this direction.


We will add badges like these to our ink!-related repositories:


#### Time to Dapp

The Time to Dapp refers to the time it takes a developer to build and launch a Dapp.

ink! consists of two products at the moment:

* ink!, the Rust dialect for writing a contract.
* `cargo-contract`: a command-line tool for working with ink! contracts.

Building a frontend is something that we have not covered in any way. We currently just forward people to `polkadot-js`, which is complex to use.

We are adding another product to the ink! stack: a frontend library called `useink`. It is a library for the popular React framework. Technically it is an abstraction on top of `polkadot-js` (in the future we will switch to use CAPI under the hood).


Developers will be able to utilize `useink` for building a frontend to their smart contract. The library is very much geared towards ink! and smart contracts. It makes it easier to build a frontend than with `polkadot-js`.

_The overarching intention here is to have a full-stack narrative for ink!. We no longer want to make it just about the smart contract, but instead cover everything needed to build a complete Dapp._

The goalpost is that in our ink! examples repository we will no longer have just smart contract code examples. Instead, for each example contract there will be a corresponding frontend example, built with `useink`.

ink-examples/
	multisig/
		contract/
		frontend/

This will make the time it takes for developers to build and launch a Dapp way shorter.

#### Debugging

For developers, debugging is an essential piece when developing software. Our contract debugging story is not good currently. We have a plan how to integrate contract debugging capabilities into popular IDEs, like VSCode or IntelliJ.

#### Discoverability

We have a SEO consultant working for us since about six weeks. There have already been a number of improvements made.

Besides that we have outsourced most marketing to community teams by now. This has proven a good path for us. In May, the Brushfam team organizes a virtual ink! hackathon. A number of teams have organized big Twitter spaces for us in the past.


We are creating multi-modal content based on the existing written material on [use.ink](https://use.ink). Specifically this means that we take our detailed longer form content and put it into YouTube Shorts and educational videos of 5-8 minutes, as well as shorter-form Medium articles. We are promoting those via YouTube, Twitter, LinkedIn and Medium.

A lot of the content we provide is recycled by community teams in different forms (articles, videos, etc.). We also regularly have people translating our material to other languages, like Hindi, Portugese or Spanish.

We have had good success with providing content that people can easily recycle/remix/process into other forms. So to enable the community to easily make use of the content. All illustrations in the documentation are in a vectorized file format; this format is losless, they can easily be included into e.g. high-res YouTube videos that someone makes. Our code examples are put in the Public Domain (CC-0), as well as our entire documentation on [use.ink](https://use.ink). This means, someone could e.g. write a book about ink!, reusing our texts, illustrations, etc. This is likely seen as critical by readers of this text, but I'm convinced it is beneficial for us. The overarching goal here is to make it as easy as possible for the community to further publicize our project. This is easiest by relinquishing some control. And in the crypto world copyright is ignored anyway, so we can also just embrace this characteristic.

We have had talks about ink! at each Decoded and sub0 event in the last years and will continue to do so.

#### Latin America

Our documentation has been translated into Spanish. It was a combined effort of Spanish speakers at Parity and the community.

We had a first ink! Meetup in Buenos Aires in February and have connected with a team there (Roloi). They will do more ink! Meetups going forward and we've sent them ink! merchandise for their meetups.

#### Safety

For smart contracts, the risk factor of choosing a technology is particularly important.

We are currently transitioning to our own GitHub organization. This happens with the intention of making ink! a product that can in the longterm survive without Parity and has multiple stakeholders besides a single company. It's bad for programming languages to have just one company behind them. On the whim of a company roadmap/budget/priority change, a multitude of dependent projects would be affected. We are making an active effort of getting other companies to have skin in the game and would ideally give them merge rights for selected repositories later this year.

_SRLabs_
SRLabs has finished the initial audit of ink! and `pallet-contracts` a couple weeks ago. They will do another audit of ink! in summer, when more ink! projects are deployed and we have more usage patterns.

_OpenZeppelin_
The OpenZeppelin security review was recently finished as well. The feedback was very good:


The report is online on their website [here](https://blog.openzeppelin.com/security-review-ink-cargo-contract/). We made sure to backlink to the Polkadot website in there and included the Polkadot logo everywhere as well. We had a big Twitter space with them once we wrapped the review up. The results from the audit are persisted in [this]( https://github.com/orgs/paritytech/projects/81/views/1) GitHub board.

On Sunday, April 16, we will meet the OpenZeppelin team in Lisbon and discuss further engagements.

_Ecosystem of ink! auditing companies_
We are creating a financial incentive for auditing companies to build up ink! expertise. This is done with the ink!ubator project detailed further below.

#### Community

We have improved our community interactions a lot, questions for ink! on the Substrate StackExchange are answered quickly. We have monitoring in place for StackExchange questions and unanswered GitHub issues. We are hosting monthly office hours on Twitter, where anyone can ask us questions.

There have been two ink! Meetups in Berlin in the last two months. Both with 90% talks from the community. We'll do another Berlin one in May and a Krakau (Poland) one in June.

#### Education

This is our biggest shortcoming, there is a large backlog of tickets that are specified out or half-finished. It's about educational tutorials, articles and videos. We need a new DevRel person to work on them and an animator/video person to chip away on the backlog of already recorded videos.

Crypto Zombies: We are about to sign a contract with CryptoZombies for building out the same plattform for ink!.

#### Adoption

We are talking to a number of parachains about adding ink! support: Encointer, Interlay, OriginTrail, Acala, Moonbeam.

The ink!ubator program provides support for selected teams to build out great ink! Dapps. It is funded by the Polkadot Treasury and offers selected teams support to build out high-quality ink! Dapps. The support is technical (through us and an experienced community team), deployment (Astar, Phala, Aleph Zero) and funding for auditors (we have a number of auditing companies that will do the auditing).

#### Media Presence

Our media presence is mostly reliant on high-profile collaborations (OpenZeppelin), the community and the content we put out.


For the launch of ink! contracts on Astar their team had organized a big crowdcast with hundreds of attendees:


We have a number of further high-profile collaborations (CryptoZombies) coming up and some ideas for viral content that we are working on.

_Thought Leaadership_
The big change we will do for Media Presence is that we will be doing more Thought Leadership going forward.

So far we have been focussed on getting to a good product. A necessary next step will be about shaping narratives in our space and owning them.

The two most relevant ones here are the Blockspace and Hybrid Chain narratives that Rob is shaping.

ink! is ideally set up for Hybrid Chains; we support them and have just always referred differently to the concept ("chain extensions"). We have in the past not been explicit about it being a huge thing.

Specifically we want to introduce and own the term _Hybrid Contracts_. The term denotes contracts that run on Hybrid Chains. This means the parachain runtime defines which parts of its business logic/business primitives can be used from smart contracts. It's a big thing. In the past I've described it as "smart contracts as second-class citizens". It's the same thing, just tying it in with the Hybrid Chain narrative now. [Here is a more detailed explanation of the concept](https://use.ink/how-it-works#use-case-2-smart-contracts-as-second-class-citizens).

#### Ease of Use

We have an ink! playground: https://ink-playground.substrate.io. It allows for playing around with ink! in the browser, without having to install anything.

The person that developed it has migrated to a different team at Parity, it is outdated and we are working with W3F to have a grant for a community team to own and maintain it.

#### Multiple L1's

It's an ongoing effort to convince more chains of including `pallet-contracts` and ink!. Our audits have only been finished a couple weeks ago, so we can only start this effort fully up now.

The specific plan here is to approach selected teams with a proof-of-concept project, having modified their chain to include `pallet-contracts`. And have an ink! contract running on top of it.

It's unclear how much work this will actually be. We don't think it should be much work. We'll try it out with Encointer. The Encointer parachain provides Decentralized Identities (DIDs) with proof-of-personhood. They could add `pallet-contracts` so that an ink! developer can have an identity primitive in their smart contract. One could develop a DAO that has a baked-in notion of "this is real person so-and-so". Or voting systems with built-in sybil resistance. Or or or.

## Moonshots

We have a number of experimental research projects. If successful, they will each bring a magnitude of improvement to our stack.

* The Merge: Enabling developers to easily upgrade their ink! smart contract to a parachain. [Forum post](https://forum.parity.io/t/the-merge-ink-frame/1138).
* Ethereum-RPC Compatibility: Would enable using Metamask with ink! contracts. A lot more Ethereum tooling would also work out of the box for ink! contracts. [Tracking Issue](https://github.com/paritytech/substrate/issues/13891).
* RISC-V: Switching the binary format of contracts from WebAssembly instructions to RISC-V instructions. Would yield multiple magnitudes of performance improvements, resulting in higher transaction throughput and less user fees. [Forum post](https://forum.polkadot.network/t/exploring-alternatives-to-wasm-for-smart-contracts/2434).

## Asks

I have a couple of asks. The big theme here is that with ink! we want to embrace our vertical integration further. We want to have all ownership for the products in our team and all significant responsibility should reside within a role in our team.

### @Bjoern: Roles that I want to hire into the ink! team asap

The biggest holdback for ink! currently is the roles that are shared with other departments. Symptoms of this are:
* Having no influence over the prioritization of other departments and being deprioritized/denied resources for projects that are important for us (SEO, NFT creation, marketing for in-person meetups, …).
* Onboarding people into our project without any influence over the career/growth of those people. Lauren was onboarded for half a year, it worked great. Then we were informed that there was a decision that she'll be switching to a new role asap. This throws us back to where we were over half a year ago. It was not possible for us to anticipate this role change and hire someone new in time.
* There is a lot of unneeded communication overhead and it's not possible to be lean and fast. There are mistakes happening because people are not in our team and work on e.g. some Asana ticket that is decoupled from us. They are lacking domain knowledge about our products and make mistakes because of not understanding the context. It requires us to control if the work was done as intended by us. This process of explaining what is needed, the relevant context, reviewing the work, and iterating over it, is a huge time overhead that would for a large part be avoided by having these roles locally.

Specific roles:

* _Technical Project Manager_
This role is mostly about taking things off my plate and enabling me to focus on where I contribute most value. No action needs to be taken here, I already interviewed two people, the JD is being put online this week.
* _Developer Relations Engineer_
A new Lauren. The role is about creating educational material and taking over some communication work. It's too many teams now and the community has gotten too big. According to Lauren & Kori the hiring for a new DevRel position is currently blocked, I got an explanation where I couldn't follow the reasoning. This could be unblocked by a magic DM from the CEO.
* _Animator & Video Editor_
Annika from MarComms is helping us with animations, but she has other priorities and only seldomly time to work on them. We're heavily constrained by this and there is a long backlog of videos that Lauren and me have scripted, most are already recorded, and our illustrator already illustrated them. Just animations, cleaning up the audio and cutting the video is missing. It will be easy to onboard someone here.

This is how the smart contracts umbrella would look then:


The lila bubble is our current freelancer (I don't have a photo). The white ones are yet to be hired. The Team Assistant role will be newly filled, the work scope of our current assistant changes.

### @Peter: Simon Telezhkin
It would be helpful if you could approve Simon to do an NFT project with us. I have worked with him in the past. We have a concept for viral ink! content. Steve and Benoit have been briefed earlier this year. I have been trying to find budget for this since then. It will take Simon only 2-4 weeks. It's not a lot of money.

### @Steve: Add a top-level smart contracts page on polkadot.network

It would be helpful if you could make a page "Smart Contracts" on polkadot.network heppen (likely under Features).

I suggest to feature ink! there among other smart contract technologies. The page could e.g. compare them against each other. We have actually no backlink from [polkadot.network](https://polkadot.network) to [use.ink](https://use.ink) currently, having some would be good for our SEO.

### @Steve: Brand and market Alex' `pallet-contracts`

This is something that I don't want to be involved in, but I think you should focus your energy on this endeavor instead of ink!. ink! is in a good position, we have a grip on things. The following is where a lot of work needs to be done. I have discussed the following proposal with Alex, Santiago and Ricardo. We are all on the same page here. I'm happy to facilitate this conversation.

My premise is: _`pallet-contracts` is the most undersold and underrated product at Parity._ What Alex and his team have created is an alternative to the EVM. But we never tell the story like that. The name alone — "smart contracts module" — already devalues the entire product.

The `pallet-contracts` brings a number of improvements and innovations over the EVM. The concept of storage deposits, the distinction of contract upload vs. contract instantiation to counter state bloat, chain extensions, WebAssembly (Wasm) as the binary format for contracts, etc.

There was never any thought put into branding. It was just plainly called Substrate's `pallet-contracts` and a void was left with the branding for it. This is an unfortunate situation, as it has resulted in ecosystem teams filling this void with stories they make up. Specifically teams have taken on the narrative of "Wasm contracts", "Wasm contracts are better than EVM", "Wasm contracts are the future", etc.

But Wasm is not the point here. Wasm is just the binary format that contracts are compiled to. This was a good choice at the time and we have some advantages over the EVM because of it. But it's just one characteristic of `pallet-contracts`. The big point is that we have created an alternative to the EVM that improves a lot of shortcomings. Wasm is just the format for contracts, but the real innovation is so much more.

Also, we will likely transition to a better binary format than Wasm for smart contracts. It's one of our moonshots and it will (hopefully 🤞) improve transaction throughput, user costs, etc. by magnitudes. We are experimenting with RISC-V as an alternative to Wasm. No one else in the space that we know of is thinking about that. [This](https://forum.polkadot.network/t/exploring-alternatives-to-wasm-for-smart-contracts/2434) Polkadot forum post contains more details.

So teams doing stuff like this is quite bad:




It's not really about Wasm, the innovation is way bigger than that. It's about the `pallet-contracts` instead. Them forming all their marketing/narratives around "Wasm contracts" is the wrong direction and it will become an issue as soon as we start going for RISC-V as the contract format instead. Then they will still be using `pallet-contracts`, just that this one characteristic changed.

__Action Item 1: Get rid of the name `pallet-contracts`, rename to `Polkadot Contracts Engine (PCE)`.__
There should be branding and a logo for it. The name should clearly convey what it is about, so no naming in the likes of "Frontier". There is no industry abbrevication conflict for PCE, the abbreviation will be fine. I think this would be a good name.

The branding should be all about Polkadot, it should not be about Substrate. This is part of the bigger conversation Substrate vs. Polkadot SDK that you are having. In my opinion, you should just kill Substrate as a brand and rename it to Polkadot SDK. Substrate is a dying brand. The name "Polkadot Contracts Engine" will tie in perfectly with that transition.

The main controversy here will be that the Substrate repository would then contain a pallet named `polkadot_contracts_engine`. Introducing a Polkadot reference in Substrate will be a novum. So there needs to be strong backing from leadership.

__Action Item 2: Push this narrative: "Every parachain should have the Polkadot Contracts Engine."__

Each parachain has a use for smart contracts. They can enable the community to innovate with the chain's business primitives, which in turn drives their token usage.

This ties in heavily with Rob's Hybrid Chains narrative. Parachains can make unused block space available to the community by adding `pallet-contracts`. Developers can then upload smart contracts permissionless and consume the available blockspace. MarComms can help putting this narrative out there and into e.g. the Polkadot website.

__Action Item 3: Emphasize the Polakdot Contracts Engine as a research plattform.__
What we offer is that any programming language that compiles to Wasm can be deployed as a smart contract. This is a big thing. Researchers can experiment with new ideas for safer and improved (smart contract) languages, without having to build their own compilers. They can just use an existing language and create a dialect for it.

But it's not just about safer and improved languages, it's also about using languages in a heavily resource constrainted environment and their performance there.

Smart contracts are particularly interesting for security researchers.

The point here is not that researchers are our primary customer group, it's about establishing the PCE as a leading plattform in the smart contracts space, pushing the boundaries, embracing experimentation and research. And this is the stepping stone there.