 and now the stupid recording now who is recording Brian took over I think good morning oh that's why it's not working thanks Brian it's like why can't I play most all right I've got over yes thanks thanks for pointing that out Gary totally utterly failed this morning all right I got minutes I got minutes so if you guys want to get going go for it are you going to display the agenda but at least we can see that Ry is a critical resource if I have been prepped if I have been prepped everything would have been just fine that's just me trying to scramble it you know because I have things I do he has things he does cross training is good yeah well it's just I'm quite entertained by this whole process this is very sad Gary Brian Brian can you stop the recording and restart because I don't think anybody's going to care to listen to any of these I think they might are now this banter is might be more exciting than the rest of the everybody will be as easily entertained as you Gary sorry it's okay we'll all fix it in post yeah we can do that I think I think you're passing judgments on the on the general population and underestimating them all right Gary one of those speakers to keep them occupied yeah Gary you must be really born in quarantine who is sharing looks like a rune is sharing a rune I don't know that this is intentional Dave can you share if not I'll share okay I'm trying to get back into the meeting six seven oh my goodness and I will I didn't okay share screen desktop I should hide my chat where I'm like talking about how you guys are terrible we're not seeing it can you share just the agenda there you go yep thank you but just the right I got you don't don't don't don't overwhelm Dave he's you can only handle one second of time right now it's too small Christmas available how's that oh yeah here we go small for Chris I can guarantee yes please thank you about Gary he's got old eyes no Gary oh don't just real you are okay enough guys let's be serious it's 10 minutes let's get started how's that we get everyone this is the weekly TSC call this is a public call everybody is welcome to join this name or contribute there are two requirements though you should be aware of the antitrust policy the notice of which is display and this is the hyperledger call of conduct which basically requires that you behave decently and participate in a positive manner so with that being taken care of we can move on to the agenda I don't have any announcement but I wanted to give everybody an opportunity to announce anything that would be relevant is there any announcement okay hearing none we'll just move on there were three quality reports submitted thank you for this looking through them I didn't see any questions or issues that the projects wanted to raise so I will just broadly ask if there's anything that TSC members or the people who have actually submitted the reports want to raise now if not we can just move on thank you there's one thing that I will point out is you know related to the discussion that we just started regarding the maintainers and the status of the implementation of the repo structure that we have agreed to we might want to add that to the quality reports and try to see if we should have some kind of like I don't call that like monitoring activity with regard to the compliance level of the project with the policies that we set forth but let's not get more into the detail of that now let's move on we have one major agenda item for today's call we have received officially a proposal for a new project it's actually graduation from a lab that has been existence for a while I was told by Fujitsu and Accenture and so hot are you the one who's going to present this I think we have a bunch of people that are going to present okay I'll take I'll let you take the lead and then you can you guys can figure out how you want to proceed sure well I think we have we have some slides that we can share if people want to see sort of an overview and summary of the project does that sound like a reasonable way to go awesome all right let me share my screen if that's okay thank you just to make sure we have everything we have everybody on yeah all yours are great Peter and Fujimoto son and Takuchi son are you guys all there yeah looks like we all know I think you're right okay can everybody see my screen yeah yes we can so so we'll start by offering some sort of background and motivation and solution details of what we're trying to do I think Dan O'Prey first put it this way at least to me that that we sort of live in it was briefly distorted but I could hear him up until you stopped him yeah hard can you repeat the last 10 15 seconds yes sure sorry and please feel free to interrupt with questions or comments or you know if my zoom has gone out and I'm just talking to myself in the room so today we live in a world of many networks and I believe it was Dan O'Prey who first coined this term at least when I heard it and this this has a lot of implications so here's an example of some sort of financial network today that you might see it's very simplified but the key point is all of these networks need to communicate with each other right everybody needs to share information my database needs to talk to your database and so forth well what happens when we throw blockchain in here as the HGF participants heard you know we might replace a lot of these databases with blockchain what happens then well now we replace these sort of networks with blockchains but you know we can't just run everything on one blockchain you know different blockchains are going to have different requirements so some blockchains might need you know a plug-in for distributed identity others might need scalability some you know blockchains or functionality is going to need you know extra cryptography some blockchains are going to need very high transaction speeds legacy compatibility is a big and unfortunate thing that I think a lot of people you're all distorted yes now I think we can I don't know what the issue is I'm sorry it sounds like you're swallowing your microphone sometimes that's unfortunate good it sounds good no great so anyway all of these blockchains making up all of these networks are going to have different requirements and so sometimes sort of conflicting requirements even so we've come to the conclusion that there is going to be no sort of one blockchain to rule them all and we can't just sort of dump everything on a single blockchain so with this in mind sort of a key facet of this diagram of how our networks are going to have to work together are these connections between blockchains and this is where we get into the motivation for the biff so the blockchain integration framework intends to define I guess a communication model to enable blockchain ecosystems to exchange any data or assets independent of the platform and without a middleman if needed and this is kind of the overall mission so before we go further some sort of basic core principles about this we want maximum possible plugability and generality so we've designed everything to be plug-and-play as much as possible this is incredibly important for something like interoperability when you know you're going to your whole point is to work with everything we don't want to have to go through a trust and intermediate blockchain or middleman if we don't have to there are some cases where we might absolutely have to but when we can avoid it we don't want to we don't want users to have to use tokens for transactions so many many public solutions in the interoperability space or token faced we found that users and customers we lost you again you swallowed your mic it almost sounds like there's some interference or something yeah are they using a wireless mic no can you guys hear me yeah we can hear you now said i was muted by the host i'm using a wired mic i don't know what the issue is okay i i muted you briefly the non-muted yeah sorry about that i guess my internet's just flaky i think everybody out here in california is on zoom no it's weird like crossover from another like like it sounds like when you're like driving between two radio zones and like you get over interference from a different radio station that's that's weird i'm sorry all right we'll keep going so i was just going through some core principles so i said we don't want to have users to have to use tokens and we don't want to have sort of a mandatory toll booth so we don't want to require operators to make money by taking a cut of transactions so you know you should be able to build a solution where sort of the incentives uh ensure that transactions will be handled appropriately so there are a lot of existing solutions in the interoperability space but sort of no existing solution really satisfies the the core principles we mentioned earlier so we needed a new way of essentially doing interoperability and so this you know we we talked from my perspective you know we came to this conclusion and then we we talked to some extension people and you know they had also come to a similar conclusion so once we realized that we both wanted to open source our solutions we decided it would be more efficient in the long run to work together so we currently have two working code bases one from each company and we're in the process of merging the code to build sort of a best of both world solution that gives us all of the use cases of both code bases so now i'm going to turn the presentation over to peter peter are you there do you want to uh do you want to take over from this slide yeah i can well i would ask does jimoto approach this on one team present peter you're super quiet all right well i guess i will stop sharing them and let you take over from here peter as well second i'll probably switch your microphone okay apparently the the first thing we all need to do is get new microphones let me know when you're ready peter did i cut out again no peter is on mute no we're just not quite tired of listening to you yet heart that's a surprise what if you multicast out your packets to all of us and then we'll randomly decide one of us will order those packets and then send them out oh that would be interesting does peter know he's on mute i don't know can you hear me better now yeah that's much better all right i'm gonna stop sharing peter and let you take over the slides from here okay go ahead okay we can see your screen can you see the slide yes yep go ahead all right so i'll start off with our short list design principles there's a much longer list in the white paper that we'll have a link for at the end or link to you so white support we wanted to support all the ledgers possible because that's pretty much the bad rock of the interoperability solution everybody will ask us the support is the support that and we want the answer to be either yes of course or well yes but we definitely or no but we definitely could this also leads to the plug in architecture that we are designing which i'll talk about much more in detail in the later slides so here i'll just mention that it's all about flexibility prevent double spending very applicable it's very important to say very applicable because we've concluded that there are edge cases that are simply out of scope not just for us but pretty much for anybody or anything who tries to prevent double spending when integrating different ledgers there's a little longer essay about this in the questions answers that we have produced as part of the feedback i believe that was already published by heart earlier now the gist of it is that everything's fine with prevent double spending if you have two permissioned ledgers for example but if you have one permission ledger and one permission less ledger with let's say proof of work as the consensus then you can never really be sure if there's going to be let's say a 51 percent attack on that ledger that completely erases all transaction history now you know people can always argue what's the probability of this happening or why would someone actually just completely erase the ledger but nevertheless it's possible so that's why it's important to say that we aim to prevent double spending very applicable preserving ledger features is about making sure that we don't just or we don't constrain the end users to this stripped down bare bones feature set that is the common denominator between the ledgers that they are transacting with because integration is nice but you also probably want to enjoy some of the higher level features uh and obviously sometimes these features we conflict with each other in you know ledger a and ledger p that you're transacting with but there can be a good enough abstraction on outside that allows the use of as many features as possible we just have to work on it and i will again invoke the plugin architecture here which we are going to depend on a lot to actually deliver on this design principle and then last but not least low impact we do not want some really heavy-handed solution as heart mentioned as well we do not want to be a middleman we want to be as easy to set up as possible and you do not want to have any unintended side effects so one of our main components in the system architecture is validators these are essentially validator nodes similar to uh normal nodes of a ledger or peers however you call them but uh they have the extra added capabilities uh injected from the framework which allow for signature validation so the validator nodes have a responsibility of being able to communicate with a specific ledger that the framework is connecting and i already mentioned the services that it provides we call them foreign validators uh from the perspective that a validator is able to give you an attestation of a certain state record of a given ledger and another question that came up was about corda so i wanted to stop here and and also mention here what i answered there which was that uh we tried to make very few assumptions about what a given ledger is and we try to keep the abstraction very simple so that as many of the ledgers as possible can be really fit in that definition because obviously if some ledger is so different from our abstraction then we just won't be able to work with it and so pretty much the only thing that we assume about a ledger is that it is a database with read write capabilities and with uh the capabilities they execute custom code uh you know aka the contracts and their custom code can also read and write the data so as long as you bring us a ledger that is capable of doing these things which is pretty much every ledger uh then our design the core of the design should allow us to write a so-called connector plugin for that ledger and uh all the higher level features that you may have are something that the other types of plugins that we have or will have in the future will be able to work with but the core functionality to be able to produce signatures for attestations of the states of the ledgers and to submit transactions to the ledgers ledgers so those core functionalities will operate as long as your ledger is a read write database with custom code execution capabilities some technical info about a project we use java scripts more specifically type script we type script we transpile from try to type script to java script and run it on Node.js but also planning on having a client-side SDK uh which actually should be universal in the sense that it runs on Node.js and the browser as well the plugin interface should is not constrained to java script only eventually it will be able to accept calls from any language without you actually having to write bindings for that language and a good idea we've seen elsewhere for this type of support is the go plugin which allows you to start your main application and then launch a grpc client and launch a binary which is the plugin which will host a grpc server and communication will be established between the two over http or more specifically grpc and this way your plugin can implement a well-defined interface api interface that is callable by the main code base and it does not matter what your language is what your choice language is for the plugin this is just for reference this is one of the many uh use cases that we've documented in the whitepaper i'll keep mentioning the whitepaper because that's our biggest uh most standalone document we have so i recommend that if you want to have a read then that's where to go basically what you see here is uh the biff api standing between the end users and the ledgers and giving you this common abstraction layer for those users to interact with the ledgers through this shows an idea of how the layers of the architecture are and this should give you an idea of what it is that you need to implement yourself if you are let's say in a an enterprise environment where you are an application developer who is tasked with writing an application against biff that uh makes some business case reality so the idea is that you deploy biff as a software and you either use the plugins that are already there or if you have some ledger that is not supported you can write your own plugin but the happy path is that you just clone biff from github you deploy it and then you start writing your own application where our SDK is a dependency and uh you just point that to your own biff deployment wherever that server cluster of servers is running and then you're good to go so under the hood this is uh going back to what the validator node is there's uh on chain logic which means that that's uh code that runs in smart contracts that we deploy through the chain this is uh why i mentioned in the beginning that the abstraction of ours needs custom code execution basically we put the public keys onto your smart contract as part of its state and then we use that to validate signatures so that uh the attestations can be created about the ledger's state and then on the off chain logic that's where it's really just a REST API with some endpoints on the validator node itself it's just a web application basically which is what you use or leverage to to build your business application that talks to it exporting requests means that you can send the REST API request to the server saying that you want uh let's say a block worth of data or some kind of state data on your ledger or export it to another ledger and then it gets copied over and you will have cryptographic proof from the original ledger that this was indeed the state on that ledger and now it has been copied over to the other ledger the plugin architecture so this is the backbone of it or because uh always the biggest question is well how do you know that this design is actually going to be worth anybody's time how do you know this will work in a few years and new ledgers come out with different ideas so my or our answer to that is nobody really knows the future but uh we are doing our best to prepare for it we really ask everyone to chime in on especially this because we believe in this particular sense we are doing the best we can to prepare for that unknown future and so the line is we want software that bends not breaks then major technological shifts occur and so far for this uh we have plugins or plans for plugins I should say with identity certificate authority ledger connector and storage now the storage is a little bit different from the ledger connector because you may want to store um certain metadata that you don't actually want to put on the ledger because maybe it's expensive to store data on your ledger or maybe it would be a performance bottleneck um you know maybe you're running a financial institution and there's some metadata about metadata about each transaction that you want saved and you want it in a database but you don't want it on the ledger so for that we also want a storage plugin separate from the ledger connector which at first sight it may look like they are kind of redundant of each other and the plugins are loaded at one time so that there's complete flexibility about how to uh compose your deployment meaning that before you deploy or before you actually start your deployment you have to provide the list of plugin IDs that you want loaded for the different purposes that are available and uh now I'm going into the open source ideas that we have the important thing to mention here is that if you want something supported by BEF you don't necessarily have to even come and talk to us like ever because with the previously mentioned mechanism what you can do is really just start your own GitHub repository uh have a look at our interface definition for that set plugin and start writing code and publish it put it on npm as a package for example and then the next thing you can do is just install that package specified to be loaded and used and as long as it doesn't actually crash your code that is then it should just work that's the idea and we really hope that this will make it easier to spring up a community of developers who look at this and say oh that's great because if I need something urgently I can just write it myself and I know from experience personal experience that there are people like that it's just not the majority but there are always people like that in the community and if you enable them they can contribute greatly yeah but you really have to give them the opportunity to do that and that's what we're trying to do okay so if you ask me what about supporting xyz this is always the workflow that my head or my mind will execute if there's a plugin already then good then you just use the plugin that's what I will say I will point you to the plugin if there isn't one then I will ask myself okay is this an aspect that's already pluginified such as the connectors storage or or is it something completely new but if it's an aspect that we already support via plugins then I'll just say well go implement your plugin and then use that plugin and you don't have to wait for my approval ever just do it and then there's the edge case which hopefully will happen rarely if we get the initial core design right uh so the edge case is that you asked for something that has no plugin to it and it's also just hard-coded in our core design instead of being pluggable so that's going to launch a review process on our side saying should we allow this to be pluginified and then you can submit a pull request to the actual biff repository and in this case you will have to go through you know the usual mundane review cycles everybody chiming in saying this is not right that's not right how about that but if you persist and everybody's happy and we approve it then we merge that in and then you can implement your plugin based on the interface that you just contributed to biff and then use that plugin but hopefully this is uh you know less than one percent of the cases that's what we are aiming to do yes I think I already talked about the storage plugin uh yes I'm just supposed to mention here that again it's a really really simple interface and I just wanted to show this as an example that this is how this is a plugin definition so when I say go and implement the plugin I really just mean go and write maybe a few lines of code or maybe a few hundred lines of code that implements an interface similar to this of course it's going it may be a different interface depending on what is it what plugin are you implementing and uh yeah so the storage plugin again I kind of already said this I just forgot that we had this slide here uh it's important to mention you know that we have two code bases and the fugeetzy code base called connection chain that's what already supports uh escrow moving of assets so the storage plugin idea actually came when we looked at each other's code base and I also wanted to emphasize that we are not running our own ledger we focus on integration not being a ledger of ledgers and yes this is the other design principle about preserving the ledger features and a great example is for example if you are doing a transaction between base even fabric and both of them have some sort of support for uh private transactions you know fabric has those uh private channels and uh basically have something as well I just forgot the name but the point is technically they are different features you know you cannot just put together a fabric and a basic ledger and they won't just be able to talk to each other but since functionally on a higher level of abstraction it's they are doing the same thing with private transactions uh that means that we could come up with the right uh interface definitions for that and allow a transaction to be private on both sides leveraging the different features that these ledgers offer now this is uh obviously much more complicated behind the scenes as I sounded it make it sound in my example uh but this is just the idea I'm not saying that we always support this just that this is how we are planning to implement it in the future and we'll just fix the gimmicks that come up in the meantime as we go hopefully and another important thing is uh the transaction proposal protocol that we have it we really wanted to be upfront about certain risks so that there's no unintended side effects this also goes back to double spending if uh you are on a permission ledger and someone proposes a transaction to you and they are on a permission less ledger with proof of work then we want you to see this right at the beginning when they propose a transaction so that you don't get uh duped into doing a transaction that you thought was safe in the sense that there is no double spending because we guarantee it but then there actually was no guarantee like that and then uh bad things happen so we want the protocol to do its best to push this out to the edge to the person who's making the decision to transact or not and uh the same can be said about private transactions as well just to get back to my example if only one side supports private transactions then there is absolutely no reasonable expectation of that transaction actually being private because you know that on the other side everything will be visible Peter I'm sorry I mean we are getting close to the end of the call and I'd like to keep some times at least the beginning for conversation so oh oh I'm sorry I kind of I kind of get lost in time though then uh I think I can just stop because most of it I already said performance yes performance I just want to say we don't want to be the bottleneck so if there's two ledgers and they're both very fast we want to be the fastest among those two ledgers so that they both can run at maximum speed uh this is our proposed position of the greenhouse as a project but we are absolutely open to feedback on that because uh we could explain it away in any direction really we have a road map that is strongly subject to change and we have some links and open source communities that's and ordinary questions all right thank you so do you see members in equations yeah this is Angelano um so would I would I actually personally would I also expecting from uh such a presentation was maybe I'm just biased and I might be totally wrong um I was expecting something so what is a blockchain is a system to build trust so bitcoin is the clear example here so it starts from the starting from minimal assumptions so in bitcoin what happens that you trust the crypto and on top of crypto you are building a payment system so trust in a payment system so now you are telling you you describe the system and you never talked about trust so and so if I want to combine multiple blockchain with their view of trust what it means to build a new level of trust this I was expecting actually like something like this from an interoperability project because there was what we are talking about yeah with the rest dpi gpi grpc these are all beautiful aspects I don't want to judge on this on this part but looking at blockchain maybe you had in the slide and we didn't have time to to see that part but I really would like to see what it means to build trust in this setting well my feedback to that or answer to that is that we intentionally did not speak that much of trust because in a sense you have to trust the organization that runs all biff so it doesn't matter if you individually trust the ledgers it's not going to be enough to transact between them you will have to trust this third party whoever that may be who runs the software that in that performs the integration between those so trust in that sense is sort of implied but it's a very long topic and I also want to and I also want to allow the other team members to chime in if they want to yeah sure I'll chime in so basically the idea here is that is that the trust is whatever you want it to be you know we want this to be as configurable as possible so I mean our basic philosophy is that we cannot say what your trust requirements are whether you know you're on this ledger are you going to trust someone on this other ledger you're exactly right that angelo that we probably should have given some examples but we wanted this to be sort of as up to the user as possible as part of the biff we don't want to dictate trust relationships between people we want them to be able to configure biff to whatever trust relationships already exist did they answer your question but definitely I would I would appreciate a lot if you can put also examples of this thing because you know why every time you see oh we'll we will like to I understand the point of seeing we want to be as general as possible but you know these are very complex system and if you leave the freedom at the such a freedom in the wrong hands this can be used I mean the problem people might believe that they are combining the pieces in the right way and that can be a total failure so sometimes maybe less generality more application scoping and say oh you know what if you have a if you have a a chain with this trust assumption another chain with this trust assumption or out of this you can build that is a new level of trust assumption that can provide an application on this level again the example of bitcoin is beautiful you start from trust in ecdSA and hash functions and on top of this you build a decentralized payment system on internet I mean which is a it's a great actually it's a massive achievement the guy who designed this would deserve at least a touring award so you see the you see the point that would give more confidence also in the fact that the framework can really deliver something useful but I really appreciate it really if I can no help also I would never definitely look at the document I think it's a very it's a very very interesting topic and we definitely have to as a TSC member I would like to to push for it as well so following up on this I wanted to get back to a little bit what Dan brought up in the on the mailing list which has to do with okay you have a lab today you guys brought both you know a bunch of code and so what is the status and I understand the idea of you know heart was quite frank about saying well the idea of part of the idea of bringing it up at a project level would be to have more exposure and bring more people in but beyond that I mean what has been basically achieved in the lab can you tell us that Can I talk a little from the Fujitsu? My name is Shinro Fujimato and to be honest I would like to have more resources for the collaboration since that we are certain the environment like we are restricted to the habit of opportunity to meet each other more closely so the at least we need to the mailing list to exchange the information or discussions nowadays we are doing the same things on the chat but it is very difficult to develop the or merging the code so the we need to do some the well openness for the development but that is more easier when we authorize other official project so that is my personal hope to be an official project thank you all right thank you I'm not sure I understood though you're saying as a project you'll be able to cooperate more easily I don't see that so I mean I think one of the things was we're doing a big refactoring of the architecture right to sort of merge everything together and one of the reasons we did this was to sort of get everybody's attention we know there are other people in hyper ledger that are interested in interoperability and we want to sort of bring everybody to the table and get feedback on our architecture and and everything like that and make sure it's make make sure it potentially works you know for everybody that might be interested rather than having sort of participants trickle in where we have to do major refactorings every time somebody comes in so that was a big motivation and so I had a question actually is the is the idea that if I have a beef in place my application will interact with all the networks only through this beef or is that something that I add to my application to interact with other networks so basically I could be a fabric application but at times I want to go talk to a Bezu network and then I have beef that I can rely on leverage to go talk to Bezu more in a more standard way or does beef become my kind of like higher level in which I interact with all the networks I want to use can I speak yeah well I think that we can develop your own application for the particular purposes right this is a kind of the template for the each use cases so if you are building to the shopping cart type of the application that you will use to the this integration framework as the infrastructure but if you need to do some other use case like a supply chain management they need to be you need to the another system using to the same integration framework but that service will be the running independently so the this is kind of rivalry type of the project so the we can minimize the such a building cost for the each application as a secure that is that is my assumption for the use of the project to resolve the derivatives is that answering your questions yeah I think so thanks we only have two minutes left I wanted to check that you know if there's any other members who have burning questions and maybe you know obviously we don't have time to close this today we'll follow up next week if it's possible but if there's anything people want to get that the the requesters could work on you know along the lines of what Angela asked for he wants more information than the trust assumptions and so is there anything else yeah we'd be happy to answer any questions via email or rocket chat or or whatever you like I know a lot of people have been asking in chat and I've sort of fallen behind on answering questions but if if you have questions please please follow up all right thanks heart and thanks to the team I mean for helping out and everybody to join in unfortunately we're out of time so I'm going to close the call on this but we'll continue next week as heart suggests it'd be best if we could make some progress on the mailing list in the meantime so let's keep the conversation going thank you all for joining talk to you next week