Exploring the Relationships Between a Blockchain Reference Architecture, Design Patterns and Governance
Dec 21, 2018
Our CTO Mohan Venkataraman and SVP Isaac Kunkel spent the past week at the Hyperledger Global Forum in Switzerland. They talked about different reference architectures, technical and business patterns, and consortium building and governance from their experience at Chainyard.
If you are interested in blockchain and our work, we would love to hear from you.
Watch our presentation and come learn with us.
We’ve provided a transcript below!
We’ve seen all of these things coming together in projects that we've been working on over the last three years and so this is pretty much a survey of what we've learned what we've done and what we've coalesced into into these slides today. A little bit about Chainyard as I said we're based in North Carolina, we're about 50 people now 80 percent in North Carolina 20 percent. In Hyderabad India we have deep expertise and blockchain specifically we’ve been working with fabrics since its inception. We were fortunate enough to partner with IBM in the early days of the beginning of the hyper laser project and we came into the labs with them to help them to start with building their their CI CD pipeline to put out the quarterly releases. Obviously it took a while to get the quarterly releases that started last year happy to say that 1.4 was released today. We do focus on permission blockchains, we often get asked about crypto ideas we tend to give to people's our opinions and thoughts on that but the projects we've done over the last three has evolved in based on permission blockchains we specifically focus on the value that we believe blockchain will bring to enterprises as we continue to move forward all right um we have done some work in the theory 'm as well much of that has been in the government sector and we've studied quorum and corta alongside those we think all of those will tend to dominate going forward and that's why we you know we've put some effort into all of those we've worked on a variety of platforms and in industries but the ones that we focus on and and invest in our supply chains. You’ve seen an awful lot of those use cases over the last two days in manufacturing and transportation specifically is where we focused we are hyperledger members and active contributors we also are members of data which is blockchain in Transport Alliance which has over 400 members so in the transportation industry we're seeing a lot of traction as well an interest in blockchain and we understand that much of that's because of the tremendous potential under supply chains and we have expertise in consortium building and setting up governance and you'll see some of that in the reference architectures today and the reason we can say we have expertise in that is we've worked on three projects that are have moved to product status. They’re all in their early stages of beta but a lot of the work that we've done over the last two years has been working on building this consortiums talking to people inviting them in finding the value for all the stakeholders and then putting governance models in place I'm happy to say that within the next quarter you'll hear a product that we're launching in the supply chain space called Trust Your Supplier and we've you know the last year has been tremendous amount of nothing but the the governance side the consortium billing side the original prototype was done over a year ago so as I know that we have a lot to go through Mohan is going to go through most of it at the end I will come back to the business patterns I do want to say these slides should be available for download if they're not we're happy to share them with you and you can ask questions at the end we hope to have a few minutes for that or you can see us afterwards I got it So good evening everyone I'm really very happy to be here to see such a big crowd it is a little bit intimidating for me but let's fight let's see how I can do a good job here so what we have done is like project after project we learned the hard way as Isaac said you know I have 14 you know consultants in IBM blockchain labs all they do is test the fabric before it goes into the community and along with that we learned a lot of stuff like the first project we started without a participant in the network for a customer and it turned out to be very difficult for us to take it to production because new members would refuse to join because they thought the first member it's all very proprietary to the first member so we learned that in the next project we learned that we have to have at least two members in the consortium before the project really can take off successfully and that's a pattern we continued and as Isaac says you know like a lot of this is based on our learnings we can quickly put together solutions for our customers and I'm sharing our knowledge with you all and and I hope it is beneficial the methodology or the approach that we follow may apply to you it may not apply to you as well or it may be a modified approach that suits you. So one of the first things that we said when we set out to build solutions and whatever we built today is we said we applied a set of core principles we said like we will build only on fabric so that's all chosen platform if not if the customers choice is Etherium we will do that the second is we do want to utilize Identity and Access Management it is easy to read I'm just gonna skim through this but we set up a set of what do you call core principles into any application that we are going to design in whether it's Etherium or whether it is fabric so we laid this out but most of the experience from Etherium has been distilled into the fabric space so that's so if I move on to the next one I have 45 slides I want to see how I can pace it nicely so the first thing is like what we did is like whatever we learnt we we learned that in order to enable a customer we have to follow a very orderly pattern of analyzing the business case of identifying the opportunity and then from that point onwards how do I take that opportunity to a strategy and an implementation so we started with the blocks in reference model and so it helped us a lot and then we figured that when our product is going into production the consortium became the biggest issue meaning like customer you know that the contractual agreements with the legal lawyers on both sides and then finer details of what we should do and what we should not do who owns the court so we went into governance and we said these are the steps we need to do in order to establish governance but then when we were doing governance one of the parties said like have you done code scanning security scanning how are we sure that the network that you have built is actually secure so we said okay let's hire an outside company to do a security analysis of our solution and there came a security deployment model and then from that point onwards it's like it's not blockchain alone there are many participants in this network whether it is SAP, Arriba they are all part of the ecosystem of a solution so we need to know end-to-end system architecture and when we got all this together. I had to train our analyst what they do so we we said this is an analysis reference model that the analysts can go and work with our customers so let's warn to the very first one. You know this is the simplest representation of a reference of a reference model it looks at the business the user the blockchain and the application and other services that need to be in the ecosystem and what it help does is it provides us a logical path to decompose the entire entire customer issue into very easy to understand what pieces do we need to actually analyze and develop and code so we understood fabric where you and then we learned that your organizations organizations should have peers so we laid this this is a very high-level piece and the next slide is going to be a little intense Let’s see what it says okay so this is our reference model okay when we go to a customer okay what you can see is on the top you see that we have to do the business analysis thoroughly like you have to have a business model we learned that you can't go with the technology and then later on try to figure the business model we made that mistake in one of the projects and then later on trying to justify what the business model is so you had to work through the business model the current and target process the business transformation where you are versus where you want to go along with your ecosystem business participants you had to work through and then you have to download the business case because one of the you know one of the problems we have seen as if we don't define the business case very clearly there is a tendency to do what we build today into a blockchain solution and it becomes like a transactional system like anything else that we have screwed up in the past so we have to know what the opportunities and from there the business architecture and then take on how do I design and deliver this right so that's very first in our in our model our business analyst work through a design thinking process with the customer with all the stakeholders and then we lay this out once it is done you know the next step in us is to find who the users of the system are now there's a composer model which says you need to know the participants but what we noticed is there are business participants which are organizations for example in some of a Cisco metalife chevron they're all members of a particular network we potentially will build but then we have to understand who those participants are and then whether they want to really be part of the network as a as a node operating user or an extra so we have to understand who the participants are we then focus on technical participants you know so in some of the solutions that we built a node operator need not necessarily be an organization you know what we noticed is that we could have a technical node which can do things like management or analytics or anything else you know even key management so because those are not owned by any specific organization but they are part of the network so the solution as we expanded and we talked to many architects we found that there are peers some of the some of the organizations and their peers our business participants and some of them are technical participants in the same network and then we looked at other users you know there are you know system and human users so there are users who are systems there are human users and then there are passive users are external like in the solution we build there could be an auditor who has nothing to do with the blockchain but is an adviser and sometimes uses the application and so they need credentials so are there you know active users versus passive users who are they you know internal and external human then governance members so there could be governance members in the network we build they have nothing to do with the blockchain but they may be investors they may have voting powers so that other members who need credentials on the network then go on into roles and responsibilities for each one and what is their access control mechanisms and the next one we I'm dwelling a little bit longer on this but then the rest of it I will move a little faster but you know on the blockchain side you know we have to look at all the assets that we do you know the model technically what transactions are we dealing with what kind of events the system has to generate then information management right what is the information model you know like what is the data that I'm gonna store on the chain what are the data that I'm going to store off chain what is the data that has to be private etc etc like what is confidential so that whole analysis then we look at all the contracts that we need to build the contract templates so we learned that in Etherium I could have contract templates and I could dynamically fire a contract at runtime so we said like let's see how to do that so you know reference model we have contract templates and we use that then business rules you have to know all the business rules that need to be implemented on the contract or off contract and then you go down you know what are the policies policies are universally applicable like passwords are to be changed every as so often our credentials are to be changed every so often so what policies are there and then in the network look at audit and compliance so many of the projects we have done they involve audit and compliance show me your transaction history show me what kind of audits have you implemented can you prove to me so and so so are there any audit and compliance requirements then look at Oracle's and integration so there are solutions in which we actually communicate with external Oracle's which might be things like you know exchange rates or that could be integrations like si P Arriba Salesforce some of which we have done so what kind of integrations are required so an enterprise solution is not just a blockchain self-contained you have to talk to a bigger ecosystem then tokenization in one of the solutions we are doing actually it's a hyper ledger project but we learned how to organization works with ERC 20 and so on and so forth so in the solution you know tys trust your supplier we actually issue credits of you know credits in the form of ERC 20 tokens that we implemented on top of hyper ledger so that we can issue credits to verifiers and others and that's so we learned that organization has to be analyzed properly what kind of tokens are they are the asset tokens utility tokens crypto tokens and then last but not least documents what documents do I need to save as part of my architecture you know if that is an invoice do I need a copy of the invoice toward externally a hash of that document physical document on the chain so this is like a complete analysis of what all I need to do in order to build a full solution and Finally you is you know in every application everybody loves our UI if they don't know what is happening behind the scene and so we increasingly noted that UI UX expertise is essential for all the apps that we have developed so there's a presentation layer and then there's mobile Ouya you know mobile UI and then there is the application components because an application talks to the blockchain but it also talks to other pieces so if you take this this is the core of our reference in order to build anything we need to do this level of analysis at the bottom you can see a lot of other pieces like you know what is the pieces in the block that I need to have then there is you know what kind of API services and integrations I have to provide these are platform services like if I do AWS we are licensing AWS services like key management and so on and so forth so what are the things on the platform that I really need to license some of it is self-explanatory but we spent a lot of time looking at what is what HSM technologies are available because the customer is very cost-conscious so we did a lot of evaluations so we realized that in our platform we need to consider what kind of HSM and key management services that we need to utilize you can move on to the other areas you can see what is my off chain storage technology going to be what is my document storage technology going to be what is my application and analytics engine because the solution we develop has got an integration into an analytics engine so whether we use Watson or whether I use tensorflow what does a customer prefer and then on the right block in the complete side we actually built reusable components because every project I have login I have session management I have crypto encryption decryption so this whole set we built pre-built components so that when I go to a customer some of these things I don't have to keep reinventing so we focus on the business aspects and then we use our pre-built components and then we figure out platform services what do we need and then at the bottom most layer is some of our solutions are implemented on IBP some of them are in Azure and some of them are on AWS so we look at the platform services based on the customer so this is like kind of our starting reference model for blockchain solutions and that's what we use when we go to a customer on the right side you can see other things like you know what kind of tools we will use what is our you know development environment going to be what kind of you know system management tools so on and so so with this you know what I'm gonna do is I'm gonna shift to the next one which is like we learned that we had to build a consortium and you know we started off early trying to figure out what is consortium building mean you know so and realize that when our foot when our first product is going out we got to work with a variety of lawyers and everything is like a homeowner's association if you work if you live in the United States my neighborhood has a homeowner's association there are bylaws there are rules and I have to behave according to the rules that the homeowners association has put together they treat all of us as consortium members right so we use the same principles and we noted that first thing in building consortiums is you have to have your bylaws or articles of engagement between all your participants so there are investors who want to invest in your solution and then there are consortium members who actually want to be a member of your consortium so at the top we have like governance processes governance structure financial model and incentive model is the high level components at the bottom we have technical components so right now we are negotiating what is the service level agreements how you know what is your disaster recovery how are you going to support me if there is a bug what is your ticketing system these are the issues that are common in traditional applications we are facing that with our own product and even with the solutions that we have supported so we came up with let's see what are the different pieces that we need to do right so we looked at it's a governance process you know I need to have workflow you know so suppose a new member wants to join the consortium and the existing members have a process right fill up this form you get you know you know we have to verify the credentials of the new member who wants to join the consortium bead and organization we then how to issue them credentials we have to issue them you know like you know how do we enroll them you know how do we activate them on the network so on and so forth so there's this whole membership model then there's governance structure you know who are the members of the network what are their voting powers you know which members what are their roles and responsibilities on this on this governance team what are their voting authorities what are the segregation of duties so our lawyer was asking is all the questions actually when we were sitting with them a couple of weeks ago he's like the guy who developed the court does he have access to github there's a person who had access to github you know most of the three you know he was questioning us on all of things and so we looked at segregation of duties then financial model you know there's so many POCs built but there is no financial model who is going to pay for the network you know how is the revenue that you collect on the network being going to be distributed how are you going to collect the revenues what kind of tokens are you going to issue so we we you know went through the process and listed that this is something essential when we look at governance and then on the right side you see technical operations management how do I ensure SLA so they SLA that one of the consortium members who wants to join our network said I want ninety-nine point nine nine nine three nines right so we then so in order to meet that SLA we have to figure out whether we have the right number of nodes whether if in one load goes down will the other node be affected what is their transaction through point to guarantee on an average 99.999% quality of service so configuration management issue management you know disaster recovery account management service management these are all like standard items on operations management then standards and guidelines you know like when somebody wants to put a new contract into their network then are there any standards and guidelines that they need to follow what are the infrastructure policies suppose I want to bring my own node into the network and I want to bring my own server is there any guidelines in terms of what should be its sizing what should be the memory what should you know stuff like what should be installed on it what should not be installed so those are all considerations on standards and guidelines then we look at audit and controls what kind of audits are there you know like there are artists for Sox compliant that is artists for regular HIPPA compliance or what are the other things and do we have any tools that can detect malicious behavior or you know non-compliance and finally change management it's very essential because in the initial stages we are releasing 1.1 1.1 11.1 2 into the environment because there's a lot of change as testers come in and they're testing our solution so how do you manage all these changes you know so we have governance contracts in some of the solutions we built we built contracts that are not directly impacting the solution but their governance car there are smart contracts that sit in front of the application contracts run on the blockchain and ensure that governance aspects are happening and then smart contracts itself Sochi how do you manage that the smart contracts and as well as your regular contracts who do who does who has to sign off on it have all the parties agreed to it you know can I deploy it now so those are the other aspects okay so this is like a there we notice that that big model cannot be done on one day so when we worked with one of the projects we had to time it so what do I do you know this is very important in the solutions you build it is a case by case in some solutions you may do all of it some of it is very important and some of it is not so what do we build in the first three months and what do we do you know what do we do before before we go into production we should have the articles of engagement and we should have the network operations and other things taken care of like what is your support model you know and what is your operations team going to look like what is their operations procedures those are all before you go into production but once you go into production what would you do in the first three months what should you have in place in the next six months and what should you have in there is 12 to 24 month period so this is what it lays out skipping to the next one I'm going to skip this a little bit but what I'm going to say is when we looked at security our lawyers and the security audit company started a question as like who are the officers in your company what kind of authority they have you know are they all like have they all signed NDA documents with the with a company have you had an NDA with the network participants so they started to question us in all different directions so we said like let us look at everything that needs to be really looked at in terms of security so you have to have insider threat is the biggest threat in in the network and so you know we have to when your lawyer works with you or when you're working with your consortium members you got to look at who are your key threats it's mainly insider threats a guy who knows the smart contracts very well is the biggest threat so you have to have things in place look at whether your use of security is in place how are you managing your keys you know do your keys leave out so I did some of the work for the US federal government and so they have NIST standards and then when I was talking with the NIST you know consultant he was saying like new yorkese ever leave how long are they in memory so because these measuring the window of time when the keys can be in memory and can somebody steal it so he's asking me questions like how are you securing it so that there is no man-in-the-middle attacks so we said like let us look at how how are we securing the keys are the keys ever leaving a container and coming out or are we sending the encrypted encryption and decryption functions into the you know into the into the key management service tokens how are you securing your tokens how are you securing you know your databases off chain on chains so there was a big question like where is your data store you know if you do gdpr you know and there are certain rules that I learnt is like certain countries want the data to be in the nodes that are in their country specific data center so that you would face and then how are you securing them so that was you know on you know off chain data especially your configuration files you know if you look at fabric or even if you look at its helium networks there are so many configuration files and there are other files that you need to secure then how are you securing an application because that is user facing you know what kind of controls have you put in place and finally how are you securing your smart contracts you know are they exposed who all have authorization which ports are they running on are the endpoints visible I you know so those are kind of things that we had to go through and finally you know if you are to put your entire solution together you have to look at the big picture right so blockchain is only one end of the spectrum but my clients would like to connect to the blockchain using their own clients that they weren't a design or they would like to use clients that we specifically give them you know if I work with large customers they want they want the API layer so that they can integrate it into their photos if I work with small customers they weren't the UI that we have customized and given it to them so you got to look at how are you exposing your API and in which languages are they available and then what is the UI UX taken going to be and messaging so a lot of our solutions use micro services you know like if I'm exposing s ap services I'm using micro services as a way of exposing functions to the blockchain network or to our application and finally on the extreme left is like how am i connecting to s AP in a secure manner how am i connecting to Arriba how am I connected Salesforce how am i connecting to anything else that's an enterprise apps that kind of like tells us you know what we really build our solutions on and this little piece tells us like this is our blockchain reference architecture for doing analysis and we already covered this before so and this is a piece of the reference architecture that our business analysts go and we have detailed X on what we actually asked questions when we work when our analysts work with the business participants like in the business model we have a series of 14 questions similarly you know when you study the organization's we ask questions like are they going to operate a node not operate a node if they are operating a node between two organizations do they need a secure channel non secure channels a lot of things I'm going to move into I do not know the time check got 15 more minutes so let us see design patterns you know so one of the biggest things in a fabric its fabric gives you so many features that sometimes you could get lost right so one of the things is like you know where do I store my data you know this is a common question in every application that gets asked and then like how do I you know how many chain code should I have multiple chain codes on a single channel or should I spread the chain codes into multiple channels you know how many channels should I have between two nodes you can do all kinds of things in fabric and you can get completely lost a real complicated fabric solution can be multiple nodes multiple chain cause multiple channels between the same two nodes in fact in one of the solution there were multiple channels between inside the same node it was like a closed loop channel one channel two so that we could isolate out the ledger storage there are cases that I've come across so we have and then how do we design and court the solution and then we have faced now as the network expands in fabric and a new participant wants to come but they want to expand the network on their side but not be part of this portion of the network because in fabric a channel is like a private blockchain and you can have many private blockchains on the same network and they won't all be isolated but communicate as needed and last but not the least the business patterns so let us see what we did in in in data design patterns so when we started to analyze and many of the projects we noticed that there is data that goes into a public ledger that every member of the network wants to see transparent there are channels in which there is privacy between two parties on the network they are public but they are only visible to those two parties then we have like private information okay where do I store private information that is very specific to a particular organization and then there is confidential information that needs to be encrypted and finally there is like off chain information like for example GDP our data cannot be on the Block scenes though and there are also application specific information that drives your blocks in solution so how do we store so we came up with a very simple way of looking at it what we said is like you know if I have three parties right organization one two three and all the data is public then I need a single channel between all of them reading from left to right one collection it's all the data is public and so I have three organizations or one in our three peers then I would put them all on a single Channel now if our collection - where do r1 and r2 share public data and r3 r4 then I would have two channels between between the organization's so I mean this is kind of like a decomposition of our decision tree if I have something that is where let us say Prai you know that is partially private right and then I have collections that are like confidential that it could be confidential data purely confidential confidential data that actually sits on the ledger in that case I have to use encryption in fabric you can use techniques like sending transient I know you can use transient data to go into the block you know as and you can send the keys in and you can have your actual payload coming through another channel so you can do all these things if it is private in fabric you can use site DB so I can use all these multiple methods by which I can feed the data if I use the keys on the payload itself then it'll be visible on the ledger so you don't want that so how do I do that and then so finally you have like site DB because the data is private secure Keys uses it very effectively and we have used it in some trade finance applications I do not want to know how much I bid on it but it is private to me between me and my party but I do not want to expose my coat in trade finance right the suppliers invoice you know the buyers invoice is exposed by the supplier me gets bids from different financial institutions you if that data is very private you don't want it on the ledger the bit information then you can utilize site DB which is available in fabric so so private data on site DB and if the data is PII you know personally identifiable information then you put it off chain right so that is like kind of how we have we do our data modeling a little bit and the other thing is like channels you know you can have many channels between two parties there are many cases I'm going to just use one example in this pattern like let us say you know high availability so often it comes up you know people don't want to pay for nodes I do not know how many of you have actually costed how much your POC costs right appear if I were to use fabric and I know that well an organization cost you a thousand dollars and then a peer cost you a thousand dollars per month so technically speaking if there are two organizations two thousand dollars upfront cost and then two thousand per month so there are people there are organizations that want to invest in peers but there are some organisation one invest so I if in the first pattern I could have two peers that a particular organization hosts org one and R two has only one node but it trusts or two so if there's a failure on any of the nodes at least I have activity still going on but the still depends on how you model your endorsement policies and so on and so forth right so that way you can see high availability you know to you know both organizations don't trust each other so I have two peers on each side then the next model is like network with management peers so there are two nodes which are organizational Ledger's and then there are two management peers that can store additional ledger information like audits and others that should not be visible to all the other organizations but it is visible only to the network so you can do similar models so there are like many things like single chat you know then other things are like single channel one chain code single channel I can now change code one two and three so I can I can I use this approach when we want to you know in fabric the tendency is to write one massive chain code but technically when I worked with Etherium you could actually slice your functions into smaller bits manageable smart contracts you can do the same thing in fabric and so you can do c1 c2 c3 as multiple chain cores running on it and the beauty is that each one of those smart contracts can talk to each other and update each other's ledger if you want to separate them completely then you can have multiple channels and each one up let us say there are two organizations they use the same smart contract but they want to isolate their Ledger's out for other purposes right like then I could have multiple channels with the same chain code running on the same Channel I could also have multiple chain codes running on different channels gonna skim through this and then coding I'm going to go here and some other patterns be used if I use Etherium I can actually have all the addresses inside a registry and I can figure out at runtime which change which smart contract is running whereby the address and I can actually communicate with contracts you know I can build a registry so we in some of the projects we have multiple chain codes so I need to have an effective way of managing them so we do use a registry pattern in which but in in unlike a tinea where I can model this inside as a smart contract we model this outside on the nor J's client we have a registry contract in which every chain code what is running what is its github location is a to register there and I can actually use that model to do a runtime install a instantiation because you can instantiate chain code you know from your client so if I wanted a nut if I use the template pattern I want chain code one and I want to reinstate chain code one again I can look at the registry get a copy of the code instantiated and deployed on any channel so I can use registry patterns I can use the routing patterns if I have a workflow on my application and depending on the workflow it has to call chain code one two three four we can use the routing pattern I learnt another thing in is helium is you actually isolate our data contracts from business contracts simply because you want to actually preserve the data all the time you know sir if you do chain code you can upgrade chain codes but actually the data moves from chain code version 1.1 to 1.2 but what I learnt while doing a tedium project says you can separate our data as a separate contract it maintains all the data in the ledger and business contract only does business functions so you can isolate our data versus business that way changes in your business logic will not impact your data you know those changes and data structures can actually impact your data structures but if you are storing everything in JSON structures it doesn't really matter you can continue using this so there are some workflow patterns we came up with dynamic instantiation I said I can look at the registry and dynamically instantiate contracts we can we wrote our own contracts for governance which may you know which manages contract rules and permissions management so that as soon as a transaction comes from node SDK it hits the verifier contract which verifies if that function is executable or not and then only route set to the appropriate contract you know that is supposed to run that function you also use the adapter because in supply chain especially there is a lot of data that is common to many different contracts but you had to translate them from one format to the other so you've done some of that you know then I ran into some of the network configuration patterns right it's a very simple network everyone shows us the POC with four nodes and a single Channel right I would like but we are gone into complexities because what happened is we started that way and this is actually an actually example of a procurement application but and what happened is one of the ends of the note said I want to now expand my own network I I'm a I'm a bi am a supplier but I have affiliate suppliers I do not want to you know make visible my affiliates to you so they expand on the left and each one of them could have their own node and have separate Ledger's each affiliate could be on a separate note and have a separate channel so that they can isolate their Ledger's and so they can expand on one side or sometimes that are very small affiliates they don't wanna operate a note so they come together and then they decide that I will use Nord C as a trusted anchor and we all will trust it and so affiliates could work with a single anchor node or affiliates could have their own nodes so a couple of different ways by which we have approached as our first app we got two of our applications I've finished 24 months you know we've been working on it for 24 months since you know August of 2016 so as the network expands we have to make sure that the network can scale and expand so many of the other ones are like how does it scale and finally how will it look like this and each one can then keep expanding there so you can see it's like a truly distributed network and finally I mean in all the negotiations we have a big problem you know the customers want to know where the opportunity is we waste a tremendous amount of time three three months and I'm deals with most of the customers all the time so we said like let's come up with something all right so respecting your time I know we're right at the ED here edge here I will just do a tell you why we think the business patterns are important and then we'll all just give you the survey of them these are all things that you guys have seen read about these are ones that we've happened to have the fortune of working on as well and and you've seen tremendous examples of many of these some have multiple patterns within them I can think of every ledger trade lens IBM food trust I know all of us have multiple these patterns but everything from identity management and the work being done with sovereign and indie is great border trade is huge digital asset registry auditing compliance financial settlement system of record data and document management secure trade finance disputes and reconciliation provenance asset track and trace again nothing you haven't read about we got a little bit more detail on each of these the reason we we have these and we think they're important is when we go in and to do that analysis we're trying to make sure we're solving a problem that should be solved with blockchain we're not just trying to throw blockchain as a hammer and trying to find a problem for it to solve and that's one of the big things we going with companies and companies always almost always start with my I want to own it you know the just typical enterprises and we have to start talking to about consortium building and thinking about how to decentralize it in some way and you can still have some traditional models or the SAS models and all but you want to you want to build the trust through some descendant some centralization mechanism you want to solve data problems with solutions that solve data problems and we want to make sure that we're positioning them so if they do leverage blockchain that is solving a problem today and also positioning them for more you know features in the future so they can continue to take advantage of blockchain in other areas of their business and that's one of the reasons we we love fabric is that it is pluggable and we do know that this is very nascent technology and it's going to continue to evolve and that that pluggable nature is going to make the investment that companies do today pay off more in the future than having to throw away everything and start over each time so again you guys are having great hanging out I will we will take some questions and I'm gonna let no I think the questions and most of that information was his are there any question yes well you know so we've done several projects I'm gonna let start we do track and trace it's been 24 months we've done procurement and contingent labor that's 24 months in in going from MVP you've done seven projects for the federal government from logistics - you know secure words and stuff like that we've done what equal compliance where audit ability of you know of a manufacturer to our distributor to a end customer there are so many other examples we can use we have done trade finance so just curious can you provide some metrics on these projects like how many participants are in this consortium how many nodes they're running like how many locations in etc so you can take the biggest one for example yes so you know so our own network you know so that's the solution we are having is two nodes right now okay which is going into production we have three companies that are signed up but the thing is like before a node can operate I have to finish the memorandum of understanding and other things the legal obligations so even though there are far you know I can say one two three four five members have signed up the legal contracts before they can come on board is taking us time so that would be our own trust your supplier on the network ultimately we expect 15 nodes when all of them sign up and we will have at least 20,000 suppliers overall to begin with you know so by the end of 2019 or the first quarter of this that many we expect them to sign up as passive users they won't operate notes for I told two of the networks I showed you where I've saying scalability they started off with two nodes which means they've the procurement application especially the client and their supplier it started off too and now what happened as others have expressed interest the the the supplier said I want to expand the network to my this so we the supplier is negotiating with their suppliers they go through the same process so we know you know that that's how it is going to expand so day one it starts centralized somewhat and as the network grows that's when it gets truly decentralized so this is the teething problem in getting production networks up and running it's not like you cannot put fight I have a final network and I can put finals you know but that doesn't mean anything you know our own solution we'll have two management nodes one for analytics and one for key management and one will be the first anchor client and then the second will be us as network our and network managers and verifiers of the network and then other selection ah yeah as I was running down to I was expecting something like saxman or toga and if you such guys so when we come it when we communicate with sa P yeah you know so I'm a to have certified architect okay so some of my thought process is always toga I need to know what the business does and then how does it translate into different layers right so application information in this but then we said the blockchain is not in TOGAF yet and when we go to customers - when we saw those layers have to be understood you know the workbook includes like when we do data analysis we say is this confidential is it proprietary to organisation 1 or is common so we do the whole nine yards of analysis so that first few layers actually helps us to crystallize the solution all right but when we talk to sa P we are negotiating actually I mean like your question was that so we have to work with s a P and a civvy architects and we try to negotiate what the data is gonna be whether there's an Oracle that will be provided by them or do we create the API sand will they just most often we like to create API so REST API so that they consume it rather than having point-to-point integrations or message based integrations all right well we'll