 Hello everybody. I hope you all are having a good time. My name is Ahmed Khan. I am the Senior Technical Manager at Verizon Communications. I would like to take this opportunity to thank Hyperledger Global Forum organizers for giving us the opportunity to present our use case. Today I have my colleague and partner in crime joining all the way from India. He is sitting over there laughing with us. His name is Rangesh, joining from India to share our experiences on blockchain journey. We have a very exciting and packed topics for this session. We will start with giving you a quick overview on the use case that we have implemented. We will go with a brief summary on the pain points and how blockchain came to our rescue. We will also showcase the future state of how we have used the blockchain technology in implementing this solution. Finally, we will wrap up the session with a short Q&A. As you may all know and agree that when partners do business, there is always chances of disputes popping between them as one partner does not agree to the decisions made by the other partners. Same situation here. When we started analyzing our use case, we saw that the discrepancy that happens between the partners is regarding the payments. The payments that needs to get cleared between the partners do not get cleared because of one party do not agree to the terms and conditions laid out resulting in the disputes rather than the payment. So what happens is whenever there are disputes that are coming out of this disagreements, it results in manual labor intensive work for both of the parties to start investigating and trying to resolve it. What we have seen is that in the organizations where all in the strategy mode trying to figure out how to resolve these disputes more efficiently, faster and with higher accuracy. And it also always resulted in 100% of the time they were addressing the disputes that are coming out of this solution. It's a heavy time consuming labor intensive work on both parties as they have to tap into their enterprise systems to find the source of the truth. And just to let you know that during this time, the disputed amount which was the key that we have started, the payments that we have started, the disputed amount for both of the parties now limbo because the parties do not agree to the terms and conditions causing huge losses in the cash flow or the revenue. So what we have done is we have done the throw analysis on and went deep into the underlying problems to see what are the three key pain points that are causing disputes. The number one we found out that it was a lack of visibility of the data. The data is hidden from partners when making the key decisions. Number two, lack of trust between partners, discrepancy in understanding the way we make the decisions. Multiple versions of the truth. The data is varies between how each partner stores that data. So taking this into account, these pain points and the issues that are happening in the dispute management, we went and did the analysis using different technologies, different blockchain technologies to see how it can help to dissolve this pain points. And also how we can do that, how we can change the way we do business. Yeah, so like I mentioned, the challenge is this, when we write rules, when we write rules to resolve the dispute, the data should never be owned by a single partner. So it has to be shared. The only option that you have is you distribute, even though you distribute the data to partner, there is no guarantee that the owner is not tampering the data. So when we think about the important aspect of blockchain, it does provide sharing of data and decentralized and distributed nature. Also, it has the property of immutability. This means that if something is going to change, it will all get tracked to the blockchain. It is going to give the trust to the partner saying that, hey, if something has changed, you could always come and look into it and you could always check who changed it. Plus, one important factor is smart contract, where we had the cushion to write a shared smart contract or shared business logic and distribute to our partner. What this has led is winning of trust. So we established blockchain as technology solution for the problem that our mother clearly laid out. Number one, sharing of data and both partners should get convinced that data is stamp approved and also it is not single parties owning the data. So the only solution to all of this is blockchain and that's the reason why we choose blockchain. Now with that said, there are again different versions of blockchain. One is public, one is private, the other one is mix of both. You call that as hybrid. So this is the standard flowchart that we often use or more enterprise often use to decide whether they need blockchain or not. So this particular slide helped us to determine especially for our use case to choose private blockchain. That being, we want to do the blockchain solution in a closed manner. We don't want any other parties to get involved and we only wanted intended parties to join the network. So that is one common use case for private blockchain and that's the reason we use private blockchain. So this is this flowchart, right? You could always go back and refer to the business problems that you guys have and always go on effort here and say, do you even need a blockchain? And if you need a blockchain, you could choose either public, hybrid or private. And I just to add to that point, what we also have done is that before even we went into whether we go with the private or the hybrid, we have also done some people sees using different technologies, blockchain technologies to see if that fits the solution for us. The problems that we have laid out to be used those problems to see whether those problems can be fitted into those technologies and how technology can help to leverage and minimize the biggest endpoint that we currently have is the dispute. How we can minimize those disputes and completely remove it from the solution. So using those things, after going through those different technologies, finally, landing up into the hyperledge of fabric. So this talks about why we choose hyperledge of fabric. Even if you look at our private blockchain, there are there are many like big code up or quantum, there are there are many private blockchain that suits the need. The reason that we chose hyperledge of fabric is it is open source and we see a lot of contribution right from 2015. And this and hyperledge of fabric is tailor made for private blockchain and also it only lets people who wants to join the network and it's not open like the public blockchain. Plus as well, IDM and other major players have kicked in the hyperledge of fabric in shape. So that was also a major confidence for us to choose hyperledge of fabric. And as well, you have the concepts or notions of channels where you segregate different data corresponding to different partners. So that was one of the main reasons we chose hyperledge of fabric. Though it does not support crypto economic, I think even hyperledge of fabric is working on it and there are there are notions to introduce crypto currencies out there, but still we don't we did not really require for our use case. So hyperledge of fabric was the best private blockchain network that existed and we chose hyperledge of fabric for the solution or the business problem that earlier we mentioned. So this slide more gives you a reason why we chose hyperledge of fabric. With that said, once we had the blockchain implemented, the solutions were all together different and the results that we got out of blockchain is all together different. So I'd like to speak on this. So you heard from Rangesh about the different flowchart of how we have selected the blockchain technology and the first step was do we even need the blockchain? Second thing is what blockchain technology should be used. Finally, when we selected the hyperledge of fabric, now the main point came is in the design sessions of how we will implement the solution. As you heard in the first initial of the session that the pain points of the whole current scenario regarding the lack of visibility of the data, lack of transparency, trust and the multiple versions of truth between partners, we wanted to address those pain points for any implementation with any technology that we're doing it. And when we started finalizing the design for hyperledge of fabric, we wanted to address these key areas. The difficult, the most important part of that whole issues were regarding the data, how the data is being stored, how the data is being reviewed by each partners. So the first thing what we have done is to bring that data set onto the blockchain network. Of course, after establishing and setting up the infrastructure peer-to-peer network between us and the partners, securely connecting through the VPN channels and then exposing that data from our side as well as from the partner side so that we can view that data as a single source of truth on to the blockchain. That itself resulted in the minimization of the disputes. Second thing as what Rangesh was mentioning about the smart contracts, we worked with the different partners in writing some of the hardcore business rules agreeing upon by both the partners, by the partners and by us to see that the rules that are going to be implemented on blockchain and in addressing any of those disputes proactively should be agreed upon by the partners. Then only those rules have been implemented on the smart contracts so that now we started building the trust between each other rather than we are just disputing or rejecting those disputes based on our assumptions, based on our rules. Now, after writing those business rules jointly created, both the partners agree what is the outcome of those disputes going to be proactively or even after the disputes that are going to be created. So all of this resulted in the biggest thing is all of this resulted in reducing the disputes. If you all remember that in initial we mentioned that we wanted to get rid of the disputes or completely eliminate or reduce the disputes out of the solution. So by providing the visibility of the data by writing jointly business rules and making the blockchain as a single source of truth so that all the parties can refer to that dataset rather than looking at their specific views of the data, we have eliminated 90 or 90 plus percent of the disputes from the solution. That resulted into the improved cash flow. Till now with those 90 percent of the disputes that were stuck in the limbo, the cash flow was stuck and was not getting released. Now the revenue started coming in, cash flow was easily available because of the disputes that got resolved. The third part is that the transparency that came into picture. Initially when we were doing business with the partners, there was difficulty that there was no transparency because each partner is assuming their own version of truth. Now by putting everything onto the blockchain, making it as a single source, the transparency it came into picture. Last but not the least, we have started building the trust between the partners, which was completely gone in the BAU environment. Now by putting all of these things, the trust got established and we started doing a different way of business. Yes, so to add to Hamath's right, so with this solution, with blockchain-enabled dispute management, what we have done is, we have prevented the disputes even coming in. The reason is the data is shared, you have the smart contract well before you even raise dispute. The smart contract sitting there in the middle would always flag you saying, do you even want to raise a dispute or not. So that is one of the biggest advantages with the solutions that we implemented and blockchain was one of the main reason and then smart contract was one of the main reason that enabled us to provide such a solution. You could think about the system where partners may not even raise a dispute. The smart contract is going to collaborate for you saying, yeah, this is not even a dispute but you are raising it. So there is no point in raising it. So such kind of power block solution was achieved with blockchain. And yeah, so with this said, I will move on to the technical stack. The reason that we brought this in here is, it is important that you choose blockchain but it is equivalently important that you choose the right technical stack. All the nodes, all the network that appear out and connect should be available all the time, right? Else your transaction is going to get trade. So it is important that you choose right tech stack. So this is the tech stack that we chose and we had good success with it. So we are sharing this piece of tech stack with the team. So to get started, we use typology of fabric and then we also explored with Composer even though now Composer is depreciated, we even started using Composer before it when it was released. So we explored with all kind of stack. And then right now we are using typology of fabric, FabricCA, and then Bitta and Koush TBS database. Now when it comes to container and orchestration, it's Docker and Kubernetes hosted over AWS. So it is important you have Docker or Kubernetes running. That's because the nodes have to be available all the time. And the Docker or the ordering servers were Kafka and Zookeeper. And now onto the left, you see the cloud automation configuration. So that's AWS, Ansible and Jenkins. So these are all the standard practices that we use, but these are all the recommendations that we give, but it's not that mandatory that others use it. And now when it comes to SDK and chain code, it's NodeJS and GoLang as well. And now interesting fact is the application you guys, you know, you call that as Dapp or the frontend. And all the data that comes into the blockchain, we have a centralized place called as data ingestion layer. Now we do all the massaging of data in this centralized place, and we just keep it as neat as possible for partner to look into it. We do all kind of massaging, data massaging work with Spring Boot and Java. And we just insert that to the blockchain. With that said, that is also important aspect on the data size or the data volume. As you go and deploy the solution and production, right, the data that you see is going to get a grow proportionally with time. So we had different on chain and off chain solutions like caching or a client, you know, we really did explore few of them to make sure that we don't get hunched by data. And that is also important aspect for people who are trying to adopt blockchain in their enterprise organization. And I guess just to add one more thing here, if you notice on this slide, the right side of the slide is where it's common to both the partners for us and for any other partner when we are doing when we are implementing the Hyperlegia Fabric or this blockchain solution. On the left side that you see the cloud and the UI and other stuff can be changed, can be used by the different technologies by the partners. And in our cases, we have not only used the AWS in our implementation, but also used different hybrid versions of the cloud platform. Whereas we are on the AWS, the other parties may be on a different cloud environment. So just wanted to segregate that the right side is common to both us and partners. It has to be same. The left side can be various can have some variations between whatever the industry might that they want to choose separately. Thanks. With that said, I think we just have five more minutes. So should we take up questions? Sure, please. Go ahead. Okay. So an anonymous user has asked what is Hyperlegia Fabric in simple terms. Okay. So Hyperlegia Fabric is one of the blockchain framework that exists for you to implement blockchain solutions. So that is more suitable for private blockchain. In simple terms, Hyperlegia Fabric is a framework that enables you to implement private blockchain. Okay. I think Karthik has asked what is the rationale for selecting a framework such as Fabric or Iora, etc. What is the evaluation method that you used? Okay. That's a good question. So if I go back to my slide, so the evaluation method, there are two things Karthik. So if you look at this slide, right? So this is for us to choose either public or hybrid or private blockchain. So we decided that it is private blockchain. And like you asked, why not Kordak, why not Quorum or why not Iora or any other such private blockchain? The reason that we used Hyperlegia Fabric is that we started this way long back two and a half years before. The reason that we chose Hyperlegia Fabric is number one, we had the entire business logic, we want the entire business logic to be driven by smart contract. And Hyperlegia Fabric had Golang as one of the powerful tool to write smart contracts. When we evaluated with Kordak or any other such framework, it did have the capacity but the reason that we chose is it was more modular. And Kordak, you could not even call Kordak as a blockchain, it is a DLT. And also one important aspect is the partner's choice as well matters here. We peered out to our partner and partner should also agree to the same framework. So the reason that we used Hyperlegia Fabric was it all came out of heavy discussion that we had and we chose Hyperlegia Fabric. I'll let how much do I add in it. It's a combination. Yeah, good point to Rangesh. It's just a combination of all of the things that Rangesh mentioned. And finally, Karthik, before even we lay out or finalize what architecture, what technology that we have to use to have the blockchain implementation, then we need to have that partner alignment. This was the first step in aligning partners on agreeing upon the technology down to the level of the patches and to the versions of what we will use, what are those are the common components that we will use together. And this was one of the also aspect of agreeing upon with the partners. And I think Karthik has one more question. So he has asked, how do you manage this office up to date because in this blockchain world, in this blockchain world, things keep changing on a daily basis. Yeah, ideally, you know, but it's again, you should not see blockchain as different stack. It is just like a tool that enables you to achieve the features, right? It's again, like Java or partner framework. So as you wish, you could go ahead and upgrade it. But again, switching from one blockchain framework to other blockchain framework is not that we recommend because, you know, it is all intensive operation, you got to be in from start, right? So. And I'll look with that to Rangesh. One more thing Karthik that we have also addressed in this is not only upgrading or keeping up with the blockchain software updates, but as you know, when Rangesh mentioned that we are on the AWS platform, we also have some governing policies in the cloud environment. For example, the rehydration of the environments, every three or four months, we do the AMIs rehydration. So keeping all of this while the environment is in production is a task for itself. But yes, we are able to maintain all that hydration of the, not only the non-blocking components, but also with the blocks and comforts. Yeah. And Franklin has asked, can we replace the agreements written in natural language? Yes. So, so eventually all the agreements, here we call it as business rules. So smart contracts, you know, can be smart contract is a programming language. You could translate your business logic into business logic into boards. That is feasible. And Franklin, when we say that the smart contracts are the business logic, these were the business logic that we used to own it previously. Now what we have done is that we have created those business laws logic in agreeing upon with the partners that, hey, if it is one plus one equal to two, then both needs to agree that it is really two, not one plus one equal to 11. So that's how we wrote those business logic and deployed it onto the blockchain. So next time when any transaction that comes in and this smart contracts gets executed, both partners and us, we know that what logic has been written and how the outcome is going to be. And Dibayesh has asked us, are you able to incorporate inter-carrier SLG, service level guarantee? So how much do you want to take this? I think this is one together a different use case, right? The service level guarantee and inter-carrier SLG. Yes, we are still looking into that, Dibayesh, we have not incorporated those yet into our use case. The use case that we have done is mostly related to the agreeing upon some of the business rules on the way we have the payments or the terms of those payments that we need to pay off some of those transactions. Yeah, I think we are two minutes over the time. I think we can end this with a thank you note. Thank you so much, everybody. Thanks to Hyperledger again, Hyperledger Global Forum organizers and the moderators and all the staff that helped us to make this event successful. I appreciate all the help and thank you to the audience for putting a good lively questions and looking forward to another session. Yeah, thank you. Thank you. Thank you all. I mean, thanks for the opportunity. Thank you for all the coordination that Hyperledger fabric team has put in. And thanks for the audience as well. See you soon on the next session. Thank you. Thank you.