2025-06-20 Technical Fellowship OpenDev Call

1

previous: 2025-05-15 Technical Fellowship OpenDev Call
video: https://www.youtube.com/watch?v=7OT22B3geBY

Next releases responsibilities

  • Oliver: 1.6
  • Kian: The one after

Rank 1 - Gavin

(submitted a video)

  • mostly refactoring,
  • working on 0.7 paper: practical concerns based on empirical experience
    • mostly augmented economic metering: economic means of getting the metering closer to the actual time taken on physical hardware.
    • going to take at least a month or longer

Rank 6 - Basti

  • gave Presentation about coreplay at Protocol Berg
  • handled a security issue: bug from 2020, one tx could stall the chain
    • could produce a block but others would fail to import. then nodes would start banning each other
    • post-mortem in the forum
  • been working on 500ms blocks, discussions w/ Sebastian around interfaces
    • Q Kian: path for someone to move 500ms? runtime upgrade? collator upgrade?
    • yes, runtime and collator upgrade. validation to accept multiple blocks in a single PoV. First upgrade the nodes, then the runtime.
    • optimizations for the future:
      • if you have faster blocks, you might not want to do onInitialize/onFinalize in every block.
      • The scheduler doesn’t need to run every 500ms, it could run every 6s
      • if the first block is empty, could you make the next one bigger? instead of injected weight limits
      • for the relay chain it is a single state transition

Rank 5 - Kian

  • Westend AH Migration mostly done
    • staking: we are in a fine position
    • not the same situation as Kusama and Polkadot, on Westend there are only 16 validators. we run testnets for that
  • made a presentation, sharing how the Polkadot staking system is working - https://www.youtube.com/watch?v=QlZDIuSIYmE -
  • getting ready for Kusama, so far surprisingly good, because nothing is on fire. talking to auditors
  • Q: how was the Rank 5 interview
    • Gav emphasized the things that are described in the manifesto I should make sure I do more of
  • Q re AH migration: XCM should we move the reserve location of the DOT currency to parachains?
    • reserve location would be AH
    • Cisco: ID will be the same. ID will still be relay chain.

Rank 3

Oliver

  • AH migration
    • done on Westend
    • next Paseo, working with the Paseo ppl, first update Polkadot runtime, then we have script to mirror that for Paseo runtime.
    • done on Westend, merge changes to SDK and then to runtime for Paseo, Kusama, Polkadot
      • August 15th Kusama
      • September for Polkadot
  • working on 1.6 release
    • weight updates, benchmarks are very slow
    • currently CI check, contract fixtures dont compile
    • with 2503 SDK
    • propose for Kusama, will include contracts
  • received question for Fellowship salary
    • since we receive salary from Parity. Is there a conflict of interest since we receive salary from Parity and the Treasury?
    • Basti: Parity also has Polkadot focus. In general, I don’t see a COI.
    • Kian: raised this with Gav in the interview. I don’t think there is a COI, but I do wish there would be more agreement between Parity and the Polkadot DAO, there are individuals with higher responsibility and rank. And most of us align priorities with Parity.
    • Tommi: Optimistic Project Funding was expressed as wish from the DAO and it did not really move forward.
    • Oliver: Fellowship is QA body
    • Basti: It is not only QA. Manifesto says it’s about retaining knowledge about the Polkadot protocol.
    • Oliver: There is confusion for people looking from the outside about why there is issues on one side and developers on the other side and the developers don’t work on them
    • Kian: might also not be visible that there goes a lot of effort in maintenance
    • (this transcript is heavily shortening the original conversation, please watch it for full context)
  • Q: Elastic Scaling in the current release?
    • Basti: It is already out, but Andrei and Rob are mitigating one additional security consideration

Jan Bujak

  • secure gas cost model
    • finished worst case secure gas cost model
    • recommend watching Gav’s talk at Protocol Berg.
  • Q Kian: tldr on metering?
    • i did a lot of benchmarking on the numbers gav presented - PVM vs EVM
    • when running code you want to make sure it takes a bounded amount of time. hard to model because modern CPUs use a lot of tricks to make the coe go really fast. but these are typically average case tricks. so you could have a malicious actor who writes code that makes those tricks not work and then the code runs really slow.
    • for secure gas metering (doesnt allow anyone to DOS), you want to assume the worst case, but in reality you will run average case. that is where the idea of subjective metering comes into play. which is doing the worst case objective metering and the subjecte wall clock based metering and there will be consensus among the validators; stake your funds and claim that your code runs with the average case. if that is false, it will get slashed.
    • as Gav said, a part of that is already live on Polkadot. We will essentially port this to JAM. Even with worst case gas cost model we are faster than EVM

Rank 2

Seun Lanlege

  • folloiwng up on prev discussion BLS Beefy - contact in W3F researchers, still WIP, so I can wait. last I heard they are waiting for an RFC to pass even though the code has already been merged. From what I understand everything relating the code is already in.
  • Security amendment to 0048 ownership proof by drskalman · Pull Request #147 · polkadot-fellows/RFCs · GitHub
  • expected to see Sayed on the call, who I think is responsible.
  • Hyperbridge depends on this upgrade passing soon. will allows us to decentralize our conensus prover. one of THE most important features Polkadot can feature today.
  • Basti: have never seen anything like that, a test network trying to use this kind of code. there are unit tests, but I don’t think there exists an upgrade path. I remember last time it was agreed you do it and the fellowship pays for it. I think it is not just the RFC holding us back.
  • Seun: Would be good to have a working group. I will follow up with them.

Tsevotomir Dimitrov

  • Performance changes on the dispute handling. We want to speed things up a little bit. followed a few leads. one of them is caching on key lookups that are taking quite a lot of time.

Sebastian

  • finalized eliminate forks on relay parent blocks, comments, polishing, testing, will be in the next release
    • just need to update the config
    • likely reduce forks at cost of higher xcm message latency
    • by working on that I realized that the parachain runtime config is convoluted. maybe should do some cleanups
  • worked on reviews
    • reviewed bastis 500ms block stuff
    • transaction pool topics. transaction pool will be default in next release in 2506 will not have default, but on next patch release. if there is something going wrong with the tx pool we will know it because it comes as an extra release

Someone Unknown

  • celebrating promotion to rank 2. planning to be rank 9 before 2040
  • impl of RFC 4; was renumbered to RFC 145. lots of interesting challenges and Jan helps when he gets stuck. will share when he gets some interesting results.

Rank1

Pablo

  • working on signing. enabling improvements on the consideration trait. allows pallets handling deposits for storage
    • not being widely used, in a couple of pallets already, but it is not everywhere. should be on more pallets that use deposits; standardized the process of handling deposits.
    • easier to use in new pallets
  • migrating the scheduler pallet to use the agile coretime. rn waits the num of blocks increases monotonically, one by one. some parachains might not be wanting to have constant production of blocks but still use scheduler
    • for that we might use the relay chain block #
    • sync backing of prod blocks
    • whats the best way to do it?
    • 2 proposals rn
      • one is issue
      • and one is actual proposal to make an actual change on the pallete scheduler
  • introduce a couple of PBA alumni to the Fellowship. we are tackling on the task to use the new fungible trait instead of the old currency trait

Daniel Shiposha

Alain Benzikofer

  • PR to use XCM in Encointer chain for communities to manage their community Treasuries responsibly
  • use stablecoins

George Pisaltu

  • working on proof of personhood - made public
    • the people pallet
    • origin restriction pallet
  • most interesting stuff is still private. still working.
  • DIM 1 is basically complete with benchmarks, tests, seems to work, in advanced phase of testing
  • DIM 2 is almost done, various tests and benchmarking, currently auditing the code if it is indeed secure

Next month there is the physical Fellowship meeting.

5 Likes