 Alright, so on tap for today we have some updates on the HackFest and also on just a reminder to the workgroup chairs to please post their updates on the list and I think another brief update on the communication tools we'd really like to get that sort of squared away. Then Tamash is going to give us an introduction to the Global Synchronization Log, GSL, meaning that digital asset holdings has been working on and then I'd like to have a discussion on exit criteria and then I think Brian wants to talk about the China Technical Working Group that's been proposed. Are there any other agenda items? If not, Tom. Alright, just a couple really quick updates. December HackFest, we are still looking for a venue for December 5th and 6th. We thought we had one place that ends up it won't work out. So if anyone on this call has venue space in or near Manhattan, please get in touch as soon as possible. We would like to get this locked down for the 5th and 6th of December. Onward from there, workgroup updates. Just a reminder from Chris as well last week, please send any updates to the TSC mailing list so that people can stay in touch with what's happening in the various working groups. And also please make sure to update your wiki pages so that anyone that wants to participate can easily get up to speed and understand how to navigate the group. And then lastly, communication tools. If you haven't had a chance to poke around with discourse, please do so as soon as possible. I think the other one Brian was asking people to look at was Rocket Chat. If anyone has had a chance to do that, definitely let us know your experience there. And Brian, I'm not sure if you're on yet or if you had anything else to add there. Otherwise, Chris, I think we can move on to the main part of the agenda. Okay. Thanks Todd. So I guess we should turn over the talking stick to Tomas. Hello everybody. I... Thank you. I just received this invitation to be a presenter just a moment. Hopefully while Tomas is getting set up, hopefully everybody should have seen a note from Dan O'Prey last evening with a link to a white paper. You should see in the meanwhile the white paper that we just sent to the TSC mailing list this morning. Would you confirm? I can see it. I can see it. Yeah, perfect. So this white paper is an attempt to formulate a module of the distributed ledger technology. And it is... The purpose is really to encourage collaboration to work on this sub module. I think that it is quite an ask to refer on this complex paper in a short walk through what I'm doing here and I apologize that this was made public just a few hours before this meeting and I hope that after this presentation you will have the time to go through it in full length and also provide feedback, which I would really appreciate. So as said, the purpose of this paper is to encourage a collaborative work in the hyperledger community. And it is an output of our experience working with regulated financial institutions implementing the distributed ledger technology. Thereby we both try to use existing distributed ledger stacks such as the fabric and others in the space and also build our own solution. Why we did this exercise? We learned that the current stacks are not only inadequate for most of the problems we try to solve but they are also very hard to be used in conjunction because they always came as a full stack solution. They came with a smart contract language with an implemented ledger with their own solution for the entire problem space. So the attempt we are making here is to just focus on a very small piece of this entire problem space which is we think the foundation could be the foundation of such a technology. And this is what we call the global synchronization log which is described in this document. The global synchronization log is basically a log of commitments and notifications that guarantees the integrity of the distributed ledger store and is auditable to the stakeholders and form the other components to get out the actual distributed ledger. We found in our work in this space that the most fundamental requirement in applying the technology in financial services is to preserve the privacy of sensitive information. Taking in consideration these risk factors that I would like to elaborate on the problems area, we think that physical segregation of the data, of the sensitive data is the solution that would be acceptable to the work plan base. Maybe this is best exemplified if I go to the individual solutions that we saw in other ledgers. Others try to solve the problem of sharing sensitive information using either of the following four ways. One is to use a kind of obfuscation where the transactions are visible to all parties but the parties themselves are seldom in this. This is what you see in the case of Bitcoin. Another solution to address this was to use encryption which is where the transaction carries a cyber tax and you communicate the keys only to parties who are entitled to see the content. This is the approach that was made by Fabric. Another way that we saw to handle this was the use of zero-knowledge proofs where the transaction carries a cryptographic proof of validity that is convincing to the network but it doesn't reveal, only reveals the transaction's real meaning to the eligible parties. The fourth solution is segregated ledgers where the actual transactions are only communicated and built into ledgers on a bilateral or multilateral basis only involving those who are entitled to see the transactions so they have only the replicated storage. The fifth solution is where you only store commitments in a global ledger and distribute sensitive information peer-to-peer to involved parties. Now we think that the first two options are unfortunately not viable in our client base mostly because of data domicile requirements and concerns of forward secrecy in case of entry chain. We also think that obfuscation is, although it could practically work well, it is not really secure against a sophisticated data miner. So we closed out the first two for not being applicable, not being viable and evaluated some solutions using the zero-knowledge proofs that our current, as for our current knowledge, they are either not powerful enough or not have not received the scrutiny that would make them viable for our clients. The remaining two options, segregated ledgers and data execution commitments are the ones which be further worked, further dived into and GGSL in particular as described in this document is focused on implementation where you have data execution commitments, that means the network-wide blockchain areas, fingerprints of sensitive data and the actual data is segregated. I'd like to go a bit more into detail what global synchronization log can achieve in that limited set of functionality that we think builds a value block. The three functions it can achieve is that it can build a relative order between transactions. The second one is it can ensure uniqueness of mutually exclusive events. So to translate it into a simple meaning it can exclude double spans, it can exclude alternate contracts that artists might have entered into. It can, if there are two contracts in existence, it can choose the only one which is really valid. And it can serve as an assured notification mechanism. This is a concept that we invented with the GGSL. It is, we think, necessary to also have the ability to notify, to ensure that the party who might be who is involved in the transaction always learns about this transaction. This is no longer a trivial statement as soon as the ledger, the actual transaction data is segregated. So the ledger only carries proofs of the contracts. A central data structure of the GGSL re-envision is the set of active contracts. We think of the ledger as being defined by the set of active contracts and we think of contracts as the off-chain business logic that describes the binding agreement between the parties. This is not really a contract in a legal sense, but more in an algorithmic sense. But what's important in our think model is that this contract is, as is, a very static description of the current agreement. And because of that, the set of active contracts describes the state of the world as it is understood by the GGSL. The contract is a bit similar to the state object you see in the Corder framework or could be a bit similar to the chain code state or the word state that's in fabric. But the real difference is that in all case the active contracts do not change. They are instantiated. The contract is instantiated and then replaced with subsequent contracts or destroyed entirely. This is to be restricted with the expressiveness of contracts by that, but not really fundamentally, since one could express any state change by rewriting the contract and one could express any procedure in the procedural sense in a declarative functional way which we think is a more appropriate representation of legal contracts we work with. So, as I said, the GGSL carries proofs of existing contracts and we also suggest to maintain a set of active contracts, a failure print of these set of active contracts in the blockchain so that if a party is joining the network, is able to very quickly learn from any other party the active contract set or a partial active contract set he is interested in and verify this active contract set against the fingerprint of this set in the blockchain. The GGSL itself is maintained by appending transactions just like any other blockchain implementation is so. Committing a transaction to GGSL changes the active contract set by adding or replacing, adding a new contract or replacing an existing contract and in more case these contracts are formulated in the demo language but we don't think that this is a limiting property. It's not designed to be a limiting synergy between GGSL and or implementation. We think that it could be any kind of generally contract language that is useful for your specific use case. The transaction carries the fingerprint or the evidence of the contract and it carries a list of notifications. These notifications are derived from the active contract. They are very likely the parties who are involved in the contract and those notifications are the second very important functionality of the GGSL. I mentioned earlier that the contracts reference those contracts they replace. This remembers a bit of the Bitcoin UTXO model. It is similar in the logic and therefore it also has similar vulnerability to Bitcoin. You know that in Bitcoin it is possible to analyze the transaction graph implied by the UTXO links of 22 references. Now we would want to avoid that and therefore we split the actual GGSL transaction into two components. One is only carrying the evidence of the contract and the notifications and another part which we only share between a set of auditors and a set of writers of the GGSL. I will go into that a bit later who are entitled to see it. Now the notifications that I mentioned previously are not again not plain text notifications since it would again reveal a lot of information about what is happening on the ledger if you could tie individual events to parties. Therefore we think that the notifications tokens used on the ledger have to be constructed such that they can be only recognized by those who are consuming it or those who are creating it. They are cryptographic tokens based on a shared secret between the modified party and the party who is modifying. The next function of the GGSL is certainly ordering transactions. We think that relative order is sufficient but since capturing all dependencies between contracts explicitly on the chain might not be not be sufficient or feasible we are rather going for a double order defined by a blockchain and this order has to be established in case there are several participants or several operators writing the GGSL. The options we have here are consensus algorithms and they were seen in the Hyperledger Foundation to distinct approaches PBFT like and probabilistic convergence approaches and probabilistic convergence of way at one. The GGSL as we defined does not assume any particular consensus algorithm but is actually quite agnostic to that choice. As for a moment we see that the probabilistic convergence since it doesn't offer finality on its own is not yet an option for us but we are looking into that very exciting research currently ongoing in the South of Lake project. Now while we formulated this GGSL we carefully separated the contract implement the contracts interpretation and the contracts recordation on the ledger and this certainly raises the question of how do we ensure the integrity of the ledger in a whole the integrity the sense of only regarding wallet contracts and I do the GGSL that is not planned to or not meant to be having visibility to the contracts themselves. The way we suggest to solve this is by introducing auditors to the invariance of the ledger. The GGSL itself has several. For example the aforementioned uniqueness of contracts is an invariant that can be checked by an auditor of the contract references without the need of being able to understand what the contracts are. Similarly an auditor that has only limited insight into the contract's meaning could audit notification sets whether they are appropriate for the type of contract that the ledger is recording and also every participant consuming the GGSL can certainly perform all the validation that is attainable to that participant with the data that is available to the participant and thereby all those participants and all those auditors in their partially overlapping responsibilities and capabilities can keep a check of the ledger of the ledger's imbariances and integrity. Now this is about our vision of the GGSL in a functional sense. We have also a long list of non-functional requirements that we think GGSL would have to satisfy. I would only want to mention the first two which is that we expect the ledger will have to be able to process several thousand transactions in the second and that some contracts in our sense will have thousands of involved parties that need to be notified and the transactions have millions of contracts updated in an atomic event. We also expect the active contract set will have a magnitude of billions of contracts at any given time point. Now the publication you have in front of you is just the start of a series. I admit that this is a very high level view. It meant to be a high level view so you get accommodated to our thinking and we also get timely feedback on how you think this resonates with the model of the Hyperledger Foundation which in our understanding aiming to introduce enterprise quality modules for the distributed ledger technology. We think that this GGSL is as described in this document is a very valid candidate for this module and think that the function that is described here could be implemented with several of the currently incubated projects and the digital asset tools we want to work on of this implementation. And welcome you to join this in the sense of the ledger of the Foundation's spade. That's my conclusion to the document which I hope will be shared by you. I'd like to open it for questions. Yes. Yeah hi Tamash. It's Richard here. This is Richard. This is great. Thank you for sharing this. I read the paper when Dan sent it around this morning and it was great, really well written and I thought it was helpful because there are so many pieces in it and I guess as you've alluded to so many pieces in it that seem so close to what we're doing in Corder. But you've also gone slightly further. You've formalized some concepts that we've been less clear about when we've been writing these things and articulated a useful set of requirements around notification but also like the actual concrete and non-functionals you've included in that. I had a question to make sure I've understood it correctly about most validation and notification. Did I hear correctly that the people who can commit to the GGSL, but I think you called the moditors, the people who can commit to it have full visibility and by committing or attesting that they have verified the transactions and that's my first question. Well people who are committing or let's say people who are creating a transaction, so creating a contract with other parties certainly have a visibility to that contract because they are part of it. Now they propose this commitment to the ledger which is that we called it to the ledger. This is not an auditor role. An auditor, what we call an auditor is some function who is auditing an invariant of the ledger which one of it is probably, is something that you call a uniqueness service which ensures that the ledger has the right properties. So this is a distinct function. It's not necessarily the same thing or ledger integrity guarantees or ledger integrity is guaranteed by the by the concept of participants, auditors and those who are writing the ledger. Cool, okay because we have the same, I think we have the same approach here in one dimension, just wanted to check. So if I were feeling perverse I could create a transaction where the private part of it is invalid and you know I don't screw myself I guess because it would quickly be discovered but I could in principle commit that to the ledger and consume, consume an input inappropriately. Is that correct or is that prevented? Well this is not something that we think is a realistic example. Those who are writing the ledger are also doing a validation of it. To what extent it depends on their entitlement or depends on the configuration. So what I'm describing here is a concept of overlapping responsibilities of ensuring the ledgers and what we are aiming here is to come up with a design that gives a large flexibility of creating those distinct sets of responsibility that can overlap and then in concept ensure that the ledger is okay. Cool, just a quick thank you, thank you Thomas, another very second question. Am I right in thinking that the way that where I should think about notifications is let's imagine I create a transaction and I'm assuming from context that you're using a UTXO style model so there'd be some concept of verifying the transaction and the business logic that verifies it is also responsible for ensuring that that transaction has, I'm using the wrong terminology here but ensuring the transaction has specified correctly the set of people who should be notified so that the transaction can only be considered valid if it also specifies the right people to be notified and that's how you lock those two things together. Yes we said one there's a statement in the paper that or we assume that service that validates the contract considers the contract only valid if the transaction also notifies the right people whatever this definition means the right people it's certainly those who are affected in some way by the contract. Sure got it that's just really clear thanks Thomas. I think there are a couple of other comments in the chat. I see a lot where do I start, quick question, how much more efficient would SNOC have to be to be a viable solution for your application? I think it is certainly there is also a scalability issue with SNOCs but the real problem is that these kind of proofs do not cover all the invariants that we would want to check so I don't think that it is just a question of scalability it is also a question of applicability of the current zero knowledge proof algorithms of the current practical zero knowledge proof algorithms. The next question in the order of 25 seconds several people working on making it more efficient how to ensure the notification be received by every effect that's stakeholder I think this was covered by my answer to Richard. This looks like a colloquine metaprotocol approach the blockchain orders transactions blah blah and my question is how do you ensure the two parties the transaction are absolutely the same same ledger state well I would say this would be it would be mischaracterized to be a colloquine a metaprotocol approach this is a this is a suggestion to modularize the problem we think that this can the hyper ledger or this technology or industry in a full can only advance if we if it began working on components which are well defined and can be reused across different implementations so we can also compare their performance and figure out what what is the right thing to do with the right solution to do I think we cannot cannot advance this in this industry any any any further if we are just proposing full stack solutions one after the other which which find a solution for every detail of the problem in some other way than than this so before so is there an implementation that mirrors these requirements a reference implementation well at digital asset we work on an implementation that is I wouldn't call difference in reference implementation because it is due to our commitments to deliver to our clients it is an implementation pretty much tailored to the current needs of our customer so I admit that we do some shortcuts there to to be able to deliver there so I would not call it a reference implementation but it might at some point be be powerful enough for that purpose but I don't think that it would be the it would be the the right approach to on from all side to to aim for such a reference implementation I would rather see this idea inspiring the already incubate projects in the Hyperledger Foundation so we so we work together at this start any further questions so tomorrow this is Chris so I guess the question is so what are your intentions is deep is digital assets intending to contribute something and given you know as Richard suggested and I think as was suggested in the chat and certainly as I felt as I was reading through this there's an awful lot of similarities to things that are already sort of in flight how do you how do you see this you know sort of moving forward do you envisage an external component that would be maintained do you envisage you know helping to morph the capabilities that we have and other things towards this first of all first of all I think we made a very important contribution by proposing a modularization to the problem and we are we hope that you follow our argument that's arguments that's why the paper is is very verbose and we made a lot of effort making it making our points very clear why we think this is a this is a viable meaning for separation of concepts so this is this is our first this is our first contribution and I hope that this is will be appreciated and we we are also committed to contribute coding effort and along these lines and proving if which which we are actually convinced possible if the incubator projects including fabric and corda can be can act as a GSL or can offer those services so so so Richard speaking here um there's there's given we've only recently seen this there's still more um thinking we need to do inside our three but just reading through it this morning and um and and then this needs to tell us his answers now um I that's certainly be interested in that this looks like a okay that you sometimes you dream of um receiving instead of requirements that are a perfect fit and um and this is not quite that there are some things we don't have but it's it's um it's remarkably aligned to how we see things so I'd love to continue to collaborate on this thank you hi this is Dan from digital asset um just to add to that we we do intend to follow up with a more technical document uh at some point in the near future and are obviously happy to participate on any tsc pools or have a you know an hour long discussion once people have had time to to read and digest uh the document but yeah the very much the goal is to stimulate discussion uh as Tomash said to to move towards a more sort of modular approach which I think is in line with uh Brian's concept of a an umbrella organization for ideally reusable modules across multiple different implementations and then also we continue to explore the current projects and we're committed to you know in the future hopefully adopting um an open source project that does meet these needs and those needs will evolve from feedback from clients and as well from community around the ideas that are proposed here um but I think the goal is is very much in line with the mutualization of hyperledger well if there are no further questions then and back to Chris um so this is Ram um you know glad to see this contribution Tomash very well in paper um you know as you know we've been working on the architectural work group and perhaps in the next meeting we can you know you can do a deep dive uh as part of this to see if this needs to change the modularity as we've defined so far in a group I don't think it overrides anything that we we've worked on in the group and and and would be very pleased if you take those ideas and consider them great looking forward to more discussions on this next week this is a ripping Tomash great work I think it it feeds into the whole modularization approach that we have been actively championing in the architecture working group and other places as well even when we introduced the membership services last time we were talking about making it more generic and as a utility available to the multiple incubated incubator digital ledgers available to us this is a great uh approach and let's hope that uh we can put some more meat into it uh and get uh you know like as like I was asking uh some kind of an implementation or more technical paper would be very welcome thank you yes I did mention people follow up I apologize I had to step away for a bit I missed all the excitement so I'm not sure where we are just waiting for 10 more seconds no questions I guess thanks were there any actions that I that I missed that I should just know about we promise to follow up uh both with uh for the technical details and the publications and also with uh uh contributing work along these lines to the incubated projects stop it stop it all right thank you uh let's see what's next Todd I think uh there was uh exit criteria um so a while back we had a discussion and we worked on uh there's the link to the to the exit criteria um wiki and um and I think that we sort of again I just want to make sure that we're all right at dog chain um that you know that we're all still sort of aligned you know we've had a little bit of a changing in the guard but basically I just wanted to again review the exit criteria because I think the fabric team is looking you know as we you know do our sort of march towards you know a v1 um at the end of q1 it's likely that you know we'll want to sort of exit from incubation um and so I just wanted to make sure that we're all sort of up to speed and familiar with where you know with what we I think agreed in the past about the exit criteria and um that uh you know that that would be the sort of the yard stick that we would measure um any any projects that seek to sort of exit from from incubation into active status so I'll just remind people I don't know if we need to have a discussion at this point in time but you know if if there are concerns or issues then I would suggest that we take it to the to the mailing list and have you know have whatever discussion we need to have and uh uh if we need to if we need to amend them we'll amend them but um I just sort of put it out there and open it up for any any discussion or um or if not we can we can move on to um to Brian's topic I hear crickets so I'm gathering that that's agreement that those are the criteria and those are what we'll use to sort of measure suitability for exit is that right uh at least in my case I just haven't had a chance to look at it Chris recently see me again I don't want to you know sort of force a decision but I do want to sort of you know sort of re re-raise the the the topic just so that it's it's front and center so I guess what we can do is and again I'm not going to be around for two weeks for the next two weeks but you know maybe we if I could ask the members of the TSC to sort of review the exit criteria and um and and if there's any you know comments or suggestions to add them to the to the wiki and send them to the mailing list so that we can have the necessary discussion and um and then maybe what I'll suggest Todd is that sometime in the next week or two that if either if there is no just uh discussion or if there is if we can just bring that to closure and um you know within the next couple of weeks so if you could everybody read that hey this is Brian can you guys hear me okay good um can I suggest we actually uh okay do a little bit of uh just one last kind of review on the exit criteria I think it has some dated things like a github repo etc but just just one last pass and then give it one week and then starting next week we actually develop a checklist of sorts something we can use the wiki to track progress for each of our projects and incubation to see you know did it meet criteria one criteria two criteria three uh just so that you know we have a trackable sense of progress against these um and something that collectively the group can own rather than you know another email thread that may get lost and something like this I'll you know I'll volunteer my staff to help with that process um but I think you know some way of formally talking it would be good and fair to all the projects and incubation well I I certainly think yeah that a checklist would actually be a positive thing to come out of this and a wiki page the tracks that was kind of mine yep the main okay cool all right thanks brian of course probably thanks talk yep I put it all on Todd's shoulder okay I just come up with the ideas yeah actually thank you guys uh so then the the last topic I think is the china technical working group brian so um yeah well um just real quick it sounded like there was generally positive responses to that um I'm not prepared yet to make a formal proposal but I'd like to do that uh next week I think as part of that formal proposal the one thing in my kind of sketch uh that that you know would be would be helpful to put in the proposal would be naming um some co-chair people for that committee um for that working group I'm sorry for the working group I'm not looking to set up you know something with 11 people you know like the uh the the TSC um nor is it something where there's intended to be a lot of voting because generally it'll be more of a support group and conversational rather than having a lot of decisions that need to be made um but the idea is naming a few specific people to be links between this world and that world between this working this committee and that working group and and uh and that sort of thing so um so a are there any other comments people wanted to make on that before I kind of write it up as a formal proposal for next week the does anyone oppose to that timeline and see are there are there what what process should we go to through to name those individuals I think it should be more than one but um I'm open to that as well so this is Chris um I think I sent this to the list I'm not sure I'm definitely you know as as our others um very very positive about this um I I suggested that there be a tie between that group and this group and that um you know we invite one of the chairs or all of them but I mean again it's an awkward time in the evening for um uh for our colleagues in China and so I was just suggesting that maybe they could sort of because you know we would have multiple chairs that they could sort of take on a rotational assignment of sitting in on this and any of the other work group calls um to serve as that sort of liaison to be you know up to speed and be able to communicate that with their colleagues in China um right you know whether it's to you know have a discussion on their their regular calls or what have you or we chat but um I definitely think that that would be a good thing and I definitely think that multiple chairs would be a good idea other thoughts okay then um what I'll do is I'll solicit volunteers for the chair um and uh on the tsc list uh and it's an overwhelmingly crushing number I may exercise a bit of executive kind of prerogative in in narrowing that that list down but uh um in general again I'm really happy with the response that's come in and uh I look forward to putting a more formal proposal on the agenda for next week okay and so I just noticed in the chat that vipin was asking how the China technical working group reports this with the tsc I think we answered that but vipin just to make sure that you're good uh yeah how it would respond I mean the the the chair is just like you say either rotate or all of them show up on the tsc calls here report in from time to time on the activity there um and it's I definitely see the twgc as accountable to this tsc you know there's that link there you know if things aren't working then we look for new chairs that sort of thing um but uh but that's that's the connection for me so it'll be purely a way to uh socialize our um I mean whatever activity that we're engaged in and the activity in China um in the chinese ecosystem uh and make the make the bridge because of of course the language barrier uh and that kind of yeah okay yeah and um exactly uh to give them a sense of local local support local uh identity so yeah hi hi this is Charles from one dark group uh yeah I think it's not necessarily the language rather than the time zone I'm actually in Silicon Valley so I can attend early morning over there at nine o'clock asking all our chinese members to join it's actually a bit difficult so uh me and Julian we are organizing the chinese hackathon these days so we are just busy uh but so we will be connecting the the feedbacks as well because all of the members in China will be participating in the hackathon the Shanghai hackathon uh supposed to be happening in January next year so but I do like the idea uh as a gateway or bridge uh to cover the the big communities there there's overwhelming interest because previously the interest of interest was around Israel and then there's more and more interest uh from within China so it's a really good momentum there yeah thanks Charles we're really looking forward to it and and I guess uh this we haven't yet publicly announced the the hackathon yet but we should soon um so that's early January I think it's 7th and 8th is that correct um the dates we're looking at um yes yeah and I'm looking forward to getting out there as well and I think anybody on the TSC who you know uh could could make the trip would be uh well rewarded for doing that uh from uh just the community out there is tremendous the support from our partners you know Wanda, Huawei and IBM's China regional office has been really tremendous and so definitely encourage people if you've got the travel budget um to uh to find a way to get out there for that time we can make it really worth your while cool okay well um I'll put a proposal together for next week all right super um and I think I also heard you say you're sort of already putting out the call for yeah I'll do that yeah okay super all right well unless there's any other topics I think we can proceed to end of job and uh thank everybody and I'll see you all in about three weeks actually no that'll be Thanksgiving so I'll see you in a month thanks Chris ciao take care thank you