Finally, let me introduce Avail. Before we officially begin, I would like to remind everyone that Avail has launched Binance Alpha. You can pay attention to it Event link: https://(x.com)/finance/status/1935957400697319869 Main text: Native ZK Verification Unlocks Hyper Scalable Execution Avail now has transaction verification and settlement added to its horizontally scalable, public blockchain network. With native ZK verification on the base layer, Avail can support any execution environment. Native ZK verification unlocks super scalable execution Avail has now added transaction verification and settlement capabilities to its horizontally scalable public blockchain network. With its native zero knowledge verification feature, Avail can support any execution environment. In the early stages of the Avail project, our core focus was on addressing data availability issues. We realize that in order to make blockchain technology widely applicable to various use cases, it is necessary to protect the security of massive transaction data in an efficient, decentralized, and secure manner. In addition, we have invested a significant amount of effort to achieve a blockchain that is fully aligned with Ethereum's sharding roadmap, ensuring that any user, any program, and almost any device can verify data published on the Avail network. Now, we have achieved this goal and started recruiting the first batch of early users. At the same time, we have also begun to address other key technological barriers that hinder the development of blockchain, the most notable of which is the seamless connection of cross chain transactions through Nexus upgrade. From now on, all projects built on Avail will create exponential returns in terms of scalability and performance. The reason is simple, Avail has implemented an elegant solution for the biggest scalability bottleneck of web3- data availability. From now on, adding cross chain transactions to Avail means that cross chain transactions can inherit all the scalability features of Avail's underlying blockchain, such as KZG commitments and data availability sampling (DAS). The same applies to rollup and application chains integrated with Avail. The core argument of Avail's rollup centric architecture is that execution should take place outside of the main chain. For situations such as rollup and validium, this is relatively easy to understand; Each chain manages its own execution environment and publishes transaction data to Avail. Although this is a valuable solution, it is often more attractive to large mature projects that require high throughput and efficient data availability solutions, such as Lens. However, this overlooks a large portion of people in the community who want to build applications and services on the network without launching new chains, just like deploying smart contracts on Ethereum. However, without native execution support, Avail's services in this area are still limited. This requires a new perspective. Execution is still off chain, but verification is on chain It is not meaningful to implement an execution environment similar to EVM or SVM on Avail. This will largely go against the original intention of building an optimized blockchain for DA, and we will eventually return to the starting point (of course, DA's efficiency will be improved). This is because a universal Turing complete blockchain will always encounter a bottleneck at some point. Each Turing complete chain will have its own encryption cats, which will occupy bandwidth, block other chains, and have a negative impact on user performance. The computation of Avail's execution layer does not execute transactions on the chain and block the network, but runs off chain and then uses ZK proofs for verification on the chain for settlement. This has brought many benefits. It enables the Avail network to verify and settle transactions while providing efficient data availability (DA). The zero knowledge proof (ZK) execution engine will not cause blockchain bloating, nor will it have a negative impact on the scalability benefits we have already obtained, which would occur if we adopt EVM or SVM style methods. In addition, it does not strictly enforce runtime execution, providing developers with greater flexibility. Now, you can introduce any execution environment and use zero knowledge proofs on top of Avail's base layer. By checking and verifying zero knowledge proofs at the bottom level, Avail's execution engine actually outsources a significant portion of its computation to external parties, which aligns with the core concept of Avail's horizontally scalable design. The Avail version of the encrypted cat will not occupy resources on the chain, nor will it have a negative impact on other chains, as Avail's encrypted cat will provide its own computing power. ZK application similar to smart contract verification Developers can now build ZK applications and validate them directly in Avail without launching a new blockchain, leveraging its security and scalability, similar to deploying smart contracts on Ethereum. Avail's runtime can verify any program that is currently provable by RISC Zero or SP1, and support for Brevis, Starkware, and other ZKVM can be added in the future. This has opened up a wide range of ZK use cases, such as: Native token deployment (such as ZK minting assets or stablecoins) Smart contracts (such as ZK validated smart contract logic) TEE (Trusted Execution Environment) Proof (such as Confidential Computing Proof) ZK automation compliance (such as KYC/AML checks, will not expose private user data) Developers can now start trying out ZK applications and deploying them to Avail's runtime. There are currently two versions: ZK application for Ethereum and ZK application for ZKsync, which are used to verify the status of Ethereum and ZKsync at runtime, respectively. If you would like to learn more information, please check your respective code repositories, or contact me, or our developer relationships @ naruto11eth and @ robin_rrtx. Avail's Growth Journey From the beginning, we focused on understanding the basic principles of blockchain technology and building from them. Now, we have assembled an efficient team that understands blockchain technology better than most people, and we welcome other pioneering teams with a shared vision to join the Avail ecosystem. However, like many things, this work will never end, and we still have a lot of work to do now to better utilize Avail's unique architecture. Avail's ZK execution runtime will play a key role in facilitating cross chain transactions in the upcoming Nexus upgrade. It will also significantly expand the scope of the Avail network, extending it from providing data availability (DA) services to serving a wider community of developers. Now, the Avail network includes a universal execution layer that is optimized for the latest ZK technology and supports it, while also providing state-of-the-art data availability sampling. This is just the beginning. Avail's ZK native execution layer has opened up new design space for developers, enabling them to build a variety of highly scalable, interoperable applications that are more flexible than ever before. the original 👉 Link: https://blog.availproject.org/native-zk-verification-unlocks-hyper-scalable-execution/ Official recommendation: @ AvailProject Gitbook：https://(github.com)/availproject/? ref=blog.availproject.org Blog: https://blog.availproject.org/ Discord:https://(discord.com)/invite/y6fHnxZQX8? ref=blog.availproject.org