zkSync

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.

Tag me to post a bounty or ask a question about Bountycaster. Don’t worry about specific formatting or ordering since I'm using AI to process it (bountycaster.xyz) /bounties. FAQ: bountycaster.xyz/faq

blockchain engineer @ https://openfort.xyz /
https://unchained-onchain.xyz / built @factchain / opinions entirely those of others / rekt 👎 ship 👍

https://github.com/zkSync-Community-Hub/zksync-developers/discussions/639#discussioncomment-10360021

@gatedude you have received an onchain attestation via EAS for this bounty completion

@gatedude was paid 100 USDC for this bounty

Your bounty was marked as complete and users have the completion recorded in their profiles

Please send payments promptly. You can pay users directly at https://www.bountycaster.xyz/bounty/0xeffc5c47d4f01b833a14082f653266d9231f58ca

Thanks for using Bountycaster! 🎉

Your bounty has been marked as in progress

Confirmed! On your bounty page, you can pay users and view their bounty completion history

Frame buttons
- Admin: manage bounty status, amount, deadline, add boost to get more attention on your bounty

🤖 commands
- @bountybot cancel
- @bountybot in progress
- @bountybot complete (optional: tag winners)
- @bountybot shoutout (optional: tag winner and write a positive review)

The standard for secure blockchain applications. 

We are hiring.

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.

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.

1. zkSync builds are non-deterministic because of the underlying cryptography, gas costs, and off-chain factors like the L1/L2 interaction that make bytecode unpredictable across those two different tools you mentioned (foundry/Hardhat)

2. Updating the smart account alters the proxy bytecode because the initialization logic changes, creating a new contract setup.

3. Only one proxy bytecode works since it's uniquely generated by your account factory's deployment logic and structure. 

Did some digging and Got some information from here

Thanks @jaivsdawrld for taking the time to answer!

i can't wrap my mind around your second point though. if the implementation bytecode changes (the smart account implementation), it shouldn't affect the proxy bytecode.  but again i might be missing something 🤷‍♀️  

If you look at this very simple proxy contract in the screenshot, how on earth a change on the implementation modifies its bytecode? once deploy, you only need to udpate the proxy *storage* to point to the new implementation.

And in fact, hardcoding the proxy bytecode (previous version) in the factory deployment script is my only option to make it work now.

will pay the bounty if you can make the factory deployment work with the proxy bytecode from the build: https://github.com/openfort-xyz/openfort-zksync-contracts/blob/b89d4a262fd90522c00cd947c737828fa7ac95ff/tasks/deployFactory.ts#L32

glgl :))

Take it easy on me. I’m just trying to make friends. ❤️ | Data analysis | fitness 

1. zkSync builds are non-deterministic because of the underlying cryptography, gas costs, and off-chain factors like the L1/L2 interaction that make bytecode unpredictable across those two different tools you mentioned (foundry/Hardhat)

2. Updating the smart account alters the proxy bytecode because the initialization logic changes, creating a new contract setup.

3. Only one proxy bytecode works since it's uniquely generated by your account factory's deployment logic and structure. 

Did some digging and Got some information from here https://docs.zksync.io/build

zkSync builds need improvement for determinism. Smart account updates affecting proxy bytecode is suboptimal. Multiple options should be available for account factory