 You can start whenever you like. OK, awesome. Just like I would say, one more minute and then we start. I've added the live stream link in the Zoom chat. Cool. Thanks a lot. I do not open it at the moment because otherwise it's just, you know, I see myself live. It's just funny. Yeah, not totally, I get it. So let me just start slowly. Basically, I would just start my video for a second. Just I won't hold it on a very long term due to two reasons. For on the one hand, I mean, my bandwidth is not necessarily the best on the other hand. Actually, I've been working in home office for more than a year. So it might be not so practical in this sense. You know, I mean, just to just video myself. But your audio did pop up a little bit when you started sharing your video. Yeah, yeah, I was afraid of that. So let me just stop my video and then probably my audio will be really good again. So welcome, everybody. This is this is Hyperledger Budapest. It's basically a community blockchain consortium blockchain community meetup from from the Linux foundation and Hyperledger foundation. So it's a free community for knowledge sharing. Everybody is welcome to share ideas, ask questions, mostly on topics of consortium blockchains. And of course, Hyperledger products and different technologies. So what I prepared for today, that's a brief introduction on the European blockchain service infrastructure. It's called the EBSI. It's funny saying it's usually pronounced as just EBSI. I'm not quite sure why, if that's the French pronunciation or the Holland one. So I usually say it's EBSI just EBSI, but it means basically the European blockchain service infrastructure. And let me just start with a brief disclaimer. So I'm not a member and I can't speak on behalf of any organization participating in the EBSI. I'm just a freelancer blockchain software architect. And so basically I do a lot of things that I'm interested in. And what I'm going to present today is the publicly available information on the European blockchain service infrastructure, mostly on the technical side. So I will present actually the technical concepts and ideas behind the European blockchain service infrastructure. And so the main reason is actually that I'm interested in the topic. So it's not going to be something like a sales pitch or something similar. It will be just a technical concept, technical introduction for the most important concepts of the European blockchain service infrastructure. So let me just start with my presentation with a little bit like evolution of blockchains. And then so it might be the evolution, but I mean it's like comparing the different type of blockchains. We might argue that EBSI might be something new. Something a little bit different. We started somehow like 10 years ago. We published permissionless blockchains like Bitcoin followed by Ethereum like five years ago. And we got something might be as private blockchains. I would say private blockchains might not have much sense basically, because private blockchain is something which is a blockchain in one company, which usually doesn't really make sense. I mean, there might be one exception if you want to create something as a Byzantine for the current system. But I mean, never do I see even in such a case. I mean, I think using blockchain in just one company is pretty much an overkill. And we got, of course, something as a consortium blockchain. And of course, I mean, high-collegiate focuses mostly on consortium blockchains. I mean, the idea from consortium blockchains that we got a set of companies wanting to collaborate, wanting to share information or business process and all that kind of stuff. And for that, we use basically a consortium blockchain. And this might be a new category. We can argue that what we see here is a kind of special consortium blockchain. But I would argue it might be something more. And this is the appearance of national and cross-national blockchains. It might go a little bit again in the public blockchain direction, but I would say it's totally different from a public permissionless blockchain. I'm not sure if you guys are familiar, but the first version of such a national blockchain direction was actually Alastria. That's a national blockchain platform in Spain and Portugal. It was built by an Ethereum fork. I think it was a Quorum fork. So Quorum was a hyper leisure fork. And then Alastria forked again a Quorum. So this is more or less based on a consortium Ethereum network. And as far as I know, the second such a direction, which is not even national, but EU-wide blockchain network is basically the European blockchain service infrastructure. Just staying with the conceptual overview, I would argue that these types of blockchains might be a little bit different. So if we talk about type of blockchains, we should basically distinguish two kind of things. I mean, in terms of publicly or privately available. And I would distinguish basically the infrastructure layer. So this is like the infrastructure. And I would distinguish the infrastructure layer from the application one. So these are the servers that we put it that way. And these are the users, basically. And if we regard these things, I would say that we can really fine tune the previous slide. So we do not just have public permissionless networks and consortium ones, but something in between as well. Let me just have one more stuff here. So basically, I mean, the major category or the classical category is like Bitcoin and Ethereum. Bitcoin and Ethereum looks that way that both the infrastructure side and the consort and the application side. So the users side are public. So both sides are basically public and permissionless. We got the classical consortium direction. The classical consortium direction looks that way that we have the infrastructure layer as a consortium one. So basically, only companies in the consortium can run this service. And we got something as an application, as a user side. And basically, usually user side is consortium one as well. So it's a permissioned blockchain. Only people allowed to use this. So only people like, if there's like 15 company consortium network, then usually just people participating in this 15 company somehow can participate in the network from the user side as well. And there might appear a self category as well, which looks that way that the infrastructure side is strongly consortium. So we got just very specific companies running the nodes, running the infrastructure, running the blockchain, but the application and user side might be public. And the first example was actually the Facebook initial blockchain and cryptocurrency Libra, which did not succeed, but it had actually the same idea as well. And I would say that FC is going a little bit in this direction as well. So the infrastructure side is very strongly consortium running by the EU states, state members. And basically application side is not directly public because it targets for the first run like institutions, but the institution's gonna give on a long run something which is publicly available. So with this two up or off, I would say FC might go on a long run or is an example on a long run, something which is this category that it is strongly, it's a strongly consortium infrastructure that on a long run application, even if it's not directly, but indirectly with the help of institutions, we'll go to the public. Okay, so this was like just a little bit brief introduction on blockchain and blockchain types and technology. And let me just start back with the background of the European Blockchain Service Infrastructure. So the whole stuff started actually with the European Blockchain Partnership. It was basically an EU-wide collaboration attempt to increase blockchain adaptation and basically the blockchain technology acceptance and use cases and ideas within the EU member states. And as far as I know, it started in 2017, if I'm not mistaken. And it has actually more than one initiative. So they do a lot like regulation and stuff like that. But one of the real technical initiative is launching the European Blockchain Service Infrastructure which is basically an initiative for making, for realizing a cross-border blockchain that provides services for public institutions and with the help of public institutions, I mean like government institutions, with the help of these institutions to EU citizens as well. So this is the idea of EPC and this is the direction. And so as I mentioned, basically the nodes are, and the services as well are distributed within the EU member states. So if I just go back to this direction, I'm not particularly sure if that's the current state or the most up to this state, but these are the nodes in the EPC network. So as you can see, there are, I mean most EU member states run at least one mode. There are some exceptions, not running, still not running the node. And there are some member states running actually more than one node. And basically this is the EPC network from the infrastructure side, from the node sites, from the peer-to-peer network side. So this was actually the introduction. And after that, I would discover some of the ideas of the architecture of EPC. And then after that, some of the, let me put it that way, some of the use cases and possible business applications that are already running on the network. So again, this is not a sales pitch. I'm gonna be concept here, but I remain on the technical level. So the idea of EPC, of the infrastructure, is to build up, so the idea is not to build up something as a brand new platform, a brand new core blockchain technology. It's like not, you know, I mean, not something like EOS, and we say, hey, we can do better, better Ethereum or we can do better, better high-paragraph fabric. But basically the idea is more like architectural, having something as a layered and pluggable architecture that can integrate already existing blockchain platforms as well. So that's the main idea. And it looks that way, that it has like five different layers, basically four of them exist already. So that's the core blockchain technology. Actually there are two, as far as I know, at least two technologies inside. One is basically hyper ledger fabric that is integrated and the other one is Ethereum consortium. And there might be actually hyper ledger in the as well, but I'm not quite sure about that. So there are a lot of hyper ledger connections, I would say. But anyway, the major idea is that we got something as a general architecture containing four core layers and one business application layers. And then this layered and pluggable architecture will provide basically use cases and business applications in a stable and pluggable way. So let's start just by introducing some of the layers. So just going from the top to the bottom, I would say the first layer, I mean the bottom layer is the infrastructure. Infrastructure is practically a containerized infrastructure. So it contains something as images both in terms of virtual machine images and in terms of like Docker images as well. Containers, the usual tools for delivering these images. It's like container orchestration, staffs automation monitoring and stuff like that. That's practically the infrastructure layer. The second one might be a little bit more exciting. It contains the state chain and storage layer. And again, so the idea is here that within this layer, there might be the possibility to integrate more than one or even on a long run, more than two or three different blockchain, existing blockchain platforms. So at the moment, there are two blockchains integrated here. The chain and storage layer. One is hyperledger fabric. And the second one is a consortium ethereum. Sorry, that's wrong here in the slide, but that's a consortium ethereum network, which is realized by hyperledger Bezu. Hyperledger Bezu is basically an ethereum client with which you can build up. So the major direction is building a consortium network, but you can build up actually ethereum public networks as well as far as I know. So that's like the chain and storage layer. And of course, we get some other components in the chain and storage layer. Like you can write smart contracts. Of course, you can write smart contracts on hyperledger fabric or on ethereum. So the two programming languages is one is Google for February, as far as I know only Google. The second one is basically it's solidity. We support it as far as I know. We got something as blockchain explorer as well. So like this is a blockchain, not quite sure if I find it, but yeah, like this is one of the, actually there are two explorers because of the two technologies. So like this is an ethereum explorer for the FC network, for the ethereum consortium part. And then, so this is basically an open source ethereum explorer. Nothing special, so you can see the blocks. You can see the, I'm not quite sure how it's encoded, but some of the transactions and stuffs like that. I don't know, let me just find the transaction. Ashburn, so I don't know, but I should somewhere see actually the transactions as well. Anyway, so this is like a classical ethereum blockchain explorer. Nothing special, this is basically an open source project building up consortium ethereum explorers. So, and what we got here at the same chain and storage layer, that's another part which might be exciting, which is an off chain storage service. The main reason is for that, is that the most large chain or most decentralized larger application is not built up solely with the help of a blockchain. I mean, especially not in Europe because we got this GDPR regulation, which is pretty challenging in terms of blockchain. And so basically if you want to store data on the blockchain, it is challenging at all, it is challenging because I mean, blockchain do not store very well a lot of data, but it is even more challenging in EU because if you coincidentally store data with personal information, it's not something that can be deleted. So it's not GDPR compliant and you're gonna have a lot of problems with that. So basically most of the high-pollager or ethereum applications running in a consortium setup has something as an off chain component and we got here something as an off chain service for this. So off chain service looks that way, we can store something as files, actually relational database tables, something as key values, basically, and even some big data. And we can just combine this data with the blockchain like hashing the data and writing into the chain. And there are three different kinds of off chain storage. One is basically this sort of distributed storage. Distributed storage looks that way, that we got basically the nodes, these are the nodes, running throughout Europe at member states and each node has something as a data store, which is a distributed data storage. So each piece of information is replicated throughout the whole network. So if I put a piece of information here, that's gonna be replicated actually at each and every node on the blockchain network. It is certainly not necessarily the best idea for some of the use cases. So for this reason, we got something as a private storage as well. Private storage is just a private storage for one specific node where you can store some data and it is not replicated throughout the network, or usually actually the idea is that every node can store something in the private storage and there might be some custom application or custom implemented application as well that is sort of use cases might get one of the data from private store off chain store to another one. And there's a possibility as well to integrate external storage providers as well. It's like AWS storage or even Dropbox perhaps possible. So that's probably the most important layer from a technical perspective, of course, that's the chain and storage layer. We get something as a core services as a next layer. On the one hand core services provide basically abstract functionalities for the underlying layers. So it looks that if you get a use case or a business application, it doesn't directly work with the underlying blockchain, but it does with the help of some core services. So in this sense core services abstract available with the functionality of the underlying infrastructure. So in this sense, if there's gonna be something as a, I mean, getting the new blockchain platform in the chain and storage layer or upgrading something in the chain and storage layer, then it might not affect very much the business applications or the use cases. We get some core services like identity, like decentralized identity, wallet services, some off chain storage services and so on. And last but not least, we get something as use cases. So use cases basically, at the moment, these are use cases for public institutions. So like public and government institutions, these are the use cases. We still do not really have this business application layer. This business application layer coming more and more in the future with the help of use cases as well. And it might provide functionality not just for like public institutions, but for the private sector as well. But anyway, we get like four use cases at the moment. And I think there are three more which are not very much documented. So I will just refer them. I can't say much about them. Basically, we have two different kind of applications. And one is something in the direction of verifying data. So you might know basically one general use case of blockchain is that we have basically data somewhere and we want to be sure that this data is not changed. I mean, very simply put. I mean, the use cases are more complicated but in a simple sense, this looks that way. We got to the blockchain. And let me say we have here something as a document. So what we do basically is that we extend this document with some metadata. It's like the creation of the document or a timestamp or the signing of the document or something similar. We hash it together and we write it to the blockchain. So this looks very simple, but there are a lot of use cases that uses this technique. So what you can do like, for instance, if you just store this document like on an archive and then you just pull out this document like after five years or 10 years, then you can make sure that the document wasn't tampered. It's because you just see the document version, you hash it again and then you check if that data is the same actually in the blockchain. This is like one application. The other one is that you can send this document to somebody or perhaps it's not a document. It can be like, again, just a piece of any kind of data. So you can send this document to somebody, to another organization, for instance, and the organization can again check if this document wasn't tampered. If that's the correct version, simply by checking the document, having the metadata, hashing it together and checking again if the hashes are the same. So these are the basically the use cases. And we got two use cases that build up with this idea. One is the notarization service. It's like notarized documents. Check if the documents are valid, if they weren't tampered, if the timestamp wasn't tampered, somehow it wasn't faked or modified and so on. So basically this is something which is the same idea for documents or for legal documents. And there's something which is trusted data sharing. Trusted data sharing is something, some kind of a data sharing service between as far as I know, text authorities for kind of a value-added text administration. I don't know much about it actually, but as far as I know, it has the same structure. So we get not documents, but kind of a data that is basically hashed, written into the blockchain, sent to another party and basically the other party can check it that if the team formation is still valid. And we got two other kind of applications, use cases, which are more technical, a little bit in details. So I'm gonna talk about them a little bit more. This is the diploma service. It's a diploma issuing service. And we got something as an initiative for a European sales or an identity service. So these two items are a little bit more, so let me put it that way, technically challenging and the ideas might not be so, so the ideas behind are a little bit more counterintuitive. So I will just introduce them a little bit more in details what's behind these two services from a conceptual point of view, okay? And basically, let me just start. So what we're gonna talk about in the next couple of slides, it's five slides, I guess. This is the blockchain and identity stack. And so speaking on a blockchain and identity stack, let me just take a look on the example of issuing the diploma. It's a degree, but I'm not quite sure. I wouldn't say, I think diploma is English as well. Sometimes I'm not quite sure. It's like, I mean, in Europe, we have sometimes with this continental English, which might have some special words. But anyway, so let me just see the idea that basically I get a diploma from a university and then I have this diploma, okay? So in this model, for the first round, we have something as two rows, two major rows. We got something as an issuer. The issuer is basically the university giving from your diploma. And I'm the holder of the diploma. So as soon as I got this diploma, I am holding this diploma basically. And there's a third party as well that's the verifier. So supposing I'm looking for a new job and then there's an employer wanting to see my diploma, then basically I can present this diploma and then my probably future employer can check if this diploma is really, yeah, I mean, really worth something or not. So speaking of blockchain and identity, this is the major model that we should start with. We got an issuer, we got the holder and we got the verifier. It's like issuer is again like a university issuing a diploma, that's a permit here, but they just imagine that's a diploma. I'm holding or anybody can hold this diploma and basically this diploma can be presented to a verifier that can be an employer, for instance, or a future employer. So giving a little bit more in this model, we get something as a verifiable data registry. So the point is basically that, I mean, so let me just imagine I got, there's an issuer issuing the diploma, I'm holding the diploma and so the question is, what prevents me to forge this diploma or to fake this diploma or just to rewrite this diploma somehow? The point is that, I mean, this diploma issuing use case works pretty well if we have something as a paper. It has been working like for, I don't know, 200 years, but since getting fully digital, so the same idea is not necessarily the best idea. So just going a bit further with this model, let me imagine that I got a diploma, sorry, I got a university issuing the diploma for me, that with issuing this diploma, this diploma is somehow registered into a publicly verifiable data registry. So as soon as I'm having this diploma and I want to present this diploma to a verifier, to my future employer, then what I'm doing, I'm presenting this diploma, but the verifier can see my diploma as well, but they can somehow take a look on this publicly verifiable data registry as well and check if my diploma was rewritten somehow or not. So this is the basic model of verifiable credential without blockchain. And what we're gonna do is that we place this whole model to the blockchain. So we got an issuer again, we got the holder, we got the verifier, and we got something as a verifiable data register. So the question is how we put this whole stuff on the top of a blockchain. This is the diploma like, I got something as a diploma, I got an issuer, I got a name, and I get a lot of information, like I mean, I finished in the business administration and it was taking three years. I got an excellent grade at the end, but it's like an accounting, I wasn't so good in international business, I was good in marketing, I was excellent and so on and so on. So this is basically the piece of paper. It's called the credential that we want to put actually on the top of a blockchain in a fully digitalized form. So how do we do it? So the first idea is intuitive. We say that the verifiable data registry is the blockchain. So we got this diploma. We don't write the diploma into the blockchain itself. It's because of GDPR, you can do it, but I mean, having the previous example, what we can do, we can hash together this diploma and write to the blockchain to the publicly verifiable data registry. So it means as soon as the holder presents this diploma to a verifier, the verifier can hash together this diploma again and can take a look at the verifiable data registry and can check if this is the correct diploma or not. So like possible forges, like, I mean, in my diploma, it says like accounting good, but supposing that I forge or I've made some modification in my diploma and then I see my diploma that here from accounting, I was excellent. And this is a forged diploma in a sense. The verifier can take a look in the publicly verifiable data registry and of course, if I rewrite here that accounting instead of good, it's excellent. Then certainly the hash of the whole diploma will be different. So this forging will be more actually pretty fast. So this is the first idea. The second idea is that we shouldn't find something like the issuer identity or the holder identity into the blockchain. And to understand this, let's just take a look in the classical blockchain example. So if it's somewhere like a Bitcoin or an Ethereum address, you know what I mean? In Bitcoin or in Ethereum, your public key is practically your identity. So if you have a public key, then we can regard like blockchain, like Ethereum or Bitcoin in a direction that your public address holds basically the crypto coins. So basically your public address is basically your identity. And what you can do is that you can spend your money. And if you spend your money, you can do it in a way that you sign with your private key. And basically if you sign your private key, you say that, hey, this is me, this is my identity, and you can spend your coin from your identity. So having this idea, we can say that issuer and basically holder shouldn't be something as names. So if I'm written in the diploma, it has some problems, actually. It would be better to use a structure where there's no identity like this in my diploma, in my verify book, like a credential. So what I basically do, I get an issuer, that's a university, and the university doesn't write the university, or not necessarily write the university into the diploma, but what they do is that they get practically a public and private key, and then the public key in this sense is the identity of the issuer. So what the issuer says, it writes the public key of the issuer into the diploma, which is practically the cryptographic identity of the issuer, and then it signs with the private key diploma. And there's one more information. There should be a public information from the issuer public key, that like this university will sign documents with these key pairs. So in this sense, issuer identity is basically a pair of keys, it's basically a public key. And the basically holder identity can be the same. So what I can do, my name is not written at all in my diploma, but basically what I can do is that I generate a pair of keys, a public key and a private key, and I say issue my diploma to this public key. Okay, so basically instead of the name, instead of charts, my public key is written into the diploma, and I can prove that this diploma is related to me, so I'm holding this diploma in a way that I have actually the private key for this public key, and I can sign again the document with this private key. And then in this sense, with this digital signature, I can prove to the verifier cryptographically that I'm owning, I'm holding this diploma. So again, three ideas putting everything into the blockchain. First, hashing the diploma together and then writing it to the blockchain. The second one is instead of identities using like public private key pairs. That's the main idea for the verifiable credential model, and that's the main idea for the blockchain and identity stack. Things are getting a little bit more complicated because we don't say like public and private keys, usually say decentralized identifier. This is usually the public key that I was referring previously, but it looks that way that this private key has a lot of like meta information. So we get some like more information with which cryptographically tool did we create this, how we can sign and stuff like that. But we can imagine that this is our like extended public key, which is kind of an identifier, kind of cryptographically identifier. And the idea behind blockchain and identity stack that there's an end user, this is the end user, and basically the end user got the wallet. And the wallet doesn't store, I mean the wallet won't store actually coins, not in Bitcoin or in it or with Ethereum, but the wallet stores actually public and private keys, but as opposed to like a Bitcoin use case, these public and private keys are not used for transferring coin, but for proving identity. So what we got here is that these digital wallet with these so-called decentralized identifiers, basically one of my identity fires is related for instance with a diploma. There can be another decentralized identifier that I use with some online services. There can be a decentralized identifier that is actually a government issued digital ID or driving license or some kind of a, I don't know, hospital staffs document that was issued to me. And basically everything is stored in this wallet as practically public private keys, not exactly public keys, but it's with more these DIDs. And if I want to do something, then basically with an online service, what I have to do is that I have to move my identity, which means getting my wallet that stores basically these DIDs and with the finding the necessary DID and making a signature with my private key related to my DID, basically. So this is how DID look like. We get some scheme, we get some method, and basically it's an identifier. It's like an address or a public key with Bitcoin or with ETU. And we got the DID document as well. DID document describes stuff like with which cryptography should I, should I somehow sign this or use this, some meta information and then stuff like that. So with this stack, this is the so-called, I mean, we covered basically the D-plomb, but the Europe itself, so our identity system goes beyond with one step of the D-plom use case. And this is the general architecture, like issuing such verifiable credential. So basically we got the same elements. We got like issuer, issuer can issue like these verifiable credentials. It can be like postal address, it can be D-plom, it can be a national ID as well. We got further holding this DID identity wallet, having the keys and then related to these keys, there are these documents like diplomas, like some kind of an official certification and postal address, or even official national ID cards. We got of course the blockchain, that's the European social identity system blockchain, having the cash values of the verifiable credentials and public keys, so not keys, but public DIDs for institutions issuing the different credentials. And of course we got verifiers, so verifier can like, for instance, verify if a diploma is valid, if it was issued by a certain issuer and if it is related to the holder. So that's the idea of European social identity system and that was the first use case. Again, there are three more use cases, but they are not so much described actually and published, so I don't know much about them. What's lastly, I would just a little bit highlight is basically the FC roadmap. It's a little bit old, but it looks that way that it started in 2019. These are the four use cases that are implemented in 2020, there are like three more use cases and basically every year there's something as an initiative for new use cases. So like I will show some of the links perhaps, but even at the moment I think there's like an active phase for getting new use cases and new applications on the FC network. So if you just take a look on the slides or the websites, then then you find some information. It targets, it still targets mostly public EU institutions. So like, I mean, if you like just a freelancer architect and wanting to do something, then probably you need a public EU institution for that. There's something as a demonstration as well. It doesn't work at the moment, but I can show something on that. So it looks that way. This is the FC user journey demo and it looks that way that these use cases are demonstrated. So first, what you have to do is to create an FC wallet. The FC wallet stores your DIDs and we have the IDs you can get practically, I mean, you can have access for the rest of the services. So if you have your DIDs, you can get your DID that's a demonstration of digital identification card as a verifiable credential. If you have your official DID, then you can get your bachelor's diploma for that. You can get your master's diploma and even you can authorize documents as well. I'm just checking it very fast. It might work, but I think there was an error on that. So I'm not quite sure if it was repaired in the meantime. So first you need basically a general login, but I think I have my general login and then you can create a new wallet and again, your wallet stores basically your DIDs. So it's keys, but it's not a crypto wallet. It's an identity wallet. So this is my wallet and then it doesn't work. There's some error in that. But supposing that it works, you can check these use cases. Let me just check one more. So like getting your DID, I think it somehow my wallet wasn't generated very well. So I will still get an error here. So I should just log in. Yes, so there's some error with my DID wallet. I don't know exactly, but anyway, you can find the links here. You can find the demo for all of the use cases, just general for the wallet, for European sales of online entity. It's like issuing ID card that was demonstrated by the by the Belgium government. It's like issuing diploma, having the authorization and trusted data sharing use case as well. Some links and links function before these slides. So first, if you're interested more on the app see from a technical point of view, and let me just take a look if that works. So basically you find a lot of information in the internet. This is like the technical infrastructure, but you find something as like, if you want to pilot a new application, you have something as a pitch deck for there and some more information. Let me just go off. Just taking a while because my network is not so strong. So it's like streaming and checking the slides is not something which goes very well. But anyway, so this is the major side or major, major side for app see. So if you just say get started with app see, you have something as a learning package as well. And if you go to the burn learning package, you find some contacts as well. If you like want to do our pilots or pilot application, basically again, it's for public institutions for the first time. And it's still loading that there's one other link. You find representatives for each country in EU. So if you are somehow related in one country in the EU, then you can find the official representative and then you can get more information from there as well. So you have here something as these slides are more, I mean, more marketing oriented. So not so much technical as I presented here, but you find some cool materials actually on this side. So I think that was my presentation and we still have time for a brief Q&A. So anybody having questions, then please feel free to ask. Hi. Hi. I think you enter design based on trust over IP. So you have designed issuer, verifier and holder also. So my question is nowadays we are hearing about multi-host. So how do you think about that in your system? What actually your design purpose or how actually you deploy it on cloud? What's your core architecture design? Can you share with us? I mean, it's like multi-host, did I get it? Multi-host to deploy. Yeah, yeah. Yeah, that's a very good point. So I'm not quite sure. Again, I'm not so much deep inside in the exact implementation of EPC, but so basically what you do, you get the blockchain system usually. It looks that way, it has like layers. So you have something as a virtual machine. And after that, you get something as a containerized infrastructure. And based on these two staffs, you have something that's your business application. So what you can do if you like want to hosting staffs in multi-host, multi-cloud, multi-technology. I mean, one way is getting to the virtual machine aside and saying, hey, I got several notes. I got my virtual machines that are fixed. So I say, which is the virtual machine I want to use. And then I can run one virtual machine in like, I don't know, like on-premise. The other one, basically it's like the Amazon cloud, the third one in the Google cloud, and so on. And then that means that you separated your blockchain level on a virtual, blockchain network on a virtual machine level. Each, I mean, the virtual machine type is the same, but each virtual machine running on a totally different host, even on a totally different cloud, even in with totally different hosting technologies. And despite, if everything goes well, then these virtual machines can communicate with each other. And then you got your blockchain network up and running. That's one way. You can move one section level higher and you say that you have something as a container. So you get something as a container as infrastructure. So you don't care how the virtual machines are actually implemented, but you say, hey, I want to run everything as Docker components. So like provide me something that can run my Docker components. And I don't care which is the virtualization technique you use. I don't really care which is the, you know, physical operation system or which is the any kind of other technology. I just need some container orchestration, some infrastructure that runs my Docker containers. And if that works, I mean, there's like networks and stuff like that, then you deployed your blockchain network on a multi-cloud, multi-host, even mixed on-premise cloud and multi-technology environment. As far as I know, and I'm not that sure, based on the documentation, there's virtual machine and Docker layer as well in the FC infrastructure. I can't say stuff like that. You absolutely need the virtual machine or it's enough if you have your Docker components. I'm not that sure about that, but these are the two fundamental levels as running your network. As multi-hosts, even multi-cloud, even hybrid on-prem multi-cloud environment. Okay, thanks for your information. I got it. But the question arise from some developers. Some developers and the internet, they are claimed that hyperledger fabrics by default don't provide decentralized. That's why they claim that we need multi-host deployment. I mean, issuer, verifier or holder, they may be order a node and maybe they are another node, CA node, certificate authority node and other PR node. They distributed them in different VM, right? And they try to prove that every VM are distributed and they can hold same hyperledger project. In that way, they try to prove we are getting decentralized capability from hyperledger. But the documentation from hyperledger fabrics, there is actually no good way or no good discussion about that. But some of developers are claim that. So that's why maybe I and many developers who are trying to learn for production, they are confused about that. What actually your opinion based on your experience, is it actually we need multi-host to get the power of decentralized form hyperledger fabrics? I already know about that hyperledger fabrics, one chain, in a one chain, how much PRs are available, they hold chain code and also every chain code means some smart contract, which is smart contract actually represent distributed laser, right? So we already know about from hyperledger documentation but it means that hyperledger by default in one chain, we get some decentralized power. But why need actually extra virtual machine setup? I actually can't understand that point. Can you share your opinion? So I mean regarding FC, this information is not available. So regarding FC, there's no information how hyperledger fabric built in the system or any specific such information. So I can't say more. You can take a look actually on the technical documentation, but basically even technical documentation says, I think that you get like two block chains, and then basically this plug-able protocols are implemented with the help of hyperledger fabric and consortium material with hyperledger Bezu. And there might be some further protocols in consideration as well. How it is exactly implemented, there's no publicly available information on that, but you can take a look on the documentation as well. So regarding FC, I can't say anything. If we just change it with focus and then we say, like, let's have something as hyperledger fabric without FC. So basically it looks that way. I mean, it's the question, how do we want to build up your network? So usually you get one company with one infrastructure, another company with other infrastructure, the third one with the third infrastructure, and then these might be VMs and like some, I don't know, you need something as a docker swarm on that. And then it's the question if you have like one docker swarm or several docker swarm. And then after that, there's one more layer as well where you distribute your fabric components as well. So like you can have something as an ordering service and you can have like distributed ordering service. You can have ordering service concentrated on one element. You can have something as peers. And then the question is where are the peers? And then you can have some certificate authorities as well. And then you can have some certificate authorities as well. So basically it's a pretty complicated design challenge, designing your hyperledger fabric network. First question is usually how your fabric infrastructure look like, how it is distributed among the different participants, different organizations, then you can go one level deeper and then you can make some considerations as well how your core infrastructure look like. If it's like docker swarm or if it's like Kubernetes, do you want to use one Kubernetes cluster or perhaps more than one? And then how the stuff is implemented on a virtual machine layer. So these are like at least three big areas where you can consider two and three, where you can consider something as centralization or decentralization. So I don't have like, you know, I mean, magic bullets here or magic source here that I can answer like in two minutes. Yeah, I got your good point. Ultimately they are in one network, right? However VM they are used, it's not most important. I mean, the question is what do you mean by network? It's like, again, is it a hyperledger fabric network? So are we at the level of, you know, Pierce and ordering service and certificate authorities? Is it like on an infrastructure layer? So I will speak about like docker swarm or I will speak about like Kubernetes. Is it one Kubernetes cluster? Is it more than one Kubernetes cluster? And then how the virtual machine structure. So these are like three different stuffs that can be taken into consideration. Okay. Okay, then my final question is, how actually you used, how much VM actually you used for this project for hyperledger fabrics? Can you share with us? So we can get more information that, oh, okay, someone is building top on that architecture. That will be more helpful to get more confidence. So what you basically need, you need this layer and this layer as far as I know, can be like docker swarm or Kubernetes. It can be actually any kind of orchestration theoretically, but you find the most information and most examples from hyperledger fabric infrastructure actually on docker. So you can see docker swarm and the second one is Kubernetes. So you need this layer. This can be like, again, docker swarm or Kubernetes. And if you have this layer, then you can separate the task into two parts. First, basically for the fabric network, it doesn't map, I mean, for the fabric map network, it's something which is running the images practically. So it's almost separated from the virtual machines. And then you can go down and then take a look how practically like docker swarm need to be implemented with the help of virtual machines. And then you need basically virtual machines for your docker swarm implementation. So again, you don't consider directly hyperledger fabric and then virtual machines. You consider hyperledger fabric with the help of an orchestration tool and this orchestration tool is like docker swarm or Kubernetes and you consider virtual machines for your orchestration, for your dockerized environment or containerized environment. Okay, okay, thank you a lot. You're welcome. So let me just take a look if we have some more questions. So we don't have more questions here, I think. But in the meantime, let me just know if you have question. I just stop here this sharing and I take a look if we have questions on the YouTube channel. So let me just take a look if we have some more questions. So there's one more question if we can connect hyperledger with embedded systems. So yeah, good question. As far as I know there are initiatives integrating the directly hardware devices with hyperledger fabric, but I'm not quite sure about the details. So you can take a look actually. There are some research papers as far as I know. They investigated the area in the direction. If it's, I mean, not just, if technically a hardware device can be somehow integrated with hyperledger fabric, but if there's a possibility of having the transaction speed of integrating hyperledger fabric and then embedded device. And then, so there might be the answer that in very special cases, you can have a couple of, it's like 1,000 or 2,000 transactions per second as well. So it might be possible to integrate an embedded system with hyperledger fabric. It means integrating. So you come from your hyperledger fabric on an embedded system if there's the question. So I don't know if there's further questions. If not, I would say that's the end of my presentation. Thank you very much for your attention. Then I'm sharing with you the slides as well. So thank you very much again and take care and bye. Thanks Daniel. Thanks everyone.