This is possible. Cross contract calls can be done using the normal Solidity syntax.
This will become possible through an XCM pre-compile that will allow executing, sending, and receiving XCM messages. At first, we will implement XCM. We can also look at other protocols or allow a more low level transport where other protocols can be built upon.
Agreed. We should have an Ethereum compatible DEX. We will have something similar to Moonbeam’s XC20 that allows interacting with AssetHub assets as if they were ERC20 contracts.
We will built pre-compiles for all relevant runtime features. Just exposing dispatchables won’t work because they can’t return data. They are also not stable enough and it is cumbersome to use them. Having pre-compiles for each API will make it easy to consume.
As of right now PolkaVM is part of the runtime. So Smoldot supports it out of the box.
The RPC proxy is a different story. We made sure that its endpoints don’t become part of the client spec to not increase the burden of implementations like Smoldot. If you run Smoldot locally on your computer you can run the RPC proxy and connect it to Smoldot already just as if it was a full node. However, when you run Smoldot in the browser that is not possible out of the box. It will require some work to compile the proxy for the browser and incorporate it with substrate connect.
Polkadot’s two main tenants: shared security and interoperability.
However, as we have learned, there are limitations to what can be built regarding synchronicity for dApps that want to leverage a cross-chain solution. JAM aims to alleviate this. I do believe it makes sense for certain operations to leverage cross-chain interactions and others simply do not scale in terms of composability. Developers will have to find a sweet spot for this or we, as stewards in Polkadot, should give them a clear and effective pathway to build decentralized applications in a multi-chain, multi-service world.
We expect this to complete in Q3. If it isn’t a one-shot we can add individual pre-compiles as soon as the corresponding functionality gets migrated. Out of curiosity, what is the project you are working on?
But with the advent of Solidity running on native Polkadot, we are exploring the possibility of creating a Solidity smart contract for the DAO, to deliver a true Web3 experience. However, we are constrained to what is technically available.
I would love to have your team’s feedback on this! (and find alignment) Perhaps this could be the first real-world use case that could drive the first set of features for the Polkadot Hub.
Is there a known solution for this? Just tried to deploy on Westend hub, my dapp depends on it and would love to launch on hub when it comes to Kusama or Polkadot. Is there an issue link I can follow? I’m pretty motivated to get this working, and hopefully it is an easier way.
Yes. Since we have on-chain constructors this pattern is simply not necessary. You can just do the customization in your constructor. When compiling a Solidity contract with our compiler it will not embed the actual code into the contract which contains the create2 call. It just embeds the hash. So even when the contract you are deploying is big it will be still gas efficient.
Hello Miles, just checking if you’ve seen this post? It’s the latest comms on the status of solidity smart contracts so might have some info you are after.
There’s also links in there to log bugs and issues directly. I saw on another forum post you mentioned specific functionality you need, please feel free to log there to get it in the official “queue”.
You would just use the normal factory pattern. Solc will include the whole Child contract into ChildFactory. This is why people mess around with EXTCODECOPY in order to stitch together the constructor: ChildFactory will be too big otherwise. Our resolc compiler will only include the hash of Child into ChildFactory. As long as one version of Child is already on chain this will just work. This is because we keep the constructor of Child on chain. Upcoming versions of our tooling will make sure that the code of Child is already on chain when deploying ChildFactory.
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
/// @title A simple contract whose instances we’ll deploy via a factory
contract Child {
uint256 public value;
address public creator;
event ValueSet(address indexed setter, uint256 newValue);
/// @param _value Initial value to store
constructor(uint256 _value) {
creator = msg.sender;
value = _value;
emit ValueSet(msg.sender, _value);
}
/// @notice Update the stored value
function setValue(uint256 _value) external {
value = _value;
emit ValueSet(msg.sender, _value);
}
}
/// @title Factory that creates new Child contracts
contract ChildFactory {
/// @notice All deployed Child instances
Child[] public allChildren;
event ChildCreated(address indexed childAddress, uint256 indexed initialValue);
/// @notice Deploys a new Child with the given initial value
/// @param _initialValue The value passed into the Child constructor
function createChild(uint256 _initialValue) external {
// Deploy a new Child contract
Child newChild = new Child(_initialValue);
// Track it
allChildren.push(newChild);
emit ChildCreated(address(newChild), _initialValue);
}
/// @notice How many Child contracts have been deployed
function childrenCount() external view returns (uint256) {
return allChildren.length;
}
/// @notice Get the address of a deployed Child by index
/// @param index Position in the allChildren array
/// @return childAddr Address of the Child contract
function childAt(uint256 index) external view returns (address childAddr) {
require(index < allChildren.length, "Index out of bounds");
return address(allChildren[index]);
}
}
Do you know if any tests have been done for OpenZeppelin upgradeable contracts? They use an initialize function in place of a constructor. Maybe you’re talking about a different constructor? Thanks!
The OZ upgradeable pattern dooes work on our platform in the same way. Even though we have on-chain constructors you still need to use the initialize function when using this pattern: Reason is that the proxy delegate calls the implementation contract in order to initialize the storage inside the proxy. It is an unrelated issue.
The storage of the implementation contract is never used and hence never initialized. A constructor doesn’t make sense here.
