 Here we are with the first panel of the day, the second day. And this will be with Christof, Baptiste, Adam and Michael. So we're going to have both the speaker in the talk and their collaborators. We have this mystery about Mr. Egg that you posted online in your background while you were doing the talk. I'm going to show you. Pavel, you got that. Yeah, I can ask you because I thought there's actually two Easter eggs. Maybe that was by accident and great minds think alike, that kind of thing. I saw the dots on the table, so I thought that was the one Easter egg. The other thing was that the books that you had on the bookshelf were really familiar, right? And I think all of those books, well, most of those books, at least on the shelves on the sides were listed on Rich Hickey's bookshelf, right? Like Rich Hickey posted at some point, he's, you know, whatever, reading that inspires closure. And I think all of those books on the side bookshelves were, was that intentional or by accident or just like the same books or what happened there? So for foundation of databases, it definitely comes from Rich Hickey's bookshelf, but the other is an accident. That is uncanny. Great minds think alike, I guess, that's the answer. So I'll leave it now to John to see if the other guests are available. Thank you, Renzo. So let's see if Adam is online. Hi, yes. Hey, there we go. How are you doing? I'm quite alright, thanks. That was an excellent talk. That's an impressive microphone. I thought mine was good, but yours is even better. Oh, it just looks, you know. What I'm listening to you is, is there anything curious or interesting you'd like to share about your surroundings about what's going on at the moment? In my surroundings, well, it's a bit of a peculiarity. But usually on my desk, I always have a deck of cards, you see. It's a bit weird, I know, but the thing is, when I was quite a bit younger, I used to do a lot of magic tricks, you know, and so I don't have much time for that these days. So usually I always have a deck of cards, so that when I have to do some readings or long session and all that, it keeps my hands kind of busy and can help me concentrate. So a bit of a fun thing to say, I guess. Excellent. I suppose it's good for keeping the dexterity in your fingers and stopping RSI and things like that as well. So great stuff. And do we have Michael as well? Yes, indeed. Thank you. And Giselle, if you've got anything you'd like to share briefly, you've got a very nice seat you're sitting on by looks and things. Yeah, this is this is secret lab chair. So this is I'm supporting, so I live in Singapore, I'm supporting a local company secret labs that makes gaming excellent gaming chairs so I can put it in the sponsorship plug for them. Excellent. Thank you very much. I really want to ask the first question. Yeah, let's go with the first question. We want to know, first of all, if that bookshelf was Christophe or Baptiste's but I think we saw that live and we know that now is Christophe bookshelf. So another question is, what is the meaning of that dot ampersand enclosure dot? The dot ampersand is mostly on its way out, but in the enclosure dot, you can have named parameters to a function. So the, the trick we, when we started designing closure dot was to find a way to tell closure that from this point on, these are name, name parameters that you have to pass to this dot function or Mr. So the, the dot ampersand was used as delimiter to, to instruct the compiler that it was an interval form with named parameters. But we had to, to resort to this, to the solution because at the start of the project we, we made all variables dynamics and by making them all dynamics we would go to to produce code quickly, but it was, it wasn't efficient and we had other problems in the world. Now that we have proper typing inference on all methods, we know when a method is going to have name parameters so we don't need them anymore. We are just facing them out at the moment. So basically it's just a syntax to use the name parameters right now. Okay, thank you for the clarification. John, you want to take a question for Adam or Michael. Question I guess for Adam is like, what do you see is the overall vision for cortex world. What do you expect that that will enable and grow into. And like, is it comparable to things like Ethereum and so on is that or is that like very different kind of tangent and what we're trying to do. Oh sure you could very much compare it to Ethereum, but because we have this ability to build complex data models. And it's also much, much faster, at least in our bench concurrent benchmarks. Much, much farther, right. I think that this kind of tech has the same kind of effect on blockchain that Cluster had on Java or on the GVM I could say right the GVM by itself as a way of, you know, just having a virtual machine and, and it's very capable right, but you want to have something that is more sophisticated and allows you to, to, to handle more complex data and you can go very, very far. I think that's Mike has many examples you'd like to give you, I guess. Okay, thank you. Yeah, well, certainly I think the vision of the vision of convex is definitely that it can be a building block for people who want to build the sort of next generation of decentralized applications. And I think some of the things that I find particularly important is I was horrified by the energy efficiency, inefficiency of things like Bitcoin and Ethereum. It's just ecologically unsound and one of the motivations to be certainly contributing to convex was was building something that was super energy efficient super fast. And it has a sort of low latency, which makes it usable for things like gaming or consumer mobile applications web applications, these kind of things, which are currently impractical with the current blockchain technology. So, so my hope certainly is it becomes a valuable tool in the in the building block for people who want to build these different applications in the future. And can you say a little bit more about the energy efficiency is that due to closure or is it just kind of like your design or the infrastructure. I think there's, there's two things one the JVM is actually a pretty good execution engine and we all know from closure that you know the JVM gives a very solid foundation and wants to build a very good performance and obviously did compiler and stuff like that. The garbage collection turns out to be really, really useful for decentralized apps where you've got these big immutable data structures with structural sharing and sometimes you have to discard large chunks of it. The GC is very valuable, but say the main reason that it's efficient is that convex in the design of convex we found a way for the peers the decentralized peers to agree on an ordering of transactions without burning energy. You have to spend a bunch of time or compute or storage in order to reach that consensus on the order and that's kind of the key innovation. It's how do you make the ordering of transactions stable consistent and consensus without spending any electricity or other computer resources to work that out or at least minimal. If you have a local test network, you can you can you can you can literally pump millions of transactions with convex. It's incredibly efficient. Okay. And with resources, if I may add, there are a couple other innovations I didn't talk about today because it was kind of more advanced. But for instance, there is a kind of a memory allowance, right, because on networks like ethereum. For data, you pay things fees just once. And that's it. Then the peers have to store it forever, which is kind of unlogical if you think about it right where there are here what you have is is the fact that you have some amount of memory that you can use. And then if you, you, you lack some, then you can automatically buy some for context coins during a transaction I mean it's completely automatic right. And if you release memory because you you undeath some data, for instance, then you could sell it back for instance right. So you have that kind of mechanisms that have been embedded in the network so that you have some incentive to keep things clean. And so there is also this category of innovation that prevents things like wastage, essentially. Excellent. It's obviously a lot of thoughts be going into that aspect. I'm very happy to see that. Thank you very much. We have another question for Christophe and the test from Ben's less who is next to speaker, by the way, how much of these conclusions and techniques could be applied to closures compiler. Anything from inferring NILs for tests to project the HALA, which should allow the JVM to get past type of measure and much it would be possible to type in terms as it is a plug in the compiler. And to be less I don't understand the goal of a project. So maybe Christophe do you have input on this project. So, basic type inference would be stuck to closure dots. Okay. Christophe, are you with us? Yeah, I'm not familiar with project HALA, but for the type inference itself it's really tied to closure to dot itself. It tries to mimic and simulate the own dot type system so as to be able to please the compiler, because otherwise the dot compiler is pretty harsh. There are even some cases which I consider borderline as bugs. For example, I remember with NIL labels, you have an operator dot question mark which allows to, it wasn't even with a special operator. We add one line, which was checking a value against NIL. And if it was NIL, it was throwing an exception. And then because the code generation wasn't quite good, further than the line, there was also, there was the same test anew. And that compiler was complaining because once it passed the first if, which would throw if the value was NIL, he was complaining that we were testing a non-NIL value against NIL. So the type inference is really there to be able to be as smart as the dot compiler. Otherwise we get weird errors as well. Yeah, it seems to be premature to think that there is anything we can introduce into the closure compiler in this kind of sense. That was the original question, that's why I'm asking. Okay. Yeah, just maybe NIL and some could be helpful, but I believe there are already some some handling of that enclosure. Thank you, Christoph. John, any other question for. Yes. So there's a question from the discord channel. Could you please explain the consensus procedure used in convex in regards to pound pause? How does it differ? How does reaching consensus work? That's a very complex question because this is the hardest part of the whole stack, I think. And it has to, you know, it mixes with a bit of economics and game theory. But so proof of stake is a class of algorithms. So conversion proof of stake, which is what Mike has designed in the first place is under the very first one ever, but it has been in the workings for like three or four years. I think Mike, it was. But yeah, about three years. Yeah, so could you tell us how is it exactly different from usual proof of stakes algorithms? So I mean, I think Adam's exactly right proof of stake is a class of systems where consensus is agreed by a stake so some kind of weight and convex does use stakes and it's effectively it's a type of proof of stake and algorithm. I think the most important difference with convex and potentially other other decentralized networks is convex consensus is actually implemented as a CRDT. So it's a conflict free replicated data type. And these are these data types that have this beautiful property that you can merge two instances together and get a new instance. And if you happen to do that in a repeated fashion, e.g. by gossiping the values around the network, then as long as the merge function has the right mathematical properties and there's some lovely math papers if anyone's dive into this. You can actually prove that will eventually converge to a stable state. And that's what you want for consensus you want this convergence to a stable stable state which then you know forms the basis of your agreement around the ordering of all the transaction which is then how you compute the updates the global state. Now, can't go into too much detail here on how that merge function works, we basically found a merge function that enables you to implement proof of stake as a CRDT. Yeah, so that the merge function takes into account the stakes of the different peers, and the merging happens in a way that is consistent with the boats of the of the peers in the network. So it's all in the white paper if you want to dive into more depth but hopefully that's given sort of a brief overview the key idea is a conflict free replicated data type therefore it's guaranteed to converge under the under certain conditions. And two things that are apparent from this is that so in blockchain the word blockchain you have the word blocks of course because what you end up with usually at the end is a chain of blocks that are indeed cryptographically linked right but here it's a bit different. So transactions are being grouped in so blocks, this is what appears emits to other peers groups blocks of transactions. But there's effectively no leader so any peer can emit a block of transaction at any moment right where we're asking even older flavors of proof of stake. You tend to have quite often a notion of a leader so that only one peer at one given time can broadcast a block of transactions. So that's one of the reasons also why convex is so fast even on the network level, we could say. And having that kind of CRDT also means that those blocks are not cryptographically linked. They so peers vote on an ordering so there is a sequence of blocks at some point, but it's a bit different from the usual blockchain in that aspect right technically we could say that it's already something a bit different from from a typical blockchain. Okay thank you that was really useful explanation and yes I'm kind of looking forward to having a look at the white paper that's on the website as well that should dive into a lot more detail I expect. Oh, okay thank you for that. So we got more questions for one more question for sure and yeah remember to raise your hands for live interaction. This is for Christopher Baptiste from Yakub. I gather there is a some impedance mismatch between closure and art due to the types Neil handling and such. It seems you have made great progress, but do you think you will get to a point when writing flutter apps in closure script will be painless without running into the into the mismatch or will there remain some corner cases where the interop will remain painful. I'm going to start. I'm writing a closure that application. I rest application right now and I found the experience awesome. We are still like Jacob Jacob Jacob said. We are not still at the level of interaction greatness like closure and closure script to be honest. I don't know if we can achieve that, but I don't, I don't think types will be necessarily an interrupt would be necessarily the main pain. We really have to find out how we could have a better, a better repo and auto load experience. Actually, actually, we don't have a repo right now. But we try to design. And it's working. But, yeah, what's your opinion, Christopher. To on the impedance mismatch between closure and the and that I've got we, I think we have got it mostly under control now. There are some, some things with which are going to to be addressed by the but what we call the magic cast, which, which are workers which are automatically inserted by the compiler by the closure compiler to to make sure that we transform the input into a wrapper of the of the suitable type for that. But yeah, just from the relationship between the two languages. I think we, we don't have much to much to fix yet. One thing that's worth mentioning is that we never designed crucial that code to be credible from that code. The intent has never been to be able to create leaves to be used by regular that code. That's either to add to what Betty just said. Well, we don't have a weapon yet, but we have made a proof of concept very early in the development. And the focus currently is on the on the batch compiler, which, which we can then couple with the auto editing feature of doubt to produce the same developer experience as the one that that developer used to, or even some, some people in the community, which can work with auto auto reload. That being said, writing a mobile application sex, it's, it's hard. No, it's true. You have to, you really have to comply with the iOS tools and even if you're using flutter or reactive, you will still have to struggle to compile your application. And let's say to package assets. It's, it's, it's not like rating the web app or shows a very crucial application. You have many rules. Okay, thank you. We have probably another question from Jones. Yeah, we've got a couple of questions ones actually follow up from the last question. So just querying if there's any trade offs in the convex approach compared to traditional POS networks. Is that something that's in the white paper or is there something you can say about that. I think it's probably a very, very long topic. I think we have the best approach to POS in the sense that the CRDT seems to be a perfect fit for the centralized systems and then we use we use POS. Well, there are obviously challenge with POS. Yeah, I mean it does require people to put steak on, on nodes and or steak on other people's nodes. And there isn't yet a long history of POS networks and how they behave from an economic perspective. So, I think that's still a bit of an open question. It's one of the reasons we're taking a lot of time to get this right and also to make sure that the economics are viable and sustainable in the long term but I'd say there's still a bit of an open question around what is the best way to make proof of steak work. I do think there's too many trade offs. I think we've genuinely eliminated some bottlenecks and some some pain points in some traditional blockchain approaches. I don't think we've given up too much, but you know, people can argue this all day because there's a lot of complexity and a lot of different, different aspects of it rather than so. Sure. Happy to make further on the convex channel or something if someone really wants to get into that. Good. Yeah. On the discount channel there, asking a couple of questions about that. And just one final question as a query about adoption, I guess the question is really aiming at like what does this COVID need a covex need anything to be successful. It's like we'll move from this core product into actually being widely adopted in production or is it just a matter of people using it. Yes, two things like to say here is that that kind of open source, you know, community project, whatever we call it, it can show some limits where we have to actually hit actual production. So we have released an alpha version it was in September I think so not that long ago, we are slowly but surely go for beta. But the problem is that when you want to actually launch a mainnet, as it's called, then you its best, usually to have some kind of audit for instance, from a third party company who will try to to break it and ensure that it just works perfectly that, you know, security wise, things are just as smooth. And unfortunately that kind of steps require a lot of funding, right. And it's a bit hard. I'm going to be honest, it's a bit hard to found that kind of project because it's a bit too abstract. So if you know Clodger and Lisb and all that, then in a bit of blockchain, then you can realize the value of a network like convex but if you have never heard about Lisb or anything like that, then it looks just very very abstract, right. So we have a bit of a Lisb curse going on here. That's the first thing I could say here and the second one would be about just having a strong community. So that's why we would like talking to developers who aren't really into blockchain because first of all, that's the vast majority of developers today, only tiny fractions of developers actually work in blockchain or decentralized tech, because we'd like to expose that kind of ideas more and more, and show that it's interesting for other use cases than just NFTs and cryptocurrencies. And so yeah, we would like to see more people like that coming in and building a stronger community and have something going on there, a bit more impressive. Excellent. Thank you very much. Well, hopefully people watching this live and in the future will be interested and take up that call to join our community as well. Thank you. I wanted to just add for Christophe and Baptiste that I saw your tense grittics closure dart repo. So you mentioned that is something is my code might appear there in Q1 of 2022. So I wanted just to close asking you where people can go to help you out or follow your work in general. Twitter, just follow Christophe and me and we'll have the last news about the project. Okay. Or create PRs on the empty repo. Okay. Well, looking forward to the evolutions of that. And yeah, I'd like to thank Christophe, Baptiste, Adam and Michael for being with us today answering questions, your effort in putting together the talk very appreciated very interesting projects. Thank you very much.