Let me start. Recording.
Alright Welcome everyone to the October twenty-seventh Technical Oversight Committee.
Call as you're all aware 2 things that we must divide by on call calls.
The first is the antitrust policy notice, and the second is the code of conduct which is linked in the agenda as far as announcements today, we have the standard Dev weekly developer newsletter that goes out each friday If there's some that you would like to reach
the hundreds of hyper like hyper ledger developers.
please leave a comment on the the Wiki page that is linked in the agenda.
The second announcement that we have today is that the Tlc nomination period is still open.
the nominations do close on Monday, October 30 first.
So if you are interested in nominating yourself, please do so.
And then Rye, you said you had an announcement.
Well, it was an expansion on that announcement, and that is the people that have nominated themselves.
The minority of those have filed an issue.
Okay.
Okay, any other announcements
Okay, not seeing any hands or anybody coming off mute. We'll take that as now.
as far as Quarterly reports the ursa.
One is in draft. So last I looked. It still said it was in draft, and that we shouldn't review it yet as far as The other.
2 fabric and cacti. I haven't seen any specific comments showing up on either of those.
But does anybody have any questions that they'd like to bring up at this point
Alright. I will take that, as I know, so as far as upcoming reports, we do have this talk to a report that is due today, so we'll look to see if that one comes in today.
And then we also have the Aries Indiana Roha reports coming due on the tenth of November.
so we'll expect to see those at that point.
Any other items that anybody would like to cover before we get to the presentation that we have scheduled for.
Today.
Okay. So we have no other just discussion items. We do have the the folks from the prune lab here.
We have Mano and the Ts that are here, and they're going to present to us the prune lab and walk us through that.
So I will hand it off to to you.
Okay.
Yeah, thank you. Then I can share my screen now.
Yes, please
Hmm! Can everyone see my screen? Yeah, Okay? Perfect: Hi: everyone.
I'm manufactured. I work as software engineer and Bosch and I have been involved with parents since the beginning days.
Perron is is a framework that targets 2 problems in the blockchain space.
One is blockchain scalability. Another one is blockchain interoperability.
It's it's started out as an independent project, and later became a hypothetical labs project, And it's collaboratively being developed by Bosch and a Polycarp Gmbh: I would like to start with the problem statement that we try to solve
we are aware that blockchain provides an excellent mechanism for doing trust transactions, say payments, or, in more general terms, exchange of any value.
but with time we have seen that there are quite some limitations.
With this the first one being limited transaction throughput.
For example, if we look at Bitcoin, it has like 10 of transactions per second.
That's the limit, and there are quite some new chains which have improved the layer one scalability.
But the's still a limit on on how much we can go far in that respect.
So a layer to scaling then becomes quite important. Second is a problem where which we figured out along the way as we develop pair, one that the blockchain networks as new.
Ones come up, become The The network is getting fragmented, and then we need mechanisms to make the networks, interrupted with each other, and we we realized that the technology we developed with spareone is usable.
In this context as well. So these are the 2 challenges that we target.
now mainly coming to the agenda for the presentation.
First I would like to present you an overview of the parent framework, then a brief history of the project, and then the interesting applications that we see Yeah, first, the overview to begin with, let's say 2 participants, Alice.
And Bob they want to make some transactions, so they come, together, and and they talk to each other on what transactions they want to do what they rules for the transactions are and once they agree on these terms they also decide What are the elevators For them for example, in case
of a payment. Channel. It could be that Alice wants to be able to spend 10 units of a currency.
So they decide all of that, and then approach the blockchain to say, We want to open a channel, and these are the initial terms of the channel, and these are the sets you Would like to block in the channel Then the assets are blocked in the parent smart contract and the their own channel
is open for transaction now, each of them could make any number of transactions in a very direct peer-to-peer manner, because these transactions are direct peer.
There are technically no limitations, only limitations on how fast they can make the transactions, how fast they can create new States and creating new states is basically about generating data and then making signatures on the data and the second limitation is how fast.
Is the communication channel. So these are the only 2 factors that limit them, which means they can easily reach thousands of transactions per second with a near 0 cost.
For each of the transactions and the confirmation is immediate.
As soon as both these parties signed, then that particular state is valid, and after they make any number of transactions in this fashion, they can go to blockchain, and say here is the final state that we agreed on or that we want, to settle, and then the parent smart contract
will validate that state; and and if verify, if it's really the final state, and one, it confirms that it's a final state.
It will settle the channel and redistribute the log assets according to the final state.
So this is what happens with parent State tennis. What the Protocol provides is that it's probably secure meaning.
It has been proven in a formal way that if any State that is generated on the off chain, parent channel can eventually be settled on the blockchain, it only becomes invalid when the next State is created and second thing is cross chain capability, so in
this picture we we can see that the parent smart contract is just one unit, which means we are using one blockchain back end, but we also figured out that we can use a parent we can open a parent channel, that is simultaneously using 2 different blockchains for example, a
Perim channel, which blocks assets for Alice on one chain satirium, and for Bob one another chain, say, Well, like cosmos, or something like that Yup.
So this is an overview of how the parent State channel works and coming to the implementation part all of these parent protocols, and that we as we as we call the Funding Protocol, of the off chain communication protocol and the settling protocol everything is
defined is implemented in abstract way that is, independent of any blockchain back end of any persistence.
Mechanism, and even independent of any networking or civilization format used for the option communication.
So this is a real, abstract, and modular core of the framework, and into this we can plug different blockchain backends, and I think we currently have 5 different blockchain backends.
Ethiopian cosmos, polka dot Internet computer and fabric, and for network and civilization we we currently have Tcp for the transport protocol and and for serial session we are using a custom format called parent Format and recently, we also
implemented protocol buffers. So which means you can just take the quote of definitions agenda, the steps and easily implement the parent client in any other language, and for persistence we currently persist all the off-chain states that are created in a level.
DB. But again, this is also pluggable. You can go for any other options, So this is the core of the framework, and on top of this we have the second component which is peron node and per node.
What it does is that, in first, place, it takes the open framework and configures it according to your use case.
Picking one of the options for each of the plugable modules, and configuring them in the needed way.
And on top of that it provides an abstraction called session.
So what session allows you is that it manages all the channels that a single user has, and all the keys and wallets associated with the chat with all the channels of the user and additionally it also maintains contact list on off how to contact each of the peers that
the user wants to talk to. They're off chain information to maintain all the off information of those peers, and it provides an easy api for the user to open channels with any of these peers and and then transat on those channels But this is a more a generic
kpi which is, providing all of these functionalities.
But if you're looking at a specific use case, say payments, for example, Then on top of the session Api, we provide another Api layer, which is payments api layer, which is providing like really simple api's allowing you to specific only need the data that is required
for payments, and this payment api can either be access as a library or like a go library, or anything, or if you want a scenario where you want access over remote, interface, then you can just implement a Gfpc adapter.
So this is also existing right now, and so on. So this is like we the extensible component of of the whole parent framework, where, depending on a use, case, you can just implement lighter api layers without modifying the protocol or the session layer so
that's the interesting way in way in which the whole code of the protocol can be extended by using plugins and the a framework can be more usable or tailored to use case.
By writing appropriate Apis in the only in the upper layers.
Yeah, So this is an overview of the 2 components of current framework
And now we come to project history. We started in 2,018, with the publication of Parent.
Such paper. This was published by Sebastian first, and then a few of his colleagues from Tio Dam, start in collaboration under the University and then, Bosh joined with them to collaborate on the development of the parent framework.
into those 19, and from there we had several milestones before we eventually became a hyperlogile apps project in in late 2020, and from there it has also been interesting that we develop a lot in terms of the framework functionalities and We even presented a few demos in hyperlog in depth
series. And as I told that we have several other backends like Polka, dot, and cosmos.
We also collaborate with the corresponding communities as well.
So. So this is how we are. Our collaboration looks like in in time
And finally I would like to discuss some of the applications that we find interesting, and that we had experimented with so far.
First of them is their own IoT state channels. This was also one of the initial use cases which we had in mind for Bosch like, How do we enable 2 devices to make transactions based on blockchain so that was one of the initial questions.
That we had in mind, and the parent state channels that we developed.
we extended it further and and the reason that we needed to extended is for that the IoT devices that are here can have like real limitations on on compute memory or network interactions.
Or even power. Consumption like they can always not be connected to Internet or and so on.
And so we it is. It is tricky to expect that the device is able to do all the blockchain interactions by itself.
So we thought about the key parameter for for of IoT devices, which is that each device is owned by a owner or a user, or if it's by company, then it's administered by some person, so, then we said, let's build some protocols to
outsource all the blockchain interactions of the device.
To this owner or administrator. And this device is then interacting only with the other device that it wants to transact, with and with the user never with the blockchain and and these protocols we released in our recent releases and we also presented an extensive talk on depending on
I to state chance itself in the last week. So that is the first use case that I want to discuss.
The second one is blockchain gaming at low latency.
So this is a very interesting use case. Iuna is a blockchain gaming infrastructure provider in the polaroid ecosystem.
What they're having in mind is that they wanted to build a game that works completely on blockchain like it.
It Every move that is done is stored in the blockchain, and this means games are usually fast, and then the need, like real time, confirmation of transactions, and this is quite not possible. In The layer.
One. So they were looking at a a layer, a very low latency layer for implementing their game logic, layer, which is recording these transactions and eventually recording it on blockchain and that's where pearon was a very interesting fit and this is like work in progress and if you
have more questions we could also discuss about it in in in the discussion section.
The next use case is trustless. Across Genocide Swap.
So here, as I said, in the event discussing the concept of parent channel, let's say there's a client who has an asset on ethereum, and then there's a liquidity provider who has an asset on polka dot and now these
2 people want to exchange their assets, so what they can do is they can open a parent channel, blocking their corresponding assets on the corresponding chains.
So the client will block data set on Pvm.
And the liquidity providable block data set on Polka, Dot and then they can also give each other the addresses, on the chain, for example, liquidity provider will give the address to which they want the asset to be transferred on ethnium, and vice
versa. And after this channel is opened, what they can do is they can create a state which is swapping the assets.
So it is wrapping the asset ownership between the client and liquid provider, and a single atomic transaction, and then they can finalize the state, and again settle it on the corresponding chains where the smart contract will then scrap the assets
for them on the corresponding chains. So this way, it's very cheap.
and and trustless tokens have, because you're now not relying on any intermediate party like a bridge or something
And next use case is trustless, credential payment. This is similar to the trustless cross Cross as it's crossing as its web.
But then the differences here. One of the asset is a piece of data, maybe a decentralized Id, or something, which is, it should be an authority, and the other asset is the payment for it.
So both of them can block the corresponding assets in the perim channel, and inside of the channel.
They can swap it in an atomic way, and then set it again on a chain, which means again, this is atomic in nature, and because it is done off chain.
it Can be like really thousands of transaction. Second Ss: we said, and I think we implemented a Poc in on this, which is available, on Internet, which you can try out and currently we are also working to integrate this into the hyperlger areas framework that brings us to the end
of presentation, and to summarize, I think, Perone, we would like to call it as a toolkit for blockchain scalability and interoperability.
Using the State channel technology and the key advantages that that it offers is a low latency, modularity, and it's beyond, based on peer reviewed research and and formal proofs.
and as a good segue to discussion, section I think one of the interesting things you would like to discuss is possible opportunities for collaboration within the hyperlog ecosystem And then what we saw based on interactions during the global forum was that a 2 projects
hypnotic cactus and firefight might be interesting. I mean, might have interesting avenues to collaboration.
But then we are looking forward for your inputs as well on how to think about this
alright. Thank you for that. So I have an initial question to kick us off, and then hopefully we'll get some other questions as well I'm curious about the the roadmap for the Proven framework you know, when we're looking at the history. It kind.
Of you know, peaked in my mind that you know I'm curious as to what's next.
Yeah, sure.
Yeah, I think in terms of roadmap, one of the things that we're currently looking at is IoT state channels.
What we demonstrated in in the recently is the ability to use the main framework on devices like raspberry, pi, or little more capabilities.
So One of the things you want to do is develop a light client which can work on like real, like low embedded devices which are like running bare metal or or running an octos kind of systems, so that is one of the areas that we want to go forward and maybe
yes, sure. Maybe I can extend this a bit. So we are currently also working on extending the prune framework to other blockchains.
So, for example, right now in progress is Cardano. So this demonstrates the The framework is also can be applied to EU ticks, or oh, stop blockchains And Yeah, we're also in talks with further blockchain ecosystems for next year.
Then, Yeah, mano highlighted. The SSI use case.
So we recently in this October, started a project, on integrating this into the areas framework, and this is a project that we plan for the next 2 years.
And it's also partially funded by the State ground from the German Estate Government and there then we are also continuing on the gaming use case that manufactured will the folks from are Youuna network and yeah, then of course, we also intend to we are open for yeah.
becoming a full hyper ledger project. So for that there are a lot of things that that need to be done.
For example, streamline the naming streamline, the repositories.
Documentation, create more attraction in terms of marketing, and also create more attraction in terms of the applications as they are currently in Yeah, Poc State.
What are the plans for additional chains or additional sort of work that's going on There
hey? Thanks, minority! This was This is really nice project, and I'm actually personally looking forward to a project like this.
Matthias or Henry can highlight on some other areas that we are looking forward for
it's really beneficial for the community. And I have 2 questions Probably to kick it off.
Yep.
I My first question is from the interoperability tangle right?
so can you collaborate a bit more on that.
So when you talk about interoperability, it's not actually providing a set transfer mechanism across an option.
It's rather thinking mechanism on the same blockchain but the panel node itself is adaptable.
Yeah.
no. Maybe I can go back to that area one moment. Yeah.
So So what happens is that you can have 2 different contracts.
So say one contract is on Polka dot, and one contract is an ethereum, and then when you come together in opening the channel, so during the initial interaction, you see that liquidity provider has the asset on polka dot and client, has asset on
itvm and they're going to block and swap it.
So all of this is agreed in the first transaction, and when we have to fund this channel, we funded on both the chains.
So on. Both these smart contracts we block the assets, and and then only the channel becomes open, and once it's Sanders open, you do the first transaction. It's also a last transaction, which is wrapping the assets and once you create, that state that state can
be used to climb the assets by the other user on both the chains, so that way, it's it's an asset.
Swap, not begging.
So single channel. Is is like you're actually swapping the ownership of a set in the in off chain, because in off chain is a single medium and it, can be done in an atomic manner, and then you go back and settle claim your assets back on The chain
Okay, thanks. I'll read more about it, since my second question is on on the used cases so far, but probably I'm little outdated when a lot of the payroll note all the examples that I could find work with 2 parties.
I remember there was some kind of implementation where it the multi-party aspect of it.
Yeah.
Yes.
No, I think currently it's mostly 2 party of framework, So currently you mostly support 2 party transactions.
but the protocol itself is not the limitation I think the protocol is extensible for multi-party channels; but since most use cases currently we are interested in or the community is interested in it you see involving only 2 parties we are going in the direction so most of
right.
yeah. And I can add also, the implementation is written in a way that the data structures are already multi-party.
but we didn't right. The protocol communication implementation. Are already for multi-party.
So kind of the data structures already are, and depending on the protocol, For example, the funding protocol or the off-chain transaction.
Protocol. We would have to extend these protocols to communicating with multiple parties, maybe integrating a broadcast functionality or something like that.
So this part is, is not there, but the core is written in a way that it is extensible.
got it? Thanks, thanks for answering that I I don't know.
I could probably hold on to this question later, but the later question that I had was in terms of, Are you guys thinking to bring the project?
To Hyper ledger information, and how many come contributors are currently having you maintain the project, and all that this aspects are so I'll hold on to that question.
The examples are 2 party examples, but the protocol itself is is not having the limitation
Yeah, okay, Maybe we'll take the other questions and then come to that later on.
Time.
Thank you, Chris. As a presentation. I wanted to know about the opening of the Channel.
Okay.
Does that require a transaction on layer, one to open the channel
Yes, it does.
Okay, and then the cost to that is that paid by Dallas and Bob from the charts
Gotcha, and one more quick one for the exchanges is that based.
There are those contracts our htlcs, or or there's some butter mechanism to return funds.
Yeah.
If if something bad happens.
so it's it's comparable in a way to httl that you have this locking mechanism.
But it's different to Hdlc that it works based on signatures.
So you can almost think of a channel in a way, as a multi sick contract.
so as soon as all the participants and create on the new Channel State, for example, transferring a token from one party to another, then the contract recognizes this as a creed as opposed to an htc which depends on this secret value that you have to reveal this has also the
the benefit that we're not limited to one transaction.
But we can do multiple updates So you can do as many updates as you like before you settle the channel where it in Htc based swaps.
So
Gotcha and the the source code. This contract is that also open source in the lab.
You can only do one
No, these are Yeah, These are based on State Channel technology
Got it.
Nice Okay, then, last thing, Not not a question. Just comment on one of the maintainers of practice for cacti.
Yes, they are!
Okay.
Sorry, and I would be definitely interested in collaborating, trying to figure out how we could work together and achieve internal probability.
Or
Yeah, thanks for the presentation. My, My my comment is more on No.
On the on on the side of the the project; that is, if it makes sense to to a fast track for per room to get into cacti instead of having perunas and other hyper ledger.
Project because of, you know also to have clarity of the ecosystem.
If if now we know that there is a hyper ledger cacti, that is a project so that contains multiple multiple techniques that offers multiple techniques to achieve entrepreneurship, or interoperability, to me, perun is another.
Okay, Yeah, that sounds interesting. Probably we could also talk after the Do you see meeting
yeah, I I could also see that I I don't have the biggest word in that, of course, but I I yeah, through the discussions, the global courtroom.
I also have the impression that cacti has, like several Protocols, included, but none of them is a State channel based so State channels could add something to cake time some additional functionality which is not there yet so.
I could see you fit there, but maybe yeah, we would also have to look at other aspects of such an integration, like How comfortable are the code bases and the architectures, and so on.
But yeah, I I I agree with the idea that it could make sense.
yeah, it would be definitely a faster truck. That's that's for sure. So you don't have to to find other organizations that you will have.
the the that the needs to be committed. Maintainers of the Peru repository, and so on and so forth.
but
Yeah. And you know, I think I think the the key here right is to have these connections.
So Peter is obviously worked with other other labs right to bring into to hyper ledger cactus to become cacti. Right?
So I think it's it's definitely a good place to start with those conversations.
See how likely it is that it makes sense, and I know Peters definitely up for that.
Okay, Yeah, probably we can have a look into it like, what are the possibilities There
so. I think it's the same like Angela mentioned you and other like, instead of having a separate project, it could be maybe clubbed with We're like like we were in practice, where it could be has some some different way of interactivity in the blockchain
I saw the thumbs up that Peter gave so definitely. Let's let's continue those conversations and see what makes sense English
right? So I have slightly contradictory statement to Angelo. And you guys are proposing right now in terms of margin, need to cat type.
so so far I have been treating cat type earlier as interrupt solution.
Then I needed that interoperability of space, but looks like Payron does have additional capabilities which would spill over beyond interrupts.
Yeah, that really sounds like a very interesting avenue for for going forward
yeah, thanks for bringing up this point. So so I think of one of the thoughts I have in mind, as I say here with the comments, is is one definitely There is a a way like a good synchrony to work with Cacti because both are
addressing in trouble, routine one way, but I think their own itself has some other directions.
For example, IoT State channels where it's it's it's not about interoperability, but about just scalability, and and so on.
So I think, having a closer look and having more discussions with the team, would provide a clear understanding of what's possible
thanks. I look forward to outcomes of those discussions.
But yeah, I'm pretty much excited, if collaboration does happen.
Yeah, okay.
Yeah, Thank you. And coming back to the question that you rise from the beginning around, I think, in terms of becoming a a main hyperlger.
Project few things, housekeeping things which might just start in the beginning like bring together different repositories and and then house skipping around the code, and something.
but in other aspects. Vc. 2 other friends, for to achieve before we can become main project, one is to see a fit with other hyperlger projects.
And how do we collaborate? And so on? And second is is to find a use case or a third contributor.
I think currently it's it's mostly Bosch and Polycry that's working on this.
yeah, So I guess the the question is, have we had projects that have come in with the lead to 2 organizations?
Have had maintainers and I'm not sure I'd have to go take a look at the original project proposals and see where they were.
I I do think that you know our incubation entry criteria, probably outlines what is suggested.
and then it's a a matter of you know.
See how well those those criteria are met. I think it.
It's really, you know, if you read that documented really kind of highlights, the the expectations of things that we've seen in the past when it when it comes to how we have approved projects into hyper ledger, so probably worth taking a look at that if you haven't
Probably if if we find a up third entity, that is also finding the technology interesting, probably it could be a more stronger project when it as a main project, maybe call your thoughts on this
already
Yeah, okay.
And I'm I'm happy to share that link directly in the in the prune chat, so that you guys have access to that and can take a look at kind of where you think you stand related to.
That I I do. I Yeah, I mean, I do find it interesting right in looking at kind of the the history right?
When we looked at that slide, that the number of kind of collaborations that you've had with other sorts of organizations or chains, or you know, there there was definitely some some sort of collaboration happening there and I'm curious as to whether or not any of those sorts of groups that you've
You're not sure that could be really helpful.
worked with, would you know, be willing or or able to also participate in contributing and maintaining the code, So that could be another sort of avenue or venue that you take a look at you know, with the the other sorts of groups that you've done collaboration with
yeah, no, just no, no to to me. So what I don't said that makes out a sense. Because if if per own, the main focus of per own is layer to and performance, that probably deserves a dedicated space in the in the in the greenhouse th that in in
that case. Yes, from the point of your layer to we don't have any anything that speaks directly to for layer 2, and even the level of a con integration with with blockchains that perun has already Yeah, that was the that would the out in my ask you would that will qualify. As a as a hyper, ledger project with that target so layer of 2,
Okay, yeah, that that that's also one possibility.
Yup Angela
and just if I didn't just look at the incubation entry considerations, it's the product should have multiple maintainers.
These maintenance need not be from different companies. However, having maintenance from different companies, is positive sign proposals, with only one maintainer, have been rejected by prior tocs.
Okay, Yeah, Thanks for your input.
so I I You know there is sort of precedence, I think, and it's just a question of you know what what it looks like.
As far as the the actual growth of the the lab. And how that's looking.
So, you know, like I would say, based on our our considerations.
Okay.
It's not an immediate, no right.
Okay, Yeah, Yeah, Thanks Thanks for the quick. Input, on that point.
Yeah, and I did. I did add the link to the prune channel, so that you guys can take a look at that in in depth.
Other questions.
Yeah.
Cool, yeah, I think, I'd like to thank the Poc for the opportunity.
It was quite a insightful discussion for us, in terms of how we, how the Poc is this project, from their point of view, and the way forward.
Yeah, any closing thoughts for the Pro: Thank you.
right. I do have one more question, so out of curiosity, just because of the integration that it's for, like the parent project has made.
But I don't know other frameworks outside of not hypothetical system.
So how? What is the interest that you've seen in other countries that you have observed in terms of adoption, or the project interest itself
maybe I can say a few words on this, so the channels were one of the early scaling technologies, and they have specific use cases where they are interesting, So especially when you want to go.
What's low latency? And I think the other communities are all interested in They are 2 solutions, and that's why they funded our project as one day a layer 2 solution.
For their for the community, for their drop, change, space, and at the moment I think we are now looking more towards applications And one interesting aspect, or one interesting application.
Was, for example, the collaboration is the ongoing collaboration with.
Are you now? Where we already did on Crown Project, regarding bringing state channels into the gaming space and enabling low latency interactions?
There! So overall, I would say First of all, we are kind of an infrastructure technology provider, which is a toolkit.
And now we are in all of these communities, going more and more into the direction.
Alright thanks, and that looks like a room, maybe has a another question or comment
Alright, any any last questions.
Alright. If there's no questions, then I would like to thank Mono with you, and and for journeying us today on the call.
I think this has been a really interesting presentation, and and discussion.
I I am curious to see how this he continued. Conversations might go with cacti, and whether or not it makes sense to to bring that into cacti, or whether it makes sense to bring us into a separate product top level project as we move forward so definitely keep us informed as you move forward
with those conversations, and and let us know how it goes.
And with, that I am going to close the call for today.
So thanks for your time and thanks for listening