The tracing RPCs will come after we are on Westend. They need some more work. Talking about those two:
debug_traceBlockByNumber
debug_traceTransaction
So far we don’t have a well thought out release plan. It is a but more complicated since there are two versions involved: The solc version + the resolc version. So we kind of need to construct a matrix of versions we want to release. And yes we plan to release them as dockers.
Hey, sorry for asking a question far at a far later than it should have been asked, but for the sake of context and documentation, what was the thinking around going down this path with PolkaVM, rather than just jumping on top of Frontier which was pretty proven and battle tested?
One clear downside is the time to integrate this stuff into the Polkadot Hub.
So what were the major upsides? What kind of long term gains can we expect because of this decision?
Any major drawbacks for someone who would want to argue the other side?
No need to write a whole new answer if it was already written somewhere. Please just link me.
The main reasons can be found in this post, other posts and in #885. They are indeed a bit scattered, let me quickly summarize:
Frontier does not allow using existing AccountId32 accounts
The EVM does not cut our performance requirements, add to that we found the Frontier EVM implementations to be even slower than the reference EVM
Frontier does not support other contract Languages than EVM based ones. And adding multiple runtimes for supporting other Languages brings it’s own problems.
Frontier, once added, can not be removed again
We expect parts of our stack to be directly re-usable with JAM
Those translate roughly to the following long term gains:
Seamless integration, better user experience
Unlock new contract use cases which are currently impossible on any non-domain-specific blockchain ecosystem
Enables building a more diverse and bigger contract ecosystem, in turn allowing adoption and market share to grow way beyond the scope of EVM
Avoiding major maintenance burdens
Less time and effort required once JAM is around the corner
TL;DR: With our PVM based solution Polkadot will offer a superior, innovative and future-proof contracts product instead of being just another Ethereum side-chain. (There is nothing wrong with Ethereum side-chains, they are great but note that this problem is already being solved in our ecosystem)
Personally I’d like to add that I think it’s fair to say that we are moving relatively fast. The additional time spent is only in the realm of a couple months.
At least for fungible tokens we are planning to emulate one ERC20 contract per asset on pallet_asset. Basically having a contract address prefix that determines that this is an asset and then using the rest of the bytes to encode the asset id. For NFT we need to check if there are standards which match well to the existing NFT pallet. But we should change the pallet so that they do if not. The goal here should be that contracts can interact with assets hold in pallets the same way as if they were a contract.
You can also imagine that stable coins like USDT will deploy a shim contract that doesn’t hold the actual asset in its state but forwards the call to pallet_asset. Setting the owner of the asset to the contract. That will allow them some degree of programability without conceding the upsites of being on pallet_asset. Not sure if that is a useful, though. They might want to completely migrate to a contract to take full control over balance transfers.
As everything regarding cross chain interactions this seems to be an open question. Esepcially how to do this in a user friendly way. Hence the push to centralize the platform. However, we will have XCM support within contracts and given a demand there will pop up ways to do this.
An DEX deployed as a smart contract platform will access pallet_asset assets just like any other ERC20 contract. Hence this will “just work”.
As of right now the plan is to give contracts access to those assets by emulating various Ethereum standards as mentioned above. If we notice that they are no longer needed to could think about an automatic migration path. But this is not planned.
Most of the work is actually making the system Ethereum RPC compatible and testing all the various developer tools and javascript frameworks against it. Something that is also necessary for ink! since the plan is that you can write a Dapp that works for both. Of course you could just use ink! as-is and rely on Polkadot.js to write ups. However, that fragments the ecosystem and we could never keep up with the tooling meant for Eth developers.
So the plan for ink! has to also profit from this. Basically making ink! a drop in replacement for Solidity contracts but the rest stays the same. You would still interact with the ink! contract using Meta mask and the Web frontend is only written once (e.g using ether.js).
Basically was ink! has to do to not be dead on arrival is to drop their custom ABI and also use the Ethereum ABI. Otherwise they won’t be able to use Metamask nor would they be ale to be called from Solidity contracts. If you are the underdog: Be compatible. Be a drop in replacement. Then at least the people who want can use it.
At this moment, the ink! alliance is working on making ink! compile to PVM, allowing ink! smart contracts to be deployed on Polkadot just like Solidity-based contracts.
Once that milestone is achieved, it might be a significant point for the alliance to start considering the Ethereum ABI, enabling both ink! contracts and EVM-compatible contracts not only to run on the same VM but interact with each other. Step by step.
As of today, the following js libraries and utils work nicely with ink! and can be used to build dapps:
As of today, the following js libraries and utils work nicely with ink! and can be used to build dapps: