CorePlay - An actor-like framework for blockchains

Okay, let's start with the content. First, I want to give like a small history lesson on blockchains and all the industry involved, then talk about more users. As already said, I want to talk about Jam because I co-play all the ideas to build it on Jam, and I want to introduce some of the building blocks that we are using. Then I want to get to co-placers, and lastly, I want to talk about infrastructure for these actors. As most of you probably know, Bitcoin has this Genesis block in 2009.

From Bitcoin on, there were some talks of the Bitcoin code base, like Namecoin, Litecoin, and some others. It took like four years to have the first non-Bitcoin-based blockchain implementation, which was Ripple in 2013. I think it already shows, and if you look at today, we have maybe thousands of blockchains, but most of them are forks of other blockchains and forking the code. For me, basically, writing a blockchain isn't that easy, especially from scratch. You need to have a lot of knowledge.

You need to know about networking, storage, content, so like a lot of topics if you want to write your own blockchain, which makes it very complicated. We had the next step in the history of blockchains, I would say, was the invention of smart contracts. They launched or premiered with Ethereum. Today, there are like 78 million smart contracts. I mean, not all of them are different or like most of them are probably also forks or variations of each other, but it already shows there are maybe thousands of blockchains, but millions of smart contracts, which shows that it's easier to write a smart contract than to write a blockchain.

The good thing about smart contracts is that the developers can concentrate on the business logic because, as I said, you don't need to do the networking, blah, blah, blah. All the stuff is being provided by the blockchain for you. You also get the security from the base layer, so you don't need to take care that you have validators. Validators have no stake or proof of work or whatever you're using. The bad thing of smart contracts is that you have less room for optimization.

You can for sure optimize in certain ways, but there's always an end to it. For blockchains, you can go deeper when you want to do these optimizations. And you also have less access to certain things, like you cannot change the ordering of transactions or decide when a transaction can be applied. All these things. Then we have this third phase, what I call it.

It's wallups and similar things. I call it similar things because some people have really concrete descriptions of what a wallup is and maybe don't like if you call all the things wallups. But with Cosmos, for example, there is security. It's more like that you need to trust all these different chains. Then there is Polkadot with parachains, and parachains are similar to decay wallups because the validator set is actually checking the state transition of your Polkadot parachain or while you verify your decay proof.

All these things that you have, there's a different security assumptions to all these things. So people are going back to these wallups because people want to have more freedom. They want to decide what is the fee model, what's transaction ordering, they want to capture the fees or all these things. To simplify the development of wallups, people started providing SDKs to write the wallup, which makes it easier but still complicated and not as easy to write a smart contract. Also, you don't get the infrastructure for free.

You need to have nodes running, you need to have integrations, all these kind of things, which are provided. If you're kind of provided when you have a smart contract by the base layer, you need to have on your own. Okay, now to more users. I think if you look at the industry right now, a lot of all blockchains want to have more users because all these blockchains should have a value. It's not like that we just do all these things for no meaning or whatever.

If you want to have more users, you need to have better products, more products, more applications. That brings us to the point where you need to have more developers to do these things. You also need to have people doing marketing and business, but also these people need to have products and applications that you can actually sell because without an application, just selling it maybe works for some time but not always. If you look at the developer report from last year, we have 24,000 developers in the crypto industry. That's 0.

01% of all the developers existing worldwide. That's a really small margin of how many people exist in the crypto industry versus how many developers out there. It would be actually nice if we could capture more people. The more people you have, the more things they can build. I think that blockchains are too complicated.

Smart contracts go in a similar direction. It makes stuff easier, but you need to still think, well, does my computation finish in a block? Does it not take too much resources? All these things which make it quite complicated if you're used to writing a simple Python script or Java script. I think we need to pick up the people where they are and not where we want them to be.

So that was the introduction. Now to the GEM building block. GEM stands for Join Exterminate Machine. It's a protocol written by Gavin Wood. You can find more information on graypaper.

com. Tomorrow, there's also a talk about it. I think the last one. The important thing for us here is GEM will provide 341 cores, and all of these cores can execute arbitrary code in a RISC-V-based VM. All these cores get the same security level as the base layer, so as GEM itself from the validators.

You will get also deterministic gas metering, which is important because with that, you can implement a continuation which enables you to write an endless loop because you can always stop the loop after some execution time and then always restart from the last point, which makes it much easier to write code. Also, another important topic is synchronous composability. GEM has all these shards. You can have infinite amount of shards. I mean, not really infinite.

That's an upper number, but verify 341 state transitions of all these shards. If you have infinite number of shards, if you only can progress 341, that's not enough. Also, you want to have that you talk between these shards. That's what the synchronous composability will enable you to do because you can take multiple shards and put them onto the same core, so they run at the same time, and you can talk to each other. What you, for example, have in Ethereum with smart contracts where multiple smart contracts can call each other, you could have the same on GEM on this core.

The nice thing is that the data is sharded outside of GEM, but you can bring it together and manipulate it together. Okay, now to copy. I copied this nice description on what an actor is from Wikipedia. I think the most important point here is these actors are like building blocks for concurrent computation. Basically, what we have, we have all these shards, which can run concurrently, and these actors are reacting to messages, so they either send new messages, change internal state, or create new actors.

There are a lot of things. That's a fitting model, I think. For me, the idea here behind Complay is it's a mix between blockchains and smart contracts. We want to get the properties of the performance of a optimization you can do on a blockchain, the block space you get on a blockchain, and more control over transactions and all these things. You can get this with these actors.

On the other side, we also want to give you all the ideas also to inherit some features or some properties from smart contracts. For example, the logic and constellation, if you look at smart contracts, they always do one thing, like multi-fig smart contract or proxy smart contract, while if you look at a blockchain, a blockchain provides a lot of things like multi-fig proxies and other things together, which again makes it more complicated and not so easy to stick stuff together and create a new application out of it. Like with these actors, we also hope that this logic encapsulation goes, that you just build smaller things, which can be used together with other stuff. We want to make it easy as you start and then complex if needed. As a smart contract, it's easy to use, but if you need more and need to drill down more, then you also get these kind of features.

Yeah, and we have like a minimal interface, or like the minimal interface requirements. Like there will be like maybe need to main function and like import like a function for sending messages and receiving messages. And that should enable like, and it's not only about like providing like a language, it's also like providing like a framework. So other languages could also be easily integrated into the thing, as long as it complies to this class, which should be almost all languages. Yeah.

And it's also like, as I said, like it's also the framework. It's also about like providing infrastructure because like you don't want to, like for blockchains, you don't want to run all these nodes and all this stuff that should be provided to you to make it easier to get started, similar to how smart contracts are working. Here I've written like a really bad example. I written some code, which should show like a little bit how it looks like in the future. Not everything of that is correct.

And also like maybe there are for sure like logical issues in it. So like, let's concentrate on like these only call ping functions here. So what we're seeing here is like that we call into an, like Ectos can export functions that you can call. So, and here we call, for example, this other ping. So like we call into another Ecto and want to call the ping method.

And this will tell the call place scheduler or however you want to call it. Okay. This Ecto wants to talk to this another Ecto. So like in the future I will need to run both at the same cross. So like that this Ecto can progress because like it wants a synchronous interaction between each other.

So by default, like the function that I exposed by these Ectos are like, assume that you want to have mutable access so that you won't have this interaction, like that you need to run both together. But that can also be like read only, read only functions, which then enables you that you maybe have one Ecto that you can still run somewhere, but it only do like a read only. So like it just reads data from its state and provides it back. And then another thing here is like what I call this wake me up in whatever thing is like the Ecto should have the possibility because like Ectos maybe react to messages, but also maybe they have some kind of maintenance work they want to do. And so they should pay the scheduler, hey, please wake me up in whatever, 60 seconds, one hour, whatever is required for your logic.

So like it's not only like reacting to like outset events, but also being able to like on its own being scheduled in the future. I have here like another example for like what I call a lock Ecto. So like you could imagine that like an Ecto, which is basically functioning as a lock. So maybe you have like another Ecto, which is a database or whatever, and you want to manipulate certain parts of the Ecto space. So like you would first need to lock it.

And it's a kind of free-floating Ecto. So like the idea is more that like, or you can call them utility Ectos. So they have no logic on their own, they have no messages or whatever. It's only that they're being used to other Ectos as in when talking to, only when talking to other Ectos. And here's the like, or here's the sorry, to have these read-only stuff, because like this one Ecto maybe wants to lock something.

And another Ecto then needs to know if the first Ecto has the lock. I have one here, this small diagram for it. So like in the case here, like the Ecto one wants to lock in Ecto two, and then it wants to call this changeX function. So changeX in the second Ecto again, hey, does this first Ecto actually have like the lock? And yeah, so like that's the operations that should be executed.

And here's like how you could do that, like how you could schedule this. So the first Ecto and the second Ecto are like, at the beginning are like scheduled together, because like Ecto one needs to lock something, like needs to mutable access to Ecto two. So both are scheduled together, it can get a lock and then the Ecto three is right now talking to another Ecto. And in the second iteration then, like as we have to lock, we need to go and do the modification. So like we have Ecto two and Ecto one and Ecto three actually schedule together as the same core and have like these read-only instance of Ecto two also running on core one, which then only provides like these, yes, that's the lock.

Okay, now to infrastructure for Ectos. Yeah, if you have a smart contract platform, as I already said, like you have like, you have all the nodes that run this blockchain and like if you want to interact with the smart contract, you send like a transaction to the blockchain and then like it gets applied in the block. For GEM it's a little bit different, because like these Ectos are validated in core, like outside of the block and you only like final state result to the GEM block. And GEM has no idea how these Ectos are working, how you can communicate with them. So you need to provide these transitions actually to GEM and not like only transactions.

All the other properties here, it's like when you have these Ectos, they maybe have state, maybe the status in the A layer or maybe the status somewhere out there or whatever, someone needs to take care and keep the data around. You also need to have this solver thingy that will be able to, okay, you have like these five Ectos and like some Ectos want to talk to his other and like other Ectos maybe don't need to execute now, maybe another Ecto needs to be executed in one minute and all these kind of things. You need to have a solver available that can, where you can like give it like, these are the requirements and it gives you like a work plan that says, okay, let's know what we do and then next iteration we do it in a different way. I also tried to show that here, like you have these users and like the users are sending like these transaction to these nodes and these nodes are then not like GEM nodes, but like these extra network of nodes for like for driving these Ectos and like then you have here like every node, like every time like one node, for example, is leader that does the work plan and then moves forward. Yeah, another thing that I think would be nice or like what we want to have then is like AWS for Ectos.

As I told you with these, like yeah, maybe Ectos can schedule themselves to be executed in like five minutes, 10 minutes or whatever. Someone needs to pay for it because like in the end, like you're still running on a blockchain. So like someone needs to pay for it and it would be nice that you, for example, you have like your Ecto and you can buy like these block space in advance where it gets like maybe like every 10 minutes or like one week of block space or something like that. And then like this amount gets always reduced and then it can maybe pull it up on its own or like people are paying for it or like it's like on demand either, for example, paid by users or paid by user, like you send a transaction by that you also pay for it or like on demand you're paying it for users and like to have actually like free execution. Yeah, that's it and thank you.

Thank you very much, Bastian. Thank you for everyone who already asked questions. Still have a little bit of time if you want to add a question, if you want to upvote some questions. But then I'll ask you the most upvoted question first. Here it goes.

Are actors tied to a shard? Yes, the actors are like what I call like shards in this jam view are like Ecto would be one shard. That was nice, quick. We have the next one here. Oops, I might have just put the wrong one.

You said you can run many actors on one shard at the same time. How many actors can be run on a core? What are the limits? I mean, that in the end depends on like the computation you want to do. So like you get a certain amount of computation per core, like you also get like memory, like data you can input and like you need to fit all this data together.

So like it's complicated to say what is the actual limit. Like if you maybe have like 10 actors and each actor does like 10 milliseconds of execution, then you can do 10 or 100 or whatever that fits. But if each actor is doing like complicated mathematical computations, then you cannot run 100. I found the question that I accidentally marked as answered. Why 341 cores?

33 by 11, but why? That's a question you can ask tomorrow to get. But I think it's because like we have 1,023 validators and like there's a reason I think with the data sharding or something. I don't exactly know, but you can ask tomorrow. Okay, great.

Yeah, Gavin is speaking at 5.30 tomorrow at the main stage. So you can take that question there. We have another one here. How can actors on different shards interact if shards cannot call each other synchronously?

I mean shards can call each other. Like if you want to have the synchronous interaction, you need to have one guy that like takes both of these actors and puts them together on one core and does the execution together. So that's the question, I hope. Okay, then we have this one. Can actors execute in parallel on the same core, given that they are not dependent?

Right now, not. Maybe in the future, but cores are right now like more like single threaded execution. So like what that would mean is actually like maybe you could just double the amount of cores and then like each validator, for example, runs these in parallel and then like it's kind of the same as running them in parallel manually or whatever. Okay, I think this will be the last question. Are actor nodes responsible for transaction ordering as well?

That's kind of the idea. Or like at least that you can give them like that you can get access to. For example, like the transaction, like the messages you want to do is like maybe you do like iterate over like the, you know, there's like 100 messages coming in and you just consume all of them and then like internally you order them in whatever way it fits your needs or something like that. So that's like a little bit blurry right now, but it should be possible to expose it in a way that you can do that. But by default,