Welcome to wasm plus kubernetes beyond containers. We're going to talk a little bit about how we can kind of leverage some of these technologies together To build a working solution to build web assembly services on the back end that are real and running Uh and solve some business problems along the way. My name is sean isam I am a senior manager at adobe working on optimizing our cloud infrastructure and this is callen Collin's also a senior engineer at adobe working on some of our Uh new web assembly based stack. Yeah Web services. Yes Okay, so I always like to start with a quote or a thesis statement. Um, here's a somewhat provocative one People don't really want innovation. This is a quote from justin eathridge People talk about innovation a whole lot But what they are really usually looking for is cheap wins in novelty If you truly innovate and change the way that people have to do things expect mostly negative feedback If you believe in what you're doing and know it will really improve things then brace yourself for a long battle Show of hands in the room. Who can who can empathize with this in this room? I'm sure we've all been here with uh technologies before So, you know, I think you know still want to keep this to be a very positive talk But a lot of this is going to be some of the lessons we've learned along the way getting into the state We're in today where we can kind of get some of these technologies in our operating Wasm is the tool I personally believe it is the tool to write better software faster But innovating is is hard, especially in a large enterprise organization Uh, so we'll just talk briefly, you know, I'm going to start with a little bit of history I don't want to bore you too much with some of our background on kubernetes This is wasm day not kubernetes day right now But uh understand a little bit of the history, you know, some of our current setup How we're thinking about this some of the business problems we're going to solve Collins going to have a pretty awesome demo of some of the stuff working in production Uh, and then you know, summarizing why we think this is worth it History so all right, so what do we mean when we mean running things in the cloud? Obviously a lot of us probably remember pre container days VM backed services These are the the the dark days Before containers magically fixed everything for us There's a group at adobe as a startup that they actually acquired called behance That was really focused on solving a couple of different problems. First was cicd This is something that other people can probably empathize as well But build knights right trying to move all that code out to production Trying to get all these systems working together. That's a challenging task. And so You know kind of standardizing around this is early late 2014 early 2015 standardizing around a cicd framework That could be used to help automate and solve some of those pain points And then deploying apache mesos to run containers First as like system d units. I don't know if anyone remembers those days But uh, you know, that's uh, you know, that was kind of the leading way I'd say but this is a little bit for I think ecs was even released. So this this is the the bad old days of containers Why why did we do this right? So if you think about a developer, this is a developer But again, a lot of you can probably empathize with this as well Um, what are the things that a developer has to think about? There's a lot of different things and that landscape is changing all over the time with technologies And you know, really like this causes problems when you're trying to do things in a large organization Do you want, you know, 20 30 50 100 different teams different orgs different geos reinventing the wheel all over time? I don't think so and so thus in 2015 ethos was born late Yeah late 2015 early 2016 and so the idea behind the ethos project was can we run multi tenant web services at adobe? Like can we magically get all these different service teams inter operating putting their stuff together? Containers was the tool of choice based off of mesos based off our ccd framework And you know kind of automatically scale, you know Get those get the cost efficiency from the economies of scale of running those together so You know running mesos manually is hard. We standardized around dc dc us 2017 migrated everything over to that You know dc us was a great platform for us for for many years But there's a lot of things we had to build ourselves that did not come out of the box And you know, obviously you see the direction the community has gone. So sorry late 2018 Early 2019 we started building around retooling the entire platform around kubernetes When we think about web services, there's kind of three different models that exist in kubernetes. There's ethos cas which container as a service and this is kind of where we took that paved path for And we replicated that experience in kubernetes, but obviously infrastructure is code with you know, the vast amount of kubernetes experience that the community has We built this new pass base system too where you can provision namespace on a cluster and you know Get some basic network policies and get right access in that namespace and hook up your own cicd tool Or do whatever you want to pull your own infrastructure in there And then fairly new is using argon helm product called flex Which is how we can kind of get the best of both worlds Where we can give you a cicd suite that actually give you right access as well so you can create your own cloud native resources Ethos is a huge project powers. I would say at this point most of adobe's web services Over 5,000 production services lots of containers lots of cpus This is kind of interesting because it's going to be a central theme of this talk is this concept of multi tenancy Right and so you talk to a lot of other large companies. You know, there's 500 clusters a thousand clusters There's an infinite number of kubernetes clusters that are running. This has scaled up a lot in the last You know year or so I would say like we this account was under 100 for a while because of our multi tenancy That has scaled out, but we're still at 285 clusters running, you know those kinds of statistics. So I think that's pretty notable We're so along that journey. Where has that gotten us today? I'd say our kubernetes has been very successful given those numbers We still have you know, kind of that unified s re operations model We have a security model that other teams would have to onboard to by default We are still mostly a 12 factor app based system mostly a multi tenant system As that cluster account has gotten larger. I would say that over time we have You know pivoted a little a little bit away from that You know for specific larger workloads But the idea is that you know, we can provide this basic platform for hosting services We can be cloud agnostic. We can be platform agnostic. We can run containers as a service We can run I mean streaming workloads anything you can name and essentially provide this infrastructure as a service With an additional set of value add components on top of it Okay, so again, this is wasm day. Let's start talking about what wasm can do for us So as we look to how multi tenancy works in kubernetes today Is operationally very simple allows us to get you know economies of scale with our people with our cluster operations This promise of you know, just make everything multi-tenant. You've got large applications You've got small applications. They're just going to fill up all the space automatically and get rid of all of your overhead That's not really the case. It's very efficient in theory But you know when you start mixing applications different architectures different scheduling constraints different taints and tolerations different zone affinities You know minimum replica counts that are more than the nodes in the cluster You can imagine how over time things scale out and things the efficiency level drops So, you know, I'm not here to convince you that you should get rid of kubernetes Obviously a lot of people are running kubernetes But when you run this kind of multi-tenant setup while it's operationally very excellent It can be very expensive to run and so when we're looking at what's next and for for us today That's why the assembly You know, we want to be able to leverage our existing investment kubernetes We've got a lot of it We know how to work with it. We've got all these different other resources that you know These hundreds to thousands of teams within adobe have built for these thousands to tens of thousands of services that are already operating in kubernetes So we need a model where we can still leverage that investment beat but be able to integrate in What's new so kind of the question is What if there's a better way? Can we make some of these things work together using web assembly and so You know how i'm personally thinking about this is a model more towards fast. I would not say pure fast, but Actually, let's go to the next slide There's a lot of services that are running on our platform that look kind of like this, you know, we It's a like it's a multi-tenant platform lots of different types of services But the standard service if I was to define what a service looks like it's probably written in java spring brute Using a lot of internal libraries They will pull some utilization statistics about 28 cp utilization about 55 ram utilization So that's good, but not great, right? And so what that really means is that like we've got a large java service that's serving web traffic And it's going to take incoming requests and crunch some numbers on them And then maybe like fire off a call to an external dependency pull some data from a database Wait for that other external dependency to do something and then you know With that transform data send it back to the user maybe you know asynchronously go store that You know send that to another service stored in another data system And it's kind of like data processing flow I would say is is a very standard workflow that's replicated across Hundreds if not thousands of services and so if you look at a compute profile of those services, right? Like we're as strong as our weakest link which for this one I might have pulled the wrong example, but uh the idea often that is cpu, right? Or memory bound or iops bound we've got some other constraining component and there's just idling cpu there That we would like to be able to do something with So, uh How could web assembly be the answer to this then? Let's give a bit of background on how web assembly at adobe has historically worked We have a lot of experience with this on the browser side and actually predating web assembly If anybody remembers portable native client from google Asm.js, you know kind of predecessors of web assembly These are all things that have been integrated into adobe products over the last 10 years starting with the lightroom web beta All the way at the production version acrobat web Moving towards the you know our flagship experience of photoshop Which has been running in beta and browser for almost a year now In some next generation products where wasm is really a key enabler in allowing us to to build that rich client experience In a web browser So we have all this experience working with web assembly code already mostly, you know Taking native code mostly interoperating interoperating with javascript But uh, it's something that that you know We have the experience to leverage in other places because it meets all these same requirements that we're looking for the back end It's a very high-performance system. It is uh secure by default for example, right? We don't have to worry about multi-tenant isolation So This is the experiment. How do we actually run this in kubernetes? And so we're utilizing wasm cloud right now You see on the left here. This is kind of a legacy setup. I would say This is uh, and there's some links there and you know, I'll send out the slides and everything But if you take the cosmonic kubernetes applier, this is a script that allows you to kind of bootstrap a wasm cloud installation within a cluster We started by doing this within a namespace and so this is within the context of a client application and that's important because Namespaces are isolated from each other right like when a client service on boards to our system when we run a multi-tenant system If they need to vpc appear back to one of their own cloud resources They get a netpall that allows their namespace and only their namespace to talk to that inside a multi-tenant cluster And so this was a nice way of kind of like keeping that, you know namespace boundary isolation for external resources Um, but as you can imagine this probably didn't hit our efficiency goals as much as we would like because we're replicating that core Wasm cloud infrastructure for every single app that needs to work this way And so what we're moving towards is this more multi-tenant model This is utilizing some very hot off the press scripts Some coming out of the wasm io workshop that the cosmonic folks did But essentially the idea here, which is this diagram on the right is that within the namespace boundary, which is are these blue boxes We've got uh, you know, we've got the automation and provision services allow us to get ingress to talk to a web assembly module We've got uh wasm cloud providers running the back end these can be like htp providers that are serving this htp traffic and then They communicate through gnats, you know over this lattice this green box back to a pool of common wasm cloud hosts And so with that we have core compute capacity that's per visit to just do work and do work in a fass kind of way And so we uh, it's very efficient We can run all of these different workloads side by side because they're secure by default We can run the actual Execution of that code outside of the namespace boundary and then just communicating back and forth back up to providers that are running in namespace You know using a gnats topic Which is secured by default as well In order to then communicate with those external dependencies So with this it's it's kind of you know the best of both worlds If there is a best of both worlds to be had between kubernetes and web assembly because We can have other things that are still running in that namespace that we need to talk to you that we can access We can talk to all these external providers But we're still able to drive down that CPU cost by those greater economies of scale by actually isolating out the core client compute not having those services Just spending all of their time idling Um a lot of this is going to involve getting code working For web assembly in the first place and taking a service and building it for web assembly So call in has a awesome amount of experience and demo here that he's going to show you Thanks, Sean So, um, yeah, I I have to preface this whole thing because I didn't do it this last time I for you who are in valency remember you might remember I gave a talk last year So i'm going to preface this with i'm going to read it okay, um My goal is not to make any sort of criticism or indictment of decisions that have been made This technology has a very bright future. Everyone involved should be very proud of what they've accomplished Um, i'm just trying to highlight the work that still needs to be done Um in the next phase of focusing on developer experience. Okay, so Afterwards, okay, if uh, I don't mean to offend So this is you know, we've already hit a lot of these highlights. This is this bailey This is from her youtube video with luke wagner So a lot of work great work's been done and uh, and it's really it's really great. It's been great to witness um so Last year it was background removal. It was a really simple service. I think the hardest part for me was Taking a spring boot app and learning rust So that was that was the hardest part there It just worked really flawlessly and the the reason was that it had very few dependencies. So I would I could take a signature and I would I could Remove the background and I think I ran it on maybe fastly and cloud flare was in cloud and fermion spin worked great This year Is the content authenticity proxy? so Here we have the the holy father balenciaga So right this is a very timely thing and adobe's really made a big investment in ai generation Um, so this kind of thing. So is this a real image? Was it was it ai generated? Was it modified in photoshop that kind of thing? Okay, so it sounds simple right i'm gonna i mean i have a proxy This is meant to be running kind of on the on the edge Close to the users so cdn edge think of that kind of thing Um, what we call cdn edge compute right? User will pass a url to the service the service will download it Check it. Uh, it will resize the image now. There's a cache. Maybe it's been cached Transcode it so make make resize it Record that in the content authenticity manifest This is something adobe's been working on the content authenticity initiative That's a embedded data in an image on the history of that image and then Return the image and Push the transcoded image into cache Okay, so as i said before last year worked really well because the only the only crate that was a dependency really was image And this year very different. Okay, so Fast image resize because this is supposed to be fast that needs sim sim d And the fast image resize crate before i started did not support wasm sim wasm. So there's some sim d work Um, the c2 pa sdk needed to work with web assembly wazzy specifically Uh, oh which required open the ssl xo x 509 ring and chrono. So, uh, I did what any Uh Full hardy developer did I forked everything? Um, so and the the worst part was when I when I came to the content authenticity initiative team they said, um Uh, oh it already supports wasm right of course it it doesn't support wasm It supports wasm in the browser right and that's kind of the problem is the wasm 32 unknown unknown target Which I used last year for background removal Wasn't going to work because it was going to pick up wasm bind gen and j s s and so I had to Go through the cargo gut toml and everywhere That required any of these crates in the code and do lots of little configs. So, you know As you can see, um, so that was that was a that was a real challenge And actually so I actually did get it all to compile but the open ssl Not quite there yet. So it actually kind of fell down, but this actually this this highlights um Kind of a positive thing is that I I got it working in wasm cloud because I moved that open ssl into a provider So once open ssl is ready for um for wazi Uh, it can go into the into the web assembly boundary um Okay, so the simd which is kind of the successful part. So I led I I lowered your expectations and now here's the actual success so um This was what the real challenge here was getting wazi simd to actually be faster than wazi Or sorry web assembly not simd, right? So, uh, and this is kind of a bigger point Which is web assembly would not be possible or if it was it would be much more complicated If cpu architectures were not so homogenized, right? Um back maybe back 20 years ago when we still had big endian mips or power pc This would be a different story, right if we had to compile something and maybe it'll run big end And maybe to run little endian or or you know take anything else, right? There's a real uniformity now in cpu architecture um But the problem is simd very very, uh You know simd instructions vary greatly between neon and ssc4 and avx 512, right? So Uh, this is the list I took it from the inscription docs Um And uh, I had to avoid these and of course I didn't have to avoid them in my actual code I had to avoid them in the optimized code, right? So here I have The most efficient way to write something And that was 10 times slower than the fastest way to do it Which is five commit five instructions versus 12 instructions So I'm pulling out watt and I'm making sure I'm not getting these very slow shift left shift right Commands, right? And and those are slow not just on x86. They're also slow on neon on arm So that was uh, that was very challenging um And so I think we you know, we've really pounded this today What goes in the wazam box what doesn't go in the wazam box? And I think there's some debate on this kind of thing um You know we I think hopefully you've been convinced if you were on the fence that there's an advantage Things in web assembly today You know so we want things to go in there We just if we want to be performant We don't not everything can kind of go there so What what I would kind of like would be cryptography in web assembly because you know open ssl should work on a very variety of architectures and os's Simdi maybe not so I kind of what in my example I actually kind of Swap these Like I would prefer it was the other way but in my example simdi's inside the wazam box and cryptography's outside Although cryptography the um the simdi instructions were ended up being four times faster So it was you know, it wasn't a complete waste of time Um, okay. So demo time. All right. Here we go Let's see Okay, so it's Nope Yeah, okay, this is good Sorry This is always terrifying So here we've got adobe firefly And I was like what's a good image because it doesn't understand web assembly firefly, you know, not in the model Web assembly for the firefly am I am a training data? But I was like well crabs and gophers and amsterdam, right? So made some images. I picked one of them And then I put it I put it somewhere I put it in github. I tried s3. It didn't work. I don't know why And uh, it was very slow and so then um here so I Here so this is kind of the output of the of the wazam cloud and i'm just gonna so i'm not going to refresh that Uh, but I will curl my way and see if we can get it Uh Okay, so yeah, it worked. Okay, and then uh If we do cpa tool, so so that's what it did it it grabbed the image it transcoded it and updated its c2pa manifest um I can't type up here when I'm uh, sorry. It's true. You really can't type A tool what is going on Sorry, uh, I'll see if I can hold on See oh c2pa tool Hey, there we go. Wow Um transcode so just seeing here. We've got the transcoding action that was done by the wazam cloud um Service so so that is the demo and the whole idea is this is actually going to hopefully run Um on edge compute and maybe in wazam cloud or if we can get that in multiple places Uh, yeah, so that's that's the demo um See if we can get back to power point All right handing it back over to shawn. Oh, sorry. Actually. Sorry. I have some notes. Um We do use web assembly on the server side a lot at adobe But it runs in headless chrome in fact and including in the projects i'm working on around Uh newer web services around creative cloud. Um, so We have to at least match what we have in the browser for web assembly with wazi Or else it's going to be really hard to convince these people who already think they know web assembly to move over to wazi So That's it. That's that's it and that's not a criticism. Okay. Thanks I don't really have much I don't really have much more to add but uh, basically I just want to summarize, you know So like this whole journey we've been on so we've gone to cloud native. We run kubernetes We run kubernetes fairly well. We've got some business problems. We want to try to solve Web assembly is a tool that helps us write better software faster But you know as we've seen, you know, both on the how we run it Although that experience is improving how we write it what the developer experience looks like like this is hard How do you convince, you know thousands of java developers that are used to writing code? You know that is like dm base that we've wrapped a docker container around that we've put up in the cloud, right? Like that's the model How do we convince people essentially to get that back to a model where it's like We want to free you from those infrastructure concerns We want you to be able to write the software once and run it anywhere And so, um, you know, I think we're on that journey I think we're in kind of like, you know the technology adoption curve We're in the like, you know storming phase of this right now trying to get all of this going but This is worth it, right? It's worth it for the efficiency. It's worth it for the performance It will be worth it for the developer experience Wasm isn't the enabler of all these things, but we just also, you know, like we're not going to stop running kubernetes tomorrow So, uh, I envision a world where these coexist Far into the future and I appreciate all the work that everyone in the community has been doing to make All these things reality That's it. Thank you absolute Hello, absolutely fantastic. Um, definitely love to see and these are really challenging problems So it's cool to see like how y'all actually tackling them. I know y'all have questions So please, uh, if you have a question raise your hand so I can come give you the mic Making my way back here. Just give me a moment If you could please introduce yourself So larry carvalho with robust cloud, um, you know, we had the days of cloud first that we went container first If we are going to wasm first and you said, you know developers There's still some more time before it becomes easy for developers. What is stopping? Uh, the the way to make wasm easier for developers to use Yeah, so so great. So so the point isn't that I mean, um, the it's just we have to get the language supports, right? Um, we we can't have every developer forking major, you know Rust libraries or and let alone rust because rust is the best The best supported language, right? Um, so, you know, when do you get down to python or or, uh You know, our other language is that we you know, we have to have a good story We can't have them say yeah, you can use python, but you can only you know go within the the main packages, right? So yeah I'd also throw out just like core core library support, right and and sorting out dependencies and dependency trees and dependencies of dependencies There's a talk I can't remember which one is but like if anyone's ever seen a dependency graph of like a real microservice It's it looks like a firecrackers. It's an explosion, right? So like all it takes is one thing not working in wasm to blow that whole thing up Um, the provider model where you can, you know, basically go out to native code communicate and distribute systems fashion helps Don't get me wrong. But also like we need more things running in wasm natively Any other questions? All right, then give it up again. Thank you so much


HBO Max recently teamed with DC to release a Raised by Wolves tie-in comic. In this video, I'll recap the events from that comic and what it taught us about the world of Raised by Wolves. Quick note, this video contains spoilers through Episode 9 of Raised by Wolves. This story takes place during Episode 1 before any of the Generation 1 children died. On Kepler-22b, Mother tells her children of a planet called Earth. She tells them how humans could not find a peaceful way to resolve their differences. She explains, An argument can never be resolved if one of the parties refuses to see reality for what it is. And so, there was war. Decades earlier on Earth, the year is 2120, or 25 years prior to the Ark's departure. An announcement is made in the Mithraic capital. Sol has shown the Mithraic that the fifth force of nature is real. It is now time to use that power to purge the evil of non-believers. Their leader announces, My brothers and sisters, I give you the Necromancer, Hail Sol! Elsewhere, atheist soldiers notice a woman floating in the sky. Then they burst in an explosion of blood. Back on Kepler-22b, present day, Mother finishes her story. She tells the children that believers claim the technical specs for Necromancers were found in ancient scripture. On the other hand, she believes it was more likely stolen from an atheist nation. The atheists blanketed the world with bombs in an effort to stop the Necromancers.  Which appears to be a risk on Kepler-22b as well. The children play with small stick Necromancers they created. Some of which they have lit on fire, which catches some of the crops. Later, Mother and Father discuss a plan to incentivize the children toward better behavior. Mother points out that this is difficult because the children know Mother and Father are programmed to nurture humans. They are incapable of doing the children harm. They decide to lie, as Mother suggests. What if we could convince them that Necromancers are attracted to bad behavior? Father replies, The children aren't afraid of Necromancers. They think they're exciting. However, Mother replies that if they teach the truth that Necromancers are built to torture and destroy, the children will be afraid. Campion is skeptical, but Mother and Father assure him the Necromancers are coming. When Campion claims he's too fast for a Necromancer to catch him, Mother reassures, It doesn't need to catch you, Campion. It need only raise its voice.  Campion is shocked. What do you mean? It can kill you with its voice? Yes, Mother replies. And with its stare too, don't ever look into their eyes. After Campion wakes from a Necromancer-fueled nightmare, so Mother calms him down by coming clean that the Necromancers will never leave what remains of Earth. Maybe they took their scare tactics too far. Finally, Mother hums the song, which always makes Campion sleepy. And that's where the issue ends. This short comic was titled, Hark the Herald Angel Sings, and it was written by Raised by Wolves showrunner Aaron Guzikowski, with art by Megan Hedrick. No release date has been announced, but there will be another issue bridging the gap between seasons one and two. Now that we've recapped the story, I just wanted to point out a few interesting bits of worldbuilding that came from the comic. First we get a glimpse of the Mithraic capital. We don't see a whole lot, but it definitely gives off the vibe of an empire. Further, we hear them refer to dark photon energy as the fifth force. In the real world, scientists have identified four basic forces of nature, gravitational, electromagnetic, strong and weak. However, scientists have observed anomalies that point to the existence of a fifth force. Some have theorized that it could relate to dark photons. So in the world of Raised by Wolves, it seems this force is eventually proven to exist. Next we get some further detail on how exactly the religious war destroyed Earth. It seems that in retaliation to the Necromancers, atheists essentially blanketed the world with bombs. This made Earth uninhabitable. I'm assuming this involved nuclear weapons, which certainly would have made parts of the planet unlivable. Mother also says that although the Mithraic claim the Necromancer designs came from Scripture, they were more likely stolen from an atheist nation. Personally, I subscribe to the theory that there is an advanced intelligence on Kepler 22B, which has meddled in human affairs on Earth. So although I'm skeptical that Necromancer designs came from ancient scriptures, I do think it's likely they were given to the Mithraic by some outside force. Finally, although we know that a Necromancer's scream and eyes can be dangerous, Mother's phrasing was interesting.   That phrasing just makes me curious, what else they can do to your brain? Further, I'm curious what their stare can do exactly. Thus far on the show, I believe that all the people Mother exploded were victims to her shouts. I'm curious what she can do with just her eyes. Anyway, I think we can wrap it up there. Let me know in the comments if you noticed anything else in this comic that I missed. And if you enjoyed this video, please go ahead and hit the like button, hit the subscribe button, and hit the bell icon for more videos like this one. Every time someone likes or subscribes, it's a big help to the channel and personally gets me that much more excited to do the next video, so I really appreciate it. And I'll make sure to cover the next issue whenever it gets released. With that, thanks for watching and see you on the next One Take.


Hi, I'm Fabrice Benavida, and I will be talking about Mr. List, multi-party, reusable, non-interactive, secure computation. This is a joint work with Rachel Lin. Let's start with the model. Let's suppose that you have four hospitals, H1, H2, H3, H4, with confidential databases of medical records, X1, X2, X3, and X1. And let's suppose that you have a rich art institute, which wants to conduct a public study, F, on this record of H1, H2, and H3. So by a public study F, I mean just a function F on the input X1, X2, and X3. Unfortunately, X1, X2, and X3 are confidential. So the hospital cannot just reveal them. Instead, what we would like is that the hospital can compute and publish some messages or computation encoding, alpha 1, alpha 2, alpha 3, such that from this computation encoding, anyone can compute the output of the function F on X1, X2, and X3. Importantly, this computation encoding should not leak anything more than F of X1, X2, X3. In particular, it should not allow anyone to learn any single medical record.  So there are many different research institutes who conduct many different studies with many different subsets of hospitals. And we would want to allow that to allow another study like F prime to also be conducted. And the process should be the same. So for example, this orange study is with the database of H1 and H4. And to be conducted, H1 and H4 can generate the computation encoding alpha prime 1 and alpha prime 4, and this computation encoding reveal F prime of X1 and X4. Remark that the computation encoding depends on the actual study. So the green alpha 1 is different from the orange alpha prime 1. In addition to that, we would like to allow a hospital to join the system at any point. For example, the hospital H5 can join, and then another research institution can conduct yet another study between for example H5 and H4. And that's the same process. But let's first focus on a single study, the green study with the hospital H1, H1, H4. And let's ask ourselves, can we even achieve this ideal goal? Unfortunately, in 94, Fajon-Kilian, and in 97, Isha and Kushelevit show that we cannot achieve this goal. That in any such non-interactive protocol, the residual function will be leaked. What do we mean by that? We mean that for example, suppose that hospital 1 is correct. What it can do is it can participate to the study normally, but then in its head, it can consider another input, another database X prime 1, derive the corresponding computation encoding alpha prime 1, and use the public computation encoding of hospital H2 and hospital H3. So the public computation encoding alpha 2 and alpha 3 to derive the output of the function F on X prime 1, X2 and X3. In other words, a corrupt hospital can compute F on X prime 1, X2, X3 for any X prime 1. This is completely insecure. And the issue intuitively is that the inputs of the hospitals or the parties are not committed. So to bypass this lower bound, something must give. And what we propose in our paper is to allow hospitals to make commitments. So concretely, H hospital HI will create a commitment X hat I and keep the associated secret state SI, secret state of randomness. Then they will publish their commitment. And now the big difference with B4 is that the computation encoding alpha I can depend on these commitments. So for example here, alpha 2 is a function of the study F, the secret state S2 of hospital H2. And most importantly, of the three commitments, X hat 1, X hat 2 and X hat 3. So now what happens is H1 is correct and try to use another database X prime 1 in its head. Then it will not be able to compute the output of the function F on this X prime 1, X2, X3 using alpha 2 and alpha 3 because alpha 2 is linked to the commitment X hat 1. Which commits to X1 and not X prime 1. So alpha 2 and alpha 3 cannot be used with X prime 1 and hence the previous attack can be avoided. But we still want to keep the flexibility we had before namely that any hospital can join at any time by just making a commitment, keeping the secret state, publishing the commitment. And now a new study can be conducted between for example, hospital one and this newcomer hospital four. Importantly what we want is that the computation and coding alpha prime one and alpha prime four only depends on the commitments of the parties involved in the study. So here X hat 1 and X hat 4. And they should not depend on the commitment X hat 2 and X hat 3 of the other party, hospital two and hospital three. Let's try to be a little bit more formal and define precisely what an MRNISC is. So an MRNISC is defined by three algorithms. The first one is input and coding or commitment. Come, it takes as input the input of the party, the database of medical record in our example before. X hat and output the commitment X hat I and the secret set as I. Then once the commitment of some parties are known, anybody can choose a subset S of these parties and ask them to compute a function F on their inputs. And to do that, the party will need to compute this computation and coding alpha I using this algorithm and code which take as input the function to be computed. The commitments of all the parties involved in the computation, but no other parties and the secret states of the party will consider. From all the public computation and coding alpha I, you can then evaluate the output of function using the further algorithm evaluated. This is completely public, there is no secret to perform this evaluation. Importantly, you should be able to perform this computation on any set of your choice and any function of your choice. You can use the same function on many different sets of parties or you can use many different functions on the same set of parties, everything is allowed. And we want to achieve correctness even with dynamic party joining. And despite all of this, we still want to achieve a strong notion of security namely simulation security. And in details, we consider semi-unless adversary but we actually can consider slightly strong adversary. Static corruption and dizziness majority which means that even if all but one parties are corrupt then we still ensure security for the non-corrupt party. Another way to look at our MRNISC is to look at them as a two-round MPC with two extra properties. Okay, look at it this way. In round one, the parties would just broadcast their commitments, XI, I. And in round two, on input some function F, the party would broadcast the computation encodings alpha I and then they can compute the output of the function F on their inputs from all these computation encodings. Importantly, we have these two extra properties. The first one is reusable first round. It should be possible to compute many different functions on the inputs by just doing again the second round. The first round being completely fixed. In addition to that, we want the set of parties involved in the computation to be dynamic. For example, you may want to compute a function F on the inputs of the party one, two and five and this computation should only require parties one, two and five to broadcast the computation encoding and the other party should not need to do anything. And then you may want to do a computational function F prime on the inputs of the party three and four and then only the parties three and four need to participate in this computation, need to send their own two message for this computation. This is a dynamic set of party proper. So this relation with two round MPC leads us to think that maybe we can just use existing two round MPC protocol and tweak them a little to get a more nice. So let's look at existing two round MPC. So there are essentially five main lines of work and I apologize if I'm missing some citation here, but essentially here are the lines of work. The first one is the one based on multi key FHC by Asharoff et al in 2012. So this line of work is MPC, two round MPC from LWE, which is a very standard assumption. The issue is that it requires a setup. And in our mRNAs, we would like to avoid setup to really allow as much flexibility as possible. And the second caveat is that we don't know to make it reusable and to have a dynamic set of parties because the notion of security that multi key FHC achieve looks a little too weak. Second line of work, homomorphic secret sharing. Homomorphic secret sharing is an amazing primitive introduced by Boyle Gilbois Isha in 2016. And it has many applications, in particular it allows to construct two round MPC. Unfortunately, it also requires a setup in that setting. Furthermore, it seems very hard to achieve a dynamic set of parties with homomorphic secret sharing because as the name indicates, some secret is shared between the parties. And if a new party is joining the system, somehow this secret need to be reshared with this new party. And most likely we will need interaction for that purpose. The good thing is that homomorphic secret sharing based two round MPC is based on very standard assumption to give you. The next line of work is obfuscation based two round MPC. Introduced by Garth Gentry, Alevi and Reikova in 2014. The advantage of this construction is that it requires no setup. And with little tweaks, it can be made reusable and support a dynamic set of parties. The big drawback is that it uses IO indistinguishable obfuscation, which is a very complex primitive. So in 2015, Gordon, you and she showed that you can replace IO by witness encryption, which is a seemingly weaker primitive. And you still keep the reusability and dynamic set of parties properties. Unfortunately, witness encryption is still a very, very complex primitive. So 2017 and 2018, Garth Gentry-Nivasan and Rachel and I showed that we can instantiate the GLS-15 construction using much weaker assumptions. Namely, Delin for GS-17 and two round OT for GS-18 and BL-18. And two round OT for GS-18 and BL-18. Two round OT being the minimal assumption. The drawback is that we lost the reusability and dynamic set of parties properties. So in our result, we showed that to recover these two properties by using just a slightly stronger assumption than two round OT, a 6-bit. Let's compare our work with concurrent works. Namely, work from Anna, Jane and Jean, and a work from Bartosek, Garth, Mastny and Mukherjee. Both are reusable to run MPC without any setup and based on standard assumption, LWE and DDH. Actually, interestingly, they are based on the two first lines of work as described before. The caveat is that they don't support dynamic set of parties. So in this work, we are achieving construction with dynamic set of parties at the expense of using a slightly stronger assumption, S6DH, stronger at least compared to DDH. Okay, here are our contribution. First contribution, definition of Marnisk. Second contribution, construction of Marnisk from S6DH, and as a side result, construction of weakness encryption for a new family of language, music of commitments. Finally, two applications. Secret sharing DBB obfuscation. DBB obfuscation cannot be achieved, but secret shared version can. And reusable setup for non-interactive MPC. Non-interactive MPC or NIMPC is a bit of the cuisine of Marnisk, but without commitments, and so with a much weaker security property, namely leakage of the residual function. Let's now show how we achieve our construction. And let's start with the paper of Gare-Gendry Alevi and Reykjavar from 2014. In this paper, they construct two round MPC by starting with a many round MPC, L round MPC, and by compressing all the round using IO obfuscation. So here is how the construction works. In the first round, parties commit to their inputs. That's exactly what happened in our Marnisk. In the second round, parties broadcast obfuscation of a program computing the next message in the L round MPC. Why does this work? The idea is that after receiving all the obfuscated program of all the parties, you can run the L round MPC in your head. And that gets all the message of the L round MPC and then get the output of the L round MPC, which is the output you want to get. There is a little tweak that this obfuscated program need to verify that the messages they receive are valid with regard to the commitments to avoid the leakage of the residual functional type. For that, they use non-interactive their own output, music proof, that they verify. IO is a very expensive primitive, as we have said before. And so in 2015, Gordon, you and she showed that you can replace IO by garbled circuits plus a seemingly weaker primitive witness encryption. So the idea is the following. Instead of obfuscating this orange box, we are garbling a slightly simpler green box. It's actually same as the orange box except without the verification of the music proof. And if you know garbled circuit, you know that to evaluate a garbled circuit, what you need is the labels or keys corresponding to the wires of the inputs. How can parties recover these labels or keys? So what they do in GLS-15 is that they witness encrypt this label so that people can decrypt the label they need using the music proof, proving that the message they got before are the valid messages. So more precisely like what witness encryption gives you is that it allows you to encrypt, for example, labels related to some statement. And if this statement is true and you know a witness for this statement, then you will be able to decrypt the ciphertext and get the garbled circuit label. And in GLS-15, what they did is that they use generic witness encryption which works for all statements. Issue is a very expensive quantity. And actually, they don't need witness encryption to work with all statements, they just need a specific statement. Here's the specific statement. The statement is a triple of a commitment c and output y and function g. And the witness is a value x and the music proof pi proving that c, the commitment c, is a commitment of x and g of x is y. So if you had a witness encryption for this specific language, you would be good. Unfortunately, until recently, we did not know how to do that. So instead, Gargan Srinivasan in 2017 showed that you can construct witness encryption for a slightly more restricted class of language where the function g is a named function. And they showed that it's sufficient for two-round NPC. And in 2018, Rachel and I showed that if we restrict slightly differently the statement to the case where a commitment can be used a single time and it becomes insecure if you use it multiple times, then you can actually construct such a witness encryption for such a language from just two-round code. And Gargan Srinivasan in 2018 independently showed how to construct something in the intersection of both from two-round T and they also showed that this is sufficient for two-round NPC. So that's great for two-round NPC. But unfortunately, for MRNISC, we really, really need the green set of language. We cannot just use the blue or the gray one. It's too small. So in this work, I tell you what we do is that we show that we can construct witness encryption for this green language, this language of NISC's of commitments. And let me show you how to do it at a very, very high level. So remember, the goal is to be able to encrypt with regard to a statement composed of commitment C and output Y and a function G. And you need to be able to decrypt if you know a witness, that is a value x and a NISC proof pi, proving that C is a commitment of X, such that G of X is Y. How do we do that? Let's suppose that you have a commitment that is fully homomorphic. This means that if you have a commitment of X, you can compute a commitment C prime of G of X. And you also suppose that this commitment has witness encryption as above, but for G, the identity function. So just Y is equal to X. Very simple. And actually so simple that both of this property can be achieved independently from non-cremative. Like for example, a fully homomorphic commitment can be constructed from FHE and a commitment with witness encryption for the identity function can be constructed from a trundity, actually it's almost a trundity. The issue is that we don't know how to construct a commitment that satisfy both this property at the same time. So the idea is the following. Remark that a BGN commitment is already one multiplication homomorphic, so you can do one multiplication. And it also has a witness encryption for the identity function. That's actually what Gargan, Trinivada, and Newton, the Fox 17 paper. But one multiplication is not sufficient. It's sufficient to do the name as we have seen before. It's efficient to get to run MPC, but it's not sufficient to run MNISC. So instead what we showed is that we can somehow really linearize the commitment to get additional multiplication and to be able to do witness encryption for NISC of commitment for any function D. Only point of time function D, obviously. And that's how we construct witness encryption for NISC of commitment and that's how we construct Mr. NISC. So to conclude, we defined a new model, MRNISC, we showed that we can contract MRNISC from A6DH and we presented it to application. So I did not show you any of the application. Please read the paper if you're interested. And thank you very much.


as we prepare to witness the world's foremost athletes compete on this global stage. This partnership, I say, signifies the convergence of expertise, innovation, and shared passion for sports. So, you know, we are so excited for Trinidad and Tobago, we're excited for people, I mean, from July 26th to August 11th, you know, this promises not only to be an exciting time for the world, but you know, the people of Trinidad and Tobago, whether they will be in their homes, whether they'll be in their workplaces, I know some people would have viewing events, you know, it really, really promises to be an exciting time for countries.


Mae'r rhwng ymddi, yn y bacholus gyda'r panau at Wadston, ac mae'r cyfnodd cyfnodd yn ymddi'r 80s-90s, oedd bairon fferdon yn ddiddordeb yn ychydig i'w ddweud o'r rhwng Gwyrdyn, ac mae'n ddweud o'r rhwng yn ymddir i'r rhwng yn ymddi'r rhwng. Mae'n holleg o'r rhwng yn ymddir i'r rhwng yn ymddir i'r rhwng yn ymddir i'r rhwng. ac yn ystyried i ddyfans, mae'n gweithio iaith yn y teimlo'r cychwil, yn y dyn nhw'n ei gweithio amgylcheddau. Mae'n gweithio cychwynol, mae'n gweithio, a'r cychwynol mae'n gweithio i ddweud i wneud y gweithio ac yn cydweithio ar y rhaid o'r coul. Wrth gwrs, mae'n document arfer y cwrwp red wedi'u ddwylo'r hynny'n argylcheddau ym 1897 yma. Mae'n ddwylo'r document and the appearance of Wadston in 1897. Unfortunately in the red book, Ferdinand did not write about how he furnished the house. But what is interesting about the smoking room is that in the red book there are six photographs of the interior and of his Renaissance collection in its glass cases. More photographs of this room than any other and we think that's because at the time ond Ferdinand was thinking about and compiling lists of items in that collection that he would later bequeath to the British Museum. The character of this room is different from other parts of the house where in the main house Ferdinand uses 18th century patterns for his textiles. Here in the smoking room he goes back to an early period of time, the period of time when many of the objects in his collection were actually made. Felly, mae'r cyflawn y gwelwch, yw'r cyfrannu yw'r 17th Cymru, ac mae'n gweithio'r texas yma ar y 16th a 17th Cymru. Mae'n gweithio'r eich cyflawn o'r oedd ymwyloedd cyflosiadau, felly mae'n gweithio'r texas yma i'r cyfrannu yma, ond mae'n gweithio'r eich cyfrannu a'n gweithio'r cyfrannu cyfrannu. Mae'n gweithio'r cyfrannu a'r cyfrannu i'r cyfrannu i'r cyfrannu i'r cyfrannu. Fferdinand was very inspired by the idea of a treasury collection and this idea that although things were in glass cases they could be elevated or they could be mounted in some way to enhance their status. When we look at historic photographs of the smoking room in the 19th century we see that not only were objects on plints outside the cases but also in the cases and here we have collected together quite a lot of these historic plints and you can see from the fact that they're covered in velvet and braid and all of these tassels and trimmings that they were quite theatrical and luxurious objects in their own right and these kinds of things would have been mounted on the walls with various sculptures or dishes on them, some of these might have been in the cases with glass or jewellery standing on them. In particular we have a marble bracket which is one of four that is visible in one of the historic photographs of the smoking room and it would have had a large oval shaped limoge enamel dish on top of it probably resting on one of these but these things survive here at Wadston because they weren't included with the Wadston request. This chair is a good example of how Ferdinand was using older textiles in the smoking room and creating 19th century pieces of furniture for comfort and for effect alongside his renaissance museum. The chair is meant to look like it's from the 16th century but in fact the frame, the barley twist frame is a 19th century creation. The seat in the back of this chair have been taken from a type of ecclesiastical vestment called a dalmatic and this is a T shaped robe where you have a rectangular panel at the front and the back here and then panels on each sleeve and because of their shape they lent themselves very well to being cut out and reused for seat furniture if the vestment was sold or confiscated or destroyed or stopped being used for whatever reason and you've got red velvet and then embroidery and applied silk as well and lots of metal threads so they're very luxurious objects in their own right. Ferdinand wrote very eloquently about collecting and how he felt that eventually collections in private hands would pass into public museums and that that was right, that people should have access to these wonderful collections and this was partly his intention in making the Wadston bequest that the collection that he had formed should stay together in his name and be available and accessible to the public. There was also a practical reason for him making the bequest in that death duties had been introduced just a few years before and he was very aware and concerned about the future of Wadston for his heirs and that this gift to the British Museum would offset some of that tax. The Wadston bequest has been on display since 1900 in its own gallery and a catalogue was published as soon as 1902 with wonderful photographs of highlights of the collection and it's being re-displayed in June in a new gallery so that lots of people will be able to see it in its new location on the ground floor of the British Museum.