The RedStone Expedition beckons, promising a thrilling odyssey through uncharted territories of challenges, innovation, and abundant rewards. Spanning three captivating seasons, this journey offers adventurers an opportunity to immerse themselves in a landscape brimming with excitement and discovery.

At the heart of the Expedition lies the RedStone Gems (RSG)—a currency of sorts, meticulously stored on the blockchain to ensure transparency and security. Powered by the Warp Contracts SDK technology, every transaction and point calculation is securely recorded on the Arweave blockchain, underscoring the expedition's commitment to fairness and integrity.

Earning RSG is the key to unlocking the treasures hidden within this adventure. From active participation in the RedStone Discord server to engaging in community campaigns and collaborating with partners, adventurers have a myriad of opportunities to accumulate RSG points. Special boosts further enhance the journey, acting as multipliers to expedite the accumulation of RSG points.

The expedition's progress is tracked through a dedicated dashboard—a personalized compass guiding participants through the twists and turns of their journey. By logging in with their Metamask wallet, adventurers can monitor their RSG status, recent points earned, and active boosts, ensuring they remain on course to their desired destination.

Warpy serves as the bridge between the Discord community and the blockchain, diligently tracking participants' activities to ensure they are duly rewarded with RSG points. By connecting their EVM address to their account, adventurers can seamlessly translate their Discord interactions into valuable RSG points.

Partnerships are integral to the expedition's success, enriching the journey with new experiences and opportunities. With special weeks dedicated to partners, adventurers have the chance to forge meaningful connections while earning RSG points along the way.

As the expedition unfolds, participants can expect new avenues of exploration and opportunities for rewards. However, time is of the essence, as activity points will gradually decrease over time. Therefore, early and consistent participation is key to maximizing rewards and ensuring a fulfilling journey.

The RedStone Expedition invites adventurers to embark on a journey of a lifetime—a journey filled with innovation, challenges, and substantial rewards. By joining this expedition, adventurers not only become part of a vibrant community but also contribute to a revolutionary blockchain project.

So, heed the call and unlock the treasures that await in the RedStone Expedition—an adventure like no other awaits! ⛏️🚀

Join your Journey today, join Redstone Oracle Discord at:

https://discord.gg/PAYTxQEZ

Do not forget to link your wallet at #warpy to be eligable to participate in any upcoming RSG Campaigns and Social Campaigns.

Introduction: RedStone Oracle is a decentralized oracle solution that provides secure and reliable data feeds for decentralized applications (DApps). This tutorial will guide technical users through the process of using RedStone Oracle to access external data for their DApps.

Prerequisites:

• Basic knowledge of Ethereum and smart contracts

• Familiarity with web3.js or ethers.js

• Access to an Ethereum development environment (e.g., Ganache, Remix, Truffle)

Steps to Use RedStone Oracle:

Step 1: Install Necessary Dependencies Ensure you have the necessary dependencies installed:

• Node.js and npm: Required for installing packages and running scripts.

• Web3.js or ethers.js: JavaScript libraries for interacting with Ethereum smart contracts.

Step 2: Obtain an API Key Visit the RedStone Oracle website and create an account to obtain an API key. This key will be used to authenticate your requests to the oracle contract.

Step 3: Connect to the Ethereum Network Connect to an Ethereum network (mainnet, testnet, or a local blockchain) using web3.js or ethers.js. You can use tools like Metamask or provide your own node URL.

Step 4: Import RedStone Oracle ABI Import the RedStone Oracle ABI (Application Binary Interface) into your project. You can find the ABI on the RedStone Oracle documentation or GitHub repository.

Step 5: Instantiate the Oracle Contract Instantiate the RedStone Oracle contract using its address and ABI. This will allow you to interact with the oracle contract from your JavaScript code.

javascript

const Web3 = require('web3');
const RedStoneOracleABI = require('./RedStoneOracleABI.json');

const web3 = new Web3('https://mainnet.infura.io/v3/YOUR_INFURA_PROJECT_ID');
const oracleAddress = '0x...'; // RedStone Oracle contract address
const oracleContract = new web3.eth.Contract(RedStoneOracleABI, oracleAddress);

Step 6: Request Data from the Oracle Call the appropriate function on the oracle contract to request data. For example, if you want to get the latest price of an asset, use the requestPrice function.

const assetSymbol = 'BTC/USD'; const requestId = '123'; // Generate a unique request ID const result = await oracleContract.methods.requestPrice(assetSymbol, requestId).send({ from: YOUR_ADDRESS }); console.log(result);

Title: RedStone Oracle User Tutorial for Technical Users

Introduction: RedStone Oracle is a decentralized oracle solution that provides secure and reliable data feeds for decentralized applications (DApps). This tutorial will guide technical users through the process of using RedStone Oracle to access external data for their DApps.

Prerequisites:

• Basic knowledge of Ethereum and smart contracts

• Familiarity with web3.js or ethers.js

• Access to an Ethereum development environment (e.g., Ganache, Remix, Truffle)

Steps to Use RedStone Oracle:

Step 1: Install Necessary Dependencies Ensure you have the necessary dependencies installed:

• Node.js and npm: Required for installing packages and running scripts.

• Web3.js or ethers.js: JavaScript libraries for interacting with Ethereum smart contracts.

Step 2: Obtain an API Key Visit the RedStone Oracle website and create an account to obtain an API key. This key will be used to authenticate your requests to the oracle contract.

Step 3: Connect to the Ethereum Network Connect to an Ethereum network (mainnet, testnet, or a local blockchain) using web3.js or ethers.js. You can use tools like Metamask or provide your own node URL.

Step 4: Import RedStone Oracle ABI Import the RedStone Oracle ABI (Application Binary Interface) into your project. You can find the ABI on the RedStone Oracle documentation or GitHub repository.

Step 5: Instantiate the Oracle Contract Instantiate the RedStone Oracle contract using its address and ABI. This will allow you to interact with the oracle contract from your JavaScript code.

const Web3 = require('web3'); const RedStoneOracleABI = require('./RedStoneOracleABI.json'); const web3 = new Web3('https://mainnet.infura.io/v3/YOUR_INFURA_PROJECT_ID'); const oracleAddress = '0x...'; // RedStone Oracle contract address const oracleContract = new web3.eth.Contract(RedStoneOracleABI, oracleAddress);

Step 6: Request Data from the Oracle Call the appropriate function on the oracle contract to request data. For example, if you want to get the latest price of an asset, use the requestPrice function.

oracleContract.events.DataResponse({ filter: { requestId } })
    .on('data', event => {
        const { requestId, result } = event.returnValues;
        console.log(`Received data for request ID ${requestId}: ${result}`);
    })
    .on('error', console.error);

Step 7: Handle Data Response Listen for the data response event emitted by the oracle contract. Once the data is available, retrieve and process it accordingly.

Step 8: Test Your Integration Test your integration by running your DApp and verifying that it can successfully retrieve data from RedStone Oracle. Ensure that your requests are properly authenticated using your API key.

By following this tutorial, technical users can easily integrate RedStone Oracle into their DApps and access reliable external data. RedStone Oracle provides a secure and decentralized solution for fetching real-world data on the Ethereum blockchain, enhancing the functionality and utility of decentralized applications.

RedStone Oracle is a decentralized oracle solution that provides reliable, tamper-proof data feeds for decentralized applications (DApps). By integrating RedStone Oracle into your DApp, you can securely access external data such as prices, weather conditions, and other real-world information. This tutorial will guide technical users through the process of integrating RedStone Oracle into their DApps.

Prerequisites:

• Familiarity with Solidity programming language

• Understanding of Ethereum and smart contracts

• Basic knowledge of decentralized applications (DApps)

Steps to Integrate RedStone Oracle into Your DApp:

Step 1: Install Necessary Tools Ensure you have the following tools installed:

• Truffle Framework: For smart contract development and deployment.

• Node.js and npm: Required for installing dependencies and running scripts.

• Ganache: For local Ethereum blockchain development.

Step 2: Set Up a RedStone Oracle Account Visit the RedStone Oracle website and create an account. After registration, you'll receive an API key and access to the RedStone Oracle dashboard.

Step 3: Create Your Smart Contract In your DApp's Solidity smart contract, import the RedStone Oracle interface and define functions to interact with the oracle. You'll typically need functions to request data and handle callbacks.

pragma solidity ^0.8.0;

import "@redstone-finance/contracts/contracts/IRedStoneOracle.sol";

contract MyDApp {
    IRedStoneOracle public oracle;
    address public oracleAddress = YOUR_ORACLE_ADDRESS;
    bytes32 public dataRequestId;

    constructor() {
        oracle = IRedStoneOracle(oracleAddress);
    }

    function requestData() external {
        dataRequestId = oracle.requestPrice("BTC/USD");
    }

    function fulfill(bytes32 _requestId, uint256 _data) external {
        require(msg.sender == address(oracle), "Only oracle can fulfill");
        // Handle data received from the oracle
    }
}

Replace YOUR_ORACLE_ADDRESS with the address of the deployed RedStone Oracle contract.

Step 4: Fund Your Oracle Request Before making a data request, ensure your smart contract has enough ETH to cover gas costs. You may need to transfer ETH to the contract or implement a mechanism for users to fund requests.

Step 5: Request Data from RedStone Oracle Call the requestData function in your smart contract to request data from RedStone Oracle. Specify the data type and any additional parameters required for the request.

Step 6: Handle Data Callback Implement a function in your smart contract to handle the data callback from RedStone Oracle. This function will be called by the oracle contract once the requested data is available.

Step 7: Test Your Integration Deploy your DApp smart contract to a test network (e.g., Rinkeby, Ropsten) and test the integration with RedStone Oracle. Verify that your DApp can successfully request and receive data from the oracle.

Step 8: Deploy to Mainnet Once you're satisfied with the integration and testing, deploy your DApp smart contract to the Ethereum mainnet. Ensure that your contract has enough ETH to cover gas costs for oracle requests.

Conclusion: Integrating RedStone Oracle into your DApp allows you to access reliable external data, enhancing the functionality and utility of your decentralized application. By following this tutorial, you can seamlessly integrate RedStone Oracle into your DApp and leverage real-world data in a secure and decentralized manner.

In the rapidly evolving world of decentralized finance (DeFi), innovative platforms are constantly emerging, each promising to revolutionize how we interact with digital assets. One such groundbreaking development is Juice, a Cross-Margin DeFi application that's carving a niche for itself on the @Blast_L2 network. Powered by the advanced capabilities of RedStone Oracles, Juice Finance is not just another DeFi platform; it's a gateway to optimized yields and unparalleled financial opportunities.

Introducing Juice Finance

At its core, Juice is a cutting-edge DeFi application that stands out through its innovative cross-margin lending capabilities. It's built on the robust @Blast_L2 network, leveraging Blast's native rebasing tokens—native ETH, WETH, and USDB—alongside unique gas refund mechanics. This integration not only ensures a seamless and cost-effective user experience but also opens up new avenues for yield optimization.

The Vision Behind Juice

Juice Finance is driven by a singular vision: to become the premier destination for users seeking to maximize their yield and point farming activities on Blast. Whether you're a lender looking for passive APY or a borrower aiming to leverage yields, rewards, and points, Juice positions itself as your go-to platform. This commitment to user empowerment and financial innovation forms the cornerstone of Juice's operational philosophy.

For Lenders: A Path to Secure Earnings

Lenders within the Juice ecosystem play a pivotal role, providing the liquidity essential for the platform's borrowing activities. By depositing USDB into the lending pool, lenders earn an attractive APY without the risk of impermanent loss. This setup not only benefits lenders with consistent returns but also ensures the platform's sustainability and growth.

For Borrowers: Leverage Unleashed

Borrowers on Juice Finance are offered an opportunity to access up to 3x leverage on their WETH collateral. This mechanism allows borrowers to collateralize WETH and borrow USDB, which can then be utilized across a range of vetted and popular DApps within the Blast ecosystem. Such flexibility and leverage potential make Juice an attractive option for borrowers looking to maximize their DeFi strategies.

RedStone's Role: Enabling Precision and Reliability

RedStone Oracles plays a critical role in the Blast ecosystem, supporting Juice Finance by providing accurate and reliable data feeds. These feeds range from traditional ones like ETH or BTC to more advanced offerings such as wETH, ezETH, and apxETH, with an extensive pipeline of developments on the horizon. RedStone's commitment to data integrity and innovation ensures that Juice Finance operates on the most reliable information available, enabling optimal decision-making for both lenders and borrowers.

Join the Revolution

As Juice Finance continues to redefine the DeFi landscape on Blast_L2, supported by the technological prowess of RedStone Oracles, the potential for users to optimize their financial strategies has never been greater. Whether you're looking to lend, borrow, or simply explore the vast possibilities within the DeFi space, Juice offers a platform that combines innovation, security, and profitability.

Embark on your Juice Finance journey and join a community of forward-thinking individuals who are shaping the future of decentralized finance. Explore more about Juice and how RedStone Oracles are powering this revolution:

• Discord: RedStone DeFi Community

• Website: RedStone Finance

• Twitter: @redstone_defi

• Telegram: RedStone Finance

Welcome to the new era of DeFi, where Juice Finance and RedStone Oracles are your allies in navigating the vibrant and ever-expanding universe of decentralized finance.

In the dynamic world of blockchain and cryptocurrency, the launch of a new Layer 2 (L2) solution is always a momentous occasion. It heralds not just technological advancement but also the opening of new opportunities for users and developers alike. The recent launch of the Blast_L2 mainnet is one such event, marking a significant milestone in the Ethereum ecosystem. To celebrate this remarkable achievement, Redstone is teaming up with Galxe to launch an exclusive campaign that promises to blend excitement, community engagement, and, most importantly, rewards.

The Blast_L2 Mainnet: A Leap Forward

The Blast_L2 mainnet stands out as the only Ethereum Layer 2 solution offering native yield for ETH and stablecoins. This unique feature sets it apart in a crowded market, offering tangible benefits to its users. By optimizing transaction efficiency and reducing costs, Blast_L2 enhances the Ethereum experience, making it more accessible and profitable for a wider audience.

An Exclusive Celebration Campaign

To mark this significant launch, Redstone is initiating an incentivized Blast Campaign in collaboration with Galxe, a renowned platform for NFTs and digital rewards. This campaign is designed not just to celebrate but also to incentivize community participation and engagement. By completing a series of quests, participants can earn special NFTs, adding both value and excitement to the community's experience.

How to Participate

The campaign is open to everyone, with a few simple steps required to join in the celebration:

1. Follow RedStone and Blast on Twitter: Stay updated with the latest news and announcements from both RedStone and Blast by following their official Twitter accounts.

2. Join the RedStone Discord: Become a part of the RedStone community by joining their Discord server. This is a great way to connect with other community members, share insights, and stay informed about the campaign.

3. Retweet and Like the Announcement: Show your support and spread the word by retweeting and liking the campaign announcement. This not only increases visibility but also helps to build a sense of community around the launch.

Special NFT Rewards

As a token of appreciation for participating in the campaign, special NFTs will be awarded to those who complete the quests. These NFTs are not just digital collectibles; they symbolize your participation in a milestone event in the Ethereum ecosystem and hold potential value both within and outside the platform.

A Call to Action

The Blast_L2 mainnet launch and the ensuing Galxe campaign represent a pivotal moment in the evolution of Ethereum's Layer 2 solutions. By participating in this campaign, you're not just earning rewards; you're also supporting innovation and contributing to the growth of a technology that promises to make the blockchain space more efficient, accessible, and profitable.

We invite everyone to join us in this celebration. Let's take part in these quests, earn exclusive NFTs, and be part of a community that's at the forefront of blockchain innovation. This is more than a campaign; it's a celebration of progress, community, and the future of finance. Join us now to make your mark!

The Core of RedStone's Innovation

RedStone Finance distinguishes itself with three unique integration methods:

1. RedStone Core: Tailors dynamic data injection to each user transaction, stepping away from traditional mass data pushes.

2. RedStone Classic: Adheres to the conventional oracle model, with data transferred on-chain via a relayer.

3. RedStone X: Designed for complex protocols, this model reduces the risk of front-running, addressing a crucial concern in the blockchain ecosystem.

Empowering the Community: The RedStone Miners Ambassador Program

RedStone invites Web3 enthusiasts from various backgrounds to join its vibrant ambassador program. The program is a beacon for those interested in content creation, social media, and community management, encouraging participants to play an active role in spreading the RedStone message.

The Rewards of Participation

Participants in the RedStone Miners Ambassador Program can expect to:

• Earn RSG (RedStone Gems) for on-chain activities.

• Gain exclusive access to giveaways and unique OGNFTs.

Rank Advancement: From Ore Digger to Mine King

The program offers a tiered system of advancement, with each rank bringing its own set of responsibilities and rewards. Members start as 'Ore Diggers' and can progress through to the esteemed 'Mine King' status by actively engaging on platforms like Twitter and Discord and completing various tasks.

Unleashing Creativity in the RedStone Hall of Fame

RedStone challenges its community to unleash their creativity through monthly competitions. With categories ranging from Twitter threads to videos, the Hall of Fame is a testament to the diverse talents within the RedStone ecosystem.

Navigating RSG Points: A Quick Guide

Key to success in the RedStone community is the accumulation of RSG points, achieved through active engagement in the Discord General Channel, boosting the server, and participating in special campaigns and tasks.

The Path to Web3 Success

What sets RedStone Finance apart is its commitment to fostering a learning environment that rewards engagement. Whether one is an airdrop farmer or a dedicated Web3 enthusiast, RedStone offers a unique pathway to success and recognition within the ever-evolving blockchain landscape.

Final Thoughts

As RedStone Finance continues to innovate and expand its reach, it stands as a vibrant example of how technology, community, and creativity can converge to create a flourishing ecosystem. RedStone is not just building a network; it's shaping the future of blockchain.

Starknet, an Ethereum Layer 2 solution, is gaining momentum with a suite of promising projects in 2023. It leverages ZK-Rollup technology to keep off-chain computation private while maintaining Ethereum’s security and composability. The system utilizes the STARK proof mechanism and Cairo, a versatile language allowing diverse dapp development. Starknet’s growth is evident with its total value locked (TVL) increasing by 4,000% to over $1.1 million.

In November 2022, Starknet introduced its native token, $STRK, for staking, voting, and fee payments. A locking period ensures a gradual distribution of tokens held by the core team and contributors.

Cairo, Starknet’s bespoke language for smart contracts, recently underwent a major upgrade with Cairo 1.0, enhancing simplicity, efficiency, and developer experience.

Account Abstraction is another key innovation within Starknet, enabling smart-contract-based wallets that alleviate the need for remembering seed phrases or private keys, as showcased by projects like Argent X and Braavos.

With the basics covered, let’s dive into the top 10 Starknet projects of 2023:

Argent X: A secure decentralized wallet that eliminates the need for a seed phrase, providing a multi-signature and social recovery framework.

Braavos: A self-custodial wallet utilizing account abstraction for improved user experience, now with open-source account contracts.

Orbiter Finance: A cross-rollup Layer 2 bridge facilitating low-cost, instant transfers across various blockchain platforms.

Starkgate: A token bridge enabling transactions between Ethereum and Starknet, leveraging Starknet’s computational efficiencies.

JediSwap: An AMM offering zero gas fee swaps, with a minimal swap fee that benefits liquidity providers.

Nostra: A multi-faceted DeFi project that includes a money market, a native stablecoin (UNO), and a next-generation stablecoin swap platform.

Starknet.id: Starknet’s answer to ENS, offering a free mintable identity that acts as an on-chain passport.

ZKX: The first perpetual futures exchange on Starknet focused on self-custody and community governance, with a mission to make global yields accessible to all.

Brine: A cross-chain DEX that opts for an order book model to mitigate slippage, charging a flat transaction fee with no gas fees.

zkLend: An L2 money-market protocol that brings together scalability, speed, cost efficiency, and security.

For coders interested in digital finance opportunities, a new protocol is emerging that is founded by veterans in financial markets, cryptocurrency and blockchain expertise spanning protocol development, fixed income, interest rate and more. The IPOR Protocol provides a comprehensive solution for digital asset management and is designed to be flexible enough to meet the needs of both traditional finance and blockchain-based markets.

What is the IPOR Protocol? The IPOR protocol is a secure network built on top of Ethereum that enables users to manage their digital assets more efficiently. It provides an easy-to-use interface for users to create and manage their portfolios, as well as access real-time market data. The underlying technology behind the protocol is an advanced blockchain architecture that supports high-speed transactions with low latency. This ensures that transactions are secure and reliable while providing maximum scalability for future growth.

What sets it apart from other protocols?

The IPOR protocol stands out from other protocols due to its focus on security, flexibility and scalability. It also offers several features not available on other platforms such as portfolio rebalancing, automated trading algorithms, real-time market data analysis tools and customizable reporting features. Additionally, it leverages industry best practices such as KYC/AML and GDPR compliance to ensure user privacy and security. The team behind the IPOR Protocol has extensive experience in developing financial products for both traditional finance and blockchain-based markets. Their expertise includes areas such as fixed income trading strategies, risk management techniques, portfolio construction principles, interest rate modeling methods, algorithmic trading systems designs and more.

By leveraging their knowledge of these core areas, they have created a powerful platform for managing digital assets with robust security measures in place to protect user privacy and data integrity. Additionally, the team has integrated several sophisticated features into the platform that enable users to maximize returns on their investments while minimizing risks associated with volatile markets.

Overall, the IPOR Protocol represents a major step forward in terms of providing users with an efficient way to manage their digital assets securely. Its focus on combining traditional finance best practices with cutting edge blockchain technologies makes it an ideal platform for coders looking to take advantage of new opportunities in digital finance markets. The team behind the project has extensive experience in financial markets which makes them uniquely qualified to deliver a comprehensive product capable of meeting both personal investing needs as well as institutional requirements for asset management solutions. If you're looking for an innovative way to get involved in digital finance markets then look no further than the IPOR Protocol!

You can follow me on twitter for more alpha news :

https://twitter.com/YeJunHyun1

ZORA is an NFT marketplace protocol. It never goes down, it’s composable, immutable, universally accessible, and censorship-resistant. ZORA V3 includes some novel mechanisms that incentivize platforms built on the protocol, as well as a groundbreaking modular architectural design that allows for a permissionless system that can continue to deploy new versions.

1. Visit the ZORA website.

2. Connect your ETH wallet.

3. Now buy NFTs for min 0.01 ETH to be eligible.

4. You can buy this NFT for exactly 0.01 ETH

   https://create.zora.co/collections/0x7e694f81251318bb9d9b06288a8c35f17e1ebd0b

5. Early users interacting with the platform may get an airdrop if they launch their token.

There have been many "ZK-EVM" projects making flashy announcements recently. Polygon open-sourced their ZK-EVM project, ZKSync released their plans for ZKSync 2.0, and the relative newcomer Scroll announced their ZK-EVM recently. There is also the ongoing effort from the Privacy and Scaling Explorations team, Nicolas Liochon et al's team, an alpha compiler from the EVM to Starkware's ZK-friendly language Cairo, and certainly at least a few others I have missed.

The core goal of all of these projects is the same: to use ZK-SNARK technology to make cryptographic proofs of execution of Ethereum-like transactions, either to make it much easier to verify the Ethereum chain itself or to build ZK-rollups that are (close to) equivalent to what Ethereum provides but are much more scalable. But there are subtle differences between these projects and what tradeoffs they are making between practicality and speed. This post will attempt to describe a taxonomy of different "types" of EVM equivalence and what are the benefits and costs of trying to achieve each type.

Type 1 ZK-EVMs strive to be fully and uncompromisingly Ethereum-equivalent. They do not change any part of the Ethereum system to make it easier to generate proofs. They do not replace hashes, state trees, transaction trees, precompiles, or any other in-consensus logic, no matter how peripheral.

The goal is to be able to verify Ethereum blocks as they are today - or at least verify the execution-layer side (so, beacon chain consensus logic is not included, but all the transaction execution and smart contract and account logic are included).

Type 1 ZK-EVMs are what we ultimately need to make the Ethereum layer one itself more scalable. In the long term, modifications to Ethereum tested out in Type 2 or Type 3 ZK-EVMs might be introduced into Ethereum proper, but such a re-architecting comes with its own complexities.

Type 1 ZK-EVMs are also ideal for rollups because they allow rollups to reuse a lot of infrastructures. For example, Ethereum execution clients can be used as-is to generate and process roll-up blocks (or at least, they can be once withdrawals are implemented and that functionality can be re-used to support ETH being deposited into the rollup), so tools such as block explorers, block production, etc. is very easy to re-use.

Disadvantage: prover time

Ethereum was not originally designed around ZK-friendliness, so there are many parts of the Ethereum protocol that take a large amount of computation to ZK-prove. Type 1 aims to replicate Ethereum exactly, and so it has no way of mitigating these inefficiencies. At present, proofs for Ethereum blocks take many hours to produce. This can be mitigated either by clever engineering to massively parallelize the prover or in the longer term by ZK-SNARK ASICs.

Type 2 ZK-EVMs strive to be exactly EVM-equivalent, but not quite Ethereum-equivalent. That is, they look exactly like Ethereum "from within", but they have some differences on the outside, particularly in data structures like the block structure and state tree.

The goal is to be fully compatible with existing applications, but make some minor modifications to Ethereum to make development easier and to make proof generation faster.

Advantage: perfect equivalence at the VM level

Type 2 ZK-EVMs make changes to data structures that hold things like the Ethereum state. Fortunately, these are structures that the EVM itself cannot access directly, and so applications that work on Ethereum would almost always still work on a Type 2 ZK-EVM rollup. You would not be able to use Ethereum execution clients as-is, but you could use them with some modifications, and you would still be able to use EVM debugging tools and most other developer infrastructure.

There are a small number of exceptions. One incompatibility arises for applications that verify Merkle proofs of historical Ethereum blocks to verify claims about historical transactions, receipts or state (eg. bridges sometimes do this). A ZK-EVM that replaces Keccak with a different hash function would break these proofs. However, I usually recommend against building applications this way anyway, because future Ethereum changes (eg. Verkle trees) will break such applications even on Ethereum itself. A better alternative would be for Ethereum itself to add future-proof history access precompiles.

Disadvantage: improved but still slow prover time

Type 2 ZK-EVMs provide faster prover times than Type 1 mainly by removing parts of the Ethereum stack that rely on needlessly complicated and ZK-unfriendly cryptography. Particularly, they might change Ethereum's Keccak and RLP-based Merkle Patricia tree and perhaps the block and receipt structures. Type 2 ZK-EVMs might instead use a different hash function, eg. Poseidon. Another natural modification is modifying the state tree to store the code hash and keccak, removing the need to verify hashes to process the EXTCODEHASH and EXTCODECOPY opcodes.

These modifications significantly improve prover times, but they do not solve every problem. The slowness from having to prove the EVM as-is, with all of the inefficiencies and ZK-unfriendliness inherent to the EVM, still remains. One simple example of this is memory: because an MLOAD can read any 32 bytes, including "unaligned" chunks (where the start and end are not multiples of 32); an MLOAD can't simply be interpreted as reading one chunk; rather, it might require reading two consecutive chunks and performing bit operations to combine the result.

Who's building it?

Scroll's ZK-EVM project is building toward a Type 2 ZK-EVM, as is Polygon Hermez. That said, neither project is quite there yet; in particular, a lot of the more complicated precompiles have not yet been implemented. Hence, at the moment, both projects are better considered Type 3.

One way to significantly improve worst-case prover times is to greatly increase the gas costs of specific operations in the EVM that are very difficult to ZK-prove. This might involve precompiles, the KECCAK opcode, and possibly specific patterns of calling contracts or accessing memory or storage, or reverting.

Changing gas costs may reduce developer tooling compatibility and break a few applications, but it's generally considered less risky than "deeper" EVM changes. Developers should take care not to require more gas in a transaction than fits into a block, never to make calls with hard-coded amounts of gas (this has already been standard advice for developers for a long time).

An alternative way to manage resource constraints is to simply set hard limits on the number of times each operation can be called. This is easier to implement in circuits but plays much less nicely with EVM security assumptions. I would call this approach Type 3 rather than Type 2.5.

Type 3 ZK-EVMs are almost EVM-equivalent, but make a few sacrifices to exact equivalence to further improve prover times and make the EVM easier to develop.

Advantage: easier to build, and faster prover times

Type 3 ZK-EVMs might remove a few features that are exceptionally hard to implement in a ZK-EVM implementation. Precompiles are often at the top of the list here;. Additionally, Type 3 ZK-EVMs sometimes also have minor differences in how they treat contract code, memory, or stack.

Disadvantage: more incompatibility

The goal of a Type 3 ZK-EVM is to be compatible with most applications and require only minimal re-writing for the rest. That said, there will be some applications that would need to be rewritten either because they use pre-compiles that the Type 3 ZK-EVM removes or because of subtle dependencies on edge cases that the VMs treat differently.

Who's building it?

Scroll and Polygon are both Type 3 in their current forms, though they're expected to improve compatibility over time. Polygon has a unique design where they are ZK-verifying their own internal language called zkASM, and they interpret ZK-EVM code using the zkASM implementation. Despite this implementation detail, I would still call this a genuine Type 3 ZK-EVM; it can still verify EVM code, it just uses some different internal logic to do it.

Today, no ZK-EVM team wants to be a Type 3; Type 3 is simply a transitional stage until the complicated work of adding precompiles is finished, and the project can move to Type 2.5. In the future, however, Type 1 or Type 2 ZK-EVMs may become Type 3 ZK-EVMs voluntarily by adding in new ZK-SNARK-friendly precompiles that provide functionality for developers with low prover times and gas costs.

A Type 4 system works by taking smart contract source code written in a high-level language (e.g. Solidity, Vyper, or some intermediate that both compile to) and compiling that to some language that is explicitly designed to be ZK-SNARK-friendly.

Advantage: very fast prover times

There is a lot of overhead that you can avoid by not ZK-proving all the different parts of each EVM execution step, and starting from the higher-level code directly.

I'm only describing this advantage with one sentence in this post (compared to a big bullet point list below for compatibility-related disadvantages), but that should not be interpreted as a value judgment! Compiling from high-level languages can greatly reduce costs and help decentralization by making it easier to be a prover.

Disadvantage: more incompatibility

A "normal" application written in Vyper or Solidity can be compiled down and it would "just work", but there are some important ways in which very many applications are not "normal":

• Contracts may not have the same addresses in a Type 4 system as in the EVM, because CREATE2 contract addresses depend on the exact bytecode. This breaks applications that rely on not-yet-deployed "counterfactual contracts", ERC-4337 wallets, EIP-2470 singletons, and many other applications.

• Handwritten EVM bytecode is more difficult to use. Many applications use handwritten EVM bytecode in some parts for efficiency. Type 4 systems may not support it, though there are ways to implement limited EVM bytecode support to satisfy these use cases without going through the effort of becoming a full-on Type 3 ZK-EVM.

• Lots of debugging infrastructure cannot be carried over, because such infrastructure runs over the EVM bytecode. That said, this disadvantage is mitigated by the greater access to debugging infrastructure from "traditional" high-level or intermediate languages (e.g. LLVM).

Developers should be mindful of these issues.

Who's building it?

ZKSync is a Type 4 system, though it may add compatibility for EVM bytecode over time. Nethermind's Warp project is building a compiler from Solidity to Starkware's Cairo, which will turn StarkNet into a de-facto Type 4 system.

The types are not unambiguously "better" or "worse" than other types. Rather, they are different points on the tradeoff space: lower-numbered types are more compatible with existing infrastructure but slower, and higher-numbered types are less compatible with existing infrastructure but faster. In general, it's healthy for the space that all of these types are being explored.

Additionally, ZK-EVM projects can easily start at higher-numbered types and jump to lower-numbered types (or vice versa) over time. For example:

• A ZK-EVM could start as Type 3, deciding not to include some features that are especially hard to ZK-prove. Later, they can add those features over time, and move to Type 2.

• A ZK-EVM could start as Type 2, and later become a hybrid Type 2 / Type 1 ZK-EVM, by providing the possibility of operating either in full Ethereum compatibility mode or with a modified state tree that can be proven faster. Scroll is considering moving in this direction.

• What starts off as a Type 4 system could become Type 3 over time by adding the ability to process EVM code later on (though developers would still be encouraged to compile direct from high-level languages to reduce fees and prover times)

• A Type 2 or Type 3 ZK-EVM can become a Type 1 ZK-EVM if Ethereum itself adopts its modifications in an effort to become more ZK-friendly.

• A Type 1 or Type 2 ZK-EVM can become a Type 3 ZK-EVM by adding a precompile for verifying code in a very ZK-SNARK-friendly language. This would give developers a choice between Ethereum compatibility and speed. This would be Type 3, because it breaks perfect EVM equivalence, but for practical intents and purposes it would have a lot of the benefits of Type 1 and 2. The main downside might be that some developer tooling would not understand the ZK-EVM's custom precompiles, though this could be fixed: developer tools could add universal precompile support by supporting a config format that includes an EVM code equivalent implementation of the precompile.

Personally, my hope is that everything becomes Type 1 over time, through a combination of improvements in ZK-EVMs and improvements to Ethereum itself to make it more ZK-SNARK-friendly. In such a future, we would have multiple ZK-EVM implementations which could be used both for ZK rollups and to verify the Ethereum chain itself. Theoretically, there is no need for Ethereum to standardize on a single ZK-EVM implementation for L1 use; different clients could use different proofs, so we continue to benefit from code redundancy.

However, it is going to take quite some time until we get to such a future. In the meantime, we are going to see a lot of innovation in the different paths to scaling Ethereum and Ethereum-based ZK-rollups.