CLVM vs EVM
We'll start with a brief description of CLVM. For details on the inner workings of CLVM, see our CLVM reference.
- CLVM is the compiled, minimal version of ChiaLisp that is used by the Chia network.
- CLVM is built out of cons boxes and atoms. Cons boxes contain two items, which can be either an atom or another cons box.
- All CLVM programs can be represented as a binary tree. Evaluation is similar to that of standard Lisp.
- CLVM uses a minimal operator set, most of which are a single letter.
Comparison
| Design decision | EVM (Solidity) | CLVM (Chialisp) |
|---|---|---|
| The blockchain contains... | Smart contracts (compiled programs) as well as accounts. | The root hash of a binary tree, not source code. |
| Money | Smart contracts contain money. | Standard Chia coins don't contain money. They are money. That said, more complex functionality is possible, allowing coins to contain state, such as money. |
| Determinism | Less deterministic because multiple people can execute code within the same contract. Depending on the order of execution, the result won't always be the same. | More deterministic because coins can only be spent once. However, it's possible to have a coin that multiple people can spend, which would reduce determinism. |
| Centralization | Multiple people interact with the same contract. Centralized by design. | Only the owner interacts with a smart coin. Decentralized by design. |
| Sandboxing | No sandboxing. If a contract is hacked, all users can lose their money. | Strong sandboxing. Spending is the only action allowed on an unspent coin, and only by the owner(s). If a coin is hacked, only that coin's owner(s) lose(s) their money. |
| Composability | Composition is supported, so it is possible to set rules temporarily governing how money may be spent. However, if money is moved outside of the contract, it will follow different rules. (Note that it is possible to create a contract that “traps” ETH inside of it by only allowing money to be sent from the contract to specific types of addresses. However, by definition this limits the functionality of that money to whatever is contained within the contract.) | Composition is handled through inner puzzles. A puzzle's creator could say, “As long as these rules are followed, an inner puzzle can add any functionality.” Thus, it is possible to set rules that are intrinsic to the money itself, which must be followed forever. |
| MEV | Changing transaction order is both profitable and common. MEV is high. | Transactions all occur simultaneously in a block. MEV is low. |
| Reentrancy | Contracts can call functions on other contracts. Withdrawals can happen multiple times. Reentrancy is possible and must be carefully guarded against. | Coins interact with each other through announcements. They cannot call functions on other coins. Spends are atomic. Reentrancy is not possible. |
| Auditability/Security | Weak. Multiple points of failure. Numerous hacks prove this. | Strong. If an attacker changes a coin's puzzle, the hash also changes. The attacker is thus attempting to spend a coin that does not exist. The attacker can modify the solution, but the programmer can counter this by using assertions, which will make any such modifications fail. |
We chose CLVM over EVM for the reasons outlined above, and especially because of these advantages:
- Sandboxing – coins are independent from one another, providing for strong security
- Composability – inner puzzles make it possible for coins to take on the functionality of other coins
- Interoperability – all coins output a list of conditions, so they can inherently interoperate with one another, even if not explicitly designed to do so
- No side effects - Auditing is easy; reentrancy is not possible