Scaling, Technology, and Tooling: Polkadot and Beyond by Robert Habermeier - Co-Founder, Polkadot

thank you thank you yeah good to be here thanks for coming everybody uh today we're going to be talking a bit about the scaling technology and tooling of polka dot I gave a presentation at the Shared security Summit a few days ago which covered some of these topics this is going to be a little bit more builder focused uh but essentially we've been doing a bunch of look a bunch of research and taking a deeper look into this concept of block space so what is the raw material what is the product of blockchains you know I think it's very easy to go deep into the stack and say like oh here are all the different layers and here are all you know the different details you have to tweak but what really matters especially from a builder's perspective is this concept of blog space it's the raw material so I Define block space as the capacity of blockchains to execute and finalize operations right pretty straightforward it's a general material that needs to be specialized into intermediate or end products and as a builder who's building something you know some kind of on-chain institution smart contract Suite something like that this is what you're actually consuming so different block space offerings from different systems are going to have different properties right like block space is not uniformly the same but when you're looking at the details of different Stacks I kind of bring it down to these three properties of uh quality availability and flexibility so quality being how secure is it what is the economic cost of reverting finality of this block space you know how permanent is this product that you're buying availability being General availability on the market and to be clear this is not the same thing as scalability right because scalability is about increasing the supply but not necessarily creating a healthy market for Block space so availability is about Supply as well as the allocative efficiency of the system for getting that blog space and then you have flexibility which is how many different ways can it be used you know is this very general is this a restrictive model is it something like Bitcoin right where Bitcoin is programmable but it's not touring complete there are limited things you can do with it you know EVMS versus zke EVMS versus webassembly these things have different properties and I'll dive a bit deeper into that because I think from the developers perspective flexibility is very important uh so to get back to that point that block space is not a commodity but a class of Commodities right different systems are going to be producing different types of block space now each system is producing that commodity that's its commodity but across all systems it's a class of commodities and as we build in a multi-chain world getting the right quality of block space is important because you're going to build apps you're going to build institutions on chain you're going to build businesses contracts and they're going to need to draw from many different sources of block space and the analogy that I like to use is that drawing on like let's say mostly good blog space and a little bit of bad blog space is like going to a restaurant and getting served a meal that's mostly really good ingredients but then the chef sprinkled a little bit of garbage in there and it's not something you'd want to eat and it's really the same thing with low quality blog space because as soon as you introduce that into an application you introduce a high level of systemic risk you know that can lead to cascading effects and take down the whole system and that's why I call it toxic and say that multi-chain applications are only as good as the worst block space that they build on top of it is a raw material and needs to be specialized per use case and we kind of break this down into two models you have autonomous models and you have reactive models so reactive being somebody sends a transaction or a message comes in and the system reacts to that so smart contract models are inherently reactive in that they respond they react to incoming inputs but you can also use block space for autonomous inputs you could say allocate 20 of your time to just doing uh maintenance tasks or you know moving things around in state or cleaning things up there's no reason that block space necessarily needs to be spent on reactive inputs that's not to say that reactive inputs are bad actually they're very very useful because this is how you ultimately interact with users and build a product however when you combine that with an autonomous model it becomes more powerful so I've already spoken out this slide but to get that more concretely in text we have it defined as autonomous models being where the system is executing pre-programmed tasks and reactive models being ones where block space is allocated in reaction to incoming transactions and we can talk a bit about this notion of flexibility along with the metering mechanism right you know what happens when you're doing granular operations versus course operations now when you're doing granular operations uh like executing in a VM that's not specialized for a particular use case you have to say stop after every instruction deduct a little bit of gas and then move on and this is a pretty high overhead so per instruction metering is good because you know you can do anything with it right these languages are very low level it's stuff like moving around memory adding numbers basic instructions like that but it has high overheads whereas if you meter things purely on the basis of data and execution time that's a much coarser building block that you can then build coarser instructions on top of right you can have something like uh how what is the gas cost of storing a file what is the gas cost of doing a swap and swap being sort of like one instruction one one operation that you don't have to meter for every single instruction that's being done there so this notion of transforming block space into intermediate or end products I think is really important and I think of smart contracts as one of these block space Transformers application specific blockchains being another so you can build a smart contract to transform block space into a product that way or build an application specific blog space blockchain as a Transformer and to be clear scaling is important but allocative efficiency is just as important right you know if you were making a new continent right like imagine you have all the consonants of the world world got a little bit bigger and there's a new continent and that continent could have all the land right like tons of land more land than all the other continents put together but unless there's good mechanisms for allocating that land it's not really useful it's kind of a free-for-all right it's just a big battle so you need effective markets that are efficient for allocating that resource and I think especially you know as we're in a bear market right now it's not 2020 it's not 2021 uh leaking tokens in order to pay for more block space than you need before product Market fit before there's a really active user user base and sustainable economy is not a not something I think projects are going to be able to do which is why we're really leaning into this allocative efficiency argument so to talk a bit about the tooling right like how can you build uh on polka dot right with this in mind like what are some of the blog space Transformers that you have access to now you have access to all the VMS that you are familiar with coming from ethereum right you have uh basically good access to the evm and the idea is that you can deploy contracts to para chains what we call para chains I'm not sure how many people here are familiar with that term the para chains paper polka dot white paper in 2016 was actually the first optimistic roll-up paper so when you see para chains if it's a term you're not familiar with just think roll up uh you can build a parachain right with an SDK with substrate that I'll talk about in a little bit you can build modules we use modules that can be plugged into different pair chains or you can build Bots essentially off-chain actors for things like Mev incentivized actors you know state cleanups that kind of thing so those are a lot of different ways to sort of transform that block space into something useful from like a tooling perspective like actually writing code um to talk a bit about substrate substrate is not just a polka dot SDK it's something we've dog fooded for polka dot in the sense of we wrote polka dot using this blockchain SDK and implemented all of the off-chain networking database all of that stuff on top of substrate but the core of it is it's a modular architecture so you have pluggable consensus swap in different consensus algorithms and then you could swap in different bits of business logic with pallets so you can use it to write parachains I know teams that are using it to write Roll-Ups on ethereum or even data availability layers that are meant to be solo chains all kinds of things and one of the approaches of substrate which is opt-in is this notion of forkless upgrades because runtimes are just big web assembly blobs so they're stored on chain and they encapsulate all business logic so upgrading logic is just a matter of taking the previous webassembly blob and forklessly upgrading it to a new one and the whole substrate meta protocol as we call it kind of encapsulates that so you can swap some the new in very low friction and of course extensible off-chain logic like we have dog food in all of this Advanced networking stuff using substrate I think it's very suitable to those types of tasks when you want to get deeper than just building something that's an atomic on-chain State machine uh talk about some of the pallets we have we have evm pallets have been built in the community uh you know stuff like balances stuff like staking nfts cross-consensus messaging uh transaction fees and all this stuff is swappable and you know any kind of pallet dexes uh nft platforms whatever you might think of uh you know stuff that's well suited for gaming marketplaces whatever you might find that can be implemented as a palette and then put into many different chains uh and this is a very very very non-exhaustive list I want to talk a little bit about Inc it's something that's been launching recently but it's it's essentially a rust based domain-specific language or DSL that targets web assembly for smart contracts and if you're curious to dig into this the documentation is up I think it's quite comprehensive and very very intuitive at the URL use dot Inc and this is definitely worth exploring if you want to dive into say writing contracts in Rust and you get some benefits of that like maybe easier formal verification uh first class like llvm support all the optimizations that come with that strong type system really good test Suites you know that you can write with the rust tooling and all of that stuff so to talk a bit about this from the Builder perspective and I don't think I have much time so I'll leave it here I have a few more slides but catch up on the talk from the shared security Summit if you want to dive deeper into this but the argument that we want to make for Builders is that we're pioneering this approach of doing for blog space what cloud architectures did for cyberspace with efficient allocation of resources basically making it as easy as possible for early stage teams to only pay for the blog space they need and scale up when they need it and scale down when they don't do this in an automated way I'll leave off for there thank you so much for coming everyone and have a good rest of your eat Denver [Applause]