Video: https://www.youtube.com/watch?v=--99YjEMNH8
Previous: 2025-10-21 Technical Fellowship OpenDev Call
Summary
- Asset Hub migration completed successfully with active monitoring and parameter adjustments during execution
- Two security issues post-migration: origin check fixed immediately, issuance miscalculation (~50% reduction) fixed after 4-5 eras
- 500ms blocks: runtime-side PR ready for review and audit, final node-side PR coming in December
- New JAM gas model finalized and spec’d - optimizes for security and determinism over cost, expects 7x overestimation with ~2x native execution speed
- Social recovery pallet being upgraded and deployed → Polkadot Asset Hub
- Elastic scaling: Asset Hub Kusama moving to 2-second blocks soon, Polkadot early 2025
- Storage reclaim ready for Asset Hub Kusama
- New issuance PR nearing completion with multiple security layers and caps
Rank 6
Basti
- 500ms blocks
- Block Bundling Node Side by bkchr · Pull Request #10477 · paritytech/polkadot-sdk · GitHub
- opened second-to-last PR covering runtime side with benchmarking and testing
- block weight can dynamically adjust up or down (500ms to 2s) based on transaction size needs
- final node-side PR coming to complete the work in December
- multiple zombie net tests included for validation
- rollout plan: merge to codebase first (no automatic activation), test on Westend before mainnet
- RocksDB database issues
- discovered during Asset Hub migration testing - warp sync caused 10ms database access vs nanoseconds on normal sync
- RocksDB was creating single 1GB SST file instead of optimized 64MB files
- fixed with manual compaction: now runs compaction on large data writes and node restart
- affects primarily warp sync nodes
- Asset Hub migration support
Rank 5
Kian
- Asset Hub migration
- overall went well, operated a bit differently from Kusama migration
- used multisig in migrator pallet to actively tweak parameters during execution
- actively monitored
- started slow for safety, progressively doubled speed as confidence increased
- active monitoring and intervention throughout vs Kusama’s hands-off approach
- Security issues (both now fixed)
- Issue 1: missing origin check from old code, fixed immediately after migration
- Issue 2: issuance miscalculation - wrong for 4-5 eras, approximately 50% reduction
- harm was limited, collected records of lost rewards
- mixed community response - some wished it was intentional given March issuance reduction plans
- up to staking participants to decide on compensation claims
- New issuance PR
- working closely with Dom to merge PR for March enactment
Rank 3
Oliver
- Asset Hub migration cleanup
- fixing small fallout issues reported by community
- fortunately limited cleanup needed due to extensive advance testing
- Social recovery pallet
- upgrading existing Kusama recovery pallet
- making it more user-friendly, currently the scope is fairly limited
- deploying to Polkadot Asset Hub with minimal UI
- allows setting friend groups with time delays (e.g., 6-of-10 friends with 30-day delay)
- includes slashing for misbehavior (advantage over time-delay proxies)
- chose recovery pallet over proxies to avoid needing backend for event indexing - everything stored on-chain
- Issuance issue perspective
- value copied from Westend runtime which has ~1/3 total issuance of Polkadot
- lucky coincidence it was ~1/3 rather than 10x or 100x
- would have been caught in testing but still concerning
- Kian: now adding four layers of checks including upper bound constraints and issuance decrease-only rules, protects against math errors, or data errors
- JAM services playground
- playground.jamcha.in
- created playground for experimenting with JAM services
- web editor for C code that compiles to RISC-V for PolkaVM target
- runs through interpreter and returns output
- plan to extend functionality
Jan Bujak
- JAM gas model
- made significant progress, successfully spec’d the model
- at least one team successfully implemented based on draft
- algorithm now final and not expected to change, unless criticial issues
- making additional PolkaVM changes to generate test vectors
- PR to Graypaper coming to include new gas model (target: this year)
- Gas model properties (three-way tradeoff)
- secure: cannot write program consuming more resources than gas estimates
- deterministic: same cost on every machine
- cheap: minimal overestimation of computation cost
- can only achieve two of three properties
- chose secure + deterministic over cheapest cost
- Performance characteristics
- execution speed: under 2x vs native (near-native performance)
- gas cost overestimation: ~7x in general case (5-10x range)
- overestimation necessary for security - must assume worst case for many operations
- non-malicious programs execute much faster than gas cost suggests
- alternative would be wall-clock time (loses determinism, different costs per machine)
- Dom: Is there a gas reclaim feature?
- not currently a feature
- would require second nondeterministic metering layer based on time
- nodes would need consensus on average time for refunds
- possible but not for JAM 1.0
- Basti: might be easier to push to sequencer layer for end-user efficiency
Davide Galassi
- JAM milestone 1 fuzzer
- not yet 100% feature complete, still refining
- current software good enough to begin milestone 1 audit campaign
- coordinating with Web3 Foundation team for fuzzing operations
- they’ll have access to codebase to contribute improvements
- knowledge transfer sessions starting this week (expect 1 month duration)
- auditing expected to start beginning of next year
- Zk applications for Polkadot
- restarted experimentation with dedicated host calls for zk verifiers in runtime
- under experimental feature, not exposed on any testnet yet
- needs RFC and Fellowship proposal to discuss if it is really worth adding host calls
- previous experiments showed nearly 1 order of magnitude speedup
- testing with PolkaVM to measure gains
- immediate application: proof of personhood using Bandersnatch curve
- currently verifier runs entirely in runtime, could leverage host calls for speedup
- test vectors for ring VRF in separate repo (Bandersnatch spec), not in JAM test vectors
Muharem
- Asset Hub migration
- working on issue with 2 affected accounts having very large frozen balances
- reserves for parachain registration left on relay chain caused large freeze amounts on Asset Hub
- Multi Asset Bounties pallet
- audit planned to finish mid-December
- putting on Westend, will write blog post for client testing
- Governance features technical design work
- prioritization queue for payouts
- currently no payout order - anyone can pay out if funds available
- problem: large USDT spend blocks smaller spends until enough USDT available
- solution: FIFO queue with expiration, need on-chain remark to hold place in queue
- governance origin to account ID conversion
- some calls only work with account ID, not pallet origins (e.g., treasury origin)
- want to enable bounty origin conversion for complex calls without third-party management
- prioritization queue for payouts
- Meta-transactions
- checking status for audit prioritization
- planning to put on Westend
Sebastian
- RocksDB debugging
- spent time on database issue Basti described
- turned out to be messy regular RocksDB behavior
- Memory optimization
- addressed long-standing memory issue during syncing (30-40 GB usage)
- root cause: parachains keept blocks from finality notifications from relay chain pinned pinned
- fixed by not keeping notifications around
- memory usage now ~12 GB during Polkadot sync
- Storage reclaim
- PR open for enabling on Asset Hub Kusama
- backported state tracing RPC fixes to older branches (needed proof recorder)
- ready for Kusama, then later Polkadot
- Elastic scaling progress
- Alex working on bringing Asset Hub Kusama to elastic scaling
- 2-second block times coming soon to Kusama
- early 2025 for Polkadot
- 3-core setup expected to work well
- Q Dom: I heard there are issues running with 12 cores?
- 12-core configurations tested and should work
- more susceptible to network latency
- Q Kian: tested?
- tested on Paseo (Westend had instability)
- Kian: small fix needed for era planning timing before Kusama/Polkadot deployment
- Q Kian: is this based on Elastic Scaling?
- no, fixed factor scaling
- chain will use the cores that are assigned
- starting with slot-based collator, relay parent offset of 1, maintaining 6s blocks initially
- as cores increase, blocks get faster
- could also remove cores on demand
- plan to keep 3 cores for Asset Hub
Rank 1
Daniel Shiposha
- XCM types refactoring
- making types more easily extendable for new versions
- using procedural macro to define instructions in one place
- can specify version ranges for each instruction
- includes flatten attribute for types that change with versions (e.g., withdraw asset using version-appropriate asset type)
- conversion logic - important to keep it clean
- preserving Brian’s idea of implementing execution per instruction separately
- goal: easily add new instructions without touching XCM executor
- applies to all versions, not just v6
- supports same-name instructions with different signatures
- allows conversion even when instruction removed in newer version
- hope to publish draft branch this week in retention argument
Seyed
- Ownership proofs
- working to get PR merged
- will enable testing on Westend
- BLS host functions RFC
- reviewed and made suggestions
- benchmarked efficiency - not much improvement with new algorithm. not worth postponing standardization
- New ZK bridge (Polkadot-Kusama)
- working with a team implementing bridge using BPK(?) group for ZK proofs
- grant application submitted to Web3 Foundation (under review)
- once ownership proof PR merges, we have ECDSA BLS signatures. the bridge aggregates BLS signatures, generates ZK proof, sends to Asset Hub Kusama/Polkadot, smart contract runs ZK verifier
- proof generation: matter of seconds
- Ring VRF Python implementation
- team implemented ring VRF primitive (used in proof of personhood, Sassafras, JAM)
- one in Rust, one in Python
- reviewed implementation, looks good
- provided test vectors
- enables Python applications using proof of personhood
Dom
- New issuance PR
- final stages with Kian and Oliver
- wrapping code in extra security layers
- should be coming soon
- Voting while delegating
- finished code
- Guillaume reviewed, thinks it’s good
- waiting for RFC final approval
- Next priority: possibly crowdsourced decision deposits
- Stored macro discussion
- macro replaces seven derives for stored items
- Guillaume reviewed
- Dom asking: still interested or moving away from macros generally?
- Basti: case-by-case basis - macros worthwhile when they eliminate significant boilerplate (e.g., encode/decode)
- Oliver: custom syntax and where bounds can get annoying
- Dom: solved many issues with default_no_bounds functionality improvements
- Kian: instead of new macro, improving error messages is also a big win
- Basti: collecting all errors instead of bailing on first error would help
- Kian: clear error messages with hints could eliminate need for stored macro entirely
- Dom: will explore error message improvements
- Kusamarian interview
- Dom did Space Monkeys interview about joining Fellowship (promoting to others)
- based on Sub0 presentation: “how not to fail at joining the Fellowship”
Additional Notes
- Next call scheduled for December 16, 2025 (third Tuesday of month)
- New issuance PR discussion (Kian and Dom)
- current implementation: snapshots total issuance once on March 14
- builds curve from snapshot to 2.1B target, never updates curve starting point
- future burns/slashes don’t affect curve
- trade-off: predictable/forecastable emissions vs exactly hitting 2.1B target
- likely to undershoot target due to not accounting for future burns
- original referendum had ambiguity around “remaining supply” vs “circulating supply”
- era duration wobbles slightly, so exact forecast impossible anyway
- can potentially change implementation detail later without changing cap or curve speed
- Jonas’s forum post on issuance buffer would provide cleaner abstraction (all income flows to buffer, no more burning, then redistributed)