This is my wishlist for Cartesi Rollups contracts v3. <a id="merkelize-inputs"></a>Merkelize Inputs Currently, the InputBox hashes every input it receives and DaveConsensus computes the Merkle root of an input only if necessary during a dispute. It is cheaper to compute the keccak256 of an input than its Merkle root, so we added a hard limit on the input size to ensure that every input sent to the InputBox contract can be merkelized later. What we want to do is, instead, make InputBox merkelize every input it receives. This does mean that adding inputs (and there depositing assets) will be more expensive, but this might be ammortized on a later release once we increase the data block size from 32 bytes to, say, 128 bytes, or even 4 kilobytes. We might also change the arity of the tree, which is currently binary, to be 4-ary, for example. There are also ZK approaches. For now, we will compute the root of a binary Merkle tree with 32-byte data blocks. With this, the InputBox will no longer serve keccak256 hashes but rather only Merkle roots. The getInputHash function will be renamed as getInputMerkleRoot to make this breaking change clear. This will make the DaveConsensus contract much simpler. <a id="store-number-of-inputs-before-current-block"></a>Store Number of Inputs Before Current Block

I've gathered some numbers on the cost of interacting with the Cartesi Rollups v2 contracts on Ethereum Mainnet and Sepolia. The table below contains gas costs and links to the transactions used as reference. Action Gas Txs Send Message L1→L2 55K ($0.28) Mainnet (#1)

Special thanks to Cláudio Silva, Danilo Tuler and Milton Jonathan for reviewing this article! Hello, my name is Guilherme. I've been part of the on-chain team behind Cartesi Rollups since late 2021. Since then, one topic that has always sparked my interest and that of fellow Cartesi contributors is upgradability. What are the trust assumptions at play? How can we minimize them, while also taking into consideration other aspects such as implementation complexity, UX, infrastructure costs, and L1 fees? Let's dig in. Introduction In the software industry, when a severe security vulnerability is reported and fixed, users are highly encouraged to upgrade to the patched version. On web2, users aren't often given much choice besides agreeing with the new terms and conditions. Users are, therefore,, often coerced to agree with the new terms, despite possible setbacks in privacy and transparency. This is even more severe with vendor lock-in practices, which are so common in this industry.