 Hey, morning everybody, or afternoon, or evening, or wherever it is, wherever you are. Apologies for my voice. I've got a bit of a cold from being on the plane too much. So the agenda for today is pretty jammed. So there's the hackfest planning and reminder about the hackathon this weekend, and not this weekend, next weekend. We've got a work group charter discussion, I think? I thought I saw a link in the... Yep, I'll drop it in the window at the time. Okay, yeah, okay. So we've got a work group charter discussion for requirements, and I think Oleg is on? Is that right? Hello, good morning. Then we have a quick sort of closure on the whole Slack archive repository thought. Some internship discussion on the various proposals that the subteam sort of pulled together. We've got a request to exit incubation for hyperledger fabric, and then Tomas is going to present the Global Sync Log proposal, I think, although I haven't seen a document. Tomas, are you ready for that this week as well? Yes, I am. Okay, good, good. All right, so any other items? If not, let's start with the hackfest planning. So Tom? Yep, we'll move quickly through things today. So we completed the Doodle poll. The date with the most availability for everyone is the week of April 24th. We are targeting the East Coast. We are chatting with a few different companies between Boston and New York to finalize on venue space, but it will be the week of April 24th, likely a Tuesday, Wednesday, or a Wednesday, Thursday. Hopefully we'll have something confirmed by next week so we can get people's travel plans. We're still about eight weeks out, so still have a good amount of time. Still looking at June to do a hackfest in Beijing around Linux on China. More details to come there. And if you have venue space for either of these are interested in potentially hosting, please get in touch with me as soon as possible. Thanks. Super, thank you. Okay, next up. Any questions, I guess, before we move on? Okay, so next up is Olek, and we have a link to the requirements work group proposal, charter proposal. Yes, hello everyone. This is Olek. Well, first of all, many thanks to Clive Bolton. And this is a result of about two weeks of discussion. The main point of the charter is that the requirements work group is a forum for business domain experts, architects, and technologists, where we exchange ideas, discuss requirements, and derive additional features for technologies in a hyperledger project. The requirements work group also provides recommendations to the projects. The scope of the requirements work group is mainly an inventory of requirements documents that capture specific use cases in the industries that we focus on. And a high-level list of features and recommendations that we deliver to the architecture group. We collaborate with other groups. The process of the requirements work group is that this forum is open to everyone in the hyperledger community. We run a wiki page, a rocket chat channel, and the email list. We also meet bi-weekly on the WebExco and discuss use cases and whatever the agenda. Well, that's about it. It's two pages of the charter. Everyone is free to make suggestions to it. I'll run a formal vote on this document on March 6th when we meet next time. But I think the draft is pretty much complete, and unless any other suggestions are made, we'll close it this coming Monday. Okay. So any questions or comments from TSE? Is this the draft that the working group is submitting to the TSE for approval, or is this a draft you're inviting for comments that the working group will then finalize and then come back to the TSE for final approval? Well, the second option. I don't mean to be overly bureaucratic. The TSE is what kind of approves the charter for each of the working groups. Exactly. So we'll close the draft on Monday after, you know, formally everybody votes on this in our group. And then I'll deliver it to the TSE so that TSE can make suggestions for approval and disapproval. Yeah, hopefully it can be approved next week. I think on the disbanding note at the very bottom, I see the need for this working group is kind of ongoing and persistent. You know, like there will always be new use cases worth considering. There will always be new releases of the different technology projects with an hyperledger that are worth mapping to those use cases. And so do you see it the same way? Or do you think that there's a fixed time frame for this working group? Yes, I do. I don't think that we should disband any time. I think it's the forum should be kept open. But yeah, so I'll discuss it again with our members, see if we can drop this disbanding clause. I think it's good to drop. Yeah, I tend to agree, Brian. I think this, you know, this is one of those that just sort of there's always new requirements until the technology becomes obsolete, I guess. The last one is lost and the last user is dead, right? He was tired or something. So the one comment I had was on the collaborations. I think it would be, and Brian, you know, we chatted sort of obliquely about this earlier this morning, but I think we need to figure out a way that we can engage the requirements working group with some of these sort of industry specific work groups like healthcare and others that may come down the pike. What are your thoughts on that? Well, I agree. I think that's where working groups actually overlap, the financial working group and the healthcare group. Yes, I don't know if we should. I think adding some mention of the relationship to those industry specific working groups to this charter would be nice. I don't want to overburden this group because I do want these industry specific groups starting with healthcare to also carry some weight in helping define these use cases. But if they knew that there were experts in helping craft these use cases and mapping them to the technology products at Hyperledger, and that would be great, right? So some verbiage about that connection would be nice. Yes. Hi, this is Leonard Dyer. It's been one. I think that's a great idea because there are some industries we can prioritize in terms of understanding the requirements and show that we are fully aware of what feature sets that blockchain should provide for some of these vertical industry sectors. So that's wonderful going forward. I'm sorry, Dan. Go ahead. Yeah, I was just saying if I was remembering right near the outset of Hyperledger, I think it was with this working group. It seemed there was a reluctance from some of our industry partners to provide use cases because there was a perception those were valuable as intellectual property within each company, and a lot of those use cases or requirements really weren't forthcoming. Does that feel like that's still an issue today, and is there something that we can do with updating the charter of the working group to help address that? Well, it's kind of hard to say. I mean, whatever I guess remained a secret a year later still remains a secret. But I think now we have a set of canonical use cases, perhaps what we are missing, maybe some measurements or some real numbers. That can help the requirements. I guess those two remain a secret. Dan brings up a good and interesting point, I think, and only to your point on sort of coming up with some metrics. You know, sometimes what it takes for people is to see, oh, look, this use case has been published and people are building solutions around it and they're still monetizing it and so forth, and nobody died, right? And maybe we need to be highlighting some of those things. I mean, do we want to put something in here in the charter? Or maybe is that just a function maybe of when we come across something interesting that we've got documented that someone was willing to share but yet, you know, is starting to reach, you know, achieve broad adoption or something that we can just sort of highlight that in a blog post or something just to raise awareness? I don't know, Brian, what do you think? I think it's going to be important to show a round trip eventually between the inputs into this process, you know, the definition of these use cases and requirements and ultimately at some point how one can deliver those with the technologies at Hyperledger. And it may be that you can't, you know, get it out of the box. You know, hey, we need a, you know, derivatives trading market. Well, you know, there's still some work to do building on top of any of the underlying technologies to implement that. But something that shows, okay, these use cases drove these specific requirements and those requirements were implemented as of, you know, fabric 1.0, you know, sawtooth 1.0, that sort of thing. That I think is going to incent people to create more of these, right? And to feel like their contribution was worthwhile. I think the biggest concern I'd have is this repository of use cases and requirements feels like shouting into the wind, right? So that's, I think, I think an urgent, I think that's an important thing to add to the charter to address those concerns. Hi, this is Vipin. Coming from the industry perspective, there has been movement in the direction that you desire, which is people first thought, oh, these are all intellectual property, but the point of the blockchain itself is collaboration. So we have been trying to educate the business users here internally that unless you share some of these, then you're not going to develop common solutions. That is the first thing. The second thing is in terms of the requirements workgroup, could we also add, I mean, maybe not in the charter, but in the description of the use case, any examples of, you know, like Brian was just saying, the round-trip phenomenon, any examples of actual implementations that are available in a sort of a, as a common place to go to to see how much we have progressed with implementing requirements. That's all from me. Thanks, Vipin. So we have, like I said, we have a jam-packed topic, a set of topics, I should say, agenda today. So I think this has been great input. And so if anybody else has input for Oleg and the requirements workgroup, please, you know, use chat or email to share that with the requirements working group. And I think we should probably move on. So thanks again, Oleg. And again, I think this is a great start, as a couple of people have mentioned. Thank you. I have to mention Abarth Khan, who helped a lot with this document. I'm Clare Poulton. So thank you. All right. Thanks. Okay. Very quickly, you know, so Rai put together an archive of all this Slack discussions. I think, you know, we were going to sort of noodle on, do we need this? Do we need to sort of pare it off? Here's what I would suggest. I didn't hear anybody say, oh, we shouldn't keep these because there could be some gems in here. I think the real challenge comes in, how do you make it presentable, right? And so I would just suggest that we, you know, unless anybody has strong difference of opinion, that we sort of put it as an action for, I guess, me and Rai to figure out, how are we going to make it presentable, you know, whether we host it in Nexus or something like that as HTML and then just sort of move on from here. Because again, I think there's probably good information here. We just need to surface it, make it searchable other than just sort of raw text form of HTML. Yeah, I think as valuable as the information is, it probably starts to expire more and more over time. So I wouldn't encourage Rai to overwork himself getting something out there, but it would be nice if it was accessible. Yeah. Any other thoughts on this? Any objections? Mick, were you going to weigh in? Yeah, I had another call coming in for 30 seconds, but is this still the conversation about the working group or did you move on to the next topic? We're on the Slack archive, Greg. Oh, gotcha. But we agreed you do all the work for the requirements for the group. Yeah. Awesome. All right. So I'll take that with Rai and we'll drive that to some sort of conclusion. Yeah. We have a partnership program. So we have a few proposals that made it through the cut. Todd, do you want to or somebody want to present this? Yeah, sure thing. So we had 12 mentors apply with project proposals that we will then have interns apply to. We needed to narrow this down to a total of six based on budget. Subgroup met earlier this week to talk through the different proposals and wanted to make sure that it was a diverse set across geography, across company, across projects, et cetera. And so the group narrowed it down to the following six. So they're listed on the slide for everyone to take a look at. They were also included in the agenda last night. And so really what we're looking for from the TSC is are there any objections to moving forward with this as the recommended six? If not, we will get this posted to our internship portal and start promoting the internship program so that students can begin applying. So for the TSC members on the call or anyone else, any questions or any objections to moving forward with this? I think this is a solid list. Yeah, we're really happy with the proposals and mentors that came in. So it's a good first year for Hyperledger. Yeah, it'll be great to get these out there with the students that I've interacted with. They're already deep into their summer plans. So the sooner we can get this out the better. Yeah, I agree. I see that two of them involve mentors who are based in China. Would we try to match up students in China with those two projects? We can, but it's not required. So much of the work that we do is virtual that they don't need to be based in China. But yeah, we will certainly take applicants from there. Great. All right. Well, I hear a lot of plus ones, plus twos. Anybody disagree with going forward with this list? Well, I disagree that we should all agree to go forward with this. I think it's a splendid list. It's well representative of all the different industry groups and corporations, as someone said earlier. And given the 12 and the six we determined here, I think this is the best we could have done. Thank you, Todd, for putting this together and for the whole team to put in on this list. All right. Thanks, Linda. Okay. I think we have agreement, Todd. Great. Super. Okay. Next up, request to exit incubation for hyper allergic fabric. Greg, I'm sorry, Gary had sent out an email Tuesday of last week with a proposal to exit incubation. We didn't really have quorum last week. Well, I think we actually did achieve quorum, but a lot of people were absent. So I think I felt that we should probably put it off until we have a more solid quorum, if you will. Arno, I know you helped to contribute to putting this together, so maybe you could pitch in. Sure. Hi, everyone. So yes, as you all know, we have defined a project life cycle for all our projects, and all the projects today are in incubation. Fabric has been in that state for quite a while over a year and a half, I guess, now. And so the maintainers have been looking into what it would take for them to be able to move the project from incubation to active state, which is the next day. And they actually documented in the document that has been pointed to and published to the mailing list the list of criteria. As you may remember, we had a lot of discussion on this. This is not about the maturity of the product of the project, but of the project itself. So it has more to do with the way the project is organized and whether they got everything together. And it's a functioning community. And as the joke has been within the among the maintainers, it's like, well, there's one thing that's pretty clear, is that the project is very active, practically speaking. So there is actually one point, which if you look at the exit criteria one by one, and we documented how we believe the project addresses all the requirements. There is one that cannot be addressed today. It's the alignment with the architecture, the architecture defined by the architecture working group. As you are sure you're all aware, the architecture working group is still working on this. So it's just impractical to define the alignment. But we hope that this would not be considered to be a showstopper. And otherwise, I'm not going to go through all of those criteria. They've been posted. There's been an email sent. I haven't seen any comments or questions. There were several people I saw on the chat have expressed support for the request. Certainly all the maintainers are excited about this and they all agreed to do this. So it's up to the TSC now to decide whether they should be granted that or not. Thanks, Arnav. Any questions, comments? Yes, this is Greg. We need a consensus protocol. Go ahead, Greg. I think I saw a VIPIN and it was Greg and then Mick. That's the way I saw the talking on the window here. I'll turn that. Just real quick. Sorry, I'll shut up. This is Greg. All right. A couple of points. One is even though the architecture working group document is not completed, some of the sections seem to be so, you know, because I have a feeling the architecture working group document to be completed is going to take a while. And if you have any comments at all on the sections that are, you know, together, then that would be a great addition to this document. That's first. Second is, is there a, I mean, I'm reading this document. I haven't clicked on all the links. Is there some notion? I mean, I know that Hart mentioned it several others mentioned it. That is more a measure of the community that's behind this rather than the completeness of the solution itself of 1.0. So is 1.0 out? No. Okay. This is, again, this is about exiting incubation. We're still working towards our alpha release of 1.0. You know, we had, I think we're pretty much sort of feature complete from, you know, from the list of things that, you know, we thought needed to be in the first release. The one sticking point was we didn't really have a good bootstrap tool, and you actually had to use the test infrastructure to create a sort of a bootstrap for a network. And so we've, you know, Gary has gone through and he's rectified that, and we're working to get the various SDKs and CLIs to align with this new tool to generate all the relevant crypto for, you know, for bootstrapping a network, you know, a system network. And, but once we get that and we have a couple of clean passes of builds, then I think we're going to cut an alpha. So that's probably going to be this month. And then we'll let it rinse and repeat on test, fix, test, fix, text, you know, till we're at, you know, sort of zero, seven ones, rather, and then probably put a 1.0 on it. So next up was, I think Greg was in a car and I think Greg, you were next. Oh, yeah. I just wanted to add the question that it wasn't clear from the proposal was what the scope of fabric was, right? So there's, obviously, there's the main fabric Git repository, which is obvious. And there's a couple other projects that I think are implicit in that like base image, for instance, and maybe the test resources. But I didn't know if that was also intending to include things like Chain Tool or Node SDK. And, you know, if so, which ones are included or all of them, that kind of thing. Obviously, I would love to see Chain Tool included, but I don't know if it fully meets the criteria in terms of, you know, the number of people involved and all that stuff. So I wanted to talk about that. I mean, I think that, so this is Chris, and I think that from a, you know, an alignment perspective, all of the repositories that say fabric-something are aligned and, you know, they're working towards, you know, getting to 1.0. And so I would think it would be all of the ones that say fabric-something. All right. That makes sense. I just wasn't sure from the document if that's what was intended. Yeah. I mean, obviously... I was just saying, correct. This is a good point, Leonard, here, that any release, whether it's an implementation just coming up of off-sharp incubation, should have a set of requirements, high-level requirements that we can map to that release. I don't think this is a conversation we're having right now. Right. Good. No, that's fine. Continue. Okay. So I think next was Mick and then Dan. I got to find out which button I used to mute this time. So just a couple of things. One is that I wanted to give kudos to Gary and Arnaud for putting together a great document that describes the transition. This looks like a really good thing. The question you brought up in the document at one point about no single organization leaving that the project would continue. What's your thinking about the ongoing role for IBM in this? If you picked up, if IBM picked up and moved, would it continue on? Is it that mature? And what's your line of reasoning behind that? So right now, we're driving towards, my goal for last year was to try and get under 50% of the contributors and to keep pushing down the total percentage of contribution of code. We're at a point where I think, and what did we put in here, 55% of the total contributors. I haven't checked this. This is a couple of weeks old. We keep gaining more contributors. And what I'm seeing is that we're getting more sustained contributors. As people start to use the fabric and all the different constituent parts. Ideally, we have to get down to about 30% of the total contributions and get others in sort of the 10% and 15% contribution levels. Right now, independence are sort of number two, and then we have some strong contributions, obviously from Greg and State Street and from DTCC and Fujitsu and Hitachi and Huawei. If IBM were to walk away today, would it continue? Probably not. We're not going to. I have no doubt about that. The trajectory that I'm looking more at, we came from essentially 100%, and the numbers continue to drive down to be much more of a plurality than anything. In fact, we were very close to being under 50%, and then the drive to get the V1 features all complete sort of bumped up our numbers a little bit. From my perspective, it was good because we're getting more people playing, but it's also more IBMers. If I had to characterize also the IBM contributions, it's not all coming from one group. It's not like if one group, we have three or four different constituencies within IBM that are contributing to this from different parts of the business that each have an interest in this thing going forward. Even if Sharon Weed's team were to sort of walk away from this, I think it would still happen. Okay. Thanks, Chris. I just thought that it was a really well organized request, and I'm frankly surprised that the fabric team didn't make that sooner. I think you guys have done a good job organizing the processes, and I don't actively contribute on fabric, but what I see from the outside is processes are in place. You guys have good reviews through Garrett, and it looks like mature team and processes. I think this is all good. We actually delayed a little bit putting the request forward because there were some repos that had not been transitioned yet from like Github to Garrett, and then the documentation was real limbo for a while while we were working on 1.0, and so we just waited to get to a sense of more stability to make the request. I think we got there now. It's not to say that everything is perfect, right? I'm one of the most critical persons about sometimes not being open enough, not transparent enough, having some of the documentation, the decisions on 1.0, not easy to find there, but I think we definitely made some great progress there. I think that's a good point is that part of the maturity there is that evaluation of whether the team is doing the best thing, and I don't think anybody's ever expected that a team is going to execute flawlessly, but having a self-critical eye of that is, I think, a great thing. Our no is our ombudsman. Sorry, Ram Jagadishan here. First of all, great document, great progress. I think we're definitely at the point where this needs to happen. In alignment with the architecture world group, I know we're not there yet in terms of a well-defined architecture document, but I'd say I'm really happy with the progress that the fabric team seems to have made in terms of moving in the directions that the architecture working group is going towards. So the first complete work item, I would say, of course it's a creative process, but it was a separation between the smart contract layer and the ledger layer, and it seems like that's been very clearly done in Fabric 1.0, as well as the other major pushes going to a modular architecture with separation between the storage layer and so forth. So I'm very encouraged to see that that's happened in Fabric. So perhaps that can be captured. Bitten probably has a good idea, given his ongoing contribution to the architecture world group, of what of those directions that we are pushing towards have already happened in Fabric 1.0. So perhaps that can be captured here, as Bitten was also suggesting. Thanks, Ron. And there was somebody on the phone. I can't tell who's on the phone, but somebody tried to get in at the same time as Ron, and Patty, it wasn't you, no. Okay, so any other comments, concerns? If not, I think, Todd, we should put it to a vote. All right, sounds good. So walking through the list, Arno? Yes. Din? Yes. Chris? Yes. Dan? Yes. Greg? Yes. Hart? Yes. Mick? Yes. Richard? Yes, so I didn't get just to be clear. Yes, we'll build onto the team. That's Minit, from a completely self-serving perspective, and I think the discussion around IBM's long-term intentions, even though the project depends so much on them right now, because I may need to rest on exactly the same argument when my quarter comes through this in the future. Otherwise, yes. Great. And Tamash? Yes. All right. And Morali? I don't think Morali joined, but if you're there. Yeah, yes. Okay, great. That passes unanimously. Congratulations. Thank you. Thank you, everyone. All right. Next up is Tamash and the GSL discussion. Thanks. Chris, I prepared a presentation which I would want to share. I hope I have the right to do so. Tamash, you're very faint. I just said that I am sharing my screen. Just give me a minute. Okay. So I hope you see my screen now. I can see it. Yes. Thank you. Great. So we promised a couple of weeks ago to extend on our thinking of the GSL, and I heard that I'm very quiet. Let me try to fix my mic. I hope it is louder now. So we promised to talk about or extended thinking of the GSL. And this comes forward now in the form of a presentation, not yet as a proposal as Chris anticipated. I think that this proposal will build very well the discussion of such a proposal. I won't do this presentation alone, but I would also include my colleague, Lance Arlos, who is working as a product architect in digital asset. He was also very instrumental in extending our thinking. So this is an honor to hand over to him so he can set the context of this presentation. Hello, everybody. I hope everyone can hear me. It's a pleasure to join you on the call today. Am I coming through okay? Just want to make sure. Loud and clear. Loud and clear, Lance. Loud and clear, Lance. Awesome, great. Yeah, so as Tamash said, I want to set a little bit of context before we get going here. And I would say as a community, the original vision that we aspire to was to achieve an internet of value transfer that seamlessly spans markets and organizations. In other words, the free movement of assets with full fidelity and no settlement risk. Tamash, next slide. So the problems that we face in achieving that vision are in some ways unique, but largely familiar actually. So fragmentation is a natural byproduct. It's actually a healthy byproduct of the innovation cycle during its initial stages. But convergence and emergence of standards is necessary for broad-based adoption. This means practical solutions and not some of the ones that require, for example, everyone using the same distributed ledger, or one ledger being the prime authoritative legal record of ownership. These ideas are unrealistic because they introduce new systematic or systemic risk in the financial system and potentially fundamentally change market structures and regulatory oversights, or regulatory oversight. And we don't want to stifle innovation in a young, rapidly evolving industry. So we're looking forward to, or we look for, is, next slide, please. The notion of interoperability. So while our unique value proposition in the market is the potential to eliminate reconciliation, and that may sound right, but reconciliation is the limiting factor of any distributed business process. So interoperability really kind of takes on a special meaning in our industry. And it's the ability to eliminate reconciliation and execute or orchestrate workflows across multiple different systems. In other words, eliminating reconciliation through automated convergence. And this is the foundation of some of the concepts that we're going to talk through today. Tamash? You certainly remember that we published a paper about GSL a few months back. If you did not read it yet, you can use the link given on that sheet. If you're not familiar, I just very shortly kept, in this paper, we encouraged collaborative work in the Hyperledger community towards creating a component of the technology stack that we think compromises the distributed ledger. In this document, we identified that the fundamental requirement for the application of DOT in regular financial services was to preserve the privacy of sensitive information. And we concluded after analyzing several alternatives that this is best accomplished for by sharing data only on a new basis. The consequence of this was the creation of a component, which we call the GSL, which is a log of commitments of confidential data, and the notification set that combines these evidence to confidential data. And the recipient of these notifications, know then what confidential data they are involved in and what they need to fetch. And thereby, with this separation of concerns, we created a distributed ledger consisting of our platform where the GSL is a component of. The GSL basically establishes a common and complete set of wallet transactions and then combines it with a corresponding of chain data. In OR implementation, the GSL is responsible for three different things. For one, it is an arbiter of relative orders, it's sorting the transactions. It also ensures that mutually exclusive events do not happen, so it maintains the consistent state of the ledger data. And it also serves as an assured notification mechanism. So the stakeholder who is affected by a change of data will be notified and they'll know that there is something happened that is concerned of. In OR current implementation of the platform, this component, although it's a logically separate component, is embedded into the platform. And this was the main reason why we did not open source it because we honestly did not have the resources and the right context to extract it as a project of its own. There, although we started with an embedded component, the design as we went on evolved into a more externalized service. And this represents basically an evolution of our original design as we described in the non-technical white paper that is much more versatile than through this clean separation of responsibilities. We basically separate the cometer, which you can think of as the maintainer of the state within the platform. The cometer is responsible for the local sequencing and caching events whereas the participants within the platform or participants who are connected to the platform get the notification of changes of ledger states the way we already described through the GSL. While we extended it into a kind of standalone service, we realized that this is also suitable to connect several instances of our platform. If, for example, two markets would be run by two distinct providers, infrastructure providers then we could connect them using a common GSL which would still maintain an independent state of the ledger on the two sides of the platform that would allow notifications across these platforms using the same service. We could, either we did not deliver this proof from the concepts of how we see this working, we believe that the workings of the GSL are even extensible to other platforms if they would implement the same type of separation of responsibilities between a cometer and a GSL compliant interface to the services I described. I would really emphasize here that this is about GSL compliant services and not the GSL as a particular software. The services, the utilities that such a GSL actually provides are quite simple. Four forward, one is to evidence contracts in our case or you would say state objects in case of Coda or the world state in case of fabric. You would evidence that with a cryptographic hash and you would use notifications to let the other platform know about what's happened that some some evidencing happened. We have the GSL in between them to distribute the data whereas our goal is to minimize the broadcast information even on the GSL level and to as much point-to-point transfer as possible. And finally the GSL is also a storage component for a self-contained, self-auditing app and only data. Now, every platform that we saw also in the Hyperledger Foundation every platform has vendor specific terms for pieces that such a GSL compliant view of them would imply. But they actually have very similar concepts and while we extended our thinking on the GSL we came up with some thoughts of a common technology that might be useful for consideration for other projects and also for the entire industry. And I would like to ask Lawrence to introduce us to this terminology. Yeah, thanks Tamash. So as I alluded to earlier, if we put this into context just in the overall innovation cycle that we've seen both within our industry and other industries as well, right? We've come to a point where we have an opportunity to have convergence really. So once we have some common knowledge about a domain you know, like I said we have the prerequisites really to meaningfully collaborate if we start speaking some of the same language. So this is not an attempt to get to a point where we eliminate differences but rather for the fundamental components that are common to the various different platforms and the fundamental concepts if you will that we map them down to a common reference model that allow us to progress towards a vision of interoperability. Next slide. So distributed reference or distributed ledger reference model is really a conceptual abstract framework that starts to identify and put common terms on some of the common pieces that we have throughout our various stacks. So a vendor neutral framework that we can map to vendor specific components that really serve as that opportunity or the means to identify opportunities to collaborate and create cross-platform modular common components for interoperability. The model is based on a layered architecture with each layer having distinct responsibilities. Sorry about that. Go ahead Tamash, do you want to take it away? I'm sorry for being a bit too fast by paging them. So I think that the reference model that Lance just mentioned is really a huge chance to align our discussions and our thinking and will probably also help us to rethink or to map the structure of the current projects to something more common and interoperable at least on the conceptual level in the industry. I think that the projects that we currently see in Hyperledger are naturally, because that's probably by nature of a new technology covering a bit higher scope than they need to do. I think I made my point. That's why we are very supportive of the idea of an umbrella organization of the Hyperledger project because we think that it would really make sense to create components that would cut across these. We certainly see that GSL type component as a minimum viable option to start with that kind of modularization of the stacks. We think that this modularization has even further promises which I would ask Lance to elaborate on. So similar to our own progression internally because when we started designing the GSL component as to much reference it really started as this embedded component and we went through this design progression where going from an embedded component that can coordinate segregated ledgers internally within one distributed ledger to now an externalized service that can coordinate across distributed ledgers even within our own platform. What we realized is if you just take the next logical step that that would be applicable to the community at large. Now I mentioned the first step to doing that as it is in any industry is developing a reference model, mapping the various platforms to that reference model and then once we have a service that can serve that reference model by extension it can serve the various platforms. So as Tamash mentioned, rather than starting from the top down and doing full stack platforms and expecting to somehow extract some modular components out of those various platforms really starting from the bottom up and having a set of clearly defined responsibilities and as I mentioned the reference model is a layered architecture which naturally starts to translate or allow us to identify some of those opportunities for having common components at that base layer and the base layer for the commitments and notifications would be a GSL or GSL-like component. So offering an approach that has the potential to deliver interoperability through a common vendor neutral service we're clearly headed for a heterogeneous distributed ledger world. Many different platforms there will be a need for these platforms to interoperate. If we think of interoperability from the perspective of eliminating reconciliation we will start getting to the point of delivering on the true promise of the industry to achieve this, like I said, we need a common framework and starting at the lowest minimal common foundation to start that journey if you will to interoperability. And Tamash is going to talk about some of the specific deliverables along that journey. So I recognize that we we write some big hopes and also made bold claims with this introduction. In all thinking this is well funded and we would want to share this thinking with the third form of reference model for distributed ledger and provide this for community collaboration and we really consider this as a request for comments on the terminology because it would be a great addition to the entire industry to get onto the same page. We think that we will be able to provide this in a very well documented manner in April and after a community discussion of and we don't honestly know how long this would take after a community discussion of this reference model we would also provide the technical specification of or generalized GSL whereas I think that this technical specification should not serve as a design document for the GSL but it is basically or experience and or knowledge about this topic in the hindsight of already having implemented such a component and we give this as a contribution to the community. So Tomas we are at the end of the job here and this has been great thank you both Mosh and Lance. I tend to think that we are getting to a point where we do need a coherent reference model that we can all be using to speak the same language and I think this is ideal. I'm hoping that we do get a chance to get together in April and I think this would be a great breakout to focus on really sort of going through this and trying to get some agreement while we're there face to face but the sooner that we can get the reference model published and contributed to ROM and the team I think the better and I really look forward to it. So I think that's it. We're at 11 o'clock and so thank you everybody. We made it through a very jam packed agenda and I want to thank everybody for sticking through it and look forward to talking to you all in the middle of the night next week when I'm in Shanghai. Thank you brother. Cheers. Thanks everyone have a good day. Bye.