Welcome back to another day of exploring Web 3 Engineering. It’s been a long since we have explored the defi world. Today let’s us getting into learning the famous crypto trading instrument that has been gaining volume recently and that is Perpetuals, popularly referred as Pers which are the derivatives on the cryptocurrencies.

What are Perps ?

Perpetuals or Perps are the derivate contracts that are usually traded in the crypto world. They work similar to the Futures Contracts on the traditional exchanges with a twist. Unlike the regular Futures contract, they don’t have an expiry date. Which means, a perps doesn’t expire and can be traded at any time in future once created.

How do they work ?

In order to understand the perpetuals, we need to understand the 6 distinct features of them. They are:

1. No Expiry - The perpetuals have no expiry date. Which means our positions remain active as long as we are able to pay the funding rate for it and we need to maintain required margin. If our account runs out of margin, the position will be closed and settled automatically by the exchange.

2. Funding Rate Mechanism -

   1. To keep the price of a perpetual contract similar to its actual asset, exchanges maintain funding rate system.

   2. Exchanges decide the funding cycle on their own. But in general, the funding cycle is 8 hours. And at the start of this cycle, traders are required to pay premium or receive discount depending on the difference between the contract price and the spot price.

   3. If the contract price is higher than the spot price (contract is trading at premium), long contract holders are required to pay to the short holders.

   4. If the contract price is less than the spot price (contract is trading at discount), short contract holders are required to pay to the long holders.

3. Leverage and Margin

   1. Margin is the amount of the capital we are using to create positions.

   2. Leverage is used to place a higher value contract order with little amount of money. For example, we can place a order of 1000USD with 100 USD margin using 10x leverage.

   3. In perpetual trading, leverage has more impact than the leverage in the traditional future contract since the crypto exchanges provide leverage up to 40x. (some provide a significant of 100x leverage depending on the asset).

4. Long vs Short

   1. You hold a long position when you expect the market price of asset goes higher. And you profit from it.

   2. You hold a short position when you expect the market price of asset goes down.

5. Settlement and Liquidation

   1. Unlike the traditional futures, perpetuals don’t have a predetermined expiry and settlement date.

   2. Profits and losses are marked to market in real time and positions can be liquidated if your margin runs too low.

Market to Market Settlements

1. In the perpetuals world, exchanges typically settle the positions and FRM payouts at the end of their trading cycle (which is usually 00:00 UTC)

2. This is carried out to liquidate the positions which ran out of margin and also reflect the P&L of the user in real time possibly and constrain the risk of high price movements of the assets.

3. Margin balance is credited or debited with this P&L—so you must have enough margin to cover losses. MTM keeps your profit and loss current, preventing large carry-forward risks if prices move sharply overnight

Types of Perpetuals available

There are various types of perpetuals that are offered in the market. But we need to focus on the main 3 that are listed below.

1. Linear Perpetual Contracts - These are straight forward contracts on a pair and the P&L calculation is also linear in fashion. For BTC / USDT perpetuals, the BTC is the asset and USDT is the quote currency in which margin and P&L payouts are carried

2. Inverse Perpetual Contracts - These type of contracts are determined in terms of base assets rather than the quote assets. In simple words, for a BTC / USDT pair, the settlement and margin is taken in BTC and not USD. If the USD price of BTC is increasing, our profit in BTC decreases and vice versa

3. Quanto Perpetual Contracts - The contract’s P&L and margin are carried out in third currency which is neither base nor quote of the contract. For example, Margin and settlement being carried in ETH for the perps on BTC / USDT. This is most popular since exchanges accept USDC / USDT usually but carry out payments in the exchange release stable coins.

Trading

Since the perpetuals are not actual spot but derivates, it can only be traded using order matching. That means we have a seller and buyer for the trade and there are not DEX pools built so far. These order matching can take various forms that is specific to the exchange itself. The popular methodologies that I have seen so far are:

1. Order book market matching ( price time priority)

2. Auction based order matching

And also depending on the order flow, there are centralized and hybrid exchanges available in the market.

1. Fully centralized - Order placing, Settlement, Margin infusion and also order matching takes place through a centralized app. e.g., Binance Exchange

2. Hybrid - Order placing, position management and settlements takes place on blockchain where the actual order matching happens using off chain servers. e.g. dydx

With that, we have a basic understand on the working of the perpetual contracts. Comment down if you have any questions. Thank you

Welcome to another day of exploring Web3 Engineering. It’s been a long time that Ethereum shifted from Proof-of-Work (PoW) to Proof-of-Stake (PoS) which has reduced the costs to become to run a node significantly as it now doesn’t require heavy hardware. Let’s explore this new procedure that provided this level of optimization to the network. So, without a further ado, let’s get started.

Post Merge Architecture

Before the merge, the entire codebase is split into Consensus and Execution layers. And when we want to run an Ethereum node, we need to run both of them.

Consensus Layer

The consensus layer is responsible for dealing with the consensus mechanism of the network, block producing, attestation, staking, node discovery, validator management etc. This layer has it’s own state called Beacon State which keeps the latest state of the node.

Execution Layer

The execution layer contains the Ethereum Virtual Machine (EVM), mempool management, transaction execution, Accounts management and contract management. All the smart contracts deployed on the network are stored in this layer and this layer is responsible for handling most of the RPC endpoints such as eth_getBalance, eth_call etc.

How does the consensus Work

Gasper is the consensus protocol used by Ethereum's Beacon Chain and post-merge mainnet. It is the combination of LMD-GHOST fork choice rule and Casper FFG finality gadget. This hybrid design is responsible for fast block production and finalization in a Proof-of-Stake system.

A fork choice rule is a set of instructions that blockchain nodes use to determine the "best" or canonical chain when there are multiple block heads available. In simple terms, rules to decide which one is the latest block when we have multiple options.

Finality refers to the point at which the transaction made can not be revoked.

Time in Ethereum PoS

• In Ethereum consensus, the timeline is divided into equal time intervals called Slots. Each slot at the moment is equal to 12 seconds right from the Genesis block and are numbered sequentially.

• Each slot should produce a maximum of 1 block and there are chances that slots will be empty without producing a block for various reasons such as no mempool transactions available, block syncing, gossip delay etc.

• There is also another notation called Epoch. 1 Epoch = 32 slots (32 × 12s). These Epochs are used to finalize the state.

Consensus Process

• Whenever a new epoch begins, a set of validators are picked up to produce the blocks in it. And for this set, these validators are all responsible for all the things in this epoch.

• And once, the epoch begins, in each slot, a random validator is picked up to produce the block.

• Once a slot begins, the validator who is selected for the producing the block (producer), validator client will makes necessary API calls to the Execution layer and creates a new block.

• Once the block generation is done, it will be forecasted via libp2p gossip pub to the network.

• Once the new block is received at the 4th second of the slot, the remaining validators (attestors) will verify the block and attests to it.

• These checks include

  • Whether the block follows the schema or not

  • Whether the previous block hash matches with their own block head or not

  • Presence of any faulty transactions

  • Blobs validations etc.,

• If all the details matches, then they emit an attestation to the network as below

{
  "aggregation_bits": "0x03",  // 2 validators aggregated (00000011)
  "data": {
    "slot": 123456,
    "index": 7,
    "beacon_block_root": "0xabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcdeabcd",
    "source": {
      "epoch": 3857,
      "root": "0x1234512345123451234512345123451234512345123451234512345123451234"
    },
    "target": {
      "epoch": 3858,
      "root": "0x5678956789567895678956789567895678956789567895678956789567895678"
    }
  },
  "signature": "0xb1aa1d5c456789abcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdefabcdef"
}

• If the new block is not received then they provide attestation to their current local head only which then creates multiple forks in the local chain.

• During this process, there’s an another actor that is selected from the validator set and is called Aggregator.

• This aggregator will collect all the attestation from the validators and then announces the new blockhead that receives the most number of attestations.

• Once all the attestations are received, the aggregator will publish the aggregated result. Then validator (producer / attestor) will update their local view of the chain with the block. And the slot ends.

• While adding the block, if the local network contains multiple fork choices, then the validator uses LMD-GHOST protocol to select the fork to which it can add the new block. And also we receive the start and end epochs as part of the attestation which are used by Casper FFG.

• Once the 32 slots are completed, then the Casper FFG protocol comes into play to finalize the epoch. If two consecutive checkpoints receive votes from at least two-thirds (≥66%) of validators, the earlier checkpoint is finalized. Any conflicting forks built on top of epochs earlier than the finalized one are considered invalid.Typically any block after 2 epochs is considered as finalized which is 12.8 seconds for better security.

Here is a second wise breakdown of the steps followed during a slot.

That’s all for this blog. As part of this series, we will keep digging deep into the consensus layer and the protocol stack used. Thank you

Welcome to another day of exploring Web3 Engineering. Since we are diving deep into the Ethereum protocol in our series, today let us understanding the type of transactions that we can make on the network and which is better for what and when. So, without any further ado, let’s get started.

Transaction

In the context of the blockchain world, a transaction is the fundamental cause of change in the state of the network which means a transaction is supposed to update the blockchain from one state to another like a finite machine.

As we all know, a group of transactions are picked up to form a block with the latest state, and this block is added to progress the network. And the miners get rewarded for executing the user’s transactions.

Types of Transactions

If this sounds all simple, why bother having differ types of transactions ? Actually what type of transactions that users can make on the Ethereum blockchain ?

The main goal of having different types of transactions is obviously to save Gas.

Ethereum so far, have introduced 5 different types of transactions which have different kinds of estimations to save users gas fee and to make the network more approachable.

1. Type 0 (Legacy)

   • It is the primary transaction type that Ethereum introduced to calculate the gas fee for a transaction.

   • The transaction schema is as follows

   •     {
           "from": "0x...",              // Sender's address
           "to": "0x...",                // Recipient's address (optional for contract creation)
           "gas": "0x...",               // Gas limit
           "gasPrice": "0x...",          // Gas price per unit (in wei)
           "value": "0x...",             // Amount of Ether to send (in wei)
           "data": "0x...",              // Input data (for contract interaction or deployment)
           "nonce": "0x..."              // Number of transactions sent from the sender's address
         }
     

2. Type 1 (EIP 2930) - Access list Transaction

   • Type 1 transactions are introduced with EIP 2930 in the Belin upgrade which introduced a new parameter to the request object called access_list.

   • This access_list contains the list of addresses and the storage keys of the data that the transaction is going to interact with, so that the EVM can prefetch them into the execution memory which reduces the gas costs while executing the transactions.

   • These access list is introduced warm and cold memory. Warm data is the part of the state tree which is already brought into the execution environment for the transaction while on the other hand the cold data is yet to brought into the execution space. Warm data read/write takes 100 gas while the cold storage (or first time retrieval) takes 1900 gas. With this, he access_list helps to reduce gas costs on complex transaction which uses same memory multiple times.

   • The transaction object of the EIP 2930 transaction looks like below:

       {
         "type": "0x1",                      // Explicitly specify type 0x1 (optional in some clients)
         "from": "0x...",                    // Sender address
         "to": "0x...",                      // Recipient (null for contract creation)
         "gas": "0x...",                     // Gas limit
         "gasPrice": "0x...",               // Price per unit of gas (same as legacy, no base/priority fee here)
         "value": "0x...",                   // Value to send in wei
         "data": "0x...",                    // Input data
         "nonce": "0x...",                   // Sender's nonce
         "chainId": "0x1",                   // Chain ID for replay protection
         "accessList": [                     // New in EIP-2930
           {
             "address": "0x...",            // Address being accessed
             "storageKeys": [              // Array of storage slot keys (as hex strings)
               "0x...",
               ...
             ]
           },
           ...
         ]
       }
     

3. Type 2 (EIP 1559) - Dynamic Fee Transaction

   • In the London hard, a new gas calculation scheme has been introduced that has 2 new attributes called base fee and priority fee. Base fee is the amount of the gas that we are willing to pay for the actual execution and then the priority fee is the amount we are willing pay to prioritize our execution. Higher the priority fee, faster the transaction gets executed.

   • The transaction object for the Type 2 transaction looks like below

       {
         "from": "0x...",                   // Sender address (required)
         "to": "0x...",                     // Recipient address (optional for contract creation)
         "value": "0x...",                  // Amount of ETH to send (in wei, hex)
         "gas": "0x...",                    // Gas limit (in hex)
         "maxPriorityFeePerGas": "0x...",  // Tip to the miner (in wei)
         "maxFeePerGas": "0x...",          // Max total fee (tip + baseFee, in wei)
         "nonce": "0x...",                 // Transaction count of the sender
         "data": "0x...",                  // Optional input data
         "accessList": []                  // Optional EIP-2930 access list
       }
     

   • We can notice that there are two new parameters called maxPriorityFeePerGas which is the maximum gas fee we are willing to pay as priority and maxFeePerGas is the amount of gas we are willing to pay for execution.

   • And it also contains access list for the backward compatibility.

4. Type 3 (EIP 4844) - Blob Transactions

   • In the Dencun upgrade of the Ethereum blockchain, a new type of storage system is introduced to the network to store data as BLOBS. And to upload these blobs, a new transaction type is also introduced. Even though a regular day to day user won’t be using this, it is used by projects that need to store huge amounts of data onchain like layer 2 networks which provides big amounts of storage in cheaper prices.

   • The transaction object for the blob transaction is as follows:

   •   {
         "type": "0x3",
         "chainId": "0x1",                          // Mainnet (hex)
         "nonce": "0x0",                            // Sender's transaction count
         "maxPriorityFeePerGas": "0x59682f00",      // Tip to the validator
         "maxFeePerGas": "0x59682f080",            // Max total fee
         "to": "0x3535353535353535353535353535353535353535",  // Recipient
         "value": "0x0",                            // ETH to send (in wei)
         "data": "0x",                              // EVM calldata
         "accessList": [],                          // Optional (usually empty)
         "maxFeePerBlobGas": "0x1e8480",            // Maximum blob gas fee (new)
         "blobVersionedHashes": [                   // References to blobs (KZG commitments)
           "0x010203...32-bytes"
         ]
       }
     

   • There are 2 new fields in the object. they are maxFeePerBlobGas and blobVersionedHashes. The versioned hashes contains the KZG commitment hashes of the blobs included in the transaction. And the maxFeePerBlockGas contains the maximum block gas can be spent for storing the blobs.

   • It is also backward compatible with EIP 1559 and EIP 2930.

5. Type 4 (EIP 7702) - Set Code Transactions

   • The Pectra upgrade has brought a new type of transactions called Set Code transactions that are used to temporarily / persistently provide smart contract behavior to a EOA address.

   • This is on testing phase right now and on Hoodi testnet of the Ethereum network. It contains a new attribute called authorizationList which contains the smart contract address that we want our EOA to mimic.

   •   {
         "type": "0x04",
         "chainId": "0x1",
         "nonce": "0x0",
         "maxPriorityFeePerGas": "0x59682f00",
         "maxFeePerGas": "0x59682f080",
         "gas": "0x5208",
         "to": "0xRecipientAddress",
         "value": "0x0",
         "data": "0x",
         "accessList": [],
         "authorizationList": [
           {
             "contractCode": "0x6001600101...",
             "yParity": "0x0",
             "r": "0x...",
             "s": "0x..."
           }
         ]
       }
     

   • As we can that the EIP 7702 transaction is backward compatible with EIP 1559 transaction

There is always a possible for transaction types to emerge in the Ethereum ecosystem to optimize the transaction execution and save gas costs.

Please comment down if you have questions.

That’s all for this article. Thank you

Welcome to another day in exploring Web3 Engineering. In today’s article, rather than focusing on dApps and ERC standards, lets focus on the node that runs our beloved Ethereum network. Let’s start with the layered architecture and different communication protocols of the Ethereum node. So without any further ado, let’s get started.

Ethereum Clients

Before the Ethereum merge and shift to Proof-of-Stake consensus, it followed monolithic architecture. Which means the entire codebase is responsible for all the features and all the components are tightly coupled with each other. After the merge, the node is divided into layers and each other is loosely coupled and it made language agnostic to support various clients written in different programming languages.

Layers of Clients

The Eth node is divided into 2 layers. Each state consists their own peer-to-peer network for their execution and also maintain a separate state depending on their needs.

1. Execution Layer (EL)

2. Consensus Layer (CL)

Execution Layer

• The EL is responsible for executing all the transactions, providing the RPC methods, communication with the dApps, smart contract etc.

• The p2p network in the EL is responsible for validating the transactions and producing the new block.

• The client RPC calls made to the node are executed here, providing the read and write calls of the Ethereum state.

• Management of the Mempooletc.

• The architecture of the EL depends on it’s individual implementation.

Consensus Layer (CL)

• The CL is responsible for maintaining the overall consensus of the blockchain network.

• Management of the Validator nodes, slashing, staking and other validator based actions

• Block production and proposal of new block producers

• Block attestation and finality etc.,

Key Protocols

Ethereum node uses multiple communication protocols to maintain the decentralization and censorship resistance in the network along with the unrestricted rules for the node operators to join and leave the network whenever possible. For example

1. Gossip Protocol - Gossip protocol is used in both the consensus and execution layers for syncing the state between the nodes in the network.

2. LibP2P (Networking Protocol) - is used in the consensus layer for discovering the node discovery and the peer-to-peer communication between the network.

3. DevP2P (Ethereum Wire Protocol) - is used in the execution layer for the peer-to-peer communication in order to maintain the state sync, block propagation and transaction gossiping between the network.

Apart from the communication protocols, Ethereum also uses various data serializations and cryptographic algorithms which we will discuss in our upcoming articles.

That’s all for the day. Comment down your questions

Welcome to another day of exploring Web3 Engineering. With blockchain taking new steps towards the decentralized finance (DeFi) and blooming with a new token standard or extension everyday, today we have come across a new one called Minimal Multi-token standard interface. With Uniswap V4 using it in their new contracts, the significance of understanding it has increased. So, without any further ado, let’s get started.

What is ERC 6909 ?

ERC 6909, in simple terms, is an improvement to the already popular ERC1155: Multi-token standard. By decreasing the overhead of ERC1155 implementation and some modifications to the features, the applications of using Multi-token standard have increased. First let us recall the original ERC1155 token standard and then let us compare the differences between.

ERC1155: Multi-token standard

Here we have the interface for the ERC1155 token standard.

interface ERC1155 /* is ERC165 */ {
    event TransferSingle(address indexed _operator, address indexed _from, address indexed _to, uint256 _id, uint256 _value);
    event TransferBatch(address indexed _operator, address indexed _from, address indexed _to, uint256[] _ids, uint256[] _values);
    event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);
    event URI(string _value, uint256 indexed _id);
    function safeTransferFrom(address _from, address _to, uint256 _id, uint256 _value, bytes calldata _data) external;
    function safeBatchTransferFrom(address _from, address _to, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external;
    function balanceOf(address _owner, uint256 _id) external view returns (uint256);
    function balanceOfBatch(address[] calldata _owners, uint256[] calldata _ids) external view returns (uint256[] memory);
    function setApprovalForAll(address _operator, bool _approved) external;
    function isApprovedForAll(address _owner, address _operator) external view returns (bool);
}

Here is the interface for the ERC1155Receiver contract.

interface ERC1155TokenReceiver {
    function onERC1155Received(address _operator, address _from, uint256 _id, uint256 _value, bytes calldata _data) external returns(bytes4);
    function onERC1155BatchReceived(address _operator, address _from, uint256[] calldata _ids, uint256[] calldata _values, bytes calldata _data) external returns(bytes4);       
}

Functionalities

ERC1155

• safeTransferFrom - To transfer tokens from one user to another user of the given token id.

  • If the function is called by a user to transfer owned tokens, enough balance is expected

  • If the function is called by a third party account to transfer our tokens, the operator must be approved prior to the call.

  • If the receiver of the tokens is a contract, onERC1155Received will be called on the receiver contract

• safeBatchTransfer - same as a safeTokenTransfer, but can transfer multiple tokens in a single transaction.

  • The caller needs to specify the array of token ids to transfer

  • Same as safeTransferFrom, if the function is called by an operator, the prior approval is necessary.

  • If the receiver of the tokens is a contract, onERC1155BatchReceived will be called on the receiver contract

• balanceOf - to check the balance of the given user for the given token id.

• balanceOfBatch - to check the balance of users for the array of given token Ids.

• setApprovalForAll - to grant operator approval for a given user. It sets approval for unlimited balance of the user on all the token Ids.

ERC1155Receiver

• onERC1155Received - A custom hook function that must be implemented by the receiver contract that gets triggered after transferring the tokens using safeTransfer on ERC1155 and it should return bytes4(keccak256("onERC1155Received(address,address,uint256,uint256,bytes)")) signaling the successful transfer of the tokens.

• onERC1155BatchReceived - A custom hook function that must be implemented by the receiver contract that gets triggered after transferring the tokens using safeBatchTransfer on ERC1155 and it should return bytes4(keccak256("onERC1155BatchReceived(address,address,uint256[],uint256[],bytes)")) signaling the successful batch transfer of the tokens.

Issues with ERC 1155

• If we look closely, there is no standard transfer and transferFrom functionalities in the standard. and there are only safe transfer functions. Even though they are safe, they add an unnecessary overhead on the token transfer increasing the gas fees.

• There is only one global operator approval for all the tokens of a given user which is limiting in some situations where a user needs to specify either multiple operators for a given token or a separate operator for each token Id.

ERC6909 addresses these issues by removing the transfer checks (splitting them to extensions) on the transfer and introducing multiple operators for a given user. Have a look at the ERC6909 interface below.

interface ERC6909 {
    error InsufficientBalance(address owner, uint256 id);
    error InsufficientPermission(address spender, uint256 id);

    event Transfer(address caller, address indexed sender, address indexed receiver, uint256 indexed id, uint256 amount);
    event OperatorSet(address indexed owner, address indexed spender, bool approved);
    event Approval(address indexed owner, address indexed spender, uint256 indexed id, uint256 amount);

    mapping(address owner => mapping(uint256 id => uint256 amount)) public balanceOf;
    mapping(address owner => mapping(address spender => mapping(uint256 id => uint256 amount))) public allowance;
    mapping(address owner => mapping(address spender => bool)) public isOperator;

    function transfer(address receiver, uint256 id, uint256 amount) public returns (bool);
    function transferFrom(address sender, address receiver, uint256 id, uint256 amount) public returns (bool);
    function approve(address spender, uint256 id, uint256 amount) public returns (bool);
    function setOperator(address spender, bool approved) public returns (bool);
    function supportsInterface(bytes4 interfaceId) public pure returns (bool supported);

    // ============= internal ===================
    function _mint(address receiver, uint256 id, uint256 amount) internal;
    function _burn(address sender, uint256 id, uint256 amount) internal;
}

The ERC6909 introduces a new role called Operators that are specific to a user. Each user can set multiple operators for their tokens and the operators have approval to the unlimited balance of the user on all of the token Ids.

Functionalities

• approve - To grant approval for a spender for a given amount of tokens of give token Id.

• transfer - To transfer given amount of tokens of the given token id to the receiver. Should be called to transfer owned tokens.

• transferFrom - To transfer given amount of tokens of the given token id from the sender to the receiver. Should be called to transfer third party (sender) tokens and also a prior approval is needed on the amount of the token Id tokens. If it is called by an operator, no approval call is needed, since they already have approval to all of the balance of them.

• setOperator - To set or reset an operator for a the caller. Once the operator role is granted, operator would have access to all of their funds.

With these additions, ERC6909 have overcome the inefficiencies that ERC1155 is lacking. And with these new features, ERC6909 plays a crucial role in the Uniswap V4, which we will explore in our upcoming blogs.

That’s all for the day. Feel free to comment down your questions.

Welcome to another day of exploring Web3 Engineering.

In our cyrpto / blockchain world, we have definitely came across various different kinds of tokens. Some talk about stable coins, some keep hyping about the meme coins, and some hold governance tokens. Being a blockchain / crypto enthusiast, one must understand the differences between these, no matter whether they are from a technical background, financial background or simply just exploring. So, in today’s blog let us debunk these token types and understand what and where are they used.

Classification of Tokens

Technical Classification

There are basically 3 types of tokens when we classify them on the technical front

1. Fungible Tokens - Fungible tokens are interchangeable among them without losing value. Which means just the real world money, no matter which Rs. 100 /- we have, we can exchange it with another Rs. 100/- note without losing any value since each token worth the same value.

2. Non - Fungible Tokens - NFTs are the tokens that are not interchangeable without losing value. Which means just the art collections, even though all the paintings are from the same artist, no two paintings are same and they may or may not worth same value.

3. Semi - Fungible Tokens - Semi Fungible tokens combines both the properties of Fungible and NFTs. They operate fungible with some conditions and NFTs otherwise. We can understand them as gaming assets. Even though all weapons are from the same game, weapons are of different kind and also there is one copy of each weapon per user.

Use case classification

Based on the use case and requirements, one of the above 3 kinds of tokens can be used to implement them. There are various types of tokens / coins available in the market. Here are some of the popular or must know types

1. Native Tokens - Native tokens are the tokens that are used to pay for the gas to make transactions on the given network. They can be only be created when the blockchain network is started and there is only one native token per network mostly and they are fungible in nature.

   • Example: Ethereum (ETH), Bitcoin (BTC), Sui(SUI) etc.

2. Wrapped Tokens - These are the tokens that are developed as a wrapper for another token to provide additional functionality for the original tokens. These are always mined and burned on demand by depositing and withdrawing the original token from into the wrapped token smart contract.

   • Example: Wrapped Ethereum (WETH), Wrapped Bitcoin (WBTC) are tokens developed to add ERC20 functionality for the native tokens.

3. Stable Coins - Stable coins are usually fungible tokens that are pegged to a real world asset to maintain stability in the exchange price of the token.

   • Example: USDC and EURC are stable coins launched by Circle.com which are pegged to US Dollar and European EURO respectively.

4. Governance Tokens - Governance tokens are used to represent the voting power of user in the election (decision making) process of a Decentralized Autonomous Organization (DAO). The token holders will be able to propose, vote and accept or reject changes that for the ecosystem and the voting power is decided of the user is decided by the quality / quantity of the tokens held by them.

   • Example: Uniswap (UNI) Token is the governance token for the Uniswap protocol.

5. Meme Coins - These are the tokens that are used to represent a trending meme or inspired from a famous internet meme. They often start as side projects but gain significant popularity and value due to social media trends, community-driven hype, and celebrity endorsements. They typically don’t have any goal or road map to them.

   • Example: Dogecoin, Shiba Inu are one of the popular memecoins in the crypto market.

6. RWA Tokens - Real World Asset Tokens or RWA Tokens are used to represent real world entities (typically real estate). The token holders are considered as the owners of the assets and price is derived based on the real world assets.

   • Example: Centrifuge tokenises various real-world assets, including business invoices and carbon credits, allowing these assets to be used as collateral in DeFi lending pools.

There are more to this classification such as utility tokens, tax tokens, AI agents etc. Day by day, we are able to observe more and more use cases are being discovered to adopt blockchain into our day to day life and the emerging opportunities are increasing the efficiency and the ease-fullness for the organizations to operate.

What are the other use cases do you think that the emerging blockchain world can offer ? Comment down below.

That’s all for the day. Feel free to comment down your questions.

Welcome to another day of exploring Web3 Engineering. Let’s dig into basics of the blockchain today and understand it’s anatomy in general. In this blog, we’ll dive into nodes and its types and their responsibilities and use cases. So, without any further ado, let’s get started.

What’s a blockchain node ?

A blockchain node is the vital component of the network that acts as the communication endpoint for the network. The nodes are responsible for maintaining the network’s decentralization and security. These are responsible for performing various tasks such as transaction validation, state broadcasting, data storage etc.,

Key responsibilities

1. Transaction Validation: Nodes are responsible for validating transactions such as message formatting, gas payments (if needed), data validation etc. They ensure the incoming transactions follows the rules specified by the blockchain.

2. Block Verification: Nodes perform validations on the new blocks that are added to the network. They also ensure the consensus conformity of the new block.

3. Data Storage: Depending on the network of the node, they store the blockchain data. If it is a full node, it is responsible to store the entire blockchain, and if it is a light node, it will store the latest copy of the blockchain state.

4. Network Security: Nodes ensure the blockchain integrity by maintaining a distributed ledger across the network to cross verify the state.

Type of nodes

Depending on the blockchain network, there are different kinds of nodes available. But in general, there are 4 different kinds of blockchain nodes available. They are:

• Full node: A full node contains the entire blockchain data and can validate an incoming transaction independently since it contains the entire blockchain data. To run a full node, the storage requirements are usually quite high.

• Light node: A light node only store a part of the blockchain data, usually the latest state. They rely on the full nodes for transaction validation.

• Archive node: An archive node stores the historic data of the blockchain and doesn’t actively participate in the transaction validation.

• Validator node: A validator node participates in the consensus algorithm of the blockchain such Proof-of-Stake , Proof-of-Work etc,.

Depending on the blockchain network and/or consensus algorithm, there are some network specific nodes as well. Some of them are:

Bitcoin

• Miner node: A miner node is a full node which is also responsible for adding new blocks to the network. They participate in the Proof-of-Work (PoW) to solve the complex puzzles in order to generate new blocks.

Ethereum

• Full node: An Ethereum full node is not only responsible for storing entire blockchain and also responsible for transaction mining and new block generation. A full node after elected by the PoS election adds the newly generated block to the network.

• Validator node: A validator is added in Ethereum 2.0 update where they are responsible for transaction confirmations, block validations and also staking rewards exchange.

Polkadot

• Validator node: Polkadot utilizes a hybrid consensus algorithm which includes Nominated Proof-of-Stake (NPoS) for relay chain. Validator nodes are responsible for Relay Chains block validation and consensus process.

• Collator node: Collator nodes are the block producers for the parachains of the network. Parachain is an individual chain connected to the Main chain (or Relay chain) of the network. They play a critical role in maintaining the scalability of the system.

Tezos

• Baker node: In tezos network, the baker nodes are responsible for network consensus and block creation. These nodes play a key role in maintaining the Liquid Proof-of-Stake (LPoS) consensus over the network.

Depending on the consensus protocol, we can observe full nodes with more responsibilities or new type of nodes with different responsibilities.

That’s all for the day. Feel free to comment down your questions.

Welcome to another day of exploring Web3 Engineering.

We have been talking about blockchain and developing smart contracts on them for a while and also writing scripts on how to interact with the blockchain for a while. But have you ever wondered on how actually your script communicates with the blockchain ?? Of course it uses RPC .. Duh..!! But what is this RPC ? How is it different from other communication protocols ? Where it is used ? So without any further ado, let’s get answers to these questions.

Remote Procedure Call aka RPC protocol

Remote Procedure Call (RPC) protocol is a communication protocol that allows a service (or an entity) to invoke a certain procedure on a remote service as if it is a local procedure.

In common language, it is a protocol that allows you to call a function on a different server as a local function in the code. For example, we are calling eth_getBalance function in our local javascript file as a local function but it is implemented on the blockchain node provided by our RPC provider.

Structure of RPC method

An rpc request contains 4 parameters. The version of the rpc, method name to be called, params if any, and finally a request identifier id. The structure looks as follows

{
  "jsonrpc": "2.0",
  "method": "getBlock",
  "params": [1234],
  "id": 1
}

We can also add any metadata if needed for our procedure.

How is it different from Other

Other communication protocols like REST-API follows resource based design and uses URLs to provide different functionalities. Whereas, the RPC is designed around the procedures rather than resources.

For example, if we want to get all the users using REST - API, the code looks like this

const url = 'https://example.com/users/getUsers';
try {
    const response = await fetch(url, {
    method: 'GET', // RESTful GET request
    headers: {
        'Content-Type': 'application/json',
    },
});
if (!response.ok) {
    throw new Error(`Error: ${response.statusText}`);
}
const data = await response.json();

But if we want to implement the same thing using RPC methods, it would like this

const url = 'https://example.com/rpc'; // The endpoint for RPC requests
const rpcRequest = {
    jsonrpc: '2.0',
    method: 'getUsers', // The remote procedure call method
    params: [], // Parameters required for the method (empty in this case)
    id: 1, // Request ID
};
try {
    const response = await fetch(url, {
    method: 'POST', // POST request for RPC
    headers: {
        'Content-Type': 'application/json',
    },
    body: JSON.stringify(rpcRequest), // Sending the request body
});
const data = await response.json();

Where it is used

RPC is mainly used for communication between micro services and distributed systems. It is also used in systems where a real time communication is needed such as IoT, blockchain and smart contracts, online multiplayer games etc.

What are the popular implementations of RPC:

Due to its flexible architecture and compatibility with different formats, RPC is implemented to support various data formats. Such as

• gRPC - The gRPC is developed by Google where RPC is implemented to transport binary data for communication between entities which is mainly used in cloud-native applications

• JSON-RPC : The JSON-RPC format transport data using JSON format widely used in blockchain communication

• XML-RPC: The XML data formatted RPC calls are used in older system where XML format is used data exchange.

• SOAP: While more of a web service protocol, SOAP can be considered an RPC mechanism, as it invokes remote operations with an XML-based request and response.

Along with the data format used, we can also use RPC with different transfer protocols such as https, web sockets etc

That’s all for today.
Feel free to comment down your questions and don’t forget to subscribe to the newsletter.

Welcome to another day of exploring Web3 Engineering. Today let’s see why we need the blockchain interoperability and where the future of the decentralized applications (dApps) head. So without any further ado, let’s get started.

Introduction:

Now-a-days with the fast growing of DeFi usage and the applications offered by them, it is safe to assume that blockchain has become a critical component in the progress. As we have different blockchains emerging day by day offering their own specialties to both developers and users, it has become difficult to stick to one platform for all their uses or switch different platforms for usability.

For example, I can’t use the stable coins I have on one Network A to stake on a dApp on Network B that is offering me more APY. This is just one of the scenarios where users are facing difficulties using their assets to full extent.

Cross-chain solutions aim to address these challenges by enabling seamless communication and interaction between different blockchain networks.

Why Interoperability Matters in Blockchain

Like in the above example, Currently, many DeFi applications exist in isolated ecosystems, each with its own unique protocols, assets, and consensus mechanisms. With the lack of interoperability, users are unable to use their assets across different blockchains and are forced to use centralized exchanges taking away the core decentralization aspect of the Decentralized Apps.

What does Interoperability provide ?

Interoperability in blockchain allows for:

• Better Liquidity: Cross-chain bridges allows the liquidity to flow between different blockchains, preventing it to be stuck on one network.

• Enhanced User Experience: With cross-chain dApps, users can interact with applications from different blockchain under one common interface with switching between multiple wallets or platforms.

• Innovation in DeFi Protocols: Multi-chain applications can integrate new features such as cross-chain lending, yield farming, and decentralized exchanges (DEXs) that pool liquidity from different blockchains.

Popular Cross-Chain Solutions:

1. Cosmos IBC (Inter-Blockchain Communication):

   • Cosmos is commonly called as Internet-of-blockchains.

   • IBC protocol allows transfer of assets and data between different blockchain such as Ethereum, Solana etc.

   • It uses Hubs and Zones to provide communication between networks without needing a centralized exchange or third party apps.

2. Polkadot Parachains:

   • Polkadot is another popular cross-chain communication protocol which provides communication using Parachains.

   • Parachains are independent and specialized blockchains that run in parallel while being connected to the central Relay Chain.

   • These parachains communicate wiht each other using Cross-Chain Message Passing (XCMP) through the Polkadot Relay chain to transfer assets and data between them.

3. Axelar Network:

   • Axelar network provides cross-chain communication with the help of interoperable smart contracts.

   • It is right now compatible with Ethereum, Avalanche, Cosmos, and other major ecosystems.

4. Chainlink CCIP (Cross-Chain Interoperability Protocol):

   • Chainlink’s CCIP is designed to create a universal standard for sending data, messages, and tokens across blockchains.

   • With the integration of chainlink oracles, CCP is ideal for DeFi protocols and security essential applications

Challenges in Blockchain Interoperability:

On one hand, we have so many pros by using the cross-chain communication, but on the other hand we have some cons too. They are

• Security Risks : Bridging dApps between multiple chains will bring in potential risks like the chance of malicious actors exploiting the weaknesses on the communication protocol is high.

• Consensus Differences : As different blockchains work with different consensus algorithms, bad actors can take advantages in the differentiating block rates or synchronization etc.

• Liquidity Fragmentation: Even with interoperability, liquidity can become fragmented across chains, making it harder to aggregate liquidity pools effectively.

The Future of Cross-Chain DeFi:

Interoperability protocols are set to play a key role in the next phase of DeFi’s growth. As protocols like Cosmos IBC, Axelar, and Chainlink CCIP continue to evolve, developers will be able to create more composable dApps that work across multiple chains. In the near future, we can expect to see:

• Cross-Chain Yield Farming: Where users can stake assets on one blockchain and earn rewards on another.

• Interoperable Lending Protocols: Enabling users to borrow assets from one blockchain and lend them on another, using a cross-chain collateral model.

• Cross-Chain DEXs (Decentralized Exchanges): These exchanges can pool liquidity from multiple blockchains, providing better rates and more efficient trades.

So, what is your opinion on this?

How are you planning to use them in your dApps? Comment below.

Welcome to another day in exploring Web3 Engineering. Today, we are going to look into an EVM based options trading platform on the Arbitrum One network. So, without further ado, let’s get started.

What is Ithaca Protocol

Ithaca protocol is an auction based option trading platform on Arbitrum One. It is both decentralized and non-custodial and also performs off-chain order matching for providing options trading on EVM networks - Ethereum, Base, Polygon, Arbitrum One and Optimism. Ithaca uses auction based order matching to execute the user trades.

Auction Based Order Matching

Auction-based order matching is a way to buy and sell things (like stocks or cryptocurrencies) where buyers and sellers make their offers at the same time. Instead of just taking the first order that comes in, everyone gets a chance to compete for the best price.

In Ithaca, an auction is conducted for every 4 minutes and users are allowed to place traders in this time. Once the auction ends, the trade price is determined on which maximum number of order matching takes place by the trades received.

Technical Architecture:

1. Off-Chain Pre-Match Processing: Ithaca has a matching engine that runs off-chain, powered by auction-based mechanisms to determine the optimal liquidity provision and execute them.

2. On-Chain Post-Match Settlement: Once the trades are matched, the settlement takes place on-chain with smart contracts. Ithaca’s Collateral Optimization Engine is a crucial part of this phase, managing risk-sharing mechanisms and collateral.

3. Axelar Bridging - Ithaca provides cross-chain capabilities with cross-chain gateway protocol from Axelar bridge which provides bridging between multiple blockchains into Arbitrum network.

Orders

In Ithaca, traders are required to place only limit orders. Auction order matching doesn’t support market orders. User can either can place a basic order or a multi-leg condition order.

All the orders that are placed will stay in the order until it is cancelled or expired.

Auction Procedure

Frequent Batch Auctions (FBA)

As I said earlier, Ithaca conducts an auction for every 4 minutes. It is called Frequent Batch Auction. The orders that are matched at discrete times and are followed by the next FBA cycle continuously.

As we can see, there are 2 phases for an auction. They are:

1. Order Submission Period

   • During this period, users are allowed to place new orders or cancel their existing orders. But during this phase, no order matching takes place and match price is also not generated.

   • Each order submission period starts immediately after another and finishes when the Matching Period starts for that auction.

2. Matching Period

   • Matching period starts right after the submission period ends.

   • During this phase, the matching engine comes into play to match all kinds of orders.

   • Once the matching process completes, the engine determines a single price for the call and put options for the next cycle.

   • Any orders placed during the matching phase with price below than the estimated single price for the options are placed into a temporary queue to include in the next order submission phase.

Settlement

Automatic Settlement

By default, all contracts are auto-exercised at maturity if and only if the contract has enough and eligible intrinsic value. They can’t be exercised early.

Everything is ‘cash settled’ which means that no party involved in the transaction has to pay any extra funds at the time of settlement. The settlement payouts to the contract holders is done using the locked up collateral amounts.

Settlement Currency

Since ithaca uses collateral optimization, the currency that can be locked up as collateral is either USDC or the underlying asset. So that by using this collateral amount, settlement payout will be done in either of them. Ithaca also provides the ability for the users to chose the settlement currency.

For more detailed information, you can explore their official documentation.

Welcome to another day of exploring Web3 Engineering. So long we have discussed on many talk topics and some of them are quite advanced as well. Today, let us get our fundamentals right and get a hold on what scalability solutions are available for blockchain networks and why do we need them. So, without any further ado, let’s get started.

What Are Layer 2 Solutions?

Layer 2 solutions are designed to enhance the scalability of Layer 1 blockchains like Ethereum, Bitcoin etc which are slower by nature, by processing transactions off the main blockchain. While a Layer 1 blockchain takes the responsibility of security and decentralization, Layer 2 handles transaction throughput, making blockchains more efficient without compromising on security.

There are 3 prominent approaches to implement the layer 2 in the market at the moment. They are

• Rollups

• State channels

• Side chains or Plasma chains

Do we really need these ?

As we can see that networks like bitcoin and Ethereum are growing day by day, issues with increased gas fees and finality time keeps increasing. Layer 2 solutions help networks to mitigate these issues, providing users with cheaper gas rates and faster finality while maintaining the underneath blockchain’s security and decentralization.

Let us dig a deeper into these. Shall we

Rollups:

Blockchain rollups are a scalability solution that processes and bundles several transactions off-chain before submitting them to the main blockchain, reducing congestion on blockchain networks.

Based on the technology that these rollups use to bundle the transactions, they are classified. Currently there are 2 approaches being followed by the market which delivered promised results. They are:

1. zk or zero-knowledge rollups

2. Optimistic Rollups

zk-Rollups

zk-Rollups bundle multiple transactions off-chain and submit a single proof to the ethereum mainnet. This ensures validity of the data on layer 2 without a need to expose entire transaction details to the layer 1. The "zero-knowledge" aspect allows for high security while significantly reducing data on Layer - 1. zk-Rollups allow for more efficient contract interactions by reducing gas fees and improving transaction speeds. Developers building dApps or DeFi products are increasingly implementing zk-Rollups to offer users a faster and more secure experience.

zkSync, zkEVM are the most popular implementations of zk-rollups

Optimistic Rollups

Optimistic Rollups also bundle transactions off-chain but assume all transactions are valid unless proven otherwise via a fraud-proof system. This means that disputes are settled by submitting fraud proofs to the Ethereum mainnet. Optimistic Rollups are simpler and cheaper to implement compared to zk-Rollups, making them ideal for applications that can tolerate occasional delays for security checks.

Arbitrum and Optimism are popular examples of optimistic rollup solutions.

State Channels

State channels allow participants to open a private channel off-chain and conduct multiple transactions directly between themselves, only recording the final state on-chain. This reduces the number of transactions processed on the main blockchain. State channels work well for use cases that require frequent, low-value transactions, such as micro-payments or gaming applications.

Raiden Network, Connext(now Everclear) are popular implementations of state channels on Ethereum network.

Sidechains

Sidechains operate as independent blockchains running in parallel to Ethereum or other Layer 1 blockchains. While sidechains handle transactions off-chain (layer 1), they periodically settle batches of transactions on Layer 1 to ensure security.

Polygon is a leading example of a sidechain solution that integrates well with Ethereum. Developers can build dApps on Polygon to take advantage of low fees and faster transactions, while still interacting with the Ethereum mainnet for finality.

Security Considerations for Layer 2

Layer 2 solutions inherit security from Layer 1 but come with some trade-offs. For example:

• zk-Rollups: Offer stronger security guarantees as they submit validity proofs to Ethereum, ensuring that the transactions bundled off-chain are valid.

• Optimistic Rollups: Rely on fraud proofs, which means there’s a potential delay if a fraudulent transaction is challenged, but they are more efficient due to fewer on-chain checks.

• State Channels & Sidechains: Provide enhanced speed and lower costs but may have weaker security models, as they rely on third-party validators or different consensus mechanisms.

How Developers Can Get Started

1. zk-Rollups: Platforms like zkSync and StarkNet are excellent starting points for developers looking to build dApps using zk-Rollup technology. Tutorials and documentation on these platforms guide developers on contract migration, zk-SNARKs, and verification mechanisms.

2. Optimistic Rollups: Developers can explore Arbitrum and Optimism, both of which offer robust developer tools, EVM compatibility, and seamless integration with existing Ethereum dApps.

3. Polygon: For developers more interested in sidechains, Polygon offers a well-documented SDK that simplifies deploying scalable dApps with high transaction throughput and low fees.

4. State Channels: Platforms like Raiden Network and Celer offer tooling for integrating state channels into dApps, particularly useful for applications that handle micropayments or gaming.

Hope you found this helpful!

Drop a comment if you want to chat more about it.

Welcome to another day of exploring Web3 Engineering. Today, we are looking into a ERC standard proposed by Uniswap Labs and Across Protocol to standardize the cross chain trading / order execution and simplify it's implementation. Its main use is to enable more efficient and user-friendly cross-chain interactions. So, without any further ado, let's dive deeper into this.

Cross-chain Intents

Here, the intent means the expected user outcome by the trade. Before getting into it's working, let us understand some technical words involved in it. ERC-7683 protocol has 2 user roles.

• Swapper - User who placed a cross-chain trade / swap.

• Filler (Relayer) - Off-chain system that fulfills the user order.

DataStructure

CrossChainOrder

struct CrossChainOrder {
    address settlementContract;
    address swapper;
    uint256 nonce;
    uint32 originChainId;
    uint32 initiateDeadline;
    uint32 fillDeadline;
    bytes orderData;
}

• settlementContract - address of the settlement contract on the source network

• swapper - address of the user(swapper) on the source network

• nonce - nonce value to prevent double spending

• ordiginChainId - chainId assigned to the source network

• initiateDeadline - deadline to initiate the call on the source chain

• fillDeadline - deadline for the order to be filled on the destination chain

• orderData - any access data in bytes form required to execute the order on the destination chain such as token address, token amount, receiver address etc

the standard interface for the Settlement contract is shown as below:

/// @title ISettlementContract
/// @notice Standard interface for settlement contracts
interface ISettlementContract {
    /// @notice Initiates the settlement of a cross-chain order
    /// @dev To be called by the filler
    /// @param order The CrossChainOrder definition
    /// @param signature The swapper's signature over the order
    /// @param fillerData Any filler-defined data required by the settler
    function initiate(CrossChainOrder order, bytes signature, bytes fillerData) external;

    /// @notice Resolves a specific CrossChainOrder into a generic ResolvedCrossChainOrder
    /// @dev Intended to improve standardized integration of various order types and settlement contracts
    /// @param order The CrossChainOrder definition
    /// @param fillerData Any filler-defined data required by the settler
    /// @returns ResolvedCrossChainOrder hydrated order data including the inputs and outputs of the order
    function resolve(CrossChainOrder order, bytes fillerData) external view returns (ResolvedCrossChainOrder);
}

Step to Step Guide

1. To place a cross-chain order, user will sign the CrosshChainOrder struct data.

2. Once the order is signed, it will be broadcast against the network of fillers. The fillers will compete against each other in order to execute it.

3. Once a filler is finalized, they will call the initiate function on the source side Settlement Contract to lock the funds on the source contract.

4. Once the confirmation is received on the source side to the filler, they will continue to execute the trade on the destination network. The settlement contract ensures that the tokens are sent to the specified receiver address, which is included in the orderData of the original order.

The standard also have a generic data structure called ResolvedCrossChainOrder for unbundling the orderData in order to provide a standard way to execute the order on the destination contract. And the settlement contract must implement the resolve function which converts the CrossChainOrder into ResolvedCrossChainOrder

struct ResolvedCrossChainOrder {
    address settlementContract;
    address swapper;
    uint256 nonce;
    uint32 originChainId;
    uint32 initiateDeadline;
    uint32 fillDeadline;
    Input[] swapperInputs;
    Output[] swapperOutputs;
    Output[] fillerOutputs;
}

/// @notice Tokens sent by the swapper as inputs to the order
struct Input {
    address token;
    uint256 amount;
}

/// @notice Tokens that must be receive for a valid order fulfillment
struct Output {
    address token;
    uint256 amount;
    address recipient;
    uint32 chainId;
}

ResolvedCrossChainOrder

• settlementContract - Settlement contract address on the destination chain.

• swapper - address of the user(swapper) on the source network

• nonce - nonce value to prevent double spending

• ordiginChainId - chainId assigned to the source network

• initiateDeadline - deadline to initiate the call on the source chain

• fillDeadline - deadline for the order to be filled on the destination chain

• swapperInputs - array of Input (token) data which are taken from the swapper to initiate the transaction.

• swapperOutputs - The outputs to be given to the swapper as part of order fulfillment

• fillerOutputs - The outputs to be given to the filler as part of order settlement. It could include fees, commission etc.

Input

• token - address of the ERC20 token on the origin chain

• amount - amount of the token to be sent

Output

• token - address of the ERC20 token on the destination chain. zero address must be used in order to specify native token.

• amount - amount of the token to be sent to the receiver

• recipient - address of the output tokens receiver

• chainId - destination chainId for the output.

Protocols implementing ERC-7683

At the time of publishing this article, currently there are two projects that are implementing this standard. They are:

• Uniswap

• Across Protocol

Hope you found this helpful!

Drop a comment if you want to chat more about it.

Welcome to another day of Web3 Engineering. Today, we are going to explore a new layer 1 blockchain called Aeternity. It was launched by Yanislav Mahalov in 2016 to deal with the blockchain scalability problem. So, without any further ado, let's get started.

Aeternity Blockchain.

Aeternity is a scalable blockchain network which uses an hybrid consensus of Proof-of-Work(PoW) and Proof-of-Stake(PoS) to increase the transaction speed of the network. It has proven efficiency over the classic approach by using PoW for transaction validation and PoS for Community Governance Decisions like block size, transaction fee etc.

Along with the hybrid consensus, aeternity also uses state channels to increase the throughput. The smart contracts are executed off-chain using state channels to reduce the load on the main network and also granted enhanced privacy with faster executions.

Major Components

Aeternity blockchain comprises several major components to increase its functionality. Some of them are

1. Hybrid Consensus - A combined consensus of PoW and PoS to increase the transactions by separating processes for community decisions and transaction execution.

2. State Channels - State channels are a significant feature that allows transactions to occur off-chain. This enables faster and cheaper transactions, as they require only two on-chain transactions for opening and closing the channel.

3. Oracles - Aeternity integrates oracles that provide real-world data to smart contracts. This capability allows dApps to interact with external information, such as weather data or sports results, thereby expanding the utility of smart contracts beyond the blockchain.

4. Sophia Smart Contracts - Smart contracts are written in Sophia language. It is a functional programming language designed for smart contract development on Aeternity blockchain which is strongly types and provides higher level abstraction.

5. AENS - An in-built Decentralized Naming System which helps users to assign human readable names to their addresses and smart contracts.

6. Interoperability Protocol - Aeternity comes with a built-in interoperability protocol allowing it to interact with other blockchain system and support cross-functional dApps.

How the Hybrid Consensus Works

PoW Working

In Aeternity's setup, the PoW component is responsible for creating new blocks and validating transactions. It utilizes a unique algorithm called Cuckoo Cycle, which is ASIC-resistant and optimized for memory usage, allowing for efficient mining with lower energy consumption. This aspect enables miners to generate blocks approximately every 15 seconds, contributing to the network's speed and scalability.

PoS Working

The PoS mechanism in Aeternity serves primarily for governance rather than traditional staking. AE token holders can vote on critical system parameters such as block size, transaction fees, and protocol upgrades. This governance model ensures that the community has a say in the platform's evolution, promoting transparency and user engagement.

Interaction Between PoW and PoS

1. Block Creation: PoW miners create new blocks and add them to the blockchain.

2. Block Confirmation: Once blocks are created, PoS participants review and confirm these blocks. This dual-layer validation process enhances security, as blocks must be validated by both miners and stakeholders.

3. Voting and Governance: AE token holders use their tokens to vote on governance issues, with their voting power proportional to the number of tokens they hold. This structure allows for a decentralized decision-making process that reflects the interests of the community.

State Channels

State channels increase the transactions by offloading transactions from the main chain and private off chain transactions. They can also include smart contract executions as well. The process of making a transaction through state channel happens in 4 steps:

1. Channel Opening

   • To open up a state channel, the parties involved need to lockup funds on special smart contract on the blockchain.

   • This contract defines the terms of the channel such as timeout, lockup amount etc

2. Off-chain Transaction

   • Once the channel is established, the parties can continue with perform limitless transactions without worrying about the network congestion.

   • Now the parties will sign the state updates to make a new transaction. These transactions are private between the participants and are not recorded on the network.

3. Smart Contract Execution

   • If a contract is involved, the smart contract will be deployed on the channel when it is opened.

   • Alongside the channel's signed state, the contract is also updated allowing it to execute off chain without being deployed on main network.

4. Dispute Resolution

   • If the parties involved raises any dispute, it can be settled on the main net, by closing the final state on the main net.

   • This is done by publishing the updated signed state on the blockchain. And the other party will be given the timeout period to respond and dispute the published data.

   • If no disputes are raised, the channel will be closed recording the final state on the network and the locked-in funds are distributed according to the published state.

Welcome to another day of exploring Web3 Engineering. In our series, we are learning about Sui language and how to write smart contracts using Move language. So far, we have already covered the basic and necessary concepts that are required to write smart contracts. In this article, let us understand how to include time aka clock module in our contracts. So, without any further ado, let's get started...

Clock module

Sui standard package contains a special module called clock which contains the Clock using which we can access the current timestamp during execution. Clock is a shared object on the network and initialized during the genesis block. This object contains only one field which is timestamp_ms storing the current time of the network in milliseconds.

Even though it's a regular shared object, it can only be included as a reference in our functions and adding as a mutable reference results in compilation errors. The structure of the Clock object is as follows:

public struct Clock has key {
    id: UID,
    timestamp_ms: u64,
}

The module can be imported and used as follows:

public struct Counter has key, store {
    id:UID,
    count: u64,
    time: u64,
    last_updated: u64
}

public entry fun new(time: u64, clock: &Clock, ctx: &mut TxContext) {
    transfer::transfer(Counter {
        id: object::new(ctx),
        count: 0,
        time: time,
        last_updated: clock.timestamp_ms()
    }, ctx.sender());
} 

public entry fun update(counter: &mut Counter, clock: &Clock) {
    assert!(counter.last_updated + counter.time <= clock.timestamp_ms(), 0);
    counter.count = counter.count + 1;
    counter.last_updated = clock.timestamp_ms();
}

In our above contract, we have a Counter object which can only be updated after time which is given during the initialization. As you can, we have added the Clock as a reference on both of the functions. Now, let us write some test cases for the above code.

#[test]
fun test_new_counter() {
    let user  = @0x12e4;
    let mut scenario = test_scenario::begin(user);
    {
        let ctx = scenario.ctx();
        let mut clock = clock::create_for_testing(ctx);
        clock_obj::new(TIME, &clock, ctx);
        clock.increment_for_testing(1);
        clock.share_for_testing();
    };

    scenario.next_tx(user);
    {
        let mut counter = scenario.take_from_sender<clock_obj::Counter>();
        let clock = scenario.take_shared<clock::Clock>();
        counter.update(&clock);

        scenario.return_to_sender(counter);
        test_scenario::return_shared(clock);
    };
    scenario.end();
}

Here we are creating a test Clock object for our test scenario and sharing it into the network. We are also using the test helper functions provided by the clock module from the sui package. Now let us write a failure test case for the above scenario.

#[test, expected_failure]
fun test_fail_counter() {
    let user  = @0x12e4;

    let mut scenario = test_scenario::begin(user);
    {
        let ctx = scenario.ctx();
        let clock = clock::create_for_testing(ctx);
        clock_obj::new(TIME, &clock, ctx);
        clock.share_for_testing();
    };

    scenario.next_tx(user);
    {
        let mut counter = scenario.take_from_sender<clock_obj::Counter>();
        let clock = scenario.take_shared<clock::Clock>();
        counter.update(&clock);

        scenario.return_to_sender(counter);
        test_scenario::return_shared(clock);
    };
    scenario.end();
}

In the above test case, we are not updating the clock object. Hence it should throw an error as expected.

NOTE: For using the clock module in a function call made externally, we must pass the value 0x6 as the clock module object id.

The full code can be found here: https://github.com/jveer634/sui_contracts

That's all for today. Thank you.

Welcome to another day of exploring Web3 Engineering. Today, let us dive into the world of Modular blockchains. Let us understand what are they? How do they work ? And where are they useful ? So, without any further ado, let's get started..

What are Modular Blockchains ?

Traditionally, the old blockchain systems (Ethereum and Bitcoin) are monolithic. Which means all the tasks like block producing, consensus, validation etc are all taken care of as a single service. This approach creates problems whenever there is a need of updating the node for even a smaller change. e.g. Ethereum PoS update.

So, all these services are separated into separate for easy updates. And this module based architecture is called Modular Blockchains. By this, we can easily upgrade one layer without effecting the other layers. For instance, we can change the consensus algorithm without effecting block producing layer etc.

How do they work ?

These modular blockchains is made up of four layers. They are:

1. Blockchain / Execution layer

2. Settlement layer

3. Consensus layer

4. Data Availability Layer

Execution / Blockchain Layer

The execution layer is responsible for processing transactions and executing smart contracts. It is where users interact with the blockchain by signing transactions and transferring assets. This layer handles state changes, enabling the blockchain to update its ledger based on the transactions processed. By offloading execution to this layer, modular blockchains can achieve higher throughput and faster transaction times compared to monolithic structures.

Settlement Layer

The settlement layer verifies the execution of transactions and resolves disputes. It acts as a final arbiter, ensuring that once a transaction is executed, it is immutable and cannot be altered. This layer is not always present in monolithic blockchains but is an optional component in modular designs. It provides a crucial function analogous to a judicial system, confirming the legitimacy of transactions and maintaining the integrity of the blockchain.

Consensus Layer

The consensus layer establishes agreement among network participants on the validity of transactions and the state of the blockchain. It employs various consensus mechanisms, such as Proof of Stake (PoS) or Byzantine Fault Tolerance (BFT), to ensure that all nodes in the network reach a consensus on the order and validity of transactions.

Data Availability Layer

The data availability layer ensures that the data required to verify transactions is accessible and can be validated by network participants. This layer addresses the challenge of ensuring that transaction data is publicly available and not withheld by malicious actors.

Where are they useful ?

Modular blockchains are mainly used as Layer 2 solutions where scalability of a blockchain is the major issue. Modular blockchains address the scalability problem with the help of the technique called Sharding.

In monolithic blockchains, every transaction passed is required to be validated by every validator node in the cluster which is time consuming since there are a good number of validators running for a strong blockchain network like Ethereum.

But in modular blockchains, the transaction set is split into smaller chunks called SHARDS. Each shard is responsible for storing and managing a subset of the network's data, ensuring that the required data is available for processing transactions within that shard. With this process, the transactions undergo parallel execution that increases the scalability exponentially.

Welcome to another day of exploring Web3 Engineering. In today's blog, let us look into the tips and patterns to follow during solidity smart contract development to save gas costs while making transactions. So, without any further ado, let's get started.

1. Don't use a loop.

   As we all know by now, in solidity, every single operation costs some gas. When we run a for loop as shown below.

for(int i = 0; i< array.length(); i++) {
    if(array[i] == val) {
        array[i] = k;
    }
}

• We are initializing a variable called count

• We are also incrementing it for every iteration

These two operations will increase the gas in linear fashion depending on the length of the array.

2. Avoid Arrays and use Mappings

• Mappings are cheaper than than the Arrays in solidity.

  • Array values are supposed to saved in serial fashion. Which means, index 1 element will be saved in the memory location right after the index 0 element and so on.

  • In the storage space, the first memory block contains the length of the array and the values are stored from the 2nd block on wards.

  • If there is any value appended, it needs to update both values list and the length of the array. The two operations are expensive

• Mappings don't have any concept of length. The mapping are stored as key value pairs in the storage space.

  • Keys in mappings are hashed to a unique identifier that is used to locate the corresponding value in storage.

  • Which means whenever there is a need to update the mapping, there is only operation taking place.

3. Avoid calling global/storage variable multiple times

   While writing contracts, we often use multiple global variables such as block.timestamp, msg.sender, msg.value etc. But accessing global variables or storage variables is expensive. So, we need to create a local copy of the variable which will create an in-memory copy of the variable and accessing variables from memory is relatively cheaper. We can look into an example below.

// expensive function
function func1() external {
    require(admins[msg.sender], "Not eligible");
    changesCounter[msg.sender] += 1;
    emit Changed(msg.sender, block.timestamp);
}

// cheaper function
function func2() external {
    address caller = msg.sender;
    require(admins[caller], "Not eligible");
    changesCounter[caller] += 1;
    emit Changed(caller, block.timestamp);
}

4. Avoid calling Public functions inside another function

• An external / public returns ABI encoded data while an internal function returns bytes data. So, using a public function inside a function is expensive than caling an internal function.

• The code can be rewritten as shown in below in order to save gas.

    // Expensive method
    function childExpensive() public returns(uint) {
        return 10;
    }
    function expensive() external returns(uint) {
        return childExpensive();
    }
  
    // Cheaper method
  
    function _childInternal() internal returns(uint) {
        return 10;
    }
    function childCheap() external returns(uint) {
        return _childInternal();
    }
    function cheap() external returns(uint) {
        return _childInternal();
    }
  

  • In the cheaper method, we have converted the logic into a internal function and created a wrapper called childCheap to make it available for the external sources. And also whenever the logic is required we are calling the internal function.

Comment down if you have any more tips to save gas. Thank you

Welcome to another day of exploring Web3 Engineering. In today's blog, we are looking into Sniper Bot, one of the well used bots for cryptotrading. So, without any further ado, let's get started.

Sniper Bot

Sniper bot is an automated program that is used to execute a cryptotrade instantly according to the conditions set by the user. The main reason for using sniper bots is its swift response to the market movements and counter orders to make profits for the users.

For example, during a auction, we can place counter bids instantaneously by continuously monitoring the bids being placed in order to increase one's allotment chances.

Let's look into the key features of the Sniper Bots:

• Precision: Sniper bots are programmed to execute trades with precision, while considering the predetermined parameters to ensure favourable market entrance and exit positions.

• Automated trading: Sniper bots operate automatically, which means once the bots are deployed, zero to none human intervention is required

• Pre-programmed algorithms: Sniper bots use pre-programmed algorithms to function, which can incorporate technical indicators, arbitrage methods, scalping tactics, and precise entry and exit points.

• Fast execution: Sniper bots can execute trades in milliseconds or less, taking advantage of favorable price fluctuations.

Are there any types of Snipers ?

Based on the trading mechanism and the parameters set, there are 4 major categories of Sniper bots. They are:

• Entry/Exit Bots - These bots are deployed with predetermined entry and exit points for the asset price. Once the price enters/exits the given value, appropriate buy/sell calls are made to achieve profits.

• Scalping Bots - These bots trade on sudden spikes in the price. They place a good number of small trades to increase the trading activity on the asset and then leverages the sudden price changes.

• Arbitrage bots - These bots make profits by dealing with multiple exchanges and leveraging the price differences in them. For example, by purchasing the tokens at the exchange which has lower price and selling them at the exchange that has higher price.

• Technical indicator-based bots - These bots are based on the technical indicators such as Moving Averages (eg 52 week moving average), Strength Indices and Bollinger Bands to initiate and carry forward the trades according to the market conditions.

Working

On the higher view, all the sniper bots work in 3 simple steps.

• User criteria ingestion

• Market monitoring

• Trade execution

Lets look into them

1. User criteria Ingestion - To deploy a sniper bot, the user must input the specific criteria depending upon the type of the bot. For example, entry and exit conditions or technical algorithm or list of exchanges etc., With these base details the bot can initiate the process.

2. Market monitoring - With the input data, the bot starts monitoring the markets in real time searching for the correlations between the parameters given by the user and the current conditions.

3. Trade Execution - The bot quickly completes transactions after locating a match, trying to enter or exit at the optimal time.

Risks and Challenges:

So far, the sniper bot seems so useful and powerful to make traders life easy and gain profits. But there are also some risks and challenges that come with the usage of trading bots.

• Market volatility: With the quick action capability of Sniper bots, it makes the markets volatile as it keeps changing the prices of the assets instantaneously. If the bot is trading with a bigger volume of the asset, it can cause a shift in price of the assets within seconds.

• Algorithmic complexity: With the increase in the complexity of the algorithm used by sniper bots, it becomes challenging to detect and stop their activity.

• Regulatory compliance: Sniper bots may be subject to regulatory restrictions, and their use may be prohibited on certain platforms.

Detection and Prevention:

• Monitoring market behaviour: Monitoring market behaviour, analysing trade volumes, and timing can help detect and prevent sniper bot activity.

• Platform restrictions: Some platforms may restrict the use of sniper bots or implement anti-bot mechanisms to prevent their activity.

• User awareness: Educating users about the risks and challenges associated with sniper bots can help prevent their misuse.

Welcome to another day of exploring Web3 Engineering. Today, we will look into Biconomy and how it achieves gas less transactions using Account abstraction. So, without any further ado, let's get started.

Biconomy

Biconomy actually started as a plug and play protocol on EVM blockchains to provide gas-less with it's relayer infrastructure. Initially they provided gas less or Meta transactions using ERC-2771 standard. The user has to create a biconomy on it's dashboard and fill the gas tank with the respective native token of the chain they are providing the gas less transactions.

ERC 2771 Standard

ERC-2771 simplifies Ethereum smart contract interactions by enabling gasless transactions and meta transactions. It provides a secure protocol for native meta transactions, ensuring that transactions are correctly relayed and executed. By leveraging ERC-2771, developers can create more user-friendly and efficient dApps.

Key Components

• Transaction Signer: The user who initiates the transaction and signs the request off-chain.

• Gas Relay: A third-party account that pays for the gas fees and turns the signed request into a valid on-chain transaction.

• Trusted Forwarder: A contract that verifies the transaction data and ensures it is correctly relayed to the intended recipient contract.

• Recipient Contract: The smart contract that accepts and executes the meta transaction.

Workflow

• Off-Chain Signing: The user signs a request off-chain using their private key.

• Gas Relay: The gas relay receives the signed request and pays the gas fee.

• Trusted Forwarder: The trusted forwarder verifies the transaction data and ensures it is correctly relayed to the recipient contract.

• On-Chain Execution: The recipient contract executes the transaction.

But later, Biconomy switched from ERC2771 to ERC 4337 Account Abstraction Model to provide which uses new way of making transactions and efficient transaction batching which reduces the gas fees for the sponsors.

ERC 4337 Account Abstraction

ERC-4337 is another standard that enables account abstraction and provides smart contracts with EAO features. While both standards simplify transactions, ERC-2771 focuses on gasless transactions and meta transactions, whereas ERC-4337 introduces a new object type called UserOperations and a paymaster mechanism for managing gas fees.

Key Components

• UserOperations: These are "to-do lists" that users provide to their Ethereum accounts, which can include actions like transferring funds, interacting with smart contracts, or a combination of multiple actions. UserOperations are bundled together into a single transaction, reducing the need for multiple transactions.

• EntryPoint Contract: This contract acts as a proxy for the user, executing the UserOperations and ensuring that the user's intent is correctly relayed to the intended recipient contract.

• Paymaster Mechanism: This mechanism allows users to pay gas fees using ERC-20 tokens instead of ETH or enables a third party to sponsor gas fees in a decentralized manner.

Biconomy Implementation

In the latest version of Biconomy (v4), we have the Biconomy Account Abstraction toolkit is available which we can use to create smart account for the users in order to make the ERC4337 transactions.

Before starting with that, we first have to setup our app on the biconomy dashboard where we set up the Paymaster and we obtain the Bundler url from it.

We can fill the paymaster with the required tokens and pass the required credentials to the SDK for creating the smart accounts. Here is the script to create the smart accounts for a given user.

Let us check a typescript example on how to create a smart account for the user using viem and typescript/javascript.

import {
  Hex,
  createWalletClient,
  encodeFunctionData,
  http,
  parseAbi,
  zeroAddress,
} from "viem";
import { privateKeyToAccount } from "viem/accounts";
import { polygonAmoy } from "viem/chains";
import { createSmartAccountClient } from "@biconomy/account";

const bundlerUrl = "BUNDLER_URL"; // Found at https://dashboard.biconomy.io

export const createAccountAndMintNft = async () => {
  // ----- 1. Generate EOA from private key
  const account = privateKeyToAccount("0x" + "PRIVATE_KEY");
  const client = createWalletClient({
    account,
    chain: polygonAmoy,
    transport: http(),
  });
  const eoa = client.account.address;
  console.log(`EOA address: ${eoa}`);

  // ------ 2. Create biconomy smart account instance
  const smartAccount = await createSmartAccountClient({
    signer: client,
    bundlerUrl,
  });
  const saAddress = await smartAccount.getAccountAddress();
  console.log("SA Address", saAddress);
};
createAccountAndMintNft();

Now, let us look into how to make a gasless transaction using the Smart account.

try {
  const nftAddress = "0x1758f42Af7026fBbB559Dc60EcE0De3ef81f665e";
  const parsedAbi = parseAbi(["function safeMint(address _to)"]);
  const nftData = encodeFunctionData({
    abi: parsedAbi,
    functionName: "safeMint",
    args: [saAddress as Hex],
  });

  // ------ 4. Send transaction
  const userOpResponse = await smartAccount.sendTransaction({
    to: nftAddress,
    data: nftData,
  });
  const { transactionHash } = await userOpResponse.waitForTxHash();
  console.log("transactionHash", transactionHash);
  const userOpReceipt = await userOpResponse.wait();
  if (userOpReceipt.success == "true") {
    console.log("UserOp receipt", userOpReceipt);
    console.log("Transaction receipt", userOpReceipt.receipt);
  }
} catch (error: unknown) {
  if (error instanceof Error) {
    console.error("Transaction Error:", error.message);
  }
}

NOTE: If we ever want to make any payable transactions using our smart account (send ether in a contract call), we need to contain funds on the smart account.

Welcome to another day of exploring Web3 Engineering. In today's blog, let us check on how to make payments using coin module on Sui.

We all know about the ERC20 standard in the Ethereum and how it is different from the native eth payments in the solidity contracts. Having 2 different payment currencies poses a lot of problems and excessive work in the solidity ecosystem. To avoid that case, Sui contains the Coin standard and the native SUI currency is also implemented using the same standard. Which means we don't have to write different functions to handle payments of SUI and other tokens.

Below we have a counter contract that accepts the SUI Coin payments.

/// Module: coin_payments
module coin_payments::coin_payments {
    use sui::sui::SUI;
    use sui::coin::{Self, Coin};
    use sui::balance::{Self, Balance};

    public struct CoinPayments has key {
        id: UID,
        new_fee: u64,
        update_fee: u64,
        balance: Balance<SUI>
    }

    public struct CoinPaymentsCap has key {
        id: UID
    }

    public struct Counter has key,store{
        id: UID,
        val: u64
    }
    // Errors
    const ENegativeDecrement: u64 = 0;
    const EInvalidPayment: u64 = 1;

    fun init(ctx: &mut TxContext) {
        transfer::transfer(CoinPaymentsCap {
            id: object::new(ctx)
        }, ctx.sender());
        transfer::share_object(CoinPayments {
            id: object::new(ctx),
            new_fee: 1000,
            update_fee: 100,
            balance: balance::zero<SUI>(),
        })
    }

    #[allow(lint(self_transfer))]
    public fun new(cp: &mut CoinPayments, payment: Coin<SUI>, ctx: &mut TxContext) {
        assert!(cp.new_fee == payment.value(), EInvalidPayment);
        coin::put(&mut cp.balance, payment);    
        transfer::transfer(Counter {
            id: object::new(ctx),
            val:0
        }, ctx.sender())
    }

    public fun increment(c: &mut Counter, cp: &mut CoinPayments, payment: Coin<SUI>) {
        assert!(cp.update_fee == payment.value(), EInvalidPayment);
        coin::put(&mut cp.balance, payment);
        c.val = c.val + 1
    }

    public fun decrement(c: &mut Counter, cp: &mut CoinPayments, payment: Coin<SUI>) {
        assert!(c.val > 0, ENegativeDecrement);
        assert!(cp.update_fee == payment.value(), EInvalidPayment);
        coin::put(&mut cp.balance, payment);
        c.val = c.val - 1
    }

    public fun val(c: &Counter) :u64 {
        c.val
    }

    public entry fun withdraw(cp: &mut CoinPayments, _: &CoinPaymentsCap, ctx: &mut TxContext) {
        let val = cp.balance.value();
        let payment = coin::take(&mut cp.balance, val, ctx);
        transfer::public_transfer(payment, ctx.sender())
    }

    #[test_only]
    public fun init_for_testing(ctx: &mut TxContext) {
        init(ctx);
    } 
}

Here we can see that Sui payments are payments are received by receiving Coin<SUI> as an argument with the required value. Unlike the Solidity msg.value as a transaction parameter, we are directly including it as a function argument.

And here if we have a close look, we are using 2 objects and they are Coin and Balance. Coin is the transferable object of the given currency while the Balance is the stored value of it. Here, we are storing the payment received as Balance in the CoinPayments object but transferring it to the user as Coin object.

Now, let us look into the test cases for the above contract.

#[test_only]
module coin_payments::coin_payments_tests {
    use sui::coin;
    use sui::sui::SUI;
    use sui::test_scenario;
    use coin_payments::coin_payments;

    const USER: address = @0xFACE;
    const ADMIN: address = @0xCAFE;

    #[test]
    fun test_coin_payments() {
        let mut scenario = test_scenario::begin(ADMIN);
        {
            coin_payments::init_for_testing(scenario.ctx());
        };

        scenario.next_tx(USER);
        {
            let mut cp = test_scenario::take_shared<coin_payments::CoinPayments>(&scenario);
            let c = coin::mint_for_testing<SUI>(1000, scenario.ctx());
            coin_payments::new(&mut cp, c, scenario.ctx());
            test_scenario::return_shared(cp);
        };

        scenario.next_tx(USER);
        {
            let mut cp = test_scenario::take_shared<coin_payments::CoinPayments>(&scenario);
            let c = coin::mint_for_testing<SUI>(100, scenario.ctx());

            let mut counter = scenario.take_from_sender<coin_payments::Counter>();
            coin_payments::increment(&mut counter, &mut cp, c);

            scenario.return_to_sender(counter);
            test_scenario::return_shared(cp);
        };

        scenario.next_tx(ADMIN);
        {
            let mut cp = test_scenario::take_shared<coin_payments::CoinPayments>(&scenario);
            let cap = scenario.take_from_sender<coin_payments::CoinPaymentsCap>();

            coin_payments::withdraw(&mut cp, &cap, scenario.ctx());

            scenario.return_to_sender(cap);
            test_scenario::return_shared(cp);
        };

        scenario.end();
    }
}

Here in the above test cases, we are testing both paying as a user scenario and also withdrawing as the admin scenario.

Welcome to another day in exploring Web3 Engineering. In today's blog, let us check out how to write custom transfer method for a Sui object.

A Sui object is usually transferred using the public_transfer from the transfer module in the sui package. This function can directly be called from a smart contract or from a PTB as well.

This function doesn't interact with the module that the object is defined and just transfers the ownership of the object without raising any events as well. And we can't control the execution as well. There might be some cases where the developer wants to impose some certain actions while transferring the objects. For example, allowing transfers to only eligible users by the app, imposing some fee for transfer of the NFT etc. For such situations, we can write our own transfer function for the Objects and implement our own logic according to the app.

For a object to be eligible to use the public_transfer function, it must contain the store ability. So, if we create an object which doesn't have store, it can only be transferred using transfer method from the transfer module. The transfer function can only transfer objects that are defined in the same module.

Now, let us write a move smart contract that tracks the number of times that the object is transferred.

/// Module: custom_transfer
module custom_transfer::custom_transfer {
    use sui::vec_map::{Self, VecMap};

    public struct CustomTransfer has key, store {
        id: UID,
        transfers_count: VecMap<ID, u64>
    }

    fun init(ctx: &mut TxContext) {
        transfer::transfer(CustomTransfer {
            id: object::new(ctx),
            transfers_count: vec_map::empty<ID, u64>()
        }, ctx.sender())
    }

    public struct Asset has key {
        id: UID,
        val: u64
    }

    public fun new(c: &mut CustomTransfer, val: u64, ctx: &mut TxContext) {
        let id = object::new(ctx);
        c.transfers_count.insert(id.to_inner(), 0);
        transfer::transfer(Asset {
            id,
            val
        }, ctx.sender())
    }

    // notice: Custom transfer function
    public fun transfer(c: &mut CustomTransfer, asset: Asset, receiver: address) {
       let counter = c.transfers_count.get_mut(&asset.id.to_inner());
        *counter = *counter + 1;
        transfer::transfer(asset, receiver)
    }

    public fun count(c: &CustomTransfer, asset: &Asset): u64 {
        *c.transfers_count.get(&asset.id.to_inner())
    }

    #[test_only]
    public fun init_for_test(ctx: &mut TxContext) {
        init(ctx)
    }
}

In the above contract, we have the

• CustomTransfer object which will save the transfer counts.

• Asset object on which we are implementing the custom transfer method.

• new method which will generate a new Asset

• transfer our custom transfer method, which will increase the transfers count in the CustomTransfer object

Now, let us write the test cases

#[test_only]
module custom_transfer::custom_transfer_tests {
    use sui::test_scenario;
    use custom_transfer::custom_transfer;

    const USER: address = @0xCAFE;
    const ANOTHER_USER: address = @0xFACE;

    #[test]
    fun test_custom_transfer() {
        let mut scenario = test_scenario::begin(USER);
        {
            custom_transfer::init_for_test(scenario.ctx());
        };

        scenario.next_tx(USER);
        {
            let mut ct = scenario.take_from_sender<custom_transfer::CustomTransfer>();
            custom_transfer::new(&mut ct, 10, scenario.ctx());
            scenario.return_to_sender(ct);
        };

        scenario.next_tx(USER);
        {
            let mut ct = scenario.take_from_sender<custom_transfer::CustomTransfer>();
            let asset = scenario.take_from_sender<custom_transfer::Asset>();

            let counter = custom_transfer::count(&ct, &asset);
            assert!(counter == 0, 0);

            custom_transfer::transfer(&mut ct, asset, ANOTHER_USER);
            scenario.return_to_sender(ct);
        };

        scenario.next_tx(USER);
        {
            let ct = scenario.take_from_sender<custom_transfer::CustomTransfer>();
            let asset = scenario.take_from_address<custom_transfer::Asset>(ANOTHER_USER);

            let counter = custom_transfer::count(&ct, &asset);
            assert!(counter == 1, 0);

            scenario.return_to_sender(ct);
            test_scenario::return_to_address(ANOTHER_USER, asset);
        };
        scenario.end();
    }
}

Here we have the test case which will test the increase the count. And also, if we try to use the public_transfer method on the Asset, the move analyzer directly gives us an error message or if it is not installed, we will get an error while compiling the code itself

Full code can be found here: https://github.com/jveer634/sui_contracts/

Thank you.