The 5 Most Anticipated Updates to ZKsync ZK Stack for Elastic Chains

The much anticipated ZKSync Protocol Upgrade v24 is live now on the mainnet, and from here on, all the Elastic Chain(s) will be able to integrate it into their operations under the ZKsync updates for Elastic Chains. Here’s what’s new you will find in your erstwhile ZK stack to make your Elastic Chain(s) fully functional and extremely efficient from now on. 

So far, users have to verify the wallets using those critical key phrases, which are very complex. However, the new RIP-7212 that proposes adding a new compiler will take the UX to the next level. For example, in the present context of ZKsync’s Zk Stack for Elastic Chain(s), if a new user has to be onboarded via a different access medium, in that case, it is not possible at the moment. 

However, after the New Precompile: P256 Verify interface is launched under the native AA improvement, it will allow even biometric auth to be acceptable. So, from here on, biometric and hardware authorization will be possible for ZkSync’s Elastic Chain(s) under ZKsync updates for Elastic Chains. Moreover, TLS, DNSSEC, Apple’s Secure Enclave, Passkeys, Android Keystore, and Yubikey, which were compatible with the EVM, will now be acceptable on ZKSync’s Elastic Chain(s) powered Dapps. 

Due to this practice it will also improve the efficiency of operations and even gas affordability within the EVM network. Additionally, since the new integration will support an elliptic curve precompiled contract, it would allow standardization of operations for the developers to smoothen the development experience on the ZK Elastic Chain(s). So, moving forward, the developers can easily integrate the curve signatures on the ZKsync Zk Stack Elastic Chain(s). Furthermore, they can also interoperate with other applications using the new upgrades of the ZKSync Protocol Upgrade v24. 

There should be a trustless bridging option available to share the users and liquidity without any challenge at all. In order to do that, ZKsync updates for Elastic Chains will launch the ZkSync Bridge Hub that all Elastic Chain(s) can use from now on for elastic chain interoperability. Due to this, all the applications/chains deployed as a ZKsync Elastic Chain can communicate with each other in a truly scalable and trustless manner.

Moreover, BridgeHub will also let L1 assets be locked in the same contract for all the chains, including the L3s and the validiums. In addition to this, these chains can simply connect and interact with other chains using mailboxes, and they can request  L1>L2 >L3 transactions for any chain. 

To interact with different chains deployed in different blockchains, the ZKsync Protocol Upgrade v24  will use a State Transition Manager (STM). 

The role of the STM will be to standardize communication and build trust zones with all the ZKsync Elastic Chain(s) under ZKsync updates for Elastic Chains. In this way, whether it is a specific token like ETH, WETH, etc., or any other native token, everything will be supported by the  L1SharedBridge Hub using Validium and transaction filtering support to interact with different chains and perform operations. 

Transaction filtering will also allow the Elastic Chain(s) to bake their own logic in the smart contract and perform the operations even in a non-native environment before sending the same to L2 for settlements. 

The former ZKsync Elastic Chain(s) lacked complete EVM compatibility. Due to this, it led to PubData usage changing at every stage of the execution. Hence, if there was a reentrancy lock, the user had to pay an initial price, which was refunded in the end. However, it took a toll on the user’s experience. 

For example, imagine swapping for a token yield on a different yield-generating platform where you want to farm the best interest rates. However, in doing so, you need to have an excessive amount of funds to interact with all the platforms, or else lose the opportunity because other platforms might not be standardized as per ZKsync’s Stack requirements. 

However, the erstwhile ZKsync Zk Stack allowed a refund in the end for the noncompletion of the transaction; the initial locking of the funds for gas fees/ smart-contract interaction severely dented the UX on Elastic Chains. 

To fix this, ZKsync updates for Elastic Chains will introduce a new version of the code-hash that starts with 0x02.  Due to this, the state machine can identify that when such bytecodes are coming, they are EVM equivalence. 

The reason an EVM equivalence matters is because of the trust that Ethereum has shown in all these years. Alex, Founder of zkSync, Says,  “There are certain things that can only be implemented by L1s and that are critical to the value created by a blockchain, above all: decentralization, resilience, and censorship-resistance. The role of an L1 is to perform these duties really well.” He believes that Ethereum has effectively won the “L1 race” as it performs these critical roles better than any other platform.

And when you have an EVM precompile code-hash,  in that case, it will help perform computationally intensive operations even for a non-evm dapp. . Hence, allowing any  ZKsync chain to perform cryptographic hash functions (e.g., keccak256, sha256) and elliptic curve operations (e.g., ecadd, ecmul). 

Therefore, the cost-intensive method of checking for functions would be decoupled because now, the Elastic Chain(s) developers will only pay for the gas costs when the transaction accesses the data availability for execution. And that would happen at the end of the transaction. This will allow the elastic chains not only to get unlimited throughput and decentralization but also to enjoy unimpaired security. 

When everyone wants to have their own token, it makes a lot of sense sometimes to decentralize your sequencers. That gives an additional token utility + higher community involvement. That’s important because, when you realize that there’s a training wheel or a backdoor entry provision on your Elastic Chain(s), you are putting the user’s trust in jeopardy. Because we have seen time and again that centralized sequencers have either brought the chain to a standstill by going offline or have severely impacted the user’s interest through front and back-running transactions/ aka MEV attacks. 

Here’s What L2beat saying about it’s centralized sequencers:

“..The sequencer cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencer censors or is down, it is so for everyone…”

However, when you have a decentralized sequencer, in that case, you can guarantee reliability. Because there will be a consensus-driven transaction ordering instead of a SPOF model or a Single Point of Failure. ZKsync updates for the Elastic Chains plans to decentralize its sequencer set using Expresso Systems in its 2025 roadmap. 

The core objective of ZkSync’s Zk Stack to decentralize the sequencers is to eliminate all the instances of front and back running. Due to this practice, a new sequencing model known as TimeBoost will be launched on the Elastic Chain(s). The trade-off of Time Boost will be to eliminate the chances of front running and back running,  making the entire Elastic Chain(s) ecosystem increasingly decentralized but not at the cost of high latency for transaction confirmation. 

Imagine that your Elastic Chain(s) has a decentralized sequencer, but the prover network is centralized. It would create a decentralization paradox. With that said ZKsync ZK Stack is introducing a decentralized prover network as an effective add-on in its 2025 roadmap under its ZKsync updates for Elastic Chains. In this regard, ZKsync’s Zk Stack has partnered with Gevulot to help decentralize the operations. 

BTW, you can build on ZKsync + Gevulot integration + 40 more on Zeeve Now. Check our integration page. 

Coming back to the ZKsync prover. For effective decentralization, a prover API has been launched that shall allow anyone to participate as the prover. The benefit of a decentralized prover is better resource allocation and checking on the overemphasis of control in the hands of a few on the Elastic Chain(s). Moreover, ZK-Sync wants to fragment the proving cycle so that even the bare minimum hardware can support better community participation. 

All these feature upgrades rolled out under the ZKsync Protocol Upgrade v24 would make the ZKsync Zk Stack the future scalable roll-up stack with all the benefits to build scalable Elastic Chain applications. However, the presence of a reliable partner to help deploy ZKsync updates for Elastic Chains equally matters, and Zeeve can help in this regard. 

Zeeve Rollups-as-a-Service introduces the necessary tooling and support that you need to deploy your own ZKsync Elastic Chain using the ZK Stack. By using the  Sandbox tools for ZKsync Elastic Chains, you can build your own custom  ZK Chain(s) with all the necessary ZKsync updates for Elastic Chains. You can even cut the time to market for your project when you have Zeeve to help you. Moreover,  the presence of 40+ integration partners to supercharge your elastic chain environment can further amplify possibilities when you plan to launch Dapps, supporting use cases around DePin, RWAs, or maybe Crypto x AIs.  

If you want more information about launching your Elastic chain, our experts are just a call or a click away.