Hey, I'm Bastian Köcher, a rank 6 Fellowship member. The Fellowship requires that members up to rank 6 apply for retention to stay at their rank; otherwise, they can be downgraded. Normally, these referendums are done within the Fellowship itself. To retain rank X, members of rank X+2 need to vote in favor of you. In my case, there are no members of rank 8+ who could vote for me. So, I need to use the Fellowship track to get approval from all the token holders.

At rank 6, I need to request retention every 6 months. This retention is for the time frame from October 2024 until March 2025.

Right now, my main focus lies on enabling parachains to build blocks faster than the relay chain block time. When parachains launched, they were able to build blocks every `12s` (i.e., every second relay chain block). With asynchronous backing, the block time of parachains went down to `6s`. With elastic scaling, it will be possible to use multiple cores on Polkadot (each core provides `2s` of execution and `5MiB` of data). Thus, a parachain could use 3 cores on Polkadot to produce blocks every `2s`. The solution I'm working on will make it possible to build blocks every `500ms` by splitting one proof of validation (`PoV`) into multiple smaller pieces. By building blocks every `500ms`, the latency of applications on top of Polkadot will be reduced.

Besides working on faster block times, I have been working on supporting [remote proxies](https://github.com/polkadot-fellows/runtimes/pull/535). Right now, proxies are local (and thus limited) to chains. So, if a user creates a proxy on the relay chain, this proxy cannot be used on a parachain. For normal proxies, this is not such a big problem because they can be replicated manually. However, when a user creates a pure proxy, it cannot be replicated without `root`. We have recently seen this issue popping up. People created proposals on Polkadot to get paid in stables to their pure proxy accounts. The stables are paid out on AssetHub, and if the given pure proxy doesn't exist on AssetHub, the funds are not accessible. I created [a guide](https://blog.kchr.de/polkadot/guides/force-create-a-pure-proxy-account/) on how to replicate these pure proxies between chains, but this is a manual process that requires `root` and is cumbersome. So, I implemented a pallet that will enable users to use their proxies across different chains. I explained how these proxies work in [this blog post](https://blog.kchr.de/ecosystem-proxy/).

Back in October, I wrote [RFC#123](https://github.com/polkadot-fellows/RFCs/pull/123) to fix some longstanding issues around runtime upgrades in the Polkadot ecosystem. The problem only arises in the block that enacts a runtime upgrade. The runtime of a Substrate-based chain is stored in its own chain as a WASM binary. So, when the runtime is upgraded, this entry in the state is overwritten. When trying to read the state of the block that enacted the runtime upgrade, right now we are using the new WASM binary to decode the state entries. As the state layout can change with a runtime upgrade, the decoding may fail, and incorrect data is returned. In September last year, we saw [degraded parachain performance](https://forum.polkadot.network/t/2024-09-17-polkadot-finality-lag-slow-parachain-production-immediately-after-runtime-upgrade-post-mortem/10057) after a runtime upgrade on the relay chain because of this issue.

I'm often involved in discussions with builders/users in various public channels like Element, [Polkadot Forum](https://forum.polkadot.network/u/bkchr/summary), or [Stackexchange](https://substrate.stackexchange.com/users/73/bkchr) to help solve their issues.

Besides the work highlighted above, I'm also very active in maintaining the [Fellowship runtimes repo](https://github.com/polkadot-fellows/runtimes/issues/created_by/bkchr) by providing reviews, helping with releases, and proposing changes of my own. I'm also very active when it comes to on-chain voting in the Fellowship, such as opening retention and promotion proposals for many members. I have taken part in three in-person interviews to promote people from rank two to rank three (the rank of a member, the first rank in which they get actual voting rights in the Fellowship).

Thank you!

- **Problem Statement:** Fellowship members up to rank 6, like Bastian Köcher, need approval from higher-ranked members for retention, but in cases where higher-ranked members are not available, they must seek approval from all token holders.
- **Significance:** Improving block times for parachains, enabling cross-chain proxy usage, and addressing issues with runtime upgrades are crucial for enhancing Polkadot's efficiency and usability.
- **Proposed Solution:** Bastian is working on solutions to enable faster block production, facilitate cross-chain proxy usage, and address issues related to runtime upgrades in the Polkadot ecosystem.
- **Expected Outcomes:** By implementing solutions for faster block times, cross-chain proxy usage, and runtime upgrade issues, Bastian aims to reduce application latency, enhance usability, and improve overall performance within the Polkadot ecosystem.

#1452 Fellowship: Retain bkchr at rank 6

No Active Proposals