You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
zkSync has a number of opcodes that are not supported in basic solidity or vyper syntax. The zkSync compiler is pretty good at knowing where to put specific zkSync opcodes depending on the solidity codebase.
However, there are times when it will be unsure. If isSystem is set to false, when it's unsure, it will not input the zkSync opcodes. When isSystem is set to true it will look for very specific call setups in the solidity opcodes and essentially hot swaps them out for the zkSync opcodes.
Example
For example, let's say zkSync supports an opcode called RESET which resets your wallet balance (idk why you'd want this, but ok). There is no Solidity syntax that would support such a call. If solidity supported this, the syntax might look like such:
assembly{reset(my_address)}
And would generate opcodes that might look like this:
PUSH0RESETPUSH1 0x01
However, the RESET opcodes doesn't exist in the EVM. So instead, what we do, is we setup a simulated call. This is when we abuse specific We instead say "Whenever we see a string of opcodes that looks like PUSH32 0xFFFE PUSH32 7 CALL swap that out for the RESET opcode.
In solidity, we use the syntax of System Contracts to make it easier to generate this set of assembly, so your solidity might look something like this:
When we pass the isSystem=true flag to the compiler, it will "hot swap" out all the "simulated called" with their real zkSync opcodes. If isSystem=false is passed, then the contract will not chance the underlying opcodes, and try to make the regular calls as instructed.
Security concerns
There is a chance that the generated opcodes have a collision. For example, maybe you want to run PUSH32 0xFFFE PUSH32 7 CALL and notRESET, this is something developers MUST be aware of when working with system contracts.
The text was updated successfully, but these errors were encountered:
For reference, see this conversation here.
About
zkSync has a number of opcodes that are not supported in basic solidity or vyper syntax. The zkSync compiler is pretty good at knowing where to put specific zkSync opcodes depending on the solidity codebase.
However, there are times when it will be unsure. If
isSystem
is set tofalse
, when it's unsure, it will not input the zkSync opcodes. WhenisSystem
is set totrue
it will look for very specificcall
setups in the solidity opcodes and essentially hot swaps them out for the zkSync opcodes.Example
For example, let's say zkSync supports an opcode called
RESET
which resets your wallet balance (idk why you'd want this, but ok). There is no Solidity syntax that would support such a call. If solidity supported this, the syntax might look like such:And would generate opcodes that might look like this:
However, the
RESET
opcodes doesn't exist in the EVM. So instead, what we do, is we setup a simulated call. This is when we abuse specific We instead say "Whenever we see a string of opcodes that looks likePUSH32 0xFFFE PUSH32 7 CALL
swap that out for theRESET
opcode.In solidity, we use the syntax of System Contracts to make it easier to generate this set of assembly, so your solidity might look something like this:
Using System Contracts
When we pass the
isSystem=true
flag to the compiler, it will "hot swap" out all the "simulated called" with their real zkSync opcodes. IfisSystem=false
is passed, then the contract will not chance the underlying opcodes, and try to make the regular calls as instructed.Security concerns
There is a chance that the generated opcodes have a collision. For example, maybe you want to run
PUSH32 0xFFFE PUSH32 7 CALL
and notRESET
, this is something developers MUST be aware of when working with system contracts.The text was updated successfully, but these errors were encountered: