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:
Writing contracts in Solidity and deploying them to Polkavm, does this mean we still use ECDSA signatures and keccak256 hash functions? Are there any precompiles that can use Polkadot’s sr25519 signatures and blake2 hash functions?** ECDSA seems to have become a problem for Ethereum. Using sr25519 on Polkavm might be a solution for account abstraction.
I’m using Foundry+viem; Hardhat and Ethers.js seem outdated. Is there any plan to support viem?
Is there anything similar to the randomness precompile on Moonbeam?** VRF is very necessary for many smart-contract.
@Alex I tested out the JSON-RPC for integration and things are looking good – but, I found a couple of issues here. These are the 2 bottlenecks for EAAS integration:
Yes this is planned. @pgherveou has a WIP PR for that but we is currently busy with building an indexer so the links within Metamask work.
Yeah we should build a docker in our release pipeline. But I am not sure how exactly that docker should look like. Do you have more precise requirements?
Not precise – any Docker design that matches the etherscan.io/verifyContract flow (contract address, chainid, solc metadata, code format, code) and comes back with bytecode that matches “eth_getCode” or with error diagnostics works.
Hi All - for Solidity on Polkadot to be useful, I see the need to be able to:
Do cross-contract interactions (instantiation, calls)
Is this already possible? Can you share an example?
Do Polkadot cross-chain calls
The ability to send raw XCM from a Solidity contract
There should an abstracted approach as well for those who want to hit-the-ground running building cross-chain solutions on Polkadot w/ Solidity without having to become an XCM expert
Can we please add integrating Polytope Labs’ ISMP to the roadmap? Or provide an alternative solution that you will commit to and add to the short-term roadmap
We cannot create real-world, meaningful cross-chain solutions on Polkadot without being able to guarantee cross-chain execution
Do wider ecosystem cross-chain calls
e.g. call a Solidity contract on Ethereum
Could be a good use-case for Hyperbridge and/or Snowbridge
Polkadot infrastructure on the Ethereum side
Snowbridge already started this with its agent contracts
We need to create a “hub” of contracts on the Ethereum side that makes it easy to build cross-chain contract solutions
e.g. an out-of-the-box Polkadot Hub compatible DEX on Ethereum
Precompiles to access underlying runtime features
Polkadot Hub runtime
a wrapper for smart contract developers to interact with Polkadot Hub pallet methods that are whitelisted
As of today, the following js libraries and utils work nicely with ink! and can be used to build dapps: