Essentially, there are a number of "system calls" you can make in the ZKSync ecosystem. To make such calls, you have to tell the zksync compiler that when it see specific unique calls, it should "transform" them into "system" calls. A "system" call is a sort of "higher permission" call on the ZKSync ecosystem.
These sets of instructions that the zksync compiler looks for to convert to a system call is known as a "simulation". You can "sort of" think of these like precompiles.
Simulation example
For example, let's say there is a simulation like so:
For context:
https://ethereum.stackexchange.com/questions/162863/how-does-the-issystem-flag-work-for-zksync-projects
Essentially, there are a number of "system calls" you can make in the ZKSync ecosystem. To make such calls, you have to tell the zksync compiler that when it see specific unique calls, it should "transform" them into "system" calls. A "system" call is a sort of "higher permission" call on the ZKSync ecosystem.
These sets of instructions that the zksync compiler looks for to convert to a system call is known as a "simulation". You can "sort of" think of these like precompiles.
Simulation example
For example, let's say there is a simulation like so:
call(address(25), 7, string(helloSecretThing)
==systemcontract.updateNonceHolder(1)
If
isSystem=false
, when this is passed to the compiler the codebase would just stay ascall(address(25), 7, string(helloSecretThing)
But, if
isSystem=true
, when passed to the compiler, that line would change to:systemcontract.updateNonceHolder(1)