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

EntityDescription
zksolcThe Solidity compiler, developed by Matter Labs.
solcThe 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.
LLVMThe compiler framework, used for optimizations and assembly generation.
EraVM assembler/linkerThe tool written in Rust. Translates the assembly emitted by LLVM to the target bytecode.
Virtual machineThe ZKsync Era virtual machine called EraVM with a custom instruction set.
EraVM specificationA 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.
YulOne of the Solidity IRs. Is a superset of the assembly available in Solidity. Used by default for contracts written in Solidity ≥0.8.
EVMLAOne 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 IRThe IR native to the LLVM framework.
EraVM assemblyThe text representation of the EraVM bytecode. Emitted by the LLVM framework. Translated into the EraVM bytecode by the EraVM assembler/linker.
EraVM bytecodeThe smart contract bytecode, executed by EraVM.
StackThe segment of the non-persistent contract memory. Consists of two parts: global data and function stack frame.
HeapThe 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 heapThe 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.
CalldataThe segment of the non-persistent contract memory. The heap or auxiliary heap of the parent/caller contract.
Return dataThe segment of the non-persistent contract memory. The heap or auxiliary heap of the child/callee contract.
Contract storageThe persistent contract memory. No relevant differences from that of EVM.
System contractsThe special set of ZKsync kernel contracts written in Solidity by Matter Labs.
Contract contextThe special storage of VM that keeps data like the current address, the caller’s address, etc.

Concepts


Made with ❤️ by the ZKsync Community