Home

Awesome

FH-EVM T-Rex Token Protocol - Enhanced Privacy Edition

1st place of Zama Season 6 Bounties

https://github.com/zama-ai/bounty-program

image

Overview

This repository contains the upgraded version of the T-Rex Token protocol, integrating Fully Homomorphic Encryption Virtual Machine (FHEVM) technology. The protocol is designed to enhance the privacy of token transactions by hiding the transfer amounts, balances, and total supply of the T-Rex Token.

What is the problem ?

Privacy Enhancement

In traditional blockchain systems like Ethereum, all transaction details are publicly visible on the blockchain. This includes:

While this transparency is beneficial for auditability and trust, it can compromise privacy. Anyone can trace transactions, identify patterns, and potentially link addresses to real-world identities. This is particularly concerning for individuals and organizations who prioritize confidentiality in their financial activities.

Benefits of Hiding Information

  1. Enhanced Privacy: By hiding transfer amounts, balances, and total supply using FHEVM (Fully Homomorphic Encryption Virtual Machine), the T-Rex Token protocol ensures that sensitive financial data remains private. This is crucial for users who need to conduct transactions without exposing their financial details to the public.

  2. Preventing Financial Surveillance: In a fully transparent blockchain, it’s easy for anyone to monitor the financial activities of others. By encrypting these details, the T-Rex Token protocol makes it significantly harder for third parties to conduct financial surveillance or track user behavior.

  3. Increased Security: When financial details are hidden, it reduces the risk of targeted attacks. For example, if a malicious actor can’t see how much wealth is stored in an address, they have less incentive to target that address.

  4. Confidential Business Transactions: For businesses, maintaining confidentiality in their transactions is critical. Hiding transaction details ensures that business strategies, supply chain payments, and other sensitive activities remain confidential, protecting competitive advantages.

How Does It Make the T-Rex Token Protocol Better?

  1. Adoption in Privacy-Conscious Industries: By addressing privacy concerns, the T-Rex Token protocol becomes more appealing to industries and users who require confidentiality, such as healthcare, finance, and supply chain management.

  2. Compliance with Privacy Regulations: As global regulations increasingly emphasize the protection of personal data, the T-Rex Token protocol’s privacy features can help users and organizations comply with these laws while still leveraging blockchain technology.

  3. Future-Proofing: Privacy is becoming a critical aspect of blockchain technology as it evolves. By integrating advanced privacy features now, the T-Rex Token protocol positions itself at the forefront of this trend, making it more relevant in the future.

How Does It Work?

  1. Replacement of Standard Data Types in the T-Rex token:
    • The standard uint256 type used in the ERC20 token contract for storing balances, transfer amounts, and approval amounts has been replaced with a new encrypted data type, euint64.
    • euint64 is a type introduced by FHEVM that represents an encrypted unsigned 64-bit integer. This encryption ensures that all numerical values related to token operations are kept private, even as they are processed within smart contracts.
    /// @dev ERC20 basic variables
    mapping(address => euint64) internal _balances;
    mapping(address => mapping(address => euint64)) internal _allowances;
    euint64 internal _totalSupply;
    
    /// @dev Variables of freeze and pause functions
    mapping(address => bool) internal _frozen;
    mapping(address => euint64) internal _frozenTokens;
  1. Adapt functions in the T-Rex token that use those values:

Example on the approve function :

    // Function needed to be able to send encrypted amount from an EOA
    function approve(
        address spender,
        einput encryptedAmount,
        bytes calldata inputProof
    ) external override returns (bool) {
        approve(spender, TFHE.asEuint64(encryptedAmount, inputProof));
        return true;
    }

    function approve(address _spender, euint64 _amount) public returns (bool) {
        // Sender need to have the rights to access _amount cypher
        require(TFHE.isSenderAllowed(_amount));
        _approve(msg.sender, _spender, _amount);
        emit Approval(msg.sender, _spender);
        return true;
    }

    function _approve(address _owner, address _spender, euint64 _amount) internal virtual {
        require(_owner != address(0), "ERC20: approve from the zero address");
        require(_spender != address(0), "ERC20: approve to the zero address");
        _allowances[_owner][_spender] = _amount;
        // Need to give the rights to _owner, _spender and the contract to access this new cypher
        TFHE.allow(_allowances[_owner][_spender], address(this));
        TFHE.allow(_allowances[_owner][_spender], _owner);
        TFHE.allow(_allowances[_owner][_spender], _spender);
    }

One of the most challenging aspects of adapting the T-Rex Token protocol to use FHEVM is ensuring that the system accurately checks whether a token transfer is permitted. In the original ERC20 standard, checking the right to transfer tokens is relatively straightforward, as all relevant data—like balances, allowances, and compliance rules—are stored as plain uint256 values and can be easily compared and verified.

However, with the introduction of encrypted data types like euint64, the process becomes significantly more complex:

To maintain these compliance requirements in the context of encrypted data, significant modifications are necessary:

Tech Stack

Prerequisites

Before getting started, ensure you have the following installed:

WARNING ! Read that before executing anything !

Mock mode

1. Clone the Repository

git clone https://github.com/QiteBlock/fhevm-hardhat-t-rex.git
cd fhevm-hardhat-t-rex

2. Install Dependencies

pnpm install

3. Configure Environment

Rename .env.example to .env.

4. Run tests

pnpm test:mock

Tests

5. Run coverage

pnpm coverage:mock

Token Coverage Compliance Coverage Registry Coverage

Local node mode

1. Clone the Repository

git clone https://github.com/QiteBlock/fhevm-hardhat-t-rex.git
cd fhevm-hardhat-t-rex

2. Install Dependencies

pnpm install

3. Configure Environment

Rename .env.example to .env.

4. Start Fhevm

pnpm fhevm:start

5. Deploy the first token to swap

pnpm task:deployTREX --token-name TREXA --token-symbol TREXA

6. Deploy the second token to swap

pnpm task:deployTREX --token-name TREXB --token-symbol TREXB

7. Deploy the Dvd transfer manager

pnpm task:deployDVD

8. Update the .env file with addresses of the deployed contracts

export TOKEN_TREX_A=TO_BE_DEFINED
export TOKEN_TREX_B=TO_BE_DEFINED
export DVD_MANAGER=TO_BE_DEFINED

9. Execute the DVD (Delivery vs Delivery)

pnpm script:executeDVD

Dvd result

Dev network

1. Deployment with Zama default account

T-Rex token A

T-Rex token B

DVD Contract

Result in Devnet

Tests

2. Deployment with my account (Get some Zama token)

T-Rex token A

T-Rex token B

DVD Contract

Result in Devnet

Tests

7. License

This project is licensed under the GPL-3.0 License. See the LICENSE file for details.