sub0 in review: impressions from the Polkadot developers conference
sub0 took place just a few days ago, on the 28th and 29th of November, at the trendy LXFactory in Lisbon. Still recovering from the frenetic pace of the recent WebSummit, team t3rn revisited the Portuguese capital for yet another cool event. In this post we’d like to share our impressions and thoughts on the latest developments in the Polkadot ecosystem.
sub0 brought together the global Polkadot developer community, as well as a chance for existing Polkadot and Substrate developers to deepen their skills and connect with each other.
sub0 was a great platform to provide an introduction about the next-generation multichain network to a very qualified tech audience. t3rn aims to become a fundamental piece in the future of Polkadot’s multichain network, enabling developers to exert their full creativity in designing multichain smart contracts.
Polkadot is attracting so many great projects, founders, and talent across the board due to its strong tech community and the sheer potential of the tech – such as development in Substrate and ink!, its inherent network security, and the potential seamless interoperability between chains, thanks to solutions like t3rn. An interesting fact is that Polkadot currently has the largest developer activity from all other ecosystems in Github.
Here is a visual of daily active developers since Polkadot’s launch.
At the opening talk, Björn Wagner, the Co-founder of Parity Technologies, mentioned that this was the largest attendance at a sub0 event, with almost double that of the previous year – which is impressive, especially during these “bearish” times.
Interesting insights from Polkadot sub0 2022
Gavin Wood’s surprise presentation
There were many interesting presentations for beginner and advanced developers in the Polkadot ecosystem, but one of the highlights was the last minute presentation by Gavin Wood.
He was not scheduled to speak at sub0 this year at all, but we were informed just a few hours before he showed up and even though it was last minute, the room was full when he showed up and started talking on the main stage.
Gavin shared some of the things he’s working on, he’s interested in, and that he’s looking forward to in 2023. Here are some of the topics he covered and the highlights.
The first section of the talk covered what he’s looking forward to working on in 2023:
- 2D Weights. They are needed for automated functions to be executed on-parachain (e.g. migrations, XCM, scheduled stuff) safely.
- Message Queues. Unified message queue & dispatch per chain. Efficient, 2D-Weight compatible.
- XCM v3 & Bridging. It’s still pending an audit and a few final touches like finalizing 2D Weights and Messaging Queues.
- OpenGov (or Gov2). Launched on Kusama but it will be eventually rolled into Polkadot.
- Fellowship Pallet. It will serve as a technical oracle for governance member benefits according to rank. Loosely based on martial arts ranking.
- NIS (non interactive staking) & KTC/PTC. Will offer the possibility of gaining resistance to DOT base inflation in exchange for locking Receipt (NFT) and Counterpart (KTC/PTC) needed to reclaim DOT after lock expires.
The following part of the talk was about things that need reform and refactor and that are almost finished working on:
- The Second Polkadot academy will be in Buenos Aires instead of Cambridge (UK) and will double in size to 100 students in 2023.
- Ecosystem Standardization to XCM for easier config, standards for XCM weights, and transaction priority.
- Weight Clawback to help save time for teams having to write sophisticated benchmarking code.
To conclude he touched on some points that are new:
- Statement Holding Hub Protocol. Accounts may post signed datagrams off-chain workers & RPCs can query datagrams sent by accounts. The datagram size/count is limited by accounts holding.
- Exotic Core Scheduling for parathreads, this is in line with the vision of making sure that Polkadot’s high quality blockspace is used and benefits the DOT economy. Besides parathreads there could be other ways of filling up the blockspace like Round-robin where N parachains share a slot.
- Ecosystem Tech Fellowship will be the next fellowship to launch. All the builders in Polkadot with the knowledge to build on Polkadot, how to use the tools and peripherals, and deploy a parachain could benefit from this. They would not only get recognition for their knowledge and expertise but also a role in governance.
- Polkadot Payroll will help support those that consistently contribute to the ecosystem and could also be the onramp to the fellowship.
Maciej Baj presentation: Pluggable light clients for trustless bridging to Polkadot
It was great to see so many people interested in our project. We would like to highlight Maciej Baj’s presentation. He covered the topic of light clients, which casually happened to be a popular topic amongst attendees this year.
What is a light client?
Light clients are nodes which only download a small portion of the data in a blockchain, and use indirect means to verify that a given chain is valid. Instead of validating blocks, they assume that the chain favoured by the blockchain’s consensus algorithm only contains valid blocks, and that the majority of block producers are honest.
Good read at: Fraud and Data Availability Proofs: Detecting Invalid Blocks in Light Clients by University College London, Ethereum Research, LazyLedger Labs
t3rn enables composing generic code execution over multiple consensus systems as part of fail-safe transactions. We want to bring the functionality and usability developers are used to work with when designing smart contracts on a single ledger to the interoperability realm.
What are the main interoperable programming challenges?
- Race conditions while cross-chain state update. This happens when multiple states come from different chains to multiple targets and how to control the flow of the execution.
- Asynchronous state reads over cross-chain execution gives no data integrity guarantee
- Error handling and reverting side effects at immutable targets. When you want to develop a smart contract to interact with multiple different chains it’s difficult to harness all of them together and put them into a working application base solution.
- Different Consensus Systems & cryptography schemes.
- No standard smart contracts programming language.
t3rn provides the solution for effective interoperable programming
Here is a run-through of how t3rn works.
Developers can deploy their smart contract to t3rn, and it will be hosted in a pallet called contract-registry. This pallet essentially hosts the bytecode and is able to provide the information to one of the virtual machines, which are WASM and EVM compatible.
While executing the smart contract on chain, t3rn extrapolates the operations that would happen on different chains and emit an array of artifacts that are called side effects. Those side effects are then put into an open market system for agents called Executors.
They are able to pick up this side effect and if the deal makes sense, execute them on chain over different consensus systems and then provide the proof that the execution has happened. This proof would then be ensured in a fully trustless way with light clients and the inclusion of events such as transfer, get price or add liquidity.
t3rn will provide information about the status of an atomic executions to the user, either it has been reverted or executed. Based on that information, t3rn provides asymmetric operation to all of the different operations, which can be called directly from the smart contract. The Executors will either commit or revert the multichain chain transactions based on the logic in the smart contract
Here is an example of how t3rn envisions the smart contract. This case is written in ink! and compiled to WASM. t3rn will provide the set of libraries to access all the individual blockchains to design the interoperable executions.
Light clients have become an important aspect to t3rn because they will play a fundamental part in expanding executions beyond Polkadot, to other consensus systems. Most of the light clients today are written as off-chain agents mainly because on-chain computation and storage is expensive, especially on Ethereum.
t3rn takes advantage of designing the solution on Substrate where parachains can be adjusted to do heavy computations and tasks, and use off-chain workers whenever on-chain computation is too heavy, and also load storage on Collators.
Substrate also allows you to access multiple programming schemes such as Schnorkell, ed25519, and ECDSA easily.
There is more to how t3rn is implementing light clients now, and how this will look on a Parachain. You can check out the information on our newly released documentation website or ask any questions you have on our Discord or Telegram.
Overall, we thought the event was a great success. It was well organised and there were some really interesting talks for beginners and advanced developers alike. We’re looking forward to keep building with the Polkadot community as we seek to give all blockchains the power to interconnect seamlessly, securely, and trustlessly.
Stay tuned for more updates on Polkadot, t3rn, and how you can get involved in this exciting community!
👉 Subscribe to our newsletter: Join 15,000 subscribers for exclusive monthly updates and insights, directly from Maciej Baj, founder & CTO of t3rn. - no spam, unsubscribe anytime.