Hyperledger Foundation Hyperledger Global Forum 2020, 9 Mar 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Connecting Ecosystems: Blockchain Interoperability - Hart Montgomery & Peter Somogyvari

Description

Connecting Ecosystems: Blockchain Interoperability - Hart Montgomery, Fujitsu Laboratories of America & Peter Somogyvari, Accenture

Following on last year's presentation, https://hgf18.sched.com/event/JKe4, Accenture will provide an update on their continued work around Blockchain Interoperability.

The solution defines a communication model to enable permissioned blockchain ecosystems to exchange any on-chain data or custom assets (fungible/non fungible) independent of the platform (e.g. Hyperledger Fabric, Quorum, etc.) without a middleman. This projectimplements an interoperability validator network, which is an overlay network of hand-picked actors that will validate and sign data before sharing. An “interoperability validator” overlay network is introduced for each of the interoperable blockchains. Interoperability validators are known or broadly discoverable by the ecosystem and are typically participants already taking part in the governance or consensus.

This project proposes an alternative to existing interoperability models, and it is designed specifically for permissioned blockchain networks.

An update on the project status willbe provided together with an overview on the roadmap and the planned future work. A live technical demo showcasing the protocol in action will be provided.

----
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 #HyperledgerGlobalForum2020 #Blockchain

A

Awesome alright welcome everybody. Thank you for coming today. We're going to be talking about the.

A

Blockchain integration work. Originally, this talk was supposed to be given by giuseppe and peter, but.

A

Unfortunately, due to travel restrictions, giuseppe was not able to make it, so you all are stuck with.

A

Me instead, so let's get started today we live in a world of many networks, as many probably.

A

Familiar as an example, here's the internet in some kind of artistic rendering it's hugely.

A

Complicated if you're a business oftentimes, you have to work on many networks, and this is what.

A

Say a network or a collection of networks for a business might look like today very centralized.

A

But you know just still connected, so obviously we're at a blockchain conference. So the question.

A

You have to ask: is what about blockchain well in a blockchain, it's going to be substantially.

A

More complicated decentralization has some cost and obviously what we need is going to be a lot.

A

More difficult and many of the block chains that we're going to replace these traditional networks.

A

With are going to have requirements that are substantially more difficult to guarantee than.

A

In the centralized world so as an example right, some of our block chains and membership services.

A

Might need decentralized identity support if we don't have central servers anymore. This.

A

Is something we might need? Other block chains might need great scalability. I'm sure many of.

A

You are familiar with the difficulty of scaling block chains, so we often have to give up a lot of.

A

Security or privacy properties to get good, scalability, other block chains or parts of.

A

Block chains might need extra cryptography for privacy. Some block chains might need very fast.

A

Transaction speeds or good performance. There are a lot of block chains that need legacy, compatibility.

A

And even some blockchains need auditor support, which again might be very simple or easy for a.

A

Centralized solution but more difficult for a blockchain. So what is this lead to? Well.

A

Essentially, we sort of feel that there will be no one blockchain to rule them all. We will.

A

Have to use many different block chains for many different applications and there's no platform.

A

That's going to be right for everybody, and what does this mean for us? Well, a really important.

A

Part of this wider network ecosystem is going to be communication between block chains and.

A

You can see here that I've outlined sort of these different communication protocols between these.

A

Various block chains, so this brings us what we're here to what we're here for today, so.

A

With the blockchain integration framework, we intend to define a communication model.

A

That enables permission, blockchain ecosystems, to exchange really anything any on chain data.

A

Any assets independent of the platform and without a middleman wherever possible, so we.

A

Thought about this a little bit and some of the basic core requirements we wanted are as follows:.

A

So we want a system, that's maximally, pluggable and maximally general. This will sort of minimize.

A

Future work we want to eliminate middlemen whenever possible. We don't want to have to.

A

Go through and implicitly trust intermediate block chains unless we absolutely have to. We don't want.

A

To use a token when we're building software for enterprises, we really don't want to mandate that.

A

Our clients or customers use tokens and finally, we don't want to mandate a tollbooth. We don't.

A

Want to require operators to have to make money by taking a cut for intermediate transactions, as in.

A

Many cases the incentives are aligned for people to complete interoperable transactions. So what.

A

Does the interoperability space look like today, here's you know a moderate assortment current.

A

Solutions in the space, but unfortunately none of these existing solutions, sort of satisfied.

A

The core principles we mentioned earlier that are essential for the enterprise use cases, so.

A

Fundamentally, we came to the conclusion that we needed a new way of doing interoperability, so.

A

And this is where collaboration comes in, so we had fujitsu and accenture sort of independently came.

A

To these conclusions, that a new interoperability solution was needed and we sort of both built our.

A

Own, so once we all realized that we wanted to open-source our solutions, we decided it.

A

Would be more efficient to work together than to continue on with our separate solutions, so.

A

Our current status is, we have two independently working code bases for interoperability, one from.

A

Each company they're currently open source and hyper ledger labs, and you can see them and play.

A

With them for yourself and we're in the process of merging the code together to build a best of.

A

Both worlds solutions that we think will give us all of the use cases of both code bases and.

A

You can see you know some sort of work-in-progress diagramming of what our interoperability solution.

A

Might look like so the question you might have is: what does a general interoperability platform you.

A

To look like, and how can we go about building it is it possible, and with that I will turn the.

A

Presentation over to peter hey everyone, I'm peter chiavari. I will talk about the rest of it. So first.

B

And foremost, we need white support if we want it to be successful, people need to use it and.

B

People have a lot of different requirements, so we need to try to capture a lot of those together. It.

B

Also has to be pluggable I'll return to that later and a lot of yep very applicable. We want.

B

To prevent double spending, of course, but that's kind of kind of rooms, and it's not always strictly.

B

Possible, so we just want to make sure that when it's possible then it has to be done and then the.

B

Features of the ledger's, if you have a ledger that has something unique, that most our ledger's don't.

B

Do we don't want you to lose that it has to work with the blockchain integration framework and last.

B

But not least, it has to be low-impact. We don't want to force you to have to fork the code base.

B

Of some ledger: that's out there just so that you can work with the innovation framework. There's a.

B

Complete list of these in the white paper, so I keep returning to that. I highly recommend that.

B

Everyone, if you have the time you look at the white paper, we will provide links for that. So.

B

One of our core components is the interoperability validator. It's basically a server-side application.

B

That sits at the deployment of your ledger and the software stack that you chose to operated with and.

B

It provides you with high availability from an overlay network. Currently it has leader elections.

B

Built in but we're planning on, removing that the network services that a validator will give you.

B

A high-level is basically to handle your export requests and explore requesters. When you want you.

B

Have a piece of data on one ledger and you want to move it to another ledger. Also, the big feature.

B

There is to be able to verify the states of one ledger on the other one, and we achieve this by.

B

Managing the trusted form validators, essentially just putting or dispersing keys of the validators.

B

On the letters within small contracts, some technical information that you should be.

B

Aware of our code is in javascript, but through the plug-in architecture we plan on supporting.

B

Different languages as well, there's uh there's some great patterns out there warm that we've.

B

Seen is how the go plugin project implements it. They can you pass in a command-line argument that.

B

Starts a binary, the binary ends up listening for gr, cp requests and your actual core software. That.

B

Interacts with the plugin it communicates with that other binary food that g or pc and then in.

B

This structure, it doesn't really matter what you use to implement your plugin. It could have been.

B

Any language that add support for that api- this is one of our example use cases. There's many of.

B

Them in the white paper, you should don't read it, I'm not going to go into too much detail here, I'll.

B

Just highlight the beginning of the sequence, which is proposing the transaction. That's where you get.

B

To specify the constraints of the transaction, and then how do you want it to be handled? Should.

B

There be an escrow. If you are transacting with a permissionless ledger, then maybe you want to.

B

Put a limit in there for a number of blocks that you want confirmed before the transaction can be.

B

Finalized on your end, and also, it demonstrates greatly that path, the blockchain integration.

B

Framework is a common api layer in front of other ledger's. In this example, fabric invasive.

B

So the architecture wise, what you need to implement yourself is you have to either.

B

Connect to somebody else's ledger or run your own. That's entirely up to you. You need that.

B

Ledger's sdk and then on top of that is the abstraction layer. That's us the blockchain.

B

Integration framework which you can use for the validation services and the data export.

B

And I will show a really quick, really simple demo: that's just with a rudimentary made-up asset being.

B

Transferred from one layer to the other, I will demonstrate that signatures can be verified in.

B

Cryptographic manners so that you actually have proof that the data that you transferred from.

B

One letter to the other is, as it was intended to be, and it will be a live demo running from.

B

A box from my living room, so if it did crash, I apologize. I also the video will fail. So what you.

B

See on the left side, you know it's dlt, one! That's! Oh apologies. What happened there? Yes,.

B

So what you see on the left side and pink or magenta color its tlt 1? It's a bunch of.

B

Containers running fabric and v validator notes and an api server that has some endpoints for.

B

The actions that I will be presenting here, the other side, it's pretty much the same blueprint.

B

But that's quorum, so you have two sets of validators in this imaginary scenario, with.

B

Two separate organizations running their own ledger's and their own deployments. That can.

B

Communicate with each other and data can be exchanged between two different ledger's, so.

B

The way it goes, you can create an asset which calls the api, which then calls spiff, which calls.

B

The smart contract deployed on fabric and works. It does there's just a json representation of.

B

Some dummy data, it's it's an asset, it kind of represents some sort of token, but it's not a.

B

Real token and what you can do, you can modify the data, for example, if you want it log so that you.

B

Have proof that, on the left side of the ledger, this data will be sort of discontinued? You can.

B

Issue a lock request: you can set additional parameters if you like, at soul, just json, you.

B

Can uh you know you could put in there who is going to receive this, and at this point the data.

B

Exists on fabric, so you can ask our validators to provide signatures for that particular piece.

B

Of data identified by the asset id, which is uh that's a primary key in database terms,.

B

So when you hit that endpoint, the validators perform a broadcast on our overlay network, so.

B

That every validator is up and running will produce the signatures. Then, in our imaginary.

B

Business application. You know at this point: you want to send over the data and you can.

B

Choose to send it with the correct or the wrong signatures. I will choose correct, but if some of.

B

The containers have died, then this may not work at this point. You can verify the signatures on.

B

The other side, which means the foreign key validator public keys that we have in these.

B

Biff validators will be used and those are the public keys of developers from the left side.

B

Yes, so it's an array of four boolean values from four val layers. It's all true, which means are all.

B

Good at this point, you cannot just say: okay, I'm going to copy the asset. At this point, we.

B

Have the same piece of data present on the quorum ledger and you can actually query the state of the.

B

Ledger through the blocks integration framework- yes, it actually works. I'm really fascinated by.

B

That that was the demo. Yes, so under the hood on the chain, we have the public keys of the.

B

Validators, that's how we establish the trust and that's how the signature verification can.

B

Work off train, you know in the rest, api layer, that's where the requests are happening for.

B

Exporting the data and requesting verification of said data, so now the demo done I'll get over.

B

To you, the plug-in architecture, which is a really really big fundamental part of what we're trying.

B

Doing because nobody knows the future, even if you have you know, cool classes like that which.

B

I'm sure will happen in the future. Nobody knows it for sure. So we can. All we can do is try to.

B

Remain flexible not produce, see many opinions and impose those opinions on our users on how.

B

Interoperability should be done, and for that we are trying to plug in. If I, as many aspects.

B

Of the whole process as possible so that future technologies as they come along, we can always.

B

Just say I'll just write a plug-in for supporting that latest saw thing and the plugins are looking.

B

At one time again, for flexibility and because jobs could allow that and what I really want to.

B

Emphasize here is the community aspect: you're really community at first in our ideas, so the.

B

Concept is that if you need something supported, you can write a plug-in. You don't have to even.

B

Ever talk to us, I mean, if you're really nice guys, but if you don't want to you, don't have to you, can.

B

Just sit home, write the plug-in, put it on github or not and use it with your deployment. And if you.

B

Ask yeah at any point in time about any feature, other ledger or algorithm protocol. If we could.

B

Support that the answer is most likely will be yes, we can, and this little chart is what will.

B

Actually go through our heads if a plugin already exists, for it, we'll just say, use that plug-in and.

B

If it doesn't exist, but it is in the realm of one of the plugin defied aspects, then we'll say.

B

All implement the plugin and then you can use it and there's the edge case where it is an aspect.

B

Of the code where we haven't thought of making it dynamic and pluggable, in which case we will.

B

Be happy to take a look at ideas that you have on how to make that pluggable, which should then.

B

Result in a pull request and then every to accept that pull request. Then you can just.

B

Go about implementing the plugin and using the plugin, so you always end up with using.

B

The plugin as an example I'll just highlight the storage plugins. It's really there so that if you.

B

Deploy it if you're not tied to your particular database for operating biff itself, you can be.

B

Agnostic of that, the interface for the storage plug-in is own intention very simple. It may.

B

Get a little more complicated in the future. If we have to you absolutely add extra things, but.

B

This is just an example here, I'm demonstrating that it's simple to implement so that anyone.

B

Who works with databases can look at this and say well. I can definitely implement that api.

B

Interface on top or 99% of the databases that you ever heard of and what I need to emphasize.

B

There, in terms of storage, we don't need the storage, because we're running our own ledger.

B

With tokens, as hart already highlighted, it's about storing metadata administrative.

B

Details related to your transactions, so basically to just keep the lights on.

B

Preserving literature features very important, but it also can be a can of worms if you use.

B

Two ledger's in your interactions and they both have privacy, which is a great example.

B

Then you should have the reasonable expectation that connecting them through biff they'll also.

B

Preserve the privacy, but I have to say they're, always consult the security experts just like.

B

I I heard a stole from the earth, sir guys they kept hammering that point home, that if it just.

B

Because you use a tool that was labeled as secure, it doesn't mean that the way you use it as secure.

B

So that has to be said there, then our main focus really is to not have unexpected behavior and that.

B

Works with the transaction protocol, where you propose up front the things the assumptions and.

B

The constraints that you want to have, for example, if you need escrow or if you want to have 10 or.

B

20 blocks confirmed on the bitcoin main net for the transaction to be considered final and then.

B

Execute a transaction if both parties said okay, I can work with this. That's all. I think I pretty.

B

Much talked about this, we won't tell always surprises. We don't want anybody coming back to.

B

Us and saying, oh, I paid someone and I did not know that bitcoin could fork and it did and I lost that.

B

Thing I had that would be unfortunate. We expect the transaction protocols have different versions.

B

Over time as it matures and it's important to defend against downgrade attacks, one way.

B

Of doing that is to just not allow downgrading the protocol versions at all. But that's something that.

B

We are still working on the bottom line. Is we want to avoid situations where extra additional.

B

Vulnerabilities are presented in the codebase because you can actually downgrade. We want to.

B

Make sure that we support batch transactions are applicable. Anybody who work with database.

B

Software in the open-source community will tell you that, as one of those features that.

B

Gets requested five minutes after you upload your code to github. If it's not there performance and.

B

Scalability we focus on not being the bottleneck because they're not our own ledger. We should have.

B

A reasonable expectation of not being a slower part of the system since they don't have to deal.

B

With persistence as much as the actual ledger's, we want to have published benchmarks eventually, but.

B

It's not there yet, and I should mention horizontal scalability. It's a big goal of ours, which is why I.

B

Mentioned earlier that we're looking to eliminate the leadership elections, so our position in the.

B

Green house, currently we are a hyper ledger lab, but if we do graduate or when depends on who you.

B

Ask then we could be put in the libraries or the tools it really depends on? Who you ask from is.

B

It the person who deploys bip for them it's a tool if you're an ops person, but if you are in.

B

An enterprise writing a blockchain business application, then, as far as you are concerned,.

B

If it's just a library that you use to abstract away some mundane details of the cryptographic.

B

Algorithms, behind signature, verification and things like that, we do have a road map, but it is.

B

Subject to change current leave you're working on finalizing the 1.0 technical design. I will again.

C

Emphasize everybody's welcome to provide feedback. We would really love that, because now is the time.

B

Then you can have a huge impact on how and what gets plugged in. If I what's configurable later on.

B

It's going to be much harder to change the core we kind of want to treat the core as similar to the.

B

Linux kernel, you know, if you try to submit a pull request there or some kind of patch you will have.

B

A hard time getting it approved no matter what just because there's a lot of scrutiny around.

B

It it's a non exhaustive list of our two do's and ideas. We want to support different identity.

B

Providers we may migrate the typescript we may unify the api server and the validator and to just.

B

One actual piece of software and we definitely want to have a reference architecture. That's.

B

Actually deployed out there and is usable the first stab at that is my actual demo environment.

B

But it will get better again: the plug for the white paper. It's an early draft, but there's a link.

B

There there's qr code, please comment on it: we've all come old feedback and the more feedback it.

B

Gets the more eyes that get it's a good insurance against us, just not realizing something basic or.

B

Crucial, we have an oasis community, it's not huge, but it's getting there. We have the bi-weekly.

B

Unique visitors are in the triple digits and, of course, you're here, presenting they're, hoping that.

B

This will improve over time and we are actually going to propose and as a high pressure project.

B

And you can look at our proposal document in which we put together recently under that link. There's.

B

More links, qr codes, come to a rocket chat, just message on the channel. There's a channel with link.

B

Or message us directly, it doesn't matter, you don't have to ask to ask just blurt it out whatever you.

B

Have to say on topic, same links, just know the qr codes and does anybody have any questions yeah.

B

Yes, make is asking if we could go back to the track. Section flow slide.

D

D

D

So the asco should be configured in a way that at times out, so if yes.

B

For this particular use case, yes,.

C

He came into the how to solve the problem maker. Other, like you mentioned it escrow to.

C

Work all sectors should be returned back to the original owner or some sort of such a hundred.

B

E

Okay question is: do we assume that the validators can be malicious or misbehaving, so trust with.

B

The validators is implied. There's consortium management features that we're also running.

B

Ideas about, but for now the idea is that you as an organization, you trust your own.

B

Validators because they are on your network and you administer and operate them yeah.

A

And it's relatively straightforward to configure validators right so like a traditional blockchain.

A

You have to trust some super majority, but you don't necessarily have to trust all of them.

E

Their way to make it.

E

But we don't really. I didn't see that.

E

Whatever the network also wondered.

B

Okay, as well start with ya sorry for.

A

Sure if you wanna answer.

A

Let me try to answer, there's so many questions, so they anyway they summarized. It would be first.

C

Of all that we need to share about the idea of the this. The interoperability is not covering.

C

To the whole network, so the its read say that is kind. The independent, the contract between other.

C

Involving multiple edges, so the data does not have to be consistent with one context to the.

C

Others, but the frame we need to inter work for the two edges that has to be consciously, including to.

C

Their exceptional cases, so the the trust folders such an intermediate would be some sort of the.

C

Trust point to achieve or to execute to their other much per transaction or maybe so to his.

C

Kinda series of the transactions, so I hope you to answering to your questions, so I can probably.

A

Answer your cryptography questions, so we don't have to use exactly the same cryptography as long.

A

As we know each other's protocols, so if you want to use like you know, pick your favorite elliptic.

A

Curve, if you want to use your favorite elliptic say you want to do a pls signature. You know you.

A

Can do that as long as I know, you know, as long as I know your protocol and I can verify it and.

A

I can trust it. That's fine. Maybe I want to use one of these fancy new post quantum signatures.

A

Like falcon, you know, I could use that and if you know the protocol and you can check.

A

It then that that's totally fine, so we have to know each other sort of crypto if we want to.

A

To be able to interoperate right and if you're, using a crypto algorithm that I don't consider.

A

Secure, I might refuse to to interoperate with you right, but in theory this shouldn't be a problem.

B

And what I could add to the first question regarding metadata and transaction traceability.

B

I'm not sure the font size is good enough or big enough, but there is an origin object in there. That.

B

Shows what was the origin dlt and what was the original asset id and those are all just arbitrary.

B

Properties, we add it to our acid definition to demonstrate exactly the traceability, but.

B

The idea is that you can define your own assets and conduct that. However, you wish to, if you have.

B

Existing tracing systems, something like zipkin or jaeger, with elastic search, um you know you.

B

Can always put a uuid in there or a trace id sorry from the open tracing specifications to follow up.

A

On that most of our use cases don't involve moving assets between block chains. They involve sort of.

A

Swapping an asset on blockchain a for an asset on blockchain b. So this you know this is our most.

A

Common use case, but well you've. Certainly you know what you've proposed is certainly viable and if.

A

You wanted to add, you know metadata or something to an asset. You know to an asset class. You could.

A

Certainly, do that you just have to you know, be a little bit careful about how you define the asset.

E

Right exactly and you you're exactly right, and this is why we've mostly tried to focus.

A

On solutions where the assets don't change chains, because, as you correctly point out,.

A

It is a big problem if you have, if you don't know where something is.

B

Any more questions, well, I think we're out of time. Oh so kenneth or it will be outside and happy to.

A

Answer questions if you're still interested or have more questions, yep thanks for your time. Thank.