--- title: "Cartesi Linux Appchains: When to Use Them" canonical: https://wavect.io/podcast/joao-garcia-cartesi-linux-appchains/ language: en description: "João Garcia on Cartesi Linux appchains, dedicated compute, Python libraries, verifiable AI and when Solidity is enough. Full interview transcript." image: "https://wavect.io/img/yt/EymrXnocoUI.jpg?v=aaa0b27902a0" --- Podcast Transcript # Cartesi Linux Appchains: When to Use Them João Garcia Developer Advocate, Cartesi When does a dApp need its own Linux execution environment? Cartesi developer advocate João Garcia explains how app-specific rollups isolate computation, reuse Python and other mainstream libraries, and support verifiable AI and games. He also explains when ordinary Solidity contracts are the simpler choice. This conversation was published in May 2025; research prototypes and release plans describe that period. - Published 16 May 2025 - Runtime 27:25 - Operator - Recorded in English ![Cartesi Linux Appchains: When to Use Them: podcast episode with João Garcia, Developer Advocate, Cartesi](/img/yt/EymrXnocoUI.jpg?v=aaa0b27902a0) // The short version - At 03:12, João Garcia explains that an app-specific rollup lets validators execute the applications they choose. Dedicated execution reduces competition with unrelated applications, the noisy neighbor problem; it does not remove every infrastructure bottleneck. - At 07:05, Garcia distinguishes booting Linux from merely compiling a language to RISC-V. A full operating system brings a filesystem and standard libraries, so developers can reuse more of their existing software stack. [Cartesi Machine documentation](https://docs.cartesi.io/cartesi-machine/) explains the execution environment. - At 08:36, Garcia separates verifiable machine learning from LLMs. He describes regression and KNN examples, cross-compiling PyTorch and scikit-learn, and experimental work on deterministic LLM execution. He presents research progress, not a production performance benchmark. - At 15:29, Garcia recommends keeping Solidity when an application does not need extra compute or particular libraries. He argues against rebuilding an ordinary token contract in Cartesi solely to use a preferred language. - At 23:20, Garcia says there is no silver bullet. Appchain interoperability still requires design work, and a coprocessor offers a different set of benefits from a rollup. His advice is to combine complementary protocols and reuse existing tools. [The Dave research paper](https://arxiv.org/abs/2411.05463) gives the fraud-proof design and assumptions. ## Why build with Cartesi Linux appchains? [Watch this part · 0:00](https://www.youtube.com/watch?v=EymrXnocoUI&t=0s) Kevin Hi everyone. Today I'm talking with João Garcia, developer advocate at Cartesi, a Linux-based app chain infrastructure that you can use to develop specific applications that are verified through a rollup. And the best thing about it is that you basically can use any general purpose library or language that you basically have available on Linux as well. So really exciting episode, a little bit techy as well. But if you're eager to build a new project or if you are on the lookout for great infrastructure, that's your episode. What are the three main reasons why developers should go for your platform for your solution? João Well, three main reasons. I think the first one is definitely empowerment. They are able to do more. They are able to use more tools, right? So they are empowered to create applications that are different than any other Web3 project. So you can use different tools like anything that would run on Linux would run on a rollup created using Cartesi, right? I think the second one is great support from community. We have everything laid out for everyone in our discord. Every contributor is active right there and we really provide great support for everyone. And I think the third one is honestly insurance and security. You are able to use the best fraud proof possible with our tools. We just developed the Dave which L2BEAT recognized as an amazing fraud proof. But besides that, everything that we do is open source. All of our discussions are in the open. Our developments are all in the open. So everyone can watch Discord and know what we're building. So I think everyone can trust that we're doing good for good and I think those are three good reasons. ## How do app-specific rollups avoid the noisy neighbor problem? [Watch this part · 2:17](https://www.youtube.com/watch?v=EymrXnocoUI&t=137s) Kevin Awesome. Awesome. So the vision is aligned with the end consumer with the developers basically. Like getting a little bit deeper on that. I mean that was already super helpful, but from a purely developer perspective, let's say I'm building something. What value do I hope to get from the tech itself? Why do I want to have this Linux based rollup approach over just having something else like smart contracts or even having whatever I would use otherwise? João That's actually a very good question. I think there are two main reasons why you would want that and we can split them. So I'm going to go first for point A and then for point B. Cartesi, what you do with our rollups framework is you create an app-specific rollup and that means that every person who's hosting a node that wants to run an application is running that application specifically. Of course there are mechanisms that we're creating for you to be able to run more than one application in a single node, but the core idea is still the same. You only host the applications that you want to. So you're not wasting resources running other applications and at the same time you avoid applications starving each other of resources. So in a shared rollup where every application runs in the nodes together, one application is consuming resources as the other. If one is getting many requests, receiving so many inputs, the other ones will be starved of computing power. So in our case what we end up doing is giving every application a full CPU in this sense. So no application is ever going to have a problem because of another one, right? Each application works and is independent. And the second one is Linux itself, which I think is a great reason, but when we just say Linux, people don't seem to understand what Linux brings as an advantage, right? There are many advantages but whenever you're running Linux, almost everything that was created for computers is created in Linux first. And okay, some games are probably not, but whatever service that you're running, that game is running, probably the server, the backend is running in Linux. Whatever bank software, whatever social network, the servers that run, that host the data, that hold the data, that host the processing logic is being run in Linux. So libraries like machine learning libraries, gaming libraries, mathematical libraries, all of that is made for Linux first. That means that everything that was created in the past can be used. So you're not stuck with just the libraries that Solidity has. You now can use libraries from Python, from JavaScript, from Rust, Go, whatever language you want. Code however you want using whatever language you want, of course. And that brings backwards compatibility in the sense that everything that was created works, but also brings forward compatibility in the sense that everything that will be created will work because everything will be created for Linux first, right? And I think that's awesome. And yeah, I think that kind of covers it. ## What does Linux add beyond a RISC-V runtime? [Watch this part · 6:11](https://www.youtube.com/watch?v=EymrXnocoUI&t=371s) Kevin Cool stuff. So, just to make sure I fully understand, basically app chains in general will solve the so-called noisy neighbor problem, right? You're basically separated from other independent projects and that as you mentioned yourself it's basically you are not influenced by the CPU usage or whatever execution they basically have to perform in any way. So that's the first advantage. The second advantage basically is well I don't need to learn a new programming language or something like that as well because I'm able to tap into the Linux ecosystem into general purpose languages like Python whatever. In contrast to lots of other app chains that are out there which often times have these domain specific languages. João Yes, exactly. Just to just to add to that something that I forgot mentioning and I think it's kind of relevant, right? We created this RISC-V emulator and put Linux on top of it. But the important thing, we could theoretically run the languages directly on RISC-V, like just compile them to RISC-V and run. But in this case we would be doing like some other protocols that do that. We would be running using the C language here, a freestanding language. So that means the minimum essentials just to run the language. But you lose some resources like having a file system, being able to deal with some standard libraries that allows you to process some information in different ways. So you get even more flexibility and more powerful by having an operational system inside there. ## Can Cartesi run verifiable AI and LLMs? [Watch this part · 7:57](https://www.youtube.com/watch?v=EymrXnocoUI&t=477s) Kevin I mean that's often times the issue right, when people or projects say, hey, you can use C++, C, Python, whatever, but then it's just heavily restricted. Yes. Right. So that's kind of a really cool thing if you really have access to all that, to the full ecosystem and that's actually quite impressive from technical perspective. One of the use cases that you have on your website, which of course is a hot topic, right, is verifiable AI. Would you mind sharing some light into that? João Yeah, of course. I think verifiable AI is a very nice thing that we've been doing for a while. But I also think that people overestimate a little bit what the word AI is because whenever someone say AI, everyone thinks of AI agents and they immediately think of LLMs, right? Because ChatGPT made all that noise and then DeepSeek and every everyone else, right? AI in itself is so much more than that. AI starts from the basic concepts of AI like linear regression, like KNNs. So there are many AI algorithms that we think about when we think about AI. So we started with these simple examples and we started by using some techniques because compiling libraries to RISC-V was not that trivial at first and now it is, but we started by doing things like KNNs, like linear regressions and we had to use a mechanism, a friend of mine did it, Marcos, shout out to him, called [model-to-code tool; name unclear]. So you basically transform the machine learning model into direct Python code and it worked fine. Then we managed to actually cross-compile the libraries from machine learning like PyTorch and scikit-learn to our machine. So you're actually able to fully use those machine learning libraries in RISC-V and Linux in our machine. So that's some cool things. Unfortunately though lots of those models like LLM they require an amount of resources that to be able to verify them you would need super hyper ultra computers if you want to or you would need GPUs, right? And then GPUs have the whole problem of being nondeterministic, so in a sense you would have to do some workarounds on that. At first LLMs sounded like something very complex to do, but we're striving forward in it and I think we're making some very good progress on it and in a hackathon, internal hackathon that we do with our developers with our contributors one guy called Eduardo who's like this amazing dev he actually found a way to run things in the Cartesi machine but delegate the complex computations just the matrix multiplications that you use on LLM to the host machine. So instead of using just one CPU, you use just one CPU for the emulated part, but you can delegate the deterministic calculations to the host machine, which is sort of crazy, but we basically improved by a bunch the processing power and now we are able to start running LLMs deterministically, which is also very awesome. And yeah, and we're studying that how we can make some progress in there. ## Which DeFi and onchain gaming use cases need this compute? [Watch this part · 11:41](https://www.youtube.com/watch?v=EymrXnocoUI&t=701s) Kevin Yeah, I mean building on the bleeding edge is always mostly research, right? That's just part of the game. And that being said, I'm curious like what other use cases are you currently exploring? Because general purpose basically means you can do lots of stuff, right? And I'm pretty sure there also some things maybe you shouldn't or can't do in some sense. So that would be interesting as well. João So I think I mean you mean general use cases inside machine learning or general use cases as a whole. Kevin Okay. What you are personally most excited about. João I think we cannot leave untouched the point of DeFi. Of course after all it's the world we're into, right? So there's a solution that I find really cool that's called DCA.Monster. So what it does is the dollar-cost averaging strategy for investment but it does with a minimum granularity. That means you get the minimum granularity that a token has which is like 10 to 18 or whatever and you start swapping the assets in very tiny batches. So you can basically say I want to exchange this one token to dollars or to USDT, right? But I want to do it in a matter of a month. So every second for that month you will be swapping that granularity part which is actually really cool and you wouldn't be able to do it otherwise if you didn't have a machine capable of performing this calculations to this level with this facility, right? So it's essentially an automated market maker that works pretty nice. And so this is a solution that I really find funny. And of course as someone who's a little geeky I really love games. We have two gaming solutions that I always like to mention. One of them is called RIVES. RIVES.io is the website and it's an onchain custom console where people can actually create games, sell games and play those games deterministically. It started by running Doom. So people would be able to play Doom, send the logs of their gameplay, so every instruction they sent to the game, to the blockchain and their gameplay would be verified. This is very cool for let's say speedruns for example for competitions for tournaments which is very nice. And then there is another one that just launched recently. It's called World Tycoon. So do you remember SimCity? Yeah, sure. Yeah. So we made SimCity on chain there. We just finished this grant. I'm actually evaluating it right now to do some code reviews, but it's SimCity onchain. You deposit your assets first and if you're able to start making money with your city, you can actually get the assets that other people deposited trying to make their city and in case they fail. So there is this whole dynamic with tokens on SimCity that turns to be pretty fun. ## When should developers use Solidity instead of Cartesi? [Watch this part · 15:05](https://www.youtube.com/watch?v=EymrXnocoUI&t=905s) Kevin Love it. Cool stuff. I mean GameFi is always a big topic, right, big part of blockchain, the crypto space in general. Are there some things that you think Cartesia is not really super suitable for? Like it's not ideal. João That's actually a very good question. So if we take applications in a vacuum, I think I don't see why people wouldn't want to use it, but I don't think people should be using Cartesi and creating. So if you don't need the processing power, if you don't need the specifics of, if you don't need specific libraries to run your software to execute your vision, then maybe you should just be sticking to Solidity, right? So Cartesi was not made for you to say, "Hey, I can do this on Solidity, but I rather do it on JavaScript, so I'm just going to write using Cartesi." That's not the intended idea. Of course, you can. Anyone can use the application however they want. But I think if something is simpler in Solidity, sometimes you just use it. There's no issue there. Kevin Okay. So it's basically more about educating developers and making sure that like if you want to build one of these standard Solidity smart contracts or something that is being built all the time, just follow the best practices there instead of some kind of reinventing the wheel with Python there. João Yeah, exactly. I mean since like the whole concept of Cartesi using Linux using all those libraries, is to not reinvent the wheel, right? Do not try to recreate extremely complex libraries for machine learning, for example, as you mentioned, in Solidity. Just use what you have. So use the rollup that will allow you to do that. Do not try to reinvent the wheel. And the opposite is also true, right? We already have some things that work really well for regular token creation, so do not try to reinvent the wheel, recreate this fully on Cartesi as well. I mean things are supposed to [unclear] together, not competing with each other. So use the best use case of each. ## What unusual games have developers built? [Watch this part · 17:33](https://www.youtube.com/watch?v=EymrXnocoUI&t=1053s) Kevin Like it. Like we have already talked about some interesting or useful use cases. Have you discovered or seen in your community any crazy or super funny ones like that you say, okay, I'm not sure if that's useful but it's an interesting one. João Sorry, what do you mean again? Kevin Like are you aware of any crazy solutions, use cases that people have built on your platform or is it just useful things so far? João Oh, no, no, no. There are some crazy fun things. There was this I love this one. I think it's not, I think it's not on mainnet anymore, but it was, maybe it is. It was a meme battle. So what people would do is bet on a meme. So we would have like [character name unclear] versus Sonic and you would simulate a fight of the two of them and you would actually see them battling each other and people were able to bet on their favorite fighter. So it was a little crazy and it was AI automated, so it was kind of like a zero player game. It was really funny and there was one that was so degenerate I think it's actually happening. It's called Bubble Wars where you invest some assets there and you become a bubble based on the number of tokens that you deposited in the application, right? And then you use onchain physics to move your bubble. So, propel it to some direction and if it touches another bubble, it steals the assets of that person. [Unclear]. And you increase, and your bubble increases in size. So it's really degenerate, but it's really funny. Kevin Wow, that sounds super painful. Like just imagine either you have collected that many and some of these big parent bubbles like as you have seen on I think it was called [game name unclear] or like what's the name of the original game? [Brief exchange about the game name unclear]. Yeah, crazy. Okay, that's indeed actually one I could imagine would be taking off if marketed properly, right? Because I mean that can be viral. Yeah, that's fun. Cool. ## What makes fraud-proof design difficult? [Watch this part · 20:06](https://www.youtube.com/watch?v=EymrXnocoUI&t=1206s) Kevin Like I'm not sure, it sounds like it, but how deeply you have been involved in the actual infrastructure itself, like infrastructure work. Can you share a couple of core learnings that you had during the initial development, right? Like what were some of the core challenges, what were or what are core challenges now to make this let's say more verifiable or whatever? João So I was not in Cartesi at the beginning because the idea of Cartesi I think started in 2018. That's when the first white paper was created, right? And I just came like two years ago. Okay. But from things that I've been learning now that I see them happening now and the team's working on it and struggling with it. I think the creation of fraud proofs was something that was very delicate, and very beautiful to see the way it was created, it was proposed. I think all the little things that you have to think when you're designing a fraud proof algorithm like the liveness of the chain, the amount of cost that you need to be able to participate that you have to stake to be able to participate on a fraud proof. All of those things being decided together until the algorithm coming together. It's crazy. So at first we had this fraud proof called PRT. We're we're launching a practical version of it real soon and we already have the paper for Dave which is like an improved version. But it was very interesting to see the struggles and the pain points that we found in each fraud proof and how we had to tackle each and every one of them. Gabriel Coutinho, who's leading the development of those fraud proof algorithms, he's been kind of explaining them to me as they were conceived and I was flabbergasted all the time, because every time they would hit a wall, but genius minds were actually able to break those walls, right? He would just tell me how the meetings go like, "Hey, Augusto, I just found a bug. This won't work." and Augusto who's one of the founders of Cartesi, would say, okay, I need some time to think, and go to the whiteboard, draw some things and come with a solution. It was just awesome. But yeah, I think that was the most delicate part. ## What are the limits of appchains and the value of modularity? [Watch this part · 22:42](https://www.youtube.com/watch?v=EymrXnocoUI&t=1362s) Kevin Love it. I mean, cryptography, if I can pronounce it, is always a super challenging topic, right? So I love to see that you have some cool team dynamics in your company. So I would have one last question for you. What are some three key takeaways you either from working at that project you had for yourself or that you want to tell developers to onboard or to use Cartesi. João Okay. So key takeaways. I think there is no silver bullet. There is not one protocol or one stack that you can use that does everything. So everyone has its limitations. Even if you think of us designing our solution, Cartesi also has its limitations, right? Even though you're running Linux and you can do all you can do in Web2, you have to go around some things. For example, if you want some degree of interoperability between rollups, you have to think well. So that's why we ended up creating other solutions like the coprocessor that delivers other benefits. It does not deliver the rollup mechanism but a fast finality coprocessor solution which is really nice. So I think the first thing is there's no silver bullet. I think the second thing is people who try to reinvent the wheel end up falling on the trap and they stay for so long trying to create something new instead of just using what's out there that they lose the opportunity of doing something that's actually relevant. Right. And the third one I think is protocols should work together. I think that's the most important thing. We had some amazing partnerships with [name unclear] to create our coprocessor, with Espresso, with Avail. And the solutions that come out of merging the knowledge of two different teams that are very good and specialized at some things, you can create something that's even cooler, right? So if you check out for example our integration with Espresso you can see that you're going to use our execution environment with their data availability and sequencing and create something that's very different than anything that everyone has ever seen. So pick whichever is best from everyone so you can make the perfect solution for you. Yeah, I think working together should be the motto of the ecosystem as a whole. Kevin I love it. Yeah. I mean that's the spirit of Web3, right? Like as people likes to say, it's all about community and building something that people really want. Yeah. Right. Exactly. Awesome. ## How can developers get started with Cartesi? [Watch this part · 26:01](https://www.youtube.com/watch?v=EymrXnocoUI&t=1561s) Kevin Hey, any last words from you? Anything that people should do after watching this session? João Yeah. Recently I got the feedback that we have really good docs. So try and experiment and play around with Cartesi. Join our community. Just even if you don't want to code, just join to see what's being done there, what is being cooked so you can learn a little bit more about it. And if you want to talk, if you have any doubts, just reach out to me on both Discord or Twitter. I'm there. And see you soon. Kevin Cool stuff. Definitely will put the links into the video description as well. And yeah, thank you again for your flexibility and your time. And it was really cool talking with you. Lots of new stuff that I'm really eager to further tap into as well. And one last thing for all developers here, all non techies, having a great documentation is so underrated. So kudos to you guys. Cool. João That's very true. Kevin Nice one. Hey, thanks man. Was great chatting. Have a great rest of your day. João See you. See you. Kevin Wavect, the Web3 software company that understands what you want. Prepared from the recording's English automatic captions, with speaker labels, punctuation and clear recognition errors corrected. Unresolved names are marked in brackets. The recording remains authoritative. Product plans and AI experiments reflect the May 2025 conversation, not a current production guarantee. // Keep digging [Plan a blockchain application→](/services/blockchain/) [Michael Heinrich on decentralized AI infrastructure→](/podcast/michael-heinrich-decentralized-ai-os/) ## Questions this episode answers ### What is a Cartesi Linux appchain? In this interview, João Garcia describes Cartesi as a framework for app-specific rollups with a RISC-V machine running Linux. Application logic executes offchain in a reproducible environment, while fraud proofs provide a way to dispute incorrect computation. The appeal is dedicated application compute plus familiar languages and libraries. ### How do app-specific rollups address the noisy neighbor problem? Garcia explains that unrelated applications on a shared rollup compete for execution resources. An app-specific rollup gives an application its own computational space, so another application’s activity does not consume that same execution budget. This isolates application computation; it is not a guarantee that settlement, data availability or hosting can never become bottlenecks. ### Can developers use Python and existing Linux libraries with Cartesi? Garcia says developers can use mainstream languages including Python, JavaScript, Rust and Go, and reuse libraries supported by the Linux environment. He discusses cross-compiling PyTorch and scikit-learn to RISC-V. Compatibility and resource requirements still need checking for the actual application; this is not a claim that every dependency works unchanged. ### When should a developer use Solidity instead of a Cartesi appchain? At 15:29, Garcia recommends Solidity when the application does not need additional computation or specific Linux libraries. A standard token contract is his example. He frames Cartesi as a way to enable otherwise difficult workloads, rather than a reason to rebuild simple Solidity functionality in another language. ### Does verifiable AI mean that an LLM answer is correct? No. In this conversation, verifiability concerns reproducible execution of a model or computation. It does not establish that the model’s answer is factually true. Garcia also distinguishes smaller machine-learning workloads from resource-intensive LLMs and describes deterministic LLM work as an experiment in the May 2025 interview. ### What is the difference between a Cartesi rollup and a coprocessor? Garcia treats them as different tools. A rollup provides an application execution environment with its own state and rollup mechanism. A coprocessor helps another application outsource computation and has different verification and finality assumptions. His closing advice is to choose the tool for the workload and consider interoperability rather than assume one stack solves everything. ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "In this interview, João Garcia describes Cartesi as a framework for app-specific rollups with a RISC-V machine running Linux. Application logic executes offchain in a reproducible environment, while fraud proofs provide a way to dispute incorrect computation. The appeal is dedicated application compute plus familiar languages and libraries." }, "name": "What is a Cartesi Linux appchain?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Garcia explains that unrelated applications on a shared rollup compete for execution resources. An app-specific rollup gives an application its own computational space, so another application’s activity does not consume that same execution budget. This isolates application computation; it is not a guarantee that settlement, data availability or hosting can never become bottlenecks." }, "name": "How do app-specific rollups address the noisy neighbor problem?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Garcia says developers can use mainstream languages including Python, JavaScript, Rust and Go, and reuse libraries supported by the Linux environment. He discusses cross-compiling PyTorch and scikit-learn to RISC-V. Compatibility and resource requirements still need checking for the actual application; this is not a claim that every dependency works unchanged." }, "name": "Can developers use Python and existing Linux libraries with Cartesi?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "At 15:29, Garcia recommends Solidity when the application does not need additional computation or specific Linux libraries. A standard token contract is his example. He frames Cartesi as a way to enable otherwise difficult workloads, rather than a reason to rebuild simple Solidity functionality in another language." }, "name": "When should a developer use Solidity instead of a Cartesi appchain?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "No. In this conversation, verifiability concerns reproducible execution of a model or computation. It does not establish that the model’s answer is factually true. Garcia also distinguishes smaller machine-learning workloads from resource-intensive LLMs and describes deterministic LLM work as an experiment in the May 2025 interview." }, "name": "Does verifiable AI mean that an LLM answer is correct?" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Garcia treats them as different tools. A rollup provides an application execution environment with its own state and rollup mechanism. A coprocessor helps another application outsource computation and has different verification and finality assumptions. His closing advice is to choose the tool for the workload and consider interoperability rather than assume one stack solves everything." }, "name": "What is the difference between a Cartesi rollup and a coprocessor?" } ], "speakable": { "@type": "SpeakableSpecification", "cssSelector": [ ".faq-question", ".faq-answer" ] } } ``` ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/podcast/joao-garcia-cartesi-linux-appchains/#webpage", "@type": "WebPage", "dateModified": "2026-10-07", "description": "João Garcia on Cartesi Linux appchains, dedicated compute, Python libraries, verifiable AI and when Solidity is enough. Full interview transcript.", "inLanguage": "en", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "mainEntity": { "@id": "https://wavect.io/podcast/joao-garcia-cartesi-linux-appchains/#video", "@type": "VideoObject" }, "name": "Cartesi Linux Appchains: When to Use Them | João Garcia Transcript", "speakable": { "@type": "SpeakableSpecification", "cssSelector": [ ".pe-takeaways" ] }, "url": "https://wavect.io/podcast/joao-garcia-cartesi-linux-appchains/" }, { "@id": "https://wavect.io/podcast/joao-garcia-cartesi-linux-appchains/#video", "@type": "VideoObject", "about": { "@type": "Person", "jobTitle": "Developer Advocate, Cartesi", "name": "João Garcia", "sameAs": [ "https://www.linkedin.com/in/jo%C3%A3o-garcia-b2276aa1/" ], "url": "https://www.linkedin.com/in/jo%C3%A3o-garcia-b2276aa1/" }, "contributor": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://github.com/wsdt", "https://www.wikidata.org/wiki/Q139796365" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, "description": "When does a dApp need its own Linux execution environment? Cartesi developer advocate João Garcia explains how app-specific rollups isolate computation, reuse Python and other mainstream libraries, and support verifiable AI and games. He also explains when ordinary Solidity contracts are the simpler choice. This conversation was published in May 2025; research prototypes and release plans describe that period.", "duration": "PT27M25S", "embedUrl": "https://www.youtube-nocookie.com/embed/EymrXnocoUI", "hasPart": [ { "@type": "Clip", "endOffset": 137, "name": "Why build with Cartesi Linux appchains?", "startOffset": 0, "url": "https://www.youtube.com/watch?v=EymrXnocoUI&t=0" }, { "@type": "Clip", "endOffset": 371, "name": "How do app-specific rollups avoid the noisy neighbor problem?", "startOffset": 137, "url": "https://www.youtube.com/watch?v=EymrXnocoUI&t=137" }, { "@type": "Clip", "endOffset": 477, "name": "What does Linux add beyond a RISC-V runtime?", "startOffset": 371, "url": "https://www.youtube.com/watch?v=EymrXnocoUI&t=371" }, { "@type": "Clip", "endOffset": 701, "name": "Can Cartesi run verifiable AI and LLMs?", "startOffset": 477, "url": "https://www.youtube.com/watch?v=EymrXnocoUI&t=477" }, { "@type": "Clip", "endOffset": 905, "name": "Which DeFi and onchain gaming use cases need this compute?", "startOffset": 701, "url": "https://www.youtube.com/watch?v=EymrXnocoUI&t=701" }, { "@type": "Clip", "endOffset": 1053, "name": "When should developers use Solidity instead of Cartesi?", "startOffset": 905, "url": "https://www.youtube.com/watch?v=EymrXnocoUI&t=905" }, { "@type": "Clip", "endOffset": 1206, "name": "What unusual games have developers built?", "startOffset": 1053, "url": "https://www.youtube.com/watch?v=EymrXnocoUI&t=1053" }, { "@type": "Clip", "endOffset": 1362, "name": "What makes fraud-proof design difficult?", "startOffset": 1206, "url": "https://www.youtube.com/watch?v=EymrXnocoUI&t=1206" }, { "@type": "Clip", "endOffset": 1561, "name": "What are the limits of appchains and the value of modularity?", "startOffset": 1362, "url": "https://www.youtube.com/watch?v=EymrXnocoUI&t=1362" }, { "@type": "Clip", "endOffset": 1645, "name": "How can developers get started with Cartesi?", "startOffset": 1561, "url": "https://www.youtube.com/watch?v=EymrXnocoUI&t=1561" } ], "inLanguage": "en", "name": "Cartesi Linux Appchains: When to Use Them | João Garcia", "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "thumbnailUrl": "https://i.ytimg.com/vi/EymrXnocoUI/maxresdefault.jpg", "transcript": "Kevin: Hi everyone. Today I'm talking with João Garcia, developer advocate at Cartesi, a Linux-based app chain infrastructure that you can use to develop specific applications that are verified through a rollup. And the best thing about it is that you basically can use any general purpose library or language that you basically have available on Linux as well. So really exciting episode, a little bit techy as well. But if you're eager to build a new project or if you are on the lookout for great infrastructure, that's your episode. What are the three main reasons why developers should go for your platform for your solution?\nJoão: Well, three main reasons. I think the first one is definitely empowerment. They are able to do more. They are able to use more tools, right? So they are empowered to create applications that are different than any other Web3 project. So you can use different tools like anything that would run on Linux would run on a rollup created using Cartesi, right? I think the second one is great support from community. We have everything laid out for everyone in our discord. Every contributor is active right there and we really provide great support for everyone. And I think the third one is honestly insurance and security. You are able to use the best fraud proof possible with our tools. We just developed the Dave which L2BEAT recognized as an amazing fraud proof. But besides that, everything that we do is open source. All of our discussions are in the open. Our developments are all in the open. So everyone can watch Discord and know what we're building. So I think everyone can trust that we're doing good for good and I think those are three good reasons.\nKevin: Awesome. Awesome. So the vision is aligned with the end consumer with the developers basically. Like getting a little bit deeper on that. I mean that was already super helpful, but from a purely developer perspective, let's say I'm building something. What value do I hope to get from the tech itself? Why do I want to have this Linux based rollup approach over just having something else like smart contracts or even having whatever I would use otherwise?\nJoão: That's actually a very good question. I think there are two main reasons why you would want that and we can split them. So I'm going to go first for point A and then for point B. Cartesi, what you do with our rollups framework is you create an app-specific rollup and that means that every person who's hosting a node that wants to run an application is running that application specifically. Of course there are mechanisms that we're creating for you to be able to run more than one application in a single node, but the core idea is still the same. You only host the applications that you want to. So you're not wasting resources running other applications and at the same time you avoid applications starving each other of resources. So in a shared rollup where every application runs in the nodes together, one application is consuming resources as the other. If one is getting many requests, receiving so many inputs, the other ones will be starved of computing power. So in our case what we end up doing is giving every application a full CPU in this sense. So no application is ever going to have a problem because of another one, right? Each application works and is independent. And the second one is Linux itself, which I think is a great reason, but when we just say Linux, people don't seem to understand what Linux brings as an advantage, right? There are many advantages but whenever you're running Linux, almost everything that was created for computers is created in Linux first. And okay, some games are probably not, but whatever service that you're running, that game is running, probably the server, the backend is running in Linux. Whatever bank software, whatever social network, the servers that run, that host the data, that hold the data, that host the processing logic is being run in Linux. So libraries like machine learning libraries, gaming libraries, mathematical libraries, all of that is made for Linux first. That means that everything that was created in the past can be used. So you're not stuck with just the libraries that Solidity has. You now can use libraries from Python, from JavaScript, from Rust, Go, whatever language you want. Code however you want using whatever language you want, of course. And that brings backwards compatibility in the sense that everything that was created works, but also brings forward compatibility in the sense that everything that will be created will work because everything will be created for Linux first, right? And I think that's awesome. And yeah, I think that kind of covers it.\nKevin: Cool stuff. So, just to make sure I fully understand, basically app chains in general will solve the so-called noisy neighbor problem, right? You're basically separated from other independent projects and that as you mentioned yourself it's basically you are not influenced by the CPU usage or whatever execution they basically have to perform in any way. So that's the first advantage. The second advantage basically is well I don't need to learn a new programming language or something like that as well because I'm able to tap into the Linux ecosystem into general purpose languages like Python whatever. In contrast to lots of other app chains that are out there which often times have these domain specific languages.\nJoão: Yes, exactly. Just to just to add to that something that I forgot mentioning and I think it's kind of relevant, right? We created this RISC-V emulator and put Linux on top of it. But the important thing, we could theoretically run the languages directly on RISC-V, like just compile them to RISC-V and run. But in this case we would be doing like some other protocols that do that. We would be running using the C language here, a freestanding language. So that means the minimum essentials just to run the language. But you lose some resources like having a file system, being able to deal with some standard libraries that allows you to process some information in different ways. So you get even more flexibility and more powerful by having an operational system inside there.\nKevin: I mean that's often times the issue right, when people or projects say, hey, you can use C++, C, Python, whatever, but then it's just heavily restricted. Yes. Right. So that's kind of a really cool thing if you really have access to all that, to the full ecosystem and that's actually quite impressive from technical perspective. One of the use cases that you have on your website, which of course is a hot topic, right, is verifiable AI. Would you mind sharing some light into that?\nJoão: Yeah, of course. I think verifiable AI is a very nice thing that we've been doing for a while. But I also think that people overestimate a little bit what the word AI is because whenever someone say AI, everyone thinks of AI agents and they immediately think of LLMs, right? Because ChatGPT made all that noise and then DeepSeek and every everyone else, right? AI in itself is so much more than that. AI starts from the basic concepts of AI like linear regression, like KNNs. So there are many AI algorithms that we think about when we think about AI. So we started with these simple examples and we started by using some techniques because compiling libraries to RISC-V was not that trivial at first and now it is, but we started by doing things like KNNs, like linear regressions and we had to use a mechanism, a friend of mine did it, Marcos, shout out to him, called [model-to-code tool; name unclear]. So you basically transform the machine learning model into direct Python code and it worked fine. Then we managed to actually cross-compile the libraries from machine learning like PyTorch and scikit-learn to our machine. So you're actually able to fully use those machine learning libraries in RISC-V and Linux in our machine. So that's some cool things. Unfortunately though lots of those models like LLM they require an amount of resources that to be able to verify them you would need super hyper ultra computers if you want to or you would need GPUs, right? And then GPUs have the whole problem of being nondeterministic, so in a sense you would have to do some workarounds on that. At first LLMs sounded like something very complex to do, but we're striving forward in it and I think we're making some very good progress on it and in a hackathon, internal hackathon that we do with our developers with our contributors one guy called Eduardo who's like this amazing dev he actually found a way to run things in the Cartesi machine but delegate the complex computations just the matrix multiplications that you use on LLM to the host machine. So instead of using just one CPU, you use just one CPU for the emulated part, but you can delegate the deterministic calculations to the host machine, which is sort of crazy, but we basically improved by a bunch the processing power and now we are able to start running LLMs deterministically, which is also very awesome. And yeah, and we're studying that how we can make some progress in there.\nKevin: Yeah, I mean building on the bleeding edge is always mostly research, right? That's just part of the game. And that being said, I'm curious like what other use cases are you currently exploring? Because general purpose basically means you can do lots of stuff, right? And I'm pretty sure there also some things maybe you shouldn't or can't do in some sense. So that would be interesting as well.\nJoão: So I think I mean you mean general use cases inside machine learning or general use cases as a whole.\nKevin: Okay. What you are personally most excited about.\nJoão: I think we cannot leave untouched the point of DeFi. Of course after all it's the world we're into, right? So there's a solution that I find really cool that's called DCA.Monster. So what it does is the dollar-cost averaging strategy", "uploadDate": "2025-05-16T00:00:00+00:00", "url": "https://www.youtube.com/watch?v=EymrXnocoUI" }, { "@id": "https://wavect.io/podcast/joao-garcia-cartesi-linux-appchains/#episode", "@type": "PodcastEpisode", "associatedMedia": { "@id": "https://wavect.io/podcast/joao-garcia-cartesi-linux-appchains/#video", "@type": "VideoObject" }, "dateModified": "2026-10-07", "datePublished": "2025-05-16", "inLanguage": "en", "name": "Cartesi Linux Appchains: When to Use Them | João Garcia", "partOfSeries": { "@id": "https://wavect.io/podcast/#series", "@type": "PodcastSeries" }, "timeRequired": "PT27M25S", "url": "https://wavect.io/podcast/joao-garcia-cartesi-linux-appchains/" }, { "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/", "name": "Home", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/podcast/", "name": "Podcast", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/podcast/joao-garcia-cartesi-linux-appchains/", "name": "João Garcia", "position": 3 } ] } ] } ```