I would like to get everyone’s thoughts on where they see the future of WebAssembly ink! smart contracts in the Polkadot ecosystem and Web3 as a possible standard.
The vision of supporting EVM/Solidity as a legacy and future of Wasm for Web3 resonates with me, but as it stands it looks like there is not enough adoption or demand for ink! based DApps ecosystem.
Also, I have the impression that the choice of Pallet development for application logic is encouraged over ink! – this is understandable for teams developing their own custom Substrate, there are still places where it makes more sense to do the implementation in ink!
The main difference between smart contract and pallet development is that they are intended to occur at different levels of the stack. Teams building on top of parachains are going to need smart contracts.
That said, I think EVM is here to stay, at least for the foreseeable future. I view the EVM’s niche as similar to C. It’s the most widely used base for smart contracts. What we’ve seen from systems programming is that even when better alternatives emerged throughout the 90s, 2000s, and 2010s, C remained and indeed remains a staple of that world.
My view is that we can build out and encourage ink! to be a better alternative for smart contract development, and indeed parachains can support both EVM and ink!, or just one of the two.
This is where Astar Network comes in. We are building a smart contract parachain that supports both EVM and Wasm. As far as I know, the Wasm contract pallet developed by Parity is going to be audited. And once it is finished, Astar is going to support the pallet and ink! smart contracts. We expect the transition from EVM to Wasm but this transition takes a long time or EVM still remains in the future as Rob said. I personally forecast that we can support commercial ink! smart contracts in October or early November.
btw, Shiden, a Kusama parachain already supports ink! smart contracts. The problem is missing a lot of toolings to develop ink! smart contracts. OpenBrush is great but we need more.
If you squeeze your eyes enough, both ink! and FRAME are doing a similar job. As @rphmeier touched on, they are on different levels of the stack. It’s always been considered that ink! is an easy tool but a bit blunt, and FRAME allows you to do more things, including cutting your leg off. For example, FRAME Runtime can write every storage entry, and it can remove the :code. Another example, is a Substrate Runtime that has to be careful about resource usage, for that it has to perform thorough runtime benchmarks. It also is not allowed to panic, otherwise it’s a risk for DoS.
But, then there are these two ideas:
There was an old idea introducing try…catch functionality into Substrate Runtime. It was partially implemented in the form of transactional storage.
Recently, a way how to do a very low overhead gas metering on wasm was discovered. The primary motivation is to fit it into PVF execution metering. However, potentially we could introduce it into Substrate Runtime.
Those two ideas might allow us to bring the contract-like environment to FRAME, blurring the line between the two. I am not sure that would kill one or another, but maybe it will be two flavors of one thing.
My views are similar to the points made by @rphmeier and @sota. Both ink! and EVM can co-exist, and it’s a matter of time until we see more adoption of ink! but some more effort needs to be put into the tooling.
There is great value in parachains supporting both EVM and ink! 1) for interoperability and support of a major developers segment 2) I see future DApps written with cross-VM components, there are things that ink! / contracts-pallet can do that EVM can’t, for example, access to extrinsics.
Any Smart contracts is a platform is highly sensitive to network effects. EVM has the massive first mover advantage and will always be around as @rphmeier pointed out. However, we can partly break this network effect by allowing ink! contracts to call EVM contracts and vice versa. That is not easily possible today but planned to make this happen.
Agreed. This is why Parity develops pallet-contracts and ink! in house and invests resources to make it the best it can be. pallet-evm is still important for onboarding but eventually we hope people to migrate over to ink! (or solang) to profit from the improvements that pallet-contracts made over pallet-evm.
Parachains is just Parity’s main product. Understandable most of the things one read is about pallets. However, those two pathes do not even start to compare. Creating a parachain is a much more involved process for two reasons: First, you need a lot of money to get a slot and make sure to keep it. Second, writing a runtime is more demanding because any panic or botched benchmark can put your product at risk. All of this are non issues in contracts.
That said, this is one of the most common questions in my experience: “ink! or FRAME”? The realization we had is that those are basically doing the same thing: A syntax sugar heavy framework for writing on-chain logic. We are currently investigating merging those two efforts: You will then be able to compile the same code as either a contract or a pallet. This is still early but it will definitely solve this problem of not knowing “what to start with”. You always start with a contract because you are already writing a pallet while doing so.
Apart from merging FRAME and ink! together there are also some core changes which are needed for this:
This will enable the runtime to be allowed to panic without repercussions and remove the need for benchmarking and all the dangers and tragedies that come with that. I discussed this with @pepyakin and we think it is realistic to make this happen.
Best place to start your learning journey would be here:
Could you describe more about the problem you have, what kind of tooling do you exactly need, what are concrete requirements? Appreciate more information on the topic (here or on Telegram).