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
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.
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
Last updated