2025-08-19 Technical Fellowship OpenDev Call

Tech Talk
1

Previous: Link

Video

Kian (Rank 5)

  • AH Migration:

    • spent time on testing, what it means to test and dry run multiple times. made familiar with the testing infrastructure and made testing infrastructure accessible to others.

    • next step for migrations is Paseo. To do that, we have to have successful execution of dry run tests multiple times in a row.

    • by the time it reaches Kusama, all Fellowship members, especially those not at Parity, all have responsibility to test and dry run it.

    • so that by the time it reaches Polkadot we can ask other Fellowship members to help with testing OR give approval that it works

    • pass conditions for tests:

      • we have 3 sets of tests. One of them is PETs Polkadot Ecosystem Tests

      • for Kusama all tests have to pass

  • engaged with Blockdeep RFC 97 (flexible unbonding) impl. Their contract is coming to an end. Me and Ankan have reviewed their work high level. Bulk of the work is done. Plan to deliver as soon as migration is complete. Towards end of the year

Oliver (Rank 3)

  • working on Paseo. AH migration. finalizing runtime.

    • ran it with ZombieBite: downloads all the state from Paseo. Runs the migration, does some post-checks: take a snapshot of before the migration and after and check if the differences are as expected.

    • hoping to do the Paseo migration soon.

    • some pallets still missing for the migrations

  • working on JAM node: at 0.6.7 now

Adrian (Rank 3)

  • working on AH migration, on the Fellowship repo, upgrading dependencies to 2506, benchmarking for weights

    • original plan was to do migration and smart contracts at the same time, but because of the migration schedule, we decided to prioritize the migration before the smart contracts.

    • we want the upgrade that brings the AH migration changes to be minimal, so as to not have interactions with other releases and not introduce any breaking points. in order to have that, we decided to have two releases.

      • The first release with only all current changes except the migration. 1.7.0

      • AH changes: 1.8.0

    • 1.7.0 Rollout:

      • next week ref for Kusama upgrade

      • next week bring in all AH code to main; then feature freeze until AH upgrade is done. will take a week

      • smart contracts (pallet revive), Snowbridge v2, XCMv5 feature toggles

      • initiate ref August 25th Kusama Upgrade 1.7.0; by September 7th enacts;

    • 1.8.0 Rollout:

      • runtime release: September 8th submit 1.8.0 for Kusama; live by 15th and 21st of September; gives a week for dry-running;

      • initiate ref 29th September; enactment itself doesn’t change anything yet, just adds the neccessary pallets (and migrator pallets)

      • around 7th October AH enact extra ref that starts the migration

      • enactment itself will not do anything yet.

  • Snowbridge V2

    • coming with 1.7.0 - but needs extra ref to actually upgrade; also upgrades on the Ethereum side

Andrei (Rank 3)

  • Elastic Scaling

    • had finality stall

      • 1.6.1 runtime upgrade enabled on-chain disabling of validators that dispute valid blocks. they get disabled for the whole era

    • successfully enabled RFC 103 on Kusama. Want to submit ref for Polkadot. Once enacted, it is live on Polkadot!

      • using it requires you to have cores. requires parachains to upgrade to 2506 stable

      • going to remove Rust feature gate for RFC 103

    • 12 core elastic scaling performance test - working with engineer

    • Q from Oliver: Elastic Scaling enabled on Relay chain but not enabled by any project?

      • yes, nodes need to upgrade their node and the runtime configuration and use RFC 103

    • Q from Seyed: when you disable the validator, what will happen?

      • will not receive era points this session

      • returns next session

  • Block Confidence

    • what is it? in the ideal world: number of block produced == number of blocks finalized; if you cannot trust a block will be finalized, you cannot have confidence to build on it. block reversals are not nice. with block confidence, you don’t need to wait for finality anymore

    • a parachain has to rebuild blocks for various reasons… we have been collecting data for top failure modes that decrease block confidence and increase block time.

      • parachain consensus

      • connectivity trouble

      • relay chain missed blocks

      • blocks with not many or zero candidates backed

    • have been investigating the efficiency of the statement distribution(?) protocol. introduced new metric: backable candidates at the time of block production that you have on the local node vs. what the block producer has. does not seem to be the problem.

    • problem seems to be at the collator side

    • in order to get more eyes there we deployed the canary parachain on Kusama which started to produce blocks. use it to gather data.

    • focus myself on the collator side

    • Q from DOM: is there a target metric for block confidence?

      • good target would be to only drop backed candidates at the session boundary

      • we will come up with some numbers once we have measured the current data

Dom (Rank 1)

  • backstory: engineer by trade, game dev for a while, discovered Polkadot 2 years ago

  • working on: crowdsourcing contributions to decision deposits RFC 151

    • basti started working on this a year ago. not sure if neccessary to work on this or pick up previous work. might become relevant after the migration

  • next: voting while delegating

Seyed (Rank 1)

  • working on Proof of Posession

    • Basti’s code is trying to prevent new types of attacks, so we need to adapt Proof of Posession

had to change Bastis code

Daniel Shiposha (Rank 1)

working on XCM NFT PR.

  • new nft traits for pallet nfts. we already had them for pallet uniques.

  • also preparing NFT derivatives

  • when NFT derivatives in AH Westend, XCM NFTs will be ready to go forward

Cisco (Rank 1)

  • XCM in smart contracts. Precompile.

    • workshop for PBA alumni hackathon, included POC of using XCM in smart contracts → solidity contract interacting with ink contract

      • will create ink contracts, because they only use existing Rust crates that we use in XCM

      • XCM programs in ink, then anyone can reference that lib in Hardhat/Foundry

    • at this point Cisco decided to drop his internet connection and Oliver initiated a small convo about XCM backwards compabibility

      • Oliver: Solidity contract expected to be immutable. Chain needs to support that XCM version. So we cannot deprecate things

      • can use proxy contracts?

    • Cisco returns

      • Decision was to support v5 forward and never stop support except something critical happens

      • XCM 3 and 4 will stay, but not be supported on the precompile

    • “we need to stop breaking things”

      • Oliver: calls intro extrinsics might break if the signature changes

      • Cisco: people will be able to use transact, but that just means being able to put the bytes in and know the ABI. smart contracts can call each other via transact

  • there is an issue with transfer assets extrinsic: tries to find out who is the reserve for DOT. but the reserve will change with the migration. we made it throw an error if you try to use it with DOT as an reserve transfer.

    • main alternative is the paraspell SDK

    • limited_reserve_transfer_assets

    • reached out to chains etc and will write guides

    • will re-enable it post-AH-migration

  • rank 2 promotion is up

  • first batch of new XCM docs is live - https://docs.polkadot.com/develop/interoperability/intro-to-xcm/

  • will be instructor at next PBA campus and preparing content

Clara (Rank 1)

  • Snowbridge v2 → merged and be ready for 1.7

  • besides that been working on off-chain infra (pools?), updating relayers and UI, hope to have SDKs ready by the time we go live

  • SnowbridgeV2 is on Westend, not on Paseo yet, need to add pallets this week

  • AH upgrade from XCM v4 to v5

  • next up: EVM L2s

1 Like