Since the announcement of UniswapV4, this swapping platform has undergone a significant transformation, evolving from a simple swapping platform into an infrastructure service provider. Especially noteworthy is the Hooks feature in V4, which has garnered widespread attention. After conducting in-depth research over a period of time, I have compiled some content to help everyone better understand this transformation and its implementation.

The innovation in UniswapV4 doesn't focus on improving AMM technology per se but rather on expanding the ecosystem. Specifically, this innovation includes several key features:

1. Flash Accounting

2. Singleton Contract

3. Hooks Architecture

In the following sections, I will provide a detailed explanation of the significance of these features and how they are implemented.

Flash Accounting

Double Entry Bookkeeping

UniswapV4 adopts a recording method similar to Double Entry Bookkeeping to track the changes in token balances corresponding to each operation. This double-entry bookkeeping recording method requires that each transaction must be recorded in multiple accounts simultaneously, ensuring that the asset values between these accounts remain balanced. For example, suppose a user exchanges 100 TokenA for 50 TokenB in the pool. The ledger would record it as follows:

• USER: TokenA decreases by 100 units (-100), and TokenB increases by 50 units (+50).

• POOL: TokenA increases by 100 units (+100), and TokenB decreases by 50 units (-50).

Operations Related to Token Delta

In UniswapV4, the primary operations use this accounting method and employ a storage variable called lockState.currencyDelta[currency] in the code to record the change in token balances. The numerical value of this change, if positive, represents the expected increase in the token within the pool, while if negative, it signifies the expected decrease in the token within the pool. From another perspective, a positive value indicates the shortage of tokens in the pool (the expected amount to be received), whereas a negative value indicates the surplus of tokens in the pool (the expected amount for users to withdraw). The following lists the impact of various operations on Token Delta:

Here is the translation of the descriptions of various operations on Token Delta in UniswapV4:

• modifyPosition: Represents the execution of Add/Remove liquidity operations. For Add liquidity, it uses addition to update Token Delta (indicating the expected addition of TokenA to the pool). For Remove liquidity, subtraction is used to update Token Delta (indicating the expected withdrawal of TokenB from the pool).

• swap: Represents the execution of a Swap operation. Taking the example of swapping TokenA for TokenB, addition is used to update TokenADelta, while subtraction is used to update TokenBDelta.

• settle: Accompanies the transfer of tokens to the Pool. The Pool calculates the increase in tokens before and after the operation and uses subtraction to update Token Delta. If the Pool receives the exact expected amount of tokens, the subtraction here precisely sets TokenDelta to zero.

• take: Accompanies the withdrawal of tokens from the Pool. The Pool uses addition to update Token Delta, indicating that tokens have been removed from this Pool.

• mint: The behavior of updating Token Delta is similar to "take," but minting does not actually withdraw tokens from the pool. Instead, it issues corresponding ERC1155 Tokens as proof of withdrawal, while the tokens remain in the pool. Later, users can retrieve tokens from the pool by burning the ERC1155 Tokens. There are two purposes for this: 1. To save gas costs associated with ERC20 token transfers (contract call + one less storage write). In the future, TokenDelta can be updated using the burn method of ERC1155 tokens for trading purposes. 2. To keep liquidity in the pool, maintaining liquidity depth for users to have a better Swap Token experience.

• donate: Indicates the intention to donate tokens to the Pool, but in practice, you still need to use "settle" to send the tokens into the Pool. Therefore, addition is used here to update Token Delta.

The operations described above only involve actual token transfers in the cases of "settle" and "take." For the other operations, their primary purpose is to update the TokenDelta values without physically transferring tokens.

Token Delta Example

Let's illustrate how TokenDelta is updated with a simple example. Suppose today we exchange 100 TokenA for 50 TokenB:

1. Before the transaction starts, both TokenADelta and TokenBDelta are 0.

2. Swap: Calculate how much TokenA the Pool needs to receive and how much TokenB the user will receive. At this point, TokenADelta = 100, and TokenBDelta = -50.

3. Settle: Send 100 TokenA into the Pool and update TokenADelta = 100 - 100 = 0.

4. Take: Withdraw 50 TokenB from the Pool to the user's account, and update TokenBDelta = -50 + 50 = 0.

Absolutely, when TokenADelta and TokenBDelta are both reset to 0 after the entire exchange operation is completed, it signifies that the operation is fully balanced, ensuring consistency in account balances. This meticulous tracking and resetting mechanism are essential for maintaining accurate and reliable accounting within the system.

EIP-1153: Transient storage opcodes

Mentioned that UniswapV4 uses Storage Variables to record TokenDelta, but within smart contracts, reading and writing to Storage Variables can be quite costly. This is where another EIP introduced by Uniswap comes into play: EIP1153 - Transient Storage Opcodes.

UniswapV4 plans to utilize the TSTORE and TLOAD opcodes provided by EIP1153 to update TokenDelta. Storage Variables using Transient Storage Opcodes will be discarded after the transaction ends (similar to Memory Variables), which means they do not need to be written to disk, thus reducing gas costs.

EIP1153 has been confirmed to be included in the upcoming Dencun Upgrade, and UniswapV4 has indicated that they will go live with this upgrade after Constantinople. This approach should help reduce the gas costs associated with these operations while still maintaining accurate accounting within the protocol.

Flash Accounting — Lock

UniswapV4 has introduced a locking mechanism, which means that before performing any Pool operations, you must first call PoolManager.lock() to acquire a lock. Before the execution of lock() is complete, it checks whether the TokenDelta value is 0; otherwise, it will trigger a revert. After calling PoolManager.lock() and successfully acquiring the lock, the lockAcquired() function of msg.sender will be called. In the lockAcquired() function, the operations related to the Pool (such as swap, modifyPosition, etc.) are executed.

Let's illustrate this process with a diagram. When a user needs to perform a Token Swap operation, they must call a Smart Contract with a lockAcquired() function (referred to as the Callback Contract). The Callback Contract will first call PoolManager.lock(), and then PoolManager will call the lockAcquired() function of the Callback Contract. In the lockAcquired() function, the logic related to Pool operations, such as swap, settle, and take, is defined. Finally, just before the entire lock() is about to end, PoolManager checks whether the TokenDelta related to this operation has been reset to 0 to ensure that the assets in the Pool remain balanced.

This locking mechanism helps ensure the integrity and consistency of operations involving the Pool, preventing any discrepancies or unintended changes in token balances.

Singleton Contract

The introduction of the Singleton Contract in UniswapV4 signifies the abandonment of the previous Factory-Pool model. Each Pool is no longer an independent Smart Contract; instead, all Pools share a single singleton contract. This design, combined with the Flash Accounting mechanism, only requires the updating of necessary Storage Variables, further reducing the complexity and cost of operations.

Let's illustrate this with a diagram. In the case of UniswapV3, converting ETH to DAI required at least four Token transfers (Storage write operations). This involved multiple changes recorded for USDC, USDT, and DAI Tokens. However, with the improvements in UniswapV4, coupled with the Flash Accounting mechanism, only one Token transfer is needed (transferring DAI from the Pool to the user), significantly reducing the number of operations and costs.

This streamlined approach simplifies transactions and makes them more cost-efficient, benefiting users of the UniswapV4 platform.

Hooks Architecture

UniswapV4's most notable update in this release is the Hooks Architecture. This update provides significant flexibility around Pool usability. Hooks refer to additional actions called when specific operations are performed on the Pool. These actions are categorized into different classes, including initialize (create pool), modifyPosition (add/remove liquidity), swap, and donate, with each class having pre-execution and post-execution actions:

• beforeInitialize / afterInitialize

• beforeModifyPosition / afterModifyPosition

• beforeSwap / afterSwap

• beforeDonate / afterDonate

This design allows users to execute custom logic before and after specific operations, providing greater flexibility in extending the functionality of UniswapV4.

Hook Example — Limit Order Hook

Next, we will use an example of a Limit Order to explain the actual operational process of Hooks. Before we begin, let's briefly explain the principle of implementing Limit Orders in UniswapV4.

The principle behind implementing limit orders in UniswapV4 involves adding liquidity to a specific price range and then executing the removal of liquidity if that range of liquidity is traded.

For example, let's say we added liquidity in the price range of 1900–2000 for ETH, and then the price of ETH rises from 1800 to 2100. At this point, all the ETH liquidity we previously added in the 1900–2000 price range has been exchanged for USDC (assuming it's an ETH-USDC Pool). Removing liquidity at this moment is equivalent to executing a market order for ETH at the current price range of 1900–2000.

Limit Order Hook Contract

This example is provided by UniswapV4 on its GitHub platform. In this example, the Limit Order Hook contract offers two hooks, namely afterInitialize and afterSwap. The afterInitialize hook is used to record the price range (tick) when creating the Pool, allowing identification of which limit orders have been matched after someone performs a swap.

Place Order

When a user needs to place an order, the Hook contract executes the operation of adding liquidity based on the price range and quantity specified by the user. In the Limit Order Hook contract, you can observe the presence of the place() function. The primary logic involves calling the lockAcquiredPlace() function after acquiring the lock, which executes the operation of adding liquidity. This part is equivalent to placing a limit order.

afterSwap Hook

After a user completes a token swap within this Pool, the Pool calls the afterSwap() function of the Hook contract. The main logic behind afterSwap() is to remove liquidity for the previously executed order operations between the previous price range and the current price range. This behavior is equivalent to the order being filled, indicating that the order has been executed.

Limit Order Flow

The entire process of implementing a Limit Order using the Hook mechanism is as follows:

1. The order placer sends the order to the Hook contract.

2. The Hook contract executes the liquidity addition operation based on the order information.

3. Regular users perform token swaps within the Pool.

4. After the token swap is completed, the Pool calls the afterSwap() function of the Hook contract.

5. The Hook contract, based on the price range changes from the token swap, executes the removal of liquidity for the executed limit orders.

This sequence illustrates how the Hook mechanism is used to implement the entire process of Limit Orders within the UniswapV4 framework.

Hook: Other features

Hooks Contract Address Bit

Whether to execute the before/after specific operations is determined by the leftmost 1 byte of the Hook contract address. 1 byte consists of 8 bits, which precisely corresponds to 8 additional actions. The Pool checks whether the bit of that action is set to 1 to determine whether it should call the corresponding hook function in the Hook contract. This also means that Hook contract addresses need to be designed in a specific way and cannot be arbitrarily chosen as Hook contracts. This design primarily aims to reduce gas consumption by shifting the cost to contract deployment, thereby achieving more efficient operations. (PS: In practice, you can use different CREATE2 salts to calculate contract addresses that meet the criteria through brute force.)

Dynamic Fee

In addition to allowing additional actions to be executed before and after each operation, Hooks also support the implementation of dynamic fees. When creating a Pool, you can specify whether to enable dynamic fees. If dynamic fees are enabled, the getFee() function of the Hook contract is called during token swaps. The Hook contract can then determine how much fee should be charged based on the current state of the Pool. This design allows for fee calculations to be adjusted based on real-time conditions, enhancing the flexibility of the system.

Pool Creation

Each Pool needs to determine its Hook contract at the time of creation, and this cannot be changed afterward (though different Pools can share the same Hook contract). This is primarily because Hooks are considered part of the PoolKey, and PoolManager uses the PoolKey to identify which Pool to operate on. Even if the assets are the same, having different Hook contracts would classify them as different Pools. This design ensures that the states and operations of different Pools can be independently managed and maintains the consistency of each Pool.

However, this design can also lead to increased complexity in routing as the number of Pools grows. Solutions like UniswapX might be designed to address this issue.

TL;DR

• Flash Accounting is used to track the quantity changes of each Token, ensuring that all changes are reset to zero after a transaction. To save on gas fees, Flash Accounting utilizes a special storage method provided by EIP1153.

• The Singleton Contract design helps reduce gas consumption by avoiding updates to multiple storage variables.

• The Hooks architecture provides additional operations divided into "pre-execution" and "post-execution" phases, making each Pool operation more flexible but also complicating Pool routing.

UniswapV4 clearly emphasizes expanding the entire Uniswap ecosystem and transforming it into infrastructure for more services to be built on Uniswap Pools. This helps enhance Uniswap's competitiveness and reduces the risk of other services replacing it, but its success remains to be observed. Some highlights include the combination of Flash Accounting and EIP1153, which we believe will lead to more services adopting these features and various application scenarios emerging in the future. This is the core concept of UniswapV4, and we hope it provides a deeper understanding of how UniswapV4 operates. If there are any errors in the article, please feel free to correct them, and we welcome discussions and feedback.

Reference

• Robert Chen Tweet

• DeFi Cheetah Tweet

• 深度解读Uniswap V4：一个“集大成者”的去中心化交易所

• Uniswap Lab Blog

• What You Need to Know About Uniswap v4

• v4-template

• Huff Hooks

• 
  
• 
  
• 
  

• UniswapV4 Github

• UniswapV4 WhitePaper

• Introducing v4 with Hayden Adams and the Protocols Team

• Uniswap V4 版本降臨！你該知道 V4 的全部升級重點

• Uniswap V4 重點性能「Hooks」是如何實現限價單交易的？

• Uniswap V4 帶來的終極問題：DEX能超越CEX嗎？

• Uniswap进化史：马行千里，V4的带来机会和影响

• 关于Uniswap V4，你需要知道的一切

TornadoCash is the most renowned anonymous transaction service in the world of cryptocurrency. TornadoCash utilizes Zero-Knowledge Proof (ZKP) technology to conceal the source of funds. The mechanism behind TornadoCash was criticized by the United States government for facilitating illegal financial activities, leading to its enforced delisting by the U.S. Treasury Department in August 2022. Privacy protection and money laundering activities often seem closely intertwined in many cases. While pursuing privacy, malicious actors often exploit these privacy features for illicit money laundering. Is it possible to find a method that allows people to maintain their privacy while effectively curbing money laundering activities? A possible direction has been suggested by Privacy-Pools, developed by ameen.eth, one of the early developers of TornadoCash. (Regarding the delisting, only the frontend website and GitHub repository were affected, while the contract portion remains unaffected on the blockchain. Eventually, the GitHub repository was restored under the efforts of the Electronic Frontier Foundation. For more details, please refer to this source.)

Introduction to TornadoCash Mechanism

Before introducing Privacy-Pools, it is important to understand the design principles behind TornadoCash. For a detailed explanation, you can refer to my previous article titled "Breaking Down TornadoCash: A Beginner's Guide to Explaining its Functionality to Friends." Here, I will briefly review the design principles of TornadoCash.

TornadoCash utilizes receipts, known as commitments, to control access rights. A commitment is generated by hashing a secret value and a nullifier code together. Each commitment can only be used for one withdrawal. Deposit information is recorded using a Merkle Tree structure, with commitments serving as leaf nodes, and the Merkle Root is calculated. Users only need to provide the data path from the leaf to the root to prove that the data is one of the leaves in the Merkle Tree, thereby indirectly proving the previous deposit of funds into TornadoCash. Zero-Knowledge Proofs are used to hide the source of the deposit, while nullifiers are used to prevent Double Withdrawal attacks.

TornadoCash's commitments serve two purposes:

1. Proving Previous Deposit

2. Ensuring Single Withdrawal

“Proof-of-Innocence”

According to the design principles of TornadoCash, it is only possible to determine that the withdrawn funds come from a previous deposit, but the specific deposit cannot be identified. This anonymity feature is exploited by criminals for illicit money laundering activities, which is why the US government seeks to regulate TornadoCash. However, if we can provide an alternative proof, such as Zero-Knowledge Proof (ZKP), to demonstrate that the withdrawn funds do not originate from deposits on the blacklist, it could potentially prove that the withdrawal is not associated with illicit activities. This concept is known as "Proof-of-Innocence," which aims to establish the innocence of the individual involved.

The concept of "Proof-of-Innocence" can be divided into two directions:

1. Proving that the withdrawn funds originate from the set of deposits listed on the whitelist (Allowed List).

2. Proving that the withdrawn funds do not come from the set of deposits listed on the blacklist (Denied List).

These two directions aim to establish the legitimacy of the withdrawn funds by either demonstrating their association with authorized deposits or their dissociation from prohibited deposits.

The design principle of Privacy-Pools

The design principle of Privacy-Pools builds upon TornadoCash and adds the concept of "Proof-of-Innocence." In Privacy-Pools, the withdrawal receipt serves not only its original purpose of representing a TornadoCash receipt but also carries a third meaning: "proving that the withdrawn funds originate from deposits on the whitelist."

By incorporating this additional proof, Privacy-Pools aims to provide an enhanced level of assurance regarding the legitimacy of the withdrawn funds, ensuring that they can be traced back to authorized deposits listed on the whitelist.

The receipt from Privacy-Pools represents the following meanings:

1. Proving Previous Deposit

2. Ensuring Single Withdrawal

3. Proof that the withdrawn funds originate from deposits on the whitelist

Here, we use the Allow Merkle Tree to explain how Privacy-Pools incorporates the concept of "Proof-of-Innocence" into the system (where the Allow Merkle Tree represents the whitelist concept). First, the Allow Merkle Tree has several characteristics.

• As the name suggests, the Allow Merkle Tree is a Merkle Tree.

• The height of the tree and the number of nodes are the same as the Deposit Merkle Tree in Privacy-Pools.

• Each leaf of the Allow Merkle Tree corresponds to the position of a leaf in the Deposit Merkle Tree (representing a deposit).

The data in the leaf nodes of the Allow Merkle Tree can be categorized into the following two types:

• allowed: This indicates that the deposit at that position is allowed. (Positions without any deposits are also considered allowed by default.)

• blocked: This indicates that the deposit at that position is blocked or denied.

The image below illustrates that the positions at index 0 and 1 in the Deposit Merkle Tree represent legal funds, and their corresponding positions in the Allow Merkle Tree are also marked as allowed.

Let's assume that today a criminal wants to engage in money laundering activities and deposits illicit funds into Privacy-Pools at the position with Deposit Merkle Tree ndex: 2. We are aware that these funds are illicit, so we update the corresponding position in the Allow Merkle Tree, specifically index: 2, to blocked This action ensures that the blocked funds cannot be withdrawn as they are associated with illicit activities.

In the case of withdrawals from the allowed list

Suppose a user, whose deposit is listed on the US government's allowed list, wants to withdraw funds. In addition to providing proof of having a deposit in the Deposit Merkle Tree, they also need to provide proof of being allowed on the US allowed list. The corresponding proof of the US allowed list includes the Allow Merkle Root (provided by the user, referred to as subsetRoot in the code) and the intermediate node values encountered along the way.

During the ZKP verification stage in Privacy-Pools, the Merkle Root is constructed using the leaf value allowed (in the actual code, it is keccak256(allowed)) and the given intermediate node values. The system then checks whether this calculated Merkle Root matches the Allow Merkle Root provided by the user. If they match, the verification is successful, indicating that the withdrawn funds come from a deposit listed on the US government's allowed list.

In the case of withdrawals from the denied list

If a user, whose deposit is not listed on the US government's allowed list, attempts to withdraw funds and their corresponding deposit position in the US allowed list is marked as blocked it would prevent the user from using the Allow Merkle Root associated with the US government's allowed list to withdraw funds. This would result in a verification failure as the corresponding proof cannot be generated.

In Privacy-Pools, the calculations rely on the leaf value allowed (keccak256(allowed) in the code), but the US government's allowed list marks that position as blocked. This discrepancy leads to the inability to calculate the same Merkle Root, resulting in a verification failure. As a result, the user would not be able to withdraw funds using the Allow Merkle Root from the US government's allowed list.

Under this design, the user would indeed need to provide an alternative Allow Merkle Root to withdraw funds. This alternative Allow Merkle Tree must mark the corresponding deposit position as allowed in order to calculate the same Allow Merkle Root for successful verification. This alternative Allow Merkle Tree can come from another government or institution that maintains such a list or even be generated by the user themselves.

In this scenario, the US government could use the Allow Merkle Root used during the withdrawal process to determine whether the user's funds comply with US government regulations, enabling them to track the funds. If the user is using a self-generated or untrusted Allow Merkle Tree, it is highly likely that the withdrawn funds come from problematic deposits, as any reputable third-party Allow Merkle Tree would mark that deposit position as blocked.

FAQ:

Q: If the Allow Merkle Root is provided by the withdrawer, can they forge a fake Allow Merkle Root to claim that the leaf corresponds to an allowed deposit? Does this mean they can still withdraw the funds?

A: The answer is affirmative. It is indeed possible to withdraw the funds in such a scenario. The author specifically points out that the intention of this mechanism is not to prevent criminals from withdrawing the funds, but rather to ensure that even if they succeed in doing so, it becomes known that the funds originated from the denied list. When the withdrawer provides an unconvincing Allow Merkle Root, it can be assumed that they are withdrawing funds from a deposit on the denied list. The reason for allowing this behavior is speculated to be to maintain the decentralized nature of the service. Each Allow Merkle Tree requires certain permission management to update the status of each leaf. If a specific Allow Merkle Tree root were enforced, it would mean that someone has certain privileges to control the withdrawal of funds, which goes against the spirit of decentralization.

Q: Who decides whether this transaction comes from funds on the denied list?

A: The author does not specifically mention who decides whether a transaction comes from funds on the denied list. It is understood that this aspect is likely to be determined by the respective regulatory authorities. For example, if the US government intends to investigate illicit funds in Privacy-Pools, they could examine each transaction's Allow Merkle Root to determine if it is associated with illicit funds. The criteria for determining which Allow Merkle Roots are considered valid or allowed would be determined by the respective regulatory authorities themselves.

Privacy-Pools Code

Here, I have provided the main code along with the author's comments, hoping it will help everyone understand the main logic through the code.

// circuits/withdraw_from_subset.circom
template WithdrawFromSubset(levels, expectedValue) {
    // public
    signal input root;
    signal input subsetRoot;
    signal input nullifier;
    signal input assetMetadata; // abi.encode(token, amount).snarkHash();
    signal input withdrawMetadata; // abi.encode(recipient, refund, relayer, fee).snarkHash();

    // private
    signal input secret; 
    signal input path; // Indicate whether the data represents the left leaf or the right leaf.
    signal input mainProof[levels];  // Construct the data required for deposit root.
    signal input subsetProof[levels]; // Construct the data required for allow root.

    // Calculate the nullifier and commitment.
    component hasher = CommitmentNullifierHasher();
    hasher.secret <== secret;
    hasher.path <== path;
    hasher.assetMetadata <== assetMetadata;
    nullifier === hasher.nullifier;

    // expectedValue: keccak256("allowed") % p
    component doubleTree = DoubleMerkleProof(levels, expectedValue);
    doubleTree.leaf <== hasher.commitment;
  
    // Convert the path to bits to specify whether it is the left leaf or the right leaf. 
    // It can be observed that the deposit tree and allow tree share the same path.
    doubleTree.path <== path; 
    for (var i = 0; i < levels; i++) {
        doubleTree.mainProof[i] <== mainProof[i];
        doubleTree.subsetProof[i] <== subsetProof[i];
    }
    root === doubleTree.root; // Verify the deposit root.
    subsetRoot === doubleTree.subsetRoot; // Verify the allow root.

    signal withdrawMetadataSquare;
    withdrawMetadataSquare <== withdrawMetadata * withdrawMetadata;
}

TL;DR

• "Proof-of-Innocence" is a concept that uses another proof to demonstrate that a withdrawal comes from a deposit listed on the allowed list. It can be constructed from both the perspective of the allowed list and the denied list.

• Privacy-Pools builds upon TornadoCash and adds the concept of "Proof-of-Innocence." The receipt in Privacy-Pools represents an additional meaning: proving that the withdrawn funds come from a deposit listed on the allowed list.

• The Allow Merkle Tree exists to provide proof that the withdrawn funds come from the allowed list. The leaf positions in the Allow Merkle Tree correspond to the deposit leaf positions in the Deposit Merkle Tree. The Allow Merkle Tree leaf data can be "allowed" or "blocked."

• In addition to providing the necessary data to construct the Deposit Merkle Root, the withdrawer also needs to provide the Allow Merkle Root and the data required to construct it as proof that the withdrawn funds come from the allowed list.

• Since the Allow Merkle Root is provided by the withdrawer, it is possible for malicious actors to forge a fake Allow Merkle Root to withdraw illicit funds. However, the presence of a forged Allow Merkle Root would still raise suspicions on the blockchain and enable tracking of the flow of illicit funds.

Developer ameen.eth combines the concept of "Proof-of-Innocence" with TornadoCash, offering another perspective that "privacy is not equal to criminality." The author finds it interesting to use another Zero-Knowledge Proof (ZKP) to prove an additional fact, akin to the addition of ZKPs. This approach is simpler and more efficient compared to constructing a larger and more complex ZKP. Regarding the choice of the Allow Merkle Tree, it seems that in the future, it may be constructed by a more impartial entity, which would provide greater credibility to others.

Lastly, the author expresses gratitude to Chih-Cheng Liang and Ping Chen for reviewing the article and providing valuable insights.

Reference

• Tornado Cash 實例解析

• ZKP 與智能合約的開發入門

• [ZKP 讀書會] Tornado Cash

• 
  

• https://github.com/tornadocash/tornado-core

• 深入理解TornadoCash技术细节

• https://www.privacypools.com/

• https://github.com/ameensol/privacy-pools

• 0xhhh Thread 介紹新功能和其原理

• demo video

• Vitalik’s 講如何改進 Tornado v2

• privacy pools v0 tweet

• Introducing Proof of Innocence built on Tornado Cash

TornadoCash is a well-known project for anonymous transactions. When a hacking incident occurs, hackers often transfer their funds to TornadoCash to ensure that their money can be moved without being traced. However, in recent years, there has been an increase in the frequency and scale of hacking attacks, which has caught the attention of regulatory authorities in the United States. As a result, a series of regulatory measures have been implemented, such as website shutdowns, arrests of developers, and removal of the source code from GitHub.

You may be curious about how TornadoCash achieves anonymity. Recently, I conducted some research to understand its operational mechanism. Here, I will do my best to explain in a straightforward manner how TornadoCash maintains anonymity and why they need to do so. I hope this knowledge can help you better understand TornadoCash.

What does TornadoCash aim to solve?

In each transaction, there are typically two parties involved: a sender and a receiver. TornadoCash aims to conceal the identity of the sender in order to prevent third parties from identifying who initiated the transaction through transaction records. This way, even if the transaction is recorded on the blockchain, the identity of the sender cannot be traced.

How does TornadoCash accomplish this?

TornadoCash utilizes a straightforward and widely adopted method called a mixer to achieve anonymous transactions. A mixer is a tool that combines funds from different senders to achieve the goal of anonymity.

Simply put, a mixer is like a box where senders deposit money, and recipients withdraw money from the box. Because the money is mixed together, it is impossible to determine which specific sender's money the recipient receives. This method makes the transactions anonymous and prevents the identification of senders from transaction records.

Only the person with the receipt can claim the money

The mixer model needs to address an important question: Who can claim the money? Without a proper mechanism to verify the identity of the recipient, anyone could claim the funds from the box, leading to security risks.

To solve this problem, TornadoCash employs a straightforward solution, which is the use of receipts. A receipt is a document that proves the identity of the recipient, similar to a luggage claim ticket given to hotel guests. Unlike the luggage storage model in real life, TornadoCash's receipts are not generated by a smart contract but provided by the user upon depositing funds. This is because the logic of the smart contract is stored on the blockchain, visible to anyone. Malicious individuals could replicate the same receipt and attempt to claim funds that do not belong to them.

The receipt in TornadoCash is provided by the user, and it is generated by hashing the secret and nullifier together. The secret and nullifierare both chosen and generated by the user. In the TornadoCash Smart Contract, this receipt is referred to as a commitment. However, for the purpose of understanding, we will continue using the term "receipt" here. The nullifier has a special purpose, which we will explain later.

The purpose of the receipt

Implementing the function of receipts on the blockchain is more challenging than imagined. On the blockchain, all information is public, including the receipts generated by Alice. If Bob uses Alice's receipt to claim funds from the smart contract, it becomes easy for others to know that Bob received the funds originally deposited by Alice, thus failing to achieve the goal of hiding the sender's identity.

Therefore, the existing receipt mechanism needs improvement. Before discussing the improvements, let's first understand the purposes of receipts in the entire system. In fact, receipts serve two main purposes:

1. Proof of previous sender's deposit: The receipt serves as proof that the sender has deposited funds previously into the system. It demonstrates that the sender has the authority to claim the funds at a later stage.

2. Ensuring each recipient can claim funds only once: The receipt ensures that each recipient can claim the funds only once, preventing double spending or multiple claims.

To illustrate this using a real-life example of luggage storage, when you have a receipt, it means you have previously deposited your luggage, and you can only retrieve the luggage once. In other words, if we can find a new way to prove that someone has deposited funds into the system and ensure that each recipient can claim the funds only once throughout the system, we can achieve the same effect as receipts.

Let's review what we want to prove.

Before explaining how TornadoCash achieves these two objectives, let's review why we need to do so. If Bob directly uses Alice's receipt to withdraw money, others can learn from the blockchain that the transaction was initiated by Alice, thus failing to achieve the goal of hiding the sender.

Therefore, we need to design a method that allows Bob to withdraw money without directly using Alice's receipt. Instead, he can use some form of proof to claim the funds. This ensures that someone has deposited funds before the withdrawal, and Bob's proof can only be used once to receive the money. Furthermore, this proof should not reveal any information related to Alice's receipt. In this way, even if Bob withdraws the money, we cannot determine who sent it to him, thus achieving the goal of hiding the sender. This is the design concept behind TornadoCash.

Prove that the sender has deposited funds before

TornadoCash employs two techniques:

1. Merkle Tree

2. Zero-Knowledge Proof

Using Merkle Tree to Record Deposits

When users want to deposit money into the Smart Contract, they need to provide a receipt, which is the hash value of the (secret, nullifier) pair mentioned earlier. This receipt, known as a commitment, is considered as a leaf in the Merkle Tree by the TornadoCash Smart Contract and added to the Merkle Tree (as shown in the diagram below, assuming the commitment is placed at leaf node r6 in the Merkle Tree).

The Merkle Tree is a data structure that allows for the calculation of parent hash values by hashing the leaf data at the bottom layer pairwise. In the provided diagram, for example, the hash value of r5 and r6 is computed to obtain the parent hash value at the next layer, denoted as H(r5, r6). This process continues as the parent hash values are hashed pairwise to generate the hash value at the next higher layer. For instance, H(r5, r6) and H(r7, r8) are hashed to obtain H(H(r5, r6), H(r7, r8)). This process repeats until the Merkle Tree's root is obtained, which is referred to as the Merkle Root.

The Merkle Tree data structure possesses a unique characteristic wherein to prove that a particular data is one of the leaves in the Merkle Tree, it is sufficient to provide the series of parent hash values traversed from the leaf to the root. In the given diagram, for instance, to prove that r6 is one of the leaves in this Merkle Tree, it is only necessary to provide the data r5, r6, H(r7, r8), and H(H(r1, r2), H(r3, r4)). These pieces of data are the intermediate parent hash values that establish the inclusion proof for the leaf data in the Merkle Tree.

Steps:

1. Calculate the hash value of r5 and r6 to obtain H(r5, r6).

2. Calculate the hash value of H(r5, r6) and H(r7, r8) to obtain H(H(r5, r6), H(r7, r8)).

3. Calculate the hash value of H(H(r1, r2), H(r3, r4)) and H(H(r5, r6), H(r7, r8)) to obtain the Root.

4. If the calculated Root is the same as the Merkle Root, it proves that r6 is one of the leaves in the Merkle Tree.

Using Zero-Knowledge Proofs (ZKPs) to Hide Deposit Source

The basic concept of Zero-Knowledge Proofs (ZKPs) is to provide a method where users can prove knowledge of certain information without revealing the actual content of that information. For example (the definition may not be precise, but the idea is the same), if I claim to possess the private key for a specific address, I can prove this by sending any amount of cryptocurrency to another address without actually disclosing the private key itself.

In TornadoCash, ZKP technology is utilized to hide the deposit source. Suppose we want to prove that we made a deposit on TornadoCash (assuming it is at position r6). We can provide the following proof:

• Knowledge: r6, r5, H(r7, r8), and H(H(r1, r2), H(r3, r4))

• Proof: Generate a proof using ZKP technology.

• Verify: In the verification contract of TornadoCash, calculate the Root based on the Proof data and check if it matches the Merkle Root on the blockchain. If they match, it indicates that r6 is one of the leaves in the TornadoCash Merkle Tree, implying that someone previously deposited funds in TornadoCash.

Using ZKP technology, we can prove that we possess certain specific knowledge without revealing the actual information. In this example, we have demonstrated knowledge of r6, r5, H(r7, r8), and H(H(r1, r2), H(r3, r4)) without disclosing the actual content of these pieces of information. Through such proof, we can hide the source of the deposit, thereby achieving anonymous transactions.

Ensuring each recipient can only withdraw funds once

To prevent the scenario where assets are withdrawn multiple times or more within a single transaction, TornadoCash introduces the concept of a nullifier. This is a common attack method that could potentially cause losses to TornadoCash. To mitigate this risk, TornadoCash incorporates the use of nullifiers.

During the deposit process, the nullifier is generated by hashing the secret along with other parameters to create a commitment. When a user wants to make a withdrawal, they must provide the hash value of the nullifier (hash(nullifier)). If this value already exists in the TornadoCash contract, it indicates that the funds associated with this deposit have already been withdrawn, and the withdrawal attempt will fail. However, if the hash(nullifier) has not been recorded, the withdrawal will be considered valid. TornadoCash then records the hash(nullifier) in the contract to ensure that the same deposit cannot be withdrawn again.

In summary, TornadoCash uses nullifiers to prevent double withdrawal attacks, ensuring the security and reliability of transactions. This mechanism safeguards against the unauthorized duplication of withdrawals and enhances the overall integrity of the system.

TornadoCash Withdraw Proof

Let's summarize the components included in the final TornadoCash proof:

1. Nullifier: The nullifier used during deposit generation to prevent double withdrawal.

2. Secret: The secret used during deposit generation.

3. Path Elements: The hash values traversed from the deposit commitment leaf to the Merkle Tree root.

4. Path Indices: Indicates whether each element in the pathElements is a left or right child.

These components will be used to construct a Zero-Knowledge Proof (ZKP) that allows Bob to prove his entitlement to claim the deposit without revealing his nullifier and secret. When verifying this ZKP, the following public data is required:

1. Root: The Merkle Tree root of TornadoCash.

2. NullifierHash: The hash value of Bob's nullifier, used to check for the risk of duplicate withdrawals.

Based on the provided example, when TornadoCash receives the proof and nullifierHash (assuming Alice's deposit is at position r6), the following actions are executed:

1. Using the secret and nullifier from the proof, calculate r6.

2. Calculate the root using r6, r5, H(r7, r8), and H(H(r1, r2), H(r3, r4)).

3. Compare the calculated root with the Merkle Root stored in TornadoCash. If they match, it indicates a previous deposit. TornadoCash keeps a record of the latest 30 Merkle Roots to reduce the chance of transaction failures since the Merkle Root changes with each deposit. The comparison is made against the 30 most recent Merkle Roots.

4. Set the map entry with the key as hash(nullifier) to true to prevent double withdrawal.

5. Transfer 1 ether to Bob.

Steps 1 to 3, which involve validating the proof, are executed in the Zero-Knowledge (ZK) verification process, ensuring that other parties cannot obtain the secret, nullifier, or related information.

By following these steps, TornadoCash ensures the security and integrity of the withdrawal process, preventing unauthorized withdrawals and maintaining privacy for participants.

TL;DR

• TornadoCash is an anonymous transfer project that uses a mixer to hide the identity of transaction senders.

• TornadoCash utilizes receipts (commitments) to control access rights. Receipts are generated from the secret and nullifierHash, and each receipt can only be used once.

• It uses a Merkle Tree to record deposit information, with receipts serving as leaf nodes. The Merkle Root is calculated, and users only need to provide the intermediate data from the leaf to the root to prove that their data is one of the leaves in the Merkle Tree.

• Zero-Knowledge Proofs are employed to hide the deposit source. Nullifiers are used to prevent Double Withdrawal attacks. TornadoCash proofs require verification by comparing them with public data, such as the Merkle Root and hash(nullifier).

Lastly, I would like to express my gratitude to Martine and Anton for reviewing the article and providing valuable feedback! Thank you very much for their assistance and contributions!

Reference:

• Tornado Cash 實例解析

• ZKP 與智能合約的開發入門

• 
  

• https://github.com/tornadocash/tornado-core

• 深入理解TornadoCash技术细节

Evolution of Trust in Blockchain

Before we dive into what Restaking is, let's first review the practical meaning and evolution of trust in Blockchain.

Bitcoin and Decentralized Trust

Bitcoin, proposed by Satoshi Nakamoto, is a decentralized trust structure. This trust comes from the fact that each miner has their own ledger. Even if a malicious miner tries to modify their ledger, it will still be rejected by other honest miners.

The above diagram simplifies the Bitcoin architecture into three layers. The bottom layer represents miners who operate the entire Bitcoin network. The middle layer represents miners who follow a set of PoW (Proof of Work) rules to generate the next block. The top layer (Limited Programmability) refers to the application services that run on this network, mainly for peer-to-peer transfers. We trust that the peer-to-peer transfer service at the top layer is correct mainly because we trust that the miners at the bottom all follow the same rules (PoW) to generate blocks (modify ledgers), and there are no malicious modifications in the middle layer (if there are, they will not be recognized by other miners). This is a bottom-up trust process.

In the early days, if one wanted to establish another decentralized application service, they would have to replicate the same architecture. In order to incentivize miners to operate the decentralized network in a specific way, miners would follow certain rules together, ultimately allowing decentralized application services to run on this decentralized network. As shown in the diagram below, this is why early new decentralized services corresponded to a new chain.

Modular Trust in Ethereum

Until the emergence of Ethereum, there were few innovations in the trust structure. The biggest difference between Ethereum and Bitcoin's trust structure is that the top layer is no longer limited to a script language. Instead, it is a Turing-complete program executor: EVM (Ethereum Virtual Machine). With EVM, anyone can create their own decentralized services (DApps) on the Ethereum network, such as AAVE, ENS, or Uniswap. These decentralized services are executed through EVM, and the correctness of EVM execution results is ensured by the nodes in the lower layer (following the PoS consensus rules). Through this mechanism, people who want to build different DApps no longer need to establish another decentralized network to gain trust, but can directly use Ethereum's trust network, which means that trust is modularized. This modularized trust structure significantly reduces the threshold for DApp innovation because there is no need to build another decentralized network for a specific DApp.

Barries to open innovation: Middlewares

However, there are still some issues with this modularized trust. The main reason is that Ethereum can only provide block-making-level trust. Block-making trust mainly refers to two things:

• Transaction ordering

• Transaction execution

If services outside of on-chain transactions are required, trust cannot be obtained from the Ethereum network (because Ethereum can only guarantee that transactions will be executed correctly according to the contract code). Usually, such services still need to establish another (decentralized) network of trust. Most of these types of services are also part of a DApp system, which are collectively referred to as Middlewares.

To ensure the security of Middlewares, a mechanism needs to be designed to ensure the correctness of data (to ensure that data is not maliciously tampered with). The most common situation is to design a high-yield economic model that encourages others to pledge to ensure the security of the service (e.g., Chainlink Staking). This makes the main cost of Middlewares to maintain a high APR an economical cost rather than an operational cost. Any service that has its own distributed verification mechanism for verification is called Actively Validated Services (AVS). The above use of token economic mechanisms to ensure security is just one method. Other methods, such as optimistic verification used by Nomad cross-chain bridges, and Wormhole/Axie cross-chain bridges that ensure security through trusting a few specific authorized relayers, are all trust issues that EigenLayer hopes to solve through Restaking.

Usually, a large DApp will not only run its own services but also need to integrate different Middlewares (e.g., Oracle, Bridge, etc.). In the case where each Middlewares has its own AVS to ensure the credibility of the data, the situation is as shown in the following diagram.

The Problems for Current DAapp

Currently, there are some issues with the DApp architecture:

• AVS cannot inherit trust from existing ETH. Ethereum itself already has a trust mechanism in place, and Middlewares cannot obtain trust (security) from this mechanism and need to create another trust network (AVS).

• The threshold for building a new full-trust network (AVS) from scratch is very high.

• Each AVS has its own pool, and Stakers need to pay additional fees to these pools besides paying Ethereum transaction fees. Using EigenLayer, there is no need to pay additional fees to these pools, or in other words, transaction fees are transferred to Ethereum validators. Under the original architecture, Ethereum validators cannot obtain these fees. This problem is referred to as Ethereum's Value Leakage.

• AVS will become the weakest link in the security of the DApp system. Because compared to disrupting the Ethereum network, the cost of disrupting AVS will be lower (using the example in the above diagram: Ethereum network: 10B, other AVS: 1B).

EigenLayer Solution

EigenLayer proposes two solutions:

• Pooled Security via Restaking

• Free-market governance

Pooled Security via Restaking

Allow the same funds to be staked in different trust (decentralized) networks to secure the data accuracy of different trust networks.

In practice, the staked funds are those of Ethereum network validators, which are also used by EigenLayer to stake in other Middlewares' trust networks.

For Stakers

• By staking the same funds in different trust networks and serving as validators for different networks, validators can earn additional validation rewards. However, if a validator engages in malicious behavior that harms the AVS, the staked capital will be punished and reduced (Shashing), which is the risk that validators must bear to earn additional rewards.

• The cost of maintaining the security of DApps is lower because there is no need to prepare two sets of funds to ensure the security of both Ethereum and Middlewares.

For Middlewares

• The threshold for establishing a trust network is significantly lowered. It is possible to inherit part or all of the trust (funds) from the Ethereum network, without the need to create a new trust network from scratch.

• Enhancing the security of AVS. Because everyone can share the trust brought by the same funds. In the original structure shown in the diagram, each AVS can only provide 1B worth of trust, but by switching to the EigenLayer Restaking architecture, each AVS inherits the overall 13B worth of trust, greatly enhancing security.

Free-market governance

Basically, it can be divided into two blocks: Staker (left) and AVS (right). Stakers can freely choose which AVS they want to participate in staking and receive rewards from. Each AVS can decide which rewards to offer to the Stakers who participate in staking, according to their own needs. This creates a free market for trading between Stakers and AVS.

For Stakers, the marginal cost of participating in staking with an additional AVS is very low. They only need to use the same capital to obtain additional rewards, without requiring additional capital. In theory, the more AVS that they participate in staking with, the higher their potential profit. Although participating in staking with other AVS does not require additional costs, they still need to bear corresponding risks. If, due to uncontrollable factors or malicious behavior harmful to AVS during the staking process, the staked funds will be reduced due to punishment (Slashing). For Stakers, as long as the total reward is greater than the total risk, they should stake more AVS as much as possible.

For AVS (in this case, Ethereum PoS is regarded as a type of AVS), in addition to being able to decide on the reward method themselves, they can also set conditions and restrictions for Stakers. Only Stakers who meet certain qualifications can stake and receive rewards on that AVS. For example, a certain AVS may require that the number of AVS staked by the Staker be less than a specific amount before they can stake on that AVS (in order to reduce the risk of operator collusion caused by staking too many AVS, which will be explained further in the article).

Restaking vs Merge Mining

The concept of Restaking is similar to early Merge Mining. The concept of Merge Mining is that, in the early days of PoW, the same mining machine is used to serve as a miner for different PoW networks, using the same computing power to obtain mining fees from different networks.

Merge Mining has a significant drawback in that it cannot effectively punish malicious miners. For example, a miner mines both Bitcoin and AppleCoin (generating blocks) at the same time. The miner intentionally engages in malicious behavior on AppleCoin to try to profit, but is later discovered and not recognized by other miners on the AppleCoin network, resulting in failure. The actual loss to the miner is not significant, as the malicious behavior on AppleCoin does not affect the miner's earnings on other PoW networks (Bitcoin's price is not directly affected), and the miner's mining machine can still continue to mine on other PoW networks to earn profits. The miner only loses the mining fee originally earned on AppleCoin and the electricity cost incurred for mining AppleCoin, without any additional losses.

When Ethereum transitions from PoW to PoS, if validators engage in wrongdoing, the ETH they staked will be punished and reduced. This is also the case for other AVS, where bad behavior will reduce the staked funds. This effectively reduces malicious behavior by validators. If the rules of other AVS can be written into smart contracts, then slashing (effective punishment) can be achieved. This is the main difference between Restaking and Merge Mining, and also the main reason why the Restaking system can operate.

Risk

The Restaking proposed by EigenLayer does solve the above-mentioned problems, but it also brings some new ones. The EigenLayer whitepaper lists two potential risks.

• Operator collusion

• Unintended slashing

Operator collusion

For a Staker, staking with all AVS is the most profitable strategy, but this may lead to a situation where All AVS TVL > Cryptoeconomic Security.

Assuming that a Staker stakes a total of 8M, but participates in staking with 5 AVS with a TVL of 2M each. This situation may lead to the Staker collaborating with other Stakers to attack all AVS in order to obtain greater benefits. The concept is similar to gambling in a casino, using the same bet to place bets on multiple different games. Although there is a chance of losing all the bets, there is also a chance of winning a higher prize than the bet. This means that if the attacker succeeds in the attack, they can also obtain funds that are more than the staking cost.

All AVS TVL (2M * 5 = 10M) > Cryptoeconomic Security（8Ｍ）

EigenLayer's proposed solution is as follows:

• AVS can set their own limiting conditions to reduce the profitability of attacks. The purpose is to reduce the profit that attackers can obtain through attacks. For example, during the Slashing period of Bridge Middleware, an upper limit on the total amount of transmission can be specified.

• Propose a monitoring system to track the AVS in which the Staker participates, in order to limit the number of AVS that the Staker can participate in.

Unintended Slashing

This refers to situations where the staked capital is slashed due to factors that are not intentionally malicious, but rather caused by other unpredictable factors (e.g., node misconfiguration). The proposed solution here is that EigenLayer will establish a committee that can vote on whether to cancel the slashing in specific situations. The members of the committee will be individuals with high reputations in the Ethereum and EigenLayer communities. This approach serves as a short-term solution and transitional arrangement until each AVS is integrated into EigenLayer and reaches maturity.

TLDR

• Ethereum has proposed a new modular trust innovation, which allows for the development of DApps without the need to create a new decentralized network. Developers can use the trust provided by the Ethereum network directly.

• Ethereum only provides trust at the block generation level, and Middlewares cannot use Ethereum's trust mechanism to build broader decentralized services. Middlewares still need to create their own trust network (AVS), with the main cost being the economic model for maintaining network security.

• EigenLayer is a platform that aims to explore the Liquid Staking Derivatives sector and provide more secure and reliable decentralized services. Its core concept is Restaking, which allows the same capital to be staked in different trust networks to ensure the security of different networks.

• Pooled Security via Restaking allows stakers to earn more rewards while reducing the cost of maintaining DApp security. Through Restaking, stakers can stake the same capital in different trust networks and act as validators for different networks to earn rewards. Restaking can also significantly lower the threshold for building trust networks for Middlewares, allowing them to inherit some or all of Ethereum's trust (capital).

• Free-market governance establishes an open market mechanism, where stakers can choose who to stake based on returns and risks. Middlewares can restrict stakers based on their needs to ensure the security of their own network.

• EigenLayer's innovation also brings additional problems and risks, such as Operator collusion and Unintended Slashing. Different approaches need to be adopted to address these issues based on different use cases.

When we first encounter Restaking, it is easy to think of it as just another service similar to LSD. However, by understanding the evolution from Bitcoin's early trust architecture to Ethereum's modular trust and Restaking, we can truly understand the problems that EigenLayer wants to solve. In summary, EigenLayer's solution can bring higher security and reliability to decentralized services while reducing the cost of maintaining DApp security, benefiting both stakers and Middlewares. I hope this article can help readers with similar questions to understand the meaning behind Restaking more deeply. After understanding its meaning, reading EigenLayer's whitepaper should make its content clearer.

I would like to express our special thanks to NIC for reviewing and correcting this article, which has greatly improved its quality.

Reference

• 白皮書

• Eigenlayer 白皮書Tweet

• 100y_eth Summary

• EigenLayer：展望以太坊生态的下一个主流叙事

• EigenLayer：2023 以太坊生态新叙事

• https://twitter.com/7upDAO/status/1626497846953533441?s=20

• https://twitter.com/OlimpioCrypto/status/1610013658125328384

• IOSG Weekly Brief | EigenLayer：将以太坊级别的信任引入中间件 #149

• Eigenlayer：以太坊又一重磅赛道推荐，二次质押关注起

• 
  
• 
  

Types of Curve Stablecoins and Their Problem-Solving Features

Curve Finance's stablecoin design belongs to the type of over-collateralized stablecoins. This type of stablecoin is minted (or borrowed) by using other assets such as ETH as collateral, based on a specific interest rate and the value of the collateral. The most famous protocol of this type is MakerDAO's DAI. ETH is used as collateral and borrowed to obtain MakerDAO's stablecoin DAI. Here, the collateral is changed to Curve Finance to borrow Curve stablecoins.

Curve stablecoins are designed to solve the problem of price volatility that exists in many cryptocurrencies. The value of stablecoins is stable and not subject to fluctuations in market prices, making them ideal for use as a medium of exchange or a store of value. In addition, the use of over-collateralization reduces the risk of liquidation and instability caused by fluctuations in the value of the collateral. Overall, Curve stablecoins provide a more secure and stable solution for users in the DeFi ecosystem.

Liquidation Issues

Stablecoin architectures of this type always have a liquidation mechanism. Liquidation refers to the situation when the value of the collateral falls to a certain price, causing the value of the collateral to no longer support the stablecoins borrowed. At this time, the collateral (partially or wholly) will be auctioned off at a favorable price to fill the gap in borrowed stablecoins. However, the current liquidation model has several problems:

• When a whale's assets are liquidated, many collaterals will flow into the market, causing market fluctuations.

• In most cases, liquidators will sell the liquidated collateral to profit, causing the collateral's price to drop again, resulting in another wave of liquidation.

• Liquidators usually sell the auctioned collateral on CEX/DEX. If the exchange lacks liquidity, it will cause bad debts for the lending platform.

• Users who are liquidated will suffer permanent losses. Even if the collateral's price rebounds, the collateral has been liquidated and cannot be restored.

In view of these issues, Curve hopes to improve the liquidation problem in stablecoin design in the following ways:

• Do not rely on external DEXs, as DEX liquidity is uncontrollable.

• Reduce users' losses as much as possible when liquidation occurs.

• Gradually liquidate users' collateral and convert it back when the price rebounds.

Curve Stablecoin Overall Architecture

The above diagram is the architecture diagram in the white paper, which can be roughly divided into two blocks.

• The Controller and LLAMMA are mainly responsible for collateral liquidation-related work (the blue box in the above figure).

• Monetary Policy, PegKeeper, and Stable Pool are mainly responsible for anchoring stablecoins to 1 USD-related work (the green box in the above figure).

This article will mainly focus on the introduction of Controller and LLAMMA, but there will also be a brief explanation of the Monetary Policy-related work. So let's start with today's highlight, LLAMMA!

LLAMMA (Lending-Liquidating AMM Algorithm)

LLAMMA stands for Lending-Liquidating AMM Algorithm, which, as the name suggests, is an AMM algorithm related to lending and liquidation. Curve mainly uses this algorithm to liquidate collateral.

AMM represents a Swap Pool based on the LLAMMA algorithm, which we will call the LLAMMA Pool for now. Users can deposit their collateral into the LLAMMA Pool through the Controller and mint stablecoins. The assets in the LLAMMA Pool are collateral and Curve stablecoins. In this article, we will use crvUSD to refer to Curve stablecoins and ETH as collateral for illustration purposes.

The most significant feature of the LLAMMA Pool is that when the price of collateral (ETH) falls below a specific price, the collateral in the Pool will gradually turn into crvUSD. Conversely, when the price is higher than a specific price, crvUSD will gradually turn into collateral (ETH).

It sounds quite magical! Before understanding this conversion process, we need to know what happens when users put their collateral in the Pool. The following diagram is an illustration of the interaction between various contracts, giving a clearer concept of the role played by the LLAMMA Pool in the architecture.

Dynamic Range and Oracle Price

Band

First, LLAMMA divides the collateral price range into different price segments called bands. When users deposit collateral, they need to provide:

• The amount of collateral

• How many bands to store the collateral in

• How much crvUSD to mint (or borrow)

The collateral will be divided into equal and evenly divided small pieces according to the number of bands to store, and then stored in a continuous price range composed of bands based on the current price and the minted crvUSD. The following figure shows the distribution of storing 10 ETH in 5 bands after calculation, with 5 small pieces of 2 ETH each stored in 5 consecutive bands.

In addition, it should be noted that each band has an upper price (P_UP) and lower price (P_DOWN). The upper price of the previous band is also the lower price of the next band. For example, the upper price of band 0 in the above figure (3000) is also the lower price of band -1 (3000). The upper and lower prices of each band represent the start and end prices of liquidation for that band. When the price reaches the upper price, the collateral stored in that band will begin to be liquidated until the price reaches the lower price, indicating the end of liquidation (meaning that all collateral in that band has been converted to crvUSD).

Oracle Price

In LLAMMA, there is another important role, which is the Oracle Price. The Oracle Price refers to the external collateral price (which can be thought of as the current market price). LLAMMA designs the Oracle Price role to achieve the behavior of ETH <-> crvUSD conversion at a specific price for the collateral. We will explain how this is achieved in detail in the following chapters. Here, we assume that the Oracle Price is P_ORACLE, and the price in the LLAMMA Pool is assumed to be P_AMM.

Regarding the design of the Oracle, what is certain is that each time an external price is obtained, it will be processed by EMA before being used. This is to prevent users from suffering losses due to drastic fluctuations in external prices while also increasing the difficulty of manipulating the Oracle Price. As the service is not yet online, it is not certain which service will be used as the Oracle source.

How to Work in LLAMMA Pool

The figure below shows the price changes in the band range (using ETH as collateral). When the ETH price is higher than P_UP (yellow range), all assets in the band range will be converted to ETH. When the ETH price is lower than P_DOWN (green range), all assets in the band range will be converted to crvUSD. When the price is between P_UP and P_DOWN (white range), the assets will be in a partially ETH and partially crvUSD state, with the proportion of ETH and crvUSD determined by the price changes.

The purple line in the middle indicates the price changes of P_ORACLE, and the red line indicates the price changes of P_AMM. P_CD and P_CU can be thought of as two equations created to find the upper and lower prices of this band.

When P_ORACLE and P_AMM are equal, it will be the blue point in the middle of the diagram, indicating that the ETH price in the Pool is consistent with the external price.

Oracle Price Increase

From the diagram of LLAMMA pool price, it can be observed that when the price starts to rise (the orange line in the diagram), the red line (P_AMM) rises faster than the purple line (P_ORACLE). When P_AMM > P_ORACLE, an arbitrage space is created, motivating external arbitrageurs to deposit ETH into the LLAMMA Pool to exchange for more crvUSD to profit until P_AMM = P_ORACLE is balanced again. During this process, the amount of ETH in the pool gradually increases, while the amount of crvUSD gradually decreases. When it goes higher than P_UP, only ETH will remain in this range. The figure below shows the changes in the AMM price (P_AMM) during the arbitrage process (the X-axis represents the oracle price, and the Y-axis represents the AMM price. To clearly indicate the price position, the orange line of the oracle price is listed on both the X-axis and the Y-axis).

Oracle Price Decrease

Conversely, when the price starts to fall (the green line in the LLAMMA pool price diagram), it can be observed that the red line (P_AMM) falls faster than the purple line (P_ORACLE). When P_AMM < P_ORACLE, an arbitrage space is also created, motivating external arbitrageurs to deposit crvUSD to exchange for more ETH until the price is balanced again. During this process, the amount of crvUSD in the pool gradually increases, while the amount of ETH gradually decreases. When it goes lower than P_DOWN, only crvUSD will remain in this range.

LLAAMA Formulas

Why does P_AMM rise or fall faster than P_ORACLE? To understand this, we need to look at the formula for P_AMM. In the LLAMMA Invariant formula, I, f, and g are all related to P_ORACLE. This means that I, f, and g are not constant, but will change.

x and y refer to the USD balance and ETH balance of the band range. y_0 is the ETH balance when P_AMM = P_ORACLE = P_UP, which can be temporarily viewed as a constant (in reality, it is also a function related to P_ORACLE).

If we arrange the band range as a sequence, we will find that it is a geometric sequence. A is the number that determines the ratio of this geometric sequence, and it is decided when the contract is deployed, so A is also an invariant.

It can be seen that P_AMM is only related to the parameters f and g, and f and g are only related to the changes in P_ORACLE. When P_ORACLE rises, f value will rise (square relationship will rise faster) and g value will decrease. The rise of P_AMM will be greater than that of P_ORACLE, resulting in P_AMM > P_ORACLE. When P_ORACLE falls, f value will decrease (square relationship will decrease faster) and g value will increase. The fall of P_AMM will be greater than that of P_ORACLE, resulting in P_AMM < P_ORACLE. Even if there is no swap in the LLAMMA pool, P_AMM will change with P_ORACLE, and the magnitude of P_AMM will be greater than that of P_ORACLE, thus creating an arbitrage opportunity to balance the asset ratio of the pool.

Summary of LLAMMA

LLAMMA intentionally creates an arbitrage opportunity for external traders by utilizing the fact that P_AMM fluctuates more than P_ORACLE. When arbitrageurs attempt to rebalance the asset ratio in the pool, they are essentially performing partial liquidations of the pool's assets. The advantage of this dynamic and continuous liquidation process is that it avoids a large-scale liquidation that could cause market volatility. As prices recover, the assets will convert back to collateral without causing permanent losses to the collateral.

Stabilizer and Monetary Policy

After discussing how LLAMMA solves the collateral liquidation problem, let's briefly explain what PegKeeper and Monetary Policy are and how they work. PegKeeper and Monetary Policy are the mechanisms used by Curve Finance to anchor crvUSD to 1 USD.

When crvUSD price > 1 USD: it means there is a shortage of crvUSD in the Curve pool. PegKeeper can mint new crvUSD without collateral and deposit it into the Curve Pool to increase the supply of crvUSD in the market.

When crvUSD price < 1 USD: it means there is an excess of crvUSD in the Curve pool. PegKeeper will start withdrawing previously minted crvUSD from the Curve Pool and burning these crvUSD to reduce the supply of crvUSD in the market.

These actions are defined in the PegKeeper contract and can be called by any external caller. Calling PegKeeper to anchor crvUSD creates profits, and these profits are returned to the external caller in the form of LP tokens. For example, suppose PegKeeper initially mints 200 crvUSD, deposits it into the Curve pool, and obtains 300 LP tokens. When the price drops, only 200 LP tokens are needed to withdraw 200 crvUSD. The remaining 100 LP tokens will be owned by the external caller.

Although this mentions forming a pool with crvUSD in each Curve pool, it is more likely that the approach will be similar to the 3pool type of pool where crvUSD is pooled with other assets. This way, only one PegKeeper is needed to adjust the price of crvUSD. In addition, the Curve team can use CRV to vote on the crvUSD ↔ 3pool pool to increase rewards and incentivize people to deposit and mint crvUSD. However, these are just personal speculations, and we need to see the actual situation after launch.

Monetary Policy

What if the PegKeeper has burned all the uncollateralized crvUSD and the price of crvUSD is still below 1 USD? Curve Finance has another way to increase the crvUSD price, which is to use Monetary Policy to raise the borrowing rate.

As we can see, when the price is greater than 1, the borrowing rate is extremely small (tending to 0). When the price is less than 1, the borrowing rate increases rapidly. This will cause borrowers who have minted crvUSD to repay their debt quickly, otherwise their collateral may be liquidated. It is noticed that the price affects the borrowing rate, and it also affects the amount of borrowing. Of course, the actual rate at which the borrowing rate increases will only be known after the crvUSD is officially launched.

TL;DR

• LLAMMA is the algorithm used by Curve to perform collateral liquidation, which - reduces losses during liquidation by distributing collateral across different price ranges.

• It generates arbitrage opportunities by using larger amplitude of price changes than external prices to dynamically liquidate collateral. When prices drop, collateral becomes crvUSD, and when prices rise, it becomes collateral again.

• PegKeeper mints or burns uncollateralized crvUSD to decrease or increase the crvUSD price, while Monetary Policy controls borrowing rates to anchor crvUSD at 1 USD.

The design of Curve Finance's mechanism is very sophisticated and is worth further study in terms of its implementation. When understanding the stablecoin mechanism of Curve, it is found that PACO has a deep understanding of studying Curve stablecoin. His articles and videos have been very helpful. The charts used in this article are from PACO's data, and it is highly recommended to read PACO's articles and videos for a deeper understanding. These references will be provided.

This article represents my own understanding and summary of researching Curve stablecoins, and I hope it can help readers gain some understanding of the mechanism. If there are any errors in the article, please kindly point them out and provide corrections. Discussions and exchanges of opinions are also welcomed. Finally, I would like to thank Cyan Ho for reviewing this article and providing some ideas for improvement.

Reference

• curve-stablecoin whitepaper

• LLAMMA - crvUSD 的新清算機制

• 
  

• November 22, 2022: $crvUSD White Paper

• crvUSD simulator

• 
  

• Path-Dependence

• https://paco0x.org/curve-stablecoin/

Zerion 是利用鏈下判斷該帳戶是否有 Genesis NFT。若確認有擁有 Genesis NFT，Zerion的 Signer 去簽署一筆 fee = 0 的簽章並放在交易中。當交易送到合約的時候會去判斷簽章是否為 Zerion Signer 所簽。若為 Zerion Signer 所簽就不收費。

Trace Flow

在呼叫 Zerion swap token 的時候會去呼叫 Zerion Router 的execute() external function。

因為我們想要知道 protocol fee 在什麼時候被收取，所以我們直接跳到最後 return execute(input, output, swapDescription) 這個 internal function 去看發生什麼事。

在 execute() internal function 中，我們往下走在 #196 行會發現這一行程式碼 Base.transfer() 。這行程式碼就是把 fee 傳送到 Zerion MultiSig 中。

fee 的數量就是 protocolFeeAmount 所記錄的數值。哪這個數值是在哪邊決定的呢？往上面的程式碼找尋可以發現 protocolFeeAmount 是從 getReturnedAmounts() 所決定。

在 getReturnedAmounts() 的 #496 是決定 protocolFeeAmount 的數字怎麼來。可以發現它是由 totalFeeAmount * protocolFee.share 所決定。

我們知道若 Sender 持有 Genesis Card NFT 可以擁有 Zero Fee 的減免。protocolFeeAmount 變成 0 條件有兩個。 totalFeeAmount 等於 0 或protocolFee.share 等於 0 （或同時為 0 ）。 於是我找了一個擁有 Genesis Card NFT 且 fee 為 0 的 transaction 來一探究竟。 使用 Tenderly 發現他的 protoclFee.share 就是帶 0。由此判斷是一開始帶進來的參數就指定了 protocolFee.share來決定這次 protocol fee 要收多少。

此時出現一個疑問。若 protocol fee 是由參數帶進來，那我們不就可以任意決定 protocol fee 了嗎？這時候讓我們回頭看到一開始的 execute() extneral function。

裡面跟 Fee 有關的檢查是 validateProtocolFeeSignature() 這一個 function。接下來我們就來分析裡面做了什麼事情。

第一個部分是去檢查這次交易有沒有包含 protocolFeeSignature。若沒有（length會等於0）就單純檢查收 fee 的對象和 protocolFee.share 是否跟 contract 預設的一樣。

若有帶 protocolFeeSignature ，就去呼叫 hashProtocolFeeSignatureData() 取得 signatureData。

hashProtoclFeeSignatureData 就是把部分參數包含 swapDescription 和 dealine等取 hash 值。這個 hash 就是 Signature 所簽的 data。

得到了 signature data 之後就去呼叫 isValidSignatureNow() 來比對簽章是否正確。可以注意 isValidSignatureNow() 其中一個參數是 getProtoclFeeSigner() ，這個是 Zerion Router 合約裡面所定義的 signer。

isValidSignatureNow() 裡面就做兩件事情。

1. 利用剛剛得到的 hash 和 signature 來還原簽署的 address (就是裡面的 recovered)。比對 recovered 和 signer 是否相同。若相同就代表這是由 Zerion signer 所簽署，確認 swapDescription 裡面所帶的 protocolFee 相關資訊是被 Zerion Signer 所認可。

2. 下方的 staticall 是支援若 Zerion Signer 是合約而非單純的 EOA。因為合約沒有 key，所以無法簽署簽章。所以利用 ERC1271 的方式來實現合約簽章。詳細內容可以參考這篇文章。

若確認簽章無誤，最後就檢查是否超過簽署的 dealine。

通過 deadline 的檢查後，就會依照 protocolFee 所記錄的資訊（包含 reciver 和 fee amount）去收取 protocol fee。

Takeaway

因為目前跨鏈的機制還尚未成熟，所以 Zerion 利用一個 signer 的角色來判斷該筆交易是否需要收 protocol fee。這樣的機制或許不是那麼去中心化，但卻是一個比較合理的做法。這樣的方式可以快速運用在不同的鏈上，而不需要考慮鏈與鏈之前該如何溝通。使用者也只需要在某個鏈上擁有該 NFT 就好，不需要每個鏈都有。缺點仍是中心化，若之後 Zerion 想要修改規則，變成改收 1% 的 protocol fee，一般使用者也只能乖乖接受（Zerion Signer 可以簽他們想要簽的任何交易）。在過渡時間這尚可是一個可以接受的方式，期待未來跨鏈機制的成熟，就不需要利用這個中心化的方式來做，而可以真的直接讀取鏈上的資訊來收費。

最近剛好看到有人介紹 ERC721 相關的變形。其中 ERC721Psi 又是其中針對 降低 gas cost 最有效率的一個，於是興起了研究的想法。這邊跟大家介紹一下 ERC721Psi 主要改進了什麼和用什麼方式改進

Introduce ERC721

ERC721 是目前主流的 NFT 的格式之一（另外還有 ERC1155)。大家對於 NFT 的需求增高，隨之而來的就是成本的降低。各種 ERC721 的變形也就孕育而生。介紹一下 ERC721 的一些概念，這些概念有助於理解上ERC721Psi 是如何減少 gas cost。在 ERC721 中每一個 token 對應一個 NFT，每一個 token 都有自己的 tokenId 和 owner 。在 ERC721 合約中會有一個 _owners 的 map 來記錄 tokenId 對應的 owner 。當你在傳送 token 給其他人的時候，就會去修改 _owners 該 token 的 owner。

當你同時 mint 多個 NFTs 的時候，你需要對這些 NFTs 在 _owners 對應的位置寫上你的 address 來表示你是這些 NFTs 的 owner。這也導致在 mint 多個 NFTs 時所需要花費的 gas 會是 mint 單一個 NFT 時的複數倍。那有什麼方式可以減少 gas cost 嗎？

ERC721A

ERC721A 是由著名的 NFT Project — Azuki 開發團隊所發表。其中針對於 mint 多個 NFT 所花費的 gas cost 進行了改善。

其原理我用一個範例來解釋。假設今天我 (Albert) 一口氣去 mint 第50號～第54號的 NFT (50,51,52,53,54)。如果是原本 ERC721 的做法，在這些 NFTs 都會寫上 owner 是 Albert。

若是 ERC721A 的做法會變成，只有第一個 (#50) 的 NFT 會填上 owner = Albert 。其他的 NFTs (#51~#54) 都會是 owner_not_set 的狀態。

若我們今天想要把 #53 NFT 轉移給 Bob 時，要如何知道 #53 NFT 的 owner 就是 Albert 呢？此時我們只要從 #53 NFT 往前找，找到第一個有 owner 的 NFT，該 owner 就是 #53 NFT 的 owner。此時只要把 #53 NFT 的 owner 填上 Bob ，並把 #54 NFT 的 owner 填上 Albert 就可以了。若沒有把 #54 NFT的 owner 也一併填上 Albert 話，會導致連 #54 NFT 都是 Bob 擁有。

可以從上圖發現從 #53 NFT 要確認 owner 是 Albert 需要往前找三個 token 才知道 owner 是 Albert。那有什麼方式可以快速知道這件事嗎？這個就是 ERC721Psi 想要改善的問題。

ERC721Psi

ERC721Psi 利用神奇的演算法有辦法快速定位距離 #53 最近有 owner 的 NFT 是哪一個。在解說之前有一些觀念需要先跟大家解說一下，方便等一下知道是如何運用在 ERC721psi 中。

Bitmap

因為存在電腦中的資料都是以二進位方式儲存，二進位的特性來記錄和運算資料。其中每一個 bit 我們都個別可以拿來記錄資料。舉例現在有三個 NFT (#1, #2 和 #3），我們可以使用一個 uint8 的變數和搭配 bitmap 的方式來記錄他們有沒有 被 mint。 因為uint8 變數以二進位表示剛好有 3 bit ( 000 )。當每一個 bit 為 0 的時候我們可以視為沒有被 mint，當 bit 為 1 可以視為已經被 mint 出來了。上面那張圖表示 #1 NFT 已經被 mint 出來了，#2 和 #3 還沒有，此時 uint8變數值為 4 (十進位）。下面那張圖的 uint8變數值為 5 （十進位），表示 #1 和 #3 皆都 mint 出來，唯獨 #2 還沒有。

De Bruijn Sequence

de Bruijn sequence 是指有某種特性的數列。當這個數列是由 k 種字母組成，給定長度為 n 的連續子數列，總長度為 k^n 。每一種子數列裡面的組合皆不一樣，這種數列我們就稱之為 de Bruijn sequence （標示成 B(k, n)）。舉例來說，我們設定 k= 2 ，字母就選 0 和 1 表示。n = 3：代表連續子數列長為 3。整個數列長度會是 2³ = 8。 數列 00010111就剛好是符合這些條件的其中一種 de Brujin Sequence。由下圖可以發現每個 sub-sequence 都是不同的排列組合。若把他們轉成數字會發現每個 sub-sequence 都會對應一個唯一數字。

How to index the owner of token Id

用一個例子來說明在 ERC721Psi 是怎麼利用上面兩個技術來達成快速找到 owner 。在 contract 裡面是用 256 bitmap 來記錄 owner。為了大家理解方便，我們這邊還是使用 8 bitmap 來說明。 主要的 function 是 BitMaps.sol 的 scanForward(uint256 index) ( index 是指 tokenId)。

Use Bitmap to record the existement of the owner of tokenId

uint256 bucketIndex = (index & off) 把 index 除與 256 來獲得此 tokenId 會是放在哪一個 bucket。一個 bucket 是以 256 為一個單位（表示存放了 256 tokenId 的 owner)。 uint256 bucketIndex = (index & 0xff) 計算出在該 bucket 中這個 tokenId 對應的位置。 bb = bb >> (0xff ^ bucketIndex) 是將要查詢的 tokenId 對應的 bitmap 移到最右邊。情形會如同下圖所示。Batch Head 就是我們要找該 tokenId 的 owner

Find LS1B

我們希望 tokenId 往左邊第一個 bit 為 1 的位置留下來，其他都設成 0 。這邊使用了一個小技巧，如 isolateLS1B256(uint256) 所示。

呈現的效果就會如同下圖所示，除了從右邊數來第一個 1 的位置是 1 之外，其他都為 0 。

圖中可以發現距離 1 的位置有三個間隔，所以表示我們需要往右移動三次。那有什麼方式可以不用移動三次就可以知道 1 的位置呢？這就要用到 De Bruijn Sequence

利用 De Bruijn Sequence 快速找出與 LS1B 的距離

De Bruijn Sequence 就以前面的 000101111 做範例。我們現在已經知道 LS1B ( 00001000) 是在右邊數過來第四個位置。此時把 LS1B ( 00001000) 和 De Bruijn Sequence(000101111 ) 做相乘，等同於跟把 De Bruijn Sequence(000101111 ) 往左移 4 個 bit。之後再把得到的結果往右移 k^n-n 位數（範例 k=2, n=3, 2^3-3 = 5)。可得到對應的且唯一的 sub-sequence( 101)。

因為唯一 sub-sequence 會對應一個唯一數字。我們可以針對這些數字建立一個 map (or lookup table)。key 為 sub-sequence number， value 為與 LS1B 之間的距離。這樣就可以直接快速定位出與 LS1B 的距離而不需要利用輪詢的方式找出。

Gas Cost

可以發現不管是在執行 mint 或者做 transfer 所花費的 gas 都有顯著的減少。

Takeaway

以上就是主要 ERC721Psi 用來減少 gas cost 主要用到的技術。熱門的 project所消耗的 gas 可以說是非常驚人。所以現階段在開發 dApp 時候，gas cost 也會成為主要考量之一。ERC721 Psi 開發者使用的手段非常精妙，非常值得學習。但因為 ERC721Psi 尚未經過市場驗證，是否能保證一定安全無虞，還需要時間的考驗。隨著 L2 或其他 L1 公鏈的興起，gas cost 有機會可以大幅下降。屆時 dDapp 的架構會可以進一步更加複雜，能實現的更多的功能！

Reference

• ERC721PSI

• ERC721 Github

Scenarios

Man-in-the-middle attacks are usually avoided by using this method. For example, to retrieve txdata, load it into a transaction, and send it out, the user will frequently utilize the paraswap API. The user's assets may be lost if the returned txdata is maliciously manipulated by an intermediary hacker. You may now use paraswap's allowlist to check whether the returned txdata is accurate. (This is just an example; I'm not sure whether or not paraswap uses allowlist.)

Allowlist defines a schema that other people can use to make their own allowlists. Multiple conditions make up the allowlist. When txdata meets one of the conditions, it is valid.

Flow

Condition

A condition refers to a function and provides an implementation contract. A condition defines the data sequence (including checking function, implementation id...) The format of each condition is depicted in the diagram below.

• id: condition id

• implementationId: An implementation contract address is represented by an id. The imlementationById map stored in the allowlist contract corresponds to the id and contract address.

• methodName: The name of the target contract's method to invoke.

• paramTypes: The types of the function arguments.

• requirements : There are two parts (type and verify function). target (check target contract) and params are the two types (check function parameters). The verification function specifies which implementation function should be used for checking.

ValidateCalldataByAllowlist() checks every condition registered in Allowlist. testCondition() will go over the conditions that were previously registered in Allowlist.

Verify the order

Check Function Selector

Calculate the function selector using the methodName and paramTypes of the condition to compare the first four bytes of txdata.

Check Target Address

CheckTarget() is called if the requirement type is target. To generate txdata, use methodSignature and targetAddress, and call the implementation's verify function with staticCall.

Check function parameters

If the requirement type is params, CheckParams() is called. To acquire the parameter values, use AbiDecoder.getParamFromCalldata() with data and paramsTypes.

To make a txdata, combine the verify function (methodSignature) with the value of the params just solved. To call the implementation's verification function, use staticCall.

Connect Allowlist to website

It is advised that you utilize ENS/DNSSEC to validate the Allowlist's authenticity.

Personal Thoughts

DApps are becoming increasingly complicated, and performing all computations on-chain will undoubtedly consume a significant amount of gas. Off-chain APIs may become a viable option in the future, but they raise additional security risks. Allowlist is an attempt to reconcile off-chain and on-chain data inconsistencies. To reduce risks and prevent the loss of user assets caused by malicious attacks, it is suggested that all services that provide APIs develop an Allowlist method.

Reference

• Yearn Allowlist

• yearn-allowlist

• yearn/eth-allowlist