Hyperledger Foundation Meetups, 14 Oct 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Blockchain Scaling & Interoperability with Perun Framework

Description

A virtual meetup hosted by Hyperledger Budapest on October 14, 2021 with Matthias Geihs (Software Architect @ PolyCrypt), Oliver Tale-Yazdi (Software developer @ PolyCrypt) speaking about Blockchain Scaling & Interoperability: An introduction to using Perun Channel Technology. The Perun Framework is a Hyperledger Labs Project that solves blockchain scaling and interoperability using state channel technology.

More about the Perun lab is at: https://github.com/hyperledger-labs/go-perun

More about this meetup is at: https://www.meetup.com/Hyperledger-Budapest/events/280325139/

----
Hyperledger – Open Source Blockchain Technologies

Hyperledger is an open source community focused on developing a suite of stable frameworks, tools and libraries for enterprise-grade blockchain deployments.
It serves as a neutral home for various distributed ledger frameworks including Hyperledger Besu, Fabric, Sawtooth, Indy, as well as tools like Hyperledger Avalon, Cactus and libraries like Hyperledger Aries, Ursa. Learn more about Hyperledger projects: https://www.hyperledger.org/use

Case Studies: https://www.hyperledger.org/learn/case-studies
Training & Certification: https://www.hyperledger.org/learn/training
Tutorials: https://www.hyperledger.org/use/tutorials
Webinars: https://www.hyperledger.org/learn/webinars
Events: https://www.hyperledger.org/events
Vendor Directory: https://www.hyperledger.org/use/vendor-directory

Subscribe to the Hyperledger Newsletter: https://www.hyperledger.org/newsletter

Follow-us on Twitter @Hyperledger

Learn about Hyperledger Membership: https://www.hyperledger.org/about/join

#Hyperledger #HyperledgerMeetup #Blockchain

A

And then I can kick it off.

A

So welcome everyone to a virtual hyperledger meetup. Today we are talking about blockchain scaling and interoperability. With the prune framework, I put a link to the go prune lab in the zoom chat. If people would like to find out.

B

More and then I'll hand it off to mathias and oliver.

A

So take it away, yeah thanks a lot, so I will go back to the title slide, which summarizes in a slogan what coparoon is and what we will be talking about today.

A

So um we will be talking about the gopro library which we developed over the past two to three years, and this is a project together with the german company bosch. It originated at the university of darmstadt as a research project, and now we also founded a small company based on this, which partially um yeah continues to develop on this product, but also yeah has other products which I briefly will touch upon.

A

So gopal ruben is a library for enabling fast and cheap transactions on and across blockchains, and this is the core idea of the library we want to scale blockchain applications, and this is all based on the channel technology on a which were developed in a series of research papers, and the goal for today is to briefly touch on the technology.

A

Give you an overview of how it roughly works, but then also dive into the architecture of the library that we developed and ollie will give you a more in-depth look, how you would actually use the library and develop a small application with that so yeah. So I am myself. I'm currently leading the peru development team, I'm matthias um yeah and my role as a software architect in general, at the polycrypt company and I'm joined by ollie yeah.

A

He will talk to you later about how to develop an application with goparoon and he is a core developer in our team since pretty much the beginning of the project.

A

Our company that we founded based on the project, also has a few other streams, so one stream is certainly the peru library, and this is targeted at a scaling scenario where you basically already know which parties you will be interacting with you make a pre-deposit and anything that you interact in this small group of people will be very fast and very efficient and basically at zero cost, but then there's also other scenarios where you might not know who you will be interacting with with the assets that you have in particular, if you look at marketplace scenarios or non-fundable tokens, these are technologies that these are asset types and settings which do not work well for the channel technologies, and these we cover in our earthshot project, which is a different yeah different technology lying below this.

A

This library- and I just briefly wanted to mention and mention both besides that we also do consulting um so if you have any needs in that regard, you can also contact us and we we like to do research, use cases and implement software. So, but let's come back to peru.

A

What problems are we addressing with the proven framework- and these are mainly two- so you might be aware of- you might have heard these these these issues or these um these challenges with blockchains already, but I will um yeah take you through that uh briefly here.

A

So we know that the popular blockchains that most people use today, for example, bitcoin the most prominent, are bitcoin in ethereum. They have a transaction throughput limit, so we're talking about globally about five to 15 transactions per second, that we can process in the network and they are also relatively slow with respect to confirmation times.

A

So it takes normally about five minutes on ethereum to confirm a transaction depending on how much confidence you want to have that the transaction is really going through and bitcoin is a bit slower, so it can take up to an hour or even longer for a transaction to be confirmed.

B

The transaction costs are.

A

Also something that make small amounts of transaction relatively infeasible on these popular blockchains, because we see transaction costs currently of multiple dollars for the simplest transaction that you can think so. Many types of transactions, with only a small value where you, where you send only a small value from one party to another, will not be viable on these types of blockchains, and on top of that, the transaction price that you pay varies a lot on how much load.

A

Currently there is on the network, and these are problems that we address with our um with our gopro library and the stagehander technology.

A

The second second thing that we are observing right now that there are more and more different blockchain networks coming up so yeah bitcoin was the first first popular one. Ethereum is certainly very popular, but we are seeing other networks such as polkadot coming up, and now we have the the thing that these users on the different networks can't natively interact with each other, and here we can also use our channel technology to basically bridge these networks and enable transactions between users on different networks.

A

So how does it work? How does the perun technology work on a very high level? So I try to summarize this in this picture, where we see on the top the on-chain layer- and this is anything that runs on the global blockchain network. We can deploy the peru smart contract, which will be executed in a decent synthetic fashion in a trustless way by the whole network. But any interaction with this layer 1 will be costly and slow, as I just explained.

A

So. Basically, the goal is to enable transactions between parties without having to interact every time, so we want to put as much load off the network in a local, basically interaction between the involved parties, and this is what we refer to by the second layer.

A

So anything that does not directly touch the blockchain we refer to by the second layer and our goal is to establish basically a connection between two parties that know that they want to act with it within to interact with each other, and we want to do that securely efficiently and possibly even between different types of blockchain networks. And this is all what the peru channel technology and the gopro library enables you to do in a secure way. So, as I said, this is based on a series of research papers.

A

We have proofs of security that our protocols are secure.

A

We achieve uh transactions between uh two parties, basically with unlimited um yeah throughput. We achieve over 2000 transactions per second, and this is between any two parties that connect wire channel. So this scales pretty well even if you're many parties, um the the transaction cost once you are off chain, is zero. You don't pay any fees for that and, as I said yeah, this can even connect clients which are on different networks potentially.

A

So how does it roughly work? The first thing that the clients need to do. They need to discover each other and they need to decide. Okay, we want to open a channel and when they do that they can deposit some funds into the smart contract which will be reserved for this specific channel under a unique channel id.

A

Then we have our library that enables um off chain updates of the state, so the the clients will interact peer-to-peer and they will sign new channel states and thereby transact and and send funds from one party to another. For example, we can even applied additional transaction logic here and basically the idea is that any transactions that are done offchain, there's a guarantee. Our protocols guarantee that you can eventually settle these transactions on chain.

A

So once you completed a transaction off chain, even without a blockchain interaction, you can there's a guarantee that you can redeem this transaction on-chain.

A

So basically, once the clients decide okay, now they have interacted as much as they wanted. They can go back to the on-chain, a smart contract and settle the most recent state that they agreed on off chain, and then the funds will be available to the global network. Again. This is the very rough idea.

A

Are there any questions on that, or should we should we do that later.

A

uh So there's one question in the chat that I see: how do you prevent off chain double spend, um so the idea is that we prefund the channel. So when we deposit we know these are the funds that are available in the channel and only to the parties that are part of this channel. This is all defined in the initial deposit that is done on chain and now the consensus in this local channel works by uh by having all parties agreeing on the on the new state.

A

So you can only update the off change state if all parties in the channel agree and this basically controls um who, what is the outcome of the channel? If all parties agree that some funds should go from alice to bob, then they will sign it and they have a consensus on the new outcome of the channel. So there's if one party is not fine with with um with basically agreeing to that transaction because they think it's double spending, they will not sign it. So they would prevent this transaction off chain and um yeah.

A

So you can only make a transaction. Have everybody agrees, and usually you would not agree to double spending so so there would be one party that would disagree with that.

A

B

So there's another question about um which blockchains do we support.

A

uh So we currently support um ethereum as our main backend and uh develop currently polka dot backend and the backend for the cosmos network and the cosmos network. Backend actually got released just this week, so this is available already in the first version and the polka dot. Backend should be available later this year by the end of this year. So then we support three back ends like ethereum, polka, dot and cosmos, and we also started developing a dfinity background for the internet computer, which is in early stage.

A

Then there's another question: I think this will be the last one that I cover here, because we have some more slides to to cover as well. um How do you fix the price cross chain? This is up to the participants of the channel, so the logic of these channels can be totally is totally free to the to the clients to program any logic that they want.

A

So they can define how how to fix the price, and if you build an application with perun, you need to think about how a fair price for your swap protocol would be, and peru gives you the technology to implement that. But we don't set, give you just this this method for for implementing it. It's basically up to the user of the framework, how you want to realize your logic, so there's no, no prefixed answer to how we how we um yeah how we swap assets against one each other.

A

This is totally free to the uh to the application designer.

A

Okay, I think yeah.

C

A

C

Sorry luciano here from brazil, I have only one more question there, uh nice to meet you everyone there. uh I have a little question. For example, the smart contract written in group deploying the room framework. Is it written in a specific language or no.

A

Yeah, so basically, I will also go into this a bit more into detail on following slides, but um for enemy, so perron as its co. I think it will be covered on the following slides. If not, let me know so, you can write the the contracts in different languages, but depending on which blockchain you use so perron is kind of abstractly defined. It does not necessarily require one contract language because it has an abstract defined interface for interacting with smart contracts, but I will go into this lately.

C

I see I see so the purpose of peru. The goal of spiro is similar to to the go of like larger characters or no. It has a different approach.

A

Yeah, so I must, I admit that I'm not talking.

C

About interoperability, right.

A

Yeah, I I'm not 100 up to date about hyperledger characters, but I.

B

A

Saw that there's a talk on that, um so I think the project started independently, so we started as a research project and hyperledger characters started within hyperledger and I'm not 100 yeah aware about the differences of this project. But this general scope yeah looks pretty similar and I think we would have to go more into detail what are actually the differences, and this is probably also a task that that I need to cover for myself, because I didn't look at the project yet in much detail.

C

A

C

For the answers matches.

A

Yeah yeah, and we will also do a hello world introduction later with ollie and for now I will continue on the high level idea of the technology, so also to understand better how that um how using our library works. I will briefly uh take you to uh through the steps of how you open the channel transact on it and settle it.

A

So when you open a channel, you first send a proposal and, and the goal is so so basically, you need to know which participants you need to know the addresses of the participants that you want to open a channel with, and then one of the participants will send a channel proposal and the other participants will agree with that or if they agree, they will sign it.

A

And if we have a signature on this channel proposal, then there's a guarantee that this channel will be open, can be opened on chain and the funds will depo will be deposited into the contract once this has been done once the fund has been deposited, and this initial agreement has been done, the channel is open, off-chain and any participant can basically propose a new update to the channel and a recruitment off chain is reached by every participant, having a sig uh by having every participant sign the new state.

A

This is the the update procedure of jane and once the the participants or if one participant wants to close the channel, there's two um yeah two ways to do that: either everybody agrees that they want to to close the channel, and this is the collaborative case which is the quick one, also because there's no dispute occurring, so they all agree with the signature. This is now the final state and we can conclude it on chain if there is a dispute.

A

Of course, our protocols have to cover that some of the participants may not react or they may just not counter sign, and in this case we open a challenge response dispute protocol on the smart contract, which guarantees that whatever was the latest state agreed of chain, will be concluded on chain.

A

So some participant registers his local state and if other participants have a newer state, they can register it and basically refute the state. And after some time we will have a final answer. What is the most recent state and we can conclude the channel and withdraw the funds from the country? That's the rough idea, and we will see that when ollie shows you how to how to write an application.

A

All right, so just a brief overview. How the architecture looks like we, when you write an application with goparoon at the core of the library.

A

Is the state channel logic, which is an abstract representation of the perum protocols, and any interfaces to the outside world are represented in an abstract way, and this means you can basically peru allows you to plug in your favorite blockchain backend your favorite database backer and your favorite network message, broker, backend and also logging is, is only represented in an abstract way so that you can use it within your environment that you like, and regarding implementation, in particular regarding blockchain back-end implementations, we have the ethereum backend, which is feature complete, so all features that are in the core library are available in the ethereum network, currently uh cosmetim.

A

We also so for the cosmos network. We have a backend just released this week. Here is still.

B

In development.

A

Because this yeah yeah was just done this week and polka dot will be released later this year.

A

The this picture should give you an idea how the go project is structured into packages. This basically resembles what I showed you on the last slide. So if you want to work with the library just to give you an overview, what are the different packages in the go in the in the go module? We have the client package. This contains the protocols it interacts with the wire package, which is the abstraction for the message communication between the clients. We have an implementation on that. With of that which is very simple based on tcp ip, then.

A

The client, of course also needs to to interact with an account model, which is the wallet package, abstraction and the client for interacting with a smart contract, basically with a smart contract logic that runs on the blockchain. It interacts with a channel package and for the channel package specifically and the wallet package. We have these blockchain backend implementations, which give you concrete implementations of these packages of the interfaces in this packages I should say, and for example, in ethereum, the channel package contains a contract that is written in solidity and for the polka dot.

A

Back-End, the channel package contains a smart contract that is written in rust, so this abstraction basically allows us to yeah to to work with any blockchain that is, smart contract enabled and potentially might even work uh with bitcoin. If we apply some tweaks and recent research results but yeah. The idea is that we have an abstraction which lets the core protocols work, abstractly against any kind of blockchain backend that you can make work for these defined interfaces.

A

Okay, um that's the end of the part um about the um yeah, about the overview of the architecture and now I would hand over to ollie, and I think we should also do that in the interest of time, and we can address more questions after that.

A

So only you can share your screen and ollie will show you in a brief example how you would write an application with gopro.

B

Yeah, great so um hello, everyone, um that's my screenshot work.

B

A

I can see it.

B

Okay, great, so um what was the look welcome to all you guarans since um yeah budafest, um and so I will uh show you how to build an application now. um I will also show you the demo first.

B

So all the tech, as all the non-tech savvy people can just stay in for a second and then see what we will achieve so on this overview graph, the orange parts are what we are going to build and what you see here is one um bob node and one alice, note and ethereum chain, um and these connections here are the communications between them, so on chain always stands for when a client communicates with the blockchain on these two sides and off chain is the communication that happens between the two participants and stays private between them unless yeah they need unless they have a dispute or something, but normally this is um yeah very fast because it doesn't reach the chain and in the ethereum chain we have the two smart contracts, as materials already hinted, so the adjudicator, which is used for disputes and adjudication in that case and the asset holder, which holds the balances and manages them for later use.

B

So I will now start all these three parts and then show you how they interact. So we first start the blockchain. This is just the local ethereum chain. It's called ganache.

B

And if we scroll up here, we can see that all the accounts start with a thousand eve, so they are just pre-funded, but um this is important to know so um you can see the results later on now I will start the ellis node in the right window.

B

um She deploys to the smart contracts on the asset, holder and adjudicator and then waits for connections, and now we run the prop node in the left window and, as you can see, there is a prompt now about an incoming channel proposal with 500 500 eve.

B

So we click on accept here enter y, and so it takes a while, um and then you see that the channel has been opened between the two um and if you now look at the on-chain balance so with info, we can see all the balances. Currently we see that alice and bob both have 500 in the channel and also 500 in the blockchain currently, and bob now queries for an integer onto how many microtransactions to do so. um Yeah, since more is always better.

B

Let's do like 50 transactions and, as you can see, this was really fast. So it's um the printing is what takes the longest here: yeah just that were 50 transactions, and now we press enter and then the channel will be closed, so bob's already done and alice waits for the event from the chain and after that happened we can then again look at the on-chain balance with info and see that alice now got the 50 that I transferred in microtransactions actually on the blockchain okay great.

B

So now I will show you actually how to build this. For that I will go to the start state again in the unfinished version and open all the files. So.

B

Right, first of all, I will show you um here the structure of the project, so we have like multiple golem files, it's a go project and then the go mode. The dependencies um which, as you can see, depends on grouper roon, so the framework that we are using and go ethereum for ethereum, specific stuff, yeah and some other configuration.

B

Okay, so now we look at uh at the configuration for the program itself, that's all uh held in this conflict struct, it's the mnemonic you're, probably familiar with that with metamask, where you enter your memonic and a chain url of the ethereum blockchain, and then we have some other setup like ip addresses um account addresses and the addresses of the smart contracts.

B

Okay, yeah. I think the concrete values are not important here, but just so you know that x exists great.

B

So um let's look at what actually happens in this program. um It starts out in this main function with first the setup, then a channel opening with where each side has 500 eve and then a for loop, which always sends one eve to the other party, and this query function. Query number function is just so that the user can enter a number that makes it a bit more interactive and then, after this has been sent, it just waits for an enterprise, and then it closes the channel.

B

So, like a really easy example, now, let's look into the code.

B

Right so this is our notes tract and all the members that are contained here will be explained in the setup now, but this holds the complete state which we need later on.

B

So let's look at it. The first thing that we set up is an account. um This is an ethereum account from the mnemonic that I mentioned earlier and the bullet and it's important to know that copper roon can handle two accounts, so one account for the on-chain communication and one for the off chain, but in this case we just use one account to keep it simple.

B

The distinctions can be used for privacy reasons, so yeah this function just sets up the account and the wallet. This will be used by google loan for signing transactions and off chain states.

B

Then this transactor um it takes in the wallet, but um this is just ethereum specific, so it will look different for every blockchain, so yeah. This is not really um important right now, then um we have the on-chain connection here. This is the uh this arrow, uh the on-chain connection between bob and the chain, um yeah it takes in the transactor and then returns the connection.

B

Then we have the contract set up. This gets in the chain connection and account and it returns to smart contracts. So the adjudicator and the asset holder- and the only really important thing is that it validates the addresses.

B

Since I'm in the config file, I edit the addresses, and if I mistyped them, then yeah the user could lose money, so we verify them here.

B

The next thing is the bus.

B

This is important for the off-chain communication, part between bob and alice, and it again takes the account so that alice can verify that she's really talking with bob and not some kind of imposter, so um yeah. This uh bus will then be used for network communication and forwarding of the messages.

B

Next, we have the funder here. The funder is um needed to deposit funds into the asset order, so bob will then use the funder and deposit ethereum into the asset order and it again takes in the onshore connection, bob's account and assent holder, smart contract, okay, and where are we even doing this? So um it's all important for this for this function here.

A

B

All needed for this function, since this is actually setting up the copper room client. I just called it paren.new here and yeah, so it is a nicer, alias to understand it and it takes five arguments. So the first argument is the address that would be in this case bobsledders.

B

And it takes in the bathtub here, so the address is used for um for letting the client know which which address they actually want to use. um Since we we don't distinguish between on and off chain addresses it's um yeah. We can just take this one. um Then it takes the bus to um enable the communication between alice and bob our funder that we just set up and adjudicate a smart contract and a wallet so indicator will then be needed for the disputes and the wallet for for signing and verifying.

B

I always have this no error here which will just assert that nothing bad happens. So yeah, it's code is keeping it simple here and then we just store all of this in our notes tracked.

B

Okay, um so then we actually have the client set up, but um it's not really um going to react to anything. Let's say: if someone wants to open a channel with bob, then it wouldn't react to it.

B

In our case, we don't have this in the protocol, so we don't have this in the demo right now, but I will still explain it to you for completeness reasons. So, let's start with the proposal and update handles there is this handle function on the client and it takes into arguments.

B

So it's two interfaces once the proposal handler and then the update handler and conveniently we will uh implement both of them on the node. So we just put the node here twice: it's a pro call, since it is otherwise a blocking call, and um so, if you look here again, first was proposal handler. This then expects you to implement a handle proposal function, and this is actually, in this case only relevant for alice.

B

That's why it's empty here, so um it gets in the channel proposal and a responder and alice would then react to this proposal by either accepting or rejecting you can yeah look at the proposal and say: if you like it or not, and then, if you accept it, you will get a channel.

B

And the next one is the update handler. So this is down here in this case, bob is sending the update, so he does not implement need to implement this as well.

B

It first gets in the old state which the channel had before the update would be applied, then the update um which is being proposed to update and then a responder where you have accept and reject, functions on it. So you can look at the update and then accept or reject it.

B

Okay, um there's one more handler here which is called handle adjudicator event. This is not used in the code right now, but I will still explain it here briefly, so um this is for reacting or to events which happened in the adjudicator smart contract. That's important for the dispute case um yeah, but we don't look at the dispute case in this example. So it's just empty, but there's another function for setting this on the client. That copyroon would then know that you have actually implemented this.

B

Okay, so that's this for the setup: let's look at our main function again.

B

This is what we did now with the setup and now the next is the channel opening with um where we pass in an amount.

B

So let's look at the open channel function, it's down here and it takes in the amount and it should return a channel.

B

So in order to open a channel or to propose a channel in gopro roon, we have to input some configuration to actually specify how we want to open it, and we do this by defining the initial balances of the channel and since copper, rune channels support multiple assets, you can even specify which assets you want to use.

B

We only want to use one asset so um yeah to keep it simple right now we just use the asset that we have in the config, so asset address, and then we put in the balances of alice and bob how they should be at the beginning of the channel. So after it's opened um in this case, we have to write bob first, since he is the proposer of the channel and the proposal goes almost as first entry yeah. So now we have the allocation and we also define which will be part of the channel.

B

So again, bob goes first and now entering the addresses of both parties. um So.

B

Fill then the copa rune which addresses should be actually part of the channel. um Then we yeah propose the channel. This is like a two-step um thing, so, first we create a proposal with error um and then we call this on the.

B

On the parent package, so new ledger channel proposal, as you can see, there's also sub channels and virtual channels. Since um gopro rune supports multiple types of channels, we will just be using the ledger channels for now.

B

um First, we put in the dispute timeout. This is uh like not important in our case, but yeah, it's still necessary for extended configuration and we put in the address of the person who proposes it. So in this case it pops edges and we put in the initial balances, which we just defined up there and the participants are part of the channel and again asserting that there was no error and then we can actually send this proposal.

B

With by using the client the parent line that we set up and calling proposed channel on it, I will not be setting up a context here so just using background and then putting in the proposal.

B

So this should then yeah propose the channel, and if the other party accepted the channel and the handle proposal handler, then we will get a channel here.

B

If alice would reject this channel proposal, then yeah we will get an error, but this case is not not interesting right now, so we just don't look at it and the last thing that we can do here is uh we can start a watcher which will watch for um events on chain which happen in the adjudicator, but I will just show you how this looks like um not like that. Yet it's an interface.

B

So we call watch on that, and this will then um use this adjudicator event handler, which we had up here currently empty to um yeah, maybe handle some some disputes right. Okay, so now we got the channel here and it's being returned.

B

Let's look back here so we have our channel nice and easy and um and the next thing is descending off the balance. So that's the same balance function, that's right below here, so it gets in the channel and an amount and then should send this amount to alice and we we send an amount by updating the state of the channel.

B

So we use our channel and call update by and this takes a context, but that's ignored right now and then a function which modifies the state here. So if we now want to exchange the balances, we first have to subtract it from box balance and then we have to add it to ls balance so that complete balance in the channel stays the same so that you like can't double spend to achieve balances, otherwise copper rune would reject it and alice would reject it as well.

B

So using co length weekend api, we now sub this from bob's balance.

B

So we are using an asset index here, since we have possibly multiple assets. We just use zero asset because there's only one asset in our channel and then we use ops index which in this case will be zero, and this will then actually expression will give us bob's balance of the asset, and we can then select amount from that, so that the new balance of prop will be the subjective amount and then we assign it with an equals or we've set or something to buff bell right now.

B

We need to do the same thing for alice, but with an addition. So um we we take alice balances. uh Let's balance in the channel, add the value to it, which is that function and then set elem's new balance. Here, okay, then uh transfer the balance and yeah this. This call returns an error, but in this case we assume that alice accepts the um update, so everything should work great um yeah.

B

So there's no problem with calling this multiple times in the for loop, so yeah that works and then the last step would be the general closing.

B

This is down here, it takes a channel and it will close the channel. So what this means is you want to get the result of the funds that are currently in the channel back onto the blockchain and what we first do is we have to finalize the stake since um otherwise that's what we dispute.

B

If we, if we don't use the final state and just try to close the channel, then it would actually go to the adjudicator and try to dispute the state. But by doing this we are using the cooperative case.

B

Okay, then we just call it settle on on the channel so and with no context, and the secondary rule is only for guess, optimization on ethereum. This is not um important to look at right now.

B

Just ignore the error here and this settle function will then also withdraw the funds back onto your on-chain account and then there's another function for um for closing the channel, which actually just reads, freeze resources. This is not for protocol reasons, so um yeah that should be it, and if I did everything correctly, then we can try it out.

B

So, let's again start with a nice chain.

B

Which yeah as before is giving everyone 1000 eve, then the alice node, which did not change.

B

Again deploying the contracts, and now we start the modified work node.

B

So there's a channel opening again with 500 500.

B

alice accepts it. I can actually also show you the transactions on the chain, so um there's one transaction here and another one and yeah two funding transactions. So it's actually happening um now. We can enter an integer. I could go up to 499. I think here, so the printing into the console takes the longest. um Actually, this takes less than a second uh yeah, much less than a second. So and now, if you press enter then um yeah the channel gets closed.

B

This will produce more transactions on the chain right here and yeah, some more there great and um yeah. If you look at the on-chain balance again, then we can see that l is now got to 499 more and bob just has 501 remaining okay. um I don't know if I can answer any questions now. Otherwise I would be giving back to. But yes.

A

Yeah, I think we we have some time to yeah. Does anybody have questions on the implementation part? Now is the time to to ask and learn more about how to do how to work with the framework.

B

Otherwise, you can also like um ask your questions. Later. um We will probably be some longer into the talk after the official part.

A

How do you plug another resistance interface in a specific database? Do you.

B

Want to um yeah we we have a persistence layer.

B

Enable persistence function and this would then like allow for persisting and restoring channels and, as you can see, it takes in an interface, persister restorer, and you could then implement that if I look into the code, what does it need to know yeah? We uh designed this very smartly, so there's all kinds of functions here which are nicely abstracted, but it's an interface. That's the important thing. So um you.

A

B

It in by that- and we also have default implementations for level db, and I also think for an in memory representation, but I'm not sure about that. Definitely level db.

B

You have any other questions.

A

Didn't check youtube, do you should I.

B

See it, but it's fine.

C

Or it can be on any other thing, defaulting.

A

um Yeah it can also, I mean I would like to address implementation questions first, because then I will wrap up the talk and then you can also ask more general questions afterwards.

C

Okay, okay, so I give the space for you asking the the questions. Then I ask my mine after that.

B

C

B

Mean if everything was so understandable, then I'm also fine with it.

A

Yeah- and you can also re-watch it later so and drop us a question either via our website perun.network or in github. We have the github repositories open source. Of course they can be found at have a little apps and I think yeah. If there are no more questions on the implementation, then I will wrap up and show the last slide. So can you.

A

B

Here's the slide.

A

Yeah just to briefly wrap it up. um Yeah gopro is a modular library for building scalable blockchain applications, so in particular for payments between small number of parties for micropayments in particular. This is a very suitable technology and we have multiple supported blockchain backends. You can even implement your own blockchain backend. If you like. We were also considering, for example, implementing a backend for hyperledger fabric, and the really nice thing about the technology is that it is potentially possible to enable channels between blockchains between different networks.

A

This is something that we know how it works, but we haven't implemented it yet, and we will uh be starting that soon.

A

That's the plan and hope to have this functionality, at least in a basic kind of way, available within the next half year. So then, the library will also support transactions and opening channels between different blockchain, backends yeah. Here's all kinds of links that you can connect with us. So of course, our repository at github or our project website. We also have a twitter linkedin, a medium account where we post news or more information on our technology, also in our other products, with our company polycrypt and yeah really happy.

A

If, if you want to connect with us and yeah, that's that's it from our side and yeah. If any quick questions, I think we need to close in in a few minutes so that people can move to to the next talk which is starting at six.

C

um Just one little fast question here: oliver uh excuse me: uh I it's still a little bit unclear for me uh not unclear, but only to check that only to confirm uh the communication of chain between the clients between the agents of the agents. uh This is done only to guarantee to give a warranty that you were. um How can I say what you were talking with? We were talking. You were speaking with someone that has a true identity that has a it is a trustable agent.

C

I don't know only to warranty trust trustability between the agents among the agents. Sorry, because, for example, the assets are going to be stored on chain right.

C

Yes, everything that you that they make the transactions and what would what would the offshoring communications uh serve for the utility for that they go actually for that.

A

So it's the the the goal is that you can uh finalize transactions without needing to go to the blockchain every time and the identities that you use in the channel can be the same identities as you use on-chain, but it can also be different identities and they can even be different from the addresses that you use for the network communication.

A

Of course, so we have different identity, abstraction layers, and if you want, you can basically use the same identity across all layers, that is, for on-chain transactions, for off-chain transactions and even for registering on the network layer. You could also use the same identity, but we, you could also reuse different cryptographic identities on all three layers. So that's up to the application.

C

Yeah, so these this final, this transaction finalization off, would make the transaction not on the transaction, but all all the transaction. All the transaction life cycle more faster right, faster.

A

Exactly that's the goal, and after.

C

We don't change.

A

Exactly so, the idea is going on chain for very small amounts of transactions is not feasible in in some cases.

A

So, for example, when you have a pay-per-view streaming service where you regularly get updates and you should pay in small incremental intervals, this is not something that you would like to do on a blockchain, but using a payment channel you could do that or if you have a game and people interact with the game on a regular basis.

A

And then you have a group of people who regularly, depending on the outcome of the game, want to yeah transfer some some money between each other- and this is a very nice use case for for payment or even for state channels which can have arbitrary transaction logic. So after the game is over, then the people can say. Okay. Now we are fine with the outcome we can. We can basically redistribute our money depending on the game outcome on that blockchain and if there's any inconsistencies, any disagreement between the participants.

A

Our protocol will ensure that the outcomes can still be resolved, at least depending on the most recent state in the game. That was still fine. That was not compromised.

C

And doing that did they out here right.

A

C

Doing that, for example, solving any kind of eventual problem like that of double spend transactions- auditing, the blockchain right auditing, the dlt, the larger.

A

C

Yes verify, for example, you've you you've stated, for example, a kind of, let's suppose that there's a problem between the participants or some divergence of some transaction. I don't know- and, for example, those transactions were made of. No, not the transactions the transactions were sa were signed, were finalized, off-chain right.

A

C

Example, if there's a problem, if there's an at the divergence between among the participants.

A

Okay, yeah, I think I get it exactly. You use the smart contract to resolve the disputes. That's that's the idea yeah. So anytime, you get a dispute, the the smart contract kind of resolves it and you may call it auditing. I would call it uh yeah adjudicating or resolving the dispute. That's the role of the of the blockchain india.

C

I see ah that's the role of the adjudicator, that's smoking.

A

Yeah there is the smart contracts, it's just like another name for the role of the of the smart contract.

C

I see I see okay thanks, uh I was talking with sorry. I think I was not talking with oliver I'm not seeing who is talking here. You.

B

Talked with matthias.

C

Matias: okay, thanks matthias thanks.

A

Thanks for your questions, yeah, and if you want to yeah connect, you can write us an email or have more questions.

A

Surely do that? Okay! Are there any other questions.

A

Yeah, if not, then I don't. I don't see any so you see the information where you get more information about our project, the websites and yeah. I think I yeah said it all and yeah. Thank you a lot for attending the presentation. I hope you got something out of it and we would be happy if you try out uh using the gopro library and experiment a bit with it, but give us your feedback thanks a lot and yeah. I think that's it from our side.

C

Okay, thanks matias, thanks oliver nice to meet you, everyone.

A

Have a nice day, yeah youtube yeah! You do bye, bye, thanks, okay, goodbye.

C