Hyperledger Foundation Meetups, 24 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Blockchain Techfest 2020 - Part 3

Description

A virtual meetup hosted by the Hyperledger India Chapter. This video includes discussion about:

1. Hyperledger Fabric Production Deployment: Blockchain Automation Framework by Priyanka Vats & Sownak Roy

2. An introduction to Hyperledger Aries - For users, and developers
by Ankita Patidar & Ayanworks Team

3. Hyperledger Cactus by Peter, Jonathan

More about the event is at: https://www.meetup.com/Hyperledger-Bangalore/events/274625911/

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

A

Yep, julian, okay, all right welcome everyone back to the to the tech fest um this. This is this special event. That's been organized by the indian chapter, uh along with uh uh the meetups from around asia, pacific and uh the african chapter. So uh this is the third, uh so welcome back. We have a great uh schedule today. uh We have, uh as this event is all about it's about meeting the maintainers and contributors uh from uh from the hyperledger projects. uh We have uh people from cactus labs.

A

We have baf, which uh I think we're gonna have a demo today on which uh we went through last uh last session and we have uh ares so uh please and the messaging. I think the message that we want to give is that please listen to these maintainers contributors and everyone wants more people to get involved. So I think that everyone wants more people involved in this project. It's all about us working together and developing this technology together.

A

So with that, I'm going to hand you over to the person who's arranged and organized this- I run around please uh take over from here. Thank you.

B

Thank you julian for the great introduction and today's session. We will have three different topics which we'll cover and upon request by the audience. In the last session, we are going to have a demonstration on the blockchain automation framework and our first event for the day would be um on hyperledger characters and thanks to peter and jonathan who are joining us from far far away place, and I know it's too late for you guys, and we really appreciate you take making out time for this session over to you. Peter.

C

Album uh I'll just ask for the forgiveness of everyone in case I uh talk a little slower than usual and let me share my.

C

C

Can you see the slide.

A

C

My name peter I work for accenture's technology architect and uh regarding the project hyperledger cactus. I just wanted to start with a safe, harbor sort of thing where I just stated very clearly that the project is an incubation status, so we don't have a 1.0 fixed, stable release.

C

Yet so it is not ready for production, so everything I say about the future is uh sort of a forward-looking statement and with that out of the way uh what is cactus, it is in very short and sdkf case for developing applications that have to use distributed ledgers, and uh we really hope that it is a plugable sort of framework that also will be enterprise grade, in the sense that uh you can count on it being uh available and uh stable and maintained for years to come and also backwards compatible where possible, not everywhere.

C

C

And then to answer the question: why it's to mainly to address fragmentation blockchain is very popular nowadays, it's the adoption is happening and there's a lot of different proposals out there for how to actually build a ledger, and it makes it very difficult as a as a business application user.

C

It makes it difficult to figure out what it is that you can put in your architectures and what it isn't.

C

uh If you want future proofing, then you really need to somehow have a way out in case the technology that you picked actually ends up, not being so great on the long run or just gets discontinued.

C

So that's one thing and uh the other one is just the obvious one for every framework. That's out there in software is to try to save people from having to reinvent the will, and then the third one which I kind of described, is to lower the risk of adoption.

C

And then, if you want to think about how bad the fragmentation is, it's actually much worse than you would imagine at first, because the number of integrations, if you want to be um less optimistic or if you want to have high standards and say that in your ideal world, every ledger or different blockchain should be able to talk to every other blockchain.

C

Then the number of integrations between these uh different blockchains goes up quadratically with the number of ledgers that are there, meaning that if you just have a hundred different lectures, which we have thousands right now, but if you just have a hundred, then uh you end up requiring five thousand different integration scenarios.

C

So that's not really sustainable, especially if you take into account that there isn't really a framework out there to combine all of these. So if you want any sort of larger scale, enterprise application today, then this is uh this is your reality.

C

Basically, so we intend to make that easier and then uh just to clarify our position in the hot pleasure greenhouse. We are right there.

C

We are in the tools category, but technically I can make arguments for us being in almost any one of those boxes, except for the distributed.

C

We are definitely not a letter, but I could say that it is library because it really depends on how you're using it. What is your persona within the organization that uses cactus, because if you are an application developer, then for you it's more of a library.

C

But if you are a person who's uh in operations, then you could think of cactus as a tool for uh integrating ledgers. Basically,.

C

And here's a very, very generic use case. This is intentionally overly simplified just to demonstrate that you're not a ledger. We are something that gets put between ledgers and a user application so that the user application gets to deliver value and uh and that's it so I I will expand on this much more later, especially if I have time.

C

But this is the very high level scenario and then a few quick design principles.

C

The most important one is the plug-in architecture, which is all about us trying to remain flexible because we don't claim to know what is the optimal design.

C

I don't I personally, I don't think anyone knows for sure it's uh it's much easier to decide or judge these things after the fact, and so our strategy is to try to keep the design flexible in a way that if next year or two years from now down the line, we start to see sort of emerging patterns that been out sort of, then we can adapt to it.

C

Even if initially we did not think to do that particular design and then uh second most important. Well, I guess I could say it is also the most important is secure by default, so we really don't want uh minor things to just take.

C

It spiral out of control with security, so this is an important uh design principle, even if it seems trivial, but we want to clarify that we don't have uh the insecure defaults, such as you know, when you deploy a software and then it boots up, and then it has admin for the username and admin for the password for the complete rights and then uh toll free, which is a little clarification.

C

So cactus is open source that is being developed in the open and also, if you deploy it, then uh by default there's no any sort of payment mechanism in it. That would make you have to either collect or pay any sort of fees.

C

uh It's it's! It's basically up to you. If you want to implement something where payment is required, then you can do so, but it is nothing like that is baked into the framework and then uh low impact deployment which I kind of already described. But I want to reiterate that we are separate from the ledgers.

C

So in this sense, the ideal scenario is that you already have letters that you want to integrate, and then you can deploy cactus to do just that without actually having.

D

C

Modify the letters themselves.

C

And some more design principles that I will also cover in a greater detail by support, meaning that we don't just want to support like the top 10 of the ledgers. We want to make sure that we actually cover at least 99 of them, and the way we try to achieve this is to assume very little about the ledgers themselves.

C

Basically, the mostly assume sigma body ledger is that it is a data store that can represent transactions and maybe blocks, and it is able to run uh some sort of arbitrary code in the form of smart contracts and then for cross ledger transactions. We made sort of the pledge for ourselves that there is possible. We want to prevent double spending, but this is not always applicable, because we can only do this on ledgers that have guarantees for transaction finality. Otherwise things can go always somehow wrong and then uh preserving ledger features very quickly.

C

It just means that, if your ledger has some sort of additional feature that distinguishes it from other ledgers that features your pride and joy, then uh the idea is that you should be able to integrate that ledger with other ledgers through cactus and still have that feature working in the way that you wanted to, so that adopting cactus for integrating your ledgers is not a trade-off in the sense that now you have to basically lose everything. That's unique about your ledger. Your particular ledger, horizontal scalability, very important.

C

We need this because uh it is derived from our performance goal which states that we never want to be. The bottleneck, however fast the ledgers we are connecting or we want to be able to handle the transaction load that those ledgers can handle and then a quick plug for our white paper, which is up on github. If you, if you want to read more, then there's a big list of use cases there and also the rest of the design principles which I won't continue mentioning because I otherwise run out of time.

C

And then getting a little closer to the fire, this is the architecture on a high level. It's uh it's not the most up-to-date diagram, but it still works. It's a pretty. It makes it pretty easy to explain.

C

The bottom line is that you have the ledgers which can be any supported, ledger and then there's ledger plugins, which are aimed solely at establishing communication with these ledgers, and then you have a business logic, plugin or even an external application that implements your business logic, and this ends up talking to the ledger. Plugins and the idea here is that you only need to you or the open source community. You only need to write each ledger plugin once and then that ledger becomes supported and anyone else can use it.

C

So you can have two ledgers that you want to integrate or 10. as long as there's plugins written for it. You can just do.

C

So, and uh going even closer to the implementation details, a few architectural decisions we made is to have the code written in typescript bundle with backpacks, so that the relevant packages that we have that makes sense. They can actually be used not just uh on the back end in an ogs environment, but also in the browser, and then all this is grouped into multiple packages in the same main, github cactus repository, and all of that is managed through this tool called learner and- and we just refer to that as the mono repo.

C

And yes, as I mentioned, we have cross platform packages so, for example, the api client package that we have that you can use to conveniently issue requests to the cactus api, so that works the same way on node.js and in the browser as well, and then the other big decision, or maybe it's just my personal pet peeve. The same thing is uh test automation. They focus very, very heavily on test automation, even the things that are normally not testable in the average software framework.

C

We have all that covered a big and important part of that is. We actually write our own custom, docker images so that we can simulate a completely fresh, clean slate ledger for each test case if necessary, and then more on. The plugin architecture is basically it's all about us admitting to ourselves that we don't know what the future looks like.

C

So we just want to make sure that there is always a possibility to adapt the software by just saying, oh well, we just need to write a new plugin that implements this in a slightly different way, but it still fits into the system because there are well-defined interfaces between the plugins, the core software itself.

C

Regarding the governance model, the important thing about plugins is that if you want to start developing a plugin today or any lecture that is not supported right now, you can do so and you don't even have to ever ask any one of the taxes maintainers.

C

In fact, if you, if you want to, for whatever reason you can even keep that code of your plugin private, because at the end of the day, cactus allows you to inject that plug-in at configuration time and then just use it.

C

So there's no real difference between the cactus plugins written by the maintainers, such as myself or a plugin written by someone else who just uploaded it on.

C

Npm- and this is definitely a forward-looking statement- big time- uh we hope to have language and nasty plugin development as well, so that, if you don't like typescript or javascript or even dojs or any of that, then uh ideally you could just implement the plugin in your preferred language, which could be o c sharp or rust, or anything else that can communicate uh through the network and uh we've seen a good idea elsewhere, where this was implemented with go plugins, which just ends up being a grpc endpoint that your plugin talks to and then the core piece of your software is able to communicate with the plugin that way, and then it really doesn't matter uh what language your plugin is written in.

C

It doesn't even matter what server it runs in as long as there's a network connectivity, but this is not something that we even aim to support in the 1.0 version. So this is uh definitely just a long-term goal.

C

And so this little chart demonstrates my personal thought process. If anyone asks me what about supporting this ledger or that kind of key management or authentication, all of these uh should be indian plugins. And then, if you ask me what about supporting something along these lines, then uh first I will say: is there a plugin and if yes, then just use it, but if, if there isn't, then uh then I will evaluate what you're asking.

C

Is that already a plugable aspect and by pluggable aspect I mean, for example, a plugable aspect is keychains and ledger connectors so meaning you can add the ledger, connector plugins for different letters and you can add keychain plugins for different keychain implementations, where the private keys or other secrets that you need for your business application can be stored.

C

So if you want to add a new keychain backend, because maybe we support one of the big cloud providers, key management service, but not the other cloud provider which you happen to use, then my answer will be okay. So you can just implement a plugin to support that and then use that plugin and then the only edge case is if it's not a plugable aspect.

C

For example, if you, if you want to customize something that currently is just hard coded in the in the core, then it will have to have an extra step for you to be able to customize or support that behavior by first sending a pull request directly to cactus, which uh the pr would just make it so that that aspect is pluggable and once that's done, then you can implement the plugin and use it to customize. The behavior.

C

And after all this talk about plugins, I just wanted to hold the waters and uh just lower the expectations. A plug-in is super simple. This is, for example, one of the plugins that we have in the code.

C

It's uh you know. It takes five seconds to read that code, I'm not going to read it all out loud. It's just an interface with a few methods that you can implement in your code and then you can feed that into cactus as a configuration parameter and it will be used.

C

And a little more storage- it's uh just something I like to clarify is that.

C

Well I call it. I find it that I like to clarify multiple times is that we are not storing a transaction of blocked data as part of access. We don't intend to come out with a new consensus algorithm on that either then I say: storage for cactus, I just mean storing operational data or pending transactions, things that you need to implement your business logic, but not uh the actual data that you end up. Putting on the.

C

Ledgers and then I'll talk a little more about preserving the ledger features.

C

The other thing that I always try to make sure we clarify is that we can only do this as much as possible, but there's always a limit and uh a big one is, for example, privacy. If you have two letters and one of them supports private transactions, but another one does not, then most likely you cannot. You can no longer have a reasonable expectation of your transaction being private, since only one side guarantees it. The other side says: well: your transactions are public, not private.

C

So despite the fact that, in this scenario, cactus would support the feature itself mechanically so that you can specify your transaction as private on the ledger, which does support product transactions in the end, this ends up not being very useful for you, if the other side, if the other ledger that you're transacting on it's just not supporting private transactions- and I just wanted to make this uh clear, because we cannot make miracles happen in this sense, so the expectations have to be clear in this regard.

C

And for transaction protocol itself, as in how do you execute a cross? Ledger transaction? Well, it's a it's! A moving target sort of the science is still being worked out on this. There's multiple different algorithms and ways to do it.

C

uh So we're not settled or anything on this ship and the design is very much a draft. But uh basically the flow is that we don't want any unintended consequences.

C

So both sides have to agree to the transaction before it gets finalized, and I know this is kind of weight, but this is where we are at with the fundamentals for this particular piece.

C

And uh yeah it's just re, I did. I just want to reiterate again that uh there could be surprises if, if you expect too much from cactus and for example, you forget that on bitcoin, it is possible that the letter just works, which is not under your control or our control or anybody else's control.

C

So basically, with the transaction protocol, we try to mitigate this kind of mistake as much as possible so that we don't end up with a large number of users who end up losing funds or somehow messing up transactions.

C

Otherwise, and then uh we also intend to have batch transactions, but only they're applicable and uh that's uh probably not the most widespread use case, but I do see it uh being necessary for enterprise applications, because I just I've worked a lot on different database projects. Their databases were not ledgers, they were just relational or mixed with no sql databases and batching transactions is always something we end up needing.

C

And then, regarding the performance, I probably also already mentioned this.

C

What we want here is to make sure that access is never the bottleneck, and we want to have published benchmarks that actually show that we ran a test where multiple ledgers were involved. Everyone running transactions right and the throughput of the letters were x and the throughput of cactus was basically the sum of all the throughputs of the different ledgers combined, since it is the component in the middle and then uh now a little deeper about one of the use cases.

C

It's a federated validation.

C

What we do is basically provide an overlay network that is, uh stop poland, where you can obtain an attestation or a signature.

C

We are also not settled on terminology yet, but the point is that you can get a signature, not just from a ledger that the transaction happened, but also from cactus itself, which can be good if the entity running cactus is more trusted by you than, let's say the letter, or if you have a specific relationship with that entity that runs that cactus node.

C

And then the way this would work is that you deploy axis and then you can manage the validators that are on practice logically within cactus, and then you can ask cactus itself to verify the payloads of transactions as they have happened on the letter.

C

And this is the about stack in an actual deployment. The way we imagine it in this use case, and you can see that on the bottom of the stack, we have the lectures, the eosp platforms.

C

There are smart contracts deployed on these that can manage sort of the identities or at least the public keys of the foreign validators, and then there's the sdks or the apis of the letters on top of the ledgers themselves and then cactus talks to those to make sure that the data that moves around is indeed validated.

C

So, in the end, what you have to write code is mostly just sits on top, but depending on the use case, you may also need to write smart contracts for a specific ledger.

C

And then what actually happens on chain in this use case is a smart contract validated in public keys or building the signatures uh based on the public keys. And then what can happen off chain? Is your application can sit off chain as in put outside of the letters and send requests to the cactus api to either have a transaction payload verified with a signature of that cactus node or actually to export data from one ledger and maybe put it on another ledger depending on what is the use case?

C

So, in the end, you can move data around and you can obtain cryptographic proof that the data has been moved around.

C

And then uh the road map, which is a very, very much subjective change, we intend to finalize the 1.0 design and a new development.

C

The recent development regarding this is that in january we have a meeting scheduled with the iphone lecture technical steering committee to actually start talking about gathering feedback about the architecture, and we intend to specifically target maintainers of the ledgers that we are intending and supporting in the initial round, and we hope to what we hope to get out of this is people saying things along the lines of hey cactus is great, but I think this particular use case would just never work because of some little shortcoming or an issue with your design, and then we would take that feedback and we go back to the drawing board and then, uh basically just do it again make sure that what we have is flexible enough to handle what was brought up going into a little more detail on the roadmap.

C

We want to have support for uh identity management. We are looking into supporting. Indy did dif all these goodies. We already have some support for json web signatures. It's just uh the slide. Hasn't been updated and then uh consortium management, we also have that and we do not yet have plugins in different languages.

C

So basically, this is the roadmap. For now and uh oh yes, we also intend to have the performance benchmarks published.

C

And then this is the presentation in the end, there's just a shameless plug, where I invite everyone to come. Hang out at the rocket chat or the mailing list, which you can find the link to from the wiki, which is the bottom link and, of course, to contribute, which you can do so through the link to our github.

C

And uh I'm not sure if I should answer questions now or at the end.

B

Thanks victor, I guess we could we should be connected. We should take up questions now. There is a question on q, a portal, some acting asking that since plugin development is externally managed, how do you ensure that cactus will provide a uniform interface for all the underlying layers.

C

So we do that by having the plug-in interfaces defined by the maintainers, so you can develop your plugin anywhere, but the plugin will only work with cactus if you implemented the specific interface definition that we published.

B

Awesome starting attendees: if you have more questions, then please feel free to ask them on the q, a portal and thanks peter for the for the excellent session, and we hope to get more contributors from this region and joining the project soon, and the recorded session will be placed on hyperledger's youtube channel and we'll send out those videos information as well very soon and up next. We have our second session, the most anticipated one.

B

I believe we heard many people asking for this session last in our last session, where um they wanted to see a live demo of hyperledger fabric being deployed through blockchain automation, framework and now I'll hand it over to accenture team or to you uh sauna, and the team.

A

Hey, thank you. uh I think it's not my uh what's. The spotlight today is priyanka and uh arnold and.

A

E

Yes, I'm sharing my screen thanks aaron um thanks peter okay. So thanks for the overwhelming q a last time, um what we are gonna do today is just do a quick recap, for uh you know folks who did not join us last time uh so just to have a starting point and then I will straight away hand it over to the engineering team, the maintainers of uh blockchain automation, framework uh shivaji, then arnold have joined and uh shanak is our main architect and product owner.

E

So if there's anything that the team cannot handle, then we have shown up okay. So with that. um So this is the agenda. um Let me um take you to what are we doing a recap for so last time we just mentioned. You know a lot of you. Don't know what hyperledger labs is, so I would uh request you to go and just have a look for it.

E

So it's it's like an incubation center within hyperledger greenhouse, um where the projects that are not really going into a full-fledged project status can start, the development can start and the team can start developing in the open source. So bath is right now a project in incubation under hyperledger labs.

E

The second thing that we discussed was uh you know. What problem are we solving? What is blockchain automation framework um and what we discussed in detail is that what we were facing uh internally in accenture, where we were doing almost 100 pocs, but we didn't have a consistent way to bring up a network to make it secure uh how to store the keys, and uh you know we used to spend a lot of time doing all this. So why not have an automation framework which actually does it automatically, while keeping the architecture consistent and secure?

E

We then discussed on um what are the components that we used. um You know and then we went shauna took us through the code structure, how our code is placed in the repository um and and also through the network, uh dot yaml, which is our main configuration file. It's a single file that this automation framework consumes and spins up the network uh in in bath components. If I can just quickly summarize that the comp we have one thing that is mandatory is kubernetes.

E

uh We we work extensively on clusters. We have ansible health charts, uh hashicorp vault, um any given cloud infrastructure and uh gitops flux, so these are the components used for the complete framework.

E

So with that um without further ado, I would um hand it over to uh shivajit. Today, uh shivajit will take us through a little bit a little uh deeper in in how the network is deployed, and then arnold will take us through uh the the features. So what do you shoot? It.

D

Thanks priyanka and uh yeah welcome everyone to the session uh before we actually move to the technical demo. uh I'd like to kind of bring your attention to this slide. So this one talks about how the automation for uh fabric dlt is done using blockchain automation framework.

D

I mean people who had joined the previous station must have seen this uh slide for other dlt uh as well. So as bro baff promises that uh all the dlt platforms that uh automates it does it in a consistent way. So the kind of automation flow remains the same uh with changes uh for dlt specifics.

D

So uh what you see on the screen is the uh some of the main pieces of uh baf automation uh and the automation uh basically starts with a developer or an operator uh config configuring or creating a config main configuration file or the single configuration file, uh which we call as a network yaml, so that configuration file is then used by the ansible uh which contains uh playbooks rules uh and um tasks. So these uh the mean the network camel is basically uh the network.

D

Configuration is used uh to kind of create further configurations which are later used by helm, so I'll talk about that uh quickly now, so uh one sensible creates this configurations and what helm contains is that it contains charts uh the basically the helm, charts which uh contains uh various jobs or deployments or these services, which, which kind of uses the configurations uh provided by the ansible as values.

D

So we call them value files as well, so these uh charts uses that value files and passes it as an instruction to kubernetes and then kubernetes uh does the deployment of whether it's a deployment or a job or any service which is required.

D

uh What you also see on the screen is uh the docker, uh so docker is basically it can be a private or a public repository. In our case, uh it's a public repository under hyper ledger labs. It contains all the official uh fabric images provided by fabric, so those images are basically used by either uh the containers uh in the kubernetes or it is used by ansible to create cryptos or yeah different artifacts required for the uh network deployment.

D

uh With this understanding of the automation flow I'll move to the next one.

D

So uh what we have as a technical demo- and uh first we will just talk about the baseline of the technical demo and uh what we already have is a baf deployed hyperledger fabric network. So uh it's a fabric network with 2.2 version. So just one important note is that this is the first time we are kind of demoing. The fabric version 2.2 uh by the end of the session.

D

I'll also provide you with a link of fabric network deployment, of an o of the older version 1.4, uh but in for this part of technical demo, this is a baseline that we already have an existing network deployed uh with fabric version 2.2 now uh just to kind of talk about uh the uh architecture of the um network.

D

Basically, how the network has been uh I mean created is that uh we I mean the nomenclature and basically the architecture is based on a use case that we uh use the use cases about the supply chain, uh logistic application, so we all do also have a ref app, which you can find in our root directory under examples, folder of our root directory in github.

D

So under that we have the uh ref app for a supply chain. So uh I mean just briefly on the use case: the use cases about the logistics supply chain where containers and products created by the manufacturer are shipped to different parties.

D

uh So here in our use case or the network, the supply chain organization hosts the orders. It does not have any peers or and just host the orders. The other participating organizations are manufactured with a single peer, single peer and organization, also with a single pair, all communicating on a single channel.

D

So uh with this uh I'll move to the operational features which we are going to demo today, so I mean uh expanding on the uh use case. uh What we want to do is that we want to add a new organization, a store organization to the existing channel, so uh I mean uh also we'll remove that particular organization.

D

So what we're going to show is that uh I mean the whole complex process of adding and removal uh can be done uh using baf uh in a consistent way, as we've shown in the previous slide. So, in fact, for the features uh for adding removal and as well as the last feature which we're going to talk about, uh we are not going to demo because uh I mean, as I said, the fabric 2.2 is something which is still work in progress. We have a feature branch on which we are still working on it.

D

So uh we're gonna talk about the last part of adding a new pair, but uh for addition and removal we'll do a um pre-recorded uh demo for that. So what we're gonna show there is that how the whole process has been uh automated by bap. So with that I'll move to the first part and that's about adding a new organization so I'll hand over to abnard, we'll take you through the details of that step.

F

Yes, uh thank you, sujit for the introduction and uh priyanka for your introduction as well I'll go ahead uh by sharing my screen so um before we actually go ahead with starting the actual demo.

F

I'd first like to set the stage again for the people that didn't join the last meeting I'll just quickly recap what has been said in the last meetup.

F

So what suvajid has already mentioned is that with buff we're going to automate that tedious process of deploying the blockchain and that can be done by executing one command on a terminal and then everything will be automated. So the file that you see here is basically our master master configuration file or master playbook.

F

That will be run when setting up the initial network. So here you see, our site.yaml is basically a file that will spin up specific playbooks based on the network type, and this master playbook will take the network yaml. That priyanka has mentioned before as an input, so to also show that network.yaml, I won't open all these specifics, but we have some certain basic information for each of the network ammos.

F

So, depending on your network type, you will have a different type here, so in this case we'll be deploying hyperledger fabric with version 2.2, you have some environment variables and the docker credentials, which will be used to fetch the docker images that have been mentioned by sujit before in this case, like he mentioned, we will have three orders.

F

um In this case, we will have one channel which will be joined by all the organizations that we have find below. So at the top, we always have the order organization, in this case it's one organization with three orders. This can also be multiple organizations, it's just depending on your network setup, and then we have the three organizations below.

F

So um what you can do is by executing that master playbook, that I've showed before with uh this network.yaml as an input, you will deploy a complete network which will basically give you um this state so I'll, zoom in a bit and full screen it.

F

So what you see here is that, with the kubernetes cli we've fetched all the pods that are in the hyperledger deployment.

F

So what you see here on the left is that we have a bunch of name spaces associated to each of the um the networks and the organizations that we have defined important to note here is that normally in a production environment we would have multiple clusters, so each of the organization would have a separate kubernetes cluster which they can manage themselves, but for our development purposes we develop on one cluster, because that makes it easier to to do and then we separate those organizations by the namespace, so everything that is within the carrier, namespace is for the carrier organization and so forth for the manufacturer, the supply chain net, which is basically the order organization, so it's kind of a network operator and then at the bottom.

F

You see the warehouse organization.

F

um Every organization will have some common uh boards and jobs that were run during this deployment. So, for example, you see some pods that are in the running states, so these are the actual active components that will stay up and running while the network is as well. So, for example, here you see the appear on the carrier network and you see it's cli, which we can use to.

F

For example, qr80 chain codes invoke the chain codes, things like that. You see the certificate authority and the certificate authority tools which I will dive in deeper, because we will use those extensively when creating a new organization and adding it to the network and then the completed pods. Those are not really bots, they are jobs that run so they will spin up some pods in the meanwhile to execute some actions and when they will be done, they will be spun down again.

F

So, in the case of every organization, we will have a job that will join the organization and its peers to the channel that we have created, and then there are some actions that we will do for the chain codes so for fabric 2.2, uh we've implemented the new the life cycle. So previously you would have a different way of installing and invoking chain codes to a channel, but now with fabric 2.2.

F

One of the biggest changes is that there is now a life cycle associated with the chain codes, so you have some different steps that will be done so you have. Each organization will install the chain code and then by the creator of the channel, it will commit and approve the chain code to the channel and that endorsement will then be basically be on that channel. So every organization on a channel will have approved chain code all right.

F

So now that we've set the stage for the initial baseline of the demo, I will start the first video of the deployment. I apologize if it's still a bit smaller on your screen, but I will talk you through what exactly we're going to see on this video.

F

uh So on the left, I've split my terminal in two pieces on the left. We have our ansible playbook commands, so this is the command that will execute the deployment of our fabric network.

F

So the first input is that configuration file important to note when adding a new organization file, that we have a sort of a new master playbook. So if I just go to my code first, we have this site.yaml, which will be used for the main network deployment for the first initial time that you spin up the network.

F

But now that we are adding a new organization, we will have to use a different master playbook.

F

So what you see here is that it's named ad organization- and this will have a bunch of roles that are executed in sequence, to make sure that everything will go right and I'll kind of link, those roles that are mentioned here with different timestamps in the video later.

F

But with adding a new organization, we will also have a different configuration file because there's obviously a new organization that will be joining the network.

F

So we need some additional info and some of the existing values will be changed so and here we have the previous network.yaml and then we will switch to a new network.yaml that will have these new organizations.

F

So we see here that the first four organizations will still be the same organizations that we've used before and then at the bottom. We will add a new organization so for the supply chain. um Supply chain use case we'll be adding the new participant in the chain, so the package will eventually be delivered to a store, so we'll be adding a store organization to our network and that store organization will have all the prerequisite information that aorta needs to have. So this subject will be used for these certificates.

F

We have some information about our aws, kubernetes and vault, but the most important thing within the adding of a new organization is this organization status, so the organization status in our configuration file can have multiple values, so in this case a new organization will have the organization status new and if we then open another organization, so this warehouse, we have already added three networks, so we know that it is an existing network uh and then our baf automation will know. Okay, this is an existing network.

F

I do not have to spin up anything new for this one. I will just use the existing resources that already be deployed in the network, so in the meanwhile I'll start, the video and while on the left, our playbook is running with that network.yaml as an input on the right. We see the kubernetes bots that will be coming up as the demo progresses.

F

So, each time when a role is completed and a helm file is generated, it will be picked up by our flux, ports, the git of flux, which will be synced to our repository and then those helm deployments will spin up ports as we go so um and first you see uh the basic uh infrastructure prerequisites uh spinning up, so we will test our kubernetes connection to the clusters and we will check uh if our fall credentials are valid and in this case we're using aws as our cloud provider. So it will download the cli tools.

F

It will configure that, so we can use that in our deployment.

F

So once I skip past a couple of minutes, so the first minutes will be used to set up the prerequisites and then, if I skip to about six or seven minutes, we see here that our first, um our first main component will be coming up. So in this case on the right, we have rca coming up, which is the certificate authority, and that is the main component like I said that we will use to generate the certificate for the organization.

F

So if we then swap to our playbook, we see here that uh eventually it will include the role to create a ca server, so our roles and and bef we've really named them uh explanatory.

F

So basically, the name of that role will tell you exactly what that rule will do without you having to understand what the underlying logic is.

F

So this will spin up the creates a dca server which will take some inputs which are configured in your network.yaml. So it's really specific to that organization, and in this case the important thing is again here you have that organization status, so it will loop through the organizations which you have defined in your network.yaml, but in this case we only want to spin up the new organization.

F

So again, we will here filter on the status which is new, so the certificate authority and the certificate authority tools, which is basically the kind of cli that we will use, will be spun up in the meanwhile.

F

So we will just continue the demo and then once those two tools are running so I'll skip again ahead. So in the meanwhile the value files are generated, it's pushed to the uh repository and it will be synced.

F

So once that is done, then we see here that there are two pods which are now running. So that means at this point in our deployment. We have those two things running so um one step that we do is in the middle. We will add a pause to the network.yaml to our deployment, um which is basically to uh to prevent our certificates from not being valid. So, by sleeping for six minutes, we make sure that our certificates are valid and we can use them to continue in our deployment.

F

But before we are sleeping, we are doing some really critical things for this adding of a new organization.

F

So we are doing two important things so once you see the ca server and the c8 tools, when that's it's done, then we will generate some scripts which will be used to add a new organization.

F

um The first thing that we will do is generate a cryptoscript for that new organization, which is a script that is filled based on a template. So here we have a template of a script which is quite complicated. I won't go into the specifics, but what we see is that we are basically parsing some values which are based on our network.yaml within this script, so this script will be basically configured based on the specifics of your new organization, though so the script will never be the same for each organization.

F

um What the script will do is um it will generate the configuration block of that fabric network based on the organization that we have already have. It will add that new organization to that block um and then once we calculate the difference between those two configuration blocks, we know. Okay, this is the part from the new organization and we can add that to the existing block to make sure that all the organizations in that fabric network know. Okay, we have a new organization that will be joining us.

F

We all need to be up to date on that and then once that is created, then we will just save that to the ansible host and then that will be used later to actually push that to the network.

F

So while we are waiting a couple of minutes to make sure it sleeps we'll just leave this running and then afterwards, once we see here, we see the network is sleeping and then we will use the previously generated cryptoscript to create the crypto material for your organization.

F

So um what we'll do again is create the cryptoscripts for each organization which has the status of new, and we will use a different template for that. Let me just check uh if I have that open, so the cryptoscript, um which is again a template that we have um for the script, so the baseline is the same across all of the organizations. But again we see within those double curly brackets that we parse in some specific values which are based on the organization itself.

F

So we see some uh variables being set and then at the bottom it will use the binaries from fabric. So in this case it will use the ca client um to generate those certificates.

F

So once we have um basically made a bash script out of this template, we will then execute that script on the certificate authority. So this this will already have the existing certificates, which we have fetched from our hashicorp fault. So it has the key stores and it has the right binaries.

F

So we can use the certificate authority to generate the certificates for that new organization, which is the certificate authority that we have spun up before. So this is why we first spin up the certificate authority and at cli so that we can use that later um and then afterwards, once that is done um I'll move to the next step.

F

So um we will create our config tx. So based on the network.yaml as mentioned here, we will create the yaml file for the conflict. Tx binary, meanwhile, we'll also be putting some stuff in the vault which will be used later and then that will be used by the config tx gen binary in the next step, where we actually go ahead and create those channel artifacts.

F

So again, here we have a channel artifacts role, which will just create everything that this new organization will need to be able to join the channel.

F

um So if I then skip ahead a bit, um let's see uh so we see here that our playbook is still running. We have not spun anything up yet because now we still do that configuration to make sure that this new organization will be able to join our network and then in the next step we will use that previously generated conflict block that I have mentioned to start the peer cli for that new organization. We will temporarily spin that up and then we will fetch that configuration block uh modify it.

F

So then we can add, as we said, those delta that delta the difference between the old configuration block and the new configuration block.

F

We can modify it and then we can push that back to the organizations once it is signed by the organizations which will come to later once that is done, we can actually go ahead with spinning up the peers for that new organization. So here again you see the create peers role. So again, this is quite self-explanatory.

F

We again have some inputs from our network.yaml. In this case we will again be deploying the new organization.

F

So if I go back to my video at about 17 minutes, so we'll take about eight to nine minutes to do the pre-configuration.

F

We see that our pier will start spinning up, so it will use the previously generated configuration files to spin up that beer, and now that we've done that we can have the new configuration block be signed by all of the peers in the network.

F

So we will call the assign and update role, which will fetch the block from the ansible host, which is basically your local machine or your docker container, whichever you will use to deploy our bath network and then get it signed from the administration organization.

F

So in this case it will look through the channels and each organization in the channel will have a role. So in this case we have one creator of the channel, which will be in this case the administrator, which will then be responsible for signing that configuration block. So once it has been signed by the creator of the channel.

F

We know okay, it's valid and we can continue on with deployment.

F

So once we have signed and updated that we can use that configuration block and the final step of the main part of ag in the new organization, we can join the new peers to the channel, so it will fetch that block so block 0 in this case we've updated that block. So it's now the updated state of the network and it will join the peers of a new organization to the channel.

F

So if we skip ahead in our video to let's see about 19 minutes, um it's a bit ahead, yeah. So here on the left, you will see that our deployment will wait for the join channel job to be complete.

F

So if we skip ahead, we see that that job is running and that at about 20 minutes into our deployment, we have joined the beer to the channel.

F

So now, the last step that we have to do is that we can deploy the chain code on that new organization. So in the channel we have to find a chain code that we've developed as part of our reference application that sufijit has mentioned, and we will now go ahead with deploying that onto the pier onto the channel. Excuse me and you see again, that we will execute some jobs, so we have the install chain code which is running on the right and then with the new lifecycle, as I've mentioned, we will have.

F

uh Let's see, um we have also will have uh a proof and then folk part of there. So we have for that new organization. We will have the approve chain code, job and we'll have the invoke chanco job so now we're at the end of our deployment. So we've deployed a new organization and added that to the existing channel. So what we can do, as a last part, is to use our cli for that period to just validate that everything has gone right. So we will take that cli for the store.

F

We can execute some commands to access the bash terminal of that of that beer cli, and then we can execute some commands that are part basically of the of the beer cli to just validate that everything is working.

F

So the first thing we do is that we fetch the channels which the spears on so you see that it has joined the all channel channel, which is the name that we use for our channel in our deployments.

F

And then the next thing that we can do is just validate everything for the chain code, so we will first fetch the install chain codes on the pier. So we will use the um life cycle for this, so you see that we have some chain codes installed.

F

The next thing that we will do is um to query the approved chain codes. The committed chain coins apologies, so we see here that we have some committed chain codes definitions.

F

uh We see a diversion and sequence of it and we also see the plugins that we can use for the endorsement, and the final thing that we will do is to check that the committed chain codes have also been approved.

F

So we see here that there is the approved chain code on here which, with a package id, so we see that this new organization has now been correctly added to the existing network, so that is basically on a high level, uh our demo for adding a new organization in the background that will happen a lot of complicated things but yeah due to uh time constraints. I have not dived that deep into it. If you have any questions on the the inner workings of the demo, please feel free to ask um and yeah also.

F

We are still uh like sufijit and priyanka have mentioned still an active development of this fabric, 2.2 feature branch, um so we're still looking for contributors on that. We still have some really interesting issues that are still uh well issues well stories and features that we are deploying uh uh for this fabric, 2.2 branch, so any contributors are very welcome.

F

um So let me just check if there are any questions in the meanwhile that I can answer before I move on to the next part of the operational features.

E

There are two questions: um the first one is by samyak and he asks where do you fetch the chain code package from? Can it be pulled directly and compiled from vcs.

F

um So the chaincoach package, like we say we have some chaincode- that we have developed as part of our reference application. So if we open the network.yaml quickly, I see that shonak would like to answer this question so I'll also maybe hand it over to shonak. So he can. uh He can answer that question go ahead. Should I.

A

No, I was, I just marked it because you are already answering it live or not.

F

A

But I think uh the the answer to that question is the chain code package is fetched from a git repository, which I guess.

F

A

Are getting to.

F

Yes, um so in our organization we have a chain code section which will supply the organization that we need for that chain code. So here you see a repository variable inside of the chain code. So in this case we are using the blockchain automation framework get repository which will have the chain code in our examples uh supply chain app, but this can be any git repository. So, for example, if you want to use the the fabric samples repository, you can use that one as well. You can deploy the fab car chain code on it.

F

So anything that is on a repository. um You can pass that here as variables, so we will deploy that chain code onto the network. Yes,.

E

So to answer your.

F

Question? Yes, it's a fetch from vcs yeah.

E

And to add on to that, uh it's totally pluggable, uh as arnold mentioned, we have used it uh in three different production systems uh with different use cases, different gene codes.

F

Yes, I believe that the chenko that we use is based on on go. I know that we've also deployed java chain code on it. I don't, I don't know for sure if we've deployed javascript chain codes, but then we have covered the three main supported languages for chaincode on fabric right. Is there any more questions.

E

So can baff integrate with external cas for getting crypto material, or is it something that's planned further down the line yeah.

F

Yeah for that I'd like to hand over to shona, because I don't know the answer to that- maybe shona can actually.

A

Yeah so uh uh as of now, it does not integrate with an external ca, and if you need that feature, you can always welcome to submit a pr.

A

F

A

Yeah and it is not planned uh further down the line by the current maintainers of the project.

F

Yes- and I think that's that's one of the main charms of an open source project right, like you mentioned sure like. If you want to add it, you can always submit a pr to the to the repository, and if it's, uh if it's possible, then we will sure look into into integrating that.

A

Yeah- and the next question is about where it is running, as I think we uh superjet also said that it is running on on kubernetes cluster and uh arnold. Can we just show where the kubernetes cluster details are mentioned? So it's.

F

A

The kts uh sorry, the kubernetes section right for each so.

C

A

Organization has a section called kts where you can run where you pass your kubernetes, the region. If you are running on aws, you don't need it on other um and then the context, which is the cube, cube context and and the config file, which is your q config file and that's all and it doesn't. um Actually it can be any kubernetes. It doesn't have to be aws. I mean this demo was on aws yeah, there's a rest api layer in the block diagram in one of the slides earlier on customers.

A

Okay, so that rest api is, I think it was at the application level uh so which does not have anything to do with uh with uh uh with uh what we saw today. So we we have the rest api at the application level and that's the part of the supply chain application that we have sample, and why do we have a rest? Api is because our supply chain front end talks seamlessly to the to either fabric order or quorum back end, and that is the rest. Api in that case provides the the express api, provides.

A

The abstraction and the rest. Api is only applicable in case of fabric which, which we have as an example. Again, it's a part of the sample application.

F

Yes, um yeah, so let me just quickly look at the time that we have still um yeah so like we mentioned um we, we also have some operational feature, which is still a work in progress, so I will not be showing a demo for that, so I'll just be going through the same master playbook that we have for the organization so again for this new uh arnold.

E

Sorry, um just yeah, let's check with arun arun. Do we have.

F

E

Or um because we.

B

Have we have ten more minutes.

E

F

Ten, more minutes: okay, yeah! If we have ten more minutes, then I'll I'll hand it over for uh the next uh live demo and the closing statements uh by swedish. Thank you priyanka for checking that so I'll hand it over to suvajit I'll stop sharing my screen and you can take it over.

D

Yep, thanks have not thanks for your detailed explanation, so it makes my job much easier, so I'll go quickly, because uh the next demo, uh which we are going to show is about um automation of uh removal of an organization. So the automation, as we already mentioned, bab, does in a consistent way and the basis of the flow remains the same. So I'll just quickly share my screen. um I have a pre-recorded demo as well as I'll be taking you.

D

Through our code structure, our code flow uh so like in the previous uh similar to the previous uh on the left screen is the ansible controller machine where uh we run the playbook. The playbook in this case is the remove organization.yaml. So if you have our latest code from the feature branch you'll have this. Under your hyperledger fabric uh configuration folder, we passed the same single uh configuration file which was uh used to addition of an organization.

D

It will have the I'll show that in details, but yeah I mean, as we said, that we we have a single configuration file. So all we do is that we change some of the configurations there and run the playbook on the right side. You have the deployments which are shown on the uh which are on the kubernetes cluster. um This the warehouse was um just in the previous demo.

D

It was shown that the warehouse organization was added to the network, so with that I'll just quickly switch to uh the code where I'll talk about uh the playbook, which uh does the removal of an organization.

D

uh Is my vs code visible to everyone.

E

D

Yep, thank you right. So uh this is the uh playbook uh which does the removal of an organization. So in terms of adding an organization it, it is a similar process, but uh more simpler than adding an organization, so the whole process of removal of an organization uh we have automated it and kind of divided into simple um roles or steps. I would say so. These are the roles, as you see here are the ones which are used to do that.

D

So, basically, uh if I have to start with the uh the thing is that first, uh it kind of generates a script uh which kind of modifies the configuration block uh to uh to kind of add the organization which we want to remove.

D

So the next role, as you see, is uh kind of uh talks about uh configuration, fetching the configuration block uh and also the next one, is uh after editing the configuration block it signs and updates it once that is done uh and the configuration block is committed to the channel uh uh to the channel. The other cleanup happens, which is uh cleanup of our kubernetes cluster. It also kind of uh I mean clean up, not the whole cluster.

D

Just the organization part, which is uh also removal of the cryptos which was previously generated and put into vault and also the flux releases, which will uh kind of remove the deployments from our uh kubernetes cluster. So this is the base uh uh playbook, which removes that. So these as roles and it kind of further calls tasks and several roles, so I'll not go into much details because I already explained by I've not in the previous video.

D

The functionality of removal is kind of same uh the updation of the configuration block and then uh signing it by all the uh peer peers in the channel and then committing it so I'll quickly go to the demo and on the demo. What you'll see is that uh the the same automation happening in sequence so with further ado I'll, just play it uh yeah before before I do that.

D

I also like to kind of talk about the changes which was made on the uh configuration file, the network yaml file, so major changes I'll just talk about quickly, as we don't have much time so uh yep. So this is the uh configuration file. This is the same configuration file which was used to add of the uh adding the organization, the store organization.

D

uh Basically, when obnox talked about the org status, he said that there would be other options available for that or other values that can be passed here so for a case of a removable, org or all we need to do is that we change the org status to delete. So there are automation, kind of picks that up and knows that this needs to be. This organization needs to be deleted and the organizations which are already there- and we don't want to do anything with that- it's just org status, still remains as existing.

D

So uh this information needs to be added to the cha to the organization or the participants uh list in the channels, as well as in the organization field uh list, which is here the last one, which is the store, we kind of uh add the org status as delete here.

D

So uh this is the single configuration which will be used to uh removal of the organization and I'll start, the playbook and start the yeah.

D

So I'll just quickly pause and you see that uh it kind of picks the first uh roll, which is like uh I mean I just skip it I'll, go back one step.

D

uh Yes, so as you see that it kind of starts with the creation of the delete.org script and then it moves to the next role, uh which is about fetching the config block. So uh in in our network uh configuration file, we have one organization under the channels which is the which is tagged as a creator.

D

So the first the creator it checks for whether the creator, the prcli for the creator organization, is up and running or not once it confirms that it uses a peer cli to fetch the configuration block. So uh in our case the uh we'll go back. uh In our case, the carrier is the one which is the. um This is the creator organization, so once it fetches the uh configuration block, it updates and signs it once uh the signing process involves uh in our policies what we have mentioned that we have kept it default.

D

So the signing process needs to happen for by all the participating organization. So it will look through all the participating organizations and it will sign the configuration block, the updated one.

D

So here, if you see it, does it, it checks all the uh prcli of the participating organizations and connects to that and signs that, so the signing happens uh through the admin account of all the organizations, so it uses the admin uh to do the signing so uh once the uh once, the channels are signed, the creator organization kind of updates the channel uh with the new configuration block. So this is what is happening here right now, as you see, in the uh left hand side of your uh screen and I'll move forward.

D

So once that step is done, the uh once that step is done. The part of where it kind of the fabric related stuff is done here. So on the next step of the automation, which I said is to kind of clean up the uh cluster, uh not completely enough, but the cleanup of the organization's uh artifacts or deployments which are there on the cluster. So this is what is happening. The first one kind of removes the cryptos which are stored in the vault for that organization.

D

So I mean before doing that it kind of tests, the kubernetes connection, it installs the required clies like the aws cli, because we are using the aws e case in a in this case. It kind of deletes, as you say, deletes the ambassador uh credentials. It deletes other cryptos and um it will also next uh delete. As you see, on the right hand, side, it has started terminating the uh the various deployments of the uh store uh net, which is the store organization.

D

So it's clearing up the organization uh store.

D

It also deletes name space and then yep so that with that I'll forward it- and as you see uh it does that through it does not directly do that it kind of deletes the files and pushes them into uh into our repository and the plug sync works and picks that up and applies that for on the kubernetes. So with that, we see that the deployment is done and the termination has already started for the pods.

D

So with that I'll, just close and uh yeah. If you guys have questions, please ask.

A

Yeah, I think I've already answered uh quite a few questions, so uh is there anything open? I'm not sure how. If um I think the next session is pending right.

D

E

Yes, sorry so the last thing I wanted to cover around just one minute: two minutes, maybe uh that we still have a lot more to do. um You know there's a lot of things, a lot of operational features in our roadmap, so I would request the community here to be uh more active and contribute, and if you have evidence you know from the client conversations that you are having that there are more things that the client are asking. We uh would welcome that as well.

E

So uh please come to the github, raise issues, raise pull requests and contribute. Thank you.

B

Awesome thanks. Thank you. um Everyone thanks! um Thank you to accenture team as old. It was a great session and up next we have our next session from ironworks team on hyperledger aries. For that I'll hand, it over to kiran and.

B

Can you do that and then probably because ankita is going to walk us through all the uh things that we have to put together other yeah, but thanks to the hyperlink chapter for giving this opportunity to us once again, can you share the screen? Please.

G

uh Yeah hi everyone. This is ankita from ironbox. Let me share my screen to all of you.

G

Let me know when you'll be able to see my screen.

B

Yeah we can see your screen.

G

um So thank you for thank you. I sincerely thank happy little india chapter for giving this opportunity and happy like every time to present. What's going on, so uh we will be presenting hyper lecture eras all about eris today and let's move on to today's agenda.

G

So we'll quickly have a look at what we are, uh what we are at ironworks and what we are working on and then we will know about hyperledger eras. What is going into the areas? What it is, what where it is placed everything and then we'll get to know about the repositories which are maintained under eris and uh contribution that we are making into and um we'll let you know how you can contribute to the forum.

G

So I would like kalyan to take over to the introduction about uh my ironworks yeah.

B

Okay, can you go to the next slide? Next, one yeah very briefly, uh ironworks. uh This is a small uh boutique. We are specifically working into the blockchain space. I think we can skip this slide and get that we can go to the next one right. So uh we are about to complete our six years mark. In a couple of months from now of which I can say five years, we have been into blockchain space, uh so we will be actually a blockchain startup.

B

We can say from last two and a half years we have been very specifically working in a very focused manner, into the hypocrite, a reason in this stack, which is to do with the self-sovereign identity, which is why we believe that we can present uh about hyperlink in a little elaborative manner over here in today's uh attack fest area.

B

So, um over the last five years, we have been working on various implementations to do with uh hyperloop fabric to start with sawtooth, and then we moved on to uh hyperledger aries uh stack of technology when we are actually working with some of our enterprise customers to work on uh some of the problems that they are having with the identity space. In that new space rather yeah. We also are part of various forums which are dedicatedly working across the globe on the uh self-sovereign or decentralized identity as well. We are part of sovereign network.

B

We are actually uh part of the trustworthy foundation as well.

B

We will, of course cover that in subsequence that we are also one of the contributing members to the decentralized identity foundation, which is another uh foundation which is working into the uh identity space rather right and- and um we also have a small uh setup in ireland, which is focused on purely business standpoint, but entirely based out of india and and uh we look forward to contributing every possible way to the community, giving it back to the community and leveraging the open source and bringing our expertise and the experience that we have earned over a period of last week, two to three years in the ssr space, rather yeah uh quickly.

B

Next slide ankita, because I don't want to spend too much of time on this slide just introduce to all of us. And then we move to the core part of the presentation. Yeah uh uh yeah quickly. As I said uh close to six years now, uh we have been working across customers on all seven geographies with 15 plus countries and customers, and we are a 25 to 30 member team which is mighty in its own size.

B

Though uh yeah that's all about uh what we are into um and now I'll take a pause here and I'll probably hand it over back to ankita to deep dive into the aries uh stack here over to you. Thank you.

G

Yeah uh thanks kalyan for this very quick um but brief introduction.

G

So, let's move on to what is it is what is hyperliterary project that is under the hyperlithium right now so before before, moving on to uh hyper laser eris, let me quickly brief you about how what is identity and how it is managed these days, so uh all the identities that we are having right from our birth certificate to email, address to user, name, passwords or graduation certificates or everything.

G

These are borrowed identities that we have so any of the organization or the issuer has given us these identities and we are just owning those identities or using those identities to prove ourselves. Why not at the other place.

G

So these are um the identities which are kept safe with the organization that has provided us. So this is the current model of identity. We are. The world is using uh moving on to the next thing that is self-sovereign identity, which talks about um as a user. I will be the owner of my own identity, all the other organizations that those are the issuers that that are giving me the identity, but I I will own the identity.

G

Whole and soul, so this is what self-sovereign, identity or ssi is about, and with this decentralized ssi, this decentralized identity concept. I will be the driver of my own identity.

G

I know when to share what to share and uh how to share and why I want to share with someone else without uh without being forging with the identity that is provided to me. So there is, um there will be multiple roles in this ecosystem. uh Mainly there will be three type of users.

G

uh One will be the issuer, the issuer which will provide or which will give the identity. That is, we call it as verifiable credential, because these credentials will be digitally verifiable, so these credentials are given by the issuer and the holder will acquire, store and present the credentials whenever required and the verifier is a rule which will verify uh the credential which is given to the user.

G

Let's say if I have a email address or I have a graduation certificate, so the organization that is asking for my identities, that will be an verifier and, of course the blockchain ledger, will be the single source of truth, where which will maintain the status of the credence of the certificates of the credentials that is given by the issuer to the holder, but where the credential actually lies. So the credential actually lies within with the holder with within the wallet that is provided to the holder.

G

So uh in this way the holder is the sold responsible of his own identity and the concept of ssi works with the on the same lines. So, let's come back to aries. This is about how the decentralized identity will work, what will be the workflow and data model and everything? So, let's come back to eris again. So uh what what eris is so aries is uh is grew out of the effort which community was building with hyperledger indy, which is the blockchain for distributed identities.

G

So they'd realize that the client component that enables peer-to-peer interaction, peer-to-peer interaction uh between the parties and the protocols can be more. You reusable and it can be extensive extendable to other blockchain uh blockchain platforms like the other blockchain projects we we have, so it can be extendable to other blockchain platforms in order to use the verifiable claims in different context, so it provides shared, reusable and interoperable toolkit, which is to create, transmit and store the verifiable credential and which are cryptographically safe and uh the key management system works on.

G

It uses hyperledger ursa to manage the keys and secure and secure the secret management.

G

So the key characteristics that hyperledger ares has are wallet infrastructure, so wallet infrastructure uh can be used for secure storage of cryptographic, secrets that can be my digital decentralized identifier or the credentials or any other information that are used to build the blockchain client that we refer to as agents here. So uh the wallet infrastructure is a secure storage technology.

G

The next characteristic is blockchain client that we also refer to as a resolver. So it is an interface for creating and signing of the transaction on one or the other ledger. Then the next is secure messaging.

G

This feature allows off-ledger interaction, so uh between agents. So there are two agents, one for um let's say alice and bob: they want to communicate with each other, so they're the messages which will go from ls to bob they. They should be secured messages by uh one or the other mean, and uh that can use multiple transport protocols that can be that can go via http or tcp or any other protocol like bluetooth or a you know, any other protocol. We have so this secure messaging um we refer to as uh in aries.

G

It is the did communication we refer to as bitcom messaging, and the next is uh api infrastructure. So api infrastructure are the mechanisms uh to build high level protocols based on bitcoins, so what type of data will flow? What uh what will be the message structure? How vcs uh can be issued and uh everything?

G

So this is where uh hyperledger areas lies, so it uses uh hyperledger indie as a decentralized identity, and it can use uh um any of the ledger um like if we have dids on ethereum or um any other ledger, it can use those as well, so it is pluggable and it uses cryptographic library from hyperledger ursa that provides wallet, security, your key management systems, uh key management and signatures and proofs that you present. So all the cryptographic hash cryptographic. Libraries provided by ursa are consumed in aries.

G

So this is an aerial view of how agents will look like so everything uh all the individual, the identity owner I as an identity owner of um few of my identities, so an organization can have its own identities. Any of the natural thing can have an identity, all the appliances, man-made things, sensors and everything they can also have their own identities.

G

So um all these, I, um the all these identity owners uh they they will have their own agents because they will have their own decentralized identity. We call it, as did so, that did is managed under the wallet, so every identity owner will have a agent will which will manage the wallet and uh the the agencies, like the issuing authority or the verifying authority or any other peer that wants to verify or issue the credentials they also have will have their own agents and wallets.

G

So these two agents will communicate with each other over a secure messaging system that we refer to as ditcom. So this is an aerial view of how agents will look like what all different agents can we can have. We can have cloud agents, edge, agents, mobile agents for that matter, so this is all agents that aeris provides.

G

So um there was a saying that seeing is believing, but in this digital era of techno of advanced technology, we can mimic everything about a person, everything and anything about a person. So what you see not necessarily what you believe.

G

So aries is about agents uh that are connecting uh connecting and enabling trust over internet, so it is about making digital systems more like human systems. So this there is an aries rfc that talks about trust over ip trust over internet uh stack that introduce a complete architecture of um bringing technology. Trust in human interaction and uh ironworks is a contributor in tuip um typ foundation and holds co-chair for governance, tech and vice chair for technology stack working group.

G

So there are different layers of this trust over ibm, so the very basic layer is dids, where every entity will be tagged to the decentralized identifier, the unique identifier that will define an identity uh that will define an entity which is provided by hyperlizer. Indeed, so the next step, uh the next layer is ditcom protocol that establish a cryptographic means or a secure mean by which two agents can communicate with each other.

G

The next layer is data exchange protocol, so the first two layers uh they establish cryptographic, trust we can say it as a technical trust between the peers, so the three and fourth layer. They are human trust between the organization, individual things that they are using, like sensors devices, appliances etc.

G

So the goal here is to standardize all this all supported credential exchange protocols uh that that are verifiable, credential exchange protocols that are given and standards that are given by w3c and um the next. The fourth layer is application. Ecosystem layer, like just an application, calls a tcip uh tcp stack uh for communication over internet, so the app will call uh toip stack to register dids or to make connections or for credential exchange or to engage in any of the three layers that are below it.

G

So this is all about how you can bring uh trust in that over the internet or trust on a trustless interaction.

G

So this was about um uh eris, where it is placed. Can.

B

I uh can, I add, quickly about trust or ip as well, a very brief way. Yeah. We are okay with that yeah. So.

C

B

Our ip foundation has uh recently been formed somewhere in the month of march or april, uh wherein uh some other veterans working in the in the identity.

B

Space actually felt realized that there is definitely a need to bring trust over a trustless network and, just like, we have a concept of voice over ip, the concept of trust or ip has been brought in, and it's entirely emphasizing on how we can have a trusted or uh cryptographically algorithmically, establishing a trust between the interactions people have over the internet with each other from any corner of the world yeah.

B

So this is catching up a lot of momentum there now and we would really encourage uh everyone to participate, be an observer, listen to what is happening, because this is technology in the making. Now uh before it starts getting as a receiving uh before we start getting out, the deliverables and components and building blocks coming out is right time to just engage and start looking at what is happening. We can join as organizations or you can join as individuals as well. At the same time,.

G

Right so um kallan has already shared few links where you can go through the trustworthy foundation. You can check about airs uh project that is over there and this rfc. That is specifically provided by that. This is one of the rfc that is provided by eris.

G

So moving on to the business use, cases of ssi or business use cases that uh hyperledger areas can bring in. So there are plenty. There are plenty of use cases that um that that that can be there, so very basic are trusted data transfer. So it's not just about sharing the data, it's about sharing the data safely and securely so that privacy is preserved, so trusted data transfer, uh verified cvs and qualifications.

G

I if I want to check whether this the particular cv that is given that is in front of me, is valid, or it is not forged with. uh Similarly, with the um certificates, the graduation certificates or in um certificates that we have the qualifications, the kyc process, uh which is an um which is in multiple sectors, that can also be a use case of it uh cross border trust, uh digital passports.

G

We are talking here about so this can also be one of uh the use case of the air stack and also in healthcare, uh healthcare systems, the healthcare reports, management and security of the data of the patients and everything that can also be the use cases of decentralized identity or ssi.

G

So there are few use cases. Apart from that that we are working on our um transfer of ownership of the verifiable credentials, the assets they can be tickets or any of the assets that you are owning. So if a you person is owning some asset, then how that can be a verifiable credential and how that the ownership can be transferred from one user to another user.

G

And there there can be use cases where iot devices can be iot, devices can have their digital identities and suppose I, if I want to have access to the door of the racks, the server racks, so uh how I can ensure a non-forced identity that this is the identity. I I I belong to, and this is the identity that has an uh ownership or access for the particular rack.

G

So the ids can be installed on the ids can be, ins can be attached to the device the ids can be attached to devices to the person and the credential can be.

G

The credential can be provided to the user to the holder and the device can verify the credential that is given to the holder, so the door racks or the bike that have installed an iot devices that those devices can uh can verify the credentials or the thought access of that is provided to the holder.

G

So these are couple of use cases that um hyperledger areas or ssi brings in or leverage there are different repositories maintained under aries frame, hyperledger areas, so we call it as frameworks and agents. So there are different frameworks.

G

There are different agents which can be, which can be, which can serve a person to to maintain its wallet, its tids and to use the protocols for the verifiable credential exchange and proof verifications.

G

So the couple of frameworks that are that are over there are um aries cloud agent python. So it's um it's uh it's an uh agent that is written in python and uh it can be used for any non-mobile agent scenario.

G

uh It's a cloud agent basically used for issuers, verifiers or storing of the credentials or anything it can be used as an enterprise edge agent as well, and the main contributor is the dc golf and we are contributing to one of um the rfc. The one of the protocol that is given in that is need for deployments uh for endorsing the transactions.

G

So you can go to the github of this framework as well.

G

uh There is another framework for which is getting developed in javascript, so it is also an ssi agent which leverage ditcom and did based communications and storing of the vcs verifiable credentials and exchanging the proofs, and it also provides the edge agent. These are uh all uh enterprise edge agents which can be used in a non-mobile scenario. Agent scenario, so we are contributing for multi for implementing multiple areas, rfcs that are provided in the javascript framework as well.

G

So there is one more framework that is written in dotnet and dotnet can be used for building mobile as well via xamarin, and it can be used as edge agent and mobile agent board and the main maintainer here is intrinsic and we are contributing for enhancements and everything.

G

And um there is one mobile agent, all the all, the agents that we discussed were for cloud agents. They were for enterprise edge agents, but we have a mobile agent as well, which um so I would like amit to talk about it, because he is the main contributor and maintainer over here.

G

So amit. Would you please yeah.

H

Yeah thanks santita, so yeah. If we talk about, uh let me start with the basic. So if we talk about the wallet, so what is a wallet? So wallet is a is a is a place where you, you add all stuff into that. If, if we have a physical wallet, then we can add a cash card photos and all things so an identity wallet, it's just a combination of agents and and and and indie wallet.

H

So where wallet you can store all the credential which issuing party or the or any organization can issue those credential you just store in in your digital wallet.

H

So you know if we talk on holder side, so there is the three party that ankita already mentioned: one is a issuer, one is a verifier and another is a holder. So in ssi paradigm there is. There is a triangle we can say triangle.

H

So if we talk about the holder specific, so every holder needs uh needs help their wallet so where they can, they can store his credential, for example, if any government wants to issue the government id card, so every citizen of that country needs a wallet and and that wallet can capable uh capable to store the ssi based credential and whenever user node need needs to prove that credential they can easily easily provide that credential. So mostly holder can use the mobile app in today's today's world.

H

If you are seeing the mobile is mobile, makes our life more easier. So so we we are developing a uh uh india is mobile agent. We are, we are called as anima, so it's a aries react native mobile agent, so there is a two type of agent in uh here for if we are talking on mobile, so one is a cloud agent one and one is a age agent. So in a cloud agent, everything will deploy on on the server, so your wallet will be created on server.

H

So all your heavy crypto graphical library are processed on on a server in in the cloud yeah. So in the in.

H

In this, uh in this scenario, you you, you just need to use those rest api through that you can create one, your mobile application or if we have existing mobile applications, so you just uh plug in those api and you you can create your your identity wallet so to use the use the cloud agent again, it's not a pure ssi based solution, because when we, when we talk about the ssi solution, first uh character characteristic games is a decentralized.

H

So uh for the decentralized we need a age age wallet for for every holders. So we we, we team team of few members. We are with team of ironworks. We created a one, one react native mobile agent, so this is a lightweight uh mobile agent for the holder specific, because holders never need to do a create a credential things and never need to create a revocation registry and and all things.

H

So it's a lightweight agent because we can say that and again, whenever you want to connect with any counter party, you just scan the qr code and executing the aries base connection protocol so yeah. We recently uh create one branch on on the repository and we have added the connection flow so subsequently, we are also working on a flutter part. So recently uh we, our team, is started working working on a flutter uh aries and indie base uh sdk in a flutter as well.

H

So as ankita mentioned, if, if you have a, if you have some existing use case of your of your business so easily, you can plug plug plug our sdk into into your your uh in your system, for example, uh right now we we on a mobile banking. We can see whenever we we want to do any transaction again, we receive otp. So if we, if we we are on out of country, so it's time we are it's difficult to receiving the otp.

H

So in existing banking application, usually using this sdk you can you can implement up your ssi based uh credential verification flow, so yeah, so ernema is a open source uh mobile agent for react native. So currently, if, if anyone have a existing react native application and they wants to use use, uh uh india is based uh credential flows, so just they can use this sdk and achieve those things. So if we, if you go to the uh below link, you can find all the all the information about about the sdk, how you can use what?

H

What are the basic uh packages that uh needed for it and all things akita. Can you please move forward so yeah, apart from this uh few few, more agents are also available on a different language, so there is one agent is available on a go language as well. uh We have also asked uh static agent in python, so they they have some static issuer issuer you, so you can just connect and you can.

H

You can easily start exploring the ssi things so in ruby, if there is also agent available and java as well so yeah, can you please yeah? So if, if you want to contribute how you can contribute, obviously we have questions so because I I know java how I can contribute. So if you want to contribute so there are some some links and chat options are available, so there is a weekly uh zoom calls are available for a hyper laser working group.

H

So there is a one wiki page for that uh there you can find all the call related information. What are the stuff is discussed on past call or what what will be discussed on next call so based on your interest, you can you can join those working group call as well. We also have a rocket chat, chat, uh yeah. We. We also have a rocket chat option so where uh everyone can share uh those doubts and and reso useful links and resources where everyone can easily learn and clear their doubts.

H

So yeah here you can see the hyper laser uh wiki page, so yeah all the things you can find here.

H

Apart from uh apart from this.

G

Yeah, so this is what uh this is, what eris is all about and how you can contribute to the the project that iris brings.

G

G

Thank you yeah. This was all about um what we were intended to present over there and um in in the situation where we are getting the laws like gdpr and pdp, where a data protection is the key uh key for any individual.

G

Any organization which are getting the data of the users which are storing the data of the users so right to forget, the data is one of the key thing that every organization has to keep in mind with the before storing or getting the details, so ssi or decentralized identity can uh fit in um with all these laws um which are coming over here.

G

So this is what we we were to present today. um So thank you for giving us this opportunity.

G

Any questions, if you would have, we can just take those up.

A

B

Thank you, ironworks team. Thank you.

G

B

I'll probably stop recording. This concludes the session.