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. 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 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.
Back in October, I wrote RFC#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 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, or Stackexchange to help solve their issues.
Besides the work highlighted above, I'm also very active in maintaining the Fellowship runtimes repo 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!
Bastian Köcher is a rank 6 member of the Fellowship. Here are some key points about his work and responsibilities:
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. 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 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.
Back in October, I wrote RFC#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 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, or Stackexchange to help solve their issues.
Besides the work highlighted above, I'm also very active in maintaining the Fellowship runtimes repo 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!
Threshold
Threshold