Kakarot Code Walkthrough: EVM Implementation and Audit Insights

Anie presents Kakarot's codebase, highlighting potential audit vulnerabilities and the transaction lifecycle in its EVM implementation.

### Code Walkthrough: Kakarot's EVM Implementation in Cairo
* 👋 Hello, my name is Anie, and I'm an engineer at Kakarot, here to present our code base and highlight **potential audit vulnerabilities**.
* 📂 The code base is spread across three repositories, with the main one being the **K repository**, which implements **KAK in the Cairo Zero language**, a foundational programming language for the **STET ecosystem**.
* 🗂 Additionally, the KR-SSJ repository contains specialized files, such as the "caran helpers" for operations that are **optimized in Cairo One** or **unavailable in Cairo Zero**, including three precompiles: **SHA-256, ECAD, and EOLD**.
* 🔄 The transaction lifecycle in Kakarot follows the **EVM specification**, and we test against the **Ethereum official test vector suite**, particularly using the latest version, **Cancun**.
* 🔑 The Kakarot account model employs **native account abstraction**, meaning all accounts are **programmable** and can implement **custom logic**, starting with an **uninitialized account** that initializes upon deployment.
* 📜 During transaction execution, we validate Ethereum-related parameters, such as **signatures and transaction data**, and execute the transaction using the Kakarot contract, which maintains an **internal registry of state changes**.
* 🔍 A notable vulnerability discovered involved under-constraint during RLP decoding, where the **length of extracted data was not verified against the input length**, potentially allowing **malicious manipulation**.
* ⚙ Finally, we utilize hints in our code to optimize expensive operations, allowing **direct value setting in memory**, which is **crucial for the efficiency** of our Cairo implementation.

### Understanding Prover Behavior and Memory Management in Kakarot
* 🔍 The prover has the ability to **fill memory with any value** during hint execution, which can lead to **vulnerabilities if not properly constrained**.
* ⚠ If a malicious prover executes a hint that writes an **unexpected value**, such as **1,000**, into memory, it can cause **inconsistencies and dangerous outcomes** in the computation.
* 📊 Implementing assertions on the values written to memory, such as ensuring they are **within the range of 0 to 255**, can help prevent these vulnerabilities by ensuring **correct computation**.
* 🛠 The development of test frameworks allows for **simulating malicious prover behavior** to verify that the code **behaves as expected under potential attack scenarios**.
* 🔒 Kakarot's precompile execution involves a class that defines helper functions, ensuring that operations like **recovering addresses** are executed **safely and correctly**.
* 📜 The Kakarot messaging contract facilitates communication between Ethereum L1 and Kakarot L2, converting user payloads into formats that can be **processed by the underlying system**.
* 💡 The interoperability protocol allows for **executing Cairo contracts directly from Kakarot**, enabling **seamless interaction** between Solidity and Cairo environments.
* 🔄 Effective state management in Kakarot ensures that any changes made during contract execution can be **committed or reverted based on the success of the operation**, maintaining the **integrity of the system**.

so hello, uh, my name is Anie. I'm an engineer at Kakarot, and uh, this is going to be our first code walkthrough to present you the code base and uh, showcase eventual sensible parts of the code base where they might be audit vulnerabilities. Um, so the first thing to know is that this code base, the files that are in the audit scope, are actually scattered across three repos. The main repository is the K repository, which is the one that I have open right now. This one is the implementation of KAK in the language Cairo Zero, um, which is the, let's say, old um, code um, programming language used for the STET ecosystem. Um, and because this language is, let's say, it's not legacy, but the new features are not necessarily integrated inside this um, language. There is also a part of the codebase that is um, inside the KR-SSJ repository. This is only used for um, some very restricted files and pieces of code that you will find in the audit description. See, you don't see

oh one second [Music] okay I can share the entire screen always the sh everything and then from time to time there is private information this should be fine okay yes um and so yeah the other is the kakur ssj repository which has a file called caran helpers that we use for various operations that are either optimized in car one or just not available in car zero for example um for the pre compiles we have uh three promiles that we're using the K1 classes 4 which is shat 56 ecad and eold and the implementation of the these ones are in the scope and everything will be in the audit description so let's come back to the krot repository and the first thing to understand is the life life cycle of a transaction in krot so as krot is an implementation of an evm retan Cairo it um follows the evm spec and we are testing our implementation against the ethereum official test Vector suit um we're using the latest four which is Cancun so all of our uh we Implement

most of the up codes from Cancun, with some differences in behavior compared to if here mayet, that are listed on the KR docs website, um, which is doc.org, um, and you have all information on kakra available there, um, yes, car Z is the version with hints, and we will talk about hints later, but it's probably um, one of the most interesting things that you can audit because there are a lot of risks of under-constraint computation when it comes to using the like the verifying improving properties of the car language. So um, let's start with an example of the life cycle of a transaction. So the first thing is we're going to see is the account contract. Um, when you send a transaction to, so first let me explain the kakro account model. Each star net has native account abstraction, which means that um, there is no distinction between externally owned account and contract accounts on Stark net. Um, everything is an account contract, and every account is programmable, and you can implement whatever logic you want. So what with done if we have implemented

um a default account class that defines rules regarding how to validate Ethereum transactions and how to process Ethereum transactions. And um we are using this account as transparent proxies. So actually um the first class, let's say involved in the execution of the transaction, is called initialized account. The reason why we are using this as a proxy is we have um two like we have one major um goal which is to be able to determine um to compute from the EVM address of a user what will be the expected StarkNet address that will be deployed on StarkNet. What's going to be the Stark address corresponding to an EVM address. And the computation is based on the class of the contract that is being deployed. And to ensure that all accounts have the same class even if we upgrade the implementation later on to bring on new features um all accounts are initially deployed as uninitialized accounts. And inside the constructor we're going to do a library call to the most recent class of the account contract class uh that initializes the

account and sets some storage variables required for future execution. And when we will interact with this account, we're going to fall back on the default entry point of the account proxy, which will delegate the execution of the code to the account contract class. So, the way things work is there is the Cal RPC that sends a transaction through a layer. So, to leverage paymaster mechanisms and to be able to sponsor transactions for our users, we are using a paymaster mechanism, which means the transaction, the socket transaction that will lead to the execution of the EVM transaction, can be submitted by an external relayer that has an Ethereum transaction signed and can invoke a function that is called execute from outside on the socket net contract that corresponds to an EVM account. So, let's say that Alice wants to send Bob one ETH. Alice will send a transaction to the socket RPC. The socket RPC will use a relayer to relay the transaction, and the transa

the relayer will call the execute from outside on Alice's um account contract, and the execute from outside will receive the um transaction data inside the call data field, and the signature of the transaction that is verified against uh the transaction data. So, we perform a set of various checks regarding either um Ethereum uh validations, like you cannot have, you cannot execute um a transaction like a transaction cannot originate initially from an account that has code. So, for example, this is one of the rules that is defined in the EVM specification, but we also have um some checks regarding like things we do not want to see, like a native multical. For now, we only allow one call per transaction and some various T checks um. So, the detailed transaction flow we can see later, but basically, we are sending a packed transaction data to for optimization purposes um, and we have to unpack this transaction data to be able to uh verify the signature. So, inside the account contract, we're validating everything um that should be um that is account-related. So, basically, it's like

checking that the signature matches the transaction data, um, and um, verifying that, yeah, just verifying the signature, basically. The rest of the checks are performed inside the C Core contract, and so when you send a transaction after you verify the signature, what happens is you make a call to the cak call contract, which contains the entire EVM, um, and you just send it, uh, the transaction data to execute, um. Any questions so far? We will question, okay, great, I'm good, um. So now we have successfully validated the signature of a transaction, and we need to execute that transaction. So the first thing is that we're going to apply our LP decoding to our LP encoded transaction, um. So we have different, we handle different types of transactions, for example, 1559 transactions, and we have an RLP decode function, um. And so, for example, maybe remember the specifics, but there was an issue found by Zelik inside the RP decoding function, yeah, yes, yes. Mainly, it was under constraint segment, so we were decoding the data but not checking at the end that the extracted length from the was

matching the length given as input of the function yes, and so considering the execution environment of stet code, this could be exploited by a malicious prover to basically um fill the memory segment with unwanted data, and that could Pro potentially alter the execution of the transaction. And there are some tricky tricky I mean in some places it's not so obuse because say when we want to unpack or to analyze an input area of data, the okay yes I was saying anyway that in some some part it's difficult to understand that sometimes you have a function to say analyze input bytes given by the user, and depending on the lens parameter for example, you you can early return a new segment, so you just allocate a new segment of memory, and then you return this segment instead of writing and defining any constraint on over this segment. And so this is every segment like that can really be freely decided, freely set by the prover, so this is this is to be understood that whenever you add the segment, you really

need to be aware of the fact that the pro may fit the segment as they want, apart from the places where you have food constraints. So, in case of an ear, for example, this is a segment with no constraint. This typically can arrive. Maybe we have still some errors like that, okay? So, this was the first notice about Pro-related issues. The full detail about these vulnerabilities is explained in the Zelic audit. So, if you want to check it, you can check it further, you can. Okay, so the Kakarot contract performs various Ethereum-related validations, for example, checking that the chain is correct, that the nonce of the transaction matches the one that we signed the transaction with, some validation and gas and things like this. And so, this is like basic EVM execution, like you could find in other clients like Geth or Rust. And then we just start executing the transaction. So, there are two main entry points inside the Cal contract. You have eSentRow and SignTX, and you also have eCall. The main difference between

these two is that e call you provide the uh unencoded transaction data like execution data. You don't need to sign anything because there's not going to be any state commitment. Um, the way things work on Stark net is that view functions can actually be triggered through a transaction and trigger a state change. And this is quite dangerous. So before execution, any view function that could trigger state change, we have to assert that it was indeed um a view call. Um, so yeah, these are the two main entry points uh and when the execution at some point the execution flow joints. So you can see that in both e call like the external entry point that is called E call and e s transaction, we execute the same call by calling the E call function. But when we execute a transaction, we have one extra step at the end which is commitments of the state changes on the stet state. Um, so during the execution of the transaction, kakr maintains an internal uh registry of all the state changes. So which contracts were deployed um, the transfers of uh value, the storage

Keys you have accessed and modified, uh, and things like this. And when you do it, when you finish the execution of a transaction, we have to explicitly commit all these state changes on the star and blockchain because that's, um, basically our database where we are going to store the data. So now, let's see, uh, the transaction execution part. Um, everything is handled inside The Interpreter um file, which just takes an environment and a transaction to execute and executes it. So, you know, two different kinds of transactions, either deploy transactions or regular transactions. Deploy transactions are going to lead to a contract creation, while regular transactions are just going to invoke a function or transfer uh some value. Um, we have the three main EVM data structures that are being initialized. We have um um I say modelization of a stack data structure using cro dictionaries, the same for the EVM memory, and we have our state data structure that will be committed to stocket after the execution transaction. Um, so all of this is typical EVM behavior. I'm not going to spend too much time on

this is just about the dictionaries as well. This is a possible vulnerability to be checked. Every single dictionary initialized needs to be squashed at the end of the program, regardless of if it's dropped because, for example, the EVM transaction is failing. So, we don't want to commit the state changes, but still, all the created dictionaries need to be squashed to make sure that the prover cannot maliciously set false values at some point. So that, for example, then it changes the execution flow of the transaction and leads to revert. Res or it should not. The dictionaries and the wood are everywhere, and we really need to make sure that they are scratched regardless of the transaction status. So, yeah, and basically, if you want some trivia about why dictionaries need to be squashed, it's because there's no mutable data structure in the Cairo memory model. Everything is just a sequence of values that can only be written once to memory, which means that to simulate a dictionary, basically, what you do is you write a tuple of the previous key.

you are writing the value to what was the previous value and what is the new value, and every time you do an operation in a dictionary, you verify the consistency, um, that the previous value matches like the previous entry, this new value matches your entry preview value, and if your whole segment verifies this constraint, then your code is sound, and that's why you need to um make these checks every time you have a dictionary going out of scope, um, where are we now, we are at blah blah evm Run. Okay, so we've um made our initial um setups, and we're going to just run the evm iteratively until we have either a revert or an exceptional Hal or finished executing the bytecode. So basically, what happens is you Call Exec up code, you get a modified state of the evm, and then you just SC this function recursively until the end, and when you do an exact up code, um, so uh, there is some uh internals way we manage calls and uh, like contract gos and things like this that spawn a new evm frame with a

new context and everything, but um, in the end, everything happens in a flat way. Uh, which is when you make a call, you keep track of the context that was, uh, wait, let me just open, for example, the generic C function. Um, when you make a call, you're going to create a child EVM instantiated with the message to execute and some gas. You're going to copy the state in case the call reverses, and you're going to return this child EVM, which means every time you run the exec up code. Um, if the previous up code was a call, then the next iteration of the XC up code will be done on the spawn context corresponding to the contract being called. So, uh, in that case, for example, if you call Pre-compile, uh, you will be calling an address that does not have code. And if you call an address that does not have code either, you're calling an EA, for example, or you're calling pre-compiled. So, this is why when we do an exec up code, we first start by checking if the address is a

promile. I will come back and precompile later. I just want to finish the normal flow of execution first. So, we get the current opcode number from the bytecode at the index of the program counter. And then we have a few checks. Um, we charge the static gas related to the opcodes. So, in the EVM, opcodes have two ways, have two different gas models, let's say. They have some static gas, for example, a lot of opcodes take, for example, gas base, which is three or very low. And there is also some dynamic gas pricing, for example, copying words. Like when you do call data copy, it will be a dynamic gas that is based on the amount of words you're going to copy. So, in the EXA of code function, we just charge the static gas, and the rest will be charged during the individual opcode execution if there is a dynamic part. And uh, the opcode execution uses a jump table where we use the offset of the opcode to jump to the correct function. And here is the entire

definition so for each up code, you're going to jump to a specific function to execute the up code. So, for example, we can take the C up code as an example, which is ZX F1, this one. So, if the up code is ZX F1, we're going to jump to this offset here and execute the exal function. And here you see that we have the jump ends, which means once the exact call function has returned, we just jump directly to a label that is called end. Uh, so let's say we execute a call. The uh, when you execute a call on the EVM, you have some values that you take from the stack. So, that you have to pop these values out of the stack. These values, it's like the how much gas you're going to give to the coal, what is the destination address, the value you're going to pass, Etc. Um, this involves like calculating an eventual resizing of the memory and how much it's going to cost. Um, but also, uh, you have to check uh, if you load

a new account into the EVM. Um, you pay for the loading of the account in the cache, let's say. So, you have different components of the gas pricing of each opcode. Uh, so, for example, for the opcode, you pay the gas of the memory expansion, the transfer. Um, if you create an account, you pay for it, and things like this, okay. Uh, and every time, it's very important to notice that every time we do an operation, for example, charge gas. Um, we return and, like, we shadow the previous definition of the EVM variable because in K, you cannot have multi-layered data structures. So, every time you want to change one field of a type, you have to rewrite the type with all the previous values, and you change the specific variant field, sorry, of the type that you want to change. So, for example, when you're charging the gas, you have two different branches. Either you have enough gas or you don't have enough gas. And if you don't have enough gas, then you just return the EVM with a gas left of zero.

which means, uh, back here we have to explicitly shadow the previous definition of the EVM because if we were, for example, forgetting to do this, we would not have any compile-time error, but the EVM variable we're referring to in the next instruction, so here, would not be the correct one, um, so normally all there should not be a lot of issues regarding that, but it's good to keep this in mind, um, that you have to explicitly reassign the variables. Okay, so now let's say that we have created our child EVM, which is the new context of execution for the next code, um, we will just return this child EVM, um, and now we're back inside our big jump table and we just jump to the end label. So, uh, because when we do jumps, we do not keep track of where our, um, variables are kept in memory. So, for example, if you execute a symbol of code like a memory copy, you're not going to use, um, you're going to use the Run check pointer a certain amount of times. Let's

say nend times, and the Run check pointer is used to verify that your values are bound to a certain range. But if you execute the cop codes, you might execute the range check pointer on number M of time, and so the value of the pointer will be different um. And so every time you will see like low-level jump tables with call up like Cyro call up codes and Kyro jum up codes, you will often see right before right after this that we are manually casting values from memory with fixed index to some variables. So we are rebinding the variables to some offsets in memory. Let me explain maybe let's go back to our generic call [Music]. Okay, so when we are executing our call, the last value we return is the child evm. And the way this works in K is in your function definition, you see a lot of implicit arguments. So implicit arguments are defined inside the bracket um. This is the implicit argument uh. This is sorry the let's say the last the the first implicit argument push to

memory, which means that its offset is the furthest away from the current allocation pointer. So, when you return values from a function, you start by returning these implicit arguments, so ccle pointer, Pon pointer, and everything, and then you return the explicit argument. So, the last function return is that offset AP minus one, and then you just increase the relative offset. So, state would be at AP minus two, memory minus three, and Cal pointer will be at three, four, five, six, seven, eight. So, if I go back to our interpreter, you can see that c is indeed casted from the memory at set AP minus 8, and at AP minus one, we rebind the value for our currently executed evm. Okay, so this was the allocation pointer, but we also have another pointer which is called the frame pointer, which is related to the currently executed function. So, here you see that evm is our new context from the C, but we also have evm prev, which refers to the eventual instance of the evm that we enter the function with. So,

If you do a call, these two values are different. If you do not do a call, I mean in any case, these two values are different. But if you do a call, the depth inside EVM will be different from the depth inside EVM. FP minus 3 means that we took this value from, yeah, so FP minus 3 is the index of the last explicit argument, last argument, well, or last argument overall inside the function definition. So when you execute exact opcode at FP minus 3, you have the EVM, FP minus 4, you have state, minus five memory, and etc. Okay, so this was some trivia about the Cairo frame pointer and allocation pointer. So we have executed our Coop code, and we basically finished the execution of the op code, and we go back to our main run loop. Okay, so this was the typical execution process of an op code. Each op code has a different set of rules. For example, yeah, each op code is defined by very specific rules defined by the EVM.

specification and our definition like implementation of the up code is supposed to match what is defined in the EVM spec. We also have pre-compiled. So, for example, if you do a code to pre-compile, you will return an EVM context in which the address of the code is the address promile. So, next time you're going to iterate over, you're going to go in exec code, and you're going to fall inside this branch which corresponds to the execution of a pre-compile, which can be sorry, the execution of a pre-compile. So, pre-compiled, we have three types of pre-compiles. The first type of promiles is the regular EVM promile, things like EC ad, EC data copy, U like to F, like regular EVM promiles. We have a second type of pre-compile which is maybe, I think we have them here. So, the first iterum promil is at address one, and the last is at address 080A. We also have the rollup pre-compile defined in

a722, which is the verification of signatures over the SCP 256 r one curve. So, this is also EIP 7212, and we have a third type of precompile, which is pre-compile specific to Kak. So, let's first start about executing, let's say, regular pre- [Music] compiles. So, when we execute the precompile, we have the address of the precompile we execute, and depending on the address, we're going to jump to a specific label to compute the offset of the function to execute. So, let's say we call E recover, okay? We're just going to invoke the Run function of the E recover namespace. And this is where you can see some operations that we do to convert Felts to bytes and some memory operations. So, we have an input, which is an array of EVM bytes, and we want to transform this input so that we can call a Chairo function defined in the core library that will recover the Ethereum address from a message and a

signature. So, the first thing we need to do is, uh, to convert our by into U 256 values. So, this is where we fold. I'm sorry for the red. It did not set up my properly. One second. Okay, so we have some helper functions that allow us to transform different data into another form. So, for example, um, by 32 to Wi 256. We just take each individual bite and pack them into a u56 data type. Um, and some of these utilit. So, for example, some of these utilit are using a low-level chyo syntax. So, in Cairo, you don't have explicit loops. You either have recursive functions, or you can do, uh, jumps, or you just do jumps with specific values. So, we have a lot of um low-level loops using jumps. And, as I said previously, whenever you do a jump, you lo, you lose track of the VAR that you have in memory. So, you have to manually recast them. And inside these utils, I'm looking for one right now. We often use things that look like this.

which are uh called hints. So, hints are uh specific chunks of code that are inside a C program but not executed as KIRO code. Let me explain. When you're going to execute the transaction, uh, you're going to have uh two roles. You're going to have a sequencer and the pro, and the goal of hint is to execute operations that are typically expensive to do uh in Cairo but cheap to verify. So, yeah, if I may, if I may had, I would say that the goal of in is to set directly some values in the memory. So, it goes with the fact that KIRO is a readly memory language. So, actually, whenever you write Cairo, you don't write in memory. You define constraint on sum of memory cells, and the prover to respect the constraint will need to set the value of the memory at some point accordingly, according to your constraint. But yeah, so the ins are just a way to actually set set directly values memory, but it's also, it's important to say that it K is not a right one.

language. It's a readily language, and all the memories are returned, are written by the prover in a hint, either by yourself, like you do the hint, but the prover may not do the hint or whatever way he wants to find out the way to pass the con, yes. So, the prover indeed might not execute the hint, or he might execute something that you don't expect him to execute. Um, and there are some findings about this and the zelic issues. Uh, I'm looking for the most important one, um, to better illustrate exactly what the issue was. I think it was this one. So, you want to split a felt into an array of bites. So, what you're going to do is you're just going to take the current value, take it modulo 256 to get the bite, and then shift it to the right so that the lowest bite of the number is the next bite to the serialize. But let's say that you're doing this and you're not asserting some conditions, um, on uh, the individual bites that are returned. So, let's say you're doing

executing split word in the context of a malicious Pro. So, you're going to define your output array, okay? And then you're going to execute this hint. Typically, this hint is supposed to write in memory at the offset of the output pointer the value rest, which is the value taken modular Prime. So, Prime is the St Prime, and the resulting result is taken modulo base. So, this would be, that would be for example, let's say me modu, sorry 26. Um, okay, but let's say that your PR is actually malicious and just does not want to do the operation and writes 1,000 inside the memory. If you do not have the right assertions, then you're just going to write something to memory. So, for example, here your wrong value, which is 1,000, and then consider that 1,000 is the, and then continue your it by filling your BTE array with a value that exceeds the range of a b. So, if you don't have these assertions, you're going to have a memory that is filled.

with values that are extremely inconsistent and dangerous because a wrong prover could very well take the bytes expression of the value to transfer from an account A to an account B and completely modify this value to change the behavior of the EVM. But if you had a set of constraints on the computation done inside this hint, then you force the pro um, or you do not force the pro, but you are ensured that the computation and the transaction will never be validated because the prover cannot find a way to fill the memory with values um that would lead to an inconsistent computation. So in this specific case, if you assert that the um value you wrote to memory is in the range zero to 255 um, then you're pretty sure that the end result of this function will be correct because the assertions that you have defined on the computation are strong enough. So this is a strong potential vector of tax, and to test these we have developed check can find this. We have a way to patch hints, so for example, so we have a lot of tests uh

covering unit test covering our code base, and the interesting thing is you can simulate inside this test what would happen if a malicious prover was executing my code. So, inside this test, for example, we're going to execute, uh, one [Music] second. No, I was just looking for the exact same function. Okay, so never mind. Let's say that we want to test the F to by S function. We can actually replace the hint that is being executed during this test by something else. So here, if the value is a specific n that is parameterized, then we, uh, replace the, uh, hint with something else. And when we run this, we will see that, uh, if the hint has been modified to fit the values with something else, then the execution of this function will fail because our final assertion will trigger an error. So, for example, in the F to byes little um function, we split a felt into an area of byes in little andan, and at the end, we must verify that the initial value is uh the minimal one possible to.

represent this value and that uh it's inside bound of basically that it's inside the bounds that we have defined previously. And if it's not the case, then you are hitting an error because you don't want, because it would mean that the prover has filled the memory with the wrong values. So, the things to remember is the prover can fill the memory with any value it wants every time it executes a hint. And what you're doing is setting constraints on these memory cells to ensure that the memory, like if the memory is wrongly filled, then your computation will fail. That's why when you Rie, when you review the code and search vulnerabilities, it's, it might be relevant to just fold all the ins to not be influenced, like biased by the behavior defined in the in, because this Behavior does not exist at the Kyo code level. So, usually, I do this. You can just fold everything, and you don't read the it, and you just consider the chro Cod. Okay um, so let's go back to our precompile.

execution. This is where we finally get to the execution of Kyo one Cod. So, we have a special class declared when we deploy the K contract, which is a class that defines the helpers that are executed in K one. So, when we're going to do recover e add, we're actually going to do a library call, which is the equivalent of a solidity delegate call to this SC1 helper class. And, uh, we're going to call the recover e address function. So, in the K out ssj Cod base, we open the car1 file, and we see that recover e address is defined here and takes U 56 and the signature as input and just recovers the public key. And if, uh, the operation is a [Music] success, Returns the if address as the hash of the point [Music]. So, yes, so if you see a library code like this and you don't really understand where the code is defined, this is where the code is defined, and you can review it, and you will see that um, it's a whole

other whole other programming language. It looks a lot like Rust, um, and it has nothing to do with Kyo zero, especially. It does not have any, uh, it's a lot more safe by default because you cannot manipulate the memory at will with a hint, uh. You do not have the risk of having under-constrained data segments because, um, you always have the length, the actual length of your data segment matches its content. It's safe by default, so if there are any vulnerabilities, it's more in the code being defined and the logic of the computations being made rather than side effects like these ones. Okay, so the second type of free compiles we have is we question in chat. Do we have mutable references to avoid having to pass by value in care one? Yes, um, yes, but so you're telling with my example with the EVM, um, so for your curiosity, you can, so the Kard SSD repository contains an implementation of Kard in K one, but it's not a part of the scope of the IT and, but if you're curious, you can.

see how the roughly equivalent code was defined in K. So, I don't know if I can see an example. Perhaps we encounter an example, for example, on executing pre-compiles. Let's say we are executing the e precompile. No, actually no. I don't have an example to show here. But yes, there is the equivalent of imitable reference in Cairo, which is in the end syntactic sugar around the same mechanism that we have presented in KIRO Z, but which is made safe to the end user. Basically, you give value as input to a function, and you get it back at the end of execution. Okay, so we have the pre-compiled 256 verified, whose specification is done in the RP 70 to 2. Same thing for this. We're calling the verify signature on the 1 head plus class. So, same logic here. And we also have our custom homemade pre-compile, which are called K compiles. So, for some context, it is not currently at this date, 27 September, possible to catch an eventual fail inside a stet call. So, if

an evm call fails. You get the B memory result and the success. The success will be false, and if the success is false, you can manage this and do some proper error handling. If today a St transac call fails inside the transaction, the entire transaction is reverted. Problem for us, if the transaction is reverted, it can cause problems regarding charging the gas to the user because we could potentially relay the transaction of the user, and the user would never pay for it because his evm transaction would never be completed. So, we have a special weight listing mechanism for who is allowed to call this precompile temporarily until we can catch Cairo calls error and properly handle them. Uh, and we have two precompiles. The first and the simplest one is the K message. It sends the message to the L1 layer. So, basically, what it does is uh get the address of the L1 messaging contract and use the CIS so defined in the stet library to send a message to L1 with the payload, like with the input expected. So far, so good, and we also have

one that is a little bit more complex, which is the KIRO PR compile, and this is one of the most exciting features of Kakarot, which has an interoperability protocol for the EVM and Stet. This means that you can execute a Cairo contract or class from Kakarot directly, which means I can send the transaction to a Solidity contract that will do an underlying call to a KIRO contract, get some data, and return it back in Solidity. I will show a specific example of this later to illustrate this. So, inside this precompile, we do various checks on the data that is being passed to the precompile, and we have an is it [Music] yes, sorry here. So, we take the input data, which is serial bytes, and transform it into data types that are used in Stet to later on execute the Stet call. So, we have the target Stet address, the selector to invoke, and the data to pass to the function. The thing is that to preserve

the context of execution of this scod. So, for example, if you, uh, if you invoke this stet call from an Eva, let's say you want to approve the spending of a stn token from Kaka. So, from your EVM account, what you would do is you would call a Solidity contract that defines functions and logic, uh, around this approv, and that lets you approve the St token underlying. So, this is defined inside the Dual VM token contract. I will come back on this later to preserve the context of execution. We execute this stet call from the context of the color, the stocket address of the EVM color. So, if an eway approves a stocket token through, uh, Solidity contract, the approval will be made through the account contra of the color. And we have this execute stet call here that simply, uh, executes the Cod contract based on the address, the selector, and the C data. So, practical example, pragma is an oracle deployed on stet that provides price feeds for various assets. The pragma Oracle, um, is written in K one, and I will

need and has an entry point, which is get data median. So, you provide it with an um with some data about what exactly you want to query. Is it a spot entry, a future entry, and what is the um ID, pair ID of the data? And as a response, you get what's the price, how many decimals, when was it updated, and other things. So, when you execute this call, you are going to get this return data as wait. Let me show you the corresponding Solidity contract we use as an example. So, we have defined this Solidity contract in which we defined EVM equivalent data structures to represent the same data. So, for example, here we have the data type inum, we have the response type, and what happens is we have this Kyo lib Solidity KY solid defi that defines a few functions that help us call Kyo contract from Solidity contract. So, when I do a call Cairo, basically, I'm just encoding the call data and calling our Kyo precompile with this C data and returning the result as bites. So,

inside this pragma color contract. What I'm doing is I'm invoking the Kakarot Kyo precompile to invoke a contract deployed on stack net. I am formatting the input data into an expected format, into the data expected by the, in this case, pragma contract. I am getting the return data serialized as bytes, and then I am deserializing the bytes into Solidity data types that can be consumed by other contracts. So, this is fairly simple, and I can just use the Kyo lib, for example, here to do a static call to the Kyro precompile address and communicate with contracts deployed on Stet. That's it. So, this involves quite a lot of operations of preparing the input data into the right type, and then preparing the data returned by Stet and serializing it into bytes with various utility functions that we have seen earlier that might as well use hints for efficiency purposes. So, I think I've covered and learned pretty much everything related.

to the execution. Um, you think I missed something? Maybe the side, the contracts funnel one. So, inside the auditing scopes, we have a few solidity contracts as well. One of them being the L1 Kakarot messaging contract. So, this contract will be deployed on Kakarot L1, and the purpose of this contract is to be able to send messages directly from Ethereum L1 to Kakarot onet Kakarot L2. So, basically, what it does is it converts the payload supplied by a user that wants to send a message to a data type that can be ingested by the stet core contract that will process the message. And this will invoke, as you can see here, something called handle L1 message on L2. So, if I go to the C contract, I can see that my handle L1 message is here defined here and simply verifies that the from address is the correct one, so that only one contract is authorized to make these calls, to ensure that the input data is properly formatted, and then we handled the

message coming from L1 by executing some transaction data using like we would with a regular transaction and finally committing the state. Okay, we have the same equivalent on L2 to send a message to L1. This one is pretty simple. We just ABI encode the payload into bytes and call the K function send a message to L1, which calls our Cairo messaging address that we have seen inside the kakar promiles. Yeah, K message, and that just calls the send message to L1 C call to send the message to L1. One of the features we want to push forward is the possibility to deploy on K an EVM contract that is actually stateless and just defines wrapping logic around a stet EC20 token. So, you would be able to deploy this dual VM token with the initial that refers to stet token, so the address of a token deployed on the stet network. And then you define a set of functions that allow you to query and modify the state of this underlying tokens. For example, if I call name, I'm

just going to do a static call K. So, using our precompile system to the function name on the stet token deployed on the stet network. Uh, but I can also do state mutating changes. For example, I can approve an EVM account to spend uh some value on my behalf. Based uh, I can approve an EVM account to spend the stet token on my behalf. So, for example, what the typical process would be is first you get the address, stet address of the sender of the spender, sorry. So, for that you do a first call to the K out contract to get what is the register stet address for the EVM account you want to give the approval to. And then you would format the call data into the appropriate uh expected C data. So, in that case, approve on the stocket token takes three arguments: the spender, the low part of the amount which is a u 12 128, and the high part of the amount which is a u 128. And because we preserve the context of execution of who made

that call this will be routed through the K pile function, which will call the execute stet call on the account here, which will do a c contract to the stet Token we had registered inside our solidity contract. So, for example, this uh token we use for test and that will rely on the implementation of the erc20 trans standard to trigger call to the St to the approv function. And so, we have defined a set of utilit for this and it's uh quite um it's quite an interesting thing because it allows the evm side of stet through Kakarot and the stet side to manipulate the same underlying token, which means you don't have to fragment liquidity in Kakarot and you could use theoretically uh ubo n all the top Protocols of stet directly from Kakarot and from your evm wallet without interacting with stocket. So, stocket will be like the execution layer, but you would not actually see the details of all this and you would just Transit through the

regular evm FL uh okay let me check if we have something else to say. Oh yes, committing to the stocket state. So, I mentioned that after the execution of the transaction, we commit all the uh changes to stet. So, our state struct keeps some information about uh the accounts that have been modified, events to Emit, and transfers to uh transfers of native value. And when we commit, basically what we do is for each account, we will commit the account changes, which means that um you will just set the nonces with the increased nonces of the account. So, for example, if I'm sending a transaction, I'm increasing my nonces, and at the end, I will commit this new nonce to storage. Uh, you will um apply any storage changes, and if you are creating a contract, you will also write the bytecode of that contract. And uh, you will also write this code hash. And we have a caching mechanism for the valid jump d uh offsets inside the contract bytecode. So, whenever we deploy a contract, we will save all the valid jump destinations uh by running an analysis.

on the entire byte code and keeping in memory which indexes are valid, and they later on return to the account storage a few minutes when we where does the go but something the if you want toou we the for yeah what what happens when you want to drop the the new state and uh so as you can see every time we're executing a call so for example either when we're creating a contract or when we are just executing a call whatever whatever that Cod is we take a copy of the state which means um so State here is passed as an implicit argument of the generic code function meaning that when you do state copy uh you are taking the current state making a copy of it and returning it from the generic code function so here state is also argument of exec call uh so you always keep track of the par State here and once you have executed your generic call sorry you are calling something called finalize finalize parent yes so inside the function run you you you execute all the up code of your currently executed contract and if

the execution has stopped. You will be making various checks, so the first step, uh, the first sorry check [Music] is uh where is it [Music] defined right here final. Okay, I'm looking for the exact one, which one, the state finalizer, uh, ah, it's here. Okay, sorry. So, regardless of the result of the execution, once you have finished executing a context, you will finalize the dictionaries of all data structures, so the memory, the stack, and the state. So, when you finalize the state, what you do is uh, you basically take all the values inside the dictionaries and you squash it into a squash dict, and you return a new state uh, with the value of the squashed dictionaries, which means if you don't need to reuse this that state later, you can just drop it. So, here we finalize the state and we um, later on have a branching condition based on whether the call has succeeded or not inside the finalized parent function um, let me check yes. So, inside the finalized parent, we have two different cases. We have

uh a first case where the revert was an exceptional he in which case the return data is emptied. Nothing is copied to memory. The gas is not returned, and the state is reverted to its previous value. I'm looking for that exact statement which I lost. Ah, it's actually here. Okay, so yeah um if the call has reverted, then you just reuse the state that was defined in the parent context. If the Cod has not reverted, then you just keep using the state that has been modified in the current context. So, this is how you drop any changes that were made inside the Cod that has red. Was that yeah, I think can you more on how state is restored after the new copy that is discovered? Yes, it's simply the new copy that is being discounted. Yeah, okay, nice. I guess we also said that we would take five minutes of Cl explaining the mental model around theistic memory. I don't know if you still don't you still think this is relevant, but I think many people might not have the mental of understanding how to navigate.

the I don't know if it's I mean if you're completely new to the Cairo zero and Kyo. This might not be the best place to start to be Hest. What to say? I don't know what to say else than uh is readly memory. What do you want me to say again? Can try to diffuse the knowledge of your 15 minutes but minutes but the basic things read only memory. So nothing is written. It's only constraint on memory again and memory is only a list of uh list of list. It's a dict of segment. Segment is just an array of numbers of felt. So there is only this. We are just playing with arrays of numbers that are written by the prover and to which we explain. We Define constraint that needs to match the evm logic. k z is very permissive so you can really cast whatever you want into whatever you want. So we do abuse also these kind of things in the code base like we consider because at the end a pointer for example is a reference to

something but a reference is still a number again, so you can put, you can mix in a given segment, references to other segment or plane values, um, and compiler with cast. We will not comply at all, so we do this, uh, at some point, uh, yeah, because the pointer is at the end. Also, a number is also a felt at the very end. Everything is so, everything like every, every, every single thing at the very end is only felt in the segment. Yes, I don't know what to say. Okay, then probably we can wrap it here. Un, any questions? Yeah, if you guys have questions, otherwise PN will jump back on and, and kind of wrap it up. I know, um, yeah, we can go ahead and, um, take any last questions. Um, we'll wait just a few minutes to make sure that we've got everything covered. Thank you all. This has been extremely thorough and well done. Really appreciate you all taking the time. Was a pleasure for us as well. Always, always a good thing to present K zero to do a lot of people. Language has disc discover that we can.

help you with this, and also the setup has been said to be quite painful by some people because of the Python. Like, depending on your familiarity with Python tooling, you might suffer a bit from it. So, I will actually merge right now um P request and Kakarot to use the new UV python package manager instead of poetry, so it's a bit easier. It's not the same code Ash as the one given by uh the C4, but there are no differences in the Cairo. It's just for the packaging. It uses UV instead, which is a bit easier. Uh, anyway, so if you have like DB questions, ask them so that you can focus on the interesting part of the AUD, I would say yes. All right, well, with that, I think that's a wrap. Thanks, everyone.

Kakarot Code Walk-Through

Code4rena

The code base for Kakarot is spread across three repositories, with the main one using Cairo Zero for implementation.

The account model in StarkNet features native account abstraction, allowing for programmable accounts and transparent proxies for transaction execution.

The transaction lifecycle involves a relayer mechanism to sponsor transactions, with various checks and validations performed to ensure compliance with EVM specifications.

Exploitation Risks and Transaction Execution in Kakarot

The Kakarot contract's memory segment allocation can be exploited by a malicious prover, potentially altering transaction execution.

The contract performs Ethereum-related validations and has two main entry points for transaction execution.

The internal registry of state changes is maintained during execution, and all created dictionaries need to be squashed at the end to prevent malicious value setting.

The EVM creates a child instance for each function call, copying the state to handle potential reversals.

Opcode execution involves charging static and dynamic gas, with a jump table used to navigate to the correct function.

The process includes popping values from the stack, resizing memory, and shadowing variable definitions to manage changes in the EVM's state.

The Role of Pointers and Pre-Compiles in Cairo

Cairo uses an allocation pointer and a frame pointer to manage memory and function execution, with each pointer having a specific role.

The allocation pointer returns implicit and explicit arguments, while the frame pointer tracks the context of the currently executed function.

Pre-compiles in Cairo are categorized into regular EVM pre-compiles, rollup pre-compiles, and Kak-specific pre-compiles, each with a defined execution process and function offsets.

The Importance of Assertions in Prover Execution

The prover has the ability to fill memory with any value during hint execution, which can lead to inconsistent and dangerous outcomes.

Setting strong assertions on memory values is crucial to ensure correct computation and prevent malicious behavior.

Testing and simulating the prover's actions can help identify vulnerabilities and ensure that memory is filled with the correct values.

Cairo, a programming language, offers safe memory management and avoids under-constrained data segments, making it more secure than Kyo.

The language provides mutable references and has a special weight listing mechanism for precompiles to handle transaction failures.

Cairo's interoperability protocol allows for seamless execution of Cairo contracts from Kakarot, enabling data exchange between Solidity and Cairo.

Invoking Kakarot Kyo Precompile for Contract Communication

The Kakarot Kyo precompile is used to invoke contracts on the Stet network, with input data formatted and return data serialized as bytes.

The L1 Kakarot messaging contract facilitates message sending from Ethereum L1 to Kakarot L2, while the reverse is achieved through ABI encoding and a static call.

A dual VM token is proposed to wrap a Stet EC20 token, allowing for state querying and mutating changes, with a focus on liquidity integration between Kakarot and Stet.

Understanding State Management in Contract Execution

The execution of a contract involves taking a copy of the current state and returning it from the generic code function.

After executing the contract, the state is finalized by squashing the values of all data structures and returning a new state.

If the execution call reverts, the previous state is reused; if it succeeds, the modified state is continued.