-
Notifications
You must be signed in to change notification settings - Fork 21
Conversation
Wdyt about this?
|
The cherry-picked branch sounds like a good idea! We need to make sure that Cumulus and Polkadot are also up to date. This means we need to:
|
Also updated some fields to point to the relevant `canvas-node` resources.
The reason that my code wouldn't compile was that there was a mismatch in the `Block` type being used by the service and the RPC.
@TriplEight Hey Denis, do you know why the Linux pipeline is failing? The error is:
|
Hey guys - I am sure you are aware of the limitations on the PoV size that might block you here, right? I also am under the impression that other optimizations will be needed and (possibly) some work on the sand-boxing upstream for the contracts pallet in the context of parachains/PoV that are missing. Happy to be wrong here, many people are looking for contract enabled parachains 😁 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recommend setting all of these to zero to prevent eviction of contracts:
type TombstoneDeposit = TombstoneDeposit;
type DepositPerContract = DepositPerContract;
type DepositPerStorageByte = DepositPerStorageByte;
type DepositPerStorageItem = DepositPerStorageItem;
type RentFraction = RentFraction;
type SurchargeReward = SurchargeReward;
Also we should set resolver = "2"
in our root Cargo.toml
. Substrate does that, too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Requesting changes because we shouldn't enable unstable interface by default.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good so far.
// One XCM operation is 1_000_000 weight - almost certainly a conservative estimate. | ||
pub UnitWeightCost: Weight = 1_000_000; | ||
// One UNIT buys 1 second of weight. | ||
pub const WeightPrice: (MultiLocation, u128) = (X1(Parent), UNIT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The constant WeightPrice
is unused.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It comes from the parachain template (and is also unused there). I'm gonna leave it here just to keep the diff
smaller, but it should be addressed upstream next time the template gets updated
I think this pulls in some updated dependencies which breaks the build.
This is for BEEFY, Polkadot, and Cumulus
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apart from the runtime configuration it looks good to me.
Co-authored-by: Alexander Theißen <alex.theissen@me.com>
We'll be creating an updated config later on.
// Give your base currency a unit name and decimal places | ||
let mut properties = sc_chain_spec::Properties::new(); | ||
properties.insert("tokenSymbol".into(), "CAN".into()); | ||
properties.insert("tokenDecimals".into(), 12.into()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, we want to use the relay chain currency here and not have a separate one. Does anybody know if it's sufficient to just remove the properties
altogether?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to keep the properties here and align them with the relay-chain we'll connect to.
E.g. Kusama
let mut properties = sc_chain_spec::Properties::new();
properties.insert("tokenSymbol".into(), "KSM".into());
properties.insert("tokenDecimals".into(), 12.into());
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll also need to do native token teleport in order to use the relay-chain token.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also means we do not need our own faucet but can just point users to the rococo faucet?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This also means we do not need our own faucet but can just point users to the rococo faucet?
That's a good point, hmm, is it even possible to have dedicated parachain endowed accounts then? 🤔
This is a WIP attempt to turn the
canvas-node
into a Cumulus based parachain. Right nowI'm using the
substrate-parachain-template
as a reference.There is a problem with this though. The
substrate-parachain-template
is usingSubstrate branch
polkadot-v0.9.9
and thecanvas-node
needs to follow a fairly recentversion of Substrate in order for the contract functionality to work.
We've worked around this by creating a branch based off Substrate's
polkadot-v0.9.9
which cherry-picks the
pallet-contracts
commit which we need. We've then used thisSubstrate branch in BEEFY, Polkadot, and Cumulus.
One thing we can do is wait for Substrate'spolkadot-v0.9.10
branch to be cut (whichshould happen this week) and that would make it a bit easier to keep the right
dependencies synced up across the three repos.
It looks like the
polkadot-v0.9.10
won't have the required changes for us. While the custombranches work for now, we should really move away from them quickly once
polkadot-v0.9.11
is cut.