Compiler Specification
Compiler Specification
This is a technical deep-dive into the specifics of how the compiler works. If you're looking to just deploy a contract, please visit Contract deployment to better understand the workflow or Toolchain to understand the specifics around our Solidity, Vyper and LLVM compilers.
Glossary
| Entity | Description |
|---|---|
| zksolc | The Solidity compiler, developed by Matter Labs. |
| solc | The original Solidity compiler, developed by the Ethereum community. Called by zksolc as a subprocess to get the IRs of the source code of the project. |
| LLVM | The compiler framework, used for optimizations and assembly generation. |
| EraVM assembler/linker | The tool written in Rust. Translates the assembly emitted by LLVM to the target bytecode. |
| Virtual machine | The zkSync Era virtual machine called EraVM with a custom instruction set. |
| EraVM specification | A combination of a human readable documentation and a formal description of EraVM, including its structure and operation, instruction syntax, semantic, and encoding. |
| Intermediate representation (IR) | The data structure or code used internally by the compiler to represent source code. |
| Yul | One of the Solidity IRs. Is a superset of the assembly available in Solidity. Used by default for contracts written in Solidity ≥0.8. |
| EVMLA | One of the Solidity IRs called EVM legacy assembly. Is a predecessor of Yul, but must closer to the pure EVM bytecode. Used by default for contracts written in Solidity <0.8. |
| LLVM IR | The IR native to the LLVM framework. |
| EraVM assembly | The text representation of the EraVM bytecode. Emitted by the LLVM framework. Translated into the EraVM bytecode by the EraVM assembler/linker. |
| EraVM bytecode | The smart contract bytecode, executed by EraVM. |
| Stack | The segment of the non-persistent contract memory. Consists of two parts: global data and function stack frame. |
| Heap | The segment of the non-persistent contract memory. All the data is globally accessible by both the compiler and user code. The allocation is handled by the solc’s Yul/EVMLA allocator only. |
| Auxiliary heap | The segment of the non-persistent contract memory, introduced to avoid conflicts with the solc’s allocator. All the data is globally accessible by the compiler only. The allocation is handled by the zksolc’s compiler only. All contract calls specific to zkSync, including the system contracts, are made via the auxiliary heap. It is also used to return data (e.g. the array of immutables) from the constructor. |
| Calldata | The segment of the non-persistent contract memory. The heap or auxiliary heap of the parent/caller contract. |
| Return data | The segment of the non-persistent contract memory. The heap or auxiliary heap of the child/callee contract. |
| Contract storage | The persistent contract memory. No relevant differences from that of EVM. |
| System contracts | The special set of zkSync kernel contracts written in Solidity by Matter Labs. |
| Contract context | The special storage of VM that keeps data like the current address, the caller’s address, etc. |