Want to learn more about what makes Cartesi secure? Learn

about metering.

Metering is a security concept we recently explored in our R&D call and it works like this 👇

You usually don’t want to run code from untrusted sources. It leaves your system vulnerable to bad actors who might introduce code that exploits your own. 🥷

But if you’re offering a service, you have to be open to running code from regular users. The problem is that attackers can be regular users, too… 🔎

Traditionally, there are ways to secure execution environments like:
🚧Designated user-space and permissions in OS’s
🧰Hardware limitations like hypervisors

Attackers have different ways to bypass this security. They can:
🪪Escalate their privileges
🛣️Open side-channels

Sometimes they just slow down the service…

In Web3, we have a slightly different scenario. Web3 VMs only run code when a transaction is sent to a smart contract so we’re not at risk of outside code exploiting our own. 🦾

But we do have smart contracts that can interact with other smart contracts. This means an attacker’s MO will generally consist of deploying a malicious smart contract. 👾

A famous example of this problem is the re-entrancy attack. But an overlooked example we see often is bad actors going for a resource exhaustion attack.

Again, sometimes they just want to slow down the service… 🐌

This is where metering comes in. 📏
What systems like the EVM usually do is they’ll give smart contracts a “budget” for how much gas they can spend when calling other small contracts.
We can call this “adversarial metering.”

But we still have a problem here - it is very expensive for two reasons:
Every operation has to be metered.
They have to be charged based on "worst case scenario" analyses.

Cartesi is looking into what we’d call “cooperative metering.”
Cartesi runs app-specific rollups where there is a single author of code. This eliminates the possibility of malicious smart contracts deployed by anyone but the dApp’s developer. 😌

Big picture, we have a situation where trust only goes in one direction:
User ➡️ Developer ➡️ Validators
This setup actually maximizes scaling and could work without imposing gas limits.
Pretty neat, right?

There are more implementation details and fine-tuning approaches that we discussed in the R&D call. Watch the full recording on Youtube: https://www.youtube.com/watch?v=wKGmVrde4Ns

Retweet: https://x.com/cartesiproject/status/1727688571380027557

Good days my dear Community! How are we? Enjoy your friday! If you have any questions related Cartesi, please let me know. I am more than happy to help you! ✨