 Welcome back from the break by the way, welcome Sebastian, but everyone welcome back from from the break if you're only joining us now This is our second block of talks for a success factory You can follow us on YouTube or on Zoom, but then again if you're hearing me, I assume you're in one of those If you have questions, please ask them in the chat or in slack There will be time to to ask them live at the end, but it does help us if we if we already have a list of Questions ready keep in mind that if you do ask a question live You will be in the recording. So just keep that in mind And if you don't want to do it just note it in the text and I will ask it for you our next speakers today are Arvnovae and Sebastian Nagel and I welcome them to to our virtual stage now I've no began developing software professionally in 94 He graduated with a PhD from the University of Neal in 2005 and since then he has worked as a consultant Lead developer a technology sheath an advisor an architect and a coach is also a Haskell enthusiast since 2001 and he joined high OHK in 2021 Sebastian is an Austrian software engineer and functional programming enthusiast He studied CS and graduated from TU Munich with a master's degree in robotics cognition and intelligence Within the robotics industry you got to know and webaskal formal methods domain specific languages and Interpreters after several years creating robot programming languages development platforms and IOT projects at Franca emica Sebastian joins IOHK in 2021 Their talk today is titled Hydra next-generation state channels And it will focus on the research developments and productization of an l2 solution to accommodate the growing numbers of Participants and transactions on cardano by means of isomorphic multi-party state channels between subsets of participants The stage is yours You Thank you for introduction. It's kind of giving away everything Alright, I Think we don't need to do any introductory rounds anymore. So we could probably just start with the presentation Should see my screen hopefully with zoom it works as well And I hope the aspect ratio is fine. We will switch it in a half So you have a higher chance of a good aspect ratio for a second half of it This is working right Good All right. Good. Hello, everybody I'm Sebastian and with me is Arno as we got introduced kindly We are here from input output and we want to talk about Hydra and I will be starting with firstly some kind of a Introduction on blockchain scalability on the on the problem statement in itself I want to give an introduction to the hydro health protocol, which is the name of this layer to scalability protocol we have been working with and Arno will continue but On our road basically and what what she actually covered On implementing this research paper now into the industry. All right so blockchains or many blockchains have to their goal to create a open and Public or sometimes private but open Financial operating system or a store of value or a means to transact the value between individuals all over the place all over the globe without the central actor and In that sense provide an alternative to traditional financial systems The goal in that sense always includes to accommodate the system for millions of users and billions of transactions potentially in In a fashion, which is still globally distributed as I just said and in a primarily decentralized nature, so everyone can be part of it and You could be your own bank or you could be your like your own operator of Lending and and and or decentralized exchanges and transaction in value. So everything is decentralized everyone. Everything should be in power to the individual I hope this Speaks also for some projects, you know, but it certainly speaks for what a project we are in so Kodama is goal to decentralize Finance and make it an open or financial operating system to everybody and Today this this kind of problem or this kind of task is usually approached us is by gaining and Make creating the system in a way that that everybody can Use it without trusting a central actor. If the goal is to actually gain consensus Along this very decentralized and globally distributed nature of a system of network and this is usually done through massive Global replication For example by submitting transactions broadcasting it through this whole network capturing these transactions by some some of the currently active block producers, for example, they would basically Get these transactions create blocks according to some consensus algorithm And and then write that down so the progress can be made on on the whole global network and this goes all goes all around depending on the consensus algorithm in proof of work, it's basically people who would be operating this mining machines and and In proof of stake this would be like stateful operators in other consensus algorithms This is another select group, which is sometimes randomly changing So we have we have a need to actually distribute transaction all over the place but also These transactions should be like replicated massively between the whole network. So it really is Clear that there was no no censorship or anything. This naturally results in Comparably low throughput and high latency It's quite natural because transactions need to be sent through one point maybe across the whole globe Such that I can reach out all network participants and Also the whole the whole means to actually make sure it's secure and not even you don't need to trust anybody on the network To be able to process transactions in that way requires More work to be done and literally in proof of work for example and this results in a limited resources and the low throughput in general And it's not so easy to tackle like this this limitations of scalability because known to this There's this concept of a blockchain tralemma. I see on right hand side that in order to reach scalability You would necessarily need to compromise security of decentralization Why is the traditional financial systems very scalable? For example, like the visa payment system Can process many many transactions per second It's it's only because These transactions are processed in a data center or in a couple of data centers with closed location or basically the It's not so much replicated through like thousands and thousands of operators across the network and You could reach the same thing if a blockchain system by just having a small number of people who operate it so the more the smaller the numbers are on on on a Blockchain project the faster it can go usually it also depends on the consensus mechanism how much communication is necessary between the participants and in how much Overhead we have on the communication because of security so We can get scalability by a compromising decentralization or security, but we wouldn't want to do that and So many many projects of multiple approaches in the ecosystem have been like aiming to solve this Tralemma or to to maybe cut the balance or strike the balance slightly different and We want to talk today a bit about state channels But there's other approaches like sidechains where you would have Additional functionality or a different kind of level decentralization on purpose There are a smaller replicas of the same blockchain, but more attached to the main blockchain and Inheriting security guarantees that way Rollups which work very similarly, but just slightly different where you would try process transaction also in a smaller group of people Sharding as like an idea of partitionizing or Partitioning the workload of the blockchains that's differently Lightning network is maybe a good example as a as a way to actually scale a very slow blockchain For example Bitcoin in this case Which is using lots of energy and lots of hashing power to actually secure the network as rightly adopted It's very secure, but it has quite limited resources and the notion of Payment channels the concept of payment channels as they're used in lightning network Really make the whole system still usable or usable again for a very small transactions So lightning is a good example and it's actually very similar to what we do but let's quickly summarize Why why state channels can work, right? So what is the basic idea? what this is based on and It goes by the principles of not every transaction requires necessarily global consensus so if you want to like settle a Bet with your friends or like pay for the dinner You don't need everybody on on the globe on the other side of the planet agree on that this actually happened right, this is enough if you actually settle it with if the if your business partners and usually you would you would actually Ideally want to use a system which which can actually Work only between you and your business partners By not needing to actually submit that something happened To everybody on the network. We could go faster naturally, right? So as we had before in a more centralized fashion processing transactions We could if you only need to Communicate the transaction between the actual people involved in in in a process in a business process and we could go faster like you can actually not have a low latency and Another premise another idea which could leverage is if everything's fine. So if if everybody agrees on Yeah, okay, that deal happened or that that's kind of That was the game round and that person win win win the pot If everybody agrees then there's the need for like a global Permissionless nature decentralized nature technology to to be the judge That's that's also quite intuitive But still right if somebody is not playing ball, right? If something goes wrong and already we would want to Maybe want to have that global system as a fallback, right? Go going to the next instance if you lose a Court case on the local court you could go to the next instance Court you could go to the national court and so on so and these these basics ideas are used in many of the scalability Projects ideas solution ideas and they're also used in state generals and this is what we want to talk about the state general as a layer 2 on top of a blockchain So Before I explained this quickly, right within this whole setup We at IHK and especially the Hydra team is like aiming to solve the scalability problem in that sense and in general furthering growth and adoption of one of this blockchain project, which is Cardano and Yeah, the the benefits what we're aiming for is naturally faster transactions cheaper transactions And of course some enabling some use cases which wouldn't be possible otherwise and so The research team at IHG has been set out like looking at the previous research previous other solutions out there and Has been like coming up with a protocol. I would like to explain now and we have been implementing that over the last year or so So Hydra head So Hydra in general as a concept but the Hydra head is one specific protocol, which is also called isomorphic multi-party state channels and I would like to explain in the next couple of slides what this means Before we see maybe it working and how we approached it I forgot to Fix the animation here, but anyhow let me start by giving a quick hint for doctorial motivating use case here and What a multi-party state general? Could work like so you see a global ledger level a globe on the left-hand side the general ledger Which represents the blockchain a massively replicated distributed ledger, which you can see like big table who owns what? on the right-hand side, we We have a group of people like four people wanted to be poker and They could play poker on the on the on the base and the world's account ledger right, they could just play their game and decide who won and distribute the wealth as by winning the pot as they Won't You could do it on the layer one on the on the blockchain on the left-hand side, but We would want to do it. Maybe not as slow. For example Bitcoin You would need to like wait 10 to 20 minutes for a block To your transaction be included and it's a very expensive So our goal is to Take this is a bit like broken, but I guess animation makes it clear So this small mini ledger was part of the general ledger before so we were extracting the mini ledger Like a small part of the of the general state Extract it and make it available to be processed off-chain. It's called or in the state channel You would take those the small small notion of who owns what and Want to process this now separately from the general ledger and we can process this now faster and Cheaper faster because we need to communicate only between us for and cheaper because we only need to pay Whatever is to be operated to do that And not pay the whole network to actually acknowledge all our transactions So we could play that the round of poker very interactively and as it's more snappy as on the words ledger and at some point we actually We want to at certain points in time These people agree on okay. Yeah, no Alice won this round No Bob did one the next round and so the game progresses and we have these acknowledged or Agreed states These are is indicated here like some small signatures. I'm not sure if it's clear And we have a common understanding that this is the now new truth And finally we want to be able to Bring it back into the general ledger again, right? So and this this reintegration of the of the of the more smaller ledger state from the stage and back into the global ledger is Is the the end of the life cycle of a stage now basically? I Said payment channels before for example because we could simply do payment transactions between these four people But it could also be any kind of like state evolution, right? So There are Bitcoin is for Transacting and storing value some other blockchains like ethereum is more like for general execution general Smart contract executions or any kind of state modification is what typically sets a state general apart from a payment channel as being more generic and this is now more a More generalized here by having a multi-party not like between two but between multiple parties This is the basically the same kind of sequence but Drawn up on our time axis here So we see the blockchain on the bottom here We lock up funds on the blockchain to bring them make them available to a state general can be done once or multiple times They are processed somehow in the state general in step two and Eventually, I want to bring that back to the blockchain can also be done at the end of a life cycle But also like ideally multiple times reintegrating it and here it becomes quite obvious that this is a layer two in layer two system meaning If whatever happens in the state general should be enforceable should be able to be fall back on the layer one Right this is that three we can fall back on the security of the layer one and the layer one here the blockchain We see a dashed line here make sure that this Change of light green to dark green with the new status is Actually honored to the same kind of rules of what we would expect from the General lecture that is a preservation of value. Nobody got richer. It was just a redistribution of value intuitively Okay, a quick detour on ledger models just to point out one or two things why our work here is a bit different to what you might be hearing from the State channels have been around for a while and there is basically two distinct ledger models Or at least these two major ones One is an account based ledger model where you have Very much test this table we saw before this general ledger being a big table of many entries Each individual or even like systems or contracts would have an arrow on this table Would have a state in in this big global state and transactions attached to it by by processing This state into new states so sigma turns into signal prime And the transaction basically changes this state in one way or the other I can change all the values cannot change only a single one The other model is the UTXO or EUTXO it has been extended here Model in the UTXO model we would have The ledger state is a set of small niche nodes Which contains some kind of value so instead of rows we have like these nodes And transactions do attach on some of these nodes They consume some of these nodes and produce new ones so a transaction needing to be in balance can Spend this value and produce new value or a new distribution of value Maybe addressed to different individuals And these nodes here are As the red ones are spent and the black ones are unspent these are the unspent transaction outputs The actual state of the whole Distributed ledger then is basically comprised by all the unspent transaction outputs Or subsets thereof right so we can see here in the bottom Gray thing that This is the state of the ledger And this is important now if you think about How do we do this layer one to layer two transfer? And how does the station work? In an account-based model we have this global state and if you want to like take part of this global state into one state channel We need to take very special care Each system currently interacting with this global state need to be aware that something is now not available anymore To be like modified it needs to be locked So anything which needs to be put off-chain what as we would call it Needs to have like special preparation beforehand And especially the transaction processing in general of a of an account-based ledger is very sequential So we would need to Be processing Whatever we put off-chain needs also be treated in a very sequential manner like the overall It's it's just natural in an account-based ledger Um In a UTXO based ledger however we our state is just a set of subsets. It's really the like a small collection of dots Intuitively right and we can take these As these are like a sub part of the graph. They are partly independent of they are really independent of the rest And they can be moved Can be locked up But only that part is locked up and this is very Can be done in a very natural way to the underlying ledger model So there is no preparation required and and our UTXOs cannot just be locked up on the layer one In our case, they are then represented just the same on the on the on the layer two So if we if we just use the same identical ledger model on the layer two We gain the same properties of transaction processing of a UTXO based ledger, which is highly concurrent As this some of these outputs if you have a transaction spending one output And we have multiple other transactions to be processed, but they are not touching the same outputs or as Inputs in that sense They are completely independent and can be processed concurrently and and anymore In higher if higher parallelism even And this is interesting because to our knowledge There hasn't been much work before on UTXO or UTXO based state channels And this is what we exactly what we're doing We will hear in a bit from from our know the some kind of specialties still but This this ledger model is really the one of the the unique things Which makes the construction quite a legend in my opinion Now quickly to the life cycle of a hydrohead You can see the it's it's basically the same picture again We see the layer one on the bottom and the layer two on the top Whereas the layer one here has some kind of like initialization stage where we These block serve transactions on the blockchain um Some actors it's three actors would put down transactions to say what they want to get into a Hydrohead into the state channel This is then collected and whatever was actually collected so the All the all the substates of the UTXO ledger state the the the mini ledger would we want to bring into the state channel It's getting collected. It's getting locked up in this collects transaction And at this very moment and from then onwards we have this as an initial state available to us on the layer two That means we can then start spending these things on the layer two These are kind of mirrored over there And we spend these These these outputs or this ledger This value what we put what we brought with us we can spend it on the layer two with Also with the same kind of transactions in our case we can just use the same kind of transaction formats So this is what we would call isomorphic As it's using the same ledger model and it's using the same transaction format an application working on On a hydrohead can just use the same ways of posting transactions to the blockchain It can just do the same in posting transactions to a hydrohead So we it indicates here a bit that we have like many many transactions here We can go quicker As the transaction confirmation time here is a bit disconnected from blocks production on the network. It's really only a transaction gets processed into These intermediary states and we have this u1 here as a first snapshot as you would call it It basically is a snapshot of the new ledger state And it is an enforceable state It's something where all the people are running the state channel the operators I need to agree on and if they agree on Everyone involved knows from that point onwards that whatever was signed off here Will be a thing eventually on the layer one So the transactions are already final when we see the signatures here And you can go on and can do it even maybe in concurrency and can go faster You can maybe do it with some kind of different Uh What's it called parameters? So, uh, well, maybe you need to pay Some fee on the layer one Maybe you don't need to pay a fee for each individual transaction layer two Because you don't need to pay the whole network. You need to pay the The people operating the hydrohead to actually process your transaction Um at any point in time Um each of the operators can close the channel. So it's really long No, you're not taking hostage in in this. So if you're a part of the hydrohead You can decide when it's over or you can decide when you want to stop processing So it's really non-custodial in that sense And we can take in this example for example any of these enforceable states to close off and enforce one particular state on the layer one As this is more like a force closure. It's not really cooperative. It can be done cordially cooperative, but in this Basic scenario Just Alice's closes the head directly with her She thinks you want is the latest state But if there is a later even more recent state where Alice Did lose did lose the last round of poker? I'm not sure, right? So it's an unfavorable state maybe for Alice So bob says none of that. I I did win the poker round the last one. So I have a bit more Money now, right? And this last round of poker is represented by the latest snapshot which can be contested here And so there is no slashing or punishing involved, but rather simple Yeah, we agreed that this was a later state so we can enforce it on the layer one using layer one security mechanisms like smart contracts down here Fan out this basically just redistributing the funds as it was agreed in the layer two in the state journal And this closes off basically the life cycle of a hydra head And this was created by a group of researchers at ihk in 2020 was published and peer reviewed the whole concept What I just showed was a very basic construction. There is some extensions and it's a very nice paper 60 pages deep so might want to check it out might not And we have been setting off and implementing this so this was basically our starting point and Yeah, that's that's where we started to make it a reality a year ago I left this I hand over to you Arnaud And you want to switch maybe screens? Yeah Thank you, Smith. Um So, um We're seeing your second stream, I guess Oh, sorry timer My bad Yeah Um, so yeah, I will I will close this condition by giving you some of the great details about going from a research paper To a usable product or yeah, we are not there yet totally but we are getting closer every day. Um, so the first Yeah, the So here is what's the what what the The architecture of the hydra system looked like from from a high level Um, so once again, you can see here. We have this layer two on the top and the other one So the core of the system we are building is what we call the hibernode. So the hibernode is the um the the process the The server that will host the hydro ahead hydro ahead is the logical concept the thing that That participants work with um, and the hibernode is this is the the the physical or the actual process that will run And that connects to other hibernodes. So there is That's that's where the notion of layer is is also abuse that there is a distinct network Which interconnects the hibernode? um, and um That each hibernode is also connected to the layer one Here, uh, count on the node count node is the the basic component of the current network in order to ensure that um, the The count the hibernode has a direct access to change and this is a very important property of the, um, hydro as the channels The fact that a hibernode A participants in in the hydro ahead Is safe and secure as long as it is online and it can observe and react to events coming from the from the chain um, so in this case Yeah, observing what transactions get posted and posting information um Yeah, and on the right hand side we we we we we try to ally the fact that Now you can have a client application this content position can work and talk to, um, both, uh the the uh the hydro node and the calendar node and We also note that Thanks to the isomorphism property that Sebastian mentioned and the fact that The the connections that goes into the hydro node are exactly the same that goes into the calendar node I mean exactly the same down to the bytes Because the interface the hydro node accepts What is the seabor or serialized connection in the exactly the same format that the calendar node that and That would allow any any any kind of depth which is built for Working with connections on the calendar node to work also with the header node and this is also true for a wallet so if if a wallet wants to Uh do connections with the hydro node then the formats of transactions and the utx o system and Would be different of course the api is different a hybrid node expose a specific api to interact with but The the the data which is transport doesn't need to be reinterpreted in another in another model So, yeah, this is the high level picture To give you I will give you a quick flavor. So this is the the demo moments where Yeah, usually things go right, but luckily this time it will rework So here you can see we we build a small terminal Terminal base user interface to represent what it would look like to interact with With a hydro node from an external client. So here you can see I have split my screen in two in three parts We have three clients This is a version 0.60 of hydro which is which has been cut out just today just a couple hours ago And yeah, we can see that here are the clients here is connected to a bit different hybrid node So you have the clients and each client is connected to each own node And each client is also Identified by a party and an address and we can see that the clients are interconnected to its sphere So he gets some some messages The first stage as As I mentioned was is to to any to head. So if I press in it normally I should see the head is initialized. So This starts the The the hydro has to machine so now every party can commit So I will make sure that the different parties can can commit as At the commits sequence proceed, of course here I'm doing sequentially because I only have two ends and one head, but normally the the various In the if you have more parties, they are distributed then they would just commit In parallel as soon as they observe the chain you can see also some message some messages appearing in the in the in the status line, but Usually they disappear too fast and the last node so would Okay, so now the head is open. This is as shown as the head status. So that's the that's the the second state of the Distinct machine and now you can make transactions. So I can make a transaction with node three I will select this UTXO and I will send it to whatever recipient Is available and I will send not all money, but some amount and you can see here So that's where the transaction is happening on layer two and The UTXOs are are changed as We go so if I try to create a new transaction from the two for example And say sending maybe to this node. I could just say Okay, here it is. I create a new UTXO and Here we go can make more transactions once we're happy with the We we once the the head needs to be closed. This is um a user action a user decides to close the head And there is this is where we enter the contestation period In this our current implementation the contestation the contestation process is fully automatic This is the node that takes care of okay seeing that a closed transaction has been posted on chain and and Proving that. Oh, yeah, this is not the latest snapshot. So I can post a contest connection Obviously this is not happening here because the the timeline Is is way too short and once the contestation period has passed then we can simply fan out the head And this is where we we get the the the UTXOs being distributed on chain For a sake of the demo, this is not working on the on their main net Of course, this is working on the local development nets For for of kala node, but this just is only the same. This is the same kala node that that that that runs Okay, um, I hope you get a Refiety of how the dynamics of it um A little bit more details A few interesting things about the implementation that we we worked on So this is the zoom this zooms in into the the other The same representation that we had before but With with the focus on the central on the structure of the higher node And a couple of interesting things that we we can say about this implementation. So The the central piece of the high node is the what we call the head logic and this The interesting thing about this head logic is it's it's a pure thing. It's a pure function. So you can think in terms of even sourced Even sourcing or a reducer redux react kind of System where you have a pure function that takes some events. Those events can come from the various Connectors or the various systems that we are connected with. So we have the client on the right hand side the client expose For the clients we expose the api cpi is currently exposed as a web socket. So Fully asynchronous duplex api The logic is also connected to the chain. So evens can come from chain like observing connections and from network and network are incoming messages are Our events representing communications from the other high nodes in the network And of course these this The when the logic reacts reacts to events and can produce change its states The state being represented above in the upper part of the system it can change its states and Produce new new effects and these effects we represent interaction that would be sent to other parties So for example, if we follow the the path of a of the start the starting of a node of the head You can see that the hydra clients will in its the We ask for initializing the head This is gets into the event as the head logic the head logic posts the transactions Posts the connections to chain this connection gets submitted to the other node and at some point this connection gets finalized or confirmed from the common network, which is observed by the chain command and chain command Push back an event to the head logic and this changes the state of the head logic to initialize and now the commit can happen and the head logic would send Would send a notification to its clients saying hey The the head has been initialized and here is here is the state of the you are the parties and there is and please Please do your commit and now the same dense goes on for the commit um a few other things to note in in the various in this implementation and what what The main thing the an important an interesting point is this black uh White and black box about the calendar. This is really the exact same code That the color node is using Really the it's a library. So we are using some library So we are using the same ledger rules and this is very important and this is also a pure function by the way So we we put connections. We put a u g xo set We put the transaction and this tells us whether the transaction is valid and what's the outcome What's the new u g xo set and this is very convenient because now we can we can Deliver it the same logic and this is really where the eyes of office and kicks it um, and of course we um the The security of the chain is implemented using the what we call the the plotters scripts. So plotters is the counter no smart contracts language, um, which Is uh as a high schoolish flavor, I would say so it's it's a it's a it's Region in something that looks like high school, but gets compiled to be executed and run on chain Use as a as a lot as a pure lambda calculus function Expression That tells whether or not a transaction Is valid and that's only whether to describe this this has been Developing this blue script because this is an important part of the of the security of the system has been Significantly thought especially as it's a it's a bit of a moving target this is pretty new and and pretty challenging, but This is also very powerful. That's where really That's what provides the core security of for the hydra And we better be right in everything that um So, yeah, just sorry to interrupt just one second. We're we're at time now So if you could wrap up in the next couple of minutes that would be okay So I would just I would just go fast into the the the rest of the slides So you you would get the summary. I guess you would get the slides available anyway um Just uh, yeah a small focus on what's what's the what what we are targeting This is the basic head of our heads like what we call topologies those topologies represent for the basic head of head The the the thing we are implementing is a building block. This is it's it has a limited set of figures it can allow it allows one people to run hydro nodes and in a there is a fixed set or known set of participants in a closed world way and It's really a building block and the the goal is to use that once we get that version 1.0 out to use that as a building Building block to build more powerful abstractions like for example interconnected heads using some some research that's been implemented That's that's also been been implemented at iog Or or various or the topologies that that could be made that would be possible by This uh, this building block um, I would quickly go so when we we take great care at iog to um to um We we take pride into um implementing things using a more formal approach and uh very structured and formal approach so this is something that we are also implementing for hydro and currently working on a quick check based test Test generation system that would allow us to verify that the properties that are stated in the paper are actually implemented in Reflecting the implementation and we we check that the properties are old for the implementation potentially using some assumptions around the adversarial behavior of the network um If you want to know more there is a website everything happens in open source Of course, uh, there is a website that you can join so you can join the hydro family This is a really good entry point to the ecosystem and what we are doing Everything that most everything that we talked about is is there in a form or another And and yeah, there is a repository, which is public Contributions of course are welcomed in any form including uh, yeah stars feedbacks, whatever um, and I guess That's it So if I don't know if we have time for questions or if you just you uh move on to something else, but it is uh, basically a current state of state of the union for for the hydro Yeah layer two solution for Right fantastic. Thank you for your talk if someone has a really urgent question that they want to ask We can take one Other than that I see that Sebastian is already answering questions in slack So obviously you can always ask your questions in in slack as well and we'll keep the discussion going even after this is over