 Hi and welcome. My name is Adam Helens. I'm a clergy consultant as well as a psychologist from the tiny country of Belgium. The topic I'm about to expose today might be a bit polarizing, we could say. I'm sure that most of you have heard about blockchain or crypto in general, but the thing is there is so much buzz and fuss going on that it's hard to have a clear understanding of what such decentralized systems really are. So that would be my task for today. Try to provide you with a more balanced, more realistic understanding of what decentralized systems are and what you can achieve with them. Lucky us, it turns out that closure as a framework, as a way of thinking, becomes very useful for that kind of task at hand. The word decentralized is not new at all, but it certainly has become pretty well known in the field of computation for the past few years. But really, it's just the act of trying to avoid concentrating all our things, all our stuff, all our resources into one area, whether it's speaking physically or conceptually. Why, you may ask? Well, let me show you this picture. This is the Evergreen boat that blocked the whole US canal not that long ago. And this whole thing has resulted in billions of dollars of losses because a huge part of the world's logistic was simply halted. Now, sure, the whole canal remains a good idea in spite of that kind of incident. But the thing is, it shows that centralized systems introduce single point of failures and usually at more than one level. And so as a society, it would benefit from trying, at least trying, to avoid that kind of scenarios. Whether we are talking about, you know, the distribution of goods or services or politics or economics or education, the common denominator that I see in all that is that we tend to centralize truth and trust. Now, putting those two words in the realm of computation, truth would be data. Effectively, you don't really want your data to be represented by one single source of truth. Because when that source of truth starts to misbehave, then there is nothing you can do about it. And your data is essentially brittle and vulnerable. Trust would be more about permissions. We want to have a clear model, a clear idea of what individuals, what entities owns what capabilities over some pieces of data. But it's not enough. You also need security. You need the guarantee that those permissions will be enforced. And once again, you don't want one single entity to be behind that kind of guarantees. Because otherwise, as soon as this entity stops behaving in your own best interest, then once again, there is nothing you can do about it. If we had a way to decentralize those three aspects in the field of computing, we would reach something that is commonly known as the Internet of Value. You could say that it's a network that's effectively this public database, public as in anyone can read from it. And it is massively replicated. So we don't have a single source of truth, we have many. And it's a peer-to-peer network where, in theory at least, any peer is just as good as the other one. And it's a permissionless network. You don't want to be asking permission from anyone if you want to join in and take part, because then you could be vulnerable to censorship. And of course, people will try to cheat the system as always. So you have to have a secure protocol that guarantees that even in the presence of such malicious, malevolent peers, the whole network still performs as intended and securely. If we had that kind of network, then the word value in Internet of Value could have two meanings. First, it's data, right? But this data becomes so reliable that it can be seen as an asset. Asset as in the sense of being useful, or even having a monetary value. And this opens the door to so-called digital assets. Now, we don't have to go that far, of course. If you don't care at all about digital assets, I'll be mentioning NFTs later, for instance, non-fungible tokens. If you don't like that kind of stuff, we don't have to go there, but that's how far you can go, essentially. One implementation of such an Internet of Value is the convex network. It's not the only one, I'm not going to lie. There are quite a bunch of projects trying to achieve this vision, but this one has been designed to be especially energy efficient, because many networks tend to waste resources and energy. And it runs on the GVM, which is really convenient for us, clodgerists, because then we can access this stack and use it, any part of it. And what is more important here is that convex has been designed and really based on what we could call the clodger philosophy. And it's super important, because it is kind of rocket science. It's a really complex piece of tech, a really complex domain, where we mix networking and distributed systems and databases and cryptography and all that. So if we could borrow ideas that you already know, then it would certainly be a lot easier to understand. What I mean here by the clodger philosophy is fairly uncontroversial. First, we like to use a fairly small number of data types, because we have shown many, many times that we can build very complex data models if we are careful about the basic data types, the basic building blocks that we chose to do so. And those data types are even more versatile when we can combine them. Like in maps, for instance, keys can be literally anything. And this strong emphasis on immutability is something that is really important for that kind of system where truth and time have quite precise meanings. So let's start with the very first step, the data itself. Here we can see decentralized data values, or also known as cells for short. Now we can see that they have this strange familiar aura to you, because yes, they have been modeled directly on clodger data types. So I don't have to explain what are symbols and vectors and keywords and maps and all that. We do have a couple extra ones, like we have blocks, which are effectively kind of byte arrays. In this network, we have accounts and those accounts have addresses. We can see here address 42, for instance. But yeah, overall, we are pretty good to go as such. Now why are they called decentralized? How are they different from just clodger types? Well, it would pull down to design and implementation. Because we will care later about persistency in the network, we had to embed that into the design of those types. Notably, they have a very dense and very efficient binary encoding. And this binary encoding tends to match quite closely the type that it represents. So if you give me a vector, for instance, an encoding of a vector, I mean, I will be able to very quickly deserialize it into an actual vector, because the number of steps is quite reduced. And vice versa for serialization. And you know how clodger types have, these collections have structural sharing? Well, you could borrow that kind of logic for the encoding themselves. Where if you have, say, a vector once again with a very large item in it, you don't have to actually embed this, the encoding of this item into the vector, you could just store a reference. And a reference here would be the hash of the binary encoding of that item. That will become a bit more clear in a minute or so. Imagine this vector of integers from 0 to 100,000. So we have effectively 100,000 elements. Yet if we look at its binary encoding, it's only 70 bytes. So what happens here is that obviously we don't have those ints here embedded in the vector. What we stare at are a whole bunch of references to subvectors. And what this gives us are fast incremental updates. So the state of the network could be gigabytes. One day it could even be a terabyte. What happens here is that even though the state could be that big, if I modify it, for instance, and I send its binary encoding to you, you'll get that kind of very compact, very dense definition. And you'll be able to very quickly spot what is different. Most likely just one reference has been changed, for example. And then you can ask me back for it. And we can go back like this, back and forth a few times. And very quickly, even though the whole state might be huge, you will be able to get up to date with me. And this is super important for networking, obviously, but also persistency. Just a quick example here, because we do have some Clojo libraries that you can use for many things like creating those cells. We have this star macro here where we can use Clojo notation to create those convex cells. And many functions, I mean, Clojo functions, standard ones, tend to work with those. And for the rest, we have some alternatives that we would expect, like conge, get, and associated, and all that. Now, it turns out that if we take care about those cells and implement them, then implementing a database, just a plain local database, becomes a lot easier. Let me introduce you to H. H is a database, you know, I think it's a thousand lines of code, really, because it leverages the cells and those binary encodings and everything I was just talking about. It is effectively immutable, it's append-only, and it is content-addressable. What that means is that here, you could picture it as being a huge map, essentially, where when we store values, we store their binary encodings and keys, well, keys are hashes of those binary encodings. What I've just described is known as a miracle tree, a kind of tree where keys, I mean, are hashes of the values that it points to. Although here it's more of a graph, because remember that those binary encodings might themselves contain references, that is, hashes to other encodings in the database. And that kind of key value store slash map is really convenient to use because what you can do when you want to retrieve, once again, a very large value, you can just retrieve that top binary encoding and you're good to go, right? Then when you need to access one particular item that might be a reference, then only you can fetch it from disk when you actually need it. And what you don't need can be garbage collected. What this whole scheme allow you to do, no pun intended scheme, what this whole scheme allow you to do is to handle data that is way bigger than memory, right? Once again, just a quick example here of how we could create such a database just even for local use, you would point to a file, then you would create any kind of cells that you want, and then you would simply use the write function on your cells, and that's it, they are persisted. And then when you want to retrieve them, you would use the read function and provide the hash of whatever stored cell you want to retrieve. So very convenient, but you would feel a bit naked if you wanted to design a networked database. What is missing is to do some sort of computation, to have some sort of way of executing code for transactions like in any common network database. And this is the primary goal behind the convex virtual machine. It's an execution engine, Turing complete, and deterministic. Later we'll see that it's really important that the transactions that we issue are entirely reproducible. Like any kind of execution engine, we have a set of fundamental operations, we can create some constants, we have branching, we can define some stuff in some functions, but of course as a developer, writing transactions and code, and later I'll be using the word smart contracts, you don't want to write all that into that kind of assembly, if you will. You want to have a higher level language. And what kind of language would be suited for manipulating Clojure-like data types? Let me introduce you to convex LISP. Convex LISP is effectively almost a subset of Clojure, given some additional utilities and a couple of minor differences. And here is just an example. So let me stress the fact here that this is not Clojure, this is an example of convex LISP. And you can tell right away that it looks oddly familiar, because yeah, both are just so similar. Now I'll be coming back to this example a bit later. What I'm quite thrilled to say is that convex LISP is probably the very first decentralized LISP in the history of computing. I say probably because it has been mentioned before when it comes to distributed systems, but this particular flavor of LISP has an actual on-chain compiler, something that you don't seem to find. So you have lambdas, you have eval, you have macros. If you remove any of that, like a LISP without eval or a LISP without macros, it would look a lot less like a LISP, right? So probably when LISP was mentioned, it was more about just syntax and S expressions, and this could be effectively the very first actual LISP when it comes to decentralized systems. You would use that kind of execution engine to alter the state of the network, the state of this public database. But what is it, this state? Once again, you could picture this huge map where we have a whole bunch of stuff and not only accounts. Let's focus on that because accounts are the minimum through which we submit transactions. If we had an account, then you could run this transaction here, Def Hello Reclosure. And if we inspect your account after that, then we can see this kind of map where we have a whole bunch of key values and not only the environment, but being this map where we can recognize our Hello symbol pointing to this Reclosure keyword. So effectively, accounts are a bit like a namespace, a namespace that anyone can read, it's public, but you are, by default, the only one who can write anything to it. Accounts are, as I said, very important and there are actually two flavors of those. There are user accounts and those are operated by humans and they are linked to a key pair. If we come back to this description here, we can see that, yes, it has a public key, a 32 byte public key. So what happens is that when you create an account, you generate a key pair, you provide the public key to be stored on the network, and then, of course, you keep the private key for you. And so when you issue a transaction in code, then you sign it using your private key. There's no one like a peer who can very easily verify it because your public key is on the network and if it's the case that indeed you have signed it and submitted it and it has been verified, then your transaction can be executed. Then we have actors. Actors are fully automated. They have no keeper meaning that no one can issue any kind of transactions on their behalf. They still account so they have an environment. They can store some states and values and they become really useful when at initialization you define some functions for altering that environment because this will lead us quite naturally to smart contracts. Let me give you an example. Here is how we can create a new actor by using the deploy function and you provide quoted code that is being called and executed when this account has been created and in the context of the new account. What will happen here is that it will define a symbol here, myState and then a function setState taking an X argument and essentially rebinding myState to X. Just a function for altering the environment but only if the color of this function is account 42. Believe it or not, as simple as this example might look those are debounding blocks that you find everywhere in any kind of smart contract no matter how complex. You always have a notion of state and a notion of an interface that is here just plain old function describing how this state is being altered and who can do it. Let me show you an actual example that you have already seen. This bit of code for creating so-called NFTs, non-fungible tokens. They are a type of digital asset. We have an actor here that we import and then we can call its create token function and provide this map. In this map, believe it or not, is effectively the NFT that we will meet. An NFT could be really any kind of data. In the end, it just bites. And if we have a look at what could be the state of this actor at least a simplified overview, then it would be something like this. Probably a map where we have some ideas pointing to those so-called NFTs or data and we just assign a sense of ownership on top of that. You can see here that account 42 supposedly owns this NFT. But of course it's not that simple. The whole idea here is that the actor himself allows you to do many, many things especially when it comes to ownership. For instance, you can decide who can transfer it, who can destroy it, who can modify it. Although the data can be quite simple, when you have that kind of guarantee provided by such a decentralized network in that kind of interface, then it can become a digital asset. Now, this was really important in the history of convex. This library has been written by Mark Engelberg, by the way, who is also the author of Instapars. And it has shown that you simply don't get that level of sophistications on other networks. Because the level of abstractions that you get from claudial-like constructs is really unmatched in expressiveness. And this is just the tip of the iceberg. I'll go very quickly about the last missing piece here that is consensus. So what happens when you actually issue a transaction? Well, it gets received by a peer and this peer sends it to like 10 other peers. And each of them will again send it to a whole bunch of other peers. So your transactions is being gossiped through the network and very quickly the whole network becomes aware of it. Not only your transaction, but all other transactions being emitted concurrently all the time. And of course, it's a bit messy. All those transactions appearing all the time continuously. So because they are independent, they have no intrinsic order. So peers have to vote on an ordering and agree on one. So they do that kind of continuously until they have agreed on some order up to some point. And then they know that they can execute those transactions at least. And that was what I was referring to earlier when I was talking about being deterministic is that if you and I have the same state and receive the same instructions and we execute them in the same order, then we have to reach the same result. Makes sense. Now, why would peer do that? Why would they do that kind of work, I mean? If we have a glimpse once again at our account from earlier, we can see this balance. This is a balance in convex coins. Because when you issue a transaction, you do pay, so to say, some fees in convex coins. That's native token. In other networks like Bitcoin, those tokens are kind of numbers that you shuffle around. But here they have an intrinsic value because they are used to reward peers and that's why the network is kind of self-sustaining. If you want to read more about it, then you can hit the website and find the white paper and you'll find all you need to know about the convergent proof-of-stake algorithm and many, many other things. So to recap, if you want to build a decentralized application based on everything of the site, there are two sites to it. First, there is what happens on the network. You have to write the smart contracts in convex lisp, deploy them on the network. And if you want to learn more about this, you can once again hit the website and have a look at the developer section. There you find everything you need to know about convex lisp. You'll find some examples like this voting example here and the kicker, in my opinion, the sandbox, where you can create an account on the network. It's completely free of charge because it's a test network and you can issue some transactions. It will provide you this rich interactive, ripple-like experience, the best way to learn about all that. And then you have what happens on the client side. You have to have some way to talk to the network to provide some user experience, usually. We've seen a bit of closure today, but we have a whole set of libraries that you can use for creating some cells, as we've seen, and many, many things, and notably for talking to the network. You can connect to the current test alpha network and issue some transactions like calling those smart contracts that you have written. Alright, reaching the end of this presentation, I'd like to thank Mike Anderson, he's the founder and the director of the convex foundation and he's the one who first imagined this really elegant design and first implemented, so he sure deserves our credit because we can see in the end that it's quite straightforward to build decentralized application and when you use the Clojure philosophy to see how it looks like and how it behaves and what you can do, then I hope that it makes a lot more sense to you. The convex foundation has been established so that the whole project remains open source and what we do is that we try to make it self-sustaining, community-driven as much as possible. We try to reward people who actually contribute to it and make this dream come true, so to say. Sure, come and have some fun, you can help us build everything I was talking about today, improve the database, the execution engine and all that. You can help us with writing some libraries, Clojure ones, convex list ones. There's certainly a lot of things to do when it comes to dev tooling. Try to prototype some stuff, either completely decentralized applications or maybe try to decentralize one aspect, like you maybe have some voting mechanism. You could try to decentralize that one thing in your application and in the end it's all about the people of course. So do join us, we want to spread those ideas, their novel, both in the Clojure community and in the blockchain decentralized community. So yeah, come and have some fun. Thank you very much, it has been a pleasure. I can get really quite passionate about those topics. So let me leave you with this slide here where you can find us. We have a community discord, do come there if you have more questions about the project as a whole. If you're more interested about the Clojure integration then we have this convex channel on Clojureians and of course have a look at the repos. My name is Adam Helens, it has been a journey pleasure and all I can do now is I guess just wish you an excellent conference. Thank you.