Hi, good afternoon Welcome to my presentation first of all It's gonna be a little more high-level presentation than the one you have seen before you have been in this room In my presentation, I will share with you the experience I have collected together with my team in building and implementing the applications which were deployed across multiple Either public clouds or in a hybrid cloud model. So where we had some private cloud and public clouds connectivity My name is Yaroslav However, you can call me Eric as well I'm with Red Hat for almost seven years now However, I must admit with shame that this is my first time on Defcon So I'm very happy to be here And before we get started, I would like just to ask you who of you is from Red Hat in the room Okay, so we have like how good So So this journey with This kind of architectures have started for me around five years ago And if you can recall this was the time When Red Hat has released OpenShift 3 Actually, some customers were involved earlier in in OpenShift, so they started together with us some Implementations of this kind of architecture just shortly before OpenShift was released and in this presentation, I will try to share with you some findings or some interesting aspects of Building this kind of architectures So when we started five years ago, it was like kind of a totally new space for for everyone however now if you Look on for example, this this kind of research You can see that actually nowadays most of the customers who are Willing to deploy some applications in in the public cloud They will use some sort of either multi or hybrid cloud strategies so it now it's more like the mainstream and also the The tooling the software I will talk about has matured over these five years to To make this kind of projects much easier than than it was in the past So that there are quite a lot of good reasons why why customers are using this kind of architectures There are three major group. I would say the first one is really to the cost management. So Public Cloud is not is not for free In fact, it's it could be quite expensive in some scenario. So So this this kind of architectures might be a good way to to contain that kind of cost There are some, you know, some some technical reasons like I'm increasing availability reduced latency and so on and also there might be some compliance or regulatory Requirements especially related to data management and data transfer across different different geos So these are the most typical topologies that I was working with within this five-year journey So the most project they they started in a way that people who are experimenting with public cloud they typically started to put some Non-production workloads into into public cloud and and later on they they moved Also with production But typical the starting point for many customers was to run some non-production systems in Systems on environments in public cloud and running production in-house The second the second use case was where We wanted to build a solution or system that was distributed across multiple geo So if you if you were if you are working for some global companies or you are involved in some global projects Sometimes, you know, they have some applications that they want to be available across the globe So they want to serve customers from Europe, Asia, US and then typically this means that They might want to deploy the instance of the applications across the geos in different clouds The other use case is about scaling so there are some types of applications which typically Requires some limited resources, but there are some points of time some peaks or some other events where they need Dramatically to scale up and this is also a kind of good case for For leveraging a public cloud where we have this additional resources available on demand And the other The other scenario is when we are layering our application. So this is typically Done in the way that we have some data layer that sits in our private cloud, but then we have some Some API's or some front ends that could be deployed in Public clouds and they communicate with the backend that are running in in the private cloud so this is more or less the kind of Setup for for my presentation and this is what I will be talking about in the in the In my presentation so that is essentially two parts One is more for developers. So how to how to Architect the application how to manage CICD and application deployments across multiple Or hybrid clouds and the other one is more about the operations of how to manage things like networking data application Management monitoring and security One more question for you. Who of you is more like developers and who is the operations Okay, so we have like 50-50 so good mix I Guess there are also some DevOps who do both All right, so let's get started with the application. So as I mentioned in the beginning This journey started at the time when when Red Hat was releasing OpenShift version 3 based on based on Docker at the time so The containers are really the the key component of those application architectures and in this kind of projects there was always a requirement to Containerize the application in order to achieve maximum portability Which is needed for this kind of multi or hybrid cloud deployments And of course we had like two two types of Situations so either we wanted to migrate existing application or we wanted to develop Completely new one So in regard to existing applications, there are basically three strategies that that works Where well in a in a real life. So so the first one in the start first strategy is called Rehosting and this is where we simply try to leave and shift our application So in essence what that means we take our application as is and we containerize The layers or the application itself depending what is the architecture whether it is monolith or it has some more layers And this this work well this works well for for some some types of the application so Especially for technologies that that are kind of modern and not really legacy stuff For other applications other possible Strategy to to migrate was the Strategicals re-platform and this is where we basically Keep existing application as is But we try to build with the containers any new capabilities that are Introduced to the application over the time and those new capabilities are built using the containers and and they are Designed to run in Contemporized environments and then of course we need to build some kind of integration layer as you can see on the slide between our existing system and the And the new new layers new components that we introduce This is of course more complex approach than than the previous one, but still Works well in in many scenarios and then we have the third approach which is Refactoring and these are typically the most complex projects where we where we are really Taking the effort to rewrite our application into Into the new containerized Architecture so this might also mean that we migrate from monolithic architecture to microservices or we do any other needed Architecture changes so these are typically big and complex projects that that Take a lot of time and Narcosly Especially compared to the previous two approaches When we talk about developing new applications We we standardized on Cloud native Approach so what it really means that we of course Standardize on the containers as a runtime Microservices as the architecture the API as a standard of communication between a microservices and DevOps as a process is to to manage the CICD for for applications And When we had a when we had a containerized Application we need a platform to to manage and and deploy the application in our multi or hybrid cloud environments and of course the The platform is is OpenShift so In OpenShift by the way, who of you is familiar with OpenShift? Okay, so most of you so No surprise So what OpenShift give gives us it gives us Flexibility of the platforms And it gives us basically the consistent user experience across different different Cloud so if we combine OpenShift with with portability of containers We have pretty good foundation to to be successful in in deploying our applications into Into multiple in multi or hybrid cloud environments But containerization However, it works in many scenarios. It Doesn't work in in all scenarios There are still and there will be still some workloads that are running in virtual machines and we find it really Complex or too expensive to to take the effort to to migrate those workloads to To containers however on the other on the other hand we want to We want to leverage the benefits of having OpenShift as a consistent platform for for running our applications and There is an effort in the community to to build a platform that will that will let you Run a virtual machines natively in the OpenShift At the moment it is still a community effort But if you are interested in this kind of use cases I encourage you especially to have a look on QVIR projects also on Metal Cube, which are the the main projects, which will Provide us the capability which will provide the capabilities for Kubernetes and for OpenShift to run natively KVM based virtual machines So there is a hope and that also container natively container sorry natively virtual machine based workloads will be able to To leverage the value the benefits of OpenShift Okay, so so we have we have the Containers we have the the the platform To run our application now the first thing we need to to implement is CICD So our first attempt to CICD for in multi or hybrid environment was really to Leverage existing tools and knowledge so in our case this was a Jenkins And the only only change we made initially in our Pipelines was to to introduce the multi-cluster deployment of images that were that were tested created and tested during During our pipeline execution This this worked for us pretty well, but at some point We had number of situations where The deployments to to some of clusters that That we that were a part of the platform Has failed And because this step was part of our pipeline this this this man This mean really that that our pipeline has failed and We started building some you know some some solutions in Jenkins to To handle this kind of situation, but but really at some point we realized that this is pretty much the road to nowhere because There will be always some new issues with the networking that We didn't cover and you know Jenkins is not the the platform to to replicate Container images across different different Clouds or environments So this is where we Actually, maybe a bit of coincidentally At the the same time pretty much the same time Red Hat made the acquisition of coro s and with coro s we acquired also Container registry called quay and quay Provided for us One functionality, which was really the one we needed which is the geo replication So with quay geo replication as you can see here on the on the picture you can basically deploy image to one instance in your Distributed quay environment and then Quay will distribute the images across all registered Or connected Instances so this was the way How we moved forward So We started to leverage quay Which was deployed across Multiple clouds in different geos and quay was we Give a quay responsibility to to replicate the images across the Across data centers Another challenge here was to Was the management of the application configurations across different data centers, so so We had open shift cluster in each data center deployed and We And we needed to to replicate application configurations across those clusters in a consistent manner And now it's probably pretty obvious that that's for this kind of challenge You will leverage github's but when we when we When we have been facing that problem Three four years ago. It was not not that obvious so Probably now, you know what what was the idea behind github so We keep our application configurations Which are yam based in the g-tripo and then we have an engine that can replicate those configuration across multiple registered Kubernetes or open shift clusters And at the time we made the decision that we will leverage We will leverage Argo as the engine And Argo actually gave us a very very nice functionalities so first of all it With you can register multiple Clusters that can be deployed Anywhere across different Data centers clouds Geos It of course synchronized the application configuration with the g-tripo What was also very important it give us gives us possibility to Make some overlay configurations which could be specific only to some data center. So if you think about Kubernetes or open shift application There are a number of configuration that are specific for your For your data center. So things like some credentials. So typically config maps secrets Ingress configurations. They are they are specific to to to every to every cluster or application instance So we we needed and and we got it with Argo We needed the ability to make some overlay configuration specific for for the cluster Then of course Argo can Synchronize for us the configuration To each of the cluster and what is also very very important and very useful about Argo is that this last thing so Argo will also Monitor the configuration of your application on each of the clusters and will detect if someone locally makes some changes to the configuration And will revert that change to to the configuration that is defined in g-tripo. So this This also makes You know it reverse a little bit The way how we manage the configuration Because we don't manage the configuration via Command line or web console of Open shift or Kubernetes, but we will average as a single source of true the G-tripo Over the time So gtops Might become even even easier because We have Our community have introduced concept of operators. So with operators you can basically package together the application configuration and this makes nowadays some application configuration easier so there is You can you can transfer some Or you can package some application configurations into operators. So so that your Your app configuration becomes becomes easier And there is a there is a community effort to to build kind of a standardized solution for for For this use case so for Federation for federated deployments and of applications, but this is still kind of Work in progress so early days and I Don't see like this is moving forward fast So I think still the the approach with the gtops is the the best way how we can manage application configuration in multi Or hybrid cloud environments Okay, so now The second part Maybe a bit more related to operation operations and infrastructure So the networking so So so from the networking point of view hybrid and multi-cloud introduces number of challenges The first challenge is how you manage the traffic ingress So you have Instead of one cluster with some ingress load balancer in front you will have like multiple Clusters each of them will have their own local load balancer And what what you will need here you will need some global traffic manager Which will be able to distribute the the traffic between Between this multiple Clusters so GTM typically is a DNS server so it doesn't really So the traffic don't do not really go via via GTM It is a DNS also some with some advanced capabilities related to geolocalization for example, so It might as a DNS it might give you different IP address IP address of one of these load balancers depending on from where you are Sending your request and this is quite quite important in some scenarios, especially if you want to Distribute the the traffic According to a geo from of the of the of the requester The other the other challenge is The service mesh in multi and hybrid cloud So who of you is familiar with service mesh? Okay, some of you are so service mesh is very useful in in a situation when you have when you have the micro services architecture with service mesh you can manage all the aspect of the network communication between Between the the micro services so Think of security think of some Policy based routine Also, it gives you some very nice observer monitoring or observability But on the other hand, it's it is quite heavy and complex component of of the Kubernetes or open-sheet architecture And Service mesh has gives you at least three options how you can how you can Deploy it and manage it in multi cluster environment So the first two options You can use if you have Completely separate networks between your data center. So for example if you if you have If you deploy your application in different clouds in multiple clouds This this might be a case And The third up so the third approach requires that you the third option requires that you have That you have a single network between the between between your clusters So so there are some some tweaks in each of the approach so so it's It's not easy really to analyze and decide with which option to use In my experience, we typically use they the the second the second option where we Wanted to avoid to have multiple control planes in in the mesh So we wanted to keep service mesh configuration in single location and we wanted to To be to have the service mesh managed in the central way and this is how it looks like in a This this image shows you this this scenario So in regards to networking there there is some Also some some community effort to to make it easier to connect multiple multiple clusters So the one project to where we also as a Red Hat Contribute is Submariner With these projects they try to build kind of VPN That runs on on top of open she sorry on top of Kubernetes so that you can easily connect different networks and You don't need to go deeply into the Infrastructure layer to to open some tunnels and so on There are other projects lighthouse and Coast Guard, which are also aiming at Building the networking For multi cluster scenarios Easier, but this is still still community effort. So it's not yet available Next thing data data replication so Data replication basically Has two complexity so the first one is the technical one so how we can how we can Send the data in efficient way between You know between different continents Even or between different networks the other one is about the cost so the cost of Data replication between public clouds can be very very substantial. So You cannot underestimate that factor and you should always Think and analyze whether this won't make your Architecture or your use case And unacceptable So in regards to data replication there are basically three Three possible scenarios, of course if if you don't have to the best way is to do not To do not replicate the data But if you have to you can theoretically consider three options. So either you will use some Infrastructure layer so storage layer replication solutions or You have two options on the applications layer. So either you replicate the data using some application-level technology or you leverage the Data partitioning and and you don't really replicate, but you just partition your data across different clouds The infrastructure-based synchronization of course especially in public clouds scenarios Might be impossible, especially if you are thinking about some hardware level replications however, there is a Development and progress in building software defined solutions to replicate the data the one which which is now part of Red Hat offering is is is Nuba Cloud object gateway. So these solutions let you Replicate the the object storage Between different different cloud or private and public cloud The kind of downside of the solution is that it it Exposes the data using the S3 API. So this is not feasible for any kind of application You need to your application to be to be able to leverage S3 API But once you have this this You meet this requirement Nuba can replicate for you The the object storage across different Different clouds in a transparent away from the application point of view So but this is this is quite new so Even even in Red Hat we just Introduced this as part of of our new container storage version for which was released. I know week or two weeks ago so what we typically used to do in In the past in our project we used to leverage some application based replication solutions So this is an example of the multi-cloud architecture of Red Hat single sign-on Platform which is based on the key clock project So this Platform as you can see is using two persistent layers so one is relational database which in this example is a Is a mysql database with with Galera for Multimaster replication and the other one is data grid So this is in memory cache to to offload some some data from from the grid and as you can see here Both Galera and and JDG they they they have built in Cross data center replication functionality Which is built using some? Custom protocols running on on layer layer 4 so TCP or UDP and This is this is typically the most physical scenario to implement that data replication in in Whenever one of your data center is in a in a public cloud because As I said before You won't be able to replicate data using some some infrastructure solutions Similar approach is to use the messaging platform so AMQ Offers the interconnect functionality which lets you Exchange the the messages between the distributed data center so doubt so that users can Send the message into one data center and and some consumers might consume the same messages in In different data center and this is again based on some layer for replication solution which is built in into AMQ interconnect So the next thing is management so nowadays multi cluster multi cloud management is very hot topic so many vendors Started to build or to offer some solutions in that area So in case of in case of red card, so what what we what we did and what we are doing So first of all we have significantly Improved The process of installing and upgrading OpenShift so I'm referring here to to OpenShift 4 Which nowadays you can Install using the full stack automation strategy where basically You need to To provide like five up to ten parameters and you will have a cluster deploy it automatically in Let's say half hour There are also two Hostet offering so one Dedicated which is so which is hosted on the AWS the other one is Hostet offering con Azure So from the Installation and upgrades point of view There is not much more effort to to manage the Multi cluster OpenShift environment versus some some single Or private cloud environment We are also offering in a software as a service model the OpenShift cluster manager console But this console is not really for the to manage the the platform is more for us to offer you and provide you some services like subscription management or Or Updates some proactive support services and I think this platform is built to meet this this this kind of use cases However Because we we joined the the IBM family There is also there is one more a product which looks like will be our Go to platform for the the multi cloud management or multi cluster management It is IBM cloud Multi cloud manager The significant part of its functionality is the management of Kubernetes clusters and it already offers quite advanced capabilities in regards to the Visibility of your cluster so you can register Multiple clusters to the console and and and monitor them from from the metrics from single instance It also has some some nice functionalities related to the Workflow deployments, so this might at some point Compliment what we are doing currently with GTOPS It offers you also some Functionities for the two operations so updates patching and so on and I think that over the time this will be Integrated with OpenShift for capabilities This platform itself can be deployed on top of OpenShift, so And I'm expecting that soon you will hear more about that That product as our solution for multi cloud or multi cluster management Both in on-premise and in in SAS Offering offerings Next thing is monitoring so OpenShift comes with building monitoring stack so based on the Based on the Prometheus and Grafana And That they are basically two scenarios how we can leverage that monitoring stack in in the multi cloud Or multi cluster environment So the first approach Which I Have experience with was to Deploy a separate Grafana instance Which Which Where we define some dashboard that connects with Prometheus instances running on on on separate on separate on different in different Clusters or clouds The other approach which is Pretty new Is to leverage the Prometheus federation capabilities so You can have a Prometheus instance that will that will replicate The metrics from will pull the metrics from Prometheus instances running running on your on your clusters and then use Grafana to To create some some dashboard dashboard however In these two scenarios the the big concern was really a cost of Getting the data from especially in public cloud scenarios getting the data from the public clouds to To to to Grafana or here from one from in these two other I Was involved in one project where we did some tests to compare the volumes of data For some dashboards that were built in Grafana At this time in this project I Can also this is a general rule, but we find out that Using Grafana to to to collect metrics from Prometheus Was cheaper than Then then letting Prometheus to to to to To federate with with other Prometheus instances But I cannot say if this is a general rule. Maybe if you somehow optimize Reconfigure Prometheus you will be more efficient with the second scenario And the last topic is a security So very important thing So open shift is by design very Or very secure platform, so on every layer starting from the operating system you heard today may be the presentations Which cover this this operating system level security Throughout all the all the layers open shift you have Built-in security controls that let you run it in a very secure matter Also from the container images point of view there is very nice Container scanning functionality which is part of quay Container registry But what was really amazing part in open shift was to the ability to to define some and enforce define and enforce some multi-cluster security Polices That would be Enforce and Deploy it and enforce across multiple clusters at once so We have been Playing with open policy agent Which is pretty cool solution to define some security policies It runs as an admission controller. So if you know admission controllers They are kind of low-level interceptors of requests to Kubernetes API. So They have access to all the data that is sent to the Etcd database so with those admission controllers you can easily Analyze Anything any data any yaml content that is sent to to the API but Open policy agent has no multi-cluster support. So if you will use that Solution in multi-cluster environment most probably you will need to leverage JitOps tool or any other Replication tool to To manage in a centralized way The the security policies The IBM multi-cloud manager the tool I mentioned In regards to management has also quite nice compliance module where you can define Compliance policies and with that It has also built-in capability to replicate the data across across multiple clusters so this is also If we look on the products available on the market, I think this is the The best solution for for this challenge So I I leave I put a couple of links for you. So if you want to go deeper With some of the Topics I briefly discuss here are the links I Leave the presentation Here for for you to download so Feel free to to to learn more about the the stuff and I think that's Pretty all from my side Yeah, I'm almost Taking my time, but if you have any question, I think I can have no one or two Anybody say again, can you repeat or I don't hear you Download page Well, I uploaded this presentation to To this to the conference schedule page, so I think if you go to To to my presentation in the schedule you should have some link. Hopefully any more questions For data transfer it you know, it's it's also a matter of optimizing But at the time when we did some tests it was probably two times more expensive To to let Prometheus Get the data from the other Prometheus instances versus letting Grafana to execute the prom qr queries to Prometheus Okay, I don't see any more questions. Okay, so thank you very much for your time


QuickBooks Online 2023 Internormal sales cycle which includes inventory into QuickBooks Online for comparison to an e-commerce type situation. Get ready to earn the skills needed to boost your bank books on up with QuickBooks Online 2023. Here we are in our QuickBooks Online test company file using the accountant view as opposed to the business view you can toggle between the two views by going to the cog up top switch the view down below duplicating some tabs to put reports in like we're going to do every time right-click in the tab up top to duplicate it I'm going to right-click the tab up top to duplicate it again I'm going to do it one more time so we can open up our inventory report as well right-click in the tab up top and duplicating going back to the middle tab which was duplicated reports on the left hand side let's open up the balance sheet


Good morning. Today we're going to learn how to make a slide show using Google Slides. This is Google Slides and it helps us make presentations so that we can show information to large groups of people. This, as you probably know, is a slide. Children slide down the slide on the playground. This car is sliding. It's in a slide. That's very dangerous. Not a good thing. This is a sliding glass door. The doors slide and they're made out of glass. This is a slide projector. This is where we get the word Google Slides from. This technology is kind of old technology. Now that we have computers we do all of this in the computer. But this is what we used first. This is a slide. It's a photograph, a picture on a slide and it slides down into the machine and the light shines the picture up onto the wall. So that is where we get the word Google Slides. And what we're going to do is we're going to look for Google Slides on the internet. And if you have trouble finding it, your teacher will help you. But I'm just going to go to Chrome Web Store and it should be right there. There it is. Google Slides. You see the Google Slides icon so you know it's the right thing. And I'm going to launch. I'm going to start the app. So here we go. The first thing you do when you open Google Slides, the first thing is you're going to choose a theme. These are all the themes. The theme is a background design for all of your slides. And they all match the same design. You can choose any of these that you like. You'll know you've chosen it because there's a blue box around it. Right click on it to make the blue box and then click OK. I don't know what I just did. I clicked an extra time and it went. But you should click on it on the one that you want. When there's a blue box around it, then click OK. And then you get it. First thing you're going to do is make a title. A title is the name of something. The name of a movie is the title. The name of a book is the title. The name of your slideshow is the title of your slideshow. And I'm just going to name this my name. That's my name. And then a subtitle, sub means underneath. So a subtitle is the smaller part of the title. And I'm going to say who I am. Who I am. Kathy May Dickinson, who I am. I'm going to make a slideshow about myself, about who I am. Things that I like. Now I have my title slide. I want another slide. Right over here we have a red plus sign. You know, addition, subtraction, multiplication, division. I want to add a new slide. Add another slide. So I click on the red plus sign. And then I've got a title for this slide. And I'm going to name this, I'm going to put the title for this slide. I'm going to write I like to knit. That's something I enjoy doing. It's a complete sentence. I'll put a period at the end of it. Now I want a picture here. I think it would be lovely to have a picture. So I'm going to go over here and you see there, it says image. The other thing I could do is I could go to insert. Click on that and choose image here. Image is a picture. But I'm going to choose this shortcut to image. Now I have a lot of choices in front of me. I can go to a picture that I've already saved, which is what I am going to do. What you can do is you can go to search and then you can type in this box right here, knitting or knitting or whatever. It didn't give me anything. Knit. People knitting. There we go. So then it gives me some pictures. And you can choose any of the pictures that you like and then click select, the blue word select. And it will put it right in your document.  I'm going to pause just for a second while I do that. So here it is. I have chosen this picture. So I select it. It's in my drive. It's a picture that I already chose. You'll use search to find something on the internet. So then I hit select. And there's my picture. Now obviously it's very big. I can resize. All of these allow me to resize. If I choose the corner, the picture is going to stay the same. But I could also choose the side and it will squish the picture. You can squish it any way you want. If you use the corner though, the picture will stay the dimension, the way it was. It won't get squished. It will go top and bottom the same. When the picture is the size you want it to be, then Google slides. See that red line right there? That lets you know that the picture is in the middle. I also want it to be sized this way. So let's make it a little bit smaller. And check my centering again. There we go. I've got red lines vertically and horizontally. So I know the picture is right in the middle where I want it. Just right. I like to knit. And there's a picture of people knitting. I want to make one more slide. So here it is. And I'm going to write my dream job is an English teacher. I'm going to go ahead and put an enter there to make it two spaces. And again, I already know the picture that I want to use. Whoops. I don't want to go there. I want to go here. Back to image. And this is the picture that I want. You can take a picture. You can upload a picture from your camera. You can search the internet. I'm going to choose this picture. It's one that I have already selected. Select means to choose. So I'm going to use the boxes again and make the picture nice and small so it will fit on my slide. And then I click and hold the left click button while I move it over so that I have the lines that show me that it's right in the middle. And then I let go of the click and it goes right to its spot. So there you go. That's all that I'm going to do today. When you make a Google Slides presentation, you can have as many slides as you want. There's no limit. I only have three, but that's just for my example here. You can have many pictures, many slides in your presentation. That's all I'm going to do right now. Now, but the next thing I'm going to show you is very important. I'm going to show you how to save. When you go over here to file, there's no way that it really says save, but that does not mean that you can't save. What you do is you rename it. Right now, it's named Untitled Presentation. If I try to go onto Google Drive and find Untitled Presentation, I won't find it. So I need to be sure that I rename it so that I can find it when I want to call it up later. And I'm going to call it Kathy May Dickinson Who I Am. Good title. So now that is the name of this presentation. So when I go to Google Drive, I can find it when I want it later. The next thing I want to do is share this with any of my friends. If I want to share it with my teacher or with a friend of mine, I can type in that person's email address right here. There we go. Let's save it with this person. She's a friend of mine. And then I just hit Share and Save. And then that person will also be able to see it. And I want to upload it. So I go and make a copy. I'm going to pause just a second while I figure this one out. I'm going to go to Download. If I want to email someone this slideshow and they don't have Google Drive to just share it on Google Drive, but I want to send it in an email or post it to Canvas or something like that, then I need to download it from Google Slides into my computer. And then I can post it somewhere else. I'm going to choose one of these formats because Google Slides is only available on the Internet. And I want to be able to use it offline. So I'm going to choose Microsoft PowerPoint, but any of these that work, you can use. So then I'm just downloading it. Here it is right here. Download as a PowerPoint. It's still working. We need to give it some time. Then I can save it in my computer and it'll be in my documents as a PowerPoint document. PowerPoint is the Microsoft brand of slideshow. Google's brand is called Slides. Microsoft's brand is called PowerPoint. Sometimes you'll hear people say, do you have a PowerPoint? And that's what they mean. They mean do you have a slideshow? So it's opening the PowerPoint. We're not going to worry about that right now. It doesn't need to do that. That's how you do it. So you have learned how to open Google Slides and then how to name it. Make your title show, your title slide. Add more slides by clicking New Slide. Insert pictures by clicking on Image. You can also write words here. You don't have to only have pictures. You can type here and you can make it like this. Knitting is fun. Look at that. Now I have words and slides on the same. Words and a picture. And then when you want to show it, you click over here on Present and now it goes to Fullscreen and you can see what you've done. I have made a slideshow. It's thinking. I'll let it think. Oh, let's go back to the beginning of my slideshow. Kathy made a consent who I am. I like to knit. My dream job is ESL Teacher and then I exit. Have a great time. Have fun playing around with Google Slides and I'll see you next time.


Hello, this is Marco and I will just give an introduction and a brief overview of our Consensus Lab team week. Later on in this video, Consensus Lab team members will give you a detailed lab base. So we met from 5th to 9th September in Istanbul in a nice hotel, nice view, maybe the conditions were not ideal. But anyway, we had a good time. So Consensus Lab grew considerably, first of all. So 17 people attended team week. So this makes by now 13 team members and two members were remote. And we were joined by Ali from the Parkland Ecosystem team and driving from the FVM team. And so we had 15 people on site plus two Consensus Lab team members were joining remotely. I would say this time there was a lot of uncertainty among team members prior to team week. So there were discussions around what is the purpose of hierarchical consensus, which we renamed later on to interplanetary consensus or IPC, like what will be team focus, what are the future projects and so on. So apparently, something members felt a bit lost, which so we are the critical part, but like stage of what Consensus Lab is doing. So we are trying to basically productize a year of work. So maybe this is like with certain dependencies and maybe this is a tricky point. But one basically summary is that one line summary is that we largely removed these concerns. So we brought all team members on the same page and basically discussed the issues in details and came to basically conclusions, which allow us to work for at least a quarter without basically ambiguity and uncertainty. So one pending dependency at that time, because I'm recording this a bit late, so I will give you an additional update on what happened regarding this was on BuilderNet. So BuilderNet is the testnet, essentially on which we plan to incentivize testnet on which we plan to test what we are developing in Consensus Lab, so near consensus protocol and inter-parameter consensus or hierarchical consensus subnets and communication among subnets. And that pending dependency was supposed to be removed the week after the week and basically it was. So BuilderNet is happening, I will cover that in the next slide. So what we did in the in Istanbul, so basically you will hear about project updates, not the selling disorder where I put them, we are going to start, so not necessarily a disorder, but basically Y3, which covers the efficient consensus protocol for subnets, Y4, which improves the Filecoin mainnet consensus, B3, which has to do with the post-POC development of hierarchical consensus of inter-parameter consensus towards production, and G1, which explores the, this is the project that explores concurrent execution on FVM. Many people, so the first face-to-face with so many team members, and we had a lot of opportunity for so lots of breaks among sessions which were very productive, so you could see team members basically having water cooler tops, so even during the breaks things were discussed, and I'm really happy with how this went, and basically how it went from the team building side and how it went from the work side, so basically from the execution side. There was a lot of new ideas and brainstorming, especially about what we are going to do in 2023, I'm going to briefly cover this. Essentially, there is, if you go to our Ctrap, you will see also the links towards detailed notes, so you can see what this was about. But key outcomes, so basically we discussed imminent impact to the consensus lab team on Filecoin expected consensus, because we have pending improvements on Filecoin expected consensus, as well as the security analysis, so the first, I would say, detailed security analysis of expected consensus. These are the products of the Y4 project, and we spend a lot of time on that, so we will hear updates on that later on. Then we also discussed the details plan for what's called IPC, so IPC is interplanetary consensus, this was hierarchical consensus before, and we confirmed short-term focus on BuilderNet, so this is this testnet that I described, which we want to launch with the FEM team and the Lotus team, roughly speaking, by November this year, in any case this year. Certain decisions were supposed to be taken after the team week and they were. I will give you a short update on this later on. Then we spend some time on discussion about what we are going to do in 2023, so rather than what came up is the basically top-down approach, where we take use keys, basically a social network or content dissemination, in a certain sense use keys, and then after discussing email, Twitter, and other examples, we converge to perhaps look at the only sense, which stands for decentralized only sense, which would allow us to basically go through our stack, through what Filecoin already has, through what consensus lab is developing, and basically try to understand if we can build such a content dissemination platform. But this is like, I guess in the next overview of the next team week, you will hear more details about this, because this is only for 2023 and it doesn't concern us, it doesn't change our plans for 2022 and at least Q1 2023, I would say. So BuilderNet was the main focus and here I will be giving you like a short summary of it. So we remain committed, this consensus lab, we remain committed to work together with the FEM team on BuilderNet, and Akos from the consensus lab team is moving temporarily to the FEM team directly to help them deliver critical pre-BuilderNet milestones, such as helping them with the EDM on FEM, and later on on another project, basically related to gas metering on FEM. So what we are postponing is basically what we want to do, postBuilderNet is focused on Rust-based IPC core. So we want to move from the current, I would say, Filecoin-Lotus-centric approach that we had. So while for BuilderNet we are still figuring out with Lotus team what we are going to do, shall we merge changes, IPC-related changes to Lotus, or shall we go with the strip-tutical client for BuilderNet? That's basically the topic of the design sessions that are going to take place shortly after the team week. Basically for BuilderNet, this will be still the code that we develop for Udico and Lotus, and then later on we are going to change our focus as a group to Rust. These are the decisions that we took during the team week. So the plan here was to add Mir to the BuilderNet as soon as ready, but since basically I'm recording this a bit later, I can tell you that since the BuilderNet is at least in the beginning is going to be based on a proof of authority or as some listeners or viewers might know this consensus protocol as classical BFT consensus protocol, we are going to run BuilderNet immediately in Mir. So basically this BuilderNet allows consensus lab to deploy to its two key sub-projects that we have been working on for the last year or so, which are basically IPC functionality and Mir efficient consensus protocol. Thank you very much and in the rest of this video, you will hear about detailed project updates. Thank you very much. Hi everyone, I want to talk about the G1 project where we look at scalable execution of transactions. And so as an update, Vivian and I have been working on benchmarking different concurrency control protocols and we've decided to do that on top of the reference Falcon virtual machine for two reasons. First of all, we hope that it will give us an idea on how easy or how hard it is to use existing architecture for concurrent execution. And second of all, we think that this will give us the most accurate results in the benchmark that we will do. And so on the road to this goal, we've started by implementing naive parallel execution of transactions. So what I mean by that is so currently you have a single machine that executes one transaction after the other. We've now made it such that there are multiple machines are respond and that each in parallel can execute transactions. Of course, in general, this does not lead to a deterministic state. That's why we need concurrency control that has to be in place. So the next step towards this goal then is to capture the memory rights and reads, which will then allow us to understand dependencies between transactions. We've done that by adding a wrapper around the kernel and this wrapper can intercept the system calls from within the Wasm container. And this allows us to track the memory accesses. What is next for us? We plan on implementing two different approaches to then to compare them between each other. The first uses pre-execution. So it executes the transactions a first time just to understand the dependencies between each other and leverages then this information to create a so-called fork join schedule, which is some data structure that can be added to a block and used by the other nodes in the network to speed up, considerably speed up hopefully the execution of transactions. The second approach we are thinking to look at is called block STM. And here there's no pre-execution step and instead the execution is done optimistically and leverages the order of a block, the order of transactions inside a block that we already have. We also discussed the workloads that we will use to provide these benchmarks. We want them to be as realistic as possible to also have meaningful results. So it was then suggested to us that we could look at the Ethereum virtual machine and try to understand which transaction types exist and what are the proportions are and in the current use and use that to inspire us to get a realistic FVM workloads. Concretely, we will then use or reuse the message vectors that are currently implemented for FVM testing. And I think this will be a convenient way of achieving these benchmarks. Yeah, that's it for me. Thank you. Hello everyone. Today I will give you the updates for project B3 and all of the outcomes after the discussions of our CL lab week in Istanbul. So for those of you that are not aware, project B3, what we are trying is to move hierarchical consensus into production. And the first thing that we agreed on in this lab week is to rename completely as we're moving HC into production, we're going to rename the protocol name and from hierarchical consensus or HC, we are going to move into the interplanetary consensus IPC. So from now on, probably you'll, I mean, it may slip a bit and we may still refer sometimes as HC, but we've changed the name of the project. And from now on, we're going to refer to hierarchical consensus as interplanetary consensus or IPC. So from this quarter, what we've been doing in HC or IPC in order to move it into production is first, like, you know, that there was an MVP for hierarchical consensus as part of Eudico. And in this MVP, we were using the legacy VM. But as we are moving Filecoin into the FVM, the first thing that we did this quarter is to start moving from the legacy, all of the actors and all of the processes that we have in HC, we started moving them from the legacy VM to target the FVM. So we rewrote all of the HC or IPC actors to FVM. We also wrote a spec so that we could start kicking off discussions with the community and giving a bit more of like a low level detail of how the protocol works. And we wrote a feed draft for discussion in the feed discussions report so that others could start interacting because before it was just CL or because this is like the ones that were involved in the design and the implementation of the protocol. And we wanted as we move into production, we wanted others to give their feedback and their insight about what we were doing. In parallel, as the team has grown, we are also improving the protocol design. So Guy is theoretically modeling the protocol and understanding how we can improve it, unlike its security, its performance from a theoretical point of view. We kicked off a Rust implementation of IPC. And instead of using, because in our current MVP, what we are using as a high performance, we are starting to integrate as our high performance consensus for subnet is mirror. And you'll see a bit more, a few updates of the Project WIFE 3 that is the one that is working on mirror. But like for the Rust implementation, we wanted to use one of a high performance consensus that is out there, which is NARVOL. I'll give you also a brief update about that and all of the work that Akos has been doing with the Rust implementation of IPC and integration of NARVOL. Also, Will's joined the team recently and he's been working on tracing and monitoring IPC. Because like once we move, as we're moving into production, we want to deploy the protocol into a testnet and we want to have tools in order to see what is happening, how people use the protocol, like have benchmarks on the delay of cross-net messages and so on. So we've been doing a lot of work on trying to trace the MVP so that we can start getting some numbers of the protocol. And then there's been a lot of discussions and design ideas. So we've tried to, like, initially we were really focused on the MVP. Now that we have the MVP, we've been writing specs, like onboarding people into the protocol and trying to discuss openly, like the design decisions, see if we've made some mistakes on blind spots and so on before we move into a production ready implementation of IPC. So one of the things that we've been discussing and like that guy presented in Istanbul is a proposal to simplify the IPC protocol. Because before we had like this complex architecture with subnet cross-net messages and so on. And the first thing that he realized, well, he was theoretically analyzing the protocol is that maybe we could have a simpler protocol that is easier to analyze and that supports all of the features that we had so far. So instead of having an overlay of subnets, the new architecture is just an account hierarchy throughout the whole system. So we restrict the cross-net messages to parent-child accounts. So instead of having these complex cross-net messages where that are hard to reason and like the reward model is not clear, guy's proposal is to have a hierarchy of accounts and like the only way to exchange value between or interact from a subnet to with the rest of the hierarchy is through a combination of parent-child interactions. So this really simplifies the model of the reward model, the fee model and a lot of other models in the system. And the overall overview of this proposal is that we move from a motorcycle playing submarine how as guy wants to refer to our previous design of IPC to just a motorcycle. So to have a simple model that allows us to do all of the features that we were doing but having a clear core and in the end we realized like after all of the after guy presented his proposal we realized that the number of things that needed to change in the implementation may not be that much. So we are focusing on trying like as guy keeps exploring and updating the spec towards this new architecture we will try to implement the changes so that we can have this simple model in our first version of the protocol. Then another parallel stream that we had in IPC is the implementation of IPC in Rust using forest, the forest Lotus client as a base and integrating the Mist and Labs implementation of Narval which is a high performance protocol used in the sweet blockchain and one of the things that we realized as we were doing this work we knew that this was happening while integrating near into Lotus we knew that there were certain barriers and limitations in order to integrate this kind of protocol that has its own mempool operation and its own execution model into the current architecture of Falcon and as we were doing the same with Narval we realized that maybe we need to change certain parts of the architecture in order to accommodate this kind of a BFT like or high performance consensus protocol into the base codes. Some of the problems that we saw as integrate as we were integrating Narval into forest is that there's a mismatch between Falcon block and the execution model because these BFT like protocols they don't have a concept of time or epoch there are rounds but they're kind of unpredictable so it's not as easy as in a longest chain protocol then there's the problem of gas limits because we as in longest chain protocols we have a gas limit for blocks this is not exactly the same for BFT like protocols like MIR or Narval and we came up with a set of potential workarounds for this but the problem with this is that these may affect performance so we would be doing a lot of glue code that may be affecting performance and after this we realized that maybe instead of using the current architecture for longest chain protocols that we have in forest and in LD code for Lotus we need to figure out a way of coming up with an IPC reference client that is ready for any kind of consensus protocol as we build IPC so to have a reference client or a core client that is able to support any kind of consensus algorithm so in the same code base we have a way of implementing any consensus algorithm and we as part of this work we started exploring what was the best way of like in order to reach high performance and accommodate any kind of consensus algorithm in an IPC what was the best way to get there so we evaluated what would it take to just treat Odeco from all of the five one specific things and come up with an architecture able to accommodate any consensus algorithm we evaluated instead of using Odeco what would it take to use forest as a base for our reference client for IPC we even checked other projects in the ecosystem like substrate if we could have an IPLD based blockchain that targeted the the FVM and have this reference client but based in substrate or what would it take to have a new model our blockchain from the existing models that we have so to take a deco forest take the the sinker abstract the sinker with an interface so that we can have different ones according to consensus algorithm take the mempool the current mempool that we have implemented and abstract it so that we can have different ways like different implementations for the consensus algorithm and so far this has been the the what we may be tackling in the in the midterm which is trying to extract all of the models from existing models from the either forest or Odeco base code so that we come up with abstractions to build a model blockchain that allows to implement any consensus for for IPC so what are the short term next steps for IPC first we want to try to deploy as the FVM team is building their builder net for to test the the EVM and the native factors like the new update for the FVM we want to try to have to share these tests so that we can start merging some of our code from a deco to their experimental MVM to branch so that we can also test in this test net the all of the code and the MVP that we've done of HC so far in this process what we want to do is to check our code and like move it from an MVP code to a more production ready code so that we have it there and it can be and we're making more resilient and we want to integrate mere as finalize the mere integration into a deco so that it can be used as part of the steps either in the root net or as something so to give in the build net the ability not only to test a VM user defined actors but also to be able to deploy new new subjects and for this we need to reach a future party between the FVM and the legacy VM actors of of IPC this is like this builder net is going to be our main focus but like as we move towards this builder net in parallel if there's spare time we want to explore this implementation of the of IPC as a product so to have this core client of IPC that can be used for to implement any root net or any subnet with the architectural instructions that I I mentioned and we want to start onboarding new use cases to IPC because we think like the most straightforward ones that we've been discussing a lot is the use of like onboarding Saturn the Saturn team and like with their layer twos and the layer threes and this architecture their geographical architecture into IPC subnets and we also want to to test like how could we implement uh lambda scheduling and lambda execution of of lambda jobs into IPC so this is briefly all that we've discussed uh around IPC and like the short term uh future of the protocol if there are any questions please let us know and more than happy to keep discussing thank you very much hello this is Matje and I'll be talking about modeling state machine replication systems and blockchain systems first let me say a few words about the context of this problem so currently there's a big diversity in agreement protocols and this is not likely to decrease it will probably even increase even more there's many kinds many families of agreement protocols BFT style on this chain style synchronous asynchronous uh and so on and uh they are working in very different ways now uh currently what's happening most of the time is that when somebody designs a blockchain system or state machine replication system in general uh they take some particular consensus protocol and center all the all the design of the other uh parts of the system around the consensus protocol now this might work for very particular uh concrete use cases but um I think there are some problems with this approach it gets pretty complicated in general there's many modules many components of full sludge smr or blockchain system including execution of transaction availability their reception their uh the responses to the client somebody needs to handle the state the state needs to be garbage collected maybe there needs to be some execution engine and all and and so on the checkpoints need to be made and there are many many interactions between those components of such a system and uh very often it turns out in the end to be a big mess in the implementation especially what can be said in general is that we are often lacking modularity and universality uh in in the approach of uh in the approach to blockchain and smr implementations the implementations and tend to be ad hoc with few reusable components and uh very often it ends up being one big uh monolithic system that is hard to maintain and hard to upgrade and keep up with the progressing with the progress of research on on these systems and protocols what is also a very important point that is maybe in my opinion a bit under estimated sometimes is that uh different people have different mental models of how the state machine replication system works uh everybody thinks slightly differently about what basic components such a system consists of uh what their roles are how they interact with each other and so on and uh this sometimes makes discussions about such systems complicated from from own experience I uh I can say that that sometimes it happens that most of the time of the discussion actually goes to getting everybody on the same page what we're actually talking about and uh what what we mean by the by the terminology we use so this is not optimal and uh what I propose is the is the following approach I would like to uh devise a clear and useful set of abstractions around the components of a blockchain or smr system I think it is it could be in a way similar not in all aspects but in some way similar to the osi model for networking but this would be for blockchain and smr systems uh in a nutshell basically it will be just a certain set of abstractions that everybody could refer to when discussing and implementing blockchain systems that would make the understanding of it easier which in turn would also make implementation easier so what we could do next is to progressively uh try to define such a model for smr and blockchain systems and uh even start by mapping proposed protocols and designs of systems to that model to that model especially the y3 scalable consensus project or the interplanetary consensus project that could be way to start uh we could keep updating the model as necessary when we when we encounter something that doesn't really fit and when uh the whole thing stabilizes we could even write the write a paper about it next year maybe and try to publish it somewhere and I have the latest update on the scalable consensus project also called y3 so what do we have so far we have the mere unico integration of the consensus module that means that a mere-based subnet can be now instantiated and run in unico just by booting up unico with the correct parameters and this is thanks to denis who implemented the integration what we also have is a reconfiguration that means that note can notes can now dynamically join the system and be added to the system while the system is running we have plenty of technical advancements so uh to mention the most important and interesting ones we have a simple independent availability layer that is currently being extended to a narwhal implementation andrey was taking care of this so what this basically means is that we have a separate module that is concerned with availability of transactions and is independent from the ordering which is done by a separate module and only cares about the order of the transactions that are delivered we have a easy pseudocode like way of writing protocols as mere modules is also thanks to andrey we have lippy to be based communication denis was the person implementing this part and the next two points are thanks to sarge and these points are a simple benchmarking tool that we haven't used yet to obtain some numbers but we're working on it right now and sarge also wrote a similarity time testing engine which basically means that we can speed up tests without having to wait for actual real-time timeouts that sometimes need to occur in the system one more thing that is important that we have is a more clear view of the architectural system which is described in the public design document okay so what do we not yet have and what are the next steps that we need to take with this project so what we need is now a more robust and better tested version of all I mentioned just before in particular this means the system needs to be able to recover from crashes it needs to support weighted voting to be amenable to proof of stake and proof of space time and other kinds of protocols and membership management we absolutely need to improve on the documentation of the system which is currently lacking behind a lot and we also want to make the system robust robust against malicious attacks or at least the more obvious ones such that malicious attacker cannot just come and destroy the system one big thing we want to do is to deploy our system on the builder net test net as a subnet and this is our next milestone for more details you can look at the roadmap the roadmap document that is public that is being modified right now and it will contain all the small low-level details and approximate timelines when like about this process hi everyone this is Sarah giving an update on our project y4 about filecoin mainnet consensus so first some good news thanks to the amazing work of our intern Trisha we have a formal security proof for ec that we want to submit to financial crypto 23 and also with our work we proposed some security improvements to ec and during our team week we decided that we will go ahead with one of our suggestions which was to replace the broadcast in ec so the block broadcasts with consistent broadcasts and consistent broadcasts will allow to prevent equivocation from an adversary so this will greatly stress strengthen the security of ec now we also made some longer term plan that are more research oriented we wanted to investigate a new consensus protocol for ficoin which is an adaptation of a bobtail bobtail is a protocol that was presented in the context of proof of work guy made a proposal to adapt bobtail to the proof of storage case so our plan for our plan for the next couple of months is to first finalize the details of the protocol make some design choice and at the same time see if we can work out a formal proof see what security guarantees this protocol can get so very exciting work coming back thank you


I'm going to present on results on formalization experiences from Southern Africa. Like Louis said, the work that we did was part of a wider study by CFO on behalf of the European Commission to understand the reasons for formalization and its impact. In Southern Africa, we focused on four case studies, one, the bulb of tree, which I'm going to present. We also focused on amarula, which is used to make liqa, hudya, used in the pharmaceutical industry. Then lastly, we also focused on the pelagonia plant, which is also used in the pharmaceutical industry. But for this presentation, I'm going to focus on the bulb of tree. Okay, just to give you some background on the bulb of tree or the bulb of industry. Over the years, a number of bulb products have become commercialized. In particular, the fruit commercialization came about after the European Union awarded the bulb products the novel status. And that opened up a very big market for the EU. And then in the states bulb products, bulb fruit products were granted what is called generally guarded as safe status. And those two global blocks have given bulb products from bulb products. The value of bulb products from Southern Africa is now about a billion dollars per year. And then there's also a flashing market for bulb crafts, especially in South Africa for tourists. And because of this new market for bulb products, resource degradation is crept in and saw a skewed distribution of benefits from bulb abuse. Therefore, according to the state, there is need to find pathways towards attainment of conservation of natural of the bulb products and livelihood improvement for those that use the bulb of tree. That was the main reason why the government decided to come in and formalize the bulb sector. However, there has been other factors that have been driving the formalization process. One has to do with the black suit disease which affects the bulb tree. And it is so far indications that the tree succumbs to this disease if it is overused. And collection of bug predisposes this tree to the black suit disease. And then to ensure social justice, like I said earlier on, to make sure that benefits are equally distributed across board. Then it's also a source of revenue because there is a lot of money involved. It's also potentially a source of revenue for the states through a raft of taxes that I'm going to explain later on. Then there was a bit of chaos in terms of how the resource was being used so the state wanted to restore order. In terms, I'm going to give you an overview of what has taken place. There has been a raft of eggs put in place or that were in place but are now being used to regulate the bulb industry. I will draw your attention to three such key eggs. The rural district council, for example, gives the rural district council which are the local levels, state authorities, the power to collect revenues from use of natural products including the bulb tree. And then it also gives the district council authority to set up local levels, structures that will coordinate management of natural resources. This is a super imposition on traditional systems that have been in place since time immemorial. Then I will also draw your attention to the communal lands forest projects act. This act is interesting in that it criminalizes commercial use of natural products. Use of natural products is confined to on use beyond that you need to get a permit and the forest act authorizes the forest commission, a government arm to each odd permit. I'm going to explain how the permit system works. Then maybe I also need to draw your attention to the fact that while these eggs are being put in place and used there has been a lot of unfolding social and economic processes. In particular I want to draw attention to this operation, operation to move fields or operation in Rambatrina. This was an operation that was done in 2005 by the government ostensibly initially to clear urban areas of illegal structures. But later on it was taken to rural areas and this indeed affected the bulb industry in that we had the structures, that were aligned up along the highway for marketing bubble products. These straws were destroyed in the name of trying to formalize not only urban settlement but also the natural resource management and use. To those who affected the destruction of the marketing straws went beyond that it was also a demolition of life and the future. Then there was also the issue of the land reform. As some of you might be aware of we had the historic if not somewhat controversial land reform from 2000 up to the recent past. And the demand around land reform was that land is the economy and the economy is land. And to people who were using the bulb up trees the land is everything that was on it that is on it had to be used anyhow in order to generate income and to improve the local economy. Anyway I'm going to then focus on just a brief background in terms of what has been done in an effort to formalize the bulb up sector. And I'm now going to focus on what the impacts have been. I'll start off with social impacts. Women have been left out of the lucrative export market for crafts. I said earlier on crafts have a big market in South Africa and in the past what men and women used to take their crafts there. But when the government came in and tried to regulate women have now been left out largely because there is a raft of payment systems that have been put in place. And the way it affects women is that at the border you are required to pay a lot of money and you have to oil hands. There is a lot of corruption involved to the extent that some of the officials at the border post reportedly asking for sexual favors from women so that they can expedite the movement of their crafts. And the morality issues aside in a country where until recently HIV AIDS stood at 25% it will be full had to have extra marital affairs. Then there has been demand for accountability from district councils by local resource users. Local resource users are required to pay a number of levies. For example an annual marketing fee of $10 and local people are saying we can only pay if what we pay is commensurate with services that we get from council. If council doesn't deliver which it doesn't do with all the taxes. There has been resistance from local people to pay. There has been demand for accountability. There is a erosion of local practices. Before government came in local customer systems were in place to regulate use and management of the bob up tree. But now the state is coming in a half way I should say. So some customary practices have stopped to regulate use of the bob up products. The state's approach has been one of carrying a big stick but working softly. Sometimes it comes in heavy ended but at times it assumes it tends to soften its stance and as it says local officials say to show a human face. So sometimes they say ok people you can go and have this but in a sustainable way. Then there has also been some ecological costs and benefits. Trees have become more debak because of the health taxes that people pay. They claim it gives them payment of the taxes and lefis. It gives them authority to go and debak trees for example as much as they want. So a number of trees are now debakking has gone up. There is a removal of germplasing from the area. A lot of fruit trees are collected from bob up producing areas and crushed into oil or exported to or taken to urban areas. So that's the removal of germplasing from bob up producing areas. And then we have noted a trend in that heavily debak the trees tend to produce less fruits. We have use of kumblemender tree products. The number of kumblemender tree products in Bikimia, Akesia that are used to dye maids or crafts made from bob up maids and there has been an increase in the use of these trees. Economic costs and benefits, lost revenues, craft makers and resource harvesters. In the past a study that was done indicated that it also would get about $352,500 a year. But now it has really gone down and the state also has lost out in the process because of resistance from potential taxpayers who are not happy with the way this process, the formalization process has been done. Then the complex regime takes us in the country. It's quite complex. You need, if you want to harvest because I said commercial use is criminalized through the communal forest produce act. But if you decide to, but there is a leeway for one to commercially harvest and that entails engaging the forest commission which is located 130 kilometers away from in the case that I'm presenting on. It's located 130 kilometers from the community and one is to pay an inspection fee of $20 to the forest commission who come and assess if it makes sense for you to go ahead and harvest whatever you want to harvest. Once you have harvested you have to pay another $20 which is called the movement fee to move your product from where you have harvested it to a point where you want to process it. Then if you want to export some products, for example crafts, you have to pay $10 export fee on the Zimbabwean side and then you also have to pay $10 to the minister of agriculture, the inspectorate department to get a fumigation certificate which you never get anyway. Then when you get to the South African side you have to pay an import jute of $8, 8 cents a meter or something like that. So there has been a raft of tax regimes put in place. Then in terms of overall costs and benefits of the formalization process young and educated men who are able to export crafts to neighboring countries are the main beneficiaries because it's quite lucrative to export your crafts to neighboring countries and it's only young and educated men who are now able to bid the system as it were. Then corrupt traditional leaders are also benefiting through charging expedite fees. Of course the status come in but traditional leaders are still regulating use and for you to be able to harvest they can also charge you a small expedite fee. Then some shorty dealers or towns at border points they charge you if you want to illegally cross your export goods they will charge you some fee and it's quite a lot of money about $200 which is about $20 and depending on the value of your goods then the rule of this council has lost and to date when I checked the resist they had only recovered about 20% of potential revenue that they could, they only collected 20% of potential revenue and this arising from the fact that people are resisting to pay the taxes and revenues. And then formalization by way of conclusion I would say formalization of the Babab trade has had multiple and standard consequences. For example by commission or omission state laws are used to exploit the resources without any concern for local cultures and the resource base. And then problems of Babab formalization seldomly fall snugly in the pay view of either the state or a traditional system of governance and this cause for hybrid of both systems to be in place. Customer systems because both systems have their own weaknesses and strengths for example customer systems seem to be weakening due to main factors politics politicization of traditional leaders was supposed to be guardians of customer systems economic challenges some of you might be aware until recently our inflation was over 500 billion percent when you have a situation like that they say necessity knows no law sometimes customer systems couldn't cope then the state is also weakened by its bad images popular policies, operation remove fuel being an example or a case in point and the state is also poorly resourced located 130 kilometers away and with only one vehicle it's not impossible to effectively monitor and implement policies in place. Thank you.