Hi, welcome to Yeager project deep dive. We have three speakers in this talk and we'll go over very many aspects of Yeager projects, but not all of them because we have a short session and we need to pack a lot of content. My name is Yuriy Shkurov, I'm an engineer at Facebook. I'm a maintainer of Yeager and as well as open tracing and open telemetry projects, all three of them are members of Cloud Native Computing Foundation. And I published a book last year, Mastering Distributed Tracing where you can find more information about the history of Yeager history of open tracing and as well as kind of introduction into the distributed tracing as a discipline. First, Anna and I will give an introduction and then we will talk about Yeager features and Yeager architecture. I will talk about something because this is one area where people have often questions and Paul at the end will talk about Yeager integration with open telemetry and deploying Yeagers on Kubernetes. And so first, Anna and I take away with the intro to tracing. Thank you, Yuriy. Hi, everyone. My name is Anna Nyagarwal. I'm a software developer at Grafana Labs and I'm a contributor to the Yeager and open telemetry projects. Today, we're gonna take a look at what distributed tracing is and how it fits into our debugging workflow. We're also gonna learn some concepts and terminology. This is a photo of Uber's internal architecture which is generated by Yeager and we can see that in a mature environment, the number of microservices can run very well into hundreds or even thousands. Each of the green nodes present in this graph represents a microservice and the gray lines represent the communications between these microservices. When we interact with the Uber app, a single request to the Uber infrastructure may look something like this and this typically happens billions of times a day. So what are some of the monitoring tools that we use to monitor such a complex architecture? Typically, we use a combination of metrics and logs. Metrics are great because they're aggregatable. They can be used to alert upon and they're a great way to get an overall picture into the performance of the system. This is a sample metric that I'm exposing from my application. It's a standard Prometheus metric which gives me the duration or the latency of a request to the system. And here, I can see that this gives me a very high level picture saying that my app of the ice cream shop took 10 seconds of latency for a given request. However, if I want more fine grained information about the system, then I can add more and more tags to it. But very quickly, I run into this problem of cardinality explosion. Cardinality refers to the number of items present in a set. And so in the metrics world, this means the total number of values that a given label set can take. As I add more and more labels in order to get more information about my application, I increase cardinality and this can lead to degraded performance and is also not cost effective. Logs are also a great way to check the health of a given service. But under concurrent requests, it's really difficult to get the stack trace of one particular request that pass through the service. And so really we need tracing because traces are like stack trace debugging for distributed systems. And it also tells us a story about the system or it tells us a story of the life cycle of a request passing through the system. Distributed tracing works on the concept of context propagation. On the left, we can see that we have a very simple microservice architecture where an edge service A creates a unique ID for every inbound request to it. And every time it makes a downstream request, it passes along this unique ID as part of the context. As these services do some quantum of work and generate spans, they attach this unique ID to the span. Once they're emitted and stitched together in the back end, we can see the trace as shown on the right. This is formed with the help of the unique ID. And so now let's look at some traces. So these traces are generated from the sample hot rod application that shipped as part of the Yeager repository. When we click on the system dependencies, the system architecture diagram or the dependencies diagram, we see that as a developer, this already gives me a very intuitive picture of the architecture of the system and the request flowing through it. So this shows me the different microservices that are involved and also shows me how many requests were made between these microservices. Next, in Yeager, we also have deep dependency graphs which may look similar to the system diagram at first, but the difference is that now they're filtered by the service which is highlighted. So in the system architecture, we could have calls to Redis, we could have calls from the driver to the Redis which may not have originated from the front end, but in the transitive service graphs, we ensure that the service that's highlighted, only the request originating from that service are highlighted. We can also switch to an operation view in the layout mode over here, which is what is shown here. Next, when we select a trace, this is the typical Gantt chart view of the trace that we see. On the left, we see that the services are arranged in a hierarchical manner, which shows the transitive nature of requests as generated. At the top, we have a minimap which is really useful if the trace has like a couple of thousand spans because we can highlight a given section and it will only show the spans for that duration. Next, we see just with a simple look of this, we can see that some of these operations were blocking. For instance, the front end service, which is called the customer, it's called the MySQL service, probably was trying to retrieve customer information and all other operations were blocked on this service, on this request. Next, we can see that the waterfall diagram over here clearly represents a sequential order of operations. This is also really useful for an application developer and they can look at, they can look at the operations and say, hey, this should have been parallelized why is this running in sequence? We can also see that the parent child relationships are encoded into this view. We can see that the parent always encompasses the descendants. Next, when I click on a given span, it generates some extra information in the form of tags and logs. Logs can be optionally indexed. We at Grafana Labs do not index the logs that are ingested into Yeager. But here you can see that as part of the tags, I can add higher cardinality data, for instance, like the SQL query itself. It would be very difficult to view the query if it was part of the service and operation itself, but here I can add higher cardinality data. This is a new view that's arrived in Yeager, which is the trace diff. We can see that the two traces being diffed are shown at the top. One of them took 2.7 seconds, while the other took 1.4 seconds. So clearly there must have been something very different about this, because even though they're hitting the same endpoint, which is shown at the top, and the difference is all of these nodes. So we can see that they had a common parent, which is the common gateway endpoint that they all hit. But from here, trace B, all the nodes highlighted in red were not present in trace B. So this is sort of like a visual diff that we see in systems like Git, where the red nodes show what was absent, what is absent in trace B compared to trace A, and the green nodes show what is present in trace B compared to trace A. So the operations right at the top over here were more or less common. And we can see that there's like a substantial diff, and this is probably because one of these was a success and the other was a failure. The other view that we have is to actually compare span durations. So in the first view, in the previous diagram over here, we could see this was more of a node-wise view, which showed which nodes were part of a given trace compared to another, whereas this view shows more of the latency differences between the two traces. And the darker the node, the starker or the more contrast between the latencies in trace A and trace B. So for instance, if I was a developer looking at these trace views for comparison, I would see that in trace B, this particular node might have been a problem because this seems to have elevated latencies in trace B compared to trace A. And transitively, all the other upstream services have sort of had a higher latency. If I hover on top of these, it also shows me the difference in latency, so this is really useful for debugging purposes. Next, we're going to quickly browse through the Yeager architecture. So Yeager is not just a single binary, it's a collection of services which help in trace data collection, storage as well as querying and visualization. So on this broad spectrum on the left, we have client libraries which are used to instrument the application and they're typically written in the same language as the application. And so the officially supported libraries are in Golang, Java, Python node C++ and C sharp while PHP and Ruby are community-maintained libraries. And on the right side, we have the visualization front end which is written in React.js. It's beautiful and something that we already discussed. One important point to note is that Yeager does not provide instrumentation. Yeager provides an SDK, but not the instrumentation API. For this, we can use something like open tracing or open telemetry. So a little history about Yeager. Yeager was inspired by Google's Dapper and OpenZipkin. It was created by Uber in August of 2015 and finally open sourced in April of 2017. The same year Yeager joined CNCF as an incubating project and it graduated to a top-level CNCF project in 2019. So this workflow shows what requests were part of what information is propagated as part of a regular HTTP call between services and how the trace data reaches the Yeager back in. When service A, which is an upstream service here, calls a downstream service B, it adds instrumentation from its end to add the unique ID into the HTTP context headers and then passes it along to service B. At service B's end, it receives the HTTP request, passes out the context information and uses the same trace ID in the spans that it creates. Finally, the span data that is emitted from service A and service B reaches out of band to the Yeager back in where it is stitched together to form a common trace. In 2017, when Yeager was open sourced, the architecture looked something like this. On the left, we have the host or container that has been instrumented. It has the application and the Yeager client, which was used for instrumentation. The Yeager client sends spans locally to the Yeager agent, or sends spans to the Yeager agent, which may be running locally either on the same machine or as a Kubernetes sidecar. And from here, the Yeager agent sends spans to a Yeager collector. The Yeager collector is more of a central component, whereas the Yeager agent may be deployed in multiple clusters. This is done for several reasons because the link between the Yeager agent and Yeager collector is cross DC and might break. So the Yeager agent can do stuff like buffering and so on. The Yeager collector is more of a central component that sort of receives the spans, denormalizes them, can perform some additional cleansing of the data, for example, removal of sensitive information and so on, and then ingest this into a database. From here, we have Spark jobs that run on the span data ingested that can compute the dependency step that we discussed earlier. And finally, the Yeager query, which queries the database to help visualizing the spans in the UI. Another important point to note are the red lines in this graph, which shows the flow of sampling information. The Yeager collector is a central store for all sampling configuration, and this can be used to define per service sampling, per operation sampling, and so on. The Yeager client can poll the Yeager agent, which in turn can poll the Yeager collector and receive sampling information without ever having to rotate config maps or something like that. So this is really useful. Another important change we made to the architecture was the introduction of Kafka. What this means is that we've been able to decouple the ingestion of spans from the client to the ingestion of spans into the database. The Yeager collector can enqueue spans into Kafka, and the Yeager ingester can asynchronously consume them and insert them into the database. So if ever we receive a high volume of spans because of increased traffic, they can be buffered in Kafka without overwhelming the database. The flim streaming jobs can also now enqueue from Kafka and write dependency information into the database. The rest of the architecture remains the same. Speaking of technology stack, Yeager is written in Go. It's a Go back in for tracing data. It has a pluggable storage with support for Cassandra, Elasticsearch, and Badger databases. It also has an in-memory store, and it has a pluggable storage and uses Hashicorp Go plugin. So if there are experts in other databases, you can write a plugin which can be plugged into the Yeager collector. Yeager uses a React.js frontend, which is really feature rich and beautiful. Yeager has open tracing instrumentation libraries. It's compatible with all open tracing instrumentation libraries. It also has strong integration with Kafka and Apache Flink for tracing analytics. And with that, I pass over to Yuri to talk about sampling in Yeager. Thank you. Okay, let's talk about sampling. In the distributed tracing, we use the term sampling in a classical statistical sense, meaning that we try to select a subset of all individuals or traces from a population of all possible traces in order to estimate certain characteristics of that population, or more specifically to reason about application performance based on those samples that we've selected. The question is, why do we need to sample? There are several reasons. The first reason is that tracing generates a lot of information and storing all of it incurs significant storage costs. Here's some napkin math. Assume that we have a tracing span of about two kilobytes on average and we have a server doing 10,000 query per second. So that means we'll already generate in 20 megabytes per second of data. Now assume that we have 100 instances of that service. So that's two gigabytes per second or 170 petabytes per day. And that's just for one service. If your architecture is complex, it may have hundreds or even thousands of services. You can imagine how much data we could generate if we actually were sampling every single request. The other reason is that if we're not sampling, then the instrumentation that collects the data from the application by itself introduces performance overhead. Here's an example again. If we have a service doing 10,000 QPS, then we have roughly 100 milliseconds per request to work with, right? And so if the instrumentation takes like five microseconds, then that's already 5% overhead on your compute costs. And that, like if you run in a very large fleet, that's a significant amount. And finally, the third reason is that when we collect traces, that data is actually very repetitive. A majority of traces look very same. They have the same shape, roughly similar latency measurements. And so storing all of them is kind of useless. We don't get any more insights if we're storing all of them. And so that's why we sample. However, in distributed tracing specifically, sampling has a slightly interesting aspect. What we need to do, so-called consistent sampling. And what we mean by that is that if we collect spans for a trace, then we should either collect all of them across the whole architecture for that given request, or we should collect none of them, right? Because the alternative to that is shown in this diagram here, let's assume we had a system on the left. And then we started randomly making sampling decision as part of the request. And the three nodes happened to sample and the other two didn't. And so we got a trace, which looks like on the right, but that trace is kind of broken. We have some of the nodes that came without the parent. And so it's hard to reason about these traces. And so they're not as useful as if we sample consistently and we get the whole trace every time or we don't get the trace at all, which is also acceptable. And as far as specific sampling techniques, there are two primary consistent sampling techniques that are used in the industry. Head-based is like most popular. It traditionally has been used from the days of Google's dapper paper. All the modern tracing systems support that. And recently in the last few years, tail-based sampling started appearing as another popular techniques. And I'll talk about both of them. So let's talk about head-based sampling or also called upfront sampling. The approach there is very simple. When we start a new trace, let's say when we generate a brand new trace ID because the incoming request didn't have any trace ID, then we make a sampling decision at that same time and we capture that sampling decision in the trace context which is propagated throughout the request. This way, we guarantee that the trace is consistent to sample as long as all the SDKs on the path of the call graph respect that sampling decision and capture the data accordingly. That implementation has minimal overhead when the trace is not sampled because again, we propagate the flag saying don't collect anything. And so all the calls to the tracing SDK become no open, they're very cheap. And so we don't affect performance by that and they don't collect any data. It's also fairly easy to implement because if you think about it, the code is really, you just make a probabilistic decision or some other algorithm to decide when to sample and then you just pass it around and all the other downstream SDKs are just respected decision. However, that approach also has a couple of drawbacks. One is it's not as good as capturing various anomalies. For example, let's say you're looking at your metrics and you see your P99 latency spiking suddenly. So you wanna see, okay, can I find some traces that represent that spike? Well, P99 already means one in 100. And if we're sampling with a rate of 1%, that means that our total probability of actually catching your P99 latency trace is one in 10,000. Now, if your traffic is very high to service that you have sufficient number of traces captured even with that probability, then you probably can get some example. The more rare the outliers are, the less chance you will actually capture them with the uniform probabilistic sampling approach. And the second big drawback of upfront sampling is that it cannot be reactive to how the request behave in the architecture because the sampling decision needs to be made at the very beginning. When we know nothing about that request, maybe we know like which endpoint was hit, right, at best, but nothing else. And we definitely don't know what's gonna happen to the request in a life cycle, but we already made the sampling decision and every downstream service has to respect it. And so it's very hard to sort of react to errors in upfront sampling. What about something head-based sampling in Yeager? So Yeager is the case out of the box, support that. And they come with the assortment of different samplers such as like always on, always off, or probabilistic, the most commonly used, or rate limiting, meaning let's sample like 10 traces per second or more things like that, right? And the benefit of that is those samplers are very easy to implement. However, the downside of sort of configuring sampling in this way is that when you have a service and you instantiate a tracer, you have to give it a sampler with a specific configuration which means that if you have thousands or hundreds of services in the organization, then all those decisions are made by individual developers. They're kind of sticky because once you deploy it, it stays in production with that, whatever probability or rate that was assigned. And the developers, they usually don't know what effect individual sampling rate may have on your tracing backend. Can your tracing backend actually support that level of sampling, right? So there's like a disconnect between the interests of the backend and the capacity of it and how the sampling is configured in the SDKs. And so for that reason, Yeager SDKs actually default to a different type of sampler which is called remote sampler. And what that means is that it actually reads the configuration from the central tier from the collectors in Yeager backend such that that configuration can be controlled in the central place. And then it's the team that runs the tracing backend can actually determine how much sampling for which service for which endpoints should be happening, right? And you can change it on the fly if you want to, but the point is that you centralize the configuration rather than having it all done at the edges of your traffic. Here's an example of a configuration for that type of sampling. So on the top left, we have a default sampling strategy which would apply to any service unless otherwise configured with something else, right? So here we see it says like everyone should use probabilistic sampling with 50% probability, right? Except you can also provide some overrides for very specific operations. So let's say we don't wanna sample anything on the health or on the metrics endpoint, right? And so here we give them probability of zero. On the right side, there is a specific override that we can do per service. So if we know some services that let's say maybe our full service here is very like low QPS. And so we give it a higher probability of sampling. But on the other hand, we can also override individual operations on that service. Now let's talk about tail-based sampling. So in tail-based sampling, as the name applies, the decision is made at the end of the trace rather than the beginning. What that means is that when we make a decision when we actually already observed the whole trace and that decision can be a lot more intelligent because we can look at latencies that we've seen in the trace, we can see have there been any errors, maybe there's unusual call, graph shape, et cetera. So we can be very advanced with that decision. And basically either we, instead of capturing samples uniformly, we can say let's steer them towards anomalies. If we have like a long latency or if we have an error, let's always capture that example. So that gives us control over what kind of data we can get into the backend. That means that we can also catch anomalies much easier than with the upfront head-based sampling. And another benefit is that because we are getting all this data into collectors before we make a sampling decision, we're actually dealing with a lot more data that on which we can run various aggregations. Let's say we want to compute some statistical aggregations of like what latency we're observing or histograms we're seeing in the services, right? If we do it before samples that we just have more data to work with and those aggregates will be more accurate than if we were doing them after the sampling, especially if we were doing after sampling which is not uniform, but like skewed towards anomalies. Two drawbacks though of that approach is that because we need to collect the whole trace before we can make a sampling decision, it means we need to store it somewhere, right? Because traces are distributed and they're produced in the individual pieces from multiple services. So you kind of have to collect them all in one place. You have to hold on to it until you receive all the data for that trace, which is also and like somewhat indeterminate time potentially. And typically in modern systems that support tailway sampling, this is done in memory. Like you store traces in memory, then you make a sampling decision. And if the decision is no, you just throw them away, expire from the memory, right? And because most of the requests are very short-lived, you can actually scale that system fairly well to very large traffic of inbound traces. And the other downside of tailway sampling is that if the goal is actually to collect all the data upfront and then sample only so much so that our storage can support, then all this collection upfront introduces an additional overhead on the application itself. As I mentioned in a napkin math before, you can have up to five to like 8% overhead on very high QPS services if you essentially collect data on every single request and export it into a collector tier before you make the sampling decision. So it's a bit expensive. In terms of Yeager support, so Yeager as we'll talk later is moving towards building most of the Yeager back ends on top of open telemetry collector. And open telemetry collector does have a logic for tailway sampling, all right? You can configure various sampling roles already based on like latency or certain tags, like the error flags. Unfortunately at this time, it's only in a single node mode. So sort of you can run a single service and send all the traces there, then it'll work. But if your traffic is such so large that that service cannot scale to it and you need to run multiple collectors, normally they're stateless, so it is not a problem. But in case of a tailway sampling, they become stateful and there needs to be some sort of a sharding solution which is right now not available, but it will be available in the future. There are already prototypes in open telemetry. So that is all about sampling. And now Pavel will talk about Yeager and open telemetry integration. Hello everybody. My name is Pavel Lofi. I'm software engineer at Traceable AI and I'm core maintainer of Yeager project and contributor to open telemetry and open tracing projects. In this section, I will talk about Yeager and open telemetry integration. Before we deep dive into open telemetry, let me quickly talk about open tracing. So we better understand open telemetry as the next evolution of open tracing and data collection libraries in general. So on this slide, we see basically two parts. On the bottom, there is our tracing infrastructure collecting distributed traces from the user application. And on the top, there is user application process that is instrumented with open tracing. Open tracing is a specification that tells what kind of data should be collected from the RPC frameworks, databases and so on. But it is also an instrumentation API that sits in between user application code and the tracing library implementation. The tracing library implementation is basically the implementation of the open tracing API. So this architecture allows us to change tracing system without changing all the instrumentation points that are embedded into RPC frameworks but also in our application code. However, there is one downside that if you want to do that, we still have to recompile and redeploy our application. And this might be a problem if we have, you know, dozens, maybe hundreds or even thousands of microservices. It can be very costly, a thing to do. The problem is open tracing doesn't define any data format. So all the tracing implementations, they use different data formats. So let's have a look at the open telemetry. So we see basically the same architecture as on the previous slide, but open telemetry is now substitutes the instrumentation API but also the implementation of that API. But we see also open telemetry in the agent and the collector. So the difference between open tracing and open telemetry is that open telemetry defines the API but also defines the SDK, the implementation of the API. And it also defines a data format that is exported from the SDK. And so this allows us to have an open telemetry collector which accepts, you know, this data format and then can translate it to different data formats for different tracing systems. And this pattern allows us to change tracing system without recompiling and redeploying our applications. So maybe a little bit confusing for Yeager users is that we see open telemetry logo in the agent and collector. And this is purely Yeager's decision because in Yeager project we have decided to base our agent and collector in gesture, basically all our backend components on top of open telemetry collector. So this way, all Yeager backend components will provide the same functionality that is available in the open telemetry collector. And we will just add Yeager specific functionality to it. For example, storage implementation. So let's talk more about open telemetry collector. The collector itself is written in goblin, is Yeager backend components. And in terms of Yeager integration, we basically rebased our backend components on top of open telemetry collector and we have added Yeager specific functionality to it. So now Yeager users will benefit from all the functionality that is available in the collector, but they will still be able to use all the current functionality of Yeager components. We also want to make it very easy for users to migrate to these components. So we will keep the current architecture with agent, collector, in gesture, and all in one, and also probably the same configuration options. If you are interested on our website, there is already a section for open telemetry where you can read what kind of configuration options are provided, but also there are some guidelines and you can start using these new components right now. So let's talk about Yeager and open telemetry SDKs relationship. So open telemetry SDKs, they usually support Yeager GRPC exporter and Yeager propagation format. So this basically allows you to use or to deploy services instrumented with open telemetry into an ecosystem where you are using Yeager clients. Then there is open tracing machine, which is basically an open tracing implementation that uses open telemetry SDKs. And this allows you to use all existing open tracing instrumentation libraries with open telemetry SDK. And last but not least, Yeager clients, they support W3C Trace Context, which is the default propagation format in open telemetry SDKs. So you will be able to use Yeager clients in a new ecosystem where open telemetry SDKs are used. Okay, let's move to a different topic, which is Yeager and Kubernetes. Yeager provides an excellent integration with Kubernetes and you can deploy Yeager into Kubernetes by using Helm charts, plain Kubernetes manifest files, and also Yeager operator. Operator is probably the most advanced method how you can deploy Yeager into Kubernetes. So it follows the standard operator pattern where first you have to deploy Yeager operator, create custom resource definition for it, and then you will be able to create custom resource where you define what kind of parts of Yeager deployment or how the Yeager deployment should look like. So for example, in the custom resource, you can define that you just want only one deployment or you want a production deployment with a storage backend. Yeager operator can also provision storage begins under some conditions. So for example, if the cluster, if you have deployed in the cluster Kafka or Streams operator, Yeager operator will be able to auto provision the Kafka cluster for you. Okay, this is everything from my side and thank you very much for your attention. Thank you, Pavel. This is the end of our talk. These are the different ways you can get in touch with the Yeager maintainers and community. We have a barbecue meetings where you can dial in and participate in the discussions and make sure to start the projects on GitHub, developers like those stars. Thank you very much for joining.


Hello and welcome to the session. In this session we discuss the following question that says using integration, find the area of the region bounded by the curve x square equal to 4 y and the line x equal to 4 y minus 2. Let us now proceed with the solution. We are given a curve x square equal to 4 y, let this be equation 1 and the line is also given to which is x equal to 4 y minus 2, let this be equation 2. To find the area of the region bounded by this curve and the line, first the formula is draw this curve x square equal to 4 y. This represents a parabola with the vertex at the origin and it opens upwards. This is the parabola x square equal to 4 y. Next we draw the line x equal to 4 y minus 2. This is the line x equal to 4 y minus 2 and the point of intersection of the curve and the line. Now equation 2, we have 4 y is equal to x plus 2, substituting equal to x plus 2 equal to x plus 2. This gives us x square minus x minus 2 equal to 0. Now split in the middle term we get x square plus x 2 equal to 0 and from these two terms we get x into x plus 1 d whole and from these two terms we get minus 2 into x plus 1 d whole is equal to 0 and can be whole into equal to 0. From where we get x equal to minus 1 or x equal to 2. Now this equation 4 y equal to x plus 2 equal to x plus 2 equal to 0.4. Let this be equation 3. Now substituting minus 1 plus 2 which is equal to 1 upon 4 and equation 3 upon 4 which is equal to 4 upon 4 that is point of intersection say point b has coordinates to run intersection the curve and the line that is the a with coordinates minus 1, 1 by 4 and b with coordinates 2. So this is the point a with coordinates 2, 1 of the shaded region that is the area a of b a we say that the required area is equal to the area n b m perpendicular to the x axis shaded region would be the area a region a of b m equal to 4 y minus minus 1 a of b m l a is the area n equal to minus 1 to x equal to 2. The integral may be the value of x goes from minus 1 to 2 and value of y from the equation of the line which is given by the equation 3 minus y is equal to x plus 2 upon is given as integral minus 1 to 2 a of b m l a by the integral where x goes from minus 1 to 2 this area a of b m l a square equal to 4 y from x equal to minus 1 to 2. So from here we find out the value of y which is the area x square upon 4 dx. So further this is equal to integral minus 1 to 2 x plus 2 upon 4 minus x square upon 4 we have dx equal to integral minus 1 to 2 minus x square this 1 upon 4 is the integral so 1 upon 4 into integral minus 1 to 2 plus x plus 2 you have integrating we get 1 upon 4 into 1 3 plus minus 1 to 2. So we get this is equal to 1 upon 4 into first we put the value of x as 2 so here we have upon 3 plus 2 square is 4 upon 2 plus 2 into 2 is 4 for this whole plus 1 by 2. Now taking the answer here which is 6 we get minus 16 plus 12 minus 1 by 3 is 1 by 3 plus 1 by 2 minus 2 the whole which further gives us 1 upon 4 into 20 upon 6 minus now taking the answer here which is 6 we get 2 plus 2 minus 12 upon 4 into 20 upon 6 into 7 upon 6 so that becomes plus 7 upon 6 which gives us 1 upon 4 into 27 upon 6 and 3 2 times is 6 so this is equal to 9 upon 8 is equal to 9 upon 8 square units. 3d region is 9 upon 8 square units so this is our answer this completes the session so I hope you have understood the solution of this question.


Your Excellencies, Ministries, Secretary-General of ITU, ITU Directorates, distinguished guests, ladies and gentlemen. I want to first thank and express my gratitude for the Government of Argentina for hosting the World Telecommunication Development Conference 2017, celebrating the 25th anniversary of ITUD in this beautiful city of Buenos Aires. I also want to thank the ITU, especially ITUD, for organizing this conference. Excellence, ladies and gentlemen, and distinguished guests, it is a privilege and an opportunity for me to make a few remarks on the theme of this conference – ICT for Sustainable Development Goals. But before I do that, allow me to tell a little bit about the telecommunications and ICT developments in Somalia. The ICT sector is one of the best of the brightest spots of the Somali economy, contributing close to 10 percent to the national GDP. Today, most Somalis enjoy relatively high mobile communications and mobile money penetration levels and lower rates compared to other peoples from countries in the region. However, internet penetration rates are among the lowest in the region due to limited domestic broadband network infrastructure and international connectivity. When the state-owned national posts and telecommunications infrastructure were destroyed, private operators filled the vacuum by building successful mobile communication companies in a totally unregulated environment. Due to the unregulated nature of the ICT environment in Somalia, server providers are neither incumbent by regulations protecting consumer rights requiring interconnectivity and interoperability, nor operate with formal licenses for a spectrum usage or provision of service. Just last month, the two jumpers of our parliament passed the National Communication Law with the President of the Federal Republic of Somalia, His Excellency Muhammad Abdullah Muhammad, has signed into law on 2 October 2017. My ministry is now in the process of establishing a regulatory authority. As we built the regulatory authority, we would look to leverage the expertise of the ITU and benchmark other relevant regulatory authorities. Excellency ladies and gentlemen and distinguished guests, many more eloquent speakers have and will articulate far better than I can what ICTs for sustainable development entail. But let me just say that for Somalia and I would imagine for other less developed countries, our fear and concern is being left behind in a world where countries with advanced economic economies are moving into the fourth industrial revolution while we are still struggling with providing basic internet access to our people. Today, access to knowledge and information is necessary to participate in the global economy. Yet far too many people in the developing world, particularly in the least developed countries lack access to computers and basic internet. This is especially true in my country which is struggling to recover from years of conflict. What countries like Somalia need are investments in their ICT infrastructure This can be done either directly by providing, directly by private investors or in collaborations with the government in public private partnership arrangements. In Somalia, we are keen to attract investors to develop our ICT sector so I call on private companies and member states alike to consider investing in Somalia. Thank you very much for your attention.


Elections are a very essential part of any country's political process and progress. They are very expensive for the government, electoral body and the candidates, particularly for female candidates in Nigeria. The United Nations has scored Nigeria low in the area of women participation in politics. Also, the report by the Gender Strategy Advancement International states that women participation in Nigeria falls below the world and African continental standards. Most female candidates in Nigeria need a lot of financial support in raising funds because of the expensive nomination forms, party fees and running a campaign office. In bridging this gap, women in successful career, whisker, in partnership with Chimamanda DiChi, organized a non-Patterson fundraising in compliance with a campaign finance law in Nigeria. We were all disappointed in 2019 at the decline of female representation at all levels of governance. The percentage of female representation is currently at a dismal 3.6%. The picture is not likely to be very different, to be honest, in the 2023 elections unless people like you and I come together as we are doing today to change the narrative, to change the landscape. I think that because of the challenges women face, because of the socialization women, women experience, that women are more likely to do things differently. Women are more likely to think of consensus, for example, women are more likely to put their ego aside. But on the other hand, I do not think that the case for women is that they are better. I think the case for women, political candidates and political representation is that women are food citizens and if we want a more perfect democracy, then we should want better representation. The candidates presented their manifestos and spoke about their need for finance during the fundraising. The importance of female representation in politics also takes center stage. Women make up half the planet. So when you have a situation where women are 8% of representation, they are not representing society and it's really that simple. And also women and men lead very differently. So there's the empathy that a woman brings to leadership and people talk about it and the other flip side, if women are good enough to head companies, to head homes, to head businesses, why shouldn't they be in political leadership as well? This may just be one step in creating solutions to increase female representation and participation in Nigerian politics. Bill Mooner, J-Fee, reported for PLOS TV News.


I'm Amber Richardson, I'm from Hollister, North Carolina and I'm a senior. I love my friends here at Science and Math because they are so different and so awesome in so many different ways. Being able to lay on the top bunk of my bed and call one of my friends and have them come in an instant to my rescue, no matter what it is, maybe I needed something for homework or I'm having some kind of crisis, you know, boy drama, anything like that.  These friends are just, I mean, they're irreplaceable, they really are and it's really deep because you go through a lot and you're really pushed here so being able to call them and have them come to you like that and support you through everything. I've had to deal with things that go on at home from here.  Being Native American and being a big part of the powwow that happens here on campus every year really makes me feel even more at home because I can bring that little part of me, that part of my culture here and I can share it with all of these people that are both from the campus and from the surrounding area and they understand it and they like it and they want to get involved. Science and math has made me stronger in a lot of different respects. It's made me more confident before I didn't really feel like I knew what I was capable of but now being here I understand that, yeah, I actually do know a little something, yeah, I am kind of smart. You know, yeah, I can do this and I can go into a room and make a friend or be myself and have people respect me for that so it's just really taught me to be comfortable with who I am.


Alright, in this video I'm going to show you how to find your Instagram URL. Alright, so the first thing you want to do is you want to log in to instagram.com and up here's your URL or the web address. You're not going to use instagram.com. What you're going to do is you can go down to more and you can switch accounts. So you kind of go back and forth to different accounts, okay? And then you want to click on profile, okay? So once you are here with your profile, then up here is going to be your Instagram URL.


Great, thanks for setting that up Sean as a backup or resume recording and I'm gonna set Shar and Tim here Yes Set both of you to co-host Just in case make co-host just in case Something happens to my why isn't shark oh Something happens. I get knocked out of losing. All right shark take it away. It's all yours sounds great Looks like we have Steven Corinne our great speaker for the day here So I'll I'll pass it off to Tim to walk us through the working group status updates Yes, good morning everybody Just give me one second here to share my screens. We can kind of all walk through it together So yeah, good morning. It is June 15th today and on our call day will be Reviewing some working group status updates and then we also have a presentation from Steven Curran So, thank you for joining us today Steven appreciate it Quick reminder we are under the hyperledger antitrust policy, so please just be aware of that Few announcements. We have a few upcoming speakers. We have Nick Steele on the 29th Stefan Mui on the 13th of July and then Dimitri Zagan Dulan on the 27th, so if any of these Speakers look interesting to you, please be sure to come on back in a couple weeks And then we also have a hyperledger in depth with the red data technology So that's on June 21st and anyone can register at this link right here So jumping right in it looks like the hyperledger Indy contributors working group met on the 6th was anyone able to attend this call Yeah, I I was I can give a brief update But I wondered if it also might be useful to see if we have any introductions that anybody wants to make on the call I think we've got we've got a fantastic group here and and probably a lot of new faces to this call so if people want to take the mic and and Introduce yourself and say you talk about your interest in in in decentralized identity Now would be a great time Hi James camp on the CTO at Wygren, which is a virtual power plant company and I think we might use this for IoT device identification or potentially also users. Thanks Thanks for joining. That's great My Novak, it looks like you have your hand up. Yes. Thank you. Good morning everyone. My name is Michael Novak I'm with the open voice network and been a longtime fan and student for digital identity I'm very excited. I come out of the IoT world So I see this as being a key technology enabler for this But also recently you may have heard of generative AI in the news at least once or twice in the last 15 minutes And again verifiable credentials and digital identity are perfect fit for Conversational voice as well as taking inanimate objects. I'm really excited to check Stephen's math today And I'll run through generative AI. Don't worry Stephen. I'll make sure you're doing it correctly. Okay? Awesome We're glad you're here. Any other Introductions that anybody would like to make? Hey, good morning. Um, Steve Michaelis Martin from Boeing and Boeing Vancouver We also are working on a project to Integrate the verifiable credentials and part of our Authorization access and identity Authorization access and identity and access management authentication mechanism Sort of a variety of applications to it that we're researching at the moment. So This is a fantastic application interested in How this moves forward so Thank you Absolutely. Thanks for joining Steve. I'll drop the Meeting page link in the chat here Uh, let's see. Oops So I think I dropped the wrong link in the chat, but I will correct that right now Uh, let's see so that um anybody can Um Put their name on the attendees list if they would like So great unless anybody else has any um announcements or introductions that they would like to make we could um Continue on with the um working group updates It sounds like that's about it. Uh, sure. I think we left off at the indy contributors call Yeah, absolutely. Give us a quick summary of that Yeah, so uh, we talked about uh, indy community Contribution so just a discussion about how they're really successful indie networks. Um, just few fewer Code contributors and so perhaps this is because indy just works well and and deployments are pretty specific Um, but at the same time we have a roadmap of things we would love to add to it and and see implemented. So Um, just a discussion about that that I think was really useful and then we also spent time on the call Going over open issues in indy Plenum, um, Steve and I don't know if you have anything you wanted to add about that discussion or what we did on that call No, that sounds about right Looking forward to um more discussions on you know, where indy's going and and um You know how we can Configure on how to expand uh contributions Yeah, absolutely Awesome. Well sounds good. Thank you for sharing It looks like the areas working group met just yesterday. It wasn't even able to attend the most recent areas working group calls Okay, uh, well, it looks like they were discussing some o w f resolution and did appear Stess unqualified migration stuff if you want more info. Uh, these links are We'll take you right to their uh notes The areas bifold group met on the sixth. Uh, was anyone able to attend the areas bifold call Okay, it looks like they're working on an update and discussing some some key issues Uh, the areas cloud agent python users group, uh, met on the 13th. Was anyone able to attend this uh session Uh, yeah, I was there. Um, talked about an update on the BC gov code with us, um That we at at indy co are working on to update acropi to use the um hyperledger version of of a non creds And so talking about the refactors got the um mvp of revocation completed Um, which was a big step and and the things we're looking at next are the automated registry set up, um Genericizing the revocation registry registry recovery um test updates clean up as well um, and we also talked about, uh, the Um 072 final, um release and and merging prs in acopi Um, steven. I don't know if you again have have anything you'd want to add to that summary I can figure it out on mute. Um, yeah, um 082 is ready. Um, we've got some final things going into that um, and then we went into um acopi plugins and Updates in progress were flying on making stuff and we added a new maintainer to the project, which is pretty cool All of those are covered there. Um, welcome folks to join us at the next meeting in two weeks Two weeks from this one Sounds good. Thanks for sharing I believe we've met I'm not sure if this was the same day as our last meeting But was anyone at the latest aries framework, uh, job script call? It looks like they're kind of Discussing what the future of areas will look like and how to get started for more details. You can click that link Uh versus getting into life. Uh hyperledger and on credits looks like they've been on the fifth. Uh, did anyone attend the non creds call? Um, we've had a couple of meetings. Yeah, um Basically, you know that We're moving forward on the spec. We now have a mentor Uh part of the program in the mentorship program working on the spec So we're moving that forward and also some super interesting discussions on the 2.0 um plans and um Some of the substitutions of new zkp stuff, which we're going to be talking about soon On this call, um into An opera institute So it was the topics going on in in that working group. All right, awesome. Thanks, steven It looks like to ip hasn't been doing too much looks like uh The diff didcom spec working group met on the fifth. Uh, was anyone able to attend the uh, the didcom spec working group Looks like they're working on ion compatibility for didcom 2.1 And then they're working on some new marketing initiatives for didcom This is may All right, unless i'm mistaken. I believe that is all of our working group updates. Uh, Does anyone have any general updates or groups that we've missed? Um, hey tim just uh Quick call out, um the areas framework javascript recently released 0.4.0 um The team who's worked on that including ariel uh baron and kareem are going to give a demo slash workshop On wednesday june 28th. Um, the link is in the Chat um It's not really going to be a hands-on workshop But they want to really go in depth and all the changes and the new stuff that's in the new release. So that's uh coming up in Uh, a little less than two weeks All right, very cool. Thanks. Sean Yeah, i'll give another a brief pause to see if there are any other updates or announcements Before we hand it off to steven. All right, steven the floor is yours. All right welcome Let me share my screen And i'll jump into the presentation Close that Got chat open off to the side. So if anyone has comments, let me know Let me leave that there Well, not quite there because I can't see There we go All right, can you see my screen? Yes, it looks great. Thank you. Okay. Um, this is a presentation that I did at the um open source summit in north america or a similar one so i'll i'll I'm using that i tweaked the slides a bit to adjust into it, but um We'll share them up in the top corner if you want to there's this bitly di dash zkps. That's the um Link to the slides themselves. So if you want to grab those now or follow along I should probably put that in chat, but maybe someone can um So online identity with verifiable credentials and then we'll get into the meat of it Which is zkp using high school math just to explain what? Zkp zero knowledge proofs are so i'll jump in that's the agenda A brief brief since this is the identity sake there's not a lot you need to know about Online identities and then focus mostly on the zero knowledge proof section and what they are So um credentials paper credentials are what we use in the world. That's what we've used for 2,500 plus years Many of them are for identity. There's ones down here are things like professional The attestations professional credentials like, you know, I'm an engineer. I'm an architect. I'm a doctor or I'm a lawyer or those types of things. There's supply chain, there's Iot certifications that can be for well, I guess those are definitely not paper Um, but there's there's lots of paper credentials in the world and the paper credential model is is one that As they say we've used a an issuer some sort of authority gives a Credential to a holder that holder puts it into their wallet or puts it into their filing cabinet or puts it somewhere and sometime later in a separate transaction a verifier Um wants to see that piece of paper for some Some business purpose and so the holder pulls it out of the wallet or Takes it down to the office of the the verifier and shows them the piece of paper and the piece of paper in theory Um, and I put quotes around proves who issued the credentials So there's some sort of marker on the credential that shows who issued it who holds the credential. There's some sort of binding um on the credential between the person presenting it and the credential itself And some sort of verification that the the claims are unchanged And proves is is done because the big thing here is is concerned with forgeries and things like that that the holder somehow manipulated the document either created it themselves or altered it in some way Um trust is largely this Between the holder and the verifier, but there's also the trust between the verifier and the issuer the verifier chooses What issuers um the credentials of what issuers they're willing to correct to accept Um, so in when I talked about that there's both the technology and the governments Um aspect to it. Does the you know technology does it look like it's on the right paper? Does it look like what that that organization that issuer organization produces? Does it look like there's you know ink marks on it where um, I changed my Uh date of birth on my driver's license so that I could Use it for other purposes and then the governance is is things about what's the source of the of the Authority of the issuer. Um, is it a trustworthy organization? What where where does their authority come from when they issue a piece of paper? What are the processes they use for that? So those are all the things we talk about in identity Paper identity paper credentials online are basically done these days by taking a picture of them and scanning them and that's and that's the where Where we are today generally with with the use of credentials digitally What we want is a verifiable credential model again Very I think everyone here should be familiar with this the issuer provides a An issuance of a credential that has got some cryptographic Backing to it. They hand it to the holder Um, the holder at some later time that the holder puts it in their wallet holds onto it Their their digital wallet holds onto it some later time they present it to the verifier Um, and there's a verifiable data registry is is a place where Um, cryptographic material goes such that when the verifier gets the credential from the holder Um, they are able to verify it Not by contacting the issuer and finding out whether it's about it's it's accurate whether it's it can be verified But rather by going to some independent place to get information such as public keys and so on to verify the cryptography um We've used this list one two three four in fact Verifiable credentials with capital v capital c as in defined by the w through c Only talks about the first two which is who issued the credential and the claims are unchanged So there is a path to find out who issued the credential via the information in The the presentation provided from the holder to the verifier and there is a signature on it A cryptographic signature to verify the claims are unchanged um In the inon creds world in places we work There is a formal way of defining who holds the credential of binding between The person presenting the credential and the credential itself how they are associated That in inon creds is formally defined as part of the cryptography in other in w 3c um Data model standard that's outside of this fact and has to be determined in some other way so something like there's a picture of the person in it and That's the binding or there's some uh, or there's a a um A dig And the person proves control over that did some sort of mechanism to bind it and then as well There's a fourth item which is um available in some types based on the issuers Use case and and how the issuer handles it which is the claims have not been revoked. So those um, those are the proofs that come about Um way less concerned about whether the holder forced it. It's almost it's pretty much impossible to force those types of things much more on Do you trust the issuer? And um, so that's a big piece There's also concerns about the software that goes along. So do you trust the issuer software or do you trust the holder software and so on um This is different from open id connect And log in by facebook So I did want to underline that when I talked about this or for those new to the topic Again, I think everyone knows that here and and the and the big issue is that the issuer is involved in every interaction when you're using open id connect that the There is only a single process and in that process the user sort of consents to both the issuer and the lying party And the issuer delivers the data directly and of course in a verifiable credential model On presentation the issuer is is kept out of the picture and the interaction is only between the issuer and the lying party okay, that's the background on Verifiable credentials and what we're using them for um hyper ledger and non creds is a an instance of uh a way to use verifiable credentials or a verifiable credential type It's a project at the hyper hyper ledger foundation. Um, there's a complete open source implementation of it in rust um, that is based on the non cred specification that is also Being built and created in the hyper ledger foundation This this implementation has a long history hyper ledger indy came out about seven years ago um in the the self service self sovereign identity stack and non creds has been pulled out and revamped From that indy implementation that indy implementation itself derived from a from an ibm implementation So there's a long history of this um The big change that was implemented in pulling and on credits out of indy is um verifiable data registry and agnosticism Ledger agnostic, which means you do not have to use an indy ledger to store the objects Necessary to have the and on credits interactions. They can be published in a variety of places and people have already published Such objects in a number of places outside of indy indy's still the most You know commonplace you'll see them, but it's no longer a requirement And and so that's a big push that we're trying to do in the um in the on credits community So what is it on credits add to the picture? Which is um privacy and that privacy comes Privacy preserving elements and that comes in four Four flavors one is selective disclosure so that when you have a credential That you've been issued and you present it You don't have to present the entire document So unlike a paper document where you hand over the paper document to be looked at um, you can actually Redact if you will some of the fields and just present the things necessary for the business transaction you're conducting and so The verifier can still see who issued it can still verify that it's um the the various aspects of it But they don't see all of the raw data of the attributes within them um predicate proofs so predicate proofs are um where a This is the most obvious zero knowledge proof where you prove that you are for example older than a certain age based on a date of birth in the credential without Sharing the date of birth itself. So you're you're proving something In in the credential, but you're not actually sharing the data for it and and by prove You're not claiming or or suggesting self attesting. You're actually proving it cryptographically um This is a big one that of why uh, non creds is Is really important is unlinkable identifiers So in in pretty much every other Verifiable credential model and approach when you share a presentation you're sharing Unique identifiers either for yourself or for the credential itself. So the sign that if you Are given a verifiable credential and the way of presenting it is simply to show the other party the credential itself That the signature on it is a unique identifier. It's very much unique and and so you're actually sharing a unique identifiers For it and so what an on creds does is goes highly very far out of its way to make sure that there is no linkable identifiers simply by presenting a verifiable credential that's that is a key place where um, where ZKPs are used zero knowledge proofs which we're about to get into we're getting there Which is that you can Prove that the signature for example is valid on a verifiable credential Without sharing the signature itself and again proof being the argument there and finally multi multi-credential presentation so inherent in and on creds is a That you can present multiple credentials at the same time And prove that they're tied together and do that all with selective disclosure And again that allows for a data minimization if you need to prove that you're a lawyer and You know who you are as a as a as a resident of sabers plumbia and prove that you're a lawyer You can present those two credentials minimize the data share And and still prove those things and prove that they were both issued to you Or to your wallet So that's the key features that are added I should throw that I do throw in that I do a lot of my work With the digital identity team in the government of verges plumbia This slide sort of highlights why government of verges plumbia is so engaged in this basically bc and every other jurisdiction puts a ton of of Focus on physical identity cards and and the importance they provided in underpinning the economy and and Life in in a jurisdiction The world is moving online bc therefore is investing in figuring out the best ways to provide those same Services to make it safe for citizens to operate online for residents to operate online And I highlight it do need to protect data privacy and security and that's in particular why bc is so interested in non-credits We the the organization wants to to keep Trying to make it that the Approach use for verifiable credentials is as private and secure as possible With that we move on to the fun part The high school math edition Zero knowledge proof. So we're going to talk about we're going to jump back to your your high school math and talk about how cryptographic proofs work with zero knowledge Thanks to professor Kazusako who did the Data early versions of this the first time I saw this type of thing mike lauder from sovereign and now at In other organizations, but very involved in the and on credits community did a bunch of these and Actually, it was my daughter that did a lot of the slides and presentation and math parts of these that you're going to see so Kudos to those. So what is a zero knowledge proof? Here's the quote, you know a method one party can prove to another party that they know a value x and we're going to talk About x a lot in this Without conveying any information apart from the fact that they know that value Um, it's as mentioned, it's the proof It's the core of an on credits and that example that I give, you know, I'm older than 19 based on my date of birth and But without sharing my date of birth. So one of the approaches used to to do For instance age verification and this is proposed in the iso Mbl model and and and some of the things I've seen in in other places is oh, well, let's just put in You know a a field that says older than 19 older than 21 older than 25 And so that's another way to get around that particular use case and it is a super important use case With an on credits you actually put the date of birth in but the Holder does not share the date of birth They just share a proof that they are older than a given age requested by the verifier So that's what we're after Um, this is the interaction that happens We've got a holder prover that knows some piece of information and wants to prove it Without revealing the value likewise the verifier does not know x wants to know Wants to verify that the prover knows x Without learning about x itself. So both parties have a Want to participate in this so let's start with a nursery school edition. So this is an example of You know really getting simple with it. So You recall those who grew up in the age of where's Waldo? Or had kids that did Um Relished in the knowledge that they knew where Waldo was on any particular page in the book But they never wanted to let their friends know where they were because then their friends could claim they found it themselves So so what is so how can you do that prove that you know where Waldo is but not share where Waldo actually is so the way you can do that is make a sheet of paper that's four times the size of The page in the Waldo book Put a little hole in it And then move the page um the Waldo page around behind it such that Waldo appears Inside that little hole The person looking at it can see Waldo. They know that you know where Waldo is But they can't see where on the page the person where Waldo is So that's the simplest the the nursery school edition Um three requirements of zkp's completeness if the statement is true the honest verifier will be convinced that it's in fact Uh, it is known by the honest prover Um soundness if the statement is false no cheating prover can convince the honest verifier That this is true except with some small probability and we're going to get to that in a bit probability involved in in zkp's And finally the zero knowledge component if the statement is true the verifier Learns nothing other than the fact that the statement is true. They don't actually Learn about the date of birth the the value underlying So keep those in mind complete completeness soundness and zero knowledge Uh attributes mentioned this a little earlier Zkps are actually probabilistic not deterministic You are not going to get a hundred percent um knowledge there you are going to get um Uh a probabilistic, but we're getting pretty darn close and you'll see that There's an element of randomness always in it which plays into how the zero knowledge proof is is provided And then we're going to talk about the different forms of zkps notably interactive zkps and not interactive zkps um foreshadowing a bit not interactive is better We'll see why that is Okay, high school math. Um, here's where we get to the refresher for high school math Um, we need to cover functions and inverse functions. So we'll talk about functions We'll talk about exponents and some of the rules of exponents because they come into play Very clearly in this um the modulo operator and prime numbers And basically these components That literally you covered probably in what what we in north america have is very 10 math very 11 math are All you need to know RSA the diffie helman diffie helman Algorithm shot 256 hash all of these cryptographic things are all based on these Four components of the matter So a function a function is equation For which any x can be plugged in and exactly one y comes out of the equation one one result comes out of the equation So simple one there f of x equals x plus two So if I put 25 in f of x is 27 if I put two in it's four and so on So all of these are examples of of functions And basically you have in these case one variable that you insert you do the calculation and you get your result out So easy stuff, you know that stuff Um, the inverse of function is where you reverse it. So you Given the output, how do you figure out what the input is? Uh, and and so you do the manipulations you probably remember doing those Oh, I can take the two over to the other side by by converting the plus sign into a minus sign so we remember that so x equals y minus two And we get the inverse function. So we've got our example of our original function. We can calculate the inverse function In these ones in these examples and all of these ones What you'll figure out is it's pretty easy to go from the original function to the inverse and back Those are all easy what we want for zkps is a function that is essentially impossible to invert So what we want is something that we cannot do the inverse for and that is A core feature a core requirement and in fact what a lot of the working cryptography is is to find We'll see not just the not just the functions, but the Or the The numbers the types of numbers that that contribute to making it impossible to invert those Functions inverse functions exponents so exponent refers the number of times is a number is multiplied by itself So two times two times two is two to the exponent three So again, we remember that x to the fifth We got that so exponents Pretty easy. You've seen those Regular life laws of exponents non exhaustive, but we've got a few that play are really important here x to the zero is one x to the one is x itself. You just drop the exponent off x times a gives you x to the a plus b This is we're going to use a bunch actually we're going to use all of these but So again the example expands out why that is true So you can see that Two to the third times two to the second is actually two to the fifth so adding the exponents together and finally x to the a To the b is x a times b So again, you can do the same sort of expansion out and see that that's true. So good. We got exponents covered This is faster than you did it in high school. I suspect Modular operator, this is a modular operator gives the remainder after division. So it's Done the same way as division, but the answer rather than being, you know, how many times this This five go into 17 Rather we care about the remainder And so that's what you see here 17 mod five gives two And those of you with a calculator handy or quick with math 321 mod 17 equals 15 A lot of people like to think of this as the clock ticks I I'm not so good on this one, but I put it up there because many people relate to it But basically you count the ticks around and what you stop at is the modulo 12 of a number. So 27 you go around twice to 12 you come back all the way to the three that that's the modulo of it So there you go. That's the way to think of the modulo prime numbers last one Pretty easy a number divisible only by itself and one so infinite number of these Basically Prime numbers are pretty important in cryptography and again that that's comes back to the need for these things to to make that inversion of the function so We're going to come back to it, but we're going to start again with another example That's commonly used and and quite a good one Alibaba's cave and we're going to show that How a zkp is interactive And probabilistic so that's where these two concepts come into play with with this So alibaba's cave Bob's the verifier alice is the prover because of course we can't have anything in this community without alice and bob being involved In the cave There's two paths through the cave a and b and there's a magic door between them. So um Alice is claiming to bob that she knows the code to open the magic door And she's going to prove to bob that she knows that but she doesn't want bob to know that code She just wants to have it her as her own secret. She's not allowed to tell bob that So the way bob and alice figure out to uh determine whether she knows it Is bob stands outside the cave alice goes in and then as she goes in she picks either a or b to go down So in this case she picked a And then bob Bob does not know which path alice took bob stands there and says hey Alice come out one of the sides. Hey come out a and so alice Goes out a and that was easy because she didn't even have to use her code She just came out a because she picked the same one bob picked so bob Now has some evidence that alice knows the code because if she went in b She would have had to use the code, but you know, she could have gone in a so bob really doesn't believe alice yet um, so Let's do it again Alice goes in again bob goes in again This time bob says oh come out b thinking alice is going to pick the same way in Um, alice can of course go in a since alice knows the code Um, she uses the code goes through the magic door and comes outside b and bob goes twice that worked and now The way you get it is the interactive part. Um, we've got probabilistic um We've got randomness going in alice randomly picks a or b We've got randomness from bob bob's randomly picking a or b to come out Um, and and we've got interaction. Um, we're having it repeated over and over And every time alice is coming out the wrong side the right side And bob now thinks well, there's no way alice can be reading my mind in no which way i'm going to guess So um, I i'm getting pretty convinced as I do this, you know 10 20 30 times that Probably alice knows it So again, this is the probabilistic nature bob doesn't know absolutely deterministically for sure alice knows the code It's just extremely unlikely that she would have guessed the same thing that he that he um suggested every time So ali bob is k completeness if alice honestly knows the secret code bob will eventually be convinced she knows the code Hi probabilistic And and that's done through repetition interaction If alice does not know the secret code is highly unlikely through repetition that she would be able to convince bob she knows it Um, if ever the chance came that she went the wrong one for what bob convinced She can't come out the the correct side of the cave She knows it and of course zero knowledge bob didn't learn the secret code So now we switch to math now we go over to to Using those four elements of high school math and and we figure out ali bob is cave So the first thing we do is we need a one-way function One where the inverse is essentially impossible. So coming back to that If you know x it's easy to find f of x if you know f of x It's pretty much impossible to go backwards and find x And this function right here is the one that's commonly that is used for zero knowledge proofs So g g is some public and known value G is known by alice and bob Um x of course is the number we're trying to figure out and then we do modulo p on it where again p is public and known value And it's a prime so Alice and bob share g and p um only alice knows x And we're going to use this for bob to know that um alice knows uh That that bob can determine that alice really knows x So summary of steps bob and alice agree on g and p Alice knows x and so alice tells bob f of x and again confident that Knowing f of x does not allow bob to determine x Um alice generates a random number r so alice picks one This is the equivalent to alice entering the cave and randomly choosing a or b Alice generates a random number and calculates f of r and shares it with bob bob randomly sends alice a A constant c Which is either zero or one in this first case and again, this is the equivalent of valley bob is k That's bob saying come out a or come out b um alice defines a new variable r Plus x times c so alice knows all of these items So alice knows v because she knows all of these things And then she shares v of f uh V sorry f of v um with bob again bob can't determine v bob verifies the results by checking that f of r given by alice f of x given by alice To the c which bob chose himself equals the f of v that alice shared And if the two sides match alice passes So this is the key slide that says how it's done and this is the the manipulation that goes on with the exponents basically f of r times f of x times c equals f of uh f of v that's what we said we needed to check so let's go down this side f of r expands to um this f of x to the c expands to this Then we use our um rules of an x exponentiation G of x to the c is g to the x times c And then multiplying that by g to the r is adding to it. So we get r plus x times c mod p and um And that's our results on this side f of v is g to the v mod p And recall that v was calculated by alice as r plus x times c And here here we get these matching The mod p is is a um Factor that just moves out. It's a common factor. Therefore, we can move it out and and um have it separated from the rest of the calculations of g And as a result of that We get This way that alice only alice knows x out only alice knows r um and yet bob can be confident that um uh alice knows uh is acutely representing those values So here's some numbers on it. We're going to use really small numbers Um x is four in this case. Don't tell anyone only alice knows that Um g we're going to use is five. This is public 17 is the prime number. So g is our constant p is our our prime number um f of x therefore is 13 you can do the math on that uh r this random number that alice picks um is seven again Only alice knows that not bob f of r is 10 bob then declares either a zero or a one randomly. He chooses it tells that to alice and then v is calculated um only alice knows it again because it's V is dependent on x and r and only she knows it She does that calculation and then sends um uh Does that calculation and so she can then do f of v Here's the actual math for it. We get um case one of c equals zero And we get v equals seven And we get um g to the v mod p is 10 Um bob verifies that bob knows whoops f of r f of x to the c well if c is um a zero we know that uh Anything to the zero is one So we wind up this being 10 to the mod 17, which is of course 10 and we get verification that these two alice passed few case one Case two here's here's where we use one the only difference here being 13 to the 1th is 13. So this is 10 times 13 mod 17 And if you do the math, you'll find that's 11 alice passes in either case Now we have to repeat this process where we use a different r A different c over and over and over again interactively Um on the first pass there's a probability of a half of giving the correct value because she knows bob's going to Send either a c zero or a c one so she can figure out what it is um If they do this 20 times it's a one in a million chance that alice does not know x um Alice kept guessing the right thing that bob was going to send a c A zero or one and then and so there's a one in a million chance that that was sent up that was determined um, so that's that's pretty close to being accurate and only 20 times going through this um generalizing this Instead of c being zero or one We can see to choose a c in the range of zero to p minus one remember p p is our prime number That we're using so this is the equivalent of adding many paths to alibaba's cave Alice has to choose which one of many alice or bob says come back One of many and this reduces the number of iterations necessary to prove it so basically if you have um from professor sakos um presentation Um, she basically explained it as basically each bit in c is an instance of a zero or one iteration In other words if we can get c to be 20 bits of information We've got it down to a one in a million chance that um, alice guessed correctly and and produced the right zero knowledge proof or the the right value to send to um to Bob But even if we get it down to one Back and forth. It's still an interactive process alice and bob are still going back and forth We want to get um down to a simple request response process Bob makes a request alice sends a proof bob verifies it. So how do we eliminate that extra step where um, alice Bob has to send that extra value c And that's um one more piece of it Which is figuring out how to do non non interactive z k p. So we've got interactive We don't want to use repetition to reduce probability. We want to get down to a single back and forth The way that's done is a hash function h again a hash function non invertible one With a random number i Alice has used that to define c as f of r comma i And and using that function that bob bob shared so Bob and alice both know h to the function was um Bob provides as part of his request i And alice knows makes up r alice just creates it because r is a random number that alice chooses Bob still knows c bob can calculate c Once once f of r is known And so it's a shared secret between them a shared value between them bob and alice both know it And it is sufficiently random Um i is used as to prevent replay attacks. So those familiar um with Was cryptography and zero knowledge proofs and and verify the credentials know about replay attacks with basically um alice and bob alice requests a proof from uh bob requests a proof from alice Alice prepares and sends that proof along the way some outsider mallory We often talk about mallory malicious mallory mallory listens in and records of the proof that um alice sent to bob later bob asks mallory for a proof and Mallory replays the recorded proof from alice and claims it to be their own and bob can verify the proof so doesn't know But by using a different eye on every time a request is sent out The proof that is received is different every time and as a result even if mallory hears alice's proof Mallory can't play it back and pretend it's their own because the eyes The eye the random factor that what's called the nonce is different And that prevents a replay attack So almost at the end Oops There we go in real life. Um, this is what number p looks like in um a an on cred's situation He is a little larger than the 17 that we chose in our example. It's quite a large number and that is a decimal number Um, c is between one and p minus one. So given p Um from the previous slide c is between one and this number. Remember that when we talked about c um c is a each bit of c represents um a piece of entropy So we said that you know 20 bits of of of it would allow a one in a million chance that alice Um, luckily selected. Well, there's a whole lot more than 20 bits of information in this large decimal number so a whole lot more likelihood um that c is Is is going to give enough that that probable probability is extraordinarily low that alice could pick it And then in in real life, this is what g looks like again another big and big big huge number um So that's that completes The coverage of the high school math part And i'm just at the end of time. So that works of this session. So it works out well Zkps as I mentioned, there's there's basically four commonly used I go over a couple of them here Blinding and identifier of the holder. This is the um holder binding that ability that I talked about that is sort of outside of the w3c spec of how that gets done But in an on creds, it's very formally defined and it's always the same basically The holder has a link secret um a a big number Um a blinded version is put into the verifiable credential the holder proves to the verifier They know the link secret, but they don't actually reveal it And then secondly they prove that the same link secret is used with all the presented credentials Um blinding the data values for selective disclosure is the same sort of thing in this case the issuer signs encoded versions of the data and I don't know where I mentioned this but Notice that everything I did x is a number x is always a number in zero knowledge proofs So as a result if you want to do something with data involved in zero knowledge proofs You have to encode that data as a number and so an on creds has a encoding scheme that converts all of the attributes all of the data elements into numbers um, and so it's actually Uh in an on creds it actually it is the encoded value that gets signed not the actual data So issuer signs the encoded versions of the data the numbers representing the data the holder blinds the signatures in present in presenting those The holder proves to the verifier. It knows the signature without revealing the signatures And then the holder reveals the raw data values of the attributes and the verifier verifies they could Inform they correspond to the signed values. So that's how um Selective disclosure works and a little bit on how these signatures are blinded in an on creds um, there's similar um capabilities in predicates similar in revocation, but I just Didn't think it was worth going through all the details of those Um pile of references for you. Um This was based on uh, you know, I went to this iiw 26 presentation by Professor Sacco and it was outstanding. Um, this is a little more formal than she did There's notes on the on on her presentation She actually got asked to do a second instance of it. So there's notes, but Not kind of the presentation and the math. So that's this is helpful Mike lauder did a presentation. Um, when he's with the sovereign foundation, um, that's linked here, which is About 160 odd slides that includes detailed math of this Little yeah, okay a lot more advanced than the high school map But if you're interested in seeing all of the steps involved in this That's a good presentation for that here's some other posts about cl signatures, which is the The academic paper upon which all of this is involved Um, yon and and I did that. Um Um And then some other interesting papers. Oh, David chom 1998 paper on blinded signatures just to show you that this is not brand new stuff This was the sort of basis upon which ck z cash came about and A bunch of the papers on blinded signatures. So lots of lots of things to look at. They are absolutely. I'll be sharing the presentation um Why do they matter ck p's? Um, no shared new identifier to present for governments. This is huge Not sharing creating the ssn or the social insurance number the social Those identifiers are are subject to legislation and so on creating new ones is difficult um also the unlinkability Minimize sharing and again unlinkability fighting back against online Tracking at my time. So I better stop Some other things in here, but um and a call to action get involved in this Feel free to reach out to me if you're interested and want to get involved want to learn more Welcome to do so and with that I'll stop sharing and turn it over because we're at time Thank you so much Steven. That was a fantastic presentation. Super interesting We covered a lot. So thank you. Um, I think one of the questions is if if the if people can access the slides after Yeah great, um Sounds good. I can post those as well on the meeting page. So if you go to um This page in a moment I will upload the slides there. So Great. Yeah, thank you so much Steven and thanks everyone for joining in with your working group updates and we'll see you all in two weeks Thanks. Thank you. Thank you


And the keys in these markets, there's always gonna be a leader. There's always gonna be the head of the state. There's gonna be one stock. One stock that everyone is focused on, which is HKD at this current market when we're recording this right now is HKD. When HKD is taking all the attention, TD, what do you think all these stocks are doing? All the money is going into the hot stock and all the money is selling out of the old stocks. What ends up happening is, let's say I'm long. Okay, I'm gonna give you an example. Let's get HKDs running. It's going to $800, $900, and I'm long. AMTD.   I'm gonna sell AMTD to free up buying power to buy HKD. And then that happens on a massive scale, which is the money flow concept that we talk about. Money flows out of one stock and into the other stock usually based on FOMO, right?


Do you see like decon flies along the wall of black dots?  Yeah, they're all on the captain. Oh wow, that's gross. I guess we guys can see these are all dead. We already sprayed Pade, but it's so good that's why it looks like that.  Is what those are? Maggot what? Cocoon. Oh, cocoon. It looks like, if you don't know Pada, it looks like rota dropping it, but it's not. This is a B5.