Overview

---

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 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 Validium Network, 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 Validium Network 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.

Concepts

• Code Separation
• System Contracts
• Exception Handling
• EVMLA translator
• Binary layout, linking and loading