For the past few years, developing an entirely new protocol has been brutal for developers. Forking the Uniswap codebase, either V2 or V3, make your customizations, spend another 50k getting said codebase re-audited, attracting new liquidity to your protocol, etc. This was a feat most teams could not push through, with most forks either not making it to prod, and the ones that did make it to proud reach nowhere near the levels volume of Uniswap. Below you can see that Uniswap V2 has been forked over half a thousand times and V3 over 70 times, and that’s just what actually made it mainnet.

Not only have DeFi protocols been an absolute PITA to bootstrap, but moreover botostrapping your own decentralized networks were hard too. Building the underlying trust networks for these systems to years. Getting validators to sign up to your network, going through the 7 hells of game theory to figure out a proper system, etc.

But, this year, all of that is changing with the coming mainnet release of Uniswap V4 Hooks & Eigen Layer’s AVS system.

There’s already plenty of content on what Uniswap V4 is, but if you don’t know, here’s a quick sypnopsis on uniswap there’s essentially about 2 main core functionaities: swapping and modifiying your LP positions. Throughout you doing these actions, hooks are smart contract functions that can essentially write their own custom functionality that happen at different stages of your transaction to essentially overwrite or enhance what ‘s happening on a Uniswap transaction.

• beforeSwap

• afterSwap

• beforeModifyLiquidity

• afterModifyLiquidity

• etc(there’s a few more, you can see them here on the Uniswap V4 Core codebase)

Hooks allow developers to build their own dexes without having to fork the Uniswap protocol. And depending on the implementation of your protocol, it can significantly drop the costs of getting your protocol audited, as you’ll only pay for the hook functions and not the underlying protocol. So essentially, there may be many ETH <> USDC pools in the future all using uniswap hooks. Some may do something like let you swap eth on mainnet for a token on Base, others may have a lending protocol built in that pursues yield on “dead“ liquidity ticks, etc. This makes the Uniswap protocol not just an AMM protocol(which is already a feat), but also it makes the Uniswap protocol a developer platform for the next generation of DeFi dexes.

So tl;dr on this 👇

Ok, now on to EigenLayer. I’m going to greatly shorten this part but essentially, EigenLayer revolutionizes the way decentralized networks are bootstrapped by leveraging the security and trust of Ethereum's existing staker ecosystem. With EigenLayer, devs can deploy arbitrary node software across a network that inherently trusts and secures these operations, eliminating the need to build and secure a new network from scratch.

Ok so, intents are a huge subject that and DeFi intent based protocols take many different shapes and sizes, from bridging to orderbooks. The goal here is to make DeFi a significantly more better experience than CEXs buy providing better prices and liquidity. I will not cover too much about intents but its kinda sorta this meme below(mostly inspired form how CoW Swap works)

• Basically a user sends an “intent“. I have x eth and want y meme coins.

• My off chain solver takes that order and the other orders happening and attempts to find the best prices for these orders across different DEXs/Aggregators

• My solver sorts out who gets what.

• I get my tokens, then solver takes a little bit off the top.

• I get my money, no questions asked!

Intent based protocols are the next generation of DeFi protocols and will bring more users on-chain as DEXs eat into CEXs like Binance and Coinbase.

Ok so, how does all of this come together?

Alright, let's incorporate the idea of using relayers within the EigenLayer's AVS network to assist the Uniswap V4 Hooks, creating a unique and innovative intents-based protocol. Here’s an entirely new approach, focusing on enhancing transaction efficiency and reducing slippage through strategic use of relayers.

Protocol Concept: Cross Chain Swapping Protocol(Similar to Across Protocol)

Overview: This protocol is a defi protocol that enables secure and efficient cross-chain token swaps by utilizing Uniswap V4 Hooks for on-chain actions and EigenLayer’s AVS network to manage off-chain operations and cross-chain communication.

1. Core Features:

   1. Cross-Chain Swap Facilitation: Streamlines the process of swapping tokens across various blockchains, integrating multiple blockchains into a single interface.

   2. Relayer Networks for Efficiency: Uses relayers within the EigenLayer network to validate and relay transaction data between chains, ensuring timely and secure transfers.

   3. Transaction Cost Optimization: Leverages Uniswap V4 Hooks to dynamically adjust the swapping process based on the current gas fees and exchange rates, aiming to minimize user costs.

   4. Enhanced Security Protocols: Implements advanced security measures, including multi-signature confirmations and smart contract audits, to protect against common cross-chain vulnerabilities like replay attacks.

   How It Works:

   1. Setting Up Swap Intents: Users specify the details of the swap, including the asset and amount they wish to swap and the target blockchain. This intent is processed by ChainBridge and set up using a beforeSwap hook.

   2. Cross-Chain Communication: EigenLayer relayers facilitate the communication between blockchains. They verify the user's assets on the source chain, lock or burn these assets, and instruct the target chain to mint or unlock the corresponding amount of the target asset.

   3. Optimizing the Swap: During the swap execution, Uniswap V4’s beforeSwap hook is used to check for the best exchange rates and lowest transaction fees, adjusting the swap parameters in real time. After the execution, the afterSwap hook finalizes the transaction details, ensuring everything aligns with the initial user intent and current market conditions.

   4. Completing the Transaction: Once the transaction is verified on the target blockchain, the relayers update the transaction status on both chains. The user receives the swapped asset in their wallet on the target blockchain, and the transaction is completed with final confirmations.

What are the advantages of an NFT AMM & How does an NFT AMM work?

The advantages of NFT AMMs are quite clear, you're able to create instant liquidity on the NFT collection instead of traders waiting on someone to bid for their NFT. This is helpful for traders who need instant liquidity on their NFTs. There are many different designs of NFT AMMs, but the most compelling one is by the team at Tensor on Solana (tensor.trade). What they incentivize is for traders to create "market-making orders" on an entire NFT collection. This market-making order is two-sided, one being a "buy side," where the trader deposits a certain amount of SOL to purchase a certain amount of NFTs, and on the other side being the "sell side," where they can list some of their NFTs in this collection for purchase. The trader makes money on the spread here as the purchase and selling side moves the price along the bonding curve, literally allowing the trader to buy low and sell high.

Tensor's NFT AMM utilizes the concept of bonding curves to determine the pricing of NFTs within the market-making orders. When a trader creates a market-making order on Tensor, they specify a starting price and a "change by" or delta value, which determines how much the price changes after each trade. This delta value can be set as a fixed amount in SOL or as a percentage of the current price. As traders buy or sell NFTs from the market-making order, the price moves along the bonding curve, adjusting according to the delta value. For example, if the starting price is 10 SOL and the delta is set to 1 SOL, each buy will increase the price by 1 SOL, and each sell will decrease the price by 1 SOL. This bonding curve mechanism ensures a dynamic and fair price discovery process within the Tensor NFT AMM, allowing traders to automate their "buy low, sell high" strategy while providing liquidity to the NFT market.

Let’s Implement A Tensor-Like NFT AMM As A Uniswap V4 Hook

The core innovation of Uniswap V4 is hooks, functions that we can trigger at different stages in a pool’s lifecycle/activity. Hooks allow us to tailor the Uniswap AMM to our specific use cases, the design space is unlimited. By leveraging Uniswap V4 hooks, we can build NFTFi protocols that provide liquidity, price discovery, and unique financial mechanisms for NFT collections.

Implementing Our NFTAMMHook

Code Here

A. Market Making Functionality

The NFTAMMHook contract allows market makers to create orders by specifying the desired price range and quantity of NFTs they wish to trade. The marketMake function is the core of the market making functionality, enabling market makers to create orders and deposit NFTs into the AMM.

When a market maker creates an order, they specify the following parameters:

• _nftAddress: The address of the NFT collection.

• startingBuyTick: The starting tick for buying NFTs.

• startingSellTick: The starting tick for selling NFTs.

• tokenIds: The token IDs of the NFTs being sold.

• delta: The percentage change for each order on the bonding curve.

• fee: The swap fee for buying or selling into the order.

• maxNumOfNFTs: The maximum number of NFTs the order is willing to purchase.

The market maker also sends Ether (msg.value) along with the function call to cover the cost of buying NFTs.

Inside the marketMake function, the hook performs the following steps:

1. It validates the input parameters to ensure the NFT address matches the collection, the sell tick is greater than the buy tick, and there is enough Ether to cover the maximum number of NFTs to buy.

2. It creates a new MMOrder struct to store the order details, including the starting buy and sell ticks, the current tick, the Ether balance, the maximum number of NFTs, the delta, the fee, and the NFT address.

3. It calculates the square root price ratio (sqrtPriceX96) for each NFT being sold using the createSqrtPriceForSingleToken function, which takes into account the starting sell tick and the delta.

4. It transfers the NFTs from the market maker to the hook contract using the safeTransferFrom function of the ERC721 contract.

5. It determines the wrapped token share for the deposited NFTs using the determineWrappedTokenShare function, which calculates the total value of the NFTs in terms of the wrapped token based on the bonding curve.

The determineWrappedTokenShare function calculates the wrapped token share by:

1. Converting the square root price ratio to a price ratio.

2. Iterating over the token IDs and calculating the current price for each NFT based on the bonding curve.

3. Summing up the total value of the NFTs in terms of the wrapped token.

4. Converting the total value to Ether and updating the market maker's balance in the makerBalances mapping.

The bonding curve is defined by the starting sell tick and the delta, which determines how the price changes for each order. The createSqrtPriceForSingleToken function calculates the square root price ratio for a single NFT based on the starting tick, delta, and the index of the NFT in the array of token IDs.

B. Wrapped Token and Balance Tracking

The NFTAMMHook contract itself represents the wrapped NFT token and tracks the balances of the market makers' orders. The hook contract inherits from the ERC20 contract, allowing it to mint and manage the wrapped tokens.

When a market maker creates an order and deposits NFTs, the hook mints wrapped tokens equivalent to the total value of the deposited NFTs. The makerBalances mapping keeps track of each market maker's balance in terms of the wrapped token.

C. Buying NFTs (Swap Functionality)

When a trader wants to buy an NFT using Ether, they interact with the frontend, which in turn calls the createBuyBidOrder function on the hook contract. This function creates a buy bid order, specifying the market maker's order ID, the desired NFT ID, and the amount of Ether the trader is willing to pay.

The createBuyBidOrder function performs the following steps:

1. It validates that the deposit amount is greater than zero and that the deposit amount is equal to or greater than the current price of the NFT based on the current tick.

2. It creates a BidOrder struct with the relevant information, including the market maker's address, the immediate flag (set to true), the Ether value, the NFT ID, the current tick, and the order ID.

3. It stores the bid order in the bidsToBuyers mapping, associating the bid ID with the trader's address.

4. It returns the encoded bid order data.

The frontend then calls the swap function on the swapRouter contract, passing the pool key, swap parameters, test settings, and the encoded bid order data.

Inside the swap function, the afterSwap hook is called, which handles the logic to transfer the NFT from the hook to the trader. The afterSwap function performs the following steps:

1. It decodes the bid order data to retrieve the relevant information.

2. If the swap is a "zero for one" swap (Ether for NFT), it transfers the NFT from the hook contract to the trader using the safeTransferFrom function of the ERC721 contract.

3. It sends the Ether payment to the market maker using the call function with the bidOrder.ethValue.

4. It updates the market maker's order by calculating the new starting sell tick based on the current square root price ratio and the delta.

After the swap is complete, the trader receives the NFT instead of the wrapped tokens.

D. Selling NFTs

The selling functionality allows traders to sell their NFTs to the market maker's order. The process is similar to buying NFTs, but in reverse.

The trader calls the createSellOrder function on the hook contract, specifying the market maker's order ID, the NFT ID they want to sell, and the market maker's address.

The createSellOrder function performs the following steps:

1. It retrieves the market maker's order using the order ID.

2. It transfers the NFT from the trader to the hook contract using the safeTransferFrom function of the ERC721 contract.

3. It creates a BidOrder struct with the relevant information, including the market maker's address, the immediate flag (set to true), the current price of the NFT based on the current tick, the NFT ID, the current tick, and the order ID.

4. It stores the bid order in the bidsToBuyers mapping, associating the bid ID with the trader's address.

5. It returns the encoded bid order data.

The frontend then calls the swap function on the swapRouter contract, passing the pool key, swap parameters, test settings, and the encoded bid order data.

Inside the swap function, the afterSwap hook is called, which handles the logic to transfer the NFT from the hook to the market maker and send the Ether payment to the trader. The afterSwap function performs the following steps:

1. It decodes the bid order data to retrieve the relevant information.

2. If the swap is a "one for zero" swap (NFT for Ether), it transfers the NFT from the hook contract to the market maker using the safeTransferFrom function of the ERC721 contract.

3. It updates the market maker's order by calculating the new starting buy tick based on the current square root price ratio and the delta.

4. It subtracts the Ether value from the market maker's Ether balance in the order.

After the swap is complete, the market maker receives the NFT, and the trader receives the Ether payment.

Our NFTAMMHook shows how Uniswap V4's hook system can work well with the new world of NFTFi, helping to create active markets for NFTs and opening up new chances for market makers and traders. As the NFT market keeps growing, developers have the chance to use Uniswap V4 hooks as a way of creating new NFTFi systems amongst the myriad of other design spaces.

You can see the code for the NFTAMMHook below!

https://github.com/adam0x7/nft-amm-hook

Efforts to bridge this gap have led to proposals such as EIP-3074, which introduces new opcodes, AUTH and AUTHCALL, to allow EOAs to delegate control to smart contracts for specific operations . However, concerns have been raised regarding the forward-compatibility of EIP-3074 with future account abstraction efforts, particularly in light of the anticipated transition to a pure-smart-contract-wallet world.

EIP-7702 emerges as a novel proposal aimed at addressing these concerns while providing functionality similar to EIP-3074. This EIP introduces a new transaction type that empowers EOAs to temporarily set their code to a smart contract for the duration of a single transaction. By enabling EOAs to execute smart contract logic on a per-transaction basis, EIP-7702 opens up a myriad of possibilities for complex interactions and advanced use cases.

The primary motivation behind EIP-7702 lies in its potential to enable key functionalities such as batching, sponsorship, and privilege de-escalation, while ensuring forward-compatibility with future account abstraction efforts. By allowing EOAs to temporarily assume smart contract capabilities, EIP-7702 aims to bridge the gap between the current limitations of EOAs and the envisioned future of Ethereum account abstraction .

In the following sections, we will delve into the technical specifications of EIP-7702, exploring its implementation details and potential implications for the Ethereum ecosystem. We will also examine the advantages of EIP-7702 over alternative proposals and discuss the security considerations and challenges associated with its adoption.

Motivation behind EIP-7702

EIP-7702 aims to address the growing demand for enhanced functionality in EOAs by enabling them to temporarily assume smart contract capabilities. The primary motivations behind this proposal are:

1. Enabling key use cases such as batching, sponsorship, and privilege de-escalation, which are currently limited or require complex workarounds.

2. Addressing the forward-compatibility concerns associated with EIP-3074, particularly in the context of future account abstraction efforts.

3. Facilitating a more seamless transition towards a pure-smart-contract-wallet world, where EOAs are eventually phased out in favor of smart contract accounts.

While EIP-3074 provides a solution for delegating control to smart contracts, it introduces new opcodes (AUTH and AUTHCALL) that may become obsolete in a future account abstraction landscape. EIP-7702 seeks to provide similar functionality without introducing new opcodes, thereby ensuring better compatibility with future Ethereum upgrades.

How EIP-7702 works

EIP-7702 introduces a new EIP-2718 transaction type with the TransactionType set to TX_TYPE(TBD). The TransactionPayload for this new transaction includes the following fields:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, [[contract_code, y_parity, r, s], ...], signature_y_parity, signature_r, signature_s])

The key feature of this new transaction type is the contract_code field, which allows EOAs to temporarily set their code to a smart contract for the duration of the transaction. The intrinsic cost of the transaction is inherited from EIP-2930, with additional costs for the contract_code field.

The execution process for EIP-7702 transactions involves the following steps:

1. For each [contract_code, y_parity, r, s] tuple, verify the signature and set the contract code of the signer's account to contract_code.

2. Execute the transaction as a regular transaction.

3. At the end of the transaction, reset the contract code of each signer's account back to empty.

This approach allows EOAs to temporarily assume smart contract capabilities without permanently altering their account state, enabling a wide range of complex interactions and use cases.

Advantages of EIP-7702

EIP-7702 offers several advantages over existing proposals and the current EOA functionality:

1. Compatibility with EIP-3074 use cases: EIP-7702 can be used to implement the same use cases as EIP-3074, such as batching, sponsorship, and privilege de-escalation. This can be achieved by replacing the AUTH and AUTHCALL opcodes with calls to the temporary contract code set by EIP-7702 transactions.

2. Forward-compatibility with future account abstraction: Unlike EIP-3074, which introduces new opcodes that may become obsolete in a future account abstraction landscape, EIP-7702 leverages existing transaction types and mechanisms. This approach ensures better compatibility with future Ethereum upgrades and reduces the risk of creating redundant or deprecated features.

3. Seamless integration with existing smart contract wallets: The temporary contract code set by EIP-7702 transactions can be based on existing smart contract wallet implementations, such as those used in ERC-4337. This allows for a more unified ecosystem and reduces the fragmentation of efforts between EOA-based solutions and smart contract wallets.

4. Simplified path to full account abstraction: EIP-7702 can be seen as an intermediate step towards full account abstraction, where all accounts are eventually replaced by smart contract accounts. By enabling EOAs to temporarily assume smart contract capabilities, EIP-7702 facilitates a gradual transition towards a pure-smart-contract-wallet world, reducing the need for abrupt and disruptive changes to the Ethereum ecosystem.

5. Reduced complexity and gas costs compared to EIP-3074: EIP-7702 achieves similar functionality to EIP-3074 without introducing new opcodes, which can lead to reduced complexity in the Ethereum protocol and potentially lower gas costs for users.

Potential Challenges & Considerations

These are all discussed in the current discussion on EIP-7702 on the Ethereum Magicians Forum as of 05/07/24

https://ethereum-magicians.org/t/eip-set-eoa-account-code-for-one-transaction/19923

• Nonce management: There is an ongoing debate about whether the contract_code signature should sign over the account's nonce. Some argue that signing over the nonce would invalidate popular use cases of account abstraction, such as alternative signers and transaction delegation. Others propose signing over a user-picked maxNonce or delegating nonce control to an external nonceManager contract.

• Signature invalidation: The contract_code signature could potentially be made invalid by introducing a "code assumption nonce" distinct from the transaction nonce. This would allow EOAs to revoke existing signatures over code and prevent the "perpetual signature" risk identified with EIP-3074.

• Compatibility with existing contracts: There may be compatibility issues with existing contracts that use anti-patterns like <address>.transfer() or erc721.safeTransferFrom(). If the recipient has signed a contract_code that does not have a receive() or onERC721Received() function, these transfers might fail.

• Standardization of contracts: If EIP-7702 is implemented, there may be a need for standardization around which contracts are used, similar to ERC-4337 entry points and EIP-3074 invokers, to ensure safety and verifiability.

• Gas costs: The intrinsic cost of the new transaction type should account for the contract_code size and the cost of jump destination validation (EIP-3860).

• Quantum computer concerns: The argument that quantum computers will eventually break ECDSA, necessitating a move away from EOAs, may not be sound. If ECDSA breaks, the entire Ethereum ecosystem would be at risk, and a plan for moving towards quantum-safe curves would be needed.

In the evolving landscape of decentralized technology, Solana emerges as a cornerstone for projects dedicated to decentralized physical infrastructure (DePin), championing a vision where decentralized networks harness collective computational resources for tomorrow’s groundbreaking applications. Most recently, the team at Nosana stands out with a new approach leveraging the Solana blockchain to orchestrate a distributed network of GPUs. Nosana's mission is to democratize access to high-performance computing, specifically addressing the urgent needs of AI and machine learning developers who face the dual challenges of computational resource scarcity and the high costs associated with centralized cloud services. By providing a decentralized, extremely cost-effective alternative, Nosana not only aims to solve these issues but also posits a long-term transformation in the development and deployment of AI models. As open-source models continue to match and even surpass the capabilities of proprietary systems, the demand for an open, scalable, and efficient computational platform grows. Nosana, with its permissionless, non-vendor lock-in infrastructure, is perfectly positioned to be a beacon of light for the Open Source AI community and helping developers across the globe have equitable access to the computational power necessary to drive AI forward.

https://nosana.io/

What is a Mixture of Expert Model & How does it Defer from GPT-4?

Mixture of Experts (MoE) models and architectures like GPT-4 represent are two very distinct approaches within the realm of LLMs. While GPT-4 is a large-scale, generative pre-trained transformer model designed for a wide range of tasks, MoE models employ a different strategy. MoE models consist of multiple specialized sub-models or "experts," each adept at handling different types of data or tasks, and a gating mechanism that decides which expert to use for a given input. This architecture allows MoE models to leverage the strengths of diverse experts, potentially offering more adaptable and efficient solutions for specific problems compared to a single, monolithic model like GPT-4, known for its tendency to hallucinate.

Drawbacks of MoE Models in Production

While MoE models are interesting, implementing Mixture of Experts models in production environments presents several challenges, which can impact their feasibility and efficiency for creating applications:

1. Resource Intensity: MoE models can be resource-intensive, both in terms of computational power and memory usage. As each expert within the model could be a complex model itself, running multiple experts in parallel for inference requires significant GPU resources, which can escalate operational costs.

2. Model Complexity: The architecture of MoE models adds a layer of complexity in terms of design, implementation, and maintenance. Training involves not only optimizing the individual experts but also the gating mechanism that routes inputs to the appropriate experts. This complexity can make it challenging to debug, update, or iterate on MoE models compared to simpler architectures.

3. Latency Issues: For real-time applications, the increased computational overhead of selecting and utilizing the appropriate experts can introduce latency. This is especially problematic when low response times are critical, such as in user-facing applications or when processing streaming data.

4. Data Routing and Scaling: Efficiently routing data to the correct experts and scaling the model to handle increasing volumes of data or additional problem domains require sophisticated mechanisms. This can involve dynamic load balancing and potentially retraining the model to incorporate new experts as the types of inputs or tasks evolve.

5. Overfitting Risk: There's a risk that individual experts might overfit to their specific subsets of the training data, especially if the data is not diverse enough or if the experts are too specialized. This overfitting can degrade the model's performance on unseen data.

6. Deployment and Operational Complexity: Deploying and managing MoE models in production can be operationally complex. It requires advanced infrastructure for load balancing, monitoring, and dynamically allocating resources to different experts based on demand.

How Nosana Could Address MoE Model Challenges:

In the midst of the ongoing chip shortage that has significantly hindered the AI industry, developers and researchers find themselves in a challenging position. The shortage has led to a scarcity of available GPUs, making it difficult for many to access the computational resources necessary for training and deploying sophisticated AI models, including Mixture of Experts (MoE) models. These models, which require substantial computational power due to their complexity and the need to run multiple specialized sub-models in parallel, are particularly bottlenecked by current hardware limitations. However, decentralized computing platforms like Nosana, can perhaps present a promising solution to these challenges over coming years as the network expands to the have enough of the necessary hardware to support these models.

1. Expanding Access to Computational Resources: Nosana's decentralized network harnesses the idle GPU power from a vast array of devices across the globe. By aggregating these resources, Nosana can potentially provide the extensive computational capacity necessary for running MoE models, circumventing the limitations posed by the chip shortage.

2. Cost-Effectiveness: One of the primary advantages of a decentralized approach like Nosana's is the potential for more cost-effective access to computational resources. Rather than competing for scarce and expensive GPUs on the open market or incurring high costs from cloud providers, developers can tap into Nosana's distributed network at potentially lower prices, potentially making MoE models more financially viable.

3. Scalability and Flexibility: Nosana's distributed nature allows for dynamic scaling. As the demand for computational power increases, the network can theoretically scale to include more nodes, providing additional resources without the need for centralized infrastructure expansion. This flexibility is crucial for MoE models, which may require varying amounts of compute depending on the task and the number of experts involved.

4. Reducing Latency and Increasing Efficiency: By distributing computation across multiple nodes, Nosana can help reduce the latency associated with running complex MoE models. Computational tasks can be processed closer to the data source, and load balancing across the network can ensure that no single node becomes a bottleneck, improving overall efficiency.

5. Enabling More Innovation: With easier and more affordable access to computational resources, researchers and developers can experiment more freely with MoE architectures, optimizing their models and exploring new applications. This democratization of access could lead to significant advancements in AI, driving innovation in fields that were previously hampered by resource constraints.

The potential of the Nosana network to democratize access to the computational power necessary for Mixture of Experts (MoE) models could mark a pivotal moment in the promise of intersection of AI & crypto. Given the inherently high hardware requirements of MoE models, the success of Nosana hinges on its ability to aggregate and provide access to hardware that meets these demands. If Nosana can ensure the availability of adequate computational resources, it can be a leader for the open-source community, challenging the dominance of entities like OpenAI by helping to level the computational playing field.

This democratization of AI infrastructure is not just about technological innovation; it's also critical countermeasure against the potential for regulatory capture by corporate AI giants. As global regulators craft legal frameworks for AI, there's a real risk that well-resourced companies could influence these regulations to favor proprietary models, stifling open-source innovation. By decentralizing AI infrastructure, Nosana empowers a broader range of developers to contribute to and shape the future of AI, ensuring that the evolution of artificial intelligence is driven by a diverse, global community rather than a select few. In this context, Nosana doesn't just offer a technical solution; it represents a strategic move towards maintaining the openness and collaborative spirit that has always been at the heart of AI's most groundbreaking advancements.

Some useful resources for understanding more about Nosana and Mixture of Experts

https://nosana.io/

https://mistral.ai/news/mixtral-of-experts/

This article is geared towards developers rooted in EVM-based chains, and aims to provide a detailed, side-by-side comparison of the Ethereum Virtual Machine (EVM) and its counterpart in Solana. According to the Electric Capital Developer Report 2023, the blockchain developer workforce is swiftly moving towards a multi-chain paradigm. As the Solana ecosystem continues to expand, its influence will become undeniable and there will be a demand for more Solana Developers. I predict that knowing Ethereum and Solana will soon be as essential for blockchain developers as JavaScript and Python are for traditional developers. So, let's dive in and explore what sets these two influential technologies apart.

First, lets define what a “Virtual Machine“ is in the context of blockchains

In the context of blockchain technology, a virtual machine (VM) is an execution environment that processes transactions and smart contracts/programs on a blockchain. It serves as a sandboxed environment for running code, ensuring the security and integrity of the blockchain network. For example, the Ethereum Virtual Machine (EVM) is a well-known VM that processes smart contracts on the Ethereum blockchain. Similarly, the Solana Virtual Machine (SVM) is the execution environment that processes transactions and smart contracts/programs on the Solana blockchain. Unlike traditional virtual machines, which run on a physical computer, a blockchain VM is a decentralized and distributed system that runs on multiple nodes across the network, ensuring consensus and immutability of the executed code.

What are the key components to a virtual machine?

1. Transaction Speed and Throughput: This refers to how fast transactions are processed and how many transactions the network can handle per second. Higher throughput and faster processing times are desired for scalability and user experience.

2. Transaction Cost: This is about the fees associated with executing transactions. Lower costs are preferable, especially for applications requiring high transaction volumes.

3. Consensus Mechanism: The underlying consensus mechanism (like Proof of Work, Proof of Stake, etc.) impacts network security, energy consumption, and the ability to scale. Different mechanisms have their own strengths and weaknesses.

4. Client Diversity: This pertains to the variety of software clients that can operate on the network. Greater client diversity can enhance network resilience and security.

5. Blockspace Management: This involves how efficiently the network manages the space in each block. Efficient blockspace management can lead to improved scalability and throughput.

6. Smart Contract Capabilities: The flexibility, complexity, and efficiency of smart contract execution are critical. This includes how well the VM supports various programming languages and smart contract standards.

7. Decentralization: The degree to which the network is decentralized affects its resilience, security, and trustlessness. Greater decentralization is generally seen as a strength.

8. Security and Robustness: This encompasses the overall security of the network and its resistance to attacks. It includes considerations like the security model of the VM and the track record of the platform in handling vulnerabilities.

9. Interoperability: The ability to interact with other blockchains and external systems is increasingly important for wider adoption and utility.

10. Scalability Solutions: Includes layer 2 solutions, sharding, and other technologies designed to increase the network's capacity to handle more transactions and complex operations.

11. Energy Efficiency: Particularly relevant in the context of environmental impact, this involves how much energy the network consumes for its operations.

The debate between the Ethereum Virtual Machine (EVM) and Solana's Virtual Machine (SVM) is so captivating due to the contrast in their architectural philosophies and the trade-offs they represent across key performance criteria. Ethereum, with its EVM, has embraced a modular approach. This framework allows for flexibility, scalability, and diverse applications by integrating various layer 2 solutions and other modular components, albeit sometimes at the cost of transaction speed and efficiency. Solana's SVM, in contrast, adopts a monolithic approach, wherein its core functionalities are tightly integrated to provide high throughput and low transaction costs, but with potential trade-offs in aspects like decentralization and client diversity(though will be fixed when Firedancer comes out). This divergence in strategies between Ethereum and Solana is not just a technical discussion; it symbolizes the broader debate in the blockchain community about the optimal path towards achieving a balance between speed, security, scalability, and decentralization. Each approach reflects a different set of priorities and visions for the future of blockchain technology, underscoring the rich diversity and innovation within this field.

Evaluating The EVM

Here's how the EVM stacks up against these components, with notes on tradeoffs versus optimizations:

Also a quick note, this is an evaluation of the EVM with the full 2.0 roadmap implemented and not its current state as of this writing(Jan. 2024)

Transaction Speed and Throughput

Ethereum 2.0 aims to improve transaction speed and throughput significantly. The introduction of sharding is expected to increase network capacity and reduce congestion, which should lead to faster transaction processing and higher throughput. This is an optimization, although the full benefits will be realized once all phases of Ethereum 2.0 are implemented.

Transaction Cost

The shift to PoS and the introduction of sharding are expected to lower transaction costs by reducing the energy required for transaction validation and increasing network capacity. However, during periods of high demand, transaction fees can still be significant, which is a tradeoff.

Consensus Mechanism

Ethereum's transition from Proof of Work (PoW) to Proof of Stake (PoS) reduces energy consumption and potentially allows for faster transaction confirmation. This is an optimization in terms of energy efficiency and scalability, but it may introduce different security considerations compared to PoW.

Client Diversity

Ethereum 2.0 encourages client diversity by supporting multiple software clients, which can enhance network resilience and security. This is an optimization, as a diverse client ecosystem can help prevent single points of failure. However, its important to note that a large amount of the clients on lean towards Geth.

Blockspace Management

Efficient blockspace management is crucial for scalability. Ethereum 2.0's sharding mechanism is designed to optimize the use of block space across multiple shards. This is an optimization that aims to improve scalability and throughput.

Smart Contract Capabilities

The EVM supports a wide range of smart contract capabilities and is compatible with Solidity, a popular smart contract programming language. This allows for complex and flexible smart contract execution, which is an optimization for developers building on Ethereum.

Decentralization

Ethereum 2.0 maintains a high degree of decentralization through its PoS consensus mechanism and distributed network of validators. This is an optimization that aims to preserve the security and trustlessness of the network.

Security and Robustness

The security and robustness of the EVM are critical. Ethereum's track record and ongoing updates aim to address vulnerabilities and enhance security. This is an optimization, although security is an ongoing challenge for all blockchain platforms.

Interoperability

Ethereum is working towards better interoperability with other blockchains and external systems, which is important for broader adoption. This is an optimization that can increase the utility of the Ethereum network.

Scalability Solutions

Ethereum 2.0 includes scalability solutions like sharding and layer 2 chains which are designed to increase the network's capacity. These are optimizations that address the scalability challenges faced by the network.

Energy Efficiency

The switch to PoS significantly reduces Ethereum's energy consumption compared to PoW, making it more environmentally friendly. This is an optimization in response to growing concerns about the environmental impact of blockchain technology.

Evaluating The SVM

Transaction Speed and Throughput

Solana is renowned for its high transaction speed and throughput, thanks to its unique Proof of History (PoH) consensus combined with Proof of Stake (PoS). This design allows the network to process thousands of transactions per second, optimizing for performance and scalability. However, this high throughput can come with tradeoffs in terms of network centralization and hardware requirements.

Transaction Cost

Solana offers significantly lower transaction costs compared to many other blockchains. This is a major optimization as it enables more micro-transactions and encourages broader use of the network for various applications, from DeFi to NFTs. The low cost is partly due to the efficient throughput of the network.

Consensus Mechanism

Solana's hybrid PoH and PoS consensus mechanism is a distinctive feature that enables rapid transaction processing and timestamping. This is an optimization for speed and efficiency, though it differs from the more traditional PoW and PoS mechanisms, leading to unique security and decentralization considerations.

Client Diversity

As of this writing, Solana's network is predominantly run on a single client. However, the upcoming release of Firedancer aims to diversify the client ecosystem, enhancing network resilience and security. This is a step towards optimization, addressing previous concerns about client centralization.

Blockspace Management

Solana's blockspace management is highly efficient due to its high-speed infrastructure, allowing for large numbers of transactions to be included in each block. This is an optimization for scalability and user experience, although it may impose certain hardware requirements on validators.

Smart Contract Capabilities

The SVM supports a variety of programming languages, including Rust and C, which offer high performance and flexibility for developers. This is an optimization for developer engagement and complex application development.

Decentralization

Solana's decentralization is a topic of debate. While it operates a distributed network of validators, the high performance requirements for running a node can lead to a degree of centralization. This is a tradeoff in its design, balancing speed and inclusivity.

Security and Robustness

Solana focuses on maintaining high security and robustness, although it has faced challenges, including network congestions and outages. Ongoing improvements aim to address these issues, making it an area of continuous optimization and vigilance.

Interoperability

Solana is actively working towards better interoperability with other blockchains, recognizing the importance of cross-chain communication in the blockchain ecosystem. This is an optimization to enhance the network's utility and accessibility.

Scalability Solutions

Solana's architecture itself is a scalability solution, designed to handle a high volume of transactions. Continuous improvements aim to further enhance this capability, addressing the network's growing demand.

Energy Efficiency

Solana's PoH and PoS mechanisms are more energy-efficient compared to traditional PoW systems, positioning it as a more environmentally friendly option. This is an optimization in line with increasing environmental consciousness.

In summary, Solana's VM is optimized for high throughput, low transaction costs, and energy efficiency, with a focus on enhancing developer capabilities and network scalability. While it faces challenges in decentralization and network robustness, ongoing developments like Firedancer indicate a commitment to addressing these issues.

Why it doesn’t really matter which VM is better

In essence, the EVM vs. SVM debate is less about picking a clear winner and more about appreciating the varied approaches in blockchain development. Both Ethereum and Solana offer unique solutions and perspectives, reflecting the diverse and experimental nature of the industry. For developers and enthusiasts alike, the key is not to be tethered to one ecosystem but to remain adaptable and open to the array of ideas and innovations across platforms. This diversity is what fuels the dynamic growth of blockchain technology, and embracing it is crucial for anyone looking to navigate and contribute to this ever-evolving space.

If you want to learn more, here are papers and podcasts that I’ve listened to over the last couple of months to help inform how I created this article

https://x.com/VitalikButerin/status/1741190491578810445?s=20

https://squads.so/blog/solana-svm-sealevel-virtual-machine

https://solana.com/news/proof-of-history

As many of us know, interoperability is extremely important in the coming multi-chain world. But the current state of security & reliability around bridges presents a multi-faceted problem:

• Security Shortfalls in Existing Bridges: Attempts to construct bridges have been made, but these are often complex and fraught with risk. Like precarious rope bridges swaying over a chasm, they present vulnerabilities that could lead to catastrophic security breaches, leaving users and developers wary of crossing.

• Operational Inefficiencies: The absence of seamless interaction forces users to navigate a labyrinth of convoluted processes. This inefficiency is reminiscent of having to take a roundabout maritime route, cumbersome and time-consuming, just to trade simple goods.

• Trust Issues: In the current bridge landscape, trust is a scarce commodity. Sending valuable assets across these rudimentary bridges carries the risk of loss or tampering, much like sending a treasure without a convoy.

The Solution

In early 2023, a team at Gnosis introduced Hashi. Hashi emerges as a sophisticated and principled approach to bridging. It serves as a protocol that not only connects blockchain networks but also increases the sanctity and security of cross-chain communication through redundancy.

Hashi is akin to an international airport built on blockchain territory. Just as airports enable people from different countries, speaking different languages, to traverse borders safely and efficiently, Hashi facilitates a similar function for blockchain networks. Here are the key solutions Hashi provides:

• Interoperability with Integrity: Hashi creates a framework where messages and transactions are not just passed along but are assured for integrity. This is comparable to having a multi-layered security check at an airport, ensuring every individual crossing borders is authenticated.

• Streamlined Cross-Chain Communication: Hashi offers a streamlined approach to cross-chain transactions, removing the need for complex and often convoluted bridging solutions that were once the norm. It's like replacing connecting flights with a direct route, reducing the time and points of failure in a journey.

• Scalable and Secure Architecture: Hashi's architecture is designed to be both scalable and secure, addressing the needs of growing blockchain ecosystems without compromising on security. This is akin to an airport expanding its capacity while maintaining rigorous safety protocols.

• Enhanced User Experience: For the blockchain-savvy user, Hashi provides a transparent and intuitive experience for cross-chain interactions. It's similar to having a clear and concise airport sign system, guiding passengers through a seamless transit process.

• Trust Ensured by Design: With Hashi, trust is engineered into the protocol. Users and developers can have confidence that the assets and data transmitted across chains are preserved without alteration, akin to a bank's guarantee during a wire transfer.

Hashi stands not as a makeshift bridge but as a comprehensive transport system that brings robustness, efficiency, and confidence to the cross-chain communication space.

The Different Components To The Hashi Protocol

Hashi (橋)

• Custom Oracle Adapters: Users have the flexibility to construct custom oracle adapters. These adapters serve as specialized contracts that connect to external data sources, or oracles, to retrieve verifiable data, such as block hashes, which are crucial for ensuring the integrity and origin of blockchain data.

• Domain-Specific Hash Queries: Hashi allows querying an oracle for the hash of a particular ID within a given domain (e.g., the block hash from a specific chain ID). A block hash is a unique identifier that represents the state of a blockchain at a particular point in time, akin to a fingerprint for a set of transactions.

• Consensus Mechanism: It enables users to seek consensus from a set of oracles for a given ID in a domain. This is similar to getting multiple expert opinions to reach a high-confidence conclusion.

• Unanimous Agreement: Users can also query for a block hash that has been unanimously agreed upon by a set of oracles. This feature strengthens security by ensuring that only when all oracles are in absolute agreement is the hash accepted, reducing the risk of false or tampered data.

ShoyuBashi (所有橋)

• Owner Controls: The owner account has the power to set and modify the instance of Hashi to query, define oracle sets for each domain, and set thresholds for oracle consensus. This is akin to an administrator setting rules for data validation.

• Public Queries: Any user can query for an agreed-upon hash by a threshold of oracles. This threshold mechanism acts as a layer of democratic validation to determine the authenticity of a block hash.

GiriGiriBashi (ギリギリ橋)

• Initial Setup: An owner can initialize oracle sets and thresholds, similar to setting up initial security parameters.

• Adaptation and Security: Owners can replace underperforming or compromised oracles, ensuring the bridge's integrity is maintained.

• Dispute Resolution: Users have the ability to challenge an oracle’s report. Challenges can lead to the oracle being quarantined if found at fault, ensuring only reliable oracles participate.

• Re-establishing Trust: In case of widespread issues, a no-confidence state can be declared, prompting a reset in the domain by the owner, much like a system reboot after a critical error.

Yaho (ヤッホー)

• Message Dispatching: Users can dispatch messages across chains via Hashi. Yaho records these messages and emits their hashes as events, essentially announcing the successful send-off of a message.

• Message Relaying: It also provides functionality to relay stored messages to different message adapters, broadening communication capabilities.

• Combined Operations: For efficiency, Yaho can dispatch messages and relay them in a single transaction, streamlining cross-chain communication.

Yaru (やる)

• Message Execution: Yaru acts on the receiving end of the bridge, executing messages that come from Yaho, similar to a recipient acting on a received letter.

Hashi Zodiac Module

• Control Across Chains: Users can control an avatar (like a multi-signature wallet, or 'Safe') on one chain from an address on another, enabling cross-chain command and control of assets or contracts.

• Message Passing: It defines instances for Yaho to pass messages and specifies chain IDs and foreign controller addresses, creating a comprehensive cross-chain command structure.

By incorporating redundancy and a high threshold for oracle consensus, Hashi prioritizes security, even at the expense of higher gas costs and potentially slower operations. This trade-off is deemed necessary to mitigate the risks that have plagued previous bridge protocols, providing a robust solution in a landscape where security incidents can be incredibly costly.

A quick note before we proceed on about Hashi: Understanding Arbitrary Message Bridges (AMB)

Before we delve into the specifics of how Hashi operates across chains, it's essential to understand the concept of Arbitrary Message Bridges (AMB). An AMB is a protocol that enables the transmission of messages between two distinct blockchain networks. These messages can carry various types of information, such as function calls, transaction requests, or simple data transfers. In essence, an AMB acts like a courier service that connects two separate communities, allowing them to communicate and interact securely and reliably.

AMBs are pivotal in decentralized applications that require cross-chain interactions because they expand the functionality of smart contracts beyond the confines of their native blockchain. For instance, a smart contract on the Ethereum network can trigger an action on the Gnosis Chain, or vice versa, through messages passed by the AMB. It's a bridge that not only links two separate ecosystems but also enables them to work together harmoniously.

How Message Dispatching on Hashi Works ✉️

Message Transmission from Goerli to Gnosis Chain

Using the Hashi protocol to send a message from the Goerli testnet to the Gnosis Chain involves a sequence of carefully orchestrated steps that ensure the message is not only delivered but also verified and executed. Here's how the process unfolds:

1. Initiation by the User:

   • A user starts by interacting with the Yaho contract on the Goerli network. They call the dispatchMessagesToAdapters function on Yaho to initiate the message sending process.

2. Message Processing by Yaho:

   • Yaho takes the user's message and communicates with the AMB Message Relay. The role of the AMB Message Relay is to take the message from Yaho and prepare it for cross-chain delivery.

3. Relaying via AMB Message Relay:

   • The AMB Message Relay, after receiving the message from Yaho, calls its relayMessages function. This function includes an operation to storeHashes, which is executed on an adapter on the Gnosis Chain. This action essentially packages the message for its cross-chain journey.

4. Cross-Chain Handover:

   • The AMB Message Relay on Goerli then interacts with the AMB contract through the requireToPassMessage function. This is where the AMB takes the relayed message and securely sends it to the AMB contract on the Gnosis Chain.

5. Receipt and Verification on Gnosis Chain:

   • Once the message arrives on the Gnosis Chain, the AMB Adapter contract calls its storeHashes function. This crucial step logs the message, ensuring that it's safely received and ready for the next phase. A MessageDispatched event is emitted, providing a messageId that is vital for tracking and executing the message.

6. Execution of the Message:

   • The final step involves the user calling the executeMessages function on the Yaru contract on the Gnosis Chain. The user provides the messageId (obtained from the MessageDispatched event) and the original message as parameters.

   • Yaru then performs the execution of the message, completing its cross-chain journey and allowing the intended actions to be carried out on the Gnosis Chain.

Message Transmission from Gnosis Chain to Goerli

The process of sending a message from the Gnosis Chain to the Goerli network through Hashi involves several components that work together to ensure the message is not only transmitted across chains but also validated and executed securely.

Step-by-Step Process from Gnosis Chain to Goerli

1. User Interaction on Gnosis Chain:

   • It begins with the user calling Yaho.dispatchMessagesToAdapters on the Gnosis Chain. This function is responsible for initiating the message relay process, much like dropping a mail into the postbox.

2. Message Handling by Yaho:

   • Yaho processes the message and forwards it to the AMB Message Relay. Here, relayMessages (which involves storeHashes) is called, packaging the message and its metadata for the journey ahead.

3. Message Relay to AMB:

   • The AMB Message Relay invokes requireToPassMessage on the AMB contract. This step is akin to handing over the message to the courier service, which will carry it across the bridge to the Goerli network. During this process, the UserRequestsForSignature event is emitted.

4. Signature Retrieval by User:

   • On the Gnosis side, the user now interacts with the AMB Helper contract. By calling getSignature and providing the encodedData from step 3, the user receives a signature, a cryptographic proof that the message is valid and ready to be accepted on the Goerli chain.

5. Message Passing to Goerli's AMB:

   • With the signature in hand, the user then calls executeSignature on the AMB contract deployed on the Goerli network. The signature and encodedData are provided as parameters. This step is crucial as it's where the message is verified and accepted by the Goerli network's AMB, which in turn calls storeHashes from the AMB Adapter. The MessageDispatched event is emitted, granting the user the messageId needed for the final step.

6. Execution on Ethereum via Yaru:

   • The last phase of the journey takes place on the Ethereum network. The user calls Yaru.executeMessages with the obtained messageId and the original message as parameters. Yaru then executes the message, thereby completing the cross-chain communication loop.

This process exemplifies the robustness of Hashi in handling cross-chain messages, incorporating cryptographic verification at each step to maintain security and integrity. From the user's perspective on the Gnosis Chain, the journey of the message is transparent and results in a series of actions being triggered on the Goerli network, all orchestrated by the Hashi protocol.

Ok, so what’s next?

To delve deeper into the Hashi protocol and explore its full potential, a comprehensive suite of resources is available. These materials include technical documentation, tutorials, and community discussions, all designed to provide a thorough understanding of the protocol and its applications. Whether you're looking to integrate Hashi into your project or simply curious about the mechanics of cross-chain bridges, these resources serve as a gateway to a wealth of knowledge.

https://github.com/atj3097/hashi-chiado-to-goerli-vrf

Chainlink’s VRF Service doesn’t exist on Goerli/Chiado. So with Hashi, we’re able to request a random number from Chainlink’s VRF on Goerli and have it listened for on our dapp deployed on Chiado. This is less documentation and more so of a technical implementation.

https://hashi-doc.gitbook.io/hashi/v0.1/introduction

Hashi Protocol Documentation

https://github.com/gnosis/hashi

Hashi Protocol Github & Contract Deployments here 👉 Deployments

https://ethresear.ch/t/hashi-a-principled-approach-to-bridges/14725

This forum post is a more in depth explanation of Hashi and the problem it solves.

Long gone are the days of us sitting in tech talks at crypto conferences imagining all of the cool things zero knowledge proofs will be able to do in the blockchain space. The tools are here. From zk co-proccessors like Axiom, to fully blown zkVMs by RISC ZERO, Polygon’s coming Miden VM, etc. we have the tools to create the next generation of apps that will not only scale ethereum, but also increase privacy and enable an entirely new set of defi apps that are uniquely enabled by with these tools. Last time I wrote about how Axiom enables interesting use cases of Uniswap Hooks on the coming Uniswap V4 with their zk co-processor. Lately I’ve been deep diving into the new Polygon zkEVM & their coming Miden VM, two of Polygon’s new zk rollup solutions. This research has inspired me to write this piece on how these tools that will further extend of DeFi protocols with the capabilities of the coming Uniswap V4.

Bootstrapping Your DeFi Protocol On Top Of Uniswap V4

At this point, most people know what Uniswap V4 is, but just a quick overview one more time in plain terms:

Uniswap V4 is the next iteration of the Uniswap Protocol. Uniswap Liquidity Pools are now created using a singleton PoolManager instance and we have “hooks“, which are functions of code that run at different stages of actions that happen in a pool.

If you want to learn more, Uniswap V4 whitepaper draft here

Before this, when people wanted to start their own DeFi protocol, we had to fork 🍴 Uniswap V3. This was not an easy feat for engineers, from the headaches of launching V3 on your own all the way to bootstrapping your own liquidity. This barrier to entry kept a lot of developers out of the innovation race that of DeFi. Uniswap V4 takes down these barriers to entry drastically for developers with the its new architecture.

If you’re able to attract liquidity to hooks and pools that you made, you can effectively create your own DeFi protocol on top of Uniswap V4. V4 has essentially positioned the Uniswap Protocol to become the fundamental layer of decentralized finance. While you still have to do the legwork to find and bootstrap your own liquidity, Uniswap V4 abstracts you alot of your work as a developer to get to a proof of concept of your own DeFi protocol on the ground. But ok, now we have V4 but the next question is, which chain(s) will I launch on?

Choosing Your Chain To Launch: The Case For Polygon’s zkEVM Rollup

On-Chain summer just ended. From Base, to Optimism, Scroll, etc. Developers have an insane amount of options for the different blockchains that they will launch their next DeFi application on. Polygon’s PoS chain has long been a widely adopted layer 2, a high throughput EVM compatible layer 2 that was a convenient option for many during the last bull run when Ethereum gas fees were ridiculously expensive. Polygon’s PoS chain was extremely cheap and we saw thousands of dApps launched on that chain, while in the background many were waiting on the launch of many of zk-rollup & optimistic solutions. Well…..ladies and gentlemen….we got em.

Last year fall(2022), Polygon now upped the ante with its zkEVM chain, a promising enhancement that is poised to be a game-changer in the blockchain arena.

How zkEVMs Work:

• Efficient Scalability:

  • zkEVMs process more transactions off-chain, reducing the on-chain load. This structure promotes faster and more cost-efficient transactions.

• Enhanced Privacy:

  • Zero-knowledge proofs allow for the validation of transactions without revealing sensitive data, bolstering transaction confidentiality.

• Reduced Costs:

  • By handling more transactions off-chain, zkEVMs significantly reduce gas fees, making transactions more economical.

• Improved Performance:

  • zkEVMs optimize the network, preventing it from becoming overwhelmed by transaction volumes, thus ensuring smoother operation and improved user experiences.

• EVM Equivalence:

  • zkEVM is designed to be compatible with the Ethereum Virtual Machine (EVM). This equivalence allows for seamless migration and integration of Ethereum-based dApps, smart contracts, and tools, thus providing developers with a familiar environment and the ability to leverage existing Ethereum ecosystems and communities for enhanced collaboration and innovation.

  • TL;DR you can launch your dApp on Polygon’s zkEVM with out all the hiccups of the EVM “compatible“ chains

Launching your next DeFi app using Uniswap V4 on top of Polygon's zkEVM isn't just an upgrade; it’s a revolutionary leap. Uniswap V4, with its myriad of innovative features, when paired with the scalability and privacy of a zkEVM, creates a supercharged environment where DeFi applications can operate at and easily scale when your defi protocol explodes in the next bullmarket.

Harnessing Polygon Miden for zkAMMs in Uniswap V4

Description from Polygon on what is Polygon Miden

Polygon Miden is a zero-knowledge rollup running on the Miden VM. Polygon Miden prioritizes ZK-friendliness over EVM compatibility; that way it can offer features and benefits that are not available on Ethereum. It aims at builders that want to create high-throughput and private dApps. Miden is a general purpose rollup and builders can write and deploy arbitrary smart contracts.

Incorporating the advanced functionalities of Polygon Miden can help revolutionize the capabilities of an AMM like Uniswap, leading to the birth of zkAMMs 🤫 and enhanced privacy measures for users.

1. Scalability through zk-Design: One of the defining features of Polygon Miden is its ZK-centric design, enabling users to locally execute smart contracts and produce ZK proofs for network verification. For Uniswap V4, this scalability is insane. The ability to process transactions locally and then use ZK proofs for verification ensures that trading can occur at unmatched speeds, making Uniswap V4 a prime candidate for high-frequency decentralized trades. This approach significantly diminishes the computational load on the network, offering traders rapid and smooth experiences.

2. Privacy-First AMMs with zkAMM: The transparency of blockchains, while beneficial for many use-cases, can be a hindrance in scenarios where transactional privacy is vital. Polygon Miden is designed with privacy at its core. Integrating Miden's technology into Uniswap V4 could lead to the inception of zkAMMs, where trades are not only efficient but also cloaked in privacy. This system would allow traders to retain the privacy of their trading strategies, amounts, and timing – a game-changer in the AMM landscape.

3. Asynchronous Interactions & Uniswap Hooks: Polygon Miden's architecture champions asynchronous interactions. All interplays between smart contracts are asynchronous, meaning token transfers, NFT swaps, and more don't have to touch the public state. This fits harmoniously with the idea of Uniswap hooks. By leveraging Miden's asynchronous model, Uniswap developers can create hooks that function seamlessly, interacting effortlessly between locally executed transactions and network transactions.

4. Safety Innovations & Uniswap: Safety is paramount in DeFi, and Polygon Miden has made significant strides in this arena. With every account in Miden being a smart contract, and the potential for recallable transactions, the chances of erroneous transfers are drastically reduced. Incorporating these safety measures into Uniswap V4 ensures a safer trading environment. Traders can operate with the confidence that their assets are secure and protected from common pitfalls and hacks that have plauged the DeFi ecosystem for the past few years.

In summary, Polygon Miden's advanced ZK-centric design/privacy first approach with Uniswap V4's upgrade on the way paves the way for a new DeFi paradigm. zkAMMs and privacy-enabled Uniswap hooks could very well be the next significant advancement in the decentralized trading world, providing users with the perfect blend of speed, security, and privacy. Even though we’re in a pretty brutal crypto winter, the tools to create the next generation of DeFi apps to further legitimize and increase crypto’s adoption are being provided to us right in front of our eyes.

So What’s Next?

Well, at this point I hope I’ve shown you the possibilities of what can be done in the coming months with the launch of Uniswap’s V4 & Polygon zkEVM/Miden. Uniswap V4 is already on the Mumbai testnet of Polygon while Polygon’s Miden is still in the works with just a simple playground for now. But if I were you anon? I’d get ahead of the curve now. So below I’ve compiled a list of everything you need to learn to get started. These resources will accommodate both the newbies and the shadowy super coders.

Uniswap Resources

https://uniswap.university/guides - For Uniswap Beginners especially

https://docs.uniswapfoundation.org/

https://github.com/fewwwww/awesome-uniswap-hooks#-examples

zkAMM proposal in the EF Forum

https://ethresear.ch/t/zkuniswap-a-first-of-its-kind-zkamm/16839

Polygon Resources + Some EVM Stuff

Ok, before you can really appreciate how cool the Polygon solutions are I’d recommend that you dive deep into the EVM(most people reading this article probably already are but I personally have to get refreshed on EVM stuff yearly)

This playlist is probably the best explainer on the fundamentals of Ethereum and how the EVM works. They’re long but worth the watch.

Honestly in terms of Polygon, you don’t need to look any further than the Polygon University. And I’m adding two talks on Polygon zkEVM/Miden too

https://university.polygon.technology/

Uniswap V4 represents the latest iteration of the leading decentralized exchange protocol. It introduces an innovative hooks architecture that enables developers augment pool functionality at different stages in a pools lifecycle.

Hooks allow building customized features on top of Uniswap pools, like whitelisting liquidity pools, oracles, and more. However, hooks have limited access to on-chain data, hindering their capabilities. Meanwhile, Axiom has introduced an on-chain "coprocessor" for Ethereum. Axiom allows smart contracts to make queries for historical data like past prices, balances, contract states and have the results verified on-chain via zk proofs Axiom uses two main contracts for you to accomplish this:

Note - If you’re like me, you’re not a God-Tier cryptographer like the folks at Axiom. I highly recommend to review some of the common blockchain cryptographic concepts. The more you understand these concepts the more Axiom and it’s capabilities will “click“ more for you Merkle Trees | zero-knowledge proofs | Ethereum Data Structures

AxiomV1 - a cache of Ethereum block hashes starting from genesis

AxiomV1 is a smart contract that caches historical blockchain data to allow verifying queries about the past. It stores past block hashes in two main ways:

• As Merkle roots of consecutive blocks grouped together. This lets you prove a specific block hash is valid.

• In a Merkle Mountain Range structure. This allows verifying ranges of blocks.

AxiomV1 has functions like updateRecent and updateHistorical that add new hashed blocks to the cache by verifying them with zk-proofs. It provides methods like isBlockHashValid to verify a specific block hash against the cached roots. And mmrVerifyBlockHash to verify against the Merkle Mountain Range.

The contract stores the latest mountain range and commitments to past ones. This allows using the cache to verify historical blockchain queries through cryptographic proofs of validity. The cache is updated over time so an increasing range of historical data can be proven. So in summary, AxiomV1 maintains verifiable caches of past block hashes that allow proving historical blockchain data through zk proofs.

AxiomV1Query - A smart contract which fulfills queries against AxiomV1

The query protocol allows requesting and verifying historical blockchain data through Axiom's contract. Here's a quick rundown of how it works:

• To request data, you call Axiom's sendQuery or sendOffchainQuery functions. This submits the query specifying what data you need.

• You provide a payment in ETH when submitting the query. This acts as a bounty for someone to do the work of fetching your requested data.

• The query also specifies a deadline block. If the data isn't provided by then, you can get a refund.

• To respond to a query, an Axiom node operator runs the off-chain work of retrieving the requested data from Ethereum's history.

• The node then generates a zk cryptographic proof that verifies the data is correct.

• This proof gets submitted back on-chain via the fulfillQuery function.

• Axiom's contract checks the proof is valid and matches the original request.

• If everything checks out, the contract records the data as verified.

So in summary, the query protocol consists of the on-chain functions to request data, pay bounties, refund, and verify responses. The core innovation is using zk proofs to generate proofs of historical blockchain data.

Integrating these two technologies unlocks alot of new potential. With Axiom providing trustless historical data access and Uniswap V4 hooks enabling custom functionality on liquidity pools, developers can now build data-rich defi apps on top of the Uniswap Protocol. Together, Axiom and Uniswap V4 provide the perfect ingredients for the next evolution of sophisticated data-driven DeFi products.

The integration of Axiom and Uniswap V4 brings a new era of possibility for data-rich decentralized finance applications. Axiom unlocks historical on-chain data for use in smart contracts by allowing developers to query information like past prices, balances, ownership records, and contract states. These results can be reliably incorporated into dapps thanks to Axiom's use of zk proofs for verifiable computation. By using Axiom with Uniswap hooks, developers can build decentralized applications that intelligently leverage historical data in automated, trustless ways.

Uniswap V4 🤝 Axiom Hook Ideas

Here are some ideas for Uniswap V4 hooks using Axiom

1. TWAP trading based on historical prices - Execute TWAP trades using price data fetched from Axiom.

2. Limit order hook - Place limit orders using Axiom to access historical pricing data off-chain.

3. Lending fee adjustment - Adjust lending rates based on historical utilization ratios pulled from Axiom.

4. Automated concentrated liquidity - Optimize concentrated liquidity positions based on historical trade data.

5. Decentralized TWAP arbitrage - Arbitrage across DEXs using historical prices from Axiom.

6. Liquidity provider profiler - Analyze historical provider behavior using Axiom data to identify profitable LPs.

7. Time-based access control - Restrict access based on past on-chain activity verified through Axiom.

8. Decentralized moving averages - Calculate custom on-chain moving averages using historical pricing data.

9. Smart contract price feeds - Build reliable on-chain price feeds using historical data from Axiom.

10. Liquidity incentives framework - Reward LPs based on historical usage data pulled from Axiom.

11. Automated ecosystem buybacks - Perform token buybacks when historical prices hit specific thresholds.

12. Automated Blacklist Identification - Identify malicious actors by analyzing transaction histories and patterns of abuse.

Resources to get started

Hooks using Axiom

Built by @saucepoint on Twitter during the ETHNYC Hackathon

https://github.com/saucepoint/v4-axiom-rebalancing/tree/main

A hook using Axiom I’m currently implementing - will be finished soon!

The buyback hook uses Axiom to access historical price data for a protocol's token. It sets a target price threshold and monitors the current price. When the price crosses below the threshold, the hook automatically executes a buyback.

https://github.com/atj3097/buyback-hook

Axiom Documentation & Talks/Articles

https://mirror.xyz/camiinthisthang.eth/qb9kbqj9-OOuUCQxmYJuRnBrkICQHe8YEohTrmZeqLM

https://docs.axiom.xyz/developers/axiom-for-developers

Axiom Demo Projects(This is really useful for seeing Axiom in action, especially the code examples as well)

https://demo.axiom.xyz/account-age

https://github.com/axiom-crypto/examples

Compilation of Uniswap Hooks Resources and some of my examples

https://github.com/atj3097/univ4-hooks-portfolio