As the contract will be deployed on both L1 and L2 (zkSync), the issue lies in the lack of compiler awareness for contractBytecode
in zkSync, potentially resulting in incorrect contract deployments and address calculation.
The lack of compiler awareness regarding the runtime contractBytecode
may lead to incorrect contract deployments and address calculation in zkSync, potentially causing operational issues.
This vulnerability can result in unreliable and potentially non-compliant contract deployments in zkSync, compromising the stability and integrity of the system.
To demonstrate the impact of the lack of compiler awareness in zkSync contract deployment, consider a scenario where a contract is deployed using the create
function with runtime bytecode provided as a parameter, such as in the myFactory
function. This could result in a contract deployment that does not adhere to zkSync's bytecode format requirements and may lead to operational issues, highlighting the necessity of following zkSync's guidelines for bytecode and compiler awareness.
ref @ https://era.zksync.io/docs/reference/architecture/differences-with-ethereum.html#evm-instructions
manual review and foundry
To address the lack of compiler awareness and ensure correct contract deployment in the zkSync environment, the following recommendations are suggested:
Compile-Time Bytecode: Modify the contract deployment process to ensure that the bytecode is known at compile time. Use type(T).creationCode
to determine the bytecode in advance, aligning with zkSync's specific requirements.
Bytecode Validation: Implement bytecode validation to ensure that the contractBytecode
parameter adheres to zkSync's bytecode format requirements. Validate the bytecode's length, word count, and other format criteria before deployment to prevent issues.
Replace deploy function with this
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.