 Hello everyone. Thanks for joining this session. There are more people than I expected, almost a full house, so thanks a lot. My name is Cilla Jigri and I'm VP of strategy at BTP. We are an enterprise blockchain company. And what we are going to do in this session is to demonstrate how easy it is to deploy an enterprise blockchain stack on top of Kubernetes and using our management and operations platform. But before that, I wanted to set the context a little bit. We are going to say things like hyperledger saw, tooth base, smart contracts, things like that. And I want to have a common understanding of where these different things fit. So just to spend a few minutes on the big picture, if it works, yes. So this landscape shows the broader distributed ledger technology space. We use DLT as the umbrella term. Blockchain would be a type of ledger technology. And I don't think you'll be surprised to see that the landscape starts with the computing infrastructure layer that obviously underpins a lot of things and DLT is no exception in that. Here you will see the typical cloud providers, AWS and so on. You can see things like Susie Rancher as well. There is a little delay. And also container orchestration tools like Kubernetes. We actually extensively use this tool in our platform. So essentially, a DLT-based application, well, a DLT-based network and an application on top can be deployed in the cloud. It can be deployed on premises and in a mix of these two environments. Then the next layer is made up of the core distributed ledgers. We differentiate between permission less permission than hybrid protocols. Right now companies are using a number of these. We are sort of living in a multi-chain or multi-ledger world. They choose one based on their requirements, based experience or skills that they have or vendor relationships and so on. So a few maybe, obviously, you may know the Hyperledger Foundation is part of the Linux Foundation. They have a few projects in this layer. Hyperledger Bezu would be one, which is actually one of the protocols that we support. Another example would be Hyperledger Bezu. If we move up also, I always like to say that blockchain technology doesn't stand on its own and it's used in combination with obviously other technologies as well, whether those are established ones or emerging ones. It could be something very simple as we all know distributed file systems. We have been using them for years, but you can put a distributed ledger underneath and then make it more decentralized. Also, for example, blockchain can be used in conjunction with artificial intelligence, with IoT. There's actually a very cool project. For example, Helium, they provide a decentralized wireless infrastructure for this short range type of IoT. It's a very cool project. So they take advantage of different technologies in combination. Then if we move up the stack, interoperability, obviously that's important everywhere because, again, we are in a multi-ledger or multi-chain world, so you have to make these things work together and also legacy systems used by different enterprises. You want to make sure that, for example, you can interact and transact across different systems as smooth as possible, seamlessly as possible. This is a very fragmented space still, but there are a number of projects that are focusing actually on this as well as different standards organizations. Then if we move up, obviously smart contracts and asset tokenization, it's a very important layer in this space. Smart contracts are known as transaction protocols that run on a distributed ledger, but they can also run on a database, but I would always prefer that they run on a distributed ledger. Smart contracts essentially just automate and formalize relationships between organizations, individuals, and even machines when it comes to IoT type of use cases. Asset tokenization has been, now we talk a lot about cryptocurrencies and so on, but other type of assets can also be tokenized and we can move them or trade them on a distributed ledger and using smart contracts and so on. Then the next layer comprises all the tooling for developers that can, both developers and users, just to make their lives easier and also the integrations with existing business applications that have been around for years, but now you can enhance that with the distributed ledger, enhance them with just integrating smart contracts and so on. Then on top of all this stack, you can find a wide range of industry specific applications, decentralized marketplaces, across many, many industries. For the sake of this presentation today, the important thing is that obviously as you can see, this is not, this is pretty complex. There are a lot of moving parts that need to work together. Many organizations don't have the expertise, so there are companies that actually can make this easy for organizations and we are in the platform space, which you can see on the left-hand side. We are BTP. We have this management operations platform that is called Sextant. We are essentially, what we do is basically just provide all the technology infrastructure and the tools that you need to be able to build multiparty applications. Then obviously there are other companies in our space as well as in the professional services space that they would even help you with business requirements and help you, you know, wherever you have a use case, just build everything from scratch and even, you know, deploy it for you and so on. So this is the big picture and now I'm going back to, because now is where Sextant comes into the picture. Again, you know, the basic value proposition of this platform is just to make it easy for you to build multiparty applications so you don't have to worry about that, you know, painful underlying technology infrastructure. We can, you know, Sextant can do that for you. So Sextant, very briefly, it's a Kubernetes-native management and operations platform. It can, yeah, it deploys and manages, you know, a range of blockchain protocols. Mostly we are mostly focusing on permission and hybrid type, not so much on the permissionless ones. Sextant also can overlay support for smart contract runtime environments. We now support two smart languages, one is Digital Assets Demo Language and the World Wide Web Consortium's Web Assembly Language. And we can also, you know, use Sextant to deploy Decentral, as I mentioned, earlier Decentral X file systems, document management systems, and go on for, you know, any type of business critical data. And then we have, there's some, actually, something new. We recently launched a provenance solution. There's also a powered by Sextant, which essentially provides you with the capability to track, you know, any type of physical digital asset immutably. So the good thing about Sextant, I guess, that we package it, we provide, you know, long-term support. Duncan, well, CEO Duncan here likes to call it multiple party middleware, that we, you know, provide us a software distribution. We built it, we tested it, and it's maintained by us, so you don't have to worry about all that. And then, again, so the areas that Sextant covers would be, you know, the distributed ledgers, so you can use it to deploy very quickly a blockchain-based network. You can also, you know, use it to deploy a decentralized secure file system. You can also, you know, again, deploy it and accelerate the adoption of smart contracts, because you can, you know, forget about the runtime environment and everything. You just have to focus on your business logic or the application. And then, again, provenance, Sextant supports our chronicle product that it's blockchain-based, and it's a domain agnostic provenance solution. So this is, you know, if you remember the DLT landscape that I showed you, that's a general one for the market, and this is our view of it, and these are the areas that we cover. So this is just, I guess, we like to see graphics, so it sort of illustrates where we are, right? So we use, we take extensive use of Kubernetes, the distributed ledgers that we currently or support, or will support very soon, you know, include Hypergebezu and so too, which we already support, and Fabric and Corda is coming soon. We also support some databases, because sometimes enterprises want to deploy smart contracts on a database first and then maybe move to a distributed ledger a bit later. And then, in terms of your information security, there's this cybersecurity firm from the U.S. that we work with called Techian. So they are using Hyperge's sawtooth and are sextant to provide a decentralized and secure file system. In terms of smart contracts, as I mentioned, we provide support for Demo and WebAssembly, and our provenance product is called Chronicle, which is also blockchain backed. And then you have sextant, which, you know, takes sort of takes care of everything on this stack. And in terms of customer stories, just where sextant is being used in production, just obviously we are in finance events. So there are a few clients in the, from the financial sectors of the insurance that we work with. One example is an insure tech company called the Demox Group. They are using sextant to, they have built an innovative risk management platform to help organizations build climate resilience into their business models. They are using, in terms of technology, underlying technology, they are using both Hyperge's sawtooth, the Demo smart contracts on top, and then underneath that an Azure Kubernetes service. Liquid Share is another company. It's a French startup, financial startup, is owned actually by a number of big European banks, and they have launched a cutting-edge, post-trade platform, and they were using sextant. In terms of the technology specifically, they are also using the Demo smart contract, but they are using it on top of Hyperledger Bezu. And then in terms of the infrastructure, they are using Google Kubernetes Engine. And then another example would be the Tel Aviv Stock Exchange. They built a lending platform using sextant. They are not using smart contracts, but they have deployed Hyperledger to sawtooth as their distributed ledger on top of the Rancher Kubernetes Engine. So these are some of the examples where sextant is already sort of working and being used. And now, Demo time. So I'll ask Duncan Johnson, who is the CEO of BTP, and he's going to do Demo. So I'm going to run a couple of demos, and there is a one I'm saying, never work with children, animals, or CEOs. So I apologize in advance. So the first is really looking at setting up and installing sextant itself. So we mentioned earlier, children mentioned that sextant is a Kubernetes native management and operations platform. And so what we did not that long ago, in fact, was we integrated into the Susie Rancher marketplace. Now, if you don't know what Susie Rancher is, it was originally Rancher Labs. Chris Anacheck from CNCF is here. We have some folks from like FX from Susie, if you have questions about that, but essentially, it's an open source container management platform that lets you roll out any number of Kubernetes clusters and manage them. And that's really, really important because the theme throughout this, whether it's what we're doing at the sort of blockchain DLT level, or whether it's what companies like Rancher are doing at the sort of Kubernetes level, it's all about ensuring that there is very solid management. Because what you can't afford to do with these technologies is deploy them, and then you lose track of things and you can't maintain a production grade service level agreement. And I'm actually originally from financial services and so I do understand SLAs, I do understand what it means to roll out a production system and you can't half transact, you can't half trade. So with that in mind, a couple of things, and I think these slides will be available later, there is actually a guest blog that Chilla wrote that actually describes in detail how to do what I'm going to do, he said optimistically. And then there's also cookbooks. So cookbooks are the things that our DevOps engineers like to write, which are very sort of nitty gritty, but give you the same information in a way that you can just follow. So right now, I have, and here is one I made earlier, we run a routine within our sort of organization, we run a rancher environment, which is, as you can see here, rancher.dev.catenasis.com, so catenasis or catenasis is a domain we use for a lot of our internal work, blockchain TP obviously for the external. And what's interesting with Susie Rancher from 2.6 onwards is they created this notion of a marketplace. And so what does that actually mean? It means that you have available a set of curated helm charts that the Susie Rancher team maintain themselves. So those are core, core, in fact, we can look at what they are if we if we change the selection here and just take the partners out for a second. Now you can see a range of curated helm charts that are supported by the Susie Rancher team. So things like Longhorn, if you're familiar with that, NeuVector and so on and so forth. But what's interesting for us as a partner is that they've actually also introduced this notion of creating a set of helm charts provided by partners. And you go through this whole sort of onboarding process. So this is not you don't just rock up and do this. And in fact, you can see here, you can add your own, your own repo whilst you're experimenting. So B2B stable, B2B test. B2B unstable is what that actually means rest assured is this is this is this is I love engineers. It's like they say they it does what it says on the tin. That's the experimental version of many of our sort of helm charts. But anyway, sticking with this and just coming over here, I'm just going to look for sextant. And this is standard for any of these, any of these packages. What you're essentially doing is you're providing the helm chart, you're also providing some some you decorate it essentially so that then rancher knows to pull in information and create a sort of a very, very easy to use installation process. So so if you click install, and just to prove that there is there's currently nothing there, I'll just go back here for a second. There are no installed apps. So this is this is high wire without a safety net. So what I'm going to do here is I'm actually going to specify a namespace. It's always a good idea when you're working with Kubernetes not to just push everything into the same namespace, you'll then destroy in the value of one of the values of the Kubernetes product, which is to allow you to segment things. So so I'm going to use sextant namespace. And then I'm going to go next. Now this is the only bit where you actually have to interact with us. And so you have to go and get credentials. The reason for that is that we will probably be changing this over the course of the summer. But right now, we want to engage with people, which in the open source community, it's this sort of do I don't I do you just push stuff out there and let people use it? Or do you want to have some kind of engagement with them? So right now, we politely say would you mind just pinging us and we'll give you the user credentials. So what does that mean? It means that this allows us or rather it allows the helm chart that's running behind the scenes to actually pull through our sextant Docker images from a repo that is obviously behind user credentials. So I'm just going to load these here. And I stored them because it's much easier to store them using last pass or something like that. And this was actually originally part of a tutorial that we did for the Susie Con a few weeks ago. So this is these are the credentials that I was given. There are a few other things I could set here, but I'm just going to accept the default. So for example, here I'm saying just just create an user, an internal database to store any of the sextant state. You could of course actually connect this to an existing Postgres database. So wait, hit install say a prayer to the demo gods. So what's it actually doing? It's literally what's going on behind the scenes is, and I should have said, by the way, I'm operating within one of these clusters. So I skipped a bit where, you know, because Rancher allows you to set up access to multiple clusters, I'm just using the default one, which is normally called local. So what it's now doing is then it's done it. Okay, so it's now installed sextant. We can see that because if I if I come across to here, I can't actually access sextant at the moment. So there's nothing running there. But if you look at the instructions in the Rancher install, what it's saying to me is I, and this is a sort of easy way of doing it is I can just basically if I can manage to operate a computer, I can grab that. And what this is doing is it's just for convenience for the purpose of this demo, it's just saying, fine, I'm just going to run this and and connect through to the Kubernetes, sorry, to sextant running the Kubernetes cluster using something called port forwarding. Okay, so what that now means is if I go back to here and click on here and hit refresh, right. So I'm now, so a moment ago, or a few moments ago, we didn't have an running example of sextant, which is a say a Kubernetes native management operations platform. We now do have one. And you'll notice that when you install it, it also gives you a way of extracting the full admin credentials, so admin being the username and a generated password. So I'm just going to again pull these through from here. So far, so good. So the first thing to know is that because we've done this as part of the installation within the Rancher world, we've automatically pulled through the definition of local, which was the cluster that that we've installed sex and all. Now that's quite convenient. You can, of course, add other clusters. So if I step back a minute and say, Well, what is sextant really doing here? It's really only concerned with three things users. But we have a default user. So we use that clusters. So the again, in the same way that the rancher, excuse me, rancher manages clusters, we also need to talk to clusters. Now we're not managing them. Somebody else is creating them, deploying them and so on. But what we need to do is get the service, create a service account and get the credentials so that we can actually interact with with that cluster. Interacting with it means we can ask it to do things. We can ask it to install using Helm charts. So behind the scenes, Helm charts, Helm charts, Helm charts. So with Helm, with Helm version three dot x onwards, we return to using Helm because it's now super clean and easy to use. So everything, whether it's the rancher guys importing things into the marketplace, whether it's us creating these deployments around DLT, smart contracts and so on. What we're all doing behind the scenes is curating Helm charts and making sure they're robust, versioned etc. So clusters are the target environments. And then deployments are really, this is where we get into that stack that Chilla showed you where we're actually going to pick and choose, right, do I want sorties, do I want Damwon, Bezu, etc. So if I stick with the clusters, I also have a sort of simplified, super simplified read only view just so you can see here, this is obviously this is an actual EKS cluster that's running in US one for those care about these things. There are no deployments running there. So so what am I going to do? I'm going to add a deployment. So this is really where it starts to get interesting. So the choices here in the community edition are somewhat restricted at the moment. We're just focusing on Bezu, sorties and Damwon Bezu, Damwon sorties. That's because with companies like Tachyon who we're working with in the infosex space, we're not allowed to distribute and make their stuff freely available because obviously it's a partnership. Chronicle is not here yet, but will be added shortly. So because that's ours, we have full control over that. But again, going back to that picture that Chiller showed you, the key thing here is to give you a kind of a set of options. So I will I will start with my favorite, which is Sawtooth. And again, in much the same way that the installation process that was presented by Rancher a few minutes ago, we are also simplifying things. So we're saying, look, we'll we'll provide the sensible defaults for you. Now, we've kind of gabbled our way through this and sort of never really said what a distributor ledger is when it boils down to it. What it is, in this case, is going to be four nodes which are wired up that have a protocol that allows them to talk to one another and establish consensus. Why is consensus important? Because you only ever update the state of the world when there is agreement amongst those nodes. And four is the magic minimum. So you can't do anything with less than four nodes because you want to be able to assure that, you know, we can continue to operate even if we lose a node. If I go from four to seven nodes, I can afford to lose two nodes before I have to sort of halt the network until things have repaired and so on and so forth. So basically what you're doing with, and this is true of a lot of the consensus mechanisms, is you want to make sure that that there's no there's never more than a third of the nodes either under attack or out of action. If there are, then you cannot proceed because you cannot you cannot create consensus consensus. It's in our world, in the world of permission, it's a mathematical consensus algorithm called normally practical Byzantine for tolerance or Istanbul Byzantine for tolerance, which is, which is the basic version. But these are not proof of work. So we're not consuming vast amounts of electricity, however cheap or not. So I'm going to give this a name. I'm good on names, sorted deployment and sorted namespace. I was running this during one of the keynotes. It worked twice, right? Engineers induction, okay? Once, complete fluke second. All right, we're motoring now three. It's is the universal truth. So will this will this actually work three times? So what we're saying here is we're going to accept those defaults. And as I said, we're now going to, and if you recall, we've got a four node cluster conveniently. So we now hit deploy. And now literally what we're doing is section is talking to that cluster, in this case, the local cluster in, in Rancher terminology. And it's now saying, right, I want to roll out a four node network. And I have a quick look at that network. And it's just coming up. There we go. So what, what have I actually done here? So again, harking back to what children were saying earlier, you know, we want to ensure that you, if you're developing an application, if you're working with sort to directly, then you're creating things called transaction processes. If you're working at the smart contract level, then obviously you're developing smart contracts. But whatever level you're operating at, we want to provide a very solid runtime environment for you. And we do that. So you don't have to worry about it. So you can then get on with doing the cool stuff, which is creating these new multi party applications. So what we're looking at here is a summary view of there are four nodes, there are a bunch of services associated with them. And, you know, if you don't believe me, I'm sure you do, but you know, I can come over to here. And I can look at where am I? I'm on, I'm on the local cluster. There is a namespace called sawtooth. So if I switch to that, this is sort of showing how the, you know, so that's essentially, and look, 79 seconds earlier. So, you know, we actually built this from scratch in front of your eyes. So now if I come back to sex and one more time, you know, we're not stopping there. You can also, you can go back to your cluster, look at it again. Now we can see that we've got sawtooth deployed. We can now add down one Bezu. Now to add down one Bezu, there's one thing you need to know, which is you need to actually add image pool secrets. So I'm not going to actually do that here. I don't want you to see my image pool secrets. But essentially what's going on here is there are certain components that we want to pull through that are again in a, in a repository, a Docker repository that we manage. But hopefully you get the idea of what we're trying to do. And that basically ends the demo. Hopefully we've got time for a few questions. We're everywhere. If everywhere is Edinburgh, Barcelona, London, New York and San Francisco. By the way, Edinburgh is now the number one city in the world according to time out. City in the world. Best place to live. What else? So, but so you're all welcome. But we have time for a few questions if people have any. Yes, please. Okay. Can I answer that? Yeah. So the big difference, and this was something that Chilla talked about in terms of the types of blockchain or DLT, majority of the public ones have some form of native token and there's some way of rewarding participation. When you're working with the permissioned or hybrid world that we live within, you actually take a different point of view which is you govern who can contribute nodes and so there's a whole layering of that. So you're not rewarding people simply by rocking up and adding a sort of node. What's actually happening is that sort of network is being used, for example, at the Tel Aviv Stock Exchange to build out a securities lending platform. And in the same way that there's, you know, you're all in, I hope you're all familiar with things like message oriented middleware, right? There is this thing called the internet. But when you're actually working within a bank or financial institution, you'll roll out a message bus. But your message bus might extend quite far into other companies. But it may even be the Swift network or something like that. But in general, you're not doing a one, there's no notion of a single blockchain. What there is is a number of different blockchain networks and that's why interoperability and bridging between them becomes important. So in the enterprise space, which is where we live, it's all about whether it's somebody operating the network as literally the network operator, whether it's somebody doing that and then adding participants who can contribute nodes, or whether it's a consortium where everyone is contributing nodes. What we provide and what other companies provide is really the glue, the way of actually attaching nodes to an existing network. So where I was in Sawtooth saying, yes, I'm going to create a genesis block. If you're adding, contributing, let's say, three new nodes to that network, you wouldn't actually attempt to add a genesis block. Instead, what you would do is be given the credentials that allow you to then wire yourself into what is essentially a virtual private network. So a lot of what we do around this is when I say we, this is us as a company advising is create a very secure environment in which to operate, which can be multi-party. So this is not within a single organization. But so the short answer is there is no reward because what you're typically doing is developing an application or service, and that is what's really of value. So hopefully that answers the question. I mean, reward is just feeling good about having deployed something without having to do any effort. Right. So next question. If there are no other questions, we should let our next speaker come in and actually set up because we're quite tight for time here. But thank you for joining us. We'll be around and look forward to continuing the conversation.