DEV Community: Yao Marius SODOKIN

Shadowing Inherited State Variables

Yao Marius SODOKIN — Thu, 02 Feb 2023 03:21:14 +0000

Inheritance is a fundamental concept in object-oriented programming, allowing developers to create new classes that inherit properties and methods from existing ones. However, when it comes to state variables, there is a potential pitfall that developers should be aware of: shadowing inherited state variables.

Shadowing occurs when a subclass defines a state variable with the same name as one in its superclass, effectively hiding the inherited variable. This can lead to unexpected behavior and can make the code harder to understand and maintain.

A practical example of shadowing inherited state variables can be seen in the following Solidity code:

pragma solidity ^0.8.17;

contract Parent {
    uint256 public x;

    function setX(uint256 _x) public {
        x = _x;
    }
}

contract Child is Parent {
    uint256 public x;

    function setX(uint256 _x) public {
        x = _x;
    }
}

In this example, both the Parent and Child contracts have a state variable named x. The Child contract inherits from the Parent contract and has its own declaration of x, which is called "shadowing".

When the Child contract's setX function is called, it updates its own x state variable and not the inherited x from the Parent contract. This is because the state variable in the Child contract shadows the inherited state variable from the Parent contract.

In other words, the Child contract has a new storage location for the x state variable, separate from the one in the Parent contract. The Child contract's state variable takes precedence over the inherited state variable from the Parent contract.

In conclusion, shadowing inherited state variables can lead to unexpected behavior and can make the code harder to understand and maintain. To avoid shadowing, developers should consider using a different name, using the "super" keyword, or using composition instead of inheritance. Additionally, developers should also consider the security implications of inherited state variables to ensure that sensitive information is protected.

Calling Parent Contracts

Yao Marius SODOKIN — Thu, 02 Feb 2023 02:39:28 +0000

Calling parent contracts in Solidity can be a powerful tool for developers, allowing them to build upon existing functionality while also adding new functionality to their contracts. The most common method for calling parent contracts is through the use of the "super" keyword.
This keyword allows a child contract to call a function from its parent contract, even if the function has been overridden in the child contract.

For instance, let's consider a parent contract "Animals" that has a function "isAlive()" which returns a boolean value indicating whether the animal is alive or not. A child contract "Dogs" could inherit from the "Animals" contract and override the "isAlive()" function to include additional functionality, such as checking if the dog is trained:

pragma solidity ^0.6.0;
contract Animal {
    function isAlive() public view returns (bool) {
        return true;
    }
}

contract Dog is Animal {
    bool public isTrained;

    function isAlive() public view returns (bool) {
        if (super.isAlive() && isTrained) {
            return true;
        }
        return false;
    }
}

In this example, the "Dog" contract uses the "super" keyword to call the "isAlive()" function from its parent contract, "Animals". The child contract can then add additional functionality to the function, such as checking if the dog is trained, before returning the final value.
However, it is important to be cautious when calling parent contracts, as this can also pose security risks. Developers must ensure that calls to parent contracts are made only by authorized parties and that sensitive information is properly protected. They should also be aware of the potential for reentrancy attacks and take appropriate measures to prevent them.

In conclusion, calling parent contracts in Solidity can provide a useful way to extend functionality while also maintaining code maintainability. By using t

The "super" keyword, developers can easily call a parent contract's function, even if the function has been overridden in the child contract. However, it is important to consider security and take appropriate measures to protect sensitive information and prevent reentrancy attacks.

Implementing a Voting System in Solidity

Yao Marius SODOKIN — Wed, 11 Jan 2023 23:17:15 +0000

A voting system is a crucial component of decentralized applications (dapps) that operate on the Ethereum blockchain. Solidity is the primary programming language used to write smart contracts on Ethereum, making it a natural choice for implementing a voting system.

Implementing a voting system in Solidity involves several key steps:

1. Defining the voting structure

This includes the candidates or options available for voting, the number of votes each voter is entitled to, and the total number of votes cast.

struct Voter {
    address addr;
    bool voted;
    uint8 vote;
}

struct Candidate {
    bytes32 name;
    uint8 voteCount;
}

mapping(address => Voter) public voters;
Candidate[] public candidates;

2. Setting up the voting mechanism:

This includes functions for casting votes, checking voter eligibility, and tallying the results.

function vote(uint8 _candidate) public {
    require(voters[msg.sender].voted == false);
    require(_candidate < candidates.length);

    voters[msg.sender].vote = _candidate;
    voters[msg.sender].voted = true;
    candidates[_candidate].voteCount += 1;
}

function winningCandidate() public view returns (bytes32) {
    bytes32 winner;
    uint8 maxVotes = 0;
    for (uint8 i = 0; i < candidates.length; i++) {
        if (candidates[i].voteCount > maxVotes) {
            winner = candidates[i].name;
            maxVotes = candidates[i].voteCount;
        }
    }
    return winner;
}

3. Enforcing voter eligibility

To ensure that only eligible voters can participate in the election, we can use the onlyOwner modifier or require statement to check that a voter's address is on a list of approved addresses.

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

function addVoter(address _voter) public onlyOwner {
    voters[_voter] = Voter(_voter, false, 0);
}

3. Ensuring security

Several potential vulnerabilities should be considered when implementing a voting system in Solidity. These include the potential for vote manipulation, unauthorized access to voting data, and the possibility of a malicious actor attempting to disrupt the voting process.

To mitigate these risks, it is important to employ best practices such as utilizing the require statement to validate inputs, implementing access control mechanisms, and utilizing Ethereum's built-in security features such as gas limits and time constraints.

This is the basic structure and functionality of a voting system in Solidity. Of course, there are many other considerations and optimizations that can be made depending on the specific requirements of the application.
Additionally, it's important to thoroughly test and audit the smart contract before deploying it to the Ethereum network.

Note

It's also important to notice that, depending on the complexity of your voting system, it may be expensive to deploy and run it on Ethereum blockchain. Keep in mind that each transaction made on the contract will require paying for Gas and the amount will depend on the complexity of the function being called, the data being stored and the current network conditions.

Debugging and Testing Solidity Smart Contracts

Yao Marius SODOKIN — Wed, 11 Jan 2023 19:07:56 +0000

INTRODUCTION

Debugging and testing Solidity smart contracts are crucial steps in the development process to ensure that the contracts function as intended and do not contain any security vulnerabilities. This article will provide an overview of the tools and best practices for debugging and testing Solidity contracts.

CONCEPTS COMPREHENSION

Before diving into debugging and testing, it's important to understand the basics of the Solidity programming language. Solidity is a contract-oriented, high-level programming language for writing smart contracts. It is used for implementing smart contracts on various blockchain platforms, such as Ethereum. Smart contracts are self-executing contracts with the terms of the agreement written directly into code.

Debugging

Debugging is the process of identifying and resolving errors or bugs in a program. There are several tools and methods available for debugging Solidity contracts.
One of the most popular tools for debugging Solidity contracts is Truffle. Truffle is a development environment, testing framework, and asset pipeline for Ethereum. It includes a suite of tools for compiling, deploying, and testing contracts. It also provides an interactive console for debugging and interacting with contracts on the blockchain.

Another useful tool for debugging Solidity contracts is Remix, an online solidity compiler and IDE. It allows developers to write, test, and debug their contracts in the browser. It also includes a debugger that allows developers to step through the execution of their contracts, set breakpoints, and examine the state of variables at different points in the execution.
There are also various plugins and extensions for development environments like** Visual Studio Code** that include debugging capabilities and are useful for debugging solidity contract

Testing

Testing is the process of verifying that a program or system meets its specified requirements and behaves as expected. It is an essential step in the development process to ensure that a contract is functioning correctly and does not contain any bugs or security vulnerabilities.

The most common approach to testing Solidity contracts is to use a testing framework. Truffle, as mentioned earlier, includes a built-in testing framework for Solidity contracts. It allows developers to write tests in JavaScript and then run them against their contracts to check that they function as expected.
Another popular testing framework for Solidity is OpenZeppelin's "Test Environment", which allows for the testing of smart contract in a simulated blockchain.

It's important to thoroughly test a smart contract before deploying it to a production environment. This includes testing for common security vulnerabilities such as the reentrancy vulnerability and the integer overflow/underflow vulnerability.

In addition to automated testing, it's also recommended to perform manual testing, reviewing the codebase, and conducting security audit by a third-party or specialized auditor.

A practical example

A practical example that demonstrates the concepts discussed in this article could be a simple smart contract for a token transfer system. Here is an example of what such a contract might look like:

`pragma solidity ^0.8.0;

contract TokenTransfer {
    mapping (address => uint) public balances;

    function transfer(address _to, uint _value) public {
        require(balances[msg.sender] >= _value && _value > 0, "Not enough balance or invalid value");
        balances[msg.sender] -= _value;
        balances[_to] += _value;
    }
}`

** Code comprehension**
This contract defines a mapping called "balances" that keeps track of the number of tokens held by each address.
It also includes a function called "transfer" that is used to transfer tokens from one address to another.
The function takes two arguments: an address to which the tokens will be transferred, and the number of tokens to be transferred.
The transfer function uses the Solidity require statement to check that the sender has enough tokens and the _value is more than 0 before making the transfer.

Debugging
To debug this contract, a developer could use Truffle or Remix to deploy the contract to a local test blockchain, and then use the interactive console or debugger to step through the execution of the transfer function, and examine the state of the contract's variables at different points in the execution. They could also set breakpoints to pause the execution and inspect variable values to detect errors or bugs in the contract's logic.

Testing
For testing, the developer could use Truffle or OpenZeppelin's "Test Environment" to write test cases for the contract, checking that it correctly transfers tokens between addresses, that it correctly updates the balance mapping, and that it has the expected behavior when passed invalid input or called by unauthorized addresses.

Exemple of testing code :

`const TokenTransfer = artifacts.require("TokenTransfer");

contract("TokenTransfer", (accounts) => {

  let contract;
  beforeEach(async () => {
    contract = await TokenTransfer.new();
  });

  it("should transfer tokens correctly", async () => {
    await contract.transfer(accounts[1], 100);
    let senderBalance = await contract.balances(accounts[0]);
    let receiverBalance = await contract.balances(accounts[1]);
    assert.equal(senderBalance.toNumber(), 0, "Sender balance not updated correctly");
    assert.equal(receiverBalance.toNumber(), 100, "Receiver balance not updated correctly");
  });

  it("should fail when trying to transfer more tokens than the sender has", async () => {
    try {
      await contract.transfer(accounts[1], 100, {from: accounts[0]});
      await contract.transfer(accounts[1], 100, {from: accounts[0]});
    } catch (error) {
      assert.equal(error.reason, "Not enough balance or invalid value");
    }
  });

  it("should fail when trying to transfer negative tokens", async () => {
    try {
        await contract.transfer(accounts[1], -1, {from: accounts[0]});
    } catch (error) {
        assert.equal(error.reason, "Not enough balance or invalid value");
    }
  });

  it("should fail when trying to transfer 0 tokens", async () => {
    try {
        await contract.transfer(accounts[1], 0, {from: accounts[0]});
    } catch (error) {
        assert.equal(error.reason, "Not enough balance or invalid value");
    }
  });
});`

Test cases comprehension

These test cases test the following scenarios:

The correct transfer of tokens between accounts
Attempts to transfer more tokens than the sender has
Attempts to transfer negative or zero tokens

In this example :

the beforeEach function is used to create a new instance of the contract before each test case is run. This ensures that the tests are isolated from one another and do not affect the state of the contract in unexpected ways.
The it functions are used to define individual test cases. The first test case, "should transfer tokens correctly," calls the transfer function and then checks that the balance of the sender and receiver have been updated correctly.
The next three test cases checks for the edge cases where it should fail when the sender doesn't have enough balance or trying to transfer negative or zero tokens and they check if the reason of the failure is the expected one.

They also test for common security vulnerabilities such as the reentrancy vulnerability and the integer overflow/underflow vulnerability by adding edge cases and malicious input to their test suite.

CONCLUSION

In summary, debugging and testing are crucial steps in the development of Solidity smart contracts. Using the tools and techniques described in this article can help ensure that contracts are functioning correctly and do not contain any security vulnerabilities.

Implementing a Token Contract using Solidity

Yao Marius SODOKIN — Wed, 11 Jan 2023 18:23:36 +0000

Intoduction

Creating a token contract using Solidity is a common task for those working with blockchain technology. In this article, we will go through the process of implementing a basic ERC-20 compliant token contract using the Solidity programming language.

Keys Concepts

Before diving into the code, it's important to understand what the ERC-20 standard is. ERC-20 is a technical standard for smart contracts on the Ethereum blockchain that defines a common set of rules for creating, managing, and transferring tokens on the Ethereum network. This standard makes it easier for developers to create and manage tokens, as well as for wallets and exchanges to interact with them.

A token, in the context of blockchain technology, refers to a digital asset that can be traded or transferred on a blockchain network. Tokens are typically used as a means of exchange or as a representation of ownership or access rights on a blockchain platform. Tokens can be created and managed using smart contracts, which are self-executing contracts with the terms of the agreement written directly into code.

Solidity is a programming language specifically designed for writing smart contracts on the Ethereum blockchain. It is similar to other programming languages such as JavaScript and C++, but it has additional features and syntax that make it well-suited for developing smart contracts on Ethereum.

Implementation

Now, let's take a look at the code.

pragma solidity ^0.7.0;
`contract Token {
    // The name of the token
    string public name;

    // The symbol of the token
    string public symbol;

    // The number of decimal places for the token
    uint8 public decimals;

    // The total supply of the token
    uint256 public totalSupply;

    // Mapping from addresses to their token balance
    mapping (address => uint256) public balanceOf;

    // Event for when tokens are transferred
    event Transfer(address indexed from, address indexed to, uint256 value);

    // Initialize the token with a name, symbol, and number of decimal places
    constructor(string memory _name, string memory _symbol, uint8 _decimals, uint256 _totalSupply) public {
        name = _name;
        symbol = _symbol;
        decimals = _decimals;
        totalSupply = _totalSupply;
        balanceOf[msg.sender] = _totalSupply;
    }

    // Transfer tokens from one address to another
    function transfer(address _to, uint256 _value) public {
        require(balanceOf[msg.sender] >= _value && _value > 0);
        balanceOf[msg.sender] -= _value;
        balanceOf[_to] += _value;
        emit Transfer(msg.sender, _to, _value);
    }
}
 `

This code defines a basic token contract with the following features:

A name, symbol, and number of decimal places for the token
A total supply of the token
A mapping from addresses to their token balance
A transfer function that allows for the transfer of tokens from one address to another

The constructor function is called when the contract is first deployed to the blockchain. It takes in the token's name, symbol, number of decimal places, and total supply as parameters. It sets these values as public variables and assigns the total supply of tokens to the address that deployed the contract.

The transfer function allows for the transfer of tokens from one address to another. The function takes in the address of the recipient, _to, and the number of tokens to be transferred, _value. It first checks that the sender has enough tokens and that a non-zero value is being transferred using the require statement. If the check passes, it updates the balance of the sender and recipient and emits a Transfer event, which can be used for logging or other purposes.

Vulnerabilities and Security measures

This code is a basic implementation of a token contract using Solidity, but in a real-world scenario, several security measures should be taken into account. One of the main risks is the potential for unauthorized access or theft of tokens through malicious attacks or bugs in the contract code.
To mitigate these risks, some best practices should be applied:

Use the latest version of solidity
Use open-source libraries such as OpenZeppelin
Carefully test the code and perform code review
Keep track of vulnerabilities and upgrade the contract
Use a secure way to manage your private keys
For instance, in the previous code, the transfer function doesn't include the check of the recipient address, if the address is invalid, the token will be locked forever. Also, the code doesn’t include any restriction to mint new tokens, a malicious attacker could create as many tokens as they want to. By using OpenZeppelin library and its SafeMath library, we can check that all the values passed to the contract and internal calculations are in the correct range and address checks, and restriction of minting new tokens.

`pragma solidity ^0.8.17;

import "https://github.com/OpenZeppelin/openzeppelin-contracts/contracts/token/ERC20/SafeERC20.sol";
import "https://github.com/OpenZeppelin/openzeppelin-contracts/contracts/math/SafeMath.sol";

contract Token is SafeERC20 {
    using SafeMath for uint256;
    // The name of the token
    string public name;

    // The symbol of the token
    string public symbol;

    // The number of decimal places for the token
    uint8 public decimals;

    // The total supply of the token
    uint256 public totalSupply;

    // Mapping from addresses to their token balance
    mapping (address => uint256) public balanceOf;

    // Event for when tokens are transferred
    event Transfer(address indexed from, address indexed to, uint256 value);

    // Initialize the token with a name, symbol, and number of decimal places
    constructor(string memory _name, string memory _symbol, uint8 _decimals, uint256 _totalSupply) public {
        require(_totalSupply <= 2**256 - 1); // check totalSupply within range
        require(_decimals <= 18); // check decimal places within range
        name = _name;
        symbol = _symbol;
        decimals = _decimals;
        totalSupply = _totalSupply;
        balanceOf[msg.sender] = _totalSupply;
    }

    // Transfer tokens from one address to another
    function transfer(address payable _to, uint256 _value) public {
        require(_to != address(0)); // check recipient address is not the null address
        require(_value > 0); // check value is greater than 0
        require(balanceOf[msg.sender] >= _value); // check sender has sufficient balance
        balanceOf[msg.sender] = balanceOf[msg.sender].sub(_value); // decrease sender balance
        balanceOf[_to] = balanceOf[_to].add(_value); // increase recipient balance
        emit Transfer(msg.sender, _to, _value);
    }

    function mint(address _to, uint256 _amount) public onlyOwner {
        require(_amount > 0);
        totalSupply = totalSupply.add(_amount);
        balanceOf[_to] = balanceOf[_to].add(_amount);
        emit Transfer(address(0), _to, _amount);
    }

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

}
 `

Explanation

In this revised version of the code, several security improvements have been made to ensure the proper functioning of the contract and the protection of token holders:

The contract inherits from the SafeERC20 contract from the OpenZeppelin library, which provides a number of security-related functions such as require that recipient address is not the null address and require that value is greater than zero.
The use of the SafeMath library for handling uint256 arithmetic operations to prevent overflow/underflow errors
check totalSupply within range , check decimal places within range, check sender has sufficient balance
The mint function can only be called by the contract's owner, and this is controlled by the onlyOwner modifier which checks that the msg.sender is the contract's owner before executing the function
The owner variable is added, which stores the address of the contract's owner and can be modified by the contract's owner only.
The transfer function's parameter _to is payable, it means that ether can be sent alongside the token transfer.

These improvements add an additional layer of security to the contract, reducing the risk of unauthorized access or theft of tokens. By inheriting from the SafeERC20 contract, the contract is automatically compliant with the ERC-20 standard and can be easily integrated with other contracts and wallets that also adhere to the standard. Additionally, the use of the SafeMath library and the added checks and validation make the contract more robust against potential bugs and malicious attacks.

Conclusion

In conclusion, token contracts using Solidity are a common task in the blockchain development. Implementing a basic ERC-20 compliant token contract using Solidity is relatively simple. However, it is important to consider security measures to mitigate the risks of unauthorized access or theft of tokens. By using best practices and libraries such as OpenZeppelin, developers can create secure and robust smart contracts. It is crucial to thoroughly test and audit the contract code before deployment to the mainnet, to ensure that the code is as secure as possible and minimize the risk of potential vulnerabilities.

Blockchain Transactions

Yao Marius SODOKIN — Fri, 25 Nov 2022 16:12:40 +0000

Blockchain technology represents a new generation of software that improves business processes. The financial industry is beginning to realize its potential after decades of investing in in-house software.
This technology makes transactions more reliable and should therefore offer multiple applications in banking, with a very good return on investment.
But implementing this technology is a challenge: companies cannot implement it alone. They must collaborate differently and more actively with their consumers, suppliers, and competitors. In this article I’m going to talk about transactions flow between parties in blockchain.

Definition

Blockchain is a peer-to-peer, distributed ledger that
is cryptographically secure, append-only, immutable extremely hard to change), and updateable only via consensus or agreement among peers.

Transactions steps

Step 1: Operation Initiated
Let's follow the step with a basic Ether transaction. If Alicia wants to send Billy some bitcoin, she would go to a Ether wallet application either on her phone or computer where she has some Ether stored. Wallet applications are usually free downloads that create a digital wallet to purchase and/or store your cryptocurrency.

It is worth mentioning here that cryptocurrencies are a function of a particular blockchain, the Etherreum blockchain only transacts bitcoin and the Ethereum blockchain can only exchange Ether. To initiate the transaction, Alicia would make a request of the system to send Ether to Billy’s wallet by specifying the amount and Billy’s Ether address.

Step 2: Smart Contract Triggered
When Alicia sends her transaction to the network, it triggers a smart contract that checks with the nodes on the network to make sure Alicia has the currency to spend, and that she hasn't already spent it. Once checked, the transaction is added to a proposed block.

step 3 :Operators Spread Transaction :
Proposed block is communicated to the network through the peer-to-peer protocols.

Step 4: Consensus
In order for the Etherreum network to validate a block, nodes or miners must validate the correctness of a block by completing a math problem first. The node that completes consensus algorithm equation first is rewarded with some newly minted Ether. Once a solution for the equation is reached, the other nodes can easily check its accuracy, thereby accepting the new block onto the blockchain.

Step 5: Spread The New Block
This block is spread throughout the network through the same peer-to-peer communications we used for the transaction. When block operators receive a copy of the new block, they add it to their copy of the distributed ledger. This guarantees that all members of the peer network agree on the current state of the blockchain’s distributed ledger.

Step 6: Transaction Completed
The user’s wallet monitors for the creation of new blocks that include transactions associated with the user. When a block containing the completed code from the user’s operation is received, an event is created to notify the user that the operation is complete. When the block containing Alicia’s Ether transfer to Billy is added to the blockchain, an alert will be sent to the affected wallets that the transaction was accepted and completed.

Consensus in blockchain

Consensus is a distributed computing concept that has been used in blockchain in order to provide a means of agreeing to a single version of the truth by all peers on the blockchain
network.

Consensus Categories

Roughly, the following describes the two main categories of consensus mechanisms:

1. Proof-based, leader-election lottery-based : , or the Nakamoto consensus whereby a leader is elected at random (using an algorithm) and proposes a final value. This
category is also referred to as the fully decentralized or permissionless type of consensus mechanism. This type is well used in the Bitcoin and Ethereum blockchain in the form of a PoW mechanism.

2. Byzantine fault tolerance (BFT)-based is a more traditional approach based on rounds of votes. This class of consensus is also known as the consortium or permissioned type of consensus mechanism. BFT-based consensus mechanisms perform well when there are a limited number of nodes, but they do not scale well. On the other hand, leader-election lottery-based (PoW) consensus mechanisms scale very well but perform very slowly. As there is significant research being
conducted in this area, new types of consensus mechanisms are also emerging, such as the semi-decentralized type, which is used in the Ripple network.

Consensus Algorithms

The consensus algorithms available today, or that are being researched in the context of blockchain, are presented as follows. The following is not an exhaustive list, but it includes all notable algorithms:

• Proof of Work (PoW): This type of consensus mechanism relies on proof that adequate computational resources have been spent before proposing a value for acceptance by the
network. This scheme is used in Bitcoin, Litecoin, and other cryptocurrency blockchains. Currently, it is the only algorithm that has proven to be astonishingly successful against any collusion attacks on a blockchain network, such as the Sybil attack.

• Proof of Stake (PoS): This algorithm works on the idea that a node or user has an adequate stake in the system; that is, the user has invested enough in the system so that any malicious attempt by that user would outweigh the benefits of performing such an attack on the network. This idea was first introduced by Peercoin, and it is going to be used in the Ethereum blockchain version called Serenity. Another important concept in PoS is coin age, which is a criterion derived from the amount of time and number of coins that have not been spent. In this model, the chances of proposing and signing the
next block increase with the coin age.

• Delegated Proof of Stake (DPoS): This is an innovation over standard PoS, whereby
each node that has a stake in the system can delegate the validation of a transaction to
other nodes by voting. It is used in the BitShares blockchain.
• Proof of Elapsed Time (PoET): Introduced by Intel in 2016, PoET uses a Trusted Execution Environment (TEE) to provide randomness and safety in the leader- election process via a guaranteed wait time. It requires the Intel SGX (Software Guard Extensions) processor to provide the security guarantee for it to be secure.

•** Proof of Deposit (PoD):** In this case, nodes that wish to participate in the network have to make a security deposit before they can mine and propose blocks. This mechanism is used in the Tendermint blockchain.

•** Proof of Importance (PoI): **This idea is significant and different from PoS. PoI not only
relies on how large a stake a user has in the system, but it also monitors the usage and movement of tokens by the user in order to establish a level of trust and importance. It is used in the NEM coin blockchain.

•** Federated consensus or federated Byzantine consensus:** This mechanism is used in the stellar consensus protocol. Nodes in this protocol retain a group of publicly-trusted peers and propagate only those transactions that have been validated by the majority of trusted nodes.

• Reputation-based mechanisms: As the name suggests, a leader is elected by the reputation it has built over time on the network. It is based on the votes of other members.

• Practical Byzantine Fault Tolerance (PBFT): This mechanism achieves SMR, which provides tolerance against Byzantine nodes. Various other protocols, including PBFT,
PAXOS, RAFT, and Federated Byzantine Agreement (FBA), are also being used or have been proposed for use in many different implementations of distributed systems and
blockchains.
• Proof of Activity (PoA): This scheme is a combination of PoS and PoW, which ensures
that a stakeholder is selected in a pseudorandom but uniform fashion. This is a comparatively more energy-efficient mechanism as compared to PoW. It utilizes a new concept called "Follow the Satoshi." In this scheme, PoW and PoS are combined together to achieve consensus and a good level of security.

• Proof of Capacity (PoC): This scheme uses hard disk space as a resource to mine the blocks. This is different from PoW, where CPU resources are used. In PoC, hard disk
space is utilized for mining and, as such, is also known as hard drive mining.

• Proof of Storage: This scheme allows for the outsourcing of storage capacity. This scheme is based on the concept that a particular piece of data is probably stored by
a node, which serves as a means to participate in the consensus mechanism. Several variations of this scheme have been proposed, such as Proof of Replication, Proof of Data Possession, Proof of Space, and Proof of Space-time.

• Proof of Authority (PoA): This scheme utilizes the identity of the participants called validators as a stake on the network. Validators are known and have the authority
to propose new blocks. Validators propose the new blocks and validate them as per blockchain rules. Commonly used PoA algorithms are Clique and Aura.

Smart Contracts

Definition
A smart contract is a secure and unstoppable computer program representing an agreement that is
automatically executable and enforceable.

Smart Contract explained in details : They are computer programs that execute an action based on terms and conditions.
Can also be known as chain code.
Smart contracts have terms recorded in a computer language instead of legal language. Smart contracts are not necessarily legally binding and do not need multiple participants.
Each step of a smart contract can only be implemented after the execution of the immediate former step.
Smart contracts are written in Solidity, a programming language designed for developing smart contracts that run on the Ethereum Virtual Machine.
The smart contracts act as a foundation to build decentralized applications (DApps).
Once executed, the information in the smart contract is stored on a blockchain which cannot be altered.


Smart contracts  features

Accuracy
Replacing human intermediaries with executable code ensures the process will always be performed the same.
Cost savings
Replacing intermediaries often provides significant cost reduction.
Efficiency
Removing process intermediaries often results in significant process efficiency gains.
Backup
A blockchain and smart contract deployed to it can provide a permanent record, allowing for auditing, insight, and traceability, even if the creator is no longer in business.
Autonomy
Smart contracts can be developed by anyone, no need for intermediaries such as lawyers, brokers, or auditors.


Smart Contracts properties

In summary, a smart contract has the following properties:
Automatically executable: It is self-executable on a blockchain without requiring any intervention.

Enforceable: **This means that all contract conditions are enforced automatically.
**Secure: This means that smart contracts are tamper-proof (or tamper-resistant) and run with security guarantees. The underlying blockchain usually provides these security guarantees; however, the smart contract programing language and the smart contract code themselves must be correct, valid, and verified.

Deterministic: The deterministic feature ensures that smart contracts always produce the same output for a specific input. Even though it can be considered to be part of the
secure property, defining it here separately ensures that the deterministic property is considered one of the important properties.

Semantically sound: This means that they are complete and meaningful to both people and computers.
** Unstoppable:** This means that adversaries or unfavorable conditions cannot negatively affect the execution of a smart contract. When the smart contracts execute, they complete
their performance deterministically in a finite amount of time.

@aya