Content
@
0 reply
0 recast
0 reaction
Pierre H. — q/dau
@rektorship
https://github.com/zkSync-Community-Hub/zksync-developers/discussions/639#discussioncomment-10693912 why are zksync builds non-deterministic (both foundry and hardhat)? why does updating the smart account change the proxy bytecode? and why is there only one proxy bytecode that works for my account factory? @bountybot pays 100 USD to the person who can answer *all* these questions.
9 replies
1 recast
4 reactions
gatedude.eth
@gatedude
Hey fam, I visited the repo and read the conversation. A contributor actually suggested using ---no-optimization flag with Hardhat to reduce variability. Another also suggested you exploring @openzeppelin/contracts for deterministic builds. Here's my take on the question you asked: First, you need to understand that zkSync's build process involves generating random numbers (salts) for cryptographic purposes. Also these random numbers affect the compiled contract bytecode. But Foundry and Hardhat generate different random values, leading to non-deterministic builds. Also, the reason why updating the contract actually changes the proxy bytecode is because zkSync's smart accounts actually uses a proxy contract to manage account upgrades. When you update the smart contract, the proxy contract bytecode changes due to the "New account Logic" and the "Updated account-specefic data" like the public key for example.
2 replies
0 recast
1 reaction
gatedude.eth
@gatedude
So, the change in bytecode actually ensures that the proxy contract reflects the updated smart contract configuration. Also, the reason why there's only one proxy bytecode that works for your account factory is because zkSync's account factory deploys proxy contract for new accounts and the proxy bytecode is generated based on account factory's configuration. Also, using a single proxy bytecode ensures consistency across all accounts created by the factory. But if you want to achieve deterministic builds and reusable proxy bytecode; I suggest you try using a fixed salt or a random number generator seed or Maybe try Utilizing a deterministic build tool or script. Lastly, you most ensure consistent configuration and dependencies. I hope this helps you fam...
0 reply
0 recast
1 reaction
Pierre H. — q/dau
@rektorship
Thanks, @gatedude, for your answers! How can the proxy bytecode be generated from the account factory configuration? It seems pretty isolated to me (c.f screen) Here's the deploy factory Hardhat task: https://github.com/openfort-xyz/openfort-zksync-contracts/blob/b89d4a262fd90522c00cd947c737828fa7ac95ff/tasks/deployFactory.ts#L32 I'll pay the bounty If you can make it work without hardcoding the proxy bytecode. You might ask how I got this bytecode in the first place. Well, `proxyArtifact.bytecode` used to work well in the factory deployment script. I shipped the first version of our accounts using that setup. Then, I started working on adding transaction batch support and noticed that the factory was deploying accounts with no associated bytecode. Even a single-byte update in `BaseOpenfortAccount.sol` produces a different proxy bytecode. I definitely need to dive deeper into the cryptographic purposes behind this. Thanks for pointing me in that direction.
1 reply
0 recast
1 reaction
