2025-05-15 Technical Fellowship OpenDev Call

Tech Talk
1

previous: 2025-04-15 Technical Fellowship OpenDev Call

video: https://www.youtube.com/watch?v=t5LqucWbF7E

Jonas Gehrlein

  • Research
  • RFC 17: Revisit Market Design of Coretime Sales #17
    • current problem:
      • renewal prices are not increasing fast enough. combined with that overall prices were decreasing for quite some time, someone can buy all the cores and renew them for very cheap
    • goals:
      • renewers should always have right to renew
      • not hoard cores for cheap
    • changes:
      • combine the reneweals with a market phase to make sure renewers pay something close to the market price
    • trade-offs - Q: what pushback did the RFC receive?
      • reneweals over new bidders
        • price within one market cycle is capped by factor 10 of reserve price. reserve price is going up and down based on consumption; if demand outstrips supply 90%, price goes up. on top of that there is a reverse auction that starts 2x the value.
        • issue: if someone is willing to pay 6x the price of the reserve price, they can’t do that. that is neccessary, because since we guarantee renewals, they will always be able to renew, even if they haven’t participated in the market. it could mean that someone who participated in the auction will not get a core, because the renewer can kick them out.
        • answer: it is more important to keep existing projects than give a core to the highest bidder
      • market phase at the end to clear out market inefficiencies
        • tipping wars - if we have max price, bidders could tip collators to get their tx in the first block of the auction
        • a tip is juts an extension of the bid (that goes to the collator). we want to achieve efficiency. Whoever pays the most gets the core. That is also given in a tipping war.
        • But there is still a market phase at the end of the cycle. Market inefficiencies would clear out there.
  • RFC 146 Deflationary Transaction Fee Model for Relay- and System Chains #146
    • rn 80% of fees go to the Treasury. We should burn these. Also for system chains.
    • comment on distributing more to validators/collators:
      • vlidators will not make a lot of tx fees
      • collators are not security relevant, so collators don’t need to benefit from high tx volume, but Hub txs might still become substantial

Basti (Rank 6)

  • was busy with coretime baron
  • JAM Experience in Lisbon → deep diving into JAM and first experiment with CoreChains
    • compile runtime and reexecute a block

Rank 4

Robert K

  • Latency & Coretime incidents kept us busy
  • Deal with Rob H integrating NOMT into Substrate
    • hoping to achieve: 1000x accounts @ 10x speed
    • most important part is reduction in PoV size
  • working on realiability and latency of blocks

Kian

  • did AH migration on Westend
  • Working on staking.
  • update on RFC97: unbonding queue
    • ran into some issues. BlockDeep discovered some minor issues when starting to implement
    • will land with AH migration, or right after

Rank 3

Joe

  • Contracts
    • mostly code complete on the protocol level
    • getting user feedback
    • all of the standard Ethereum precompiles implemented.
    • we also have a precompile-framework, interface between contracts and XCM, staking, governance
    • Suggestion Basti: could we have an “unstable” precompile to evaluate on-chain? Would be great for experimentation
  • Q: Reaction to “Almost compatibility is unsafe” Forum post?
    • it’s tradeoffs. We had these talks at the beginning.
    • Going for a straight impl is possible, but then it would also have to be cross-compiled to PVM eventually. Would be more compatible, but we would miss out on the benefits of PVM
    • We choose to go with revive understanding that there would be compatibility issues. If we wanted to do that, we would have just launched with frontier.

Donal

  • AH Westend migration happened last week
    • first part of a seven-stage process
    • had a small bug that loaded the DMP queue to the point blocks got stuck, quickly fixed it
      • had to drop some messages from the DMP queue and restart
      • 3 or 4 things to implement before dry-running this on Kusama
      • originally we used a fake state on a zombienet, but the livestate has quite a big staking state. got 10MB in the queue. Backpressure wasn’t handled as intended
    • next Paseo to gather more data points, then Kusama
    • timeline is still good: Q3 on Kusama

Gavin

  • Getting Graypaper to complete enough to accept M1 candidates.
    • not quite 1.0 level, still needs audit. getting to 0.7 all functionality that is needed for the network should be in and somewhat optimized to how we know the network is going to get used
    • 0.6 issues are not big protocol changes, but qol improvements
    • account metadata, introduces into the service accounts things that you expect of processes on OSs. e.g. the Parent service, the time it was last accumulated, when it was created. This provides baseline information that is very helpful for devops. interesting departure from regular blockchain considerations. we are thinking of devops people. because we have to if this is a compuer
  • tooling: jamtop understands corevm services now and can tell you what the guest is doing (doom, video test)
  • getting to 0.7.0 by the end of the month. hand that version to auditors by end of July
  • then make a run to 1.0.
  • coreboot? → renamed it to “bootstrap service”
  • corechains?
    • Basti was looking at it at the JAM Experience. Feel like it is something that won’t take too long to have something usable
  • JAM Experience
    • was fun. we showed people around the Toaster. Hardware complete. We started to put code on it.
    • We didn’t get that far with interop during the retreat, but shortly after. We already heard from 2 teams who are interoperating with Polkajam nodes. At least milestone 1 interoperable. Milestone 2 will be trickier.

Jan Bujak

  • JAM Experience
    • hosted a talk about writing recompilers
    • helped folks debug PVM related stuff. CoreVM.
    • Hopefully soon have Quake running on-chain
  • worked more on gas metering, fully spec it out.
  • working on Ethereum compatibility. I invited Cyrill on the call to chime in on the Ethereum compatibility
    • Cyrill: I don’t get the point of the post. The decisions were deliberately made

Andrei

  • incident debriefs
    • Latency Issues
    • Kusama Finality
      • Q: dispute was punishable by slashing, are we not doing that?
      • Rob K: for now, no slashes. they are ignored for the remainder of the era and don’t receive a reward for the era
  • published a new blog post on scalability
  • going to write another one on latency
  • worked with Mythical to improve tps, lowering down weights, push more txs, prepare to start scaling tests
    • presented how cores work, how elastic scaling is go to work
    • They really think big. they build something that I believe will be the largest Web3 gaming platform. It can only be achieved with a multi-chain approach. There will be one game per chain. They’ll use bulk/on-demand coretime depending on load. I expect there will be tens, if not hundreds of game parachains deployed in the future.
  • took a look at blocktimes in Polkadot and Kusama. How efficient are parachains? How much does it take for a block to be produced/discovered/backed? still under investigation

Rank 2

Sebastian Kunert

  • beginning work to eliminate forks (see previous call notes)
    • currently ironing out comments and expecting to merge very soon. probably next release

Muharem

  • working AH migration, message queue investigation reaons:
    • used the wrong send function, leading to wrong counting between relay and AH
    • some unit tests exluded networking stack
  • Q: 6s blocktime on AH soon?
    • Yes

Rank 1

Clara van Staden

  • finished Snowbridge v2 Audit
    • merged to stable 2503
    • we haven’t added the new snowbridge v2 pallets to the new runtime yet. we waited for the audit issues to be finished. and then propose to upgrade
  • in v1, messages were ordered. in v2, relayers can decide which messages are profitable to deliver and only deliver them. added a feature to allow a sender to top-up a message. will be in 2506
  • update on what the team has been working on:
    • v2 off-chain infra / relayers
    • gas estimates for v2
    • build UI to send tokens from Kusama AH and back. Will launch in next week.
    • integrations:
      • setting up pools on Stellaswap and Uniswap; Stellaswap: thursday, incentivized. Uniswap: still verifying, have to add liquidity.
      • Next month add Acala and Frequency to UI
      • Could transfer MYTH from Ethereum to Polkadot, but not back. Next month will add.
    • preparing another Treasury proposal

Cisco

  • working on XCM support for smart contracts on the Hub
  • improve the errors that pallet-xcm gives. reasons
  • enable exchange-asset instruction on AH → send a message to AH and do the exchange, e.g. if a UI needs to do a teleport
  • working with paraspell team that have an XCM SDK to include the dry-run journey out of the box.

Seyed

  • we finished proof of posession. PR is up
  • wrote an RFC 48 to give flexibility to proof of posession
  • working on compression of merkle proofs. I heard 70% of the PoV is merkle proofs. Wrote the first PoC using Plunky3. ~100kb now. Proving time ~4ms.
  • Gave a talk at ZKSummit.