working on 500ms blocks, works as a prototype, now working to make it ready for production
RFC 138 - Election mechanism for invulnerable collators on system chains #138
currently, these are configured. People are fighting for these slots. The RFC is intended to improve the process. maybe change the system more fundamentally?
Donal: currently decided by the managers of the bounty that pays out collators. original set at genesis. if someone wants to challenge it, they need to do an OpenGov ref. to become a regular collator, putting up a bond is sufficient. agree that we need something better. Having it as bounty adds overhead
having some kind of collator nomination mechanism would be good. unclear which one.
collators only get paid to produce blocks but are not penalized when they don’t produce a block
Oliver: is there a way to prevent tx censorship?
Basti: you could force-include it through the relay
Declaring your intention to be a validator on the relay chain moves to AH and is then communicated to the relay chain. Validators do most of the work on AH and then submit session keys to AH. One more month of work on this.
so far the staking system on Polkadot has been one big experiment of how we can push this. In return, we got a very high-quality validator set. This is the justification for this complex system. Putting this on a parachain is a very big step. It’s a feat not done in any system with similar properties.
A version of this will be on AH-next on Westend soon. By the next call we will do the migration on Westend.
Integrate RFC 97 Unbonding Queue as part of the migration. The one that reduces unbonding time is asked for by a lot of people.
migrating crowdloan leases so that they can be unlocked on AH
account translation sovereign accounts. They cannot use the same address as before without some kind of escape hatch
versioning debate from last call: had debate on it. we are going to keep most of crates in their normal semver versioning. and one self-explanatory version on the umbrella crate
jam client implementation of "graymatter" - importing safrole and fallback performance tests from other teams. soon join testnet.
I saw that work has been picked up on Optimistic Project Funding. What is the status Basti?
Basti: It is being worked on. Had a call with a guy that works on it and I gave him some directions. I am happy to get more people involved. The community for sure wants it. if you want to be involved, you can get invited into a channel
Oliver: There is this Rust bounty now, so it would be a possibility to fund it
Snowbridge V2: Most of the code is ready. Targeting 2503 SDK release end of March.
We need some of the features for Polkadot Hub, especially to call contracts via the bridge.
XCM support for contracts. how to expose underlying functionality to contracts
how do we extend ERC-20 to allow cross-chain token transfers?
any XCM changes regarding migration Relay to AH.
XCMv5: almost complete. tying up some lose ends. sometimes soon integrating into Polkadot runtime
all of this is coming together more or less at the same time. Hub with contract support. XCM migration. Snowbridge V2, XCMv5.
Hub on Polkadot for Q3. For Kusama on Q2.
Daniel Shiposha: is there something I can read on XCMv5? My collueagues and I work on similar problems for EVM compatibility.
Adrian: Ethereum has many complex solutions to do things that are easy for us. It is an ongoing philosophical debate if we should follow Ethereum to stay compatible or rather push for our own solutions.
working on slot based collator improvements. production of multiple blocks per slot. have 6 second slot duration, and one author produces as many blocks as there are cores. so chains don’t need to change the slot duration.