A cross-chain bridge is a protocol that allows assets, data, or smart contract states to be transferred between two or more decentralised networks. It enables interoperability between different blockchains, ensuring seamless movement of tokens, NFTs, and other digital assets across ecosystems.

So, how about we learn how to build a cross-chain bridge that allows NFTs to move between two EVM-compatible chains (e.g., Ethereum & Base, Arbitrum, Optimism & Polygon). Unlike traditional bridges, which use an off-chain relayer, we will implement an on-chain gateway using LayerZero, making the process fully decentralised and trustless.

If you want to read more about decentralised bridges, check out my previously posted article.

NFTs and assets are often confined to their originating blockchain, limiting their interoperability and liquidity. A cross-chain bridge enables users to transfer NFTs between different chains, enhancing:

• Liquidity — NFTs can be traded across multiple ecosystems.
• Utility — Users can access different dApps on multiple chains.
• Scalability — Avoid congestion on expensive chains like Ethereum.

The base chain, where an NFT collection originates, plays a crucial role in determining the overall value and functionality of the NFTs.

1. Security and Trust: The base chain provides the foundational security for the NFT collection. A well-established chain like Ethereum offers robust security features, which can enhance the trustworthiness of the NFTs. While an L2 like Base can offer lower gas fee. There’s several factors that you can think of while deciding the base chain for your NFT collection.
2. Network Effects: The popularity and user base of the base chain can significantly impact the visibility and adoption of the NFT collection. A chain with a large community can drive more engagement and transactions.
3. Ecosystem and Tools: The base chain often dictates the available development tools and ecosystem support. A rich ecosystem with various dApps and services can add more utility to the NFTs, allowing them to be used in diverse applications.
4. Transaction Costs: The cost of transactions on the base chain can affect the affordability and frequency of NFT trades. Chains with lower fees can encourage more trading activity, while high fees might deter users.
5. Interoperability: The base chain’s compatibility with other chains can determine how easily NFTs can be transferred across different networks. A chain that supports cross-chain protocols can enhance the liquidity and utility of the NFTs. It’s very important that you do not choose a chain which doesn’t allow access to outside network at all.
6. Innovation and Upgrades: The pace of innovation and the ability to implement upgrades on the base chain can influence the long-term viability and features of the NFT collection. Chains that are actively developed and improved can offer more advanced capabilities over time. Never go for a chain, which has stangant development or takes too long to iterate.

However, we can not expect all the users to remain on any single network. So, we need to prepare for the seemless moving around of assets cross-chain, thereby improving interoperability.

And of course, there are several approaches to achieve bridging, depending on how you structure your product. Let’s go ahead with a classic approach this time.

How It Works

1. Lock the NFT on Chain A (BridgeA contract).
2. Send a cross-chain message using LayerZero to Chain B.
3. BridgeB contract receives the message and mints a wrapped NFT on Chain B.
4. To return the NFT, the wrapped NFT is burned on Chain B, and a message is sent back to unlock the original NFT.

🏛 On-Chain Relayer (Our Approach)

✅ Fully decentralised, no external trust required.
✅ All logic is enforced via smart contracts.
✅ Works with protocols like LayerZero or Axelar.

⚡ Off-Chain Relayer

❌ Requires external nodes/validators to confirm transactions.
❌ Can introduce centralisation and trust assumptions.
❌ Relayers may become a point of failure.

Our on-chain approach ensures security and trustlessness by leveraging smart contracts for message passing. We’re using EVM chains for this example so the contracts preferrably written in solidity.

NFT Contract

First, deploy an ERC-721 NFT contract on both chains:

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

import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@openzeppelin/contracts/access/Ownable.sol";
contract MyNFT is ERC721URIStorage, Ownable {
    uint256 public nextTokenId;
    
    constructor() ERC721("MyNFT", "MNFT") {}
    
    function mint(string memory tokenURI) external onlyOwner {
        _safeMint(msg.sender, nextTokenId);
        _setTokenURI(nextTokenId, tokenURI);
        nextTokenId++;
    }
}

Bridge Contract (Chain A) — Lock NFT & Send Message

Create BridgeA.sol on Chain A:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;
import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
import "@layerzerolabs/solidity-examples/contracts/lzApp/NonblockingLzApp.sol";

contract BridgeA is NonblockingLzApp {
    ERC721 public nft;
    address public admin;
    event NFTLocked(address indexed user, uint256 tokenId);
    constructor(address _nft, address _lzEndpoint) NonblockingLzApp(_lzEndpoint) {
        admin = msg.sender;
        nft = ERC721(_nft);
    }
    function lockNFT(uint256 tokenId, uint16 destChainId, bytes memory receiver) external payable {
        require(nft.ownerOf(tokenId) == msg.sender, "Not NFT owner");
        nft.transferFrom(msg.sender, address(this), tokenId);
        bytes memory payload = abi.encode(msg.sender, tokenId);
        _lzSend(destChainId, payload, payable(msg.sender), address(0), bytes(""), msg.value);
        emit NFTLocked(msg.sender, tokenId);
    }
    function _nonblockingLzReceive(uint16, bytes memory, uint64, bytes memory payload) internal override {}
}

Bridge Contract (Chain B) — Receive & Mint Wrapped NFT

Create BridgeB.sol on Chain B:

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

import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
import "@layerzerolabs/solidity-examples/contracts/lzApp/NonblockingLzApp.sol";

contract BridgeB is ERC721URIStorage, NonblockingLzApp {
    address public admin;
    uint256 public nextTokenId;
    event NFTMinted(address indexed user, uint256 tokenId);
    constructor(address _lzEndpoint) ERC721("WrappedNFT", "WNFT") NonblockingLzApp(_lzEndpoint) {
        admin = msg.sender;
    }
    function _nonblockingLzReceive(uint16, bytes memory, uint64, bytes memory payload) internal override {
        (address user, uint256 tokenId) = abi.decode(payload, (address, uint256));
        _safeMint(user, nextTokenId);
        _setTokenURI(nextTokenId, "https://metadata-url");
        emit NFTMinted(user, nextTokenId);
        nextTokenId++;
    }
}

Unlocking NFTs (Return to Chain A)

Modify BridgeB.sol to burn the wrapped NFT and send it back:

function burnNFT(uint256 tokenId, uint16 destChainId) external payable {
    require(ownerOf(tokenId) == msg.sender, "Not NFT owner");
    _burn(tokenId);
    bytes memory payload = abi.encode(msg.sender, tokenId);
    _lzSend(destChainId, payload, payable(msg.sender), address(0), bytes(""), msg.value);
}

Modify BridgeA.sol to release the original NFT:

function _nonblockingLzReceive(uint16, bytes memory, uint64, bytes memory payload) internal override {
    (address user, uint256 tokenId) = abi.decode(payload, (address, uint256));
    nft.transferFrom(address(this), user, tokenId);
}

Let’s test our Bridge:

1. Deploy contracts on two testnets (say, Base Sepolia & Polygon Amoy).
2. Mint an NFT on Chain A.
3. Lock & transfer the NFT using the bridge.
4. Verify minting of wrapped NFT on Chain B.
5. Burn wrapped NFT to return to Chain A.

Future Improvements that can be made:

Multi-Chain Support

To enhance the functionality and reach of our bridge, we can consider adding support for additional EVM-compatible chains. This would involve integrating with popular networks like Binance Smart Chain, Avalanche, and Fantom, which would allow users to transfer NFTs across a wider range of platforms. Furthermore, expanding beyond EVM-compatible chains to include other blockchain ecosystems, such as Solana, Cosmos, and Polkadot, could significantly broaden the bridge’s capabilities. This expansion would require developing interoperability solutions to handle the unique characteristics and consensus mechanisms of these different blockchains. By doing so, we would enable seamless NFT transfers across a diverse array of blockchain networks, providing users with greater flexibility and access to a wider audience. This strategic enhancement could position our bridge as a leading solution in the rapidly evolving multi-chain NFT landscape.

Cross-Chain Fees

Implementing gas abstraction can significantly enhance the user experience by making transactions more seamless and user-friendly. Gas abstraction involves creating a system where users do not need to worry about paying gas fees directly in cryptocurrency. Instead, the system can handle these fees on behalf of the users, possibly by integrating a third-party service or using a relayer network. This approach can simplify the transaction process, especially for users who are not familiar with blockchain technology or do not hold the native cryptocurrency required for gas fees. By abstracting gas fees, developers can create a more intuitive and accessible platform, encouraging broader adoption and reducing barriers for entry into the blockchain ecosystem. Additionally, this can be particularly beneficial in scenarios involving cross-chain interactions, where users might otherwise need to manage multiple cryptocurrencies for gas fees on different chains.

Decentralised Governance

Decentralised Autonomous Organisations (DAOs) can play a crucial role in managing and governing bridge policies. By introducing DAO-controlled bridge policies, we can ensure that the decision-making process is transparent, democratic, and community-driven. This means that all stakeholders, including developers, users, and investors, can participate in proposing, discussing, and voting on changes to the bridge’s operational rules and guidelines. Such a system can enhance trust and accountability, as decisions are made collectively rather than by a centralised authority. Additionally, DAO governance can adapt more quickly to the evolving needs of the community and the market, allowing for more responsive and flexible policy adjustments. By leveraging the power of DAOs, we can create a more resilient and adaptable bridge infrastructure that aligns with the interests and values of its users.

Note that this was for learning purposes only. The real contracts will have to consider several security issues and vulnerabilities which we’ve assumed here, as part of the happy path. But it’s a start and would love to see at least some of you try it out and build more decentralised bridges. The bridges ecosystem is both quickly evolving and stagnant at the same time. Cross-chain messaging protocols have certainly pulled in a pin off the race for building decent decentralised bridges, but we’ve quite a few improvement yet to be made to achieve true trustless systems.

Imagine having access to the value of an asset, say, Tesla stock, without ever owning it. That’s essentially what synthetic asset tokens (or just “synthetics”) do. These are blockchain-based tokens that mimic the value of real-world assets, such as stocks, commodities, or even fiat currencies. Think of them as financial doppelgängers: they look, act, and feel like the original, but they exist entirely in the digital realm.

In the traditional financial market, synthetic assets are not new. Derivatives like futures and options have been around for decades, allowing traders to bet on the price of an asset without ever owning it. Synthetic tokens simply bring this concept to the blockchain, leveraging smart contracts to handle everything transparently and automatically.

Derivatives exist in web3 as well already. However, there’s still lot of scepticism around it. Derivatives like futures, options, and perpetual swaps already exist and are widely used. Both derivatives and synthetic tokens are tied to an underlying asset, such as Bitcoin, Ethereum, or traditional stocks like Tesla. The performance of these assets directly affects the value of the derivative or synthetic token. Just as derivatives allow traders to speculate or hedge risks, synthetic asset tokens let users gain exposure to the price of assets without actually owning them.

Crypto derivatives have gained significant traction, especially in speculative trading. Futures and perpetual swaps on exchanges like Binance, Bybit, and dYdX dominate trading volumes. They offer high liquidity and enable speculation on crypto prices. Traders and institutions use derivatives to manage risk, especially in highly volatile markets. Many jurisdictions have banned or restricted derivatives trading due to concerns over high leverage and investor risk (e.g., Binance halting derivatives in several countries). The extreme price swings in crypto make derivatives riskier than their traditional counterparts, leading to liquidations for unprepared traders.

Traditional finance views synthetics as tools for hedging and speculation. Want to protect yourself from the wild price swings of oil without owning physical barrels? A synthetic derivative could be your best friend. Similarly, traders use them to speculate on price movements, essentially making money out of thin air, if they play their cards right.

In the tokenized asset market, synthetic tokens serve a similar purpose, but with a blockchain twist. They’re used for:

1. Global Accessibility: You don’t need a brokerage account to own a synthetic version of Apple stock. Just a crypto wallet will do.
2. Fractional Ownership: Want exposure to gold but can’t afford a whole ounce? Synthetic tokens can be fractioned down to tiny denominations.
3. Decentralized Finance (DeFi): Platforms like Synthetix allow users to mint synthetic tokens using their crypto as collateral.

Like any financial innovation, synthetic asset tokens come with their own set of advantages and challenges.

Pros

• Accessibility: Traditional markets often have barriers, like location, regulations, or account requirements. Synthetic tokens tear those walls down.
• Efficiency: Transactions happen on the blockchain, which means they’re often faster and cheaper than traditional methods.
• Liquidity Boost: Synthetic tokens can unlock liquidity by bringing otherwise illiquid assets into a tradable, digital format.

Cons

• Complexity: They’re not beginner-friendly. Understanding how synthetics work requires some financial and blockchain literacy.
• Regulation: Governments haven’t fully figured out how to regulate synthetic tokens, which could lead to legal uncertainties. Hell, some governements are yet to figure to crypto itself.
• Counterparty Risk: In DeFi, your synthetics depend on smart contracts and oracles. If something goes wrong there, your assets could be at risk.

Here’s where things get exciting. Synthetic asset tokens can significantly improve liquidity in the crypto and NFT markets by unlocking idle assets, diversification and bridging markets. Imagine converting an NFT, typically illiquid, into a synthetic token that can be freely traded. This opens up an entirely new avenue for liquidity in the NFT space. Traders could gain exposure to other markets (stocks, gold, real estate) without leaving the crypto ecosystem. Synthetic tokens could serve as a bridge between traditional and crypto markets. For example, a synthetic token pegged to the S&P 500 index could attract traditional investors into the blockchain world.
In essence, synthetics have the potential to make markets more fluid, more inclusive, and more interconnected.

A few platforms and projects are already leveraging synthetic asset tokens:

• Synthetix: Synthetix is one of the leading platforms for synthetic assets. It allows users to mint Synths tokens representing real-world assets like sUSD (synthetic USD), sBTC (synthetic Bitcoin), and even synthetic stocks. Synthetix uses Chainlink oracles to ensure accurate pricing.
• Mirror Protocol: Built on Terra, Mirror Protocol enabled synthetic versions of stocks like mAAPL (synthetic Apple stock) and mGOOGL (synthetic Google stock). It gained popularity for allowing users outside the U.S. to trade synthetic U.S. stocks. However, Terra’s collapse affected its adoption.
• NFTy (👀): Imagine a platform where synthetic tokens represent a basket of the top 500 NFT collections. It creates a new layer of liquidity and market exposure for NFT enthusiasts.

Let’s skip to look into code for a bit.

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

contract SyntheticAssetToken {
    string public name = "SyntheticAssetToken";
    string public symbol = "SAT";
    uint8 public decimals = 18;
    uint256 public totalSupply;
    mapping(address => uint256) public balanceOf;
    mapping(address => mapping(address => uint256)) public allowance;
    uint256 public collateralRatio = 200; // 200% collateral required
    uint256 public collateralLocked;
    mapping(address => uint256) public collateral;
    address public owner;
    constructor() {
        owner = msg.sender;
    }
    modifier onlyOwner() {
        require(msg.sender == owner, "Only the owner can perform this action");
        _;
    }
    // Events
    event Transfer(address indexed from, address indexed to, uint256 value);
    event Approval(address indexed owner, address indexed spender, uint256 value);
    event Mint(address indexed user, uint256 amount, uint256 collateral);
    event Burn(address indexed user, uint256 amount, uint256 collateralReturned);
    // Transfer tokens
    function transfer(address to, uint256 value) public returns (bool) {
        require(balanceOf[msg.sender] >= value, "Insufficient balance");
        balanceOf[msg.sender] -= value;
        balanceOf[to] += value;
        emit Transfer(msg.sender, to, value);
        return true;
    }
    // Approve an allowance for another address
    function approve(address spender, uint256 value) public returns (bool) {
        allowance[msg.sender][spender] = value;
        emit Approval(msg.sender, spender, value);
        return true;
    }
    // Transfer tokens on behalf of another address
    function transferFrom(address from, address to, uint256 value) public returns (bool) {
        require(balanceOf[from] >= value, "Insufficient balance");
        require(allowance[from][msg.sender] >= value, "Allowance exceeded");
        balanceOf[from] -= value;
        balanceOf[to] += value;
        allowance[from][msg.sender] -= value;
        emit Transfer(from, to, value);
        return true;
    }
    // Mint synthetic tokens by locking ETH as collateral
    function mint(uint256 amount) public payable {
        uint256 requiredCollateral = (amount * collateralRatio) / 100;
        require(msg.value >= requiredCollateral, "Insufficient collateral");
        collateral[msg.sender] += msg.value;
        balanceOf[msg.sender] += amount;
        totalSupply += amount;
        collateralLocked += msg.value;
        emit Mint(msg.sender, amount, msg.value);
    }
    // Burn synthetic tokens and withdraw collateral
    function burn(uint256 amount) public {
        require(balanceOf[msg.sender] >= amount, "Insufficient token balance");
        uint256 collateralToReturn = (amount * collateralRatio) / 100;
        require(collateral[msg.sender] >= collateralToReturn, "Insufficient collateral locked");
        balanceOf[msg.sender] -= amount;
        totalSupply -= amount;
        collateral[msg.sender] -= collateralToReturn;
        collateralLocked -= collateralToReturn;
        payable(msg.sender).transfer(collateralToReturn);
        emit Burn(msg.sender, amount, collateralToReturn);
    }
    // Fallback function to handle ETH sent directly to the contract
    fallback() external payable {}
    receive() external payable {}
}

Users lock ETH as collateral, and the contract mints synthetic tokens (SAT) for them. The required collateral is 200% of the token's value (adjustable by modifying collateralRatio). Users can burn their synthetic tokens to reclaim the collateral they locked. The contract also supports ERC-20 functions like transfer, approve, and transferFrom.

Please note that this smart contract is for understanding need only and not to be used in real production use-case. It needs to have further price oracles, liquidation and governance models included for that, not to mention security.

As exciting as synthetic asset tokens are, they come with significant security concerns. Since these tokens are entirely reliant on blockchain technology and smart contracts, their safety depends on the robustness of the underlying code and ecosystem.

Smart Contract Vulnerabilities

Smart contracts are immutable once deployed, meaning any bug in the code can be catastrophic. Hackers can exploit vulnerabilities to drain collateral, mint unauthorized tokens, or manipulate token behavior.

Example: The 2020 bZx protocol exploit resulted in losses of millions due to flaws in its smart contract logic.

Price Oracle Manipulation

Synthetic tokens rely on price oracles to mirror the value of real-world assets. If an oracle is compromised or manipulated, the synthetic token’s value could diverge drastically, leading to losses for users.

Example: In 2022, several DeFi platforms experienced oracle attacks where attackers manipulated prices to profit from undercollateralized positions.

Collateral Risks

Synthetic tokens require collateral backing to maintain trust and stability. If collateral values drop suddenly (e.g., during a market crash), the synthetic asset system could become undercollateralized, leading to insolvency and loss of funds.

Rug Pulls and Governance Exploits

In decentralized systems, malicious actors could take over governance (via token voting) and implement changes that siphon funds or destroy the ecosystem.

Regulatory Compliance Risks

Since synthetic tokens mimic traditional assets, they often blur the line between DeFi and traditional finance. Regulatory bodies like the SEC in the U.S. or the RBI in India could impose restrictions or fines on platforms operating without compliance.

Governance is essential to ensure the stability, transparency, and adaptability of synthetic asset platforms. Without proper governance, these systems can devolve into chaos, whether through technical issues, regulatory non-compliance, or community mismanagement.

1. Updating Parameters: Adjusting collateral ratios, fees, and system rules in response to market conditions.
2. Security Audits: Funding regular audits to identify and patch vulnerabilities.
3. Price Oracle Management: Ensuring that oracles used for price feeds are reliable, decentralized, and tamper-proof.
4. Emergency Response: Providing mechanisms to pause or roll back operations during unexpected attacks or exploits.
5. Regulatory Compliance: Proactively adapting to legal requirements, such as Know Your Customer (KYC) and Anti-Money Laundering (AML) measures.

We can infact learn a lot from traditional financial governance as they’ve gone through similar states involving synthetic assets or derivatives.

1. SEC’s Role: In traditional finance, the U.S. SEC (Securities and Exchange Commission) enforces regulations that protect investors, ensure market fairness, and penalize fraud. Synthetic token platforms could learn from the SEC’s stringent oversight of derivatives and securities markets to build trust.
2. RBI’s Approach: The Reserve Bank of India oversees monetary policy and ensures that banks maintain sufficient reserves. Similarly, synthetic token platforms need to enforce collateralization rules to prevent insolvency.

Many synthetic token projects already implement decentralized governance models, where token holders vote on key decisions. However, these systems need to balance decentralization with expertise; relying solely on token holders without checks can lead to uninformed or malicious decisions.

In decentralized synthetic asset markets, reputation will be a key differentiator. Fund managers with strong track records will likely attract more users, liquidity providers, and partnerships. However, reputation isn’t just a personal asset; it elevates the entire market by fostering trust and reducing skepticism about decentralized finance.

As the synthetic asset ecosystem grows, we will be introducing decentralized reputation scoring systems in NFTy, think “on-chain LinkedIn for fund managers”. Reputation could become a tradable asset in itself, shaping the future of decentralized markets just as much as the assets being tokenized. We can cover more on building reputation later.

Synthetic asset tokens are still in their early days, and the use cases we’re seeing are just the tip of the iceberg. What could the future hold?

• Tokenized Real Estate: Imagine investing in synthetic tokens representing global real estate markets, all from your phone.
• Synthetic ESG Assets: Tokens tied to sustainability indices or carbon credits could attract socially conscious investors.
• Custom Market Creation: Want a token that tracks the value of “most streamed artists on Spotify”? With synthetics, you can create it.

What we can say for sure is that Synthetic asset tokens are more than just a trend. They’re a fundamental shift in how we think about ownership, liquidity, and financial accessibility. The big question isn’t just what can we do with synthetics now? but rather what haven’t we thought of them yet?

If you’re looking to learn about the basics about Chain Abstraction, then read this article instead.

Technically speaking, chain abstraction means abstracting away the differences between blockchain networks to provide a seamless experience. The goal is to:

1. Simplify User Interaction: Make it easy for users to interact with apps without worrying about which chain they’re on.
2. Enable Interoperability: Allow assets, data, and actions to move freely between chains.
3. Reduce Complexity for Developers: Provide unified tools and APIs to build cross-chain applications.

To achieve chain abstraction, several tools and mechanisms come into play.

Cross-Chain Bridges

Bridges connect different blockchains, enabling the transfer of assets and data between them. Think of them as digital highways. For example, if you want to move your tokens from Ethereum to Binance Smart Chain, a bridge handles the heavy lifting.

• You lock your tokens on the source chain (e.g., Ethereum).
• The bridge mints an equivalent amount of tokens on the destination chain (e.g., Binance Smart Chain).
• When you want to reverse the process, the tokens on the destination chain are burned, and the original tokens are unlocked.

Swaps and Liquidity Protocols

Swapping tokens across chains often requires decentralized exchanges (DEXs) or protocols like Uniswap and SushiSwap. Some advanced protocols like Thorchain take it a step further by supporting native cross-chain swaps without wrapping tokens.

• Liquidity pools on different chains allow you to trade one token for another.
• Cross-chain swap protocols use bridges under the hood to move assets while maintaining a smooth experience.

Interoperability Protocols

Protocols like Polkadot and Cosmos focus on making blockchains inherently interoperable. They create ecosystems where chains can share data and assets natively.

• Relay Chains: Central hubs that coordinate communication between connected blockchains.
• IBC (Inter-Blockchain Communication): A protocol standard used in Cosmos to let chains talk to each other securely. All contracts follow the Interchain Standards (ICS) for the Cosmos network & interchain ecosystem.

Universal Wallets

Tools like Particle Network enable universal account wallets that work across multiple chains. Instead of manually switching between networks, these wallets auto-detect and handle transactions on the right chain.

• Chain detection and configuration happen automatically.
• Transactions are routed to the correct blockchain without user intervention.

RPC Aggregators

Remote Procedure Call (RPC) endpoints are gateways to blockchains. Aggregators like Alchemy and Infura provide a unified interface to interact with multiple blockchains, abstracting away the need to set up individual endpoints.

Chain abstraction is the backbone of many user-friendly crypto applications. Lets see a few examples:

Imagine you’re using a decentralized finance app to swap Ethereum (ETH) for Binance Coin (BNB). Here’s what it looks like from your perspective:

1. You open the app and select ETH as the token to swap.
2. You choose BNB as the token to receive.
3. You click “Swap” and confirm the transaction.

From your perspective, it’s a one-click process. Behind the scenes, multiple tools work together to make it seamless.

1. The app detects that ETH is on Ethereum and BNB is on Binance Smart Chain.
2. A cross-chain bridge locks your ETH on Ethereum and creates a wrapped version on Binance Smart Chain.
3. The app uses a liquidity pool to exchange the wrapped ETH for BNB.
4. Finally, the app transfers BNB to your wallet on Binance Smart Chain.

Here’s a simple Solidity contract for locking tokens on Ethereum and emitting an event to notify a bridge:

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

contract TokenLock {
    event TokenLocked(address indexed user, uint256 amount, string destinationChain);
    mapping(address => uint256) public lockedBalances;
    function lockTokens(uint256 amount, string memory destinationChain) external {
        require(amount > 0, "Amount must be greater than 0");
        // Simulate token lock (e.g., ERC20 transfer to contract)
        lockedBalances[msg.sender] += amount;
        // Emit event for bridge to pick up
        emit TokenLocked(msg.sender, amount, destinationChain);
    }
}

This contract locks tokens on Ethereum and emits an event. A bridge service listens to the event and handles minting on the destination chain.

Lets take another example. Imagine you own an NFT on Ethereum but want to sell it on a Solana-based marketplace. Chain abstraction allows this by bridging the NFT to Solana while ensuring its metadata and ownership history remain intact.

1. The NFT is locked on Ethereum, and a wrapped version is created on Solana.
2. The marketplace interacts with the Solana version, displaying it as if it were native to Solana.
3. When the NFT is sold, the buyer can choose to keep it on Solana or transfer it back to Ethereum.

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

import "@openzeppelin/contracts/token/ERC721/IERC721.sol";
contract NFTBridge {
    event NFTLocked(address indexed user, uint256 tokenId, string destinationChain);
    IERC721 public nftContract;
    constructor(address _nftContract) {
        nftContract = IERC721(_nftContract);
    }
    function lockNFT(uint256 tokenId, string memory destinationChain) external {
        require(nftContract.ownerOf(tokenId) == msg.sender, "Not the owner");
        // Transfer the NFT to the bridge contract
        nftContract.transferFrom(msg.sender, address(this), tokenId);
        // Emit event for bridge service
        emit NFTLocked(msg.sender, tokenId, destinationChain);
    }
}

In this example, the contract locks an NFT and emits an event. The bridge then handles minting the wrapped NFT on the target chain.

How about EVM to Cosmos perhaps?

Here’s an example illustrating how a smart contract on Ethereum can interact with a Cosmos chain using IBC:

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

contract EVMToCosmosBridge {
    event TokenSentToCosmos(address indexed sender, uint256 amount, string cosmosAddress);
    mapping(address => uint256) public balances;
    function sendToCosmos(uint256 amount, string memory cosmosAddress) external {
        require(amount > 0, "Amount must be greater than 0");
        // Simulate token lock (e.g., ERC20 transfer to contract)
        balances[msg.sender] += amount;
        // Emit event for Cosmos chain to pick up
        emit TokenSentToCosmos(msg.sender, amount, cosmosAddress);
    }
}

This contract locks tokens on Ethereum and emits an event for an IBC-compatible relayer to transfer the equivalent tokens to a Cosmos chain.

On the Cosmos side, a module listens for IBC events and handles incoming tokens:

package tokenbridge

import (
    "github.com/cosmos/cosmos-sdk/types"
    "github.com/cosmos/ibc-go/modules/core/04-channel/types"
)
func HandleTokenTransfer(ctx sdk.Context, msg types.MsgRecvPacket) error {
    // Decode the packet
    var data TokenTransferPacketData
    if err := json.Unmarshal(msg.Packet.Data, &data); err != nil {
        return err
    }
    // Mint the tokens for the recipient
    recipient := sdk.AccAddress(data.Recipient)
    amount := sdk.NewCoin(data.Denom, sdk.NewInt(data.Amount))
    if err := MintTokens(ctx, recipient, amount); err != nil {
        return err
    }
    return nil
}
func MintTokens(ctx sdk.Context, recipient sdk.AccAddress, amount sdk.Coin) error {
    // Use the bank module to mint and send tokens
    bankKeeper := GetBankKeeper()
    return bankKeeper.MintCoins(ctx, ModuleName, sdk.NewCoins(amount))
}

This Cosmos module listens for incoming IBC packets, decodes the token transfer details, and mints tokens to the recipient’s address. It complements the Ethereum-side contract to complete the abstraction.

Now, since blockchains are inherently siloed networks, they ideally wouldn’t know to even listen each other. That’s where the bridges and other tools come in. Even with bridges, potential limitations still exists. If the cross-chain bridge experiences congestion, your transaction might be delayed. Additionally, if there’s insufficient liquidity in the liquidity pool for the target token, you might get unfavorable rates or the swap could fail entirely. Lastly, any issues with the smart contracts underlying the bridge or pool could result in transaction errors or delays.
Despite these risks, robust protocols and fallback mechanisms are constantly evolving to mitigate such problems. Scalability can also become a bottleneck as the number of connected chains increases, requiring more resources to maintain performance. Security is another concern, as cross-chain communication introduces additional attack surfaces, such as vulnerabilities in the relay chains or the Inter-Blockchain Communication (IBC) protocol. Addressing these issues is critical for achieving robust and secure interoperability.

There’s a long way to go to achieve true chain abstraction, but we’re on the way already…

Say you want to make an online payment, and instead of just clicking a button, you have to figure out whether the store accepts Visa, Mastercard, or PayPal. Now multiply that headache by 100x, and you’ve got the current state of blockchains. This is where chain abstraction steps in — the fintech equivalent of a universal payment processor but for blockchains. It makes the Web3 world less about mind-numbing details and more about getting stuff done.

Let’s dive into what chain abstraction is, why it’s the hero we need, and how you can build cool things around it.

What Is Chain Abstraction Anyway?

Imagine using Venmo, Apple Pay, or Google Pay without worrying about how they talk to your bank or credit card. That’s chain abstraction for blockchains. It’s all about hiding the complex, nerdy stuff like gas fees, token standards, and wallet types so users and developers can focus on what matters: buying that damn mocha.

It makes interacting with blockchains feel less like coding in the Matrix and more like using Spotify. In short, it’s the magic trick that lets blockchains talk to each other and work together seamlessly.

Why Do We Even Need This?

Blockchains are amazing, but let’s be real: they’re a pain to use. Each chain has its quirks, its rules, and its own language. For instance:

• Ethereum makes you worry about gas fees.
• Solana dazzles you with speed but has its own wallet ecosystem.
• Binance Smart Chain screams, “Hey, we’re cheap!” but you still have to bridge assets manually.

Imagine if every payment app required you to know the bank’s internal workings. You’d delete them in a heartbeat. That’s why we need chain abstraction to fix these headaches:

Simplified User Experience
You don’t care which blockchain an app is on. You just want to use it without Googling, “How to send tokens from Polygon to Arbitrum.”

More Collaboration, Less Competition
Developers can focus on innovation instead of building the same tools for every blockchain.

Onboarding for the Masses
Your grandma won’t care about gas fees or token bridges, but she might use Web3 if it’s as easy as buying something on Amazon.

Think of chain abstraction as turning a messy fintech system into a unified, user-friendly experience:

• No More Wallet Chaos: Whether it’s MetaMask, Phantom, or Keplr, users can use one interface to access all their assets.
• Universal Gas Fees: Users pay with whatever tokens they have, instead of scrambling to swap for ETH, SOL, or MATIC.
• Cross-Chain Transactions Made Easy: Think of it as a blockchain version of Wise for international transfers, but instant and decentralized.

Several blockchain superheroes are already working on this:

LayerZero: The omnichain messaging protocol. Think WhatsApp but for blockchains.

Cosmos (IBC): The OG of chain abstraction, letting blockchains chat like old friends.

Axelar Network: Focused on secure cross-chain communication. Think of it as a blockchain VPN.

Polkadot: Parachains make interoperability look easy, kinda like how Apple devices magically sync.

Superfluid: Abstracts token standards for seamless asset streaming across different chains.

How Does It Work?

Chain abstraction operates like the middleware in your favorite fintech app.

• Middleware Layers: Like Stripe for payments, middleware abstracts the complexity of multi-chain interactions.
• Universal Wallets: These wallets hide the “What chain are you on?” question.
• Gas Fee Abstraction: Imagine paying transaction fees in whatever token you like. No more “insufficient ETH” pop-ups.

So, How to Build on Chain Abstraction

If you’re a builder looking to jump in, here’s your cheat sheet:

Understand the Ecosystem

Spend time with protocols like LayerZero, Cosmos, and Axelar. They’re like the Lego sets for chain abstraction.

Keep Security in Mind

Cross-chain means more doors to lock. Study cryptographic techniques and get comfy with audits.

Use Dev-Friendly Tools

Tools like Axelar SDK or Ethereum’s EIP-4337 are your best friends. Don’t reinvent the wheel.

Think Like a Fintech Startup

Build for scalability and usability. If your app isn’t grandma-friendly, try again.

Some Cool Ideas to Build

Here are some project ideas to flex your developer muscles:

1. Cross-Chain DeFi Superapp
   Think Revolut, but for DeFi. Let users swap, lend, and stake across chains in one interface.
2. Gasless Transactions dApp
   Let users pay fees in their favorite token or abstract gas fees entirely.
3. Blockchain Expedia
   Aggregate dApps across chains so users can search for services like booking flights or investing, without worrying about chains.

Chain abstraction is like the UPI (Unified Payments Interface) of the blockchain world. It’s making blockchains talk to each other, play well together, and be user-friendly for everyone. If Web3 is ever going to rival fintech giants like PayPal or Stripe, this is the way forward.

Developers, this is your moment. Start building tools that make blockchains boring in the best way where the tech just works, and users don’t even notice the chains under the hood. At DripVerse, this is going to be the next frontier to build on. Keep an eye out folks…

Communication is a key in any ecosystem. Now with more cross-chain communication getting sorted using bridges, it’s high time to sort on-chain communications as well. Particularly, referencing of composable smart contract functionalities within the same chain.

On-Chain Immutability

Blockchains in general are isolated networks. Smart contracts are even further isolated in the network given that they record data that are immutable. Any update to their state records a new transaction cumulatively records the updated state. This is known and also creates a historical trail for later review and audit. There’s no problem is this process expect it’s not possible to update the smart contract code itself.

I’ve always believe learning by example is best. Let’s take a look at the usage of ownerOf from IERC721 interface and how it's used to check token ownership for any NFT.

First we import via openzepplin package or you can write your own packaged contract import "@openzeppelin/contracts/token/ERC721/ERC721.sol" . Or if you really want to write your own ERC721 contract, start with importing the interface IERC721 to your contract: import "./IERC721.sol" .

The IERC721.sol contains the function definition:

function ownerOf(uint256 tokenId) external view returns (address owner);

And in ERC721.sol you can find the first override for it as such:

function ownerOf(uint256 tokenId) public view virtual override returns (address) {
        address owner = _ownerOf(tokenId);
        require(owner != address(0), "ERC721: invalid token ID");
        return owner;
}

The function in itself is pretty straightforward. It takes tokenId as input and returns the owner address.

To understand this further, it’s all stored in a mapping:

mapping(uint256 => address) private _owners;

Anyway, regardless of the implementation, this is industry standard at the moment. If in case you’d want to add some conditions or enhance this function in your own contract, you’d need to override this further.

Overriden

Say we want to check for temporary ownership, like a rental ownership, which is time bound. We can not edit the original mapping of course. There’s 2 ways:

1. We add a separate mapping only for the mapping of tokenId and owner to a timestamp.
2. We ignore _owners mapping and write our own mapping replacing it. We'll go with this option cause adding and reading from multiple memory storages will be costlier than having a rogue mapping lying around.

Let’s call our new mapping as _ownership:

struct Owner { 
   address account;
   uint256 expiry;
}
mapping(uint256 => Owner) private _ownership;

Now, we can map the ownership in this accordingly. But we also need to override our ownerOf function:

function ownerOf(uint256 tokenId) public view virtual override returns (address, expiry) {
        Owner _owner = _ownership(tokenId);
        require(_owner.account != address(0), "ERC721: invalid token ID");
        require(_owner.expiry > block.timestamp, "Ownership Expired. No current owner found.");
        return _owner.account;
}

Here, we’re doing a few things. First, we’re checking if the owner account exists and expiry is anytime beyond current block timestamp.

Great, now our existing function ownerOf can serve as the modified version of the existing owner check. So, all the clients can now call this new function of contract and get timestamp enabled ownership check.

However, here’s where things get interesting…

Imported Smart Contracts

The problem in above way is that we would need to burn all tokens from old smart contract and re-mint in new one in order for them to enable expiry in ownership. Which would lead to losing all history of the said tokens. So, how do we deal with this?

Solidity supports importing another smart contract and referring to the functions of it as we established above. We usually use it to extend functionality. For example, we want to add a function to our previous contract which checks ownerOf and rewards a certain amount to them. So, we first need to define it:

import "@openzeppelin/contracts/token/ERC20/IERC20.sol";
// other code bits

IERC20 token;
// ...

token = IERC20(token_address);

Now, in above, token represents our token from previous contract which is imported based on token_address. So, we should be able to do something like token.ownerOf(tokenId) to get the owner of tokenId as shown above. Once we get it, let's say we want to do something like owner_address.send(value) where value is in base token of the chain. This is the most commonly used way to use an external contract. But what would happen if you're to extend an existing function of original contract?

Let’s take our previous example. We want to add expiry to ownerOf. So, we write a new smart contract and a new function to check ownership. Cause we can't override a function of a different contract. We've a new function which can have same name even. But for the sake of sanity, let's use a different name, newOwner() and it looks something like:

contract RentContract {
    struct Owner { 
       address account;
       uint256 expiry;
    }
    mapping(uint256 => Owner) private _ownership;

    function newOwner(uint256 tokenId, address _to, uint256 _expiry) external virtual {
        _ownership[tokenId].account = _to;
        _ownership[tokenId].expiry = _expiry;
    }
    // ...
}

So, what’s happening here is overloading (not really since we’re using a different name for the function. But from a standard perspective, let’s assume it’s the same) which means we’ve defined a second function and mapping to do the exact same thing which is already been done in previous contract where it’s been imported from. This obviously is a waste of memory on-chain but let’s leave that concern for later. So, now, we’ve a second contract, RentContract which has temporary ownership function which we can use. However, what about the client apps which is already pointed to the old contract? The token ownership does not show any changes regardless to whoever else it's rented out via the RentContract .

Shared State

Here’s where the concept of Shared State comes in. Here’s to proposing a shared state system which allows to update the state of original contract if the same state is being dealt with on an extended contract.

So, once this new system is in place, we should be able to reflect the updated state back to our original state thereby retaining backwards compatibility as well as history.

This is the next evolution in smart contract standards which will help with better backwards compatible DApps and protocols.

LFG

Originally posted here.

NFT or Non-Fungible Token, is the latest in the long line of jargon that you might be hearing a lot about recently. So, why should you care and what is it even? Let’s try to understand the origin and thereby the hype around it.

A digital token is just another piece of a smart contract code that’s running somewhere on a particular blockchain. When cryptocurrency came out and everybody started issuing their tokens, we saw a meteoric rise to Digital Tokens or CryptoCurrencies in the form of ICOs (Initial Coin Offerings) that every other project was really into at the time. Most used CryptoCurrencies came on the more popular decentralised networks like Ethereum, in the form of ERC-20s. This gave a widespread knowledge around what cryptocurrencies are and ERC-20 became a common term to be used in analogous to digital tokens wherever specified. However, several improvements on specific use-cases kept happening over time. These improvements are usually referred to as EIPs(Ethereum Improvement Proposals).

One of the most sought after use-cases was ERC-721 or deeds or as more commonly known as Non-Fungible Tokens. NFTs can represent ownership over digital or physical assets. It’s obviously not a new concept. It’s been around since 2014.

• Physical property — houses, unique artwork
• Virtual collectables — unique pictures of kittens, collectable cards
• “Negative value” assets — loans, burdens, and other responsibilities In general, all houses are distinct and no two kittens are alike. NFTs are distinguishable and you must track the ownership of each one separately.

This by itself doesn’t really mean much but when you really think about it, we already have an extremely large scale demand for such unique items. From collectible cards, items, and luxury antiques, our lives revolve around uniqueness. The more unique an item, the more valuable it becomes. It’s the very core of how our economics work and how every valuable item is identified. Now, with ERC-721, we got a way to represent it online and have a very simple way to buy and sell such assets. Of course, it comes with its own set of problems like enormous gas fees which one has to pay for networks like Ethereum. Makes it almost impossible to acquire one or more of these very special NFTs for normal people. The NFT market value tripled in 2020, reaching more than $250 million. During the first quarter of 2021, NFT sales exceeded $2 billion. Plagiarism is another big concern where a true digital identity solution can very well fix it. We’ll take all the issues and possible solutions in perhaps a separate post of its own. I feel it deserves a more in-depth analysis.

Marketplaces

OpenSea

As one of the most commonly referred NFT marketplaces, OpenSea has established it’s dominance in the space. You can practically buy or sell any type of NFT here. The process is as simplified as it can be.

Binance NFT

Binance NFT Marketplace brings together artists, creators, and crypto enthusiasts on a single platform to create and trade top NFTs. The platform features 3 product lines:

• Events: Buy premium and exclusive NFTs created by global leading artists
• Marketplace: Mint, purchase, and bid on NFTs from creators around the world
• Mystery Box: Stand a chance to win rare NFTs in a box full of surprises

Crypto.com NFT

Rarible

Foundation

SuperRare

Atomic Market

Myth Market

BakerySwap

Axie Marketplace

KnownOrigin

MakersPlace

Solana Art

NBA Top Shot

Async Art

Portion

Enjin Marketplace

BakerySwap

Even traditional art giants like Christies are setting up shop around it can step into the modern age.

Variations

Over time, some variations of ERC-721 have emerged as well.

• ERC-1155 which offers semi-fungibility and works over a class of assets instead of particular assets.
• FLOW blockchain provides proof-of-stake consensus. Mostly used by NBA Top Shot.
• Tezos also works on a proof-of-stake based NFT.
• Solana has also started supporting NFTs.

Create your own NFT

A simpler way is to start using one or the platform above mentioned and get started with it. If you want to create your own marketplace or product as such, there’s always a way to do so.

1. Select a DLT network on which you’d like to issue the NFTs on. Preferably one with less transaction fee.
2. Write an NFT smart contract or equivalent in that particular network. Here’s a good getting started point are in OpenZepplin Docs.
3. Make sure there’s an easy interface because mind you, most of your users are really just everyday Joes who just want to purchase as an investment strategy.

So, what all can you use NFTs for?

• Art
• GIFs
• Videos and sports highlights
• Collectibles
• Virtual avatars and video game skins
• Designer sneakers
• Music
• Tweets
• Github Commits

Of course, be wary of where you’re buying these NFTs from. Are they authorised sources or someone broker marketplace who’s just selling via some other marketplace? Are they really the owner or authorised seller of the items. Are they backed by a reputable organisation or foundation? Which blockchain or DLT platform are they using and how much transaction fee is that purchase going to cost you? Also, make sure you’re aware of your country or state’s legalities and taxation procedures. NFTs are also subject to capital gain tax such as any stock you might own.

Originally Published at https://blog.anirudha.dev/what-is-nft.

Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.

At least that’s how the website describes itself. The first time I tried golang was about 3 years ago as a hobby project. However lack of an implementation need and a busy work schedule made my side project obsolete. Of course, you would know what that feels like. Familiar territory. So, when the opportunity rose to write a new service in golang, I absolutely jumped at it.

I’m supposed to build a small web service accepting http connection and storing some data on mongodb. Returns a certain set of result, and so on. Basic CRUD stuff. If you’re not interested in #webdev, I believe this is your stop. If you’re interested however, read on to know about what I used and why. The entire dev cycle from dev to deploy phase.

First of all, why I opted for golang anyway? The service I’m supposed to write needs a highly concurrent persistent api service. It needs to be fast and also easily scalable. We could have gone with python fastapi, but at this stage I just wanted to learn golang.

Setting up Golang

If you’ve finally decided to go ahead with this, let’s do this. Easiest way probably is to just download from the official website and get going. Here’s another article which very nicely explains the setup process. This is ideally for mac OS. In case you’re looking for other OSes, please follow respective guides.

Be sure to setup your GOPATH very properly as this will remain as your common ground for any defined packages installed in your system.

Once done, make sure your console recognises the GOPATH. echo $GOPATH

HTTP Service

I went with fasthttp, which provides high performance, zero memory allocations in hot paths and Up to 10x faster than net/http for a large throughput service. Go provides out of the box http support but for a beginner, it felt much easier to go with a framework, thereby ended up using fiber.

API

Fiber is an Express inspired web framework built on top of Fasthttp, the fastest HTTP engine for Go. Make sure to use Fiber v2. Fiber V2 has a lot of breaking changes to Fiber v1. I had to spend an extra hour just upgrading these breaking changes cause I started with v1.

A simple fiber service can be started using just this:

package main

import "github.com/gofiber/fiber/v2"

func main() {
    app := fiber.New()

    app.Get("/", func(c *fiber.Ctx) error {
        return c.SendString("Hello, World 👋!")
    })

    app.Listen(":3000")
}

You now have a live server running at your http://localhost:3000.

Connect to a DataBase

Next, we need our web service to talk to our web-service. There are quite a few ODM(Object Document Mapper) out there. But given my initial requirement was pretty straightforward, I went the default mongodb golang driver. It’s pretty straightforward to connect an mongodb client:

client, err := mongo.Connect(ctx, options.Client().ApplyURI("mongodb://localhost:27017"))

So, now we got an active db connection going. Ideally, that’s all we would need to create the smallest possible POC(Proof Of Concept) of any web-service you can think of. Obviously, do go through the proper documentation as there are many pitfalls at every stage. Might as well address a few of those on a separate post.

However, to make a production level POC, we need a few more stuff. So, let’s discover a few add-ons to our service:

Logging

Logging is one of the most important aspects in any programming. To see what’s working and where has been the crux of any development really. We sometimes debug using our logs. Specially in production. The easiest and in-built way of printing/logging can be done using fmt or log packages. A small example:

fmt.Print("Printing with fmt")

buf    bytes.Buffer
logger = log.New(&buf, "logger: ", log.Lshortfile)
logger.Printf("Logging with log")

The use log is highly encouraged as compared to fmt. Log is thread safe where as fmt is not. A Logger can be used simultaneously from multiple goroutines; it guarantees to serialize access to the Writer.

log.Fatalf("Fatal err happened:", err)

You can also add fatal logs if in case you would want to flag certain types of logs which might be critical to the application.

Some added advantages of using Fiber is it’s logging module. If you’re on v1, you would need to install the logger package separately, but in v2 it has been made available within v2 itself: "github.com/gofiber/fiber/v2/middleware/logger".

If you need to log each request as and when it comes in, you can add something like this:

app.Use(requestid.New())

​app​.​Use​(​logger​.​New​(logger.​Config​{
	// For more options, see the Config section
  Format​: "${pid} ${locals:requestid} ${status} - ${method} ${path}​\n​"​,
}))

Now, each route visited will come up on your console.

Hot Reloading

Golang is a compiled language, which means unlike Python or NodeJS which are interpreted languages, we need to build it everytime we would want to run it. Ideally we build the project as such: go build . And then we run it like: ./app-name.

However, we can still run the dev version as: go run main.go Or if there’s more than one file: go run *.go

But while development process, we often make changes and would want to check the output without having to restart the go server manually. You can obviously write your own small shell script to detect any file changes on the entire directory and restart go run everytime. If you’re using docker, you can also write the entire go build . and ./app-name process inside the container.

Needed a more robust way, which is provided by this package called fresh. Fresh is a command line tool that builds and (re)starts your web application everytime you save a Go or template file. You can also customise the log color that comes with the default fresh setup. It requires a default runner.conf file. If you want to go with the default options, you don’t even need this file on your project root.

root:              .
tmp_path:          ./tmp
build_name:        runner-build
build_log:         runner-build-errors.log
valid_ext:         .go, .tpl, .tmpl, .html
no_rebuild_ext:    .tpl, .tmpl, .html
ignored:           assets, tmp
build_delay:       600
colors:            1
log_color_main:    cyan
log_color_build:   yellow
log_color_runner:  green
log_color_watcher: magenta
log_color_app:     blue

Now we’ve a complete dev setup done and dusted.

Routing

I’m obsessed with structured code. Everything can be written in a single file and ran but a structured codebase, makes it all the more easier to document, read and later manage it. Thereby, routing is a crucial part of adopting a new framework. Fiber comes with inbuilt route grouping

func main() {
    app := fiber.New()

    api := app.Group("/api", middleware) // /api

    v1 := api.Group("/v1", middleware)   // /api/v1
    v1.Get("/list", handler)             // /api/v1/list
    v1.Get("/user", handler)             // /api/v1/user

    v2 := api.Group("/v2", middleware)   // /api/v2
    v2.Get("/list", handler)             // /api/v2/list
    v2.Get("/user", handler)             // /api/v2/user

    app.Listen(":3000")
}

This can help you in writing a more structured app as such you might need to authenticate only a particular group or log a particular route and so on.

Deployment

Probably best to go with a containerised deployment. We have deployed on Kubernetes — Google Kubernetes Engine (GKE) which only needs an additional Dockerfile.

It’s better to go with a multi-stage docker setup:

FROM golang:1.12-alpine AS build_base

RUN apk add --no-cache git

# Set the Current Working Directory inside the container
WORKDIR /tmp/go-sample-app

# We want to populate the module cache based on the go.{mod,sum} files.
COPY go.mod .
COPY go.sum .

RUN go mod download

COPY . .

# Unit tests
RUN CGO_ENABLED=0 go test -v

# Build the Go app
RUN go build -o ./out/go-sample-app .

# Start fresh from a smaller image
FROM alpine:3.9
RUN apk add ca-certificates

COPY --from=build_base /tmp/go-sample-app/out/go-sample-app /app/go-sample-app

# This container exposes port 8080 to the outside world
EXPOSE 8080

# Run the binary program produced by `go install`
CMD ["/app/go-sample-app"]

A complete guide on dockerising your golang app can be found here and here.

With this we’ve now a deployed version of our golang app. Connect that GKE ip to your preferred DNS provider and share the link. Feel free to leave a link of you first golang app in the comments. Would love to see what everyone is working on.

If you have a different view on some of the stack used or talked here, feel free to add your thoughts. We’re all learning and would love to see the more popular frameworks and best practices in use.

Cheers and until next time…

(Originally published here)
Hope it was helpful and do let me know what else you would love reading more about.

About time you’ve heard about Blockchain and want to a dig into the development phases of it. Respect that. Though on your first few google searches you’ve probably got about a million of tutorials, articles and resources and now you’re just about on the verge of giving up on it and moving on. Can’t blame you. But before you gave up forever, you somehow seem to have stumbled across just about one more article and believe it or not, you’ve chosen wisely.

Clearly blockchain technology has lots to offer and way too many pathways to get started with. We’re going to take the journey from every possible way and hopefully, one of these would pick you right up from where you stand today.
Word of the wise, if you’re new to development in general and have no clue as to what blockchain is, we recommend to read a few introductory articles before coming back here.

Blockchain is a decentralised network and a distributed database.

It started off as being public only, with Bitcoin and Ethereum bringing up the names to the masses. Eventually, private blockchains like Hyperledger also gained traction given enterprises heavily adopting it throughout their processes. Now, there’s all sorts of classifications based on data structure or how consensus is formed.

So, where to get started from? Well, that largely depends on your area of interest really. Here’s a few areas to get started with:

Smart Contract Development

If you’re a programmer, this is one of the easiest to get started with. Smart Contracts are just pieces of codes that run on the blockchain. In that way, we can classify a Hello World program also as smart contract. Of course, it’s neither smart not a contract in this case.

“A smart contract is a set of promises, specified in digital form, including protocols within which the parties perform on these promises.”

— Nick Szabo

Every blockchain has it’s own language or syntax to write smart contract on. Ethereum uses Solidity, Hyperledger uses Chaincode, Cardano uses Plutus, Aion uses Java and so on.

Here’s an example smart contract in Solidity. This is a simple smart contract designed to store a certain value, in this case, storedData.

pragma solidity ^0.4.0;

contract SimpleStorage {
    uint storedData;
    function set(uint x) public {
        storedData = x;
    }
    function get() public constant returns (uint) {
        return storedData;
    }
}

There are two functions, set() and get(). get() will get whatever value is stored and set() takes a parameter x and stores it in the blockchain.
Pretty straightforward, right?

Here’s a more complex one:

pragma solidity ^0.4.19;

contract Escrow {

    address public buyer;
    address public seller;
    address public arbiter;
    address owner;

    function Escrow(address _seller, address _arbiter) {
        buyer = msg.sender;
        seller = _seller;
        arbiter = _arbiter;
    }

    modifier onlyOwner {
        require(msg.sender == owner);
        _;
    }

    function payoutToSeller() {
        if(msg.sender == buyer || msg.sender == arbiter) {
            seller.transfer(this.balance);
        }
    }

    function refundToBuyer() {
        if(msg.sender == seller || msg.sender == arbiter) {
            buyer.transfer(this.balance);
        }
    }

    function getBalance() constant returns (uint) {
        return this.balance;
    }

    function setSeller(address _seller) public {
        seller = _seller;
    }

    function setArbiter(address _arbiter) public {
        arbiter = _arbiter;
    }

    function getSeller() public constant returns (address) {
        return seller;
    }

    function getArbiter() public constant returns (address) {
        return arbiter;
    }

}

This is an Escrow smart contract as the name suggests. We’ve defined a buyer, seller and an arbiter. The arbiter usually is the smart contract address itself, because the entire point of blockchain is to remove middlemen (or so they said). Learn more about smart contracts in this article.

Ideally, we use smart contracts to write conditional statements which might help solve interoperability issues or accountability related stuff. But of course, if you just want to write a summation smart contract, that’s cool too.

Consensus Algorithm

So, once you know how to input and output data to blockchain, the next thing is to get the data transaction approved on chain.

A consensus mechanism is a fault-tolerant mechanism that is used in computer and blockchain systems to achieve the necessary agreement on a single data value or a single state of the network among distributed processes or multi-agent systems.

Consensus is important to maintain the decentralised nature of the network. Before data can be written to the distributed database, a given number of nodes/entities has to agree over the validity of the transaction. If majority agrees, the data is recorded, otherwise discarded.

There are several consensus mechanisms out there. Some of the popular ones are POW, POS, POA, etc. So, if you’re into deep algorithms and research, this is an extremely exciting work. Read more about various consensus mechanisms in blockchain here.
If you see a new way to validate a transaction or data, by which you can achieve synchronicity and data sanity, that can be a possible consensus mechanism. Once you’ve formularised what it does, start working on how it does it. The mathematical algorithm basically. To define the proof that you just created. These sometimes takes years to formalise. Post it on popular cryptographic forums and seek contribution help from fellow mathematicians.

Library Development

If you are pretty advanced with programming languages and want to integrate your native language with smart contracts, then library development is the right place to get started with.

Since the smart contracts are usually in the blockchain’s native language, it’s very difficult for day-to-day work to transpile every single piece of code explicity and write a mirror code to execute the same. Most popular blockchains provide support for common languages like python, javascript, golang, etc.

Ethereum has web3.js and web3.py to help javascript and python developers easily interact with blockchain. You can start writing in your native language as well, for which the Ethereum Foundation might not have written already. Of course, if your library is good enough, they might ending up adding it to their official repo.

Protocols Development

Protocols form the base layer on top of which decentralised network work. There is vast range of protocols and we need to define our scope of work to which protocols we might be referring to.

Coming from traditional programming background, you must be aware of web protocols such as HTTP (Hypertext Transfer Protocol) or TCP/IP (Transmission Control Protocol/Internet Protocol). The idea with these protocols were to provide a governance layer or setup “some rules” over how and what type of data is transmitted. Similarly we can write our own protocols for the decentralised network about the way of transactions, the form data, mode of transmission, the duration of open channels and so on. Given the use-case, protocols can form the very base layer on top of which modern decentralised applications are built.

To develop protocols, you can start with writing simple stuff like and gradually write more complex logic. Some example protocols to get started with are listed here.
Develop a protocol for:

1. End-to-end encrypted communication.
2. Interoperability amongst various blockchains.
3. Token exchange.
4. Track a product life-cycle.
5. Maintain user access

..the list goes on. But now you have a general idea of where to get started with. Read more here about protocols.

Network

So, you’re coming from OS and Networking background. Since blockchain is a basic level decentralised network, it might be a great place to start.

You might recall some basic level network topologies such as star, mesh, ring, tree, bus, etc. Well, decentralised networks are not much different as far as network architecture goes on. Various blockchains have experimented with different forms of it at various levels to achieve desired results. The key idea is to have a secure connection amongst the nodes with least possible latency. A complete loss-less connection is still far fetched idea so you’ve a lot of places to contribute here.
Side chains sometimes form completely different topologies to achieve results at faster processing. Mostly though connects through a p2p network so there’s no brokers in between.

A good place to start with network development would be to read the whitepapers of various blockchains and figure out what everyone’s doing and probably you will able to plug in your thoughts in one or more of them to come up with something original. Do not be afraid to experiment.
IIT Kanpur, IIT Chennai, IISC Bengaluru have research centres working actively on this area where you can also join as research fellowship programs and complete your thesis. Our community platforms are also a good way to work with others researching around the same.

Infrastructure

You like infrastructure development. You’ve probably worked on micro-services and monoliths and now looking to find your place in blockchain ecosystem.

Unlike traditional architecture, the infrastructure of decentralised system has nothing to do with the dapps at all. All your infra knowledge will be put together to work on node clusters to setup a robust scalable model of the decentralised network. Think about how you can run nodes from the largest of VMs or docker or kuberenetes setup to the smallest of microchips as an Arduino Uno or Raspberry Pi 2. Ideally, a blockchain database becomes way to large for a small Raspberry Pi to handle. But hey, that’s where your knowledge comes in. Think about how to make it work. IOTA is one the DLTs which nodes can run on Raspberry Pi. So, maybe figure out a way to design a lightweight node to make to run on Raspberry Pi? Who knows, you might crack it.

Another interesting arena in this regard is to play around with data storage infrastructures. Data storage is still over-blotted for a blockchain being linked list and all. Maybe experiment on how you can keep the same structural integrity and yet make it more scalable.

Token Development/Crypto-Economics

Tokens are a crucial part of public blockchains. So, if you’re planning to develop your application to run on a public blockchain, you might also would want to develop your own token.

You can obviously use the native token of the blockchain itself, such as Ethers if you’re using Ethereum blockchain, Lumens if you’re on Stellar blockchain and so on. But with your own token, you can control the output, exchange mechanisms, trade routes, use-cases, minting or creating new tokens rate, and several other factors. Ethereum offers a wide range of token standards to develop your tokens on. Most popular amongst which is ERC20.

This also involves a good understanding of smart contracts, but more focus would be on financial side. Here’s a sample ERC20 smart contract that you can study to get started with.

// SPDX-License-Identifier: MIT

pragma solidity ^0.6.0;

import "../../GSN/Context.sol";
import "./IERC20.sol";
import "../../math/SafeMath.sol";
import "../../utils/Address.sol";

/**
 * @dev Implementation of the {IERC20} interface.
 *
 * This implementation is agnostic to the way tokens are created. This means
 * that a supply mechanism has to be added in a derived contract using {_mint}.
 * For a generic mechanism see {ERC20PresetMinterPauser}.
 *
 * TIP: For a detailed writeup see our guide
 * https://forum.zeppelin.solutions/t/how-to-implement-erc20-supply-mechanisms/226[How
 * to implement supply mechanisms].
 *
 * We have followed general OpenZeppelin guidelines: functions revert instead
 * of returning `false` on failure. This behavior is nonetheless conventional
 * and does not conflict with the expectations of ERC20 applications.
 *
 * Additionally, an {Approval} event is emitted on calls to {transferFrom}.
 * This allows applications to reconstruct the allowance for all accounts just
 * by listening to said events. Other implementations of the EIP may not emit
 * these events, as it isn't required by the specification.
 *
 * Finally, the non-standard {decreaseAllowance} and {increaseAllowance}
 * functions have been added to mitigate the well-known issues around setting
 * allowances. See {IERC20-approve}.
 */
contract ERC20 is Context, IERC20 {
    using SafeMath for uint256;
    using Address for address;

    mapping (address => uint256) private _balances;

    mapping (address => mapping (address => uint256)) private _allowances;

    uint256 private _totalSupply;

    string private _name;
    string private _symbol;
    uint8 private _decimals;

    /**
     * @dev Sets the values for {name} and {symbol}, initializes {decimals} with
     * a default value of 18.
     *
     * To select a different value for {decimals}, use {_setupDecimals}.
     *
     * All three of these values are immutable: they can only be set once during
     * construction.
     */
    constructor (string memory name, string memory symbol) public {
        _name = name;
        _symbol = symbol;
        _decimals = 18;
    }

    /**
     * @dev Returns the name of the token.
     */
    function name() public view returns (string memory) {
        return _name;
    }

    /**
     * @dev Returns the symbol of the token, usually a shorter version of the
     * name.
     */
    function symbol() public view returns (string memory) {
        return _symbol;
    }

    /**
     * @dev Returns the number of decimals used to get its user representation.
     * For example, if `decimals` equals `2`, a balance of `505` tokens should
     * be displayed to a user as `5,05` (`505 / 10 ** 2`).
     *
     * Tokens usually opt for a value of 18, imitating the relationship between
     * Ether and Wei. This is the value {ERC20} uses, unless {_setupDecimals} is
     * called.
     *
     * NOTE: This information is only used for _display_ purposes: it in
     * no way affects any of the arithmetic of the contract, including
     * {IERC20-balanceOf} and {IERC20-transfer}.
     */
    function decimals() public view returns (uint8) {
        return _decimals;
    }

    /**
     * @dev See {IERC20-totalSupply}.
     */
    function totalSupply() public view override returns (uint256) {
        return _totalSupply;
    }

    /**
     * @dev See {IERC20-balanceOf}.
     */
    function balanceOf(address account) public view override returns (uint256) {
        return _balances[account];
    }

    /**
     * @dev See {IERC20-transfer}.
     *
     * Requirements:
     *
     * - `recipient` cannot be the zero address.
     * - the caller must have a balance of at least `amount`.
     */
    function transfer(address recipient, uint256 amount) public virtual override returns (bool) {
        _transfer(_msgSender(), recipient, amount);
        return true;
    }

    /**
     * @dev See {IERC20-allowance}.
     */
    function allowance(address owner, address spender) public view virtual override returns (uint256) {
        return _allowances[owner][spender];
    }

    /**
     * @dev See {IERC20-approve}.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     */
    function approve(address spender, uint256 amount) public virtual override returns (bool) {
        _approve(_msgSender(), spender, amount);
        return true;
    }

    /**
     * @dev See {IERC20-transferFrom}.
     *
     * Emits an {Approval} event indicating the updated allowance. This is not
     * required by the EIP. See the note at the beginning of {ERC20};
     *
     * Requirements:
     * - `sender` and `recipient` cannot be the zero address.
     * - `sender` must have a balance of at least `amount`.
     * - the caller must have allowance for ``sender``'s tokens of at least
     * `amount`.
     */
    function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {
        _transfer(sender, recipient, amount);
        _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "ERC20: transfer amount exceeds allowance"));
        return true;
    }

    /**
     * @dev Atomically increases the allowance granted to `spender` by the caller.
     *
     * This is an alternative to {approve} that can be used as a mitigation for
     * problems described in {IERC20-approve}.
     *
     * Emits an {Approval} event indicating the updated allowance.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     */
    function increaseAllowance(address spender, uint256 addedValue) public virtual returns (bool) {
        _approve(_msgSender(), spender, _allowances[_msgSender()][spender].add(addedValue));
        return true;
    }

    /**
     * @dev Atomically decreases the allowance granted to `spender` by the caller.
     *
     * This is an alternative to {approve} that can be used as a mitigation for
     * problems described in {IERC20-approve}.
     *
     * Emits an {Approval} event indicating the updated allowance.
     *
     * Requirements:
     *
     * - `spender` cannot be the zero address.
     * - `spender` must have allowance for the caller of at least
     * `subtractedValue`.
     */
    function decreaseAllowance(address spender, uint256 subtractedValue) public virtual returns (bool) {
        _approve(_msgSender(), spender, _allowances[_msgSender()][spender].sub(subtractedValue, "ERC20: decreased allowance below zero"));
        return true;
    }

    /**
     * @dev Moves tokens `amount` from `sender` to `recipient`.
     *
     * This is internal function is equivalent to {transfer}, and can be used to
     * e.g. implement automatic token fees, slashing mechanisms, etc.
     *
     * Emits a {Transfer} event.
     *
     * Requirements:
     *
     * - `sender` cannot be the zero address.
     * - `recipient` cannot be the zero address.
     * - `sender` must have a balance of at least `amount`.
     */
    function _transfer(address sender, address recipient, uint256 amount) internal virtual {
        require(sender != address(0), "ERC20: transfer from the zero address");
        require(recipient != address(0), "ERC20: transfer to the zero address");

        _beforeTokenTransfer(sender, recipient, amount);

        _balances[sender] = _balances[sender].sub(amount, "ERC20: transfer amount exceeds balance");
        _balances[recipient] = _balances[recipient].add(amount);
        emit Transfer(sender, recipient, amount);
    }

    /** @dev Creates `amount` tokens and assigns them to `account`, increasing
     * the total supply.
     *
     * Emits a {Transfer} event with `from` set to the zero address.
     *
     * Requirements
     *
     * - `to` cannot be the zero address.
     */
    function _mint(address account, uint256 amount) internal virtual {
        require(account != address(0), "ERC20: mint to the zero address");

        _beforeTokenTransfer(address(0), account, amount);

        _totalSupply = _totalSupply.add(amount);
        _balances[account] = _balances[account].add(amount);
        emit Transfer(address(0), account, amount);
    }

    /**
     * @dev Destroys `amount` tokens from `account`, reducing the
     * total supply.
     *
     * Emits a {Transfer} event with `to` set to the zero address.
     *
     * Requirements
     *
     * - `account` cannot be the zero address.
     * - `account` must have at least `amount` tokens.
     */
    function _burn(address account, uint256 amount) internal virtual {
        require(account != address(0), "ERC20: burn from the zero address");

        _beforeTokenTransfer(account, address(0), amount);

        _balances[account] = _balances[account].sub(amount, "ERC20: burn amount exceeds balance");
        _totalSupply = _totalSupply.sub(amount);
        emit Transfer(account, address(0), amount);
    }

    /**
     * @dev Sets `amount` as the allowance of `spender` over the `owner`s tokens.
     *
     * This is internal function is equivalent to `approve`, and can be used to
     * e.g. set automatic allowances for certain subsystems, etc.
     *
     * Emits an {Approval} event.
     *
     * Requirements:
     *
     * - `owner` cannot be the zero address.
     * - `spender` cannot be the zero address.
     */
    function _approve(address owner, address spender, uint256 amount) internal virtual {
        require(owner != address(0), "ERC20: approve from the zero address");
        require(spender != address(0), "ERC20: approve to the zero address");

        _allowances[owner][spender] = amount;
        emit Approval(owner, spender, amount);
    }

    /**
     * @dev Sets {decimals} to a value other than the default one of 18.
     *
     * WARNING: This function should only be called from the constructor. Most
     * applications that interact with token contracts will not expect
     * {decimals} to ever change, and may work incorrectly if it does.
     */
    function _setupDecimals(uint8 decimals_) internal {
        _decimals = decimals_;
    }

    /**
     * @dev Hook that is called before any transfer of tokens. This includes
     * minting and burning.
     *
     * Calling conditions:
     *
     * - when `from` and `to` are both non-zero, `amount` of ``from``'s tokens
     * will be to transferred to `to`.
     * - when `from` is zero, `amount` tokens will be minted for `to`.
     * - when `to` is zero, `amount` of ``from``'s tokens will be burned.
     * - `from` and `to` are never both zero.
     *
     * To learn more about hooks, head to xref:ROOT:extending-contracts.adoc#using-hooks[Using Hooks].
     */
    function _beforeTokenTransfer(address from, address to, uint256 amount) internal virtual { }
}

Now, you would have noticed some basic configurations that you’ll have to do while deploying this smart contract, like token name, symbol, total supply and so on.

You can explore other Ethereum token standards here usually termed as Ethereum Improvement Proposals (EIPs).

DAPPs

Ideally, I would have put this on top. You can just forget about how all blockchain works and just want to develop an application that sits on top of a decentralised network and work with tokens. Maybe create the next Cryptokitties.

All you would need for this is some frontend development knowledge, with frameworks like ReactJs, VueJs, AngularJs, EmberJs and so on. Ideally for a dapp, you might not need any backend at all.

Just integrate web3.js library to connect directly with blockchain via MetaMask chrome plugin or Infura apis. You might also would like to explore to connect via an external Blockchain Oracle service provider, such as Sentinel.

This is obviously an ever growing field so do not get overwhelmed if tomorrow you hear something entirely new in blockchain technology to work on.

Here’s some more of our curated resources for you to get started with.

Blockchained India is also doing a 100 days coding program. If you’re interested to be a participant in our program, click here and be a part of this amazing opportunity to enhance your skills and knowledge.

Also, if you liked this article, show some appreciation by giving claps!!

And don’t forget to be a part of Blockchained India community!

TELEGRAM | TWITTER | LINKEDIN | FACEBOOK GROUP | FACEBOOK PAGE

Getting started with Blockchain Development was originally published in Blockchained India on Medium, where people are continuing the conversation by highlighting and responding to this story.

One of the ultimate buzz words of the decade, blockchain has indefinitely altered not only the data and security industry, but across multiple domains. Often, the amazing distributed database, powered by a decentralised network, incentivised by a sophisticated cryptocurrency or token designed for the network is very much difficult to understand or build for that matter. So, here, we take a shot at Building Your Own Blockchain.

What is a Blockchain?

A blockchain, is a growing list of records, called blocks, which are linked using cryptography. Each block contains a cryptographic hash of the previous block, a timestamp, and transaction data (generally represented as a merkle tree root hash).
For all intend and purpose, we’ll keep it simple and focus on proof of work consensus based public blockchain.

By design, a blockchain is resistant to modification of the data, hence called immutable. It is “an open, distributed ledger that can record transactions between two parties efficiently and in a verifiable and permanent way”. For use as a distributed ledger, a blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating new blocks. Once recorded, the data in any given block cannot be altered retroactively without alteration of all subsequent blocks, which requires consensus of the network majority. Although blockchain records are not unalterable, blockchains may be considered secure by design and exemplify a distributed computing system with high Byzantine fault tolerance. Decentralised consensus has therefore been claimed with a blockchain. Read more about blockchain introduction here and here.

Public vs Permissioned vs Private

Blockchain can be primarily categorised into three types- public, permissioned and private.

Public blockchains are completely open data blockchain networks where all the data and signatures are put up on.

Permissioned blockchains are open data public blockchain networks but the validators or miners to the network are authorised or voted on.

Private blockchains are closed data blockchain networks, where they might further be divided to a private organisational blockchain network or a consortium of private organisations.

Each type of blockchain has there own pros and cons depending on the type of the task to be done.

Properties of Blockchain

Blockchain is simply an open distributed record of immutable data. So, it’s worth saying the properties of blockchain can be defined as follows:

1. Decentralised Network.
2. Open transparent distributed database.
3. Immutable Data.
4. Consensus.

Read more about the properties of blockchain here.

Consensus

One of the most important things in a decentralised network is how to agree on the data distributed amongst all to reach a consensus. To solve this, various algorithms have been introduced, most famous of which is Proof of Work, which is most widely used currently.
We won’t be covering various consensus algorithms at the moment.

All we’ve to do is generate a block, it’s hash as the signature hash and attach to a previous block.
So first, let’s create a new block with these keys:

1. index: Shows the index of the blockchain
2. timestamp: The exact timestamp of the block writing. Very critical while resolving conflicts.
3. transactions: The transactions in the block.
4. signature: The Proof of Work generates a unique hash. Let’s call it signature as it showcases the unique signature of the block.
5. previous_block_hash: The hash of the previous block. This is used to create the linked list.

Alright, now that we’ve defined a block, let’s go a step further to define a transaction data. Ideally, a lot more data is supposed to be there, but for simplicity of understanding, let’s have the following data in a transaction:

1. sender: The address of the sender.
2. recipient: The address of the recipient.
3. amount: The amount to be sent. (Please note that we have not defined any unit for this amount yet. The unit will defined by the token supporting the blockchain.)

Awesome! Now, we’ve defined all the data. Let’s start our blockchain node.

Running a node

Let’s try by creating a simple node (centralised) at this point which will help other nodes to connect to later on. Refer to the blockchain.py file.

Now, we create a small Flask app to run our blockchain from web browser. It’s not required but makes the interactions easier via our blockchain enabled APIs.

Find the entire code on the github repo here.

Run the code by running:
python blockchain.py
and go to http://localhost:8000 or replace the port 8000 with your own port.

At this point, you should be seeing something like this.
So, everything seems to be working.

Open the chain url by clicking on the link given.
You should be see the genesis block generated with the data as explained above.

Open a new terminal window/tab and run another on another port:
python blockchain.py -p 8001
Repeat the same operation as above to test the exclusiveness of the nodes.

Mining

Mining, in the context of blockchain technology, is the process of adding transactions to the large distributed public ledger of existing transactions, known as the blockchain.
Below is shown how a typical mining/validation works.

So, let’s create a few new blocks and add to our blockchain.
Run the url /mine(assuming you’re running on 8000 port or replace the url with your your port) on your browser.

Now, head back to /chain and view all the new blocks that we just mined.

At this stage, we’ve successfully created a blockchain, mined new blocks and added to our blockchain. But, our different ports are not synced with each other. We’re yet to define our consensus algorithm and sync all the nodes.
We’ll be covering these on the next article series.

BYOB — Build Your Own Blockchain was originally published in Blockchained India on Medium, where people are continuing the conversation by highlighting and responding to this story.

A most widely generic definition can be:

Any piece of information, however small or intricate, vague or clear, story or not, if given a proper structure and category that be meaningful in one way or other to oneself, can be termed as data.

So, in a way any piece of information can be termed as data. Interesting! I never knew that me, eating an apple instead of banana can be a meaningful piece of information to be classified as data. But it actually is. To the right person, in the right hands, any piece of information that they can monetise on is actually data. How, do you ask? Well, if an apple selling store knew about this, they would know that I prefer apple over banana and they would then try to sell more apples or other product of apples, perhaps Apple Juice or something. On the contrary if a banana store came around it, they would probably ask me what’s wrong and try to fix it so as to not lose a potential customer.
Of course, for as small a data set as a single person, nobody would bother. But say that data isn’t just of mine. It’s of thousands of people in the same neighbourhood. Then, it might catch their eye and they would react. Cause then they would need this data to get their business running. And they would be willing to pay to get such data. Maybe pay 1% of their rest 99% in profit from targeted marketing and sales. Believe me, it is already a thing. Which links to my next point: Currency.

Who doesn’t know what currency is? But do we really understand it? We take a dollar or rupee bill, and think it holds some value when actually, it doesn’t. If it’s unregistered, somewhere or other it’s not a legal form of currency note. Some bank or institution has to maintain a clear ledger of data as to where that particular note went through to reach your hands. If they do, that note is valid. Otherwise, it becomes something we term as black money and liable to get yourself a heavy charge for carrying illegal money. But, banking ledgers being controlled at a particular location or set defined books became easy to access or manipulate. One could copy all of the books and in process, insert their data in between the rest, which could eventually make their money legal. Eventually, the banks got smarter. They moved from books to storage devices and softwares. But now, it became even easier to randomly insert data. And copy data into new data. Now, the struggle only remained as a tug of war between who knew more technology to get ahead of the other.

Technology really just means the science of craft. But we’ve taken it so closely to gadgets, that for us, technology merely means catching a Pokemon with a ball by swiping up, in our phone. Well, technically, it ain’t wrong. Just incomplete. We live in a world surrounded by gadgets and apps. Alexa, Uber, Instagram, WhatsApp, Facebook, Twitter, Google Home, even cars now, Tesla. How can the meaning not change. Technological advancements has been tremendous in the last few years. Technology has influenced every part of our lives. From managing data to transferring currency. We don’t go to the banks anymore to fill out a form and transfer money. We just use Paypal or Paytm. Excel sheets have paved ways to databases, and then distributed databases to enhance the further security and accessibility of data. Yes, the social websites that we visit to do give us a lot of exposure. But they also clearly sell out your data to potential buyers. Data encourages currency. But technology really is the one that supports it. But the more important question is, do you really care? If you did, you would lived a monk life so far. But you don’t. You want people to show you ads of that camera, that you viewed a hundred times but can’t afford. If there’s ever an offer or better price somewhere else or newer bran, you’ll come to know about it. Isn’t that great? Of course it is. You may cower that you might not want to know about some other related item which even might get inappropriate sometime and I totally agree to it. But how will the systems learn and adapt to your needs and requirements if they are fed in with huge amounts of data on the same. Are they really breaching our privacy? Do we really need to shut them down. After-all, it’s our inability to read through the lengthy agreements of usage. We are in so hurry to get on-board the show, that we are ready to give it all up.
Being said that, obviously we would want a control over own data. Not all of us want to know the nearest restaurant or asked to check-in every time we are near one. And I totally am on the same page with that as well. We must have control over our data. But at the same time be aware of the advantages that data can bring to us.

Technology as helped us use our data in the form of currency today. There are various data marketplaces even, where companies buy and sell data legally. You can also utilise such marketplaces to monetise your data, the way you would want it to be used.

Put up your thoughts as to what you think the world should move on to the next phase of data privacy and sharing. Is it ok to come up on WikiLeaks and not on google or do we really want the control and are willing to spend time and give up the online social life to get free of that.