 getting set up here, and I'll go ahead and hit start webinar. Hi everyone, thank you for joining. We will get started in just a couple of minutes. Good morning, good evening, good afternoon. We'll get started with the webinar in just a couple of minutes. Thank you for joining us today. Thank you for joining. We'll get started in just about one minute. All right, so welcome everyone to this week's Hyperledger in-depth, an hour with Cripsy, best practices and major obstacles for upgrading to Hyperledger Fabric 2.2. My name is Karen Otonin, I'm the director of Ecosystems at Hyperledger, and I'll be facilitating our session today. We have Chris Smith joining us, Mohit Seti and Kartik Nair. But before that, I'll get into a little housekeeping before we get started. As with all sessions and meetings here at Hyperledger, we follow an antitrust policy that you can find on our website and our Wiki page. This is being recorded, so don't worry, it will be available both on our YouTube page, we are currently live on YouTube, and also on the same events page that you registered for the session. Slides will be available on the event page on our website as well where you registered. So don't worry about that, you'll get all the information you need. We like to make these webinars a little bit more interactive than your typical webinar, so we encourage you to ask questions, to get involved, raise your hand early and often. I will be monitoring the chat, the Q&A box, and hand raising, so anytime you want to jump in, please feel free to do so. And our speakers will also be inviting you to speak at certain points as well. So we really want to make this a useful time for you to get what you want to learn out of it and take advantage of the fact that Cripsy is here to share their knowledge and experience with you. So with that, I will stop sharing. Excuse me, stop sharing my screen and hand it over to Chris to get started while I grab some water. Thanks Karen. Can you see my screen? Yep, take it away. All right, welcome everyone. I want to thank you in advance for taking the time to attend our presentation on best practices for upgrading to Hyperledger Fabric version 2.2. My name is Christopher Smith and I am the Vice President of Sales for Cripsy Technologies. Also presenting today are our VP of Technology, Mohit Sethi and our research engineer, Karthik Nair. To start out, I just want to, oops, I should have showed you that there. So these are the wonderful faces. So to start out, I just want to tell you a little bit about Cripsy. We were founded in 2016 and Cripsy Technologies is a team of blockchain professionals with a combined 120 years of experience delivering world-class technology solutions to large enterprises and to aspiring startups. In addition to blockchain services that we offer to manage blockchain infrastructure and provide chain code management, we offer a low-code blockchain as a service solution called CripCore. We are heavily involved with Hyperledger, Hedera Hashgraph and we're also a Microsoft Coast seller. So today's topic, we're going to discuss upgrading to Hyperledger Fabric version 2.2 and we'll share what we believe are the best practices and some of the greatest challenges throughout the process. These recommendations are based on our experience upgrading our systems and upgrading the systems of several of our clients. All right, so the question is, what is the need for all this? So why are we talking about this today? So there have been two major announcements in the last few months. That are relevant to this topic. First, Hyperledger Fabric announced the end of support for version 1.4 as of April, 2021. And then second, Microsoft announced that they were deprecating there as your blockchain services as of September, 2021. So if you want to take advantage of the additional features of Hyperledger 2.2, you'll need to go through the upgrade process. And if you are using ABS, you may need a new technology partner to guide you through the process. So given the maturity curve of blockchain, most of the programs in the past were not in production. So the upgrades were offline and it was not a business critical issue. Now, however, more and more programs are live and the in-place upgrade is becoming more common. So in-place upgrades are relatively complex given the business dependency of multiple parties in the ecosystem. And we are witnessing more enterprises approaching us for help and we have found that each upgrade is a unique proposition unto itself. So in this session, my colleagues will share their real-life upgrade experiences. And we're not going to reference any client names just to respect confidentiality. And I will also tell you about our upgrade ARM template that is available at no cost on the Microsoft Marketplace. It's a great resource for getting started in the process. And of course, if you have any questions about how to use it or if you need extra help, we are available to help. So I'll turn it over to Moet now to discuss the best practices for getting started. You ready, Moet? And you're on mute. Yeah. Thanks, Chris. Am I audible? Yes, I can hear you. Yeah. Thank you, everyone. So as Chris mentioned, so before I get into some of the details and experience which we have gone through at Cripsy handling multiple upgrades, just to touch on like what's currently happening. So there are a lot of projects which are on production on Hyperledge of Fabric. IT and implementation teams are busy with new projects on Fabric, Hyperledge of Fabric. However, a lot of attention and thought process is going on basically on two other challenges as Chris also mentioned, migration from one platform to another as well as upgrading as we all are here to discuss on the upgrades. I'll be discussing more on the primary, on the upgrade part. Now, why it is, why upgrade have become so important in the Hyperledge of Fabric journeys because most of the production projects were on basically Hyperledge of Fabric 1.4 LTS version which was a very long supported and very stable version and it was like widely adopted. Now, when we talk about upgrades in a normal ecosystem it is basically how do we write scripts and how do we do database upgrades, application upgrades. But when it comes to blockchain and specifically Hyperledge of Fabric, there are multiple members and we would have projects might have multiple channels, multiple chain code. So there is a need of an in-place upgrade so that the data and the policies which were provisioned and configured during the 1.4 version still remains intact and for example, in the 2.2 version. So definitely there is a need of an in-place upgrade. So basically I would be sharing the experience which we have gone through and what we should be following and what we should be avoiding. And definitely during the presentation, the webinar we would like to make it more interactive if you have anything, maybe you can send a message for a particular point. So let me start. So the first thing is basically we have to create a plan and create simulated instances. For example, if our application is running on a cluster or in a virtual machine model and if there are let's say three members, three PR organization, one order organization, you should basically be doing the same thing in our test and census and run the upgrades. It would be a big mistake if it basically directly run it on the production systems. Basically I'll cover more on that than the subsequent slides as well. And there is something new which have come up. Not many people would have used it, but specifically if we are into Kubernetes-based deployment, we will be going through something called external chain code. So we should also validate that our internal chain code functionalities are also tested on the external chain code. And once we basically have done the test on various instances by repeating the, let's say, taking the backup of the data, re-creating the instances, we could perform certain, let's say, a better plan. So in what sequence of operation we should be performing the upgrades, shall we upgrade the PR first, shall we upgrade the order first or among a large consortium who should be doing this first. So this practice would basically remove any challenges which we get into the, maybe let's say the UAT systems or the production systems. I'm very satisfied with that. Now I'm there. Okay. Is there any, I heard some noise. Anyway, let's continue. And obviously what are the channel and chain code policies which are, which needs to be tuned in terms of planning the upgrade. So let me go into the next slide. Apologies, I went ahead a lot. It's a little slow. I'll get there eventually. Sure. Good. Yeah, maybe you have to go into frame. There you go. Yeah. Now, when we say testing, creating an instance, it is also equally important that we are testing end-to-end functionality. For example, in your current application, the channel chain for endorsement policy is something. So we should also test whether such endorsement policies are working. For example, we have two out of five. You should also be seeing that different combinations of two are also working in the new upgrades. And specifically, Y2.2 is more important. There could be multiple upgrades. For example, 1.4 to 1.3 to 1.41. Hyperledge Fabric 2.0 brings in the new life cycle. The new life cycle basically is quite different. You need to approve a chain code before it could be committed. Whereas in Hyperledge 1.4, people just need to upgrade the packages, right? And any one of the member would instantiate the chain code or upgrade the chain code and that upgrade would take effect. Whereas once you move to Hyperledge Fabric 2.x, 2.2, each member, the default policy enforces that each member have to approve the chain code and then only it could be committed. This is a significant upgrade in the way chain code management was managed. So it could help people to basically plan that are all of the members, their IT teams, their software, their life cycle flow have adapted basically to this new flow. And if you are upgrading from 1.4 to 2.2, then that would be some channel policies which are also needed to be validated, upgraded. Can we go into the next one? Mohit, we actually got a question from Subhasi Spaniq. He's asking, how do you add an order from a different organization to the application channel and Hyperledge Fabric 2.2? Could you share the steps? How do we order the, how do we add the order? From a different organization to the application channel. And Subhasi, if you'd like to come on off of mute and clarify your question, feel free. Yeah, sure. Can you hear me? Yeah. Yeah, yeah. So my question primarily is, I wanna know, like how do you add an orderer which does not have the certificates like the crypto material? So let's say I'm having an orderer of a specific organization and I wanna add another orderer from a different organization not having the same crypto material to the application channel and not the system channel in Hyperledge Fabric 2.2. Yeah, that's a good question. However, basically I would like to focus on the upgrade. So I will give you a brief and maybe separately we can have a discussion. So Hyperledge Fabric 2.4, which is expected to come that reduces the dependency of the tie up between the system channel and the application channel which exists today, right? So till Hyperledge Fabric 2.2 it makes a compulsory, basically, first you have to add the order into the system channel, right? Then only you can make it to the application channel. So how do we do that? Maybe I can cover in a separate discussion. Yeah, sure, we can discuss it. But that's a valid point. And that constraint is basically being much easier in the upcoming 2.4 release. Okay, sure. Thank you. What is happening today is even if you design multiple orders for different channels, right? Within the organization, each order would be aware of all the channels which are available across any of the members. But going with this new logic which is supposed to come in 2.4, that privacy would be enhanced, plus it would make order of management much simpler. Sure, thanks for that. Yeah, so we can move into the next one. Karen, was there another question? No, no, just continue, thank you. Yeah, so one more thing important is basically taking the backup and creating the rollback procedures. Now why this is important is, and your existing channel could comprise of multiple members, and different member would be running or managed by different IT teams. They might be running on different platforms. For example, few of the members could be running and let's say the Eclipse provided platform, some could be running on their own. And similarly, Azure, AWS, or there are multiples, right? Due to various ways in which the platforms are basically designed, it's quite possible that in your first case, in your first trial, you are able to upgrade, let's say peers in few of the organizations. But for some reason, some other organization peers, they were not able to upgrade. So it's important to factor that everyone, not only one, let's say if you have five member organization and if you are doing an upgrade, everyone should basically create a plan in case of failure. How do we go back to our previous version? And if we don't do so, we can get into a situation where the network is partially upgraded, partially not. And we might not be able to do any transactions. So this is a very important point. And obviously this planning requires a good synergy between teams who could be spread across different geographies and they might be in different time zones. So this backup and rollback plan is very, very important. So for example, in a simple Docker compose model, you just need to ensure that the volumes, which are basically tied to your, the Docker instances for the peer and the order. So we should basically stop the processes, take their backup and then do the upgrade process. So in case of any issues, then we figure out that, okay, this is not going to work, we have to try it again, but let's bring the network back again. That's how it was. So it would be easy if you can bring back that folder, use that same config file and bring the network back. So this was a simple example. However, if you have a custom deployment model, your own Kubernetes model, where you are having this mounted. So we should be knowing how the data have to be backed up and basically how to use the backup data. Yes, Chris, can we go into the next one? And how do we handle the downtime handling? So it's quite possible that if we are in control of the entire network, for example, if you are the platform operator managing various services for our members, all the instances would be in our control, it would be more fine tuned. However, definitely there would be multiple teams which are managing and based on the size of the data and the number of chain course channel, it would definitely take time. So how does the business take this? Certain applications could be critical that the reports or the chain code queries should be made available to them at any point of time. So do we handle it in such a way that not all the peers, for example, in my organization, I have three peers or less than four peers. So I will have, I'll upgrade the three peers, bring the network, upgrade the network, but one of my peers would still remain in 1.4. It would be able to provide the chain code queries till the basically the network, the new network comes up and then I could route the traffic to the upgraded peers and then take this pair as the only peer which have to be upgraded. So this is how we could handle, let's say, an example of handling the queries in the downtime. But this is also an important aspect that when we are upgrading, we should consider what's the impact of the downtime on the application which relies on the blockchain network. And do we need to provide query or not? Yes, I think we can go into the next one. So I have actually covered it previously. So as I said, a Hyperlegia Fabric Network, let's say five member organizations could be sparing across different geographies, people would be in different time zones. So a coordination and the plan which also included the rollback and sorry, backup and recovery plan. All those should be in place. So you should know how to contact people from different teams and then plan it well. And obviously first we have to do in the test stages, UAT stages before getting into the production. Mohit, we do have a question coming from the audience from Jayakar Johnson. Yes. He's asking, while upgrading, what are the interoperability consistency strategies to be adopted? Interoperability? Interoperability consistency strategy. Am I audible? Yeah. Yes, we can hear you. And Jayakar, if you want to clarify your question, feel free to come off mute. Yeah, please go ahead. That is, we are doing architecture for a entirely different projects for the coronavirus control program. Okay. That is upgradable for the regular real-time healthcare application. So the thing is, here there'll be a lot of interoperability in the blockchain in this project is there. So in that, we plan to use the hyperlogist framework as the base for the total security of this data security. Yes. So what is your recommendation when we upgrade from one version to another version? Any, I think you advise for that the structural designing what has to be... Yes, yes, yes. So we have a similar experience, not exactly critical on the same aspect, but it was critical from the business requirement. The data was huge in one of the projects which we had to upgrade. And for your case, the application is very critical because it needs to continue. Upgrade is required, but still the applications will continue to serve its purpose, especially in this condition, pandemic condition. So in this case, like I will share maybe a bit of our experience. So when we did the test trial, we started with just the concept, means we took the replica of the network. We had just a few transactions and we tested it again and again on the test network, not on the, obviously on the actual network. Then what we did, because the actual data and the project was basically using a lot of something called the private data collection exhaustively and the data was huge. And so one of the point is when we upgrade specifically the peer and hyperlogist fabric from 1.4 to 2.2, there is a command, basically it will upgrade the database, right? It requires the database upgrade also, specifically if they are using couch DBPan. If the data is huge, it takes time. And similarly, what happens is if you have multiple team members for the same cluster and if you are going with the sequence, so we ended up basically creating scripts. So that reduced a lot of manual intervention. Obviously everything cannot be automated, but we basically created scripts to the extent that let's say the peer upgrade process and whatever could have been done, they got executed in a script flow and all the validations were done, whether each and every process have happened and then it went so. I would say that we have to do an automation to the extent possible, reduce the scope of manual errors that could happen, practice it and then execute it on the production. And I think specifically in the case which you are referring, it would also be ideal that we follow a strategy where data is made available during the upgrade process. And I would strongly recommend that the backup is taken and you should consider that there could be problems coming in and we should be able to stay in the current version. And we should not be in a situation that we are not able to run the current version once we start the upgrade and there are problems in the upgrade. So all the risk factors would be identified and the proper steps would be taken and automation should be done to the extent possible. So that would be my recommendation. Is that an app registry that also in a blockchain whether it will be helpful for that? Application registry? Yes, because when we work for interoperability that is the different project developers maybe from the future also they will they can access the blockchain data. That's why I think that the registry, that app registry that also in a blockchain I think it will work out better. Well, I'm not able to follow what is app registry that could be very specific to your application. Thank you, Jayakar. We'll give you their contact information where you can follow up with more questions later on. Thank you. Yeah, definitely we'll be happy to have. Please feel free to continue Mohit with the presentation. Okay. Mohit, are you going to also talk about the common challenges the next section? Yes. We'll just let you roll it right into it. That's what I get to use information. Yeah, so this is one of a very important point. Sometimes as part of a downtime strategy we tend to do multiple things because the IT team and the business team that we are getting into an upgrade so let's do multiple tasks at the same time so that on a single downtime we could complete the pending tasks. One of those could be upgrading. I won't say upgrading the consensus but changing the consensus or migrating the consensus, for example, Kafka to wrap. So definitely we will not recommend that you perform both the tasks together. If the recommended consensus, the default consensus from 2.2 is wrapped it's quite likely that the applications which have been deployed on 1.4 could be running on either Kafka or wrap. So if you are on Kafka, if you want to move it to wrap so let's perform that first or maybe you can plan that later in whichever manner which suits you but let's avoid doing both of them together because this is equally complex in nature so it's best avoided to perform them in a sequence. Yeah, so it's common that when we have basically set up the IT systems for example in a dockerized environment we could have scheduled backups of the virtual machines or the docker data or in Kubernetes, managed Kubernetes services we could have used certain tools basically to take the backup of all the containers. However, before going for an upgrade it's very important that don't rely that we have the backups already taken as a good starting point it's always good to either use this backup to create your test system where you want to first validate the upgrade process or basically validate them that the network is coming up and all your application functionality is working with the existing network which is basically created by restoring the spectrum How do we handle that if they don't interfere with the live system it's another challenge but it's important that we validate this data by restoring them and also performing certain transactions on it so we are very sure that the backups are going to work in case of any failures in our upgrade process and this is a very mixed issue I would say because it is not related to just an upgrade failure but this happens when part of your network for example out of six members four of the members have successfully upgraded whereas two of them have got certain issues and the policies for your channel and the chain code were such that four members could basically endorse a transaction or the endorsement policy allowed them now in such case what could happen is you would have gone ahead with your blockchain new blocks have got added and two of the members have basically not upgraded now we have no choice right we have to just figure out how to upgrade the two organizations which fail to upgrade we will not be able to basically roll back this for because you would have done some real logical transactions and it would not be possible to in general we cannot delete it we should not be deleting any blocks because they are live transactions it would be connected with your life systems so once the upgrade have happened ideally we should be validating transactions from all the members that all of the members are able to perform transactions so best way is to basically ensure that all of them approve a new chain code so you will know that the life cycle the new life cycle is basically working and each member have got adapted to the new life cycle flow and after that we could perform transactions perform some transactions in such a way that all the party performs certain transactions so then you would be very sure that yes all the members have got upgraded and then we could continue to perform newer transactions yeah so this is this issue is very specific to deployments which are executed on managed Kubernetes service for non-managed Kubernetes service as well so from if I remember from 1.20 Kubernetes is basically not going to support the Docker and Docker support where Docker is able to create new Docker images and this have a PRR executing chain code by themselves they are when we deploy a chain code PRR is able to create a new Docker image and start the it's not going to once we move to this Kubernetes version so the only way is basically create external chain code support and we need to test them as well and once we get into acting I'm Rohit we're having a little bit of issues with your audio we're going to create six external chain code containers or we are going to share them and how do we perform mutual TLS security or shall we use chain code as a service those things will come but initially the recommendation would be basically to have at least one or two chain code services and ensure they are only getting executed by the member organization not by the other member organization and test it thoroughly because once we upgrade let's say a Kubernetes cluster it would be very tough because you will have different challenges shall we work on the Kubernetes side to downgrade or we work on hyperledger brawl back to the old version so that would add up to the complication so it's very important if your deployment is on Kubernetes and your plans are basically to upgrade Kubernetes to the latest version so sooner or later it's going to happen so it's better that the architecture and the testing is properly done on the external chain code side of it yes hey Mohit why don't you go off video because your audio is cracking up on just a little bit okay okay is it better now? yeah thank you yeah and the other thing is once the network is upgraded it would be good if for the first few days we observe it in terms of the logs are there any inconsistencies are the logs piling up so that would be good to do and I think after a week or so it's fine then I think we are good to go and we have successfully upgraded the network and maybe one more point I would like to highlight here the upgrade of Hyperledger Fabric 2.2 is not just on the the binaries we also have needs to upgrade the channel so there is something called the channel capability which needs to be upgraded from 1.4 to 2.2 and the important thing to consider is if we have multiple channels this have to be done multiple times so if we have let's say four channels this upgrade of the channel capability have to be done four times if we have let's say N number of chain codes N number of channels then the life cycle of each chain code have to be planned all of them have to be deployed and confirmed using the new life cycle that's also an important so it might be relevant for projects which have a lot of chain codes let of channel and it would be good if we basically define a strategy certain automation so that those things are minimized yes Thanks Mohit so where we go here okay so next up I'm going to have Karthik talk about the the ARM template that's available on Microsoft Marketplace this is a free resource that you can download and look at obviously if you have any questions implementing you can call us so Karthik Hi guys, am I audible? Yes, yes you are Okay do you want my video on or should I continue without the video? It's okay if you don't have a video Okay fine now okay then I'll just stop so the the main reason behind this webinar is to explain how the upgradation process is consequential to our existing setup so what we have identified is there is an inflection point at this point in time I mean the on one side the orchestration technology and the containerization technology is improving rapidly you're having co-binators evolution happening and you're getting new new releases coming in with extra powerful features similarly you're getting hyper ledger features which are getting improved divided so for us developers who started working on hyper ledger either 0.4, 0.6 or maybe 1.4 we have seen a lot of features and we have worked with them but at this point in time what has happened when it switched off to 2.0 and then 2.2, 2.4 is that the lifecycle of the entire process has been improved it has been democratized further so anytime you make a change to something everybody who's participating in the network should come into consensus the policy which is getting enforced in the network is reliant on all the participants so that is the situation that has come up happened in 2.0 and the releases which came after that similar to that the cobinators evolution has reached version 23 and they have announced that there is no support for internal talk around time for any cobinators version that's going to be coming out further so we decided to select this topic for the seminar after we figured that Microsoft AKS which was providing versions from 1.15 to 1.18 was moving on from 1.18 and it was going towards 1.19, 1.20, 1.2, 1.8 AC plus among these releases there was a huge fault where the talk around time was not being made available any longer so the existing production systems which were relying on the talk around time and the production systems which were running on 1.4 faced a mammoth task of upgrading the cluster infrastructure as well as the Hyperledger fabric protocol due to their closing dates so since the new release dates are being announced for newer versions we had to find a way where we can accomplish both the tasks so that was the whole agenda behind the presentation so we identified few problems, we identified the consequences we have just given you few steps to think, to remember that you should be addressing these for example, the 5 things to remember when you are trying to upgrade Microsoft explained all the 5 points very clearly to you the main thing is the data backup most of the time you take the data backup but you really now focus on the channel capabilities or any other artifact related information so you need to be very careful when you are doing each and every step in the strategy which you are going to create before you try something new it's always good to have a test drive so that was the whole idea behind creating an ARM template on Azure so we decided there are many people who would like to play around with Hyperledger 2.2 before they move on to 2.2 because there are consequential changes with the lifecycle maybe with the consensus mechanism maybe with the private data collection with many things to have a test drive be created infrastructure as code offering on Azure marketplace with the name Cripsy ARM template for Azure or deployer of Hyperledger Fabric version 2.2 and above so you can try this out anytime you can go on to Azure you can try the template it's free you can have the template installed in your tenant ID in your client and then you can have a test drive of Hyperledger if the application is succeeding all the parameters which you have identified for the application then go ahead please upgrade your application so the process of upgradation is very well documented by Hyperledger foundation and you can take a few advices which you might have learned today now what is there in the template so I'll explain what you get from the template so the concept or the design behind the template is to create two separate clusters an order organization and the peer organization so the template by default it comes with a peer cluster of two peers and an order organization of I think three orders or five it depends on the raft the formula which you are adopting so how do you use the template that's the next question you move on to Azure marketplace you select the template you click on try it now then you have to feed in some information you feed in information regarding your Fabric CA or the admin name the admin password you feed in information regarding the cluster the type of clusters which are allowed or this type of VMs which are allowed to constitute your cluster is already given in a drop-down you can easily select it you can provide the cluster information you can provide the CI information you can provide the organization information so in this part you have to select if you want to create a peer or an order organization so you can start with creating a peer organization then you complete the cluster creation follow through the process once the cluster is available with peer running in it you can come back to the same offer again and then create another where an order organization will be created with the number of orders which are specified and the order organization details which are fed into the user interface so at this point of time you are left with two clusters which are together constitute your original Hyperlegion network so you have the peer you have the order then how do you use it so we have a GitHub profile we have given step-by-step guidance on how to use the template how to use the clusters, how to interact with them how to create a channel, how to join a channel so this many operations can be done by following the instructions which we have provided on the GitHub page plus there are two major things which are coming in this ARM template which we have provided first thing is the peer image the peer image is coming customized to support the external chain code feature so in general if you are using Hyperlegion original 2.2 images you are downloading and then you are running it in a docker container or maybe you are getting some other way you are getting it by a hem charts you are installing it in your cluster however it is it's coming in factory made as in it doesn't support external chain code as it is the peer binary has to be rebuilt the peer binary has to be reinstalled the peer binary has to be fed into a network again so this process we have taken care of for you you can just try out the external chain code feature only if you details need to change you just have to mention the connection profile the metadata profile inside try in your chain code and then you can test your external chain code out in the network so the second feature I wanted to refer to is the fabric go-client image so in general you use peer commands to execute and then test out your network that's how Hyperlegion Fabric admin really operates we have created a custom version of Fabric go-client which is again provided by the Hyperlegion Foundation thanks to you guys so we have used the Fabric go-client we built an image we have kept it in an open repository so you can use the Fabric go-client to interact with your cluster and channel it will give you a much more easier way to interact with the channel or the organization or anything you are creating so this is what we have in stock in the ARM template so anybody can try it out if you have an Azure account of course so these step-by-step guidance like I have explained it's available in the GitHub profile if you guys want we will share the link here in the chat window or can somebody get them the GitHub link so that's all I got to say in this it deploys Fabric 2.2 and we will be maintaining the same offer we will increase or improve it anytime a new offer is coming in so this will be your starting point where you can try out 2.2 try your application in this see if it is working see if you are finding some struggle understand where all the changes have to be made in your application in order to support 2.2 version then you start planning your movement from 1.4 to 2.2 so just consider it as a step-by-step upgradation plan so you can formalize your strategy around this you can try this out and I think the references are here for the things which I was making discussion on so you can find render support for Fabulage of Fabric is available here the template link is available here and then yeah so that's where you can find the template and I think we will give you the top page link too because it will help you further your understanding of Fabulage of Fabric so yeah that's where you can start you have any queries any problems you can reach out to us we are always there I think Chris can take over now thank you Karthik and thanks again Mohit I know it's really late for you guys so I appreciate you guys taking the time to jump on the call so we have about 10 minutes left if there's any questions in the chat let me see here I don't see anything Karen do you want to open it up for questions or yeah if anybody wants to use this time with Cripsy to ask any questions before we wrap up just feel free to raise your hand or type it in the Q&A box or the chat I will also check the YouTube live page so anyone if you're on YouTube right now watching live you can post in that chat box there as well I should also point out when it says need help you can contact me I will not be providing any of said help I will have to get you in touch with the people that can answer the questions so I got the critical link with me I'll just drop it in the panel I guess the chat yeah that would be great if you could put that in the chat and I will share it with everybody here thank you Vincent is asking a question what challenges have you encountered interfacing with government defense government or defense customers to find use cases sort of a more general question is that something that Chris you could take I think Mohit can answer do you work with government in public sector so yeah we have done few projects in public sector so we can only relate to the ones which we have done here so it may not be uniform across the globe so first thing is the timing of course so it takes a very long time for the project to pick off even though it's not relevant to the technology itself that's one big challenge which we have to go through all the time second thing it's all about data localization rules which are coming in so anytime you have to address something like this you need to go through a plethora of security concerns and then the data localization rules which are government or which country you are addressing to we had I mean we did manage to do this I mean thanks to the cloud ecosystem which is like working around the clock to make sure that you have regions available wherever you can so that has helped us a lot and there is this intrinsic feel of blockchain maybe providing a problem towards the privacy of data that's coming in so we had to like talk people into understanding how the enterprise and the permission ledgers work so that was another problem which we addressed so these are just very basic things and if Mohit can add something else I think that will be it other than that majorly we face these questions other than that I don't see anything else yes so just to add to Karthik's thing what Karthik said the few other challenges could be specifically related to security how is the data secured and how are basically the keys right when we do a transaction there are private keys and certificates where they are stored how they are secured how do we maintain so one of the very important aspect of the hyperlogy fabric ecosystem is for example the fabric where you are able to manage the life cycle of identities in general I have seen that not most people are talking about posting certificate revocation list to the channels so what happens if an identity is revoked so how do we ensure that you are not able to perform the transactions so those things have to be well documented well articulated well explained because it's not just the transactions because generally sectors which are not from the above to the queries would be more related to what is the scalability what is the performance here also those things are valid but security is equally important not just the data localization which Karthik mentioned that is obviously an important factor but how the transactions are secured how do we ensure that somebody else is not able to do the transaction on my behalf or if a person leaves a company is not able to perform the transaction can we integrate with let's say identity provider and use a proxy ID to perform all the transactions in certain blockchain applications you will have multiple IDs who are performing the transactions whereas if you had a privacy control you would basically have just one identity from an MSP and the actual identities would be coming at your upper layer and you need to maintain a log of all the details basically which person from your let's say identity provider active direct etc who have done the transaction how it relates to the actual identity on the blockchain there will be a lot of firewalls DMZ all those things have to be considered it's hyper ledger fabric ecosystem is definitely the most important part of the deployment but how all the systems integrate with the blockchain network becomes much more important in this scenario and there could be times like are we using an algorithm what is the algorithm and what are the options we have such are the challenges specifically when it is related to defense as well Thank you so much Mohit I will just take the screen now just to wrap it up thank you so much Chris, Kartik and Mohit for a really informative session they said they are available for any other questions that you have for them you will find the slides on the page for this event we do this twice a month our member webinars coming up we have Previci talking about verifiable credentials and Oracle on August 18th and Oracle talking about tokenization hyper ledger fabric on September 8th so please be sure to sign up for those we also have so much more content if you are looking to learn more about use cases or dive into more technical sessions we have a webinar page on our website and also we had our global forum in June and you can find all the sessions from the global forum on our YouTube page as well there is a playlist there that you can browse so I encourage you to go there and I encourage you to get involved we have a number of channels at hyper ledger we have a number of working groups special interest groups if you are looking to ask questions when you are struggling with implementation I invite you to go to the chat.hyperledger.org where you can jump right into the open source community of each of our technologies and help with getting some of your questions answered and we look forward to seeing you here with us next time thank you so much for joining us have a great day thank you everybody