Sellerant

sellerant

You’ve probably heard that Generative AI has demonstrated the potential to disrupt a huge number of industries and jobs — and web3 is no exception. But how well can ChatGPT create smart contracts? Can using ChatGPT to code smart contracts make you a 10x developer? In this article, we’ll try it out and see. We’ll walk through writing and deploying an Ethereum smart contract using , , and … and we will ask ChatGPT for instructions on how to do everything from the code to the deployment. MetaMask Infura Truffle The goal is to see if we can break down the task of creating a smart contract into a set of simple prompts. Ideally, ChatGPT can parse those prompts and give good (and accurate) answers to them, making us a faster, and better, developer. Let’s see what we can do! A Note on Accuracy ChatGPT is a Large Language Model (LLM) extremely proficient in explaining blockchain concepts, providing advice, and even generating code snippets related to web3 development. However, keep in mind that some of the code or answers it generates may be partially or completely incorrect. Access to ChatGPT does not remove the need to know the basics of blockchain development. However, even a beginner can use artificial intelligence to dramatically increase productivity. The second point to note is that the free, public version of ChatGPT isn’t very aware of events, updates, and practices that have emerged after 2021. This can be an issue in a field such as web3 development, where everything is improving and changing at a breakneck pace. However, it is possible to get good answers if something that you’re asking is fundamental and has been stable over the years (for instance, Truffle and Solidity). Create an Escrow Contract with Truffle and ChatGPT To see what ChatGPT can do, we’re going to ask it to create an escrow smart contract that allows a buyer and a seller to exchange money, and we’ll have ChatGPT establish an arbiter to resolve disputes. Let’s see what Generative AI can do! Step 1: Install MetaMask First we need to set up a wallet. We’ll use wallet — the most popular Ethereum option — and add the Sepolia test network. MetaMask is secure and easy to use. MetaMask You can download the MetaMask extension for your browser . Then, just install and set up the wallet. You’ll be given a “secret phrase” — keep this private and safe! Never store it anywhere public. here Note: If you need background or a primer on web3, check out this on learning web3/smart contracts/Solidity. previous article I wrote Next, click on the “Network” tab in the top-right. Click on the option to show test networks. You should now see the Sepolia test network in the dropdown. Select that. Step 2: Get SepoliaETH To deploy and interact with a smart contract, you need ETH. Since we are using the Sepolia test network, we’ll need to get some Sepolia test ETH. Don’t worry — it’s free! You can obtain free SepoliaETH from Infura’s recently released faucet . This faucet gives up to 0.5 SepoliaETH each day for free. here Step 3: Install Node and NPM In order to build an escrow system using Truffle, we will need . Node and NPM To check to see if it’s installed, run: $ node -v You should see the Node version. Step 4: Sign Up for Infura Infura is an RPC provider. They provide easy API-based access to everything we need to connect to—and work with—the Ethereum blockchain (and quite a few others). Sign up for a free account . Then go to the and select Create New Key. here dashboard Choose Web3 API as the network and name the new key Escrow (though you can name it whatever you want). Click Create, and Infura will generate an API key. This key is what you need to access your RPC endpoint. For our purposes, we just want the Sepolia endpoint. https://sepolia.infura.io/v3/<your API key> Step 5: Create the Node Project Next we need to create our Node project and then complete our setup with any necessary packages. $ mkdir escrow && cd escrow
$ npm init -y To deploy and test our contract, we’ll use Truffle. Truffle is a suite of tools that give you everything you need to develop, test, and deploy smart contracts. Let’s install it: $ npm install —save truffle You can create a project skeleton using Truffle by running: $ npx truffle init To check that everything ran correctly: $ npx truffle test We now have Truffle successfully configured. Let’s next install the OpenZeppelin contracts package. This package will give us access to a few more helpful functionalities that we may require. $ npm install @openzeppelin/contracts We’re almost done with the setup! Next we have to allow MetaMask and Truffle to work together. We need Truffle to be able to sign transactions, pay gas, etc. For this we’ll use . Install it: hdwalletprovider $ npm install @truffle/hdwallet-provider And finally, let’s use to keep our wallet information secure. dotenv $ npm install dotenv Step 6: Sign Up for ChatGPT We won’t be writing the escrow smart contract code from scratch. Instead, we’ll see what ChatGPT can do. In order to use ChatGPT, with OpenAI. sign up for a free account Once you’ve signed up for an account, visit . You should see an interface that looks something like this: this page Step 7: Create the Escrow Contract Next, we’ll have ChatGPT create an extremely simple escrow contract that allows a buyer and a seller to exchange a certain amount of money, and an arbiter to resolve disputes. Let’s use the following prompt in ChatGPT. `As an expert smart contract developer, create a smart contract using Solidity that implements an escrow. There will be three parties: the buyer, the seller, and the arbiter. The constructor will set the buyer, seller, and arbiter. It will also set the value which will be equal to the amount sent to the constructor. There will be two functions. The first function allows the buyer or the arbiter to release funds to the seller. The second function allows the buyer or the arbiter to refund the amount back to the buyer. Implement any other functions that you may think are relevant.` Note the “As an expert smart contract developer” beginning of the prompt. This type of “role playing” with ChatGPT works very well. Now ChatGPT will generate a unique response for you. And this response will change every time. So you may not get the same output that is shown below, but it should be something similar. Sure, here's an example implementation of an escrow smart contract in Solidity: pragma solidity ^0.8.0; contract Escrow {
address payable public buyer;
address payable public seller;
address public arbiter;
uint public value;
bool public released;
bool public refunded; constructor(address payable _buyer, address payable _seller, address _arbiter) {
    buyer = _buyer;
    seller = _seller;
    arbiter = _arbiter;
    value = msg.value;
}

function release() public {
    require(!released, "Funds have already been released.");
    require(msg.sender == buyer || msg.sender == arbiter, "Only buyer or arbiter can release funds.");
    released = true;
    seller.transfer(value);
}

function refund() public {
    require(!refunded, "Funds have already been refunded.");
    require(msg.sender == buyer || msg.sender == arbiter, "Only buyer or arbiter can refund funds.");
    refunded = true;
    buyer.transfer(value);
}

function getBalance() public view returns (uint) {
    return address(this).balance;
}

function setArbiter(address _arbiter) public {
    require(msg.sender == arbiter, "Only arbiter can set arbiter.");
    arbiter = _arbiter;
}

function setSeller(address payable _seller) public {
    require(msg.sender == seller, "Only seller can set seller.");
    seller = _seller;
} } The `Escrow` contract has a constructor that takes three arguments: the addresses of the buyer, seller, and arbiter, and sets the `value` equal to the amount sent to the constructor.

The `release()` function allows the buyer or the arbiter to release the funds to the seller. It first checks that the funds haven't already been released, and that the caller is either the buyer or the arbiter. If both conditions are met, the `released` variable is set to `true`, and the `value` is transferred to the seller's address.

The `refund()` function allows the buyer or the arbiter to refund the funds back to the buyer. It first checks that the funds haven't already been refunded, and that the caller is either the buyer or the arbiter. If both conditions are met, the `refunded` variable is set to `true`, and the `value` is transferred back to the buyer's address.

The `getBalance()` function returns the balance of the contract.

The `setArbiter()` function allows the arbiter to set a new arbiter.

The `setSeller()` function allows the seller to set a new seller.

Note that this is a very basic implementation of an escrow contract and should not be used in production without thorough testing and auditing. Also, there may be additional features that you may want to add to suit your specific use case. Upon inspection, the snippet provided by ChatGPT is pretty good! But it does have an error—the constructor is not marked even though we’re accessing and expecting Ether to be sent to it. payable msg.value Again, an important note: Never expect ChatGPT to give you code that is 100% correct. More often than not, you will have to make small corrections like we did here. Also notice that ChatGPT uses an earlier version of Solidity, and it uses a practice of fund transfer that is not considered best practice anymore. For the purpose of this tutorial, we’ll just let it be. In the contracts folder of your project, create a new file called and add the code provided by ChatGPT with the corrections. Escrow.sol // SPDX-License-Identifier: MIT

pragma solidity ^0.8.0;

contract Escrow {
    address payable public buyer;
    address payable public seller;
    address public arbiter;
    uint public value;
    bool public released;
    bool public refunded;

    constructor(address payable _buyer, address payable _seller, address _arbiter) payable {
        buyer = _buyer;
        seller = _seller;
        arbiter = _arbiter;
        value = msg.value;
    }

    function release() public {
        require(!released, "Funds have already been released.");
        require(msg.sender == buyer || msg.sender == arbiter, "Only buyer or arbiter can release funds.");
        released = true;
        seller.transfer(value);
    }

    function refund() public {
        require(!refunded, "Funds have already been refunded.");
        require(msg.sender == buyer || msg.sender == arbiter, "Only buyer or arbiter can refund funds.");
        refunded = true;
        buyer.transfer(value);
    }

    function getBalance() public view returns (uint) {
        return address(this).balance;
    }

    function setArbiter(address _arbiter) public {
        require(msg.sender == arbiter, "Only arbiter can set arbiter.");
        arbiter = _arbiter;
    }

    function setSeller(address payable _seller) public {
        require(msg.sender == seller, "Only seller can set seller.");
        seller = _seller;
    }
} Make sure the contract is compiling correctly by running: $ npx truffle compile Step 8: Update Your Truffle Config Next, we’ll do a little configuring without ChatGPT. This is a standard setup and will depend on the environment we’re using. Create a new file in your project’s root directory and add the following: .env INFURA_API_KEY = "https://sepolia.infura.io/v3/<insert API key here>"

MNEMONIC = "<insert metamask secret phrase here>" Now let’s configure the Infura endpoint. In replace the existing code with this standard config: truffle.config.js require('dotenv').config();
const HDWalletProvider = require('@truffle/hdwallet-provider');
const {INFURA_API_KEY, MNEMONIC} = process.env;

module.exports = {
    networks: {
      development: {
        host: "127.0.0.1",
        port: 8545,
        network_id: "*"
      },
      sepolia: {
        provider: () => new HDWalletProvider(MNEMONIC, INFURA_API_KEY),
        network_id: '11155111',
      }
    }
}; Step 9: Deploy the Contract Now it’s time to deploy! Instead of giving you the script to deploy our contract using Truffle, let’s ask ChatGPT for the relevant instructions. In the same window that you used to ask for the escrow contract code, we’ll enter the following prompt: Give me a migration script that deploys the Escrow contract using Truffle. . I need to send 0.001 ETH to the constructor during deployment. And I need the address that deploys the contract to be the buyer We get this response: Sure, here's an example migration script that deploys the `Escrow` contract and sends 0.001 ETH to the constructor during deployment. In this script, the address that deploys the contract will be set as the buyer.

1. Create a new JavaScript file named `2_deploy_escrow.js` (the number at the beginning indicates the order in which the migrations will be executed).
2. Copy the following code into `2_deploy_escrow.js`: const Escrow = artifacts.require("Escrow"); module.exports = async function(deployer, network, accounts) {
const buyer = accounts[0]; // set the buyer as the address that deploys the contract
const seller = "0x2222222222222222222222222222222222222222"; // replace with seller address
const arbiter = "0x3333333333333333333333333333333333333333"; // replace with arbiter address
const value = web3.utils.toWei('0.001', 'ether'); // change to the value you want to send await deployer.deploy(Escrow, seller, arbiter, { from: buyer, value: value });
}; 3. Replace the seller and arbiter addresses with the actual Ethereum addresses of the parties involved in the escrow transaction.
4. Save the file.
5. Make sure you have a network configured in your `truffle-config.js` file. If you want to deploy to a testnet, you'll need to configure your Truffle project to use the network you want to deploy to.
6. Run `truffle migrate --network <network-name>` to deploy the contract to the specified network. Replace `<network-name>` with the name of the network you want to deploy to, e.g. `ropsten` for the Ropsten testnet. This will deploy the contract and send 0.001 ETH to the constructor with the address that deploys the contract set as the buyer. Once again, the instructions provided by ChatGPT are mostly correct. It gets the naming wrong (we want it to be prefixed with 1_ and not 2_) and makes a minor mistake in setting the arguments of the function. deploy Let’s create a new file in the folder. Add the following, slightly modified code. 1_deploy_contract.js migrations const Escrow = artifacts.require("Escrow");

module.exports = async function (deployer, network, accounts) {
    const buyer = accounts[0]; // set the buyer as the address that deploys the contract
    const seller = accounts[1]; // replace with seller address
    const arbiter = accounts[2]; // replace with arbiter address
    const value = web3.utils.toWei('0.001', 'ether'); // change to the value you want to send

    await deployer.deploy(Escrow, seller, arbiter, { from: buyer, value: value });
}; And finally, let’s deploy our contract: $ truffle migrate --network sepolia You should see something similar to this: Compiling your contracts...
===========================
> Everything is up to date, there is nothing to compile.


Migrations dry-run (simulation)
===============================
> Network name:    'sepolia-fork'
> Network id:      11155111
> Block gas limit: 30000000 (0x1c9c380)


1_deploy_contract.js
====================

   Deploying 'Escrow'
   ------------------
   > block number:        3400252
   > block timestamp:     1682974543
   > account:             0xc361Fc33b99F88612257ac8cC2d852A5CEe0E217
   > balance:             0.506876109994053108
   > gas used:            849556 (0xcf694)
   > gas price:           2.500000007 gwei
   > value sent:          0.001 ETH
   > total cost:          0.003123890005946892 ETH

   -------------------------------------
   > Total cost:     0.003123890005946892 ETH

Summary
=======
> Total deployments:   1
> Final cost:          0.003123890005946892 ETH




Starting migrations...
======================
> Network name:    'sepolia'
> Network id:      11155111
> Block gas limit: 30000000 (0x1c9c380)


1_deploy_contract.js
====================

   Deploying 'Escrow'
   ------------------
   > transaction hash:    0x7a7804d92a6b6e805991eeb8249d79a2b8c5da43cffe633a31f987e9fe596654
   > Blocks: 1            Seconds: 33
   > contract address:    0x64ccE52898F5d61380D2Ec8C02F2EF16F28436de
   > block number:        3400258
   > block timestamp:     1682974584
   > account:             0xc361Fc33b99F88612257ac8cC2d852A5CEe0E217
   > balance:             0.506876109994053108
   > gas used:            849556 (0xcf694)
   > gas price:           2.500000007 gwei
   > value sent:          0.001 ETH
   > total cost:          0.003123890005946892 ETH

   > Saving artifacts
   -------------------------------------
   > Total cost:     0.003123890005946892 ETH

Summary
=======
> Total deployments:   1
> Final cost:          0.003123890005946892 ETH To validate deployment, you can find your contract’s address on Sepolia Etherscan: Congratulations! You’ve deployed your contract. And you did this using ChatGPT to generate more than 95% of your code. Tips and Tricks Here are a few tips and tricks for using ChatGPT when coding: ChatGPT has limited knowledge and has a knowledge-base cutoff of September 2021. So some of those best practices and latest developments in smart contracts are going to be missing from its knowledge. There are several versions of ChatGPT. GPT-4 tends to give better answers, but is a paid service. GPT-3.5 (which we used here) is free, and does pretty well. Make your questions as specific as possible. Don’t stop with writing code. ChatGTP can debug your code, audit it, document it, make it pretty, analyze it, find vulnerabilities, and more. Conclusion ChatGPT was an extremely useful co-developer. But it wasn’t perfect. I wouldn’t use it to create unmodified code that I pushed to mainnet—especially if I was a newdeveloper. But as a coding partner, and as a place to start, it was helpful. It saved me significant time and created surprisingly good code. In the hands of an experienced developer, I believe it can increase productivity by many times. I plan on using it quite heavily on future projects, alongside MetaMask, Infura, and Truffle. Have a really great day!

Write a Smart Contract with ChatGPT MetaMask Infura, and Truffle

Non-Fungible Tokens (NFTs) have gained significant popularity in the blockchain space, enabling creators to tokenize and sell unique digital assets. In this tutorial, we will create a simple NFT exchange contract using Solidity, the primary programming language for developing smart contracts on the Ethereum blockchain. We will walk through the process of creating, deploying, and interacting with the contract to enable users to list, buy, and sell NFTs on our exchange. Prerequisites: Basic understanding of Solidity and smart contracts Familiarity with Ethereum development tools, such as Remix IDE or Truffle Step 1: Setting up the Development Environment To begin, we will use the Remix IDE ( ) for this tutorial. Remix is a browser-based development environment that allows us to write, compile, and deploy smart contracts with ease. https://remix.ethereum.org/ Step 2: Creating the NFTExchange Contract Create a new Solidity file named "NFTExchange.sol" in the Remix IDE, and add the following code: pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC721/IERC721.sol";
import "@openzeppelin/contracts/utils/Counters.sol";
import "@openzeppelin/contracts/access/Ownable.sol";

contract NFTExchange is Ownable {
    using Counters for Counters.Counter;
    Counters.Counter private _listingIds;

    struct Listing {
        uint256 id;
        address nftContract;
        uint256 tokenId;
        address payable seller;
        uint256 price;
        bool isSold;
    }

    mapping(uint256 => Listing) public listings;

    event ListingCreated(uint256 indexed id, address indexed nftContract, uint256 indexed tokenId, address seller, uint256 price);
    event ListingSold(uint256 indexed id, address indexed buyer);

    // Your code will go here
} Step 3: Implementing the Functions Now, let's implement the core functions of our contract: Create a Listing: function createListing(address nftContract, uint256 tokenId, uint256 price) public {
    IERC721(nftContract).transferFrom(msg.sender, address(this), tokenId);
    
    _listingIds.increment();
    uint256 listingId = _listingIds.current();

    listings[listingId] = Listing({
        id: listingId,
        nftContract: nftContract,
        tokenId: tokenId,
        seller: payable(msg.sender),
        price: price,
        isSold: false
    });

    emit ListingCreated(listingId, nftContract, tokenId, msg.sender, price);
} Buy an NFT: function buyNFT(uint256 listingId) public payable {
    Listing storage listing = listings[listingId];
    require(!listing.isSold, "NFT is already sold");
    require(msg.value >= listing.price, "Insufficient funds");

    listing.seller.transfer(listing.price);
    IERC721(listing.nftContract).transferFrom(address(this), msg.sender, listing.tokenId);

    listing.isSold = true;

    emit ListingSold(listingId, msg.sender);
} Step 4: Compiling and Deploying the Contract Now, compile the contract by clicking on the "Solidity Compiler" tab in Remix and then clicking the "Compile" button. Once compiled, switch to the "Deploy & Run Transactions" tab, select the "Injected Web3" environment, and click "Deploy." Step 5: Interacting with the NFTExchange Contract After deployment, the NFTExchange contract will appear under the "Deployed Contracts" section. You can now interact with the contract using the provided buttons to call the functions we defined earlier. Create a Listing: To create a listing, you will need the NFT contract address and the token ID of the NFT you want to sell. Make sure you are the owner of the NFT, and the NFT is approved for transfer to the NFTExchange contract. Call the function by providing the NFT contract address, token ID, and desired price. After executing the function, a new listing will be created, and an event will be emitted with the listing details. createListing Buy an NFT: To buy an NFT from the exchange, call the function with the listing ID you want to purchase. Ensure you send the required amount of Ether along with the function call. If the purchase is successful, the NFT will be transferred to your address, and the seller will receive the payment. buyNFT Querying Listings: To fetch the details of a particular listing, you can call the function with the listing ID as an argument. The function will return the listing's details, such as the NFT contract address, token ID, seller address, price, and sold status. listings Conclusion: In this tutorial, we built a simple NFT exchange contract using Solidity. We implemented core functionalities to create listings and buy NFTs. This exchange contract can be further expanded with additional features, such as a bidding system or a native token for transaction fees. With a firm understanding of the basics, you can now continue to explore more complex NFT exchange systems and develop your own decentralized marketplace for unique digital assets. You can get the whole code . here

Building an NFT Exchange Contract with Solidity: A Step-by-Step Guide

The Essential Guide to Building an NFT Auction Site with React, Solidity, and CometChat

Enabling NFT Royalties With EIP-2981

Habilitación de regalías NFT con EIP-2981

What you will be building, see the and for more info. live demo GitHub repo Introduction The demand for Web3.0 solutions is at an all-time high, but there isn't enough material available to usher in the army of developers required to fill the job openings. To assist other web developers, I've created this tutorial to help you understand how to build a decentralized eCommerce platform that transacts Ethers. You will be able to do the following by the end of this tutorial: Build an eCommerce app. Integrate Web3.0 Payment solution. Incorporate Customer Chat functionality. Interact with a Database using Firebase v9. Code and Deploy a Solidity Smart Contract. Hookup Smart Contract with React App. Lot’s more. This is tutorial is PART-ONE of a two-part series, we will begin with developing the solidity smart contract. So If you are pumped for this build, then let’s get coding… Prerequisites For PART-ONE of this tutorial, you will need the following items to build along with me; installed on your machine. NodeJs installed. Yarn package manager installed. Truffle installed. Ganache installed. Git CLI And an agile determination to learn. Installing App Dependencies To save you the pain of installing one dependency after another, I’ve prepared you a . Clone and install the dependencies with the instructions below. And… don’t forget to star the project. starter kit on my git repo On your terminal, navigate to the location of your project and run the code below: # Make sure you have the above prerequisites installed already!
git clone https://github.com/Daltonic/truffle-starter-kit.git freshers
cd frehsers # Navigate to the new folder.
yarn install # Installs all the dependencies. I recommend you use for the tutorial, it has everything you will need for coding. vs code If you’ve done that, you’re awesome, let’s proceed to the next step… Coding the Smart Contract Open the project in VS code and head on to the contracts directory, you will see an existing contract named . Migration.sol Create a new solidity contract named . Inside of the store, define the following structures. Store.sol // SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

contract Store {
  // All codes goes in here!
} This is a typical structure of a solidity smart contract, let’s code this smart contract one step at a time. // Defining store variables
address public immutable storeOwner;
uint256 public storeAcc;
string public storeName;
uint256 public immutable feePercent;
uint256 public storeSales; These are the variables our smart contract will use to perform store sales. The and variables are , once the smart contract is deployed it can no longer be changed in the course of the program. store owner fee percent immutable Variables with address type mean that they can only hold data types of wallet address. Whereas variables with or mean unsigned integers, they can be used to hold only positive numbers with or without decimals. uint uint256 // Tracking users number of sales
mapping(address => uint256) public salesOf; The code above describes a solidity variable with a key-value type of association. It's similar to the python hash method in that it returns a value if the argument passed in the parameter finds a match. // Declaring Events within each sale
event Sale(
    address indexed buyer,
    address indexed seller,
    uint256 amount,
    uint256 timestamp
);
event Withdrawal(
    address indexed receiver,
    uint256 amount,
    uint256 timestamp
); Events are useful for storing the arguments passed into the smart contract on the blockchain network. It’s an essential ingredient for writing a professional smart contract. // Structuring the sales object
struct SalesStruct {
    address buyer;
    address seller;
    uint256 amount;
    string purpose;
    uint256 timestamp;
}
SalesStruct[] sales; We're describing a structure for collecting sales data in the code above. We want to collect the buyer and seller's addresses, the number of ethers transacted, the purpose of the transaction, and the time the transaction was completed for each sale made through our smart contract. Solidity provides us with a struct method, which is the best practice for ensuring that these records are correctly entered. // Initializing the store
constructor(
    string memory _storeName,
    address _storeOwner,
    uint256 _feePercent
) {
    storeName = _storeName;
    storeOwner = _storeOwner;
    feePercent = _feePercent;
    storeAcc = 0;
} These are the information passed during the deployment of the smart contract. // Performing sales payment
function payNow(address seller, string memory purpose)
    public
    payable
    returns (bool success)
{
    // Validating payments
    require(msg.value > 0, "Ethers cannot be zero!");
    require(msg.sender != storeOwner, "Sale Not allowed");

    // Calculating up cost and fee
    uint256 fee = (msg.value / 100) * feePercent;
    uint256 cost = msg.value - fee;

    // Assigning sales and payment to store and product owner
    storeAcc += msg.value;
    storeSales += 1;
    salesOf[seller] += 1;

    // Cashing out to sales party
    withdrawMoneyTo(storeOwner, fee);
    withdrawMoneyTo(seller, cost);

    // Recording sales in smart contract
    sales.push(
        SalesStruct(msg.sender, seller, cost, purpose, block.timestamp)
    );

    // Captures sales data on event
    emit Sale(msg.sender, seller, cost, block.timestamp);
    return true;
} This function collects payment from a buyer and sends the seller of the sales and to the store owner as the fee for utilizing their platform. 90% 10% // Sends ethers to a specified address
function _payTo(address _to, uint256 _amount) internal {
    (bool success1, ) = payable(_to).call{value: _amount}("");
    require(success1);
} This is an internal method for transferring ethers to a specified address, it works in conjunction with the withdrawal function. It can only be called by another function within our smart contract. // Performs ethers transfer
function withdrawMoneyTo(address receiver, uint256 amount)
    internal
    returns (bool success)
{
    require(storeAcc >= amount, "Insufficent Fund!");
    _payTo(receiver, amount);
    storeAcc -= amount;

    // Captures transfer data on event
    emit Withdrawal(receiver, amount, block.timestamp);
    return true;
} This is a function that performs the sending of money to a specified address. It makes sure that it checks for balances before carrying out the transaction. // Retreives all processed sales from smart contract
function getAllSales() public view returns (SalesStruct[] memory) {
    return sales;
} Lastly, this function returns an array of all the sales that have taken place on our smart contract. The full code looks like this… // SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

contract Store {
    // Defining store variables
    address public immutable storeOwner;
    uint256 public storeAcc;
    string public storeName;
    uint256 public immutable feePercent;
    uint256 public storeSales;

    // Tracking users number of sales
    mapping(address => uint256) public salesOf;

    // Declaring Events within each sale
    event Sale(
        address indexed buyer,
        address indexed seller,
        uint256 amount,
        uint256 timestamp
    );

    event Withdrawal(
        address indexed receiver,
        uint256 amount,
        uint256 timestamp
    );

    // Structuring the sales object
    struct SalesStruct {
        address buyer;
        address seller;
        uint256 amount;
        string purpose;
        uint256 timestamp;
    }

    SalesStruct[] sales;

    // Initializing the store
    constructor(
        string memory _storeName,
        address _storeOwner,
        uint256 _feePercent
    ) {
        storeName = _storeName;
        storeOwner = _storeOwner;
        feePercent = _feePercent;
        storeAcc = 0;
    }

    // Performing sales payment
    function payNow(address seller, string memory purpose)
        public
        payable
        returns (bool success)
    {
        // Validating payments
        require(msg.value > 0, "Ethers cannot be zerro!");
        require(msg.sender != storeOwner, "Sale Not allowed");

        // Calculating up cost and fee
        uint256 fee = (msg.value / 100) * feePercent;
        uint256 cost = msg.value - fee;

        // Assigning sales and payment to store and product owner
        storeAcc += msg.value;
        storeSales += 1;
        salesOf[seller] += 1;

        // Cashing out to sales party
        withdrawMoneyTo(storeOwner, fee);
        withdrawMoneyTo(seller, cost);

        // Recording sales in smart contract
        sales.push(
            SalesStruct(msg.sender, seller, cost, purpose, block.timestamp)
        );

        // Captures sales data on event
        emit Sale(msg.sender, seller, cost, block.timestamp);
        return true;
    }

    // Sends ethers to a specified address
    function _payTo(address _to, uint256 _amount) internal {
        (bool success1, ) = payable(_to).call{value: _amount}("");
        require(success1);
    }

    // Performs ethers transfer
    function withdrawMoneyTo(address receiver, uint256 amount)
        internal
        returns (bool success)
    {
        require(storeAcc >= amount, "Insufficent Fund!");

        _payTo(receiver, amount);
        storeAcc -= amount;

        // Captures transfer data on event
        emit Withdrawal(receiver, amount, block.timestamp);
        return true;
    }

    // Retreives all processed sales from smart contract
    function getAllSales() public view returns (SalesStruct[] memory) {
        return sales;
    }
} Now that we are done with coding this smart contract, it's time to test it programmatically. Setting up the Migration Scripts Before we proceed with testing out the smart contract, let’s set up the migration script in the folder. migrations Head to the migrations folder and create a new file called . Paste the following codes inside the file. 2_deploy_contracts.js 2_deploy_contracts.js const Store = artifacts.require('Store')
module.exports = async (deployer) => {
  const [_feeAccount] = await web3.eth.getAccounts()
  const _name = 'Fresher'
  const _feePercent = 10
  await deployer.deploy(
    Store,
    _name,
    _feeAccount,
    _feePercent
  )
} This will be necessary when we start testing out the smart contract. Testing the Smart Contract Spin up Ganache and ensure that it’s live and accessible. Next, locate the folder and create a file called . test Store.test.js Paste the code snippet inside of it. const Store = artifacts.require('Store')

require('chai').use(require('chai-as-promised')).should()

const toWei = (num) => web3.utils.toWei(num.toString())
const fromWei = (num) => web3.utils.fromWei(num.toString())

contract('Store', ([storeOwner, buyer, seller]) => {
  const feePercent = 10
  const storeName = 'Freshers'

  let store

  beforeEach(async () => {
    store = await Store.new(storeName, storeOwner, feePercent)
  })

  describe('deployment', () => {
    it('confirms store name', async () => {
      const result = await store.storeName()
      result.should.equal(storeName)
    })

    it('confirms store owner', async () => {
      const result = await store.storeOwner()
      result.should.equal(storeOwner)
    })

    it('confirms sales fee', async () => {
      const result = await store.feePercent()
      result.toString().should.equal(feePercent.toString())
    })
  })

  describe('Sales process', () => {
    const amount = fromWei(toWei(4))
    const purpose = 'Sales on dippers'

    it('confirms increase in sales of store and seller', async () => {
      // Sales of seller before purchase
      let result = await store.salesOf(seller)
      result.toString().should.equal('0')

      // Sales of store before purchase
      result = await store.storeSales()
      result.toString().should.equal('0')

      // Perform sales
      await store.payNow(seller, purpose, { from: buyer, value: amount })

      // Sales of after after purchase
      result = await store.salesOf(seller)
      result.toString().should.equal('1')

      // Sales of store after purchase
      result = await store.storeSales()
      result.toString().should.equal('1')
    })
  })
}) The above test is designed to check that our smart contract can perform sales. An extra measure to ensure that your smart contract runs accordingly is to write a script that will interact with it. Let’s do that next. Interacting with the Smart Contract This is the best way to validate the functionalities of your smart contract. We want to write a script to simulate the sales process. Head to the and create a file called . Next, paste the following codes inside of it. scripts folder performSales.js const Store = artifacts.require("Store");

module.exports = async (callback) => {
  const [storeOwner, seller, buyer] = await web3.eth.getAccounts()
  const amount = web3.utils.toWei('4', 'ether')
  const purpose = 'Sales on dippers'

  const store = await Store.deployed()

  let buyerBal = await web3.eth.getBalance(buyer)
  let sellerBal = await web3.eth.getBalance(seller)
  let storeOwnerBal = await web3.eth.getBalance(storeOwner)

  console.log(`Initial balance of buyer | ${web3.utils.fromWei(buyerBal.toString(), 'ether')}`)
  console.log(`Initial balance of seller   | ${web3.utils.fromWei(sellerBal.toString(), 'ether')}`)
  console.log(`Initial balance of storeOwner   | ${web3.utils.fromWei(storeOwnerBal.toString(), 'ether')}`)

  console.log(`\n ${purpose} for ${web3.utils.fromWei(amount.toString(), 'ether')} ethers... \n`)

  await store.payNow(seller, purpose, {from: buyer, value: amount})

  buyerBal = await web3.eth.getBalance(buyer)
  sellerBal = await web3.eth.getBalance(seller)
  storeOwnerBal = await web3.eth.getBalance(storeOwner)

  console.log(`Balance of buyer after sales | ${web3.utils.fromWei(buyerBal.toString(), 'ether')}`)
  console.log(`Balance of seller after sales | ${web3.utils.fromWei(sellerBal.toString(), 'ether')}`)
  console.log(`Balance of storeOwner after sales | ${web3.utils.fromWei(storeOwnerBal.toString(), 'ether')}`)

  callback()
} Cool, after creating and pasting the codes above, run the following command on the terminal. Please make sure that your ganache is up and running. truffle migrate --reset You will observe the following result on your terminal. If you reached here, you’re awesome, let’s run the script by running this code on the terminal. perfomSales truffle exec scripts/performSales.js You should have something like this on your terminal… Fantastic, we can be happy that our smart contract is certified and fully functional. Let’s deploy it to the . rinkeby test net Deploying the Smart Contract To do this deployment, configure your truffle config file in the order below: require('dotenv').config()
const HDWalletProvider = require('@truffle/hdwallet-provider')
module.exports = {
  // Configure networks (Localhost, Kovan, etc.)
  networks: {
    development: {
      host: '127.0.0.1',
      port: 7545,
      network_id: '*', // Match any network id
    },
    rinkeby: {
      provider: () =>
        new HDWalletProvider(process.env.SECRET_KEY, process.env.ENDPOINT_URL),
      network_id: 4, // Rinkeby's id
      gas: 5500000, // Rinkeby has a lower block limit than mainnet
      confirmations: 2, // # of confs to wait between deployments. (default: 0)
      timeoutBlocks: 200, // # of blocks before a deployment times out  (minimum/default: 50)
      skipDryRun: true, // Skip dry run before migrations? (default: false for public nets )
    },
  },
  contracts_directory: './contracts/',
  contracts_build_directory: './src/shared/abis/',
  // Configure your compilers
  compilers: {
    solc: {
      version: '0.8.11',
      optimizer: {
        enabled: true,
        runs: 200,
      },
    },
  },
} Deploying to Alchemy At the moment, our smart contract can only run on our computer, and no one else can connect to it. We will use alchemy to make it available to everyone at no cost. Sign up with them now, or if you already have an account. log in When you log in, you will see the dashboard page, which allows you to create a new blockchain application. Click on the button and enter the information shown in the image below, making sure to include the network. Creating an Alchemy App CREATE APP Rinkeby test After you've created the app, you can view its information by clicking on the app's name or the view the details button. Copy the as shown in the image below by clicking on the button. WSS URL VIEW KEY Amazing, now proceed as shown in the images below to obtain your account. Please keep in mind that we are not using the regular account address, but rather the private key to that account. Rinkeby ENDPOINT_URL=<YOUR_ALCHEMY_WSS_URL>
SECRET_KEY=<YOUR_METAMASK_SECRET_PHRASE>
DEPLOYER_KEY=<YOUR_METAMASK_PRIVATE_KEY> Please do not use your real ; these keys must be kept secret. That's why we put them in the environment file and tell git to ignore them. Metamask details After you've entered the above keys into their respective variables, execute the commands below. truffle migrate --reset --network rinkeby As we can see below, your smart contract will be deployed on the Rinkeby test net. Wow, you've worked hard to get to this point. You've just finished deploying an eye-catching smart contract to the Ethereum blockchain network. We'll connect it to a ReactJs frontend in of this tutorial. PART-TWO Conclusion You've completed the first part of this tutorial; next, we'll learn how to connect the solidity smart contract we just deployed to our React frontend. You can see the finished version of this application , and you can also check out the , which you should star. live here git repo here I'll see you again in of this tutorial. PART-TWO About the Author Gospel Darlington kick-started his journey as a software engineer in 2016. Over the years, he has grown full-blown skills in JavaScript stacks such as React, ReactNative, VueJs, and more. He is currently freelancing, building apps for clients, writing technical tutorials teaching others how to do what he does. Gospel Darlington is open and available to hear from you. You can reach him on , , , or on his . LinkedIn Facebook Github website Also published here

Essential Guide to Building a Decentralized eCommerce Platform with React and Solidity (Part 1)

Background is here to stay and anybody who knows the potential, just do not want to be left out, but want to be an early adopter as well. So there are so many individuals and corporations who tries to build solutions based on Blockchain, but more often these solutions does not comply true values of Blockchain (or Decentralised Ledgers). This article tries to explain, a possible design pattern, which could be used when designing blockchain based solutions for common business problems. In decentralised terminology, design pattern to build truly solutions. Further this suggest a possible revenue model for trust-less solutions on decentralised ledgers. Blockchain trust-less Sample business problem Let’s consider a simple business application so we could apply this design pattern. Consider a simple online market place similar to eBay (simplest possible version of eBay). This system would ideally have 3 actors, namely Sellers, Buyers & Admins (Who manage the market place). Let’s define what each actor would do in this minimalistic version of marketplace. Create a store & put up items to sell Sellers: Create a profile and buy items offered by seller’s Buyers: Manage the site by authorising sellers, buyers and resolve any disputes and collect commission from transactions Admins: Design with centralised & trust-based mindset If you ask a general software developer (here I’m referring to a developer who does not use decentralised technologies nor aware of such concepts) to build this solution, following would be classic implementation of this solution. Sellers could register with this market place, but admins would have to approve/accept the seller to trade using the platform. Irrespective to approval/acceptance process, admins could kick a seller out of system if they want Same as above applies to buyers, admins would have the ultimate control over specific buyer’s existence in the marketplace Admins would have access to all sellers and buyers within the system from backend and would be able alter profile attributes if necessary (reset passwords, etc) Only way to access list of buyers and sellers (and their items) would be through the market place platform (or APIs provided by the platform) Whoever register with this platform (both buyers and sellers) ultimately have to trust the platform admins or the organization behind the platform So all characteristics above constitutes a controlled, closed system governed by the owners of the platform. And everything rely on how trustworthy the owners of the platform are. . So solution is trust based and centralised Important fact to remember here is, even using decentralised technologies (such as Smart Contracts and Distributed Ledgers) it is quite possible to implement solutions which needs to trust the owner of the platform and owner could control most aspect of the platform. Unfortunately, most blockchain based business solutions we find have these attributes even though those are implemented on top of decentralised technologies. Design with decentralised, trust-less mindset Let’s see how we could make the above solution truly trust-less. In other words, platform owner should not have any control over any of the aspects of the platform. This is where things start to sound weird, but if you closely look at how Bitcoin works, conceptually that’s what we proposing here. Possible way to achieve trust-less design, Platform owner should provide a Smart Contract which is a Contract Factory (a smart contract that could create sub contracts) for each actor and entity in the system. Important point here is, platform owner have any control over these factory contracts once those are deployed to the network. . should not No backdoors So in our example platform above, there will be two Factory Contracts for Sellers and Buyers each. So, anyone in the network could use these Factory Contracts to create either a seller contract or a buyer contract. Once a seller or buyer contract is created, such contract is owned by the creator of the contract not by the platform. So the individual sellers and buyers would own their respective contracts and would have full control over those. Platform owner has nothing to do with these contracts. For the selling and buying to be possible, there should be a third contract which define how the buy, sell transactions would work. Again it is important to make this (call it ) is self governed. In other words, no one should own or should not have any control over it [In a trust based world, this would be the heart of the business, but in our trust-less world, platform creator does not own or control it]. transaction controlling contract TxnController TxnController In summary, we have built set of smart contracts, which are owned and controlled by relevant actor and another contract which owned and controlled by no one other than the logic written in the contract. This constitute a truly trust-less system. Only elements we trust here are the contract logic and the (EVM in Ethereum world) which executes it. These are unbiased and autonomous, so can be trusted to do what they have programmed to do. Virtual Machines Important fact to remember here is the openness of the solution we have built. As the platform creator, you might be the first to build a DApp for the platform, but that does not prevent any third party also build a similar or better DApp. This is possible at all levels as each smart contract is available to third parties as much as those are available for the creator. Possible business model So we have a feasible way of implementing a decentralised solution in completely trust-less manner. That being true, you might have the question in your mind, why anyone should build this type of a system, if you do not own anything at the end. Usually (in trust based centralised world), the ownership, the ability to control is what you could turn into business model (revenue stream) where you could sustain your business and finally make profits out of it. While there could be many different ways to make profits even from a trust-less system similar to what we explained above (for instance, in the marketplace example, you could charge a percentage of every transaction in contract and transfer that to your ether account), there is a possible model that could use to make revenue from almost any trust-less system. TxController Smart contracts begin the core of decentralisation and trust-less design, we could leverage on the Decentralised App (DApp) to make revenue. Even though the smart contracts are completely independent from each other, a DApp you create could provide a single point of entry to deal with all these independent and self governed smart contracts. That would provide the convenience for users to access these self governing smart contracts via a single DApp and as the platform developer you could assure the data integrity (linking and referencing of data stored in smart contracts in a meaningful manner) to its end users. Just reemphasise, at the core, contract logics and stored data do not under anyone’s control and can be accessed by any arbitrary user, but the DApp which wraps these contracts provide a nexus point to deal with these contracts as a single solution platform. If you are as a reader is still skeptical about the viability of this model, I would like to relate this with a popular revenue model in open source ecosystem. If you think of Open-Core based solutions which runs profitable businesses, it might shade some lights to prove the viability of this model. There are many solutions have an open source core, which could be used by anyone to build any type of solution on top of it. But at the same time, there are organisations, provide convenience for its users by providing value additions on top of the open-core (Many Apache foundation solutions are supported by commercial ventures which make profits out of that service. ex: ThoughtWorks & Hadoop). Overview of Smart Contracts As you could see in above diagram, Factory Contracts (SellerFactory & BuyerFactory) and TxController are self governed (No owner or no one has control over those). DApp provides means to interact with these self governing contracts and optionally could own Smart Contract which could use to store relationships between data stored in independent contracts. As indicated under DApp, there will be functionality to interact with smart contracts in a more integrated manner (similar to any general business application). Registry Conclusion If anyone build solutions based on Blockchain (or decentralised ledger ) it is important to have core concepts of Blockchain being persevered in the implementation. Making core actors and entities related smart contracts self governed is a must to provide true trust-less implementation, but additional application layer (DApp + Smart contracts which are controlled by a authorised party) on top of these independent smart contracts could be a possible way to monetise a true trust-less platform. technology This design pattern is more of a thought experiment and PoC level implementation, meaning this is not tested against commercial implementations. I hope there would be many different ideas on how this can be improved and/or other possible approaches to achieve the same goals. Please share your thoughts in comments to explore further about this topic.

Stories, News & Mentions about SELLERANT

Sellerant’s Stories on HackerNoon