Kapil Dagar (Backend-Associate Consultant L1 - Development)

With the increasing popularity of blockchain app development and cryptocurrencies, many concepts have emerged that exploit the capabilities of these systems. The development of Layer 2 solutions for Ethereum is one of these concepts. As a developer in this space, you may have encountered situations where you need to create contracts for bridging funds between Ethereum and a Layer 2 chain.

Before we delve into the intricacies of bridging, let's first understand Layer 2 solutions. Layer 2 is a collective term referring to various protocols designed to help scale the Ethereum blockchain by handling transactions “off-chain” and only interacting with the main chain when necessary.

Some popular Layer 2 solutions include Optimistic Rollups, zk-Rollups, and sidechains (e.g., xDai and Polygon). These solutions help minimize transaction costs while increasing throughput capacity.

In simple terms, Layer 2 solutions serve as a “bridge” between the Ethereum mainnet and other chains. Users can move their funds to a Layer 2 chain to leverage lower transaction fees and higher throughput, while still having the ability to securely move their funds back to the Ethereum mainnet if needed.

Basic Structure of a Bridge Contract:

The main components of a bridge contract consist of two separate contracts deployed on each chain :

1. Ethereum (Main Chain) Contract: Manages locked tokens on the Ethereum side and communicates with the Layer 2 Contract.

2. Layer 2 Contract: Manages locked tokens on the Layer 2 side and communicates with the Ethereum Contract.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";

contract Layer2Bridge is ReentrancyGuard {
    using SafeERC20 for IERC20;

    address public immutable l2Bridge;
    
    event TokensLocked(
        address indexed sender,
        address indexed token,
        uint256 amount,
        address indexed l2Recipient
    );

    event WithdrawalCompleted(
        address indexed l2Sender,
        address indexed token,
        uint256 amount,
        address indexed l1Recipient
    );

    constructor(address _l2Bridge) {
        l2Bridge = _l2Bridge;
    }

    /**
     * @notice Lock tokens to be bridged to Layer 2
     * @param token ERC20 token address to lock
     * @param amount Amount of tokens to lock
     * @param l2Recipient Recipient address on Layer 2
     */
    function lockTokens(
        address token,
        uint256 amount,
        address l2Recipient
    ) external nonReentrant {
        IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
        emit TokensLocked(msg.sender, token, amount, l2Recipient);
    }

    /**
     * @notice Complete withdrawal from Layer 2 (callable only by L2 bridge)
     * @param l2Sender Original sender address on Layer 2
     * @param token ERC20 token address to release
     * @param amount Amount of tokens to release
     * @param l1Recipient Recipient address on Layer 1
     */
    function completeWithdrawal(
        address l2Sender,
        address token,
        uint256 amount,
        address l1Recipient
    ) external nonReentrant {
        require(msg.sender == l2Bridge, "Unauthorized bridge caller");
        IERC20(token).safeTransfer(l1Recipient, amount);
        emit WithdrawalCompleted(l2Sender, token, amount, l1Recipient);
    }
}

Also, Explore | Implementing a Layer 2 payment channel network in Ethereum

This Solidity smart contract, Layer2Bridge, simply implements a Layer 1 to Layer 2 (L1-L2) bridge for transferring ERC20 tokens between two blockchain layers. It enables locking tokens on Layer 1 (Ethereum) for eventual release on Layer 2 and vice versa. Here's an in-depth explanation:

Overview

1. Layer 2 Bridges:

• Bridges connect two blockchain layers (L1 and L2) to facilitate interoperability.
• Tokens are locked on one layer (e.g., L1) and "minted" or released on another layer (e.g., L2) after verification.

2. Purpose of this Contract:

• Lock tokens on Layer 1 to initiate a transfer to Layer 2.
• Release tokens on Layer 1 after a valid withdrawal is processed from Layer 2.

Also, Check | Optimism Platform: Developing and Implementing Layer 2 Smart Contracts

Key Components

1. Imports
 

The contract imports critical OpenZeppelin libraries to implement secure token transfers and prevent reentrancy attacks:

1.IERC20: Interface for interacting with ERC20 tokens.

2.ReentrancyGuard: Prevents reentrancy attacks on critical functions.
 

3.SafeERC20: Provides safer methods for interacting with ERC20 tokens, ensuring compatibility with non-standard implementations.

2. State Variables

address public immutable l2Bridge;

l2Bridge: Stores the address of the Layer 2 bridge contract.

• Immutable: This value is set once during contract deployment and cannot be changed later.
• Only this l2Bridge address is authorized to call the completeWithdrawal function.

Also, Discover | Layer 3 Blockchains | Understanding Advanced Decentralization

3. Events

Events are used to log important actions on the blockchain for tracking and transparency.

event TokensLocked(address indexed sender, address indexed token, uint256 amount, address indexed l2Recipient);
event WithdrawalCompleted(address indexed l2Sender, address indexed token, uint256 amount, address indexed l1Recipient);

TokensLocked:

• Emitted when tokens are locked on L1 for transfer to L2.
• Logs the sender, token address, amount, and recipient on L2.

WithdrawalCompleted:

• Emitted when tokens are released on L1 after a valid withdrawal from L2.
• Logs the sender on L2, token address, amount, and recipient on L1.

4. Constructor

constructor(address _l2Bridge) {
   l2Bridge = _l2Bridge;
}

Accepts _l2Bridge, the address of the Layer 2 bridge contract, and stores it in l2Bridge.

5. lockTokens Function

function lockTokens(
   address token,
   uint256 amount,
   address l2Recipient
) external nonReentrant {
   IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
   emit TokensLocked(msg.sender, token, amount, l2Recipient);
}

Purpose: Locks tokens on Layer 1 to initiate their transfer to Layer 2.

Parameters:

1. token: Address of the ERC20 token being locked.
2. amount: Number of tokens to lock.
3. l2Recipient: Address on Layer 2 that will receive the tokens.

Process:

• Uses safeTransferFrom (from SafeERC20) to securely transfer amount tokens from msg.sender to the bridge contract.
• Emits the TokensLocked event, logging the action.

Security:

nonReentrant modifier prevents reentrancy attacks during the token transfer process.

You may also like | Layer 2 Solutions for Crypto Exchange Development

6. completeWithdrawal Function

function completeWithdrawal(
   address l2Sender,
   address token,
   uint256 amount,
   address l1Recipient
) external nonReentrant {
   require(msg.sender == l2Bridge, "Unauthorized bridge caller");
   IERC20(token).safeTransfer(l1Recipient, amount);
   emit WithdrawalCompleted(l2Sender, token, amount, l1Recipient);
}

Purpose: Releases tokens on Layer 1 after a valid withdrawal from Layer 2.

Parameters:

1. l2Sender: The original sender on Layer 2.
2. token: Address of the ERC20 token to release.
3. amount: Number of tokens to release.
4. l1Recipient: Address on Layer 1 to receive the tokens.

Process:

• Verifies that msg.sender is the authorized Layer 2 bridge (l2Bridge).
• Uses safeTransfer to securely transfer amount tokens to the l1Recipient.

• Emits the WithdrawalCompleted event, logging the action.

   

  Security:

   

• Only the l2Bridge address can call this function (require statement).
• nonReentrant modifier ensures no reentrancy during the token transfer.

Also, Read | Layer 0 Blockchain Development | The Foundation of the Future

How the Contract Works

Locking Tokens (L1 to L2):

• Users call lockTokens, providing the ERC20 token, amount, and Layer 2 recipient address.
• The contract locks the tokens by transferring them to itself.

• Emits the TokensLocked event to signal the Layer 2 bridge to release tokens on L2.

  
  Withdrawing Tokens (L2 to L1):

   

• When tokens are withdrawn from L2, the Layer 2 bridge calls completeWithdrawal on this contract.
• The function validates the caller and releases the specified tokens to the recipient on Layer 1.

• Emits the WithdrawalCompleted event for logging.

   

Use Cases

Cross-Layer Token Transfers:

• Tokens locked on Layer 1 can be "bridged" to Layer 2 by minting or crediting equivalent tokens on L2.
• Similarly, tokens can be "bridged back" from Layer 2 to Layer 1.

Decentralized Finance (DeFi):

• Facilitates token transfers between L1 (e.g., Ethereum) and L2 (e.g., Optimism, Arbitrum) for reduced gas fees and faster transactions.

• Security Considerations

  
  Reentrancy Protection:

   

Both critical functions (lockTokens and completeWithdrawal) use the nonReentrant modifier to prevent attacks.

Authorized Calls:

Only the designated l2Bridge address can call completeWithdrawal, preventing unauthorized token releases.

Safe Token Transfers:

• Uses SafeERC20 to handle potential token transfer failures gracefully.
• This contract is a foundational building block for bridging tokens between layers and can be extended with additional features like fees, governance, or custom verification mechanisms.

You might be interested in | How Polygon AggLayer Emerges to be the Hub for Ethereum L2s

Conclusion

In conclusion, the Layer2Bridge smart contract serves as a fundamental tool for facilitating secure and efficient token transfers between Ethereum's Layer 1 and Layer 2 solutions, enabling users to leverage the benefits of reduced transaction fees and increased throughput offered by Layer 2 protocols. By implementing robust security measures such as reentrancy protection, authorized call restrictions, and safe token transfers, the contract ensures the integrity and reliability of cross-layer transactions. This foundational implementation can be further enhanced with additional features to meet specific use cases, making it a versatile and essential component in the evolving landscape of decentralized finance and blockchain interoperability. If you are looking to explore the applications of layer 2 blockchain development, connect with our blockchain developers to get started. 

What is a TCR (Token Curated Registry)

A Token Curated Registry (TCR) is an incentivized voting system that helps create and maintain trusted lists, managed by the users themselves. Utilizing the “Wisdom of the Crowds” concept, participants vote with tokens to determine which submissions are valid and should be included on the list.

In blockchain app development, TCRs play a vital role in curating and managing lists of information via blockchain technology. These registries are powered by community-driven efforts, ensuring the quality and reliability of data. TCRs replace traditional centralized systems with transparent, trustless alternatives, aligned with the goals of Web3 consulting services, which focus on decentralized solutions for list management.

A Token Curated Registry (TCR) operates on three key components:

1. Token Economy: The native token serves as a stake for participants, incentivizing accurate curation through voting and staking.
2. Governance Structure: Smart contracts enforce transparent and automated rules for voting, entry evaluation, and dispute resolution, ensuring fairness and reducing bias.
3. Curation Process: Community-driven proposals, voting, and maintenance ensure high-quality entries, leveraging the token economy and governance.

These components create a decentralized, efficient, and robust system for managing information, aligning with Web3 solutions.

Registration Period
 

A new restaurant, “Tommy's Taco's” – thinks they're worthy of being included; so they submit a deposit using the TCR's token. This begins, the “registration period.” If the community agrees to include Tommy's Tacos into the registry, everyone simply waits for a registration period to expire and the submission is added.

Challenge Period
 

If the community believes a submission should not be included, a "challenge period" is triggered. A challenge begins when a user matches the submission deposit, prompting a vote.

All token holders can then vote to either include or exclude "Tommy's Tacos" from the list.

• If the vote favors exclusion, "Tommy's Tacos" loses its deposit, which is redistributed to the challenger and those who voted for exclusion.

• If the vote favors inclusion, the challenger's deposit is forfeited and redistributed to those who voted for inclusion.

   

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract MyERC20Token is ERC20, Ownable {
   constructor(string memory name, string memory symbol, uint256 initialSupply, address initialOwner) 
       ERC20(name, symbol) 
       Ownable(initialOwner) 
   {
       _mint(initialOwner, initialSupply);
   }

   function mint(address to, uint256 amount) external onlyOwner {
       _mint(to, amount);
   }

   function burn(address from, uint256 amount) external onlyOwner {
       _burn(from, amount);
   }
}

contract TokenCuratedRegistry {
   struct Listing {
       address proposer;
       uint256 deposit;
       bool approved;
       uint256 challengeEnd;
       uint256 voteCount;
       mapping(address => bool) voters;
   }

   MyERC20Token public token;

   mapping(bytes32 => Listing) public listings;
   uint256 public challengePeriod;
   uint256 public minDeposit;

   event ListingProposed(bytes32 indexed listingId, address proposer, uint256 deposit);
   event ListingChallenged(bytes32 indexed listingId, address challenger);
   event ListingApproved(bytes32 indexed listingId);
   event ListingRejected(bytes32 indexed listingId);

   constructor(address _token, uint256 _minDeposit, uint256 _challengePeriod) {
       require(_token != address(0), "Invalid token address");
       token = MyERC20Token(_token);
       minDeposit = _minDeposit;
       challengePeriod = _challengePeriod;
   }

   function proposeListing(bytes32 listingId) external {
       require(listings[listingId].proposer == address(0), "Listing already exists");
       require(token.transferFrom(msg.sender, address(this), minDeposit), "Token transfer failed");

       listings[listingId].proposer = msg.sender;
       listings[listingId].deposit = minDeposit;
       listings[listingId].approved = false;
       listings[listingId].challengeEnd = block.timestamp + challengePeriod;
       listings[listingId].voteCount = 0;

       emit ListingProposed(listingId, msg.sender, minDeposit);
   }

   function challengeListing(bytes32 listingId) external {
       require(listings[listingId].proposer != address(0), "Listing does not exist");
       require(block.timestamp <= listings[listingId].challengeEnd, "Challenge period over");

       emit ListingChallenged(listingId, msg.sender);
   }

   function vote(bytes32 listingId, bool approve) external {
       require(listings[listingId].proposer != address(0), "Listing does not exist");
       require(!listings[listingId].voters[msg.sender], "Already voted");

       listings[listingId].voters[msg.sender] = true;
       if (approve) {
           listings[listingId].voteCount++;
       } else {
           listings[listingId].voteCount--;
       }
   }

   function finalize(bytes32 listingId) external {
       require(listings[listingId].proposer != address(0), "Listing does not exist");
       require(block.timestamp > listings[listingId].challengeEnd, "Challenge period not over");

       if (listings[listingId].voteCount > 0) {
           listings[listingId].approved = true;
           emit ListingApproved(listingId);
       } else {
           token.transfer(listings[listingId].proposer, listings[listingId].deposit);
           delete listings[listingId];
           emit ListingRejected(listingId);
       }
   }

   function withdrawDeposit(bytes32 listingId) external {
       require(listings[listingId].approved, "Listing not approved");
       require(listings[listingId].proposer == msg.sender, "Not proposer");

       token.transfer(listings[listingId].proposer, listings[listingId].deposit);
       delete listings[listingId];
   }
}

This code implements two Ethereum smart contracts:
 

MyERC20Token: A standard ERC20 token contract with added minting and burning functionality.
TokenCuratedRegistry: A Token Curated Registry (TCR) system that uses MyERC20Token for staking and manages a registry of items.

1. MyERC20Token Contract
 

This contract inherits from OpenZeppelin's ERC20 and Ownable contracts. It provides a secure, extensible implementation for creating ERC20 tokens.

Key Features:

Constructor:

• Accepts token name, symbol, initial supply, and the owner's address.
• Initializes ERC20 with the name and symbol.
• Mints the initial supply of tokens to the owner.
   

Mint Function:

• Allows the owner to mint new tokens.
• Uses onlyOwner modifier to restrict access.
   

Burn Function:

• Allows the owner to burn tokens from a specific address.
• Uses onlyOwner modifier for access control.

Also, Check | Ethereum Distributed Validator Technology | DVT for Staking

2. TokenCuratedRegistry Contract

This contract allows users to propose, challenge, and vote on items in a registry. It leverages the MyERC20Token for deposits and voting power.

Key Components:

Struct: 

Listing:

Represents a registry entry with the following fields:

proposer: The address of the proposer.
deposit: Amount of tokens staked for the listing.
approved: Indicates whether the listing is approved.
challengeEnd: Timestamp when the challenge period ends.
voteCount: Tally of votes.
voters: Tracks addresses that have voted.
 

Variables:

token: Reference to the MyERC20Token used for staking.
listings: Mapping of listing IDs to their respective Listing structs.
challengePeriod: Time allowed for challenges.
minDeposit: Minimum token deposit required for a proposal.
 

Functions:

Constructor:

• Accepts token contract address, minimum deposit, and challenge period.
• Initializes the contract with these values.
   

Propose Listing:

• Users propose a listing by staking tokens.
• Tokens are transferred to the contract, and a new Listing struct is created.

• Emits ListingProposed.

  
  Challenge Listing:

   

• Allows users to challenge a listing within the challenge period.

• Emits ListingChallenged.

  
  Vote:

• Users can vote on a listing to approve or reject it.
• Prevents double voting using a mapping.

• Adjusts the voteCount based on the vote.
   

  Finalize:

   

• Can be called after the challenge period ends.
• If the vote count is positive, the listing is approved.
• If negative, the listing is rejected, and the staked tokens are refunded.

• Emits ListingApproved or ListingRejected.

  
  Withdraw Deposit:

   

• Allows the proposer to withdraw their deposit if the listing is approved.
• Deletes the listing entry.

You may also like | How to Create a Multi-Signature Wallet on Solana using Rust

Explanation of Workflow
 

Proposing a Listing:

• A user calls proposeListing with a unique listingId.
• The user deposits tokens into the contract.
• A Listing struct is created, and the challenge period begins.

Challenging a Listing:

• During the challenge period, any user can challenge the listing.
• This initiates the voting phase.

Voting:

• Users vote to approve or reject the listing by calling vote.
• Each user can vote only once for a listing.
   

Finalizing:

• After the challenge period, the finalize function is called.
• If approved, the listing remains in the registry.
• If rejected, the staked tokens are refunded to the proposer.
   

Withdrawing Deposits:

• If a listing is approved, the proposer can withdraw their staked tokens using withdrawDeposit.

Security and Design Considerations
 

Reentrancy Protection:

• The code assumes that token transfers are safe and non-reentrant.
• For additional security, you may consider adding the ReentrancyGuard modifier.

Discover more | How to Deploy a Distributed Validator Node for Ethereum 2.0

Double Voting Prevention

The voter mapping ensures that users cannot vote multiple times.

Extensibility:

The MyERC20Token contract allows minting and burning, making it flexible for use in various scenarios.

Ownership:

The Ownable contract restricts certain functions like minting and burning to the contract owner.
 

Usage Example
 

Deploy MyERC20Token:

Provide the name, symbol, initial supply, and owner's address.

Deploy TokenCuratedRegistry:

Provide the address of the deployed MyERC20Token, the minimum deposit, and the challenge period.
 

Interact:

Users can propose, challenge, vote, finalize, and withdraw deposits using the respective functions.

Also, Read | Creating a Token Vesting Contract on Solana Blockchain

Importance of a Token Curated Registry (TCR)
 

Token Curated Registries (TCRs) play a vital role in the decentralized Web3 ecosystem due to their innovative approach to managing information. Here's why TCRs are important:

Decentralized Data Curation:

TCRs enable communities to collaboratively manage and curate high-quality lists without relying on centralized authorities. This fosters trust and transparency in decision-making.

Incentivized Participation:

The token economy ensures active engagement by rewarding honest behavior and penalizing malicious actions. Participants are motivated to contribute accurate and valuable information.
 

Quality Assurance:

The community-driven voting process ensures that only trustworthy and high-quality entries are included in the registry. It promotes accountability and discourages low-quality submissions.
 

Transparency and Trust:

Governance rules encoded in smart contracts ensure that the curation process is fair, transparent, and tamper-proof. Anyone can audit the on-chain activity.
 

Automation:

Smart contracts automate critical processes such as voting, staking, and dispute resolution, reducing overhead and human error. This creates an efficient system that operates independently.
 

Applications in Web3:

Reputation Systems: Curate lists of trusted participants or products in decentralized marketplaces.
Content Curation: Manage lists of valuable articles, assets, or media on decentralized platforms.
Token Listings: Curate quality tokens for decentralized exchanges or fundraising platforms.
 

Alignment with Web3 Principles:

TCRs embody the core values of Web3: decentralization, community empowerment, and censorship resistance. They provide a scalable solution for decentralized governance and information management.
 

Dispute Resolution:

TCRs offer built-in mechanisms for resolving disputes via challenges and community voting, ensuring that errors or biases are corrected. In summary, TCRs are essential for creating trustless, decentralized, and efficient systems for data and information management. They empower communities to curate valuable information while maintaining alignment with the principles of Web3 development.

Also, Discover | Integrate Raydium Swap Functionality on a Solana Program

Conclusion

In conclusion, Token Curated Registries (TCRs) offer a decentralized and efficient way to manage trusted lists in the Web3 ecosystem. By leveraging token-based incentives and community-driven governance, TCRs ensure transparency, quality, and accountability in data curation. This approach aligns with the core principles of Web3, empowering users to curate valuable information while eliminating the need for centralized authorities. If you are looking for blockchain development services, consider connecting with our blockchain developers to get started.