Cartesi Agnostic Modular Execution Layer with Abdelrahman Omran

All right, a lot of light so I Yeah. Hey Denver, my name is Abdahman Omran. I'm leading the developer relations at Karte. Today we are going to enjoy a meaningful discussion together. So yeah, before we start, anyone heard about Cartisi before okay nice majority is not.

So that's why we are here. We are having like a core contributors from Karte. Please prepare all your hard questions. They love deep technical discussions. So yeah, first time to Denver and uh I really like the city.

I like people, the attitude, the vibes, everything. I don't like the weather, but yeah, everything else is really great. So yeah, first time to Denver and I'm very excited to be here with you at Eat Denver. Um so what what are we going to cover today? We are going to cover four segments about Karte.

The first one is going to be a high level very high level uh overview about Karte. What is Karte? What we do? what we are trying to solve and second we are going to go through a showcase uh what are real world examples that you can see that you can build uh on top of cartes what are the real use cases and next how does it work and then we are going to go even deeper and see how can we technically practically step by step built on top of cartes okay so yeah let's start with the first one so what I'm going to cover is the first highle Overview about cartisi. What we are trying to solve as cartisi roll-ups is two main challenges.

The first one is computational scalability and the second one is programmability. How we are going to change that or how can we solve this? How we are trying to fix it. Um before talking about how we are fixing it, let me tell you a quick story. It's about a banana not a blockchain.

I'm going to use a very basic metaphor. Let's talk about let's forget about blockchain for a minute and talk about banana. The banana doesn't have to be a 10 x just because there is a casino down the down the road opened and suddenly become very popular, right? And that's actually what's happening with the layer 1 blockchain. A lot of applications, a lot of users are competing for the scars limited block space, right?

And that's why everyone is competing for the same limited resources and with the popularity of Ethereum blockchain with the with the popularity of the layer ones basically the more dabs the more users comes to the layer one the more slow the more expensive it will be right so for an application to be viable for an application to be uh meaningful it have to hold itself in this war in this resource war between a lot of dabs. A lot of users using this layer one, right? And for that you will find dabs your new DAB that you deploy on that layer one competing with other popular DAPs. They are competing for the same resources. They are competing and bidding for the same resources for the same computational attention that node runners verify the network uh uh state.

So why this is a problem? We believe this is a problem because everyone is looking for a global consensus. Every single DAP, every single user is looking for a global consensus for everyone to verify the same transaction, right? And that's in our opinion, the more popular the network becomes, the more it becomes a huge problem. It's going to be slowing the whole network making it more expensive and at at the same time don't give the scalability that you need for your for your own web and by that like the network itself becomes gentrified and the innovation will be hindered.

That's why we are thinking about something that should be more scalable and that's what we are trying to solve. How we are going to uh to solve that? We are talking about modular blockchain uh architecture. how like it's a it's about modularizing the blockchain architecture that we that you have. We are talking about execution about settlement and consensus and specifically local consensus not global consensus.

So for Cartisi we choose to go away from global consensus. It doesn't have to be everyone in the network competing for the same resources and everyone in the network verifying every and each single action for every app. Right? So that's what that's why it doesn't make sense to have everyone in the network all nodes or verifiers validating all transactions at the same time. In our opinion, we believe that every user, every DAB should be verifying only the transactions they care about, the uh roll-up specific transactions, the application transactions they care about.

That's where roll-ups uh um that's where application specific roll-ups comes into play, right? And with that we are embracing the application specific concept. The application specific roll-up concept where your application will have its own roll-ups and the network of your own application only will be verifying that these transactions for your own dab with that we can have uh like we can open the doors for uh a lot of um like new generation of dabs. Just imagine that if you can have uh this flexibility and this scalability just imagine what's the opportunity that we can have here. So to recap this part to recap this part we are talking about cartisia as a rollup spec application specific roll-up solution uh that can run as a layer two on top of ethereum or as a layer three on top of our bitram or optimism.

So if you are using ethereum you can use cartisi to run on top of it as layer two. If you are using optimism for example as a layer two on top of ethereum you can use cartisia on top of arbitrum or on top of optimism as a layer three let's go back to the uh world computer analogy that some of us like talk about ethereum as a global or worldlet computer right uh we think about trollups as the universal computer something that's much bigger than uh the ethereum itself ethereum enables that ethereum gives us the uh the the foundations and this layer one you can think about it like a sun in the middle and everything around it like the a constellation planets revolving around this sun right and one of these planets could be cartesia like you can think about this as cartisi rollup about this as a cartisi rollup this is maybe something else another rollup and so on so that that gives us like more flexibility to build a faster more powerful and more sophisticated dabs on top of the Ethereum ecosystem itself. That's the first one. That's the first challenge we are trying to solve which is computational scalability. The second challenge we are trying to solve is the programmability.

Before we talk about programmability and what we are trying to solve here in details, let's talk about the software engineering in general. software engineering like it's been couple of decades developers and engineers have developed many layers of abstractions every layer on top of the other one and all of these layers actually hides the complexity and the uh information of the lower layer right you can think about it like let let's look at this diagram there is operating systems tools libraries uh compilers uh interpreters and so on all of these built on top of each other starting Starting from the base layer which is the platform architecture itself the operating system the low-level uh languages the machine code the highle languages and so on and on the top you can develop your own app using these highle programming languages. So why why we should go and reinvent the wheel when we are developing for the blockchain. Why not we can use all of these tools on the blockchain as well? Because it's already battle tested.

It's been decades for engineers that have been using it has been developing it and that's what we are trying to do. That's where what we are trying to do is just to bring the uh well tested tools like Python, C++, the Linux operating system and everything that it allows you to do with it. Right? And that's what we believe in. We are trying to bring Linux operating system on top of risk 5 architecture into layer 2 optimistic roll-up solution.

And with that you can just think about the opportunities that you can do on top of uh that layer. So with that we can say hello to Python C++. You can use your own datab decentralized database like SQL light or something similar. You can use uh Python to develop your uh DAB and to connect it to the smart contracts. You don't need to be limited to the limitations of Solidity or any of the existing development tools.

You can basically use any of the uh uh tools and uh languages that you already know and love and using uh and you are already using on top of Linux, right? So yeah, with that we we are saying hello to Python, C++, uh JavaScript, SQL and so on. This is a very quick example how can you uh develop a very simple dab on top of cartisia rollups. Most of you like you already have seen something like this. It's a P python script.

With three lines of code you can import any native or third party library in Python. If you are using Python to develop your own DAP, you can use any native or any third party library included into your DAB. And it's as simple as that. You don't need to reinvent the wheel. And that allows you to use something like image recognition.

Uh you can use machine learning. You can use any of these complex uh uh like uh uh technologies within your DAB. You you are not limited anymore to the limitations of the existing development tools. Yeah. So that comes to the basic question which is what is cartisi and what is cartisi exactly?

It's a general purpose roll-up solution. It's infrastructure for application specific roll-up solution. You can use it to develop your own DAP on top of it. If you are using Pyth uh if you're using uh Ethereum as your base layer as your layer one, you can use uh you can deploy your application using Cartis on top of Ethereum. If you are using Optimus, Arbitrum, any of these language uh uh networks, you can use Cartisi on top of it as well.

And it's uh EVM compatible. So you can deploy it anywhere EVM compatible. That's it from my side. That's a very high level uh overview about cartis. What is cartisi?

Let's go a bit deeper kind of like real world examples. Show us some existing dabs, some ideas that might give us some inspirations. Um also like if you need to know more, you can check the documentation on our website. You can hear it from other developers that already developed some uh dabs on top of Curtis. Uh and this is actually like you can scan the the QR code, you will find a YouTube list with everyone who developed on top of Cartezy.

Uh very inspiring uh uh like uh stories and also we are welcoming everyone on our uh uh discord server. You can reach out to me also on Twitter Abdraman Omran leading the developer relations at Kurtzi Omranic at Twitter and we are here for the full full event like these two weeks. Find anyone with this t-shirt myself, Carlo, Gabriel, Lino, Max and Zach. You will find us everywhere. Just find us, ask any questions and we will be happy to help and support you.

Thank you every everyone and uh yeah let's get it back to Carlo. the presentation. Yeah. Hey, how you doing guys? Uh, pleasure to meet you.

I'm Carlo. I'm from solution architect ati. I'm going to talk a bit about real cool stuff at least to me that was developed using our tech. Okay. Uh, if any of you guys have a question, well, feel free to make it.

Okay. So, how can we use Cartisi? Uh basically you can see Cartasia as something that enables you to do more on your web3 application. So you can further decentralize what's currently impossible. So we have multiple really cool applications that use the blockchain but uh the core of it is actually centralized and that's because you don't have the tooling or the processing power to do it.

We have multiple interesting games on web three and the really simple ones you can actually express them the game logic on smart contracts but most of the games that uh need a bit more of of context of processing they are actually centralized and they just use the blockchain for financial layer. So with Cortezi we expect uh to allow you guys to actually decentralize that logic as well. Uh also as Omron said we are bringing a lot of tooling that have been traditionally available for web 2 and with that we want to make sure that you can express yourself better on web 3 and that's also another reason why you should be using cartasi and uh you can tradition use all these traditional stacks and finally most of the developers they are not used to blockchain it's really a stipular learning curve right you have to learn lots of new concepts uh new VM new language everything. So if you can just use the stacks that you're used to web two, it's much easier for you to get on boarded on making an extra decentralized application because you're using the stacks you're already used to, right? So uh let's talk a bit about the applications themselves, what's being built.

So a first example that I really like, it's a game and uh this game is called Dinder. And it's a nice example of these kind of games that uh traditionally would just use the blockchain for uh NFT layer and things like that, but the actual logic would have to be decentralized. So what's dinner about? It's a mashup of a RPG game like Pokemon for instance and a puzzle like Angry Crush. So basically you have this battle in which you have your team, the other guy has this other team.

You say, "I want to attack this guy using this skill." And then you power it up by making a combo on a Candy Crush like shared puzzle. And then the other guy does the same. You can choose to either attack him really hard or to just mess up with the board so he cannot do his combo. You have your own strategy.

And it's a really nice game with complex logic. The game the game logic itself is written in Rust. And well, it runs inside the Cortez machine. So when you're playing Dinder, you don't have to worry about has someone tempered with this random number. He's doing too many combos.

I think he's messing up with a random number. Oh, well, I just hit him. I should have caused like 200 damage. Did he nerf my my character on the back end or something like that? No, you have transparency.

You can just run in your machine. You can make sure that everything is all right. If someone makes a claim that's incorrect, you can just dispute it and prove it wrong. Uh on dinner, well, they use characters as NFT. And it's a really nice game, so it's under development.

I think it should be publicly available soon. So they made this really cool Unity client, really beautiful with all the skills, really cool art. So it's a it's a nice thing to check. Another really cool application and this one is from Defi. It's uh this one was born at San Francisco.

It's Nucleus. So I'm not sure if you guys uh check this out, but uh now and then we have like a a DeFi hack for many reasons, right? And uh the nucleus guys they were particularly uh motivated by the mango hack. So not sure if you guys followed it but basically on mango hack you have this lending protocol and you can leave uh a coin as collateral and uh this guy noticed that there was a really low liquidity highly volatile coin that he could use as a collateral. So what he did he picked up $5 million he purchased it.

It pumped the price a lot. Then he comes to mango says hey I want 150 million stable coins or something like that and then well mango is a simple protocol that has limitations what they did went to oracle what's this asset price it was really high because it just pumped it okay so this coll is worth this much get it but it wasn't good collateral it's if you try to liquidate it it would be worth like 5 million not to 150 million so what these guys did is okay how can we help this kind of thing not to happen so they're leveraging the Cortez machine. They just feed it the prices for assets, the volumes and other relevant information and with that they just uh do a really nice analysis using numpy and python and they make a model of risk for any asset. So this asset no it's really uh volatile has low liquidity. If you try to liquidate a collateral over $10,000 you won't be good.

So this kind of thing would not happen. No. Now you're trying to use Bitcoin or Ethereum. great liquidity. It's awesome.

Yeah, you can like put $100,000, 1 million. Yeah, it's going to work. So, this is a really nice uh application in in my opinion. Another one we have that's really cool. So, in some places you use fingerprint reading uh readers for clocking in and clocking out for instance.

And in some locations, well, people mess up with it. What do they do? I don't want to work. So, I just sent someone from my team with a silicon finger. He clocks in and he clocks out from you.

And in these places, people start figuring out, okay, so people do this. Let's put someone watching them. So if they put a silicon finger, they'll catch it. But then uh something else happened. This guy started asking for bribes.

You pay me a bribe, you're there. You don't pay me, you're not there. So this guy had this really nice idea of making a DAP for it because generally web free applications are developed in a way in which uh the best way is just to cooperate and do the right thing, right? you're caught if you do the nasty thing. So what he did in here is he made this really cool application in which he has uh the input for it is your fingerprint and then you have a C++ program that will process it with OpenCV and extract features out of that fingerprint.

Cool. Now he feeds these features into a model he trained on Python and it will tell you this fingerprint is for real or no it was poofed like someone put a a photocopy of it or a silicon finger or anything like that. So I I really like this example because it use a lot of uh really complex libraries that have like uh millions of hours of engineering to become a reality and and to do really powerful stuff. Um, another game one, but this one is also has AI involved. So, not sure if you guys play chess, but I'm assuming that at least some of you.

So, chess uh has this problem in which people just uh cheat. They don't play. You open an online chess. They go in there and they open a computer chess. Whatever you throw at them, they throw the computer.

And whatever the computer does with his infinite knowledge and processing power, they throw back at you. So, you're not playing versus a human. your general playing versus a bot. So this guy uh he's from a community. He said, "Okay, so let's change the game.

Uh you can play as a human, but let's focus on I want to be a bot trainer. I want my bot to be the best chess player in the world." And that's his focus. So he he made this ultra chess game in Python. And uh that's how it works.

Basically, you submit your bot, you train your AI, you tune it, you improve it so that you're a king of the hill. And all the games they happen inside the Cortez machine. So if someone tries to tamper with the result or anything, you can just say, "Hey, this is not right." And dispute it. And uh it's a really cool game.

Um this one on the other hand has a web user interface, traditional JavaScript stuff, not unit. Another really cool application is one uh came from uh Indian guys if India. So there's a lot of problems in India uh with insurancees. Sometimes, for instance, uh it's it's different from where I'm from, but if you um have a car accident, for instance, they can deny you the insurance because you didn't drive in a responsible way, for instance. Okay.

Uh and there's not transparency in that. They will just deny you and say, well, you're you're a reckless driver and you don't have a say on that. So, what they're doing on here, they're trying to bring transparency to this and fairness. What they do is they built this on Python. It's a DAP in which it feeds IoT data.

So, uh most cars today have this OBD2 uh port in which you can get all the data from acceleration, braking, all the stuff and they feed this into a model inside Cortez machine and it processes data and they classify how good of a driver you are. So if you have your insurance denied, it's not because someone behind a a wall in an office is saying so and you have no say on it and it might be unfair. No, it's actually transparent. You can verify the data is in there. You can run the model.

You can check yourself. Yeah, you were actually survivor and that's why you you're denied the the insurance. So it's an example like a lot. Uh this one is really cool and still on this automated gaming. So these guys and um in a hackathon in Boston, they had this I I well I'm a sucker for old school games.

So I like this one. They basically ported this uh mugen like engine for fighting games made in go ekim and go and uh they call it from within Python and they have this automated fights with crazy characters. So, in this guy is the kung fu guy versus Pichu. But they have characters like tennis player or delivery dude. All the crazy stuff you can think of.

And before the game starts, you can wager on one of them. Then the fight happens automatically inside the Cortez machine. And then they pick up this fight simulation and they render a nice old school graphics video for you to watch what happened on the fight. Kind of like MMA for video game people. So I think it's really interesting and uh well again you got Linux so you can run this uh new gen like emulator.

You can hook it on Python for controlling it for making the the render video afterwards all this cool stuff. Uh this one is actually from uh Bogotaa. So uh generally when you have these NFTs uh the certificate of ownership is on chain. the content is generally not on chain and someone can swap your image because it's a link to a server or something like this. So these guys they had this really cool idea which they make procedure art on for these NFTs and uh they use this really cool patterns that are fractals using a mandle brought algorithm which is a really computation intensive algorithm and well uh they did it in rust they're on a Linux server with a lot of computational power so they did it and uh turned out really really nice results so this was one of the images they generated for instance and uh with this kind of NFT you don't own it but you own it and if you improve you have the correct art because it's generating inside Cortis machine if you want to retry yourself you just reexecute it and you generate and you see yeah I have the correct art uh this one is more traditional IoT so these guys are from Poland and what they did is they did this uh decentralized parking application so someone might be a city hall might be a DAO might be whoever whatever uh establishes the zones of parking and the rates and all stuff.

You park your car, you interact with this and say, "Hey, I want to park here for 2 hours or something like this. Anyone can just go in there and check out this guy has paid parking." Yeah. And he still got one hour stuff like that. Um they made a nice front end traditional with uh Google Maps all the stuff.

Uh and inside the cortis machine they build a logic using rust. They have a SQLite database for storing all this information, for putting the new rules like the new fairs, for checking out how many vehicles do I have, how many spots they have left, any statistic you might perform and that's really powerful because uh we all know that it's it's a real struggle to deal with data on the blockchain. It's expensive. You don't have much tooling for manipulating it. You have some things like the graph to help you out, but you have to pre-index data in a particular format.

So having a database on it, it's really powerful, right? And the front end was built in view. So yet another technology that you they choose to use on the on the front end. Uh we have many other examples. I was a bit worried about the networking.

So I did an addis but one crazy dude from our emulator team did something which uh as a nerd I appreciate. So will it run Doom? And yeah, he put real time Doom inside Cortez machine. So I think it's a really nice example of uh the things you can just do when you have a a Linux machine available for your decentralized logic, right? Uh if you guys got any ideas, got any doubts, want to discuss if your idea is viable or not, if it fits, kind of adjust the architecture, anything you have, well, we're here.

We're available and we'll be really really pleased to to talk to you guys. Okay. Um that's my part. you have a cure code in there for Discord if I'm not mistaken. So yeah, hope you guys have a really nice event and well have fun.

[Applause] Going to give it to my colleague Bahos now. Hello. Hello. Hello guys. Um, Gabrielle.

I'm lead developer advocate at Carteesi. I'm here to give you an idea of how everything comes together. Of course, by the end of this, you're probably going to still have some questions and some doubts. It's such a short time to explain everything, but hopefully I get you intrigued to talk to us. So a quick rundown of what I'm going to say like I'll go back to rollups app chains uh talk a little bit about the cartes machine how all of that is possible the importance of fraud proof in the system and by the end of it I'm going to show you a little bit the APIs we developed uh to make it possible for you to do your dab.

So rollups rollups are a stab at a blockchain trilmama. We all know that uh it's the SAB at scalability trying to improve the TPS computational power and by the end of it really trying to make it cheaper to process things right and the idea is to make it so that in a way that you don't compromise security and decentralization and the focus really is in computation expansion. Okay, what about app chains? So when people are talking about rollups, we like to go back here. It's a little bit what said before.

So on Ethereum network, you have this uh massive network where you add computers to it and you improve on security and decentralization. However, uh you cannot really expand uh its processing capabilities. Not really. Like we can strive to do it, but it doesn't scale really really well. But with app chains it's different.

So you have separate network like uh rollups where some computers might be um um pres present in two different uh apps but they are logically separate. What it means is if by any chance let's say that B is super successful it's not going to steal resources from the other DAPs. it's not going to do the network eviction that we've seen so far happening in Ethereum. So for those of you who are older in the space, you remember by 2016 2017, we had a bunch of games showing up at L1. But with the DeFi explosion, there was no games anymore because it's too expensive to do anything on a game and it doesn't make any sense.

So with the idea of having a DAP chain uh you are guaranteeing that your application is still going to stay healthy throughout time as long as people are interested in it and you're you're not going to be bound by what happens to the other applications that are using the same technology as you. So the ecosystem stays healthier for longer. Okay. What about the Cartazzi machine? So the computer you have right now it has one of these architectures AMD 64 IIA32 or even M1 from uh Apple right now and even your uh cell phone you have like a ARM processor this architecture is a they are very capable and very powerful they are so that they are enough for you to have an operation system running on it right and that's really good because that gives you access to a lot of resources uh you can have files, you can have network communication, you can have sockets, you can have a bunch of stuff that we forgot that exists when you're programming to the AVM cuz it's more or less like a very powerful calculator, but that hinders your ability to do things.

So in that sense, Cortezi used Risk 5 which is a open-source version for hardware. It's a open hardware architecture and we did an emulator on top of it. That means it's possible to run Linux and with that now you are able to run anything really on top of it. You still don't have access to the internet. That happens a lot.

People often hear about Linux on the blockchain and they're like, "Okay, can I connect to servers?" Not really because you're still bound by the blockchain data availability. However, now you can have access to files. You can have access to several types of databases inside. you don't need to uh reinvent the query language just to make sure like you can cross reference data that is stored on the hash table of Ethereum.

So that makes it much better to develop complex applications really and that also means that you have a very capable CPU that gives you abilities to do things that previously it was unheard of like you cannot really process an image you cannot really decrypt things you cannot really uh it's very limiting to program on solidity right now and that works because you can have fraud proof. So I told you that we did an emulator of risk 5 but that's not compatible at all with EVM not at first right. So what we did we actually uh ported the emulator as well for the EVM. So we have a set of solidity contracts that represents the risk 5 machine and any instruction that can be computed offchain can be computed onchain as well. So what we needed to do and we did is a process called verification game where let's say you are playing a game for a week.

Now it's finished and somebody is complaining something about the game. They're saying somebody uh is doing something nasty. You can just do a search a binary search basically on the uh whole process and find a single CPU instruction and put all the data necessary for that onchain. It's super cheap by the way and do one single CPU instruction cycle on chain and verify who's telling the truth. So it's very simple thing actually to verify the computation you did outside with all that thing that that we are just saying like with OS abstractions Java virtual machine if you want to databases and whatnot and this is kind of like how it looks like.

So you have a set of nodes here that includes the Ethereum node because we still need to have access to uh data. You're still bound by the data availability problem, but then you have other nodes from Cortez here and your front end any kind of UI really you connect using some of these uh endpoints and from within the Cortez machine, the Linux machine we're talking about, we created this API abstraction here that makes it much easier for you to integrate with the outside world. Let's take a look at the inside first. So from the inside we have that uh API I was talking about. It has just a a few endpoints that you need to know of.

The documentation is super nice for that. Uh first you you need to be u calling this endpoint over here that will tell that you're ready to process the next transaction. So this is still a state machine. So whenever you have a new input, a transaction, it wakes up, process the information, and it finishes. So it's a loop where you're always calling finish at the end to tell the system that you're done.

You're waiting for the next uh query. Now you have two main states of how to process this new uh information. So whenever you have Ethereum call for those of you who are uh more uh familiarized with uh JSON RPC from Ethereum basically you're waking up the machine to process something but you don't intend it to store it. You don't intend to have a straight transition. So that's why we have inspect state over there.

So if you need to query about anything of the state of the machine, you can just call inspect state from outside you're going to see that and from with from within the machine you need to be um aware that the machine is going to revert. So let's say you have a counter there. Whenever you have a call, you add one to it. That thing is always going to be zero and end at one. You can't change state when you are in that uh particular uh set of of of the state of the machine.

Then there is advanced state. That's just like a normal transaction on a VM. that happen that that means that you need to be caution uh to have caution because if you break your DAP if you break your contract might be a Python contract might be a Java application acting as a contract but if you break that then your DEP is gone just like the EVM and then you had the three main types of outputs out over there so let's start with the simpler one add report so when you add a report it's basically an ephirmware information is like logging uh information in your application. It's something that is only going to show on your node. Uh of course, if people reproduce the same code as you, they're going to see that as well, but it's not tied to the state.

Then you have notices. Notices are like Ethereum events, but with a special uh twist to it. So an ERC20 transfer uh uh how to say uh it has an event to it that you can uh verify by running the Ethereum node. But if anybody gives you the payload of the event, you cannot verify that that's true unless you go back to the transaction that created it and verify by running it again. However, notices here they have a Merkel proof to it that is tied to the state of the ruleup.

So whatever information you get from a notice, it's just a string really of data. You can verify the uh veracity of it uh by having the worker proof to to that. So it's an Ethereum event with a special touch to it. And finally, we have a voucher. We call them vouchers because uh rollups, they need the 7-day window of um fraud um detection and so people can open disputes.

So you can only do transactions really once the state is settled and people agree that there's no changes uh going to happen anymore. So you create vouchers basically transactions and people can claim this those vouchers once the state uh is finalized. Uh so these are basically um this endpoint is basically the way you're going to interact back with the Ethereum network. So, somebody uh wants some tokens and they need to withdraw. It's going to be our ESC20 transfer voucher that they're going to claim later on.

Okay, these are from within. These are what you need to know when you're writing your contract. From without there are the APIs I was talking about. Let's just go back there for quick. Um the JSON RPC and two APIs for the Ethereum node over here.

The JSON RPC is basically for the data availability. So you call on a contract a rollup contract on Ethereum the function add input. It's basically just to register information going inside the rollup uh ecosystem. Uh it's not going to do anything really. It's just so we can agree on the information there.

Uh that that is what have been doing for us in auto rollups by the way. uh so you have as a comparison and then you can query outputs from the graphical API you the outputs are the reports notices and vouchers I was talking about earlier so whatever you produce from with inside that's how you get from the outside using the graphical API finally you can have the inspect state basically you are free to do with that whatever you want so you can register sub um routes to the inspect state So it's from with within the application you define those. So you can really do something like a REST API if you wish to do so and those are going to come as a high level inspect state API call from what from the outside and finally you can execute voucher the thing I was talking about. So whenever a voucher is already valid and settled, you can just call execute voucher. Then a new Ethereum transaction is going to happen coming from the rollup address inside the Ethereum network.

I know it's a a bunch of stuff, but we're going to have uh five to 10 minutes at the end of the presentation to talk about these and you can ask questions. So for the next session, uh Luna is going to go through a programming uh dep with you and you can just get your Linux cuz that's the best for this. Thank you. [Applause] Hi there. So I'm Lo from Solution Architect team.

And we are going in uh so we going just a quick uh quick start on how to uh uh get into cartesi. So uh now you should go to your terminal and your Unix environment works but uh uh we advise you to use gitpod there's a link on our uh g github repo. So uh in in this in this exercise we're going to run the apple python with a very simple example and we are then going to make some changes and see how it behaves and yeah so that's for today. So this will just clone the ripple build the cartesi machine and start the apple front end which is a web interface. So um so you just if you're using um uh gitpod is it would be automatically clone the the ripple for you but it's just you have to uh go to the rolex examples and the apple python example and then from them from there we'll build the image which contains your the apple python code.

So we use docker to set up all the environment and uh the first thing you have to build the the docker image with the kartazzi uh with the the echopyon code and then you can start the back end uh which starts all the the uh infrastructure for run the the python. has all the node uh the the part that reads the the state uh on the blockchain also the the what handle the information. So we just docker compose and and put all the the the the configuration files and it will run the deploy a local hard hat chain. So yeah, you can test everything locally and and then it takes a little bit of time to set up, but if you do this, it's in a couple of of of seconds it should work. And then uh to the front end you just change the directory to start a new terminal in to the echo front end.

You have to install the dependencies. All of these uh instructions by the way are on our our GitHub hero of Rolex examples. So we have to uh use yarn to get all the instructions all the dependencies and then you can start the front end. So by now uh you can uh it will start the the the web interface and you can uh send the transactions on the other sides the all the the the carti rollups node that what they are running. So the hard hat hardhead local chain the the the inspects uh the the the inspect server the graph call all those interface that Gabriel said and you can see the that it it reads the the state of the local chain and then gets the the output from the graph So yeah, when it reads you you will get the response.

So one thing that's very important when you are developing with cartesi since it start starts a whole environment using using several docker docker uh containers it's important that you stop and uh remove the the the volumes and the containers otherwise the volumes won't be removed and we'll have a uh you have old old uh information on side. So you every time that you do you have totrl c it and then and then you have to uh stop the containers with docker compose down dashv v. So now it's a control c and then you have to just put down v and stops and removes everything else. So now we are going to we're going to make some changes to the alopyon and then we're going to see uh how it behaves using a a console version of the front end. So yeah just just make a simple change.

We're going to make change how how the how how it the answers. So now here I'm copying some uh some of the the functions. So all the informations that when they get inside the cartis machine when you going to process they come as a hex uh hex encoded. So in order to change and to to see them as a strings you should uh decode it from hex. So that's what I'm doing here.

And then we're going to change the string and see what happens. So, and now we're going to change and add a little uh change the string there. Then we have to hex encode it again. So, K vehicles. Yeah.

And for we have to do the reverse when uh we are outputting the the message. So I have to uh encode as a hex as well and then you have to started again the the the back end and you have to rebuild since I changed the code I have to rebuild the the cartis machine uh with the new code. So it's just run the same command that we ran using the the same uh docker build x bake load should be uh fast since it's small change just to put the the new the new code there and then we can uh just after we can start again the the the the roll-ups framework Yeah, it's just start and yeah, it should be ready to go. Now, we are going to test the the test the changes with the front end console. So, we go to the front end console.

It's uh this one is more uh general for for you to interact with the application because you have several other commands inside. So uh if when you're developing maybe this one's better and then we you can build the the beautiful framework using web interface and everything that you want. So just uh yarn start and do the send an input to the rollups framework with the payload and you can uh you can see put where anything that you want it will convert to to hex to put inside the the the to the the local chain. just send another one and then we can check the changes. So just list this notice list and you can see the K vehos hello.

Yeah. So this was uh just a quick presentation on how how it works. We have a other interface that you can test like the vouchers, the all the the all the other languages and you you can always come to see us and if you have more doubts on how to build we will be available. So yeah, you know we have we got some time. So guys, uh any questions, doubts, suggestions, uh anything?

Okay. Of course, I scared, right? Okay. I asked a billion questions so maybe there will be a lack of context but um okay I guess my my main question is how does when you when you have uh application based uh validation and uh nodes how do you reach consensus on global state things like tokens okay so basically uh as we said we have this platform in which you can deploy your application specific specific roll up wherever you want. So the resources that you put in it are associated with the underlying chain.

So if you're running on Ethereum, you will be handling with Ethereum STS this kind of stuff and uh those leave on the underlying chain for their consensus all the stuff on our level which is the cretis level. Uh what happens is that you don't need local consensus. So it's not like I have 10 people validating this application. If six of of them want to do something nest, they will do it. That's not how our security works.

The way our security works is you need to trust that at least one validating party will enforce the correct result. And why is that? Because the way our system is secured is when you have someone that makes a claim on chain, they basically pick up the cartiz machine state and they built a Merkel that index it and they put it on chain the root hash and they say at this point this is what I got. any of the validators will do the same stuff. they will check okay do I have the same root hash as this guy claimed yes nothing to do it's an opport roll up if not then we have a dispute and how do we settle the dispute we have this protocol called verification game which uh is being used for other projects as well but basically what happens is the cortisic machine needs to be deterministic so I can reproduce computation so if I'm not agreeing with you it means that at least in one point we did something different the protocol identifies what's this first point what's the first instruction of risk five execution in which I had the exact same state as you but after doing it it can be sum sum two numbers or subtraction or write a value memory any instruction after that we don't have matching situations anymore that's the first part of the protocol and the second part is well we had a huge effort on implementing a cortis machine emulator on chain so once you reach this single instruction in which you don't agree then you're actually being secured by the underlying chain that instru instruction is executed by its own chain emulator.

So if it's Ethereum, it's going to be thousands and thousands of nodes and they're going to have the consensus on this is the hash of the Cortez machine after executing the single instruction. So you're right or you're wrong. But it's not those 10 validators or 20 or 30. It's actually the entire Ethereum community or whatever blockchain you're using saying you're right or you're wrong. Okay.

Um I hope I I I answered your question. Not sure. Yeah. Uh, keep trying. So, but if anyone else wants to ask something, sure.

Yeah. The just hold on for me a second. So, um, when it's um the consensus protocols running in the Cartezi machine, is it um across all like the Carteesi rollup across all of Cartesi machines or only on the app chains? Uh, okay. So u as we said the the point is that how can we uh remove the constraints on processing.

So I have a computer it only has so much processing power. If I try to validate everything that's going on either everything that's going on is going to be tiny or I'm not going to validate everything. So the way we chose was okay so you choose what you're validating and uh a cartezi node only validates a single application that you're interested in. So this cartisian node for this specific application will look for this special smart context of our framework and there are certain transactions they will look for like there's a new input for this application. Okay, I'm going to react to it.

I'm going to feed it to microiz machine. I'm going to step on it and when someone makes a claim do I have the same hash? Yes, I don't have to do anything. I don't then I'm going to interact. uh in the logical sense you can be a single validator because uh you're a validator giving your address but physically you can have a cluster of machines.

So you have a server that's validating a single application that's really demanding. Then you have another server using the same watt. So you're the same validator but it's validating much lightweight application. So you have can have like five or six applications. I I have a really high uh volume game that's pumping lots of users.

Well maybe I would need like a really a really large server just for it. So uh it depends on the application in the end. And again uh since you don't have to validate everything you choose to be a validator for application or not uh you can manage your resources. Okay just to follow up on that like if um you have like two different DAPs running on uh a certy so um what prevents like uh like double spending let's say of some token on like both. Okay so that's a great question.

So what happens is uh the execution environment is sec machine itself. So for your adapt the reality is what's on that Linux server of yours. Uh how do you interact with the outside world? So basically uh in the framework there's a special smart contract called the portal. And what's a portal?

The portal is a bridge for assets. So whenever you interact with the portal and you deposit some asset like uh let's say you're on Ethereum and you deposit ether you get a special input on the Cortez machine to handle that's going to say hey X deposited Y ether handle with it. You might save it on a database you might award him a token because he was purchased a token uh an item whatever it's up to your logic but that asset is in that portal and that portal is from your application. Now you say okay great so we have a a way in what's the way out so as Bah has explained one of the possible outputs in the cortez machine it's called a voucher and what's a voucher the cortez machine needs to be isolated because it's deterministic so you cannot directly interact with internet uh or blockchain or anything like that but still uh it's interesting for you to interact with the blockchain so that's what vouchers are for so basically you you set the transaction you want to execute you cannot execute yourself but you pack it on this voucher and then someone on the outside can enforce it. So they submit this voucher into the framework and the smart contracts will check things like okay so this is going to transfer for instance uh epher from the portal to you because you you're allowed to withdraw five ether or this NFT or some resource and that's where double spending comes in.

So how do you make sure you don't have double spending? Okay, the answer is the voucher can only be submitted and executed once that computation is final. So it's a roll up uh it's a roll up solution. So once you roll up the state, you have dispute period. There can be disputes, there can be no disputes, but after it's settled in that moment, you have a proof that's generated associated with with your voucher.

And that proof is validated by the framework when you try to execute it. So if you try to execute a voucher that uh it's not final yet like I want to withdraw this item. Yeah. But uh you cannot because uh it's not final that you are awarded this item. It's still in the dispute period.

You're not going to be able to do it. Another thing is okay. So I have this voucher. I submitted it. I'm going to submit it again.

You're not going to make it because these smart contracts also keep tab on the vouchers that were already executed or not. So you have all these validations to make sure that when you execute a voucher, you're actually uh entitled to doing that action. It's valid. No one submitted it before. No, there's no doubing anything like that.

Okay. Thank you. Awesome. I have a question about timing. Sure.

Um you have two virtual machines executed by two miners or what? Two Mhm. say they're executing the same instance. Now an event occurs and the event somehow crosses over to the virtual machine. How do I know that both of them get the same event at the same time?

So in the physical world time it it will probably not be it but uh the point is that every input that goes into the Cortez machine is uh ordered by the blockchain itself. So inputs to the cartis machine they come through the blockchain. So in the framework there's a special smart contract uh that has a method called add input. So all the inputs that go through the gro machine come through this add input except for portal ones because they're another one. But once again the the blockchain itself is the one ordering events.

So you know that you have a deterministical order on the inputs and different instances of the Cortis machine, one running on my machine, one running on yours, won't have different orders of events or won't have different inputs available. So that's what guarantees uh that we have the same inputs. So all of them stop. Yes. And they're stopped.

When an input happens, they go again. Yeah. Yeah. Okay. Got it.

Got it. That that wasn't clear. But what happens inside the Cortez machine is you have basically an iterator on your software. Whenever there's a new input available, it wakes up the Cortez machine and you get the next thing. You process it and then you say, "Okay, this is the result.

It's good or it's not good. Refuse it. And when you do it, the Cortez machine stops and it stops until there's something else to process." Okay. Yeah.

Like like the VM basically. Um, so we still got time if you guys have some additional question maybe question. I have a question. Huh? Can you run zero knowledge in cartisi?

Uh, yeah. So good question. So we have this fight about zero knowledge versus optimistic. Uh, in my humble opinion, uh, it's not a good fight because there are different tools and they have different properties. Sometimes it's better to use one the other but uh yeah answering your question.

So for instance one of the applications we made a while ago was a poker game and uh to to my best knowledge it was the first truly decentralized poker game and how did we achieve it? So poker has some very interesting properties like I want to fold. I don't want to reveal my cards, but at the same time, uh if I bluff or anything and I try to cheat on which cards I had, u I gotta be caught, right? Because you got to enforce the correct result. So for this specific problem, for instance, uh we actually use zero knowledge.

So it's a Linux server, you can run stuff. So we had this really nice uh German researcher that does a lot of research on menthol poker which is the model we implemented and he built a C++ library that actually implements zero knowledge proofs to handle some of the the problems involved in this and we just use it. So C++ library import it run it. So we have this cartis application that's a optimistic rollup solution but yeah we're making use of zero knowledge to solve a particular problem in which it makes sense to us which uh basically you you still you have a way to prove that you had that card but if you just fold no one knows what you had and yeah zero knowledge was the answer for that. So questions.

Yeah. Well, uh I think we're good. Thank you very much for all the attention. Uh your time is precious. We appreciate it.

Uh don't feel embarrassed or anything about talking to us. Uh we're really approachable, I guess. And uh I'm really excited about seeing what you guys are building. Uh all these things I showed up uh most of it is from hackathons. So it always blows my mind uh how creative you guys can get.

So yeah, good luck to everyone and uh let's chat. Byebye.