DEV Community: Axat Bhardwaj

Events In EVM

Axat Bhardwaj — Tue, 20 Dec 2022 05:47:46 +0000

Events

Solidity events give an abstraction on top of the EVM’s logging functionality. Applications can subscribe and listen to these events through the RPC interface of an Ethereum client.

In the traditional world, applications often use logs to capture and describe what’s going on at a specific moment. These logs are often used to debug applications, detect specific events, or notify the viewer of the logs that something happened. It turns out they are also very useful when writing or interacting with smart contracts!

💡 The Ethereum Virtual Machine (EVM) has a logging function
that is used to write data, including Solidity events, to a structure
outside smart contracts.

Syntax

event Deposit(address indexed from,bytes32 indexed id,uint value;

Logs and events are often referred to anonymously. Events allow you to ‘print’ information to the logging structure in a way that is more gas-efficient since the information is not stored in a storage variable, which takes up more gas. Events, or logs, live in the Transaction Receipts trie, which is inaccessible to smart contracts.

Events are inheritable members of contracts. When you call them, they cause the arguments to be stored in the transaction’s log - a special data structure in the blockchain. These logs are associated with the address of the contract, are incorporated into the blockchain, and stay there as long as a block is accessible (forever as of now, but this might change with Serenity). The Log and its event data is not accessible from within contracts (not even from the contract that created them).

💡 To put it simply, events are ways to communicate with a client application or front-end website that something has happened on the blockchain.

Logging in Ethereum

The EVM currently has 5 opcodes for emitting event logs: LOG0, LOG1, LOG2, LOG3, and LOG4.

These opcodes can be used to create log records. A log record can be used to describe an event within a smart contract, like a token transfer or a change of ownership.

Ethereum Yellowpaper — Byzantium Version 69351d5 (2018-12-10)

💡 Each log record consists of both topics and data.

Topics are 32-byte (256 bit) “words” that are used to describe what’s going on in an event. Different opcodes (LOG0 … LOG4) are needed to describe the number of topics that need to be included in the log record. For instance, LOG1 includes one topic, while LOG4 includes four topics. Therefore, the maximum number of topics that can be included in a single log record is four.

Topics in Ethereum Log Records

The first part of a log record consists of an array of topics. These topics are used to describe the event.

A topic can only hold a single word (32 bytes)Then they appear in the structure of topics, not the data portion of the log. When parameters do not have the indexed attributes, they are ABI-encoded into the data portion of the log.

Since topics can only hold a maximum of 32 bytes of data, things like arrays or strings cannot be used as topics reliably. Instead, it should be included as data in the log record, not as a topic. If you were to try including a topic that’s larger than 32 bytes, the topic will be hashed instead. As a result, this hash can only be reversed if you know the original input. In conclusion, topics should only reliably be used for data that strongly narrows down search queries (like addresses)

Data in Ethereum Log Records

The second part of a log record consists of additional data. Topics and data work best together as there are upsides and downsides to each. For example, while topics are searchable, data is not. But, including data is a lot cheaper than including topics. Additionally, while topics are limited to 4 * 32 bytes, event data is not, which means it can include large or complicated data like arrays or strings. Therefore, the event data (if any) can be seen as the value.

Indexed Events

Solidity events are interfaces with EVM logging functionality.

You can add an attribute indexed to up to three parameters. which adds them to “topics” instead of the data part of the log.

All parameters without the indexed attribute are ABI-encoded into the data part of the log.

Anonymous Events

The first topic usually consists of the signature (a keccak256 hash) of the name of the event that occurred, including the types (uint256, string, etc.) of its parameters.One exception where this signature is not included as the first topic is when emitting anonymous events

The hash of the signature of the event is one of the topics, except if you declared the event with the anonymous specifier.

This means that it is not possible to filter for specific anonymous events by name, you can only filter by the contract address.

💡 The advantage of anonymous events is that they are cheaper to deploy and call. It also allows you to declare four indexed arguments rather than three.

💡 The base cost of logging operations is 375 gas
. On top of that, every included topic costs an additional 375 gas
. Finally, each byte of data costs 8 gas

Logs are an elegant way to store tiny amounts of data on the Ethereum blockchain for a small price. Specifically, event logs are useful to let other people know something has happened without them having to query contracts individually.

Axat Bhardwaj
Blockchain Engineer

Gas Optimization In Solidity

Axat Bhardwaj — Fri, 16 Dec 2022 16:25:38 +0000

EVM Gas optimization tricks

Main Gas optimization areas in solidity

Storage
Variables
Functions
Loops
Operations

Storage

Saving one variable in storage costs 20,000 gas (Check gas used by EVM opcodes)
5,000 gas when we rewrite the variable
reading from the slot take 200 gas
But storage variable declaration doesn't cost anything, as there's no initialization

Tips

always save a storage variable in memory in a function
if you wanna update a storage variable then first calculate everything in the memory variables
organize & try to pack two or more storage variables into one it's much cheaper
also while using structs, try to pack them

Refunds

Free storage slot by zeroing corresponding variables as soon as you don't need them anymore. This will refund 15,000 of gas.
Removing a contract by using Selfdestruct opcodes refunds 24,000 gas. But a refund must not surpass half the gas that the ongoing contract call uses.

Data types and packing

Use bytes32 whenever possible, because it is the most optimized storage type.
If the length of bytes can be limited, use the lowest amount possible from bytes1 to bytes32.
Using bytes32 is cheaper than using string
Variable packing only occurs in storage — memory and call data does not get packed.
You will not save space trying to pack function arguments or local variables
Storing a small number in a uint8 variable is not cheaper than storing it in uint256 because the number in uint8 is padded with numbers to fill 32 bytes.

Inheritance

when we extend a contract, the variables in the child can be packed with the variables in the parent.
The order of variables is determined by C3 linearization, all you need to know is that child variables come after parent variables.

Memory vs Storage

copying between the memory and storage will cost some gas, so don't copy arrays from storage to memory, use a storage pointer.
the cost of memory is complicated. you "buy" it in chunks, the cost of which will go up quadratically after a while
Try adjusting the location of your variables by playing with the keywords "storage" and "memory". Depending on the size and number of copying operations between Storage and memory, switching to memory may or may not give improvements. All this is because of varying memory costs. So optimizing here is not that obvious and every case has to be considered individually.

Variables

Avoid public variables
Use global variables efficiently
it is good to use global variables with private visibility as it saves gas
Use events rather than storing data
Use memory arrays efficiently
Use return values efficiently
A simple optimization in Solidity consists of naming the return value of a function. It is not needed to create a local variable then.

Mapping vs Array

Use mapping whenever possible, it's cheap instead of the array
But an array could be a good choice if you have a small array

Fixed vs Dynamic

Fixed size variables are always cheaper than dynamic ones.
It's good to use memory arrays if the size of the array is known, fixed-size memory arrays can be used to save gas.
If we know how long an array should be, we specify a fixed size
This same rule applies to strings. A string or bytes variable is dynamically sized; we should use a byte32 if our string is short enough to fit.
If we absolutely need a dynamic array, it is best to structure our functions to be additive instead of subtractive. Extending an array costs constant gas whereas truncating an array costs linear gas.

Functions

use external most of the time whenever possible
Each position will have an extra 22 gas, so
- Reduce public variables
- Put often-called functions earlier
reduce the parameters if possible (Bigger input data increases gas because more things will be stored in memory)
payable function saves some gas as compared to non-payable functions (as the compiler won't have to check)

View Functions

You are not paying for view functions but this doesn't mean they aren't consuming gas, they do.
it cost gas when calling in a tx

Loops

use memory variables in loops
try to avoid unbounded loops
write uint256 index; instead of writing uint256 index = 0; as being a uint256, it will be 0 by default so you can save some gas by avoiding initialization.
if you put ++ before i it costs less gas

Operations

Order

Order cheap functions before
- f(x) is cheap
- g(y) is expensive
- ordering should be
- f(x) || g(y)
- f(x) && g(y)

Use Short-Circuiting rules to your advantage

When using logical disjunction (||), logical conjunction (&&), make sure to order your functions correctly for optimal gas usage. In logical disjunction (OR), if the first function resolves to true, the second one won’t be executed and hence save you gas. In logical disjunction (AND), if the first function evaluates to false, the next function won’t be evaluated. Therefore, you should order your functions accordingly in your solidity code to reduce the probability of needing to evaluate the second function.

Using unchecked

Use unchecked for arithmetic where you are sure it won't over or underflow, saving gas costs for checks added from solidity v0.8.0.

Other Optimizations

Remove the dead code
Use different solidity versions and try
EXTCODESIZE is quite expensive, this is used for calls between contracts, the only option we see to optimize the code in this regard is minimizing the number of calls to other contracts and libraries.

Libraries

When a public function of a library is called, the bytecode of that function is not made part of a client contract. Thus, complex logic should be put in libraries (but there is also the cost of calling the library function)

Errors

Use "require" for all runtime conditions validations that can't be prevalidated on the compile time. And "assert" should be used only for static validation that normally fails never fail on a properly functioning code.
string size in require statements can be shortened to reduce gas.
A failing "assert" consumer all the gas available to the call, while "require" doesn't consume any.

Hash functions

keccak256: 30 gas + 6 gas for each word of input data
sha256: 60 gas + 12 gas for each word of input data
ripemd160: 600 gas + 120 gas for each word of input data
So if you don't have any specific reasons to select another hash function, just use keccak256

Use ERC1167 To Deploy the same Contract many times

EIP1167 minimal proxy contract is a standardized, gas-efficient way to deploy a bunch of contract clones from a factory.EIP1167 not only minimizes length, but it is also literally a “minimal” proxy that does nothing but proxying. It minimizes trust. Unlike other upgradable proxy contracts that rely on the honesty of their administrator (who can change the implementation), the address in EIP1167 is hardcoded in bytecode and remain unchangeable

Merkle proof

A Merkle tree can be used to prove the validity of a large amount of data using a small amount of data.

Tools for estimating gas

Remix
Truffle
Eth Gas reporter

Happy Learning !!

Axat Bhardwaj
Blockchain Engineer

Tron Private network setup (Complete guide 2022)

Axat Bhardwaj — Tue, 10 May 2022 06:15:04 +0000

Tron network setup

Prereq

Have necessary pre req installs

I have used Ubuntu as my host OS

sudo apt-get -y install apt-transport-https ca-certificates
sudo apt-get install -y build-essential checkinstall libssl-dev

mkdir ~/nftron
cd ~/nftron

copy paste in the current shell

echo 'JDK_MD5="0029351f7a946f6c05b582100c7d45b7"
JDK_DIR="jdk1.8.0_202"
JDK_TAR="jdk-8u202-linux-x64.tar.gz"
JAVA_HOME=/usr/local/$JDK_DIR
CLASSPATH=$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
export PATH=$PATH:$JAVA_HOME/bin
export CLASSPATH=$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar
export JAVA_HOME=/usr/local/$JDK_DIR' > .envs

source .envs

Lets install Java

sudo wget -P /usr/local <https://github.com/frekele/oracle-java/releases/download/8u202-b08/$JDK_TAR>

echo "Ensure you have "OK" status for chksum"

sudo echo "$JDK_MD5 /usr/local/$JDK_TAR" | md5sum -c
sudo tar -zxf /usr/local/$JDK_TAR -C /usr/local

We will move with three tron repos for now,
1, Tron private network Deployment -
git clone <https://github.com/tronprotocol/java-tron.git>

2, Tron wallet address creation
git clone <https://github.com/tronprotocol/wallet-cli.git>

3, Tronbox for compiler & smart contract deployment , equalent to truffle

git clone <https://github.com/tronprotocol/tronbox.git>

or
you can use npm install -g tronbox

1. Now you have set all prerequisites, we will build tron network now

echo  "Building the  Source code "

cd ~/nftron/java-tron
./gradlew build

mkdir srnode
cd srnode
cp ~/nftron/java-tron/build/libs/FullNode.jar .
cp ~/nftron/java-tron/build/libs/SolidityNode.jar .
cp ~/nftron/java-tron/framework/build/resources/main/config.conf .

Lets start the node

java -jar ./FullNode.jar --witness -c ../config.conf

To start Solidity node (optional)

java -jar ./FullNode.jar  -c ../config.conf

2. Now lets start wallet -cli

Clone the repo from above link

cd ~/nftron/wallet-cli
cp src/main/resources/config.conf ~/nftron/wallet-cli/

#Modify the config.conf in src/main/resources with the fullnode/solidity details.
ie. port number or ip address if its different ec2 instance.

./gradlew build

now you can run the wallet

java -jar build/libs/wallet-cli.jar

1, Register wallet

registerwallet user1
(input your complex password)

2, login with register user

login user1

3, generate the account for tests

generateaddress

{
"address": "27abQWJo3mc2b6kRY8Dng8ZzE7GWGpNgFpF",
"privateKey": "f70c5503e6f7e83a76f12373ddb478bfd04f10b4f78de5046a7dc75532f84c81"
}

3. Now lets do with Tronbox for solidity code deployment on the private network

You can clone the repo or use npm commands to install

npm install  -g tronbox
mkdir samplecode
cd samplecode
tronbox init

Note : Edit the tronbox.js file and update the fullnode ip address and port and private key in developement
tronbox.js

Use the below solidity sample contracts, just copy paste in the current shell

echo 'pragma solidity >=0.4.23 <0.9.0;
contract Test{
function f() public pure returns (string memory){
return "method f()";
}
function g() public pure returns (string memory){
return "method g()";
}
}' > samplecode/contracts/Test.sol

echo 'var Test = artifacts.require("./Test.sol");
var Migrations = artifacts.require("./Migrations.sol");

module.exports = function(deployer) {

deployer.deploy(Test);
deployer.deploy(Migrations);
}; '  > samplecode/migrations/2_deploy_contracts.js

Lets compile and migrate

tronbox compile
tronbox migrate --network development

Cheers !!
Axat Bhardwaj
Blockchain Developer & Technologist
https://www.linkedin.com/in/axatbhardwaj

The Tron protocol (Blockchain) a Deep Dive in 2022

Axat Bhardwaj — Mon, 09 May 2022 21:25:48 +0000

TRON

The TRON Protocol, one of the largest blockchain-based operating systems in the
world, offers public blockchain support of high throughput, high scalability, and high availability for
all Decentralized Applications (DApps) in the TRON ecosystem

Progression from inception of project

The TRON Foundation was established in July 2017 in Singapore.
In December 2017, TRON had launched its open source protocol. The Testnet, Blockchain Explorer, and Web Wallet were all launched by March 2018.
TRON Mainnet launched shortly afterward in May 2018, marking the Odyssey 2.0 release as a technical milestone.
In June 2018, TRON declared its independence with the creation of the Genesis block, along with the July 2018 acquisition of BitTorrent.
In October 2018, TRON launched the TRON Virtual Machine (TVM), a complete developers’ toolset, and 360 support system. The TRON roadmap involves combining BitTorrent’s 100 million users with the TRON network via Project Atlas, as well as fostering the developer community to launch exciting new DApps on the TRON network.

Architecture

💡 The Following article is by the founder of the TRON himself so have a look at it ,

The TRON Blockchain's Technical Architecture | Gemini

💡 The below link is for the architecture of tron (official PDF)

TRON adopts a 3-layer architecture divided into Storage Layer, Core Layer, and Application Layer.

The TRON protocol adheres to Google Protobuf, which intrinsically supports multi-language
extension

Diagram of 3 layer architecture of Tron

3-layers

Core Layer

There are several modules in the core layer, including smart contracts, account management, and
consensus. A stack-based virtual machine is implemented on TRON and an optimized instruction
set is used. In order to better support DApp developers, Solidity was chosen as the smart contract
language, followed by future support of other advanced languages. In addition, TRON's consensus
mechanism is based on Delegated Proof of Stake (DPoS) and many innovations were made in
order to meet its unique requirements.

Storage Layer

TRON designed a unique distributed storage protocol consisting of Block Storage and State
Storage. The notion of a graph database was introduced into the design of the storage layer to
better meet the need for diversified data storage in the real world

Blockchain Storage :- TRON blockchain storage chooses to use LevelDB, which is developed by Google and proven successful with many companies and projects. It has high performance and supports arbitrary byte arrays as both keys and values, singular get, put and delete, batched put and delete, bi-directional iterators, and simple compression using the very fast Snappy algorithm.
State Storage :- TRON has a KhaosDB in the full-node memory that can store all the newly forked chains generated within a certain period of time and supports witnesses to switch from their own active chain swiftly into a new main chain. It can also protect blockchain storage by making it more stable from being terminating abnormally in an intermediate state.

Application Layer

Developers can create a diverse range of DApps and customized wallets on TRON. Since TRON
enables smart contracts to be deployed and executed, the opportunities of utility applications are unlimited.

Protocol

TRON protocol adheres to Google Protocol Buffers, which is a language-neutral, platform-neutral,
and extensible way of serializing structured data for use in communications protocols, data storage,
and more.

What are protocol Buffers ?

Protocol Buffers (Protobuf) is a flexible, efficient, automated mechanism for serializing structured
data, similar to JSON or XML, but much smaller, faster and simpler.
Protobuf (.proto) definitions can be used to generate code for C++, Java, C#, Python, Ruby,
Golang, and Objective-C languages through the official code generators. Various third-party
implementations are also available for many other languages. Protobuf eases development for
clients by unifying the API definitions and also optimizing data transfers. Clients can take the API
.proto from TRON’s protocol repository and integrate through the automatically-generated code
libraries.
As a comparison, Protocol Buffers is 3 to 10 times smaller and 20 to 100 times faster than XML,
with less ambiguous syntax. Protobuf generates data access classes that are easier to use
programmatically.

Decentralized Exchange (DEX)

The TRON network natively supports decentralized exchange functions. A decentralized exchange
consists of multiple trading pairs. A trading pair (notation “Exchange”) is an Exchange Market
between TRC-10 tokens, or between a TRC-10 token and TRX. Any account can create a trading
pair between any tokens, even if the same pair already exists on the TRON network. Trading and price fluctuations of the trading pairs follow the Bancor Protocol. The TRON network stipulates that the weights of the two tokens in all trading pairs are equal, so the ratio of their balances is the price between them.

💡 The TRON blockchain code is implemented in Java and was originally a fork from EthereumJ.

Consensus

The Tron Uses DPoS

Delegated Proof of Stake (DPoS)

In PoS networks, token holders lock their token balances to become block
validators. The validators take turns proposing and voting on the next block. However, the problem
with standard PoS is that validator influence correlates directly to the amount of tokens locked up.
This results in parties hoarding large amounts of the network’s base currency wielding undue
influence in the network ecosystem.

The TRON consensus mechanism uses an innovative Delegated Proof of Stake system in which 27
Super Representatives (SRs) produce blocks for the network. Every 6 hours, TRX account holders
who freeze their accounts can vote for a selection of SR candidates, with the top 27 candidates
deemed the SRs. Voters may choose SRs based on criteria such as projects sponsored by SRs to increase TRX adoption, and rewards distributed to voters. This allows for a more democratized and decentralized ecosystem. SRs’ accounts are normal accounts, but their accumulation of votes
allows them to produce blocks. With the low throughput rates of Bitcoin and Ethereum due to their PoW consensus mechanism and scalability issues, TRON’s DPoS system offers an innovative mechanism resulting in 2000 TPS compared to Bitcoin’s 3 TPS and Ethereum’s 15 TPS.
The TRON protocol network generates one block every three seconds, with each block awarding 32
TRX to Super Representatives. A total of 336,384,000 TRX will be awarded annually to the 27 SRs.
Each time an SR finishes block production, rewards are sent to a sub-account in the super-ledger.
SRs can check, but not directly make use of these TRX tokens. A withdrawal can be made by each
SR once every 24 hours, transferring the rewards from the sub-account to the specified SR account.

For more details refer to this :-

The Basics of TRON's DPoS Consensus Algorithm

The three types of nodes on the TRON network are Witness Node, Full Node, and Solidity Node.

Witness nodes are set up by SRs and are mainly responsible for block production and proposal creation/voting.
Full nodes provide APIs and broadcast transactions and blocks.
Solidity nodes sync blocks from other Full Nodes and also provide indexable APIs.

💡 SR = Super Representative(Block Producers)

Account

Types

The three types of accounts in the TRON network are regular accounts, token accounts, and
contract accounts.
1.Regular accounts are used for standard transactions.

2.Token accounts are used for storing TRC-10 tokens.

3.Contract accounts are smart contract accounts created by regular accounts and can be triggered by regular accounts as well.

Creation

There are three ways to create a TRON account:

Create a new account through API
Transfer TRX into a new account address
Transfer any TRC-10 token into a new account address

Structure

account_name: the name for this account – e.g. BillsAccount.
type: what type of this account is – e.g. 0 (stands for type ‘Normal’).
balance: balance of this account – e.g. 4213312. 16
vote: received votes on this account – e.g. {(“0x1b7w...9xj3”,323), (“0x8djq...j12m”,88),...,(“0x82nd...mx6i”,10001)}.
asset: other assets expected TRX in this account – e.g. {<“WishToken”, 66666>, <”Dogie”, 233>}.
latest_operation_time: the latest operation time of this account.

message Account {
message Vote {
bytes vote_address = 1;
int64 vote_count = 2;
}
bytes accout_name = 1;
AccountType type = 2;
bytes address = 3;
int64 balance = 4;
repeated Vote votes = 5;
map<string, int64> asset = 6;
int64 latest_operation_time = 10;
}
enum AccountType {
Normal = 0;
AssetIssue = 1;
Contract = 2;
}

Block

A block typically contains a block header and several transactions.

message Block {
BlockHeader block_header = 1;
repeated Transaction transactions = 2;
}

Block Header

Raw data is denoted as raw_data in Protobuf. It contains the raw data of a message,containing 6 parameters:

timestamp: timestamp of this message – e.g. 1543884429000.
txTrieRoot: the Merkle Tree’s Root – e.g. 7dacsa...3ed.
parentHash: the hash of the last block – e.g. 7dacsa...3ed.
number: the block height – e.g. 4638708.
version: reserved – e.g. 5.
witness_address: the address of the witness packed in this block – e.g. 41928c...4d21.

message BlockHeader {
message raw {
int64 timestamp = 1;
bytes txTrieRoot = 2;
bytes parentHash = 3;
uint64 number = 4;
uint64 version = 5;
bytes witness_address = 6;
}
bytes witness_signature = 2
;
bytes blockID = 3;
}

💡 Witness signature is denoted as witness_signature in Protobuf, which is the signature for this block header from the witness node.

💡 Block ID is denoted as blockID in Protobuf. It contains the atomic identification of a block. A Block
ID contains 2 parameters:
hash: the hash of block.
number: the hash and height of the block.

Transactions

Signing :-

TRON’s transaction signing process follows a standard ECDSA cryptographic algorithm, with a SECP256K1 selection curve. A private key is a random number, and the public key is a point on the elliptic curve. The public key generation process consists of first generating a random number as a
private key, and then multiplying the base point of the elliptic curve by the private key to obtain the public key. When a transaction occurs, the transaction raw data is first converted into byte format.
The raw data then undergoes SHA-256 hashing. The private key corresponding to the contract
address then signs the result of the SHA256 hash. The signature result is then added to the transaction.

Bandwidth Model :-

Ordinary transactions only consume bandwidth points, but smart contract operations consume both
energy and bandwidth points. There are two types of bandwidth points available. Users can gain
bandwidth points from freezing TRX, while 5000 free bandwidth points are also available daily.

When a TRX transaction is broadcast, it is transmitted and stored in the form of a byte array over the network. Bandwidth Points consumed by one transaction = number of transaction bytes multiplied by bandwidth points rate. For example, if the byte array length of a transaction is 200,then the transaction consumes 200 bandwidth points. However, if a TRX or token transfer results in the target account being created, then only the bandwidth points consumed to create the account will be deducted, and additional bandwidth points will not be deducted. In an account creation scenario, the network will first consume the bandwidth points that the transaction initiator gained from freezing TRX. If this amount is insufficient, then the network consumes the transaction initiator’s TRX. In standard TRX transfer scenarios from one TRX account to another, the network first consumes the bandwidth points gained by the transaction initiator for freezing TRX. If that is insufficient, it then consumes from the free 5000 daily bandwidth points. If that is still not enough, then the network consumes the TRX of the transaction initiator. The amount is calculated by the number of bytes in the transaction multiplied by 10 SUN. Thus, for most TRX holders who may not necessarily freeze their TRX to participate in SR voting, the first step is automatically skipped (since TRX balance frozen = 0) and the 5000 daily free bandwidth powers the transaction.

For TRC-10 token transfers, the network first verifies whether the total free bandwidth points of the issued token asset are sufficient. If not, the bandwidth points obtained from freezing TRX are consumed. If there is still not enough bandwidth points, then it consumes the TRX of the transaction initiator.

TRON Virtual Machine (TVM)

The TVM is a lightweight, Turing complete virtual machine developed for TRON’s ecosystem. The
TVM connects seamlessly with the existing development ecosystem to provide millions of global
developers with a custom-built blockchain system that is efficient, convenient, stable, secure, and
scalable.

Cheers !!
Axat Bhardwaj
Blockchain Developer & Technologist

How to set up Go Ethereum (Geth) private Network/Blockchain and deploy a Smart contract on it (2021)

Axat Bhardwaj — Mon, 09 May 2022 19:50:17 +0000

I'll divide the process in 10 steps :-

Install geth
Configure the Genesis block
Create local nodes
Generate initial accounts
Initialize and start the nodes
Connect to each node from the command line
Interconnect the nodes
Send some Ether
Start a miner
Deploy a Smart Contract

here we go …!

1. Install geth

geth is the command-line interface for running a full Ethereum node implemented in Go. To install it on a Mac, run the following commands:

$ sudo add-apt-repository -y ppa:ethereum/ethereum
$ sudo apt-get update
$ sudo apt-get install ethereum

2. Configure the Genesis block

Next, we need to create a JSON file that will define how the first block of the blockchain will be created. Each node in the network must be initialized with the same genesis block.
Create a file called genesis.json and save it in the parent folder of the nodes directories. Copy the content below but replace the addresses with those of the accounts created in the 3rd step.

{
    "nonce": "0x0000000000000042",
    "timestamp": "0x0",
    "parentHash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "extraData": "0x00",
    "gasLimit": "0x8000000",
    "difficulty": "0x400",
    "mixhash": "0x0000000000000000000000000000000000000000000000000000000000000000",
    "coinbase": "0x3333333333333333333333333333333333333333",
    "alloc": {
        "0x15024A50E641Ad330e0096bDca8Ea06f9f972Dcd": { //acc1 add it can be diff in ur case
            "balance": "1000000000000000000"
        },
        "0xE3F2Defe3e3DDB4694a985bA6AA052Ad888BCF3D": { //acc2 add it can be diff in ur case
            "balance": "2000000000000000000"
        }
    },
    "config": {
        "chainId": 111,
        "homesteadBlock": 0,
        "eip155Block": 0,
        "eip150Block": 0,
        "eip158Block": 0
    }
}

The config section ensures that certain protocol upgrades are immediately available. The alloc section pre-funds accounts.

3. Create local nodes

For the purpose of this private blockchain, we will create some nodes locally in our machine.
Create 3 new directories. Each of them will represent a single node in the blockchain:

 $ mkdir geth
 $ cd geth
 $ mkdir pvtchain
 $ cd pvtchain
 $ mkdir node01 node02 node03

4. Generate initial accounts

Let's create 2 Ethereum accounts in the first node so that later we can do some transactions for testing purposes:

$ geth --datadir "/PATH_TO_NODE01/" account new

You will be prompted for a secret password. Write down the address of the created accounts and memorize the password.

5. Initialize and start the nodes

The first step is to initialize each node with the genesis file previously created. For this, run this command for each of the nodes, replacing it with the correct path:

$ geth --datadir "/PATH_TO_NODE/" init /PATH_TO/genesis.json
Then start each node by running the following command for each of them. You will need to use different numbers both for the port and the rpcport.
$ geth --identity "node1" --http  --http.port "8000" --http.corsdomain "*" --datadir "/home/ubuntu/geth/pvtchain/node1" --port "30303" --nodiscover --http.api "db,eth,net,web3,personal,miner,admin" --networkid 1234 --nat "any" --allow-insecure-unlock
$ geth --identity "node2" --http  --http.port "8001" --http.corsdomain "*" --datadir "/home/ubuntu/geth/pvtchain/node2" --port "30304" --nodiscover --http.api "db,eth,net,web3,personal,miner,admin" --networkid 1234 --nat "any" --allow-insecure-unlock
$ geth --identity "node3" --http  --http.port "8002" --http.corsdomain "*" --datadir "/home/ubuntu/geth/pvtchain/node3" --port "30305" --nodiscover --http.api "db,eth,net,web3,personal,miner,admin" --networkid 1234 --nat "any" --allow-insecure-unlock

💡 pls remember "/home/ubuntu/geth/pvtchain/node1 is my path to node directory

6. Connect to each node from the command line

In order to interact with the nodes, you need to open a terminal and use geth to attach to it. Run the following command for each of the nodes, in a separate terminal and use the correct port number for each of them:

$ geth attach <http://127.0.0.1:8000>
$ geth attach <http://127.0.0.1:8001>
$ geth attach <http://127.0.0.1:8002>

7. Interconnect the nodes

The first node will be our admin node. Run the following command in the console to read some characteristics about it:

> admin.nodeInfo

Copy the enode address completely:
enode: "enode://26f7b83...ed769122f1692e@[::]:30303?discport=0"
Now you can connect the other nodes to this one by running the following command in their respective terminals:

> admin.addPeer("enode://26f7b8...92e@[::]:30303?discport=0")

You can verify that the nodes are peering by entering the following command in the terminal corresponding to the admin node:

> net.peerCount
2

8. Send some Ether

Next, we will execute a transaction. Go to the console attached to the first node and run the following command to check that you can see the accounts created before:

> eth.accounts

Then check the balance of the first account:

> eth.getBalance(eth.accounts[0])

Now unlock the first account in order to start a transaction from it:

> personal.unlockAccount(eth.accounts[0])

Now send some Ether:

> eth.sendTransaction({from:eth.accounts[0], to:eth.accounts[1], value:1000})

9. Start a miner

The first thing to do is to set up an account to receive the mining awards. This is called the etherbase account. We will use the admin node as a miner. Go to the console attached to it and run the following command:

> miner.setEtherbase(eth.accounts[0])

Then run the following command:

> miner.start()

You should see a null message in the console, and then in the other console where you started the node, you should see the progress of the mining that you just started.
You can now verify the balance of the account and check that the transfer was done properly.

10. Deploy a Smart Contract

In this section, we will create and deploy a simple smart contract into our network. For this, we will be using Truffle, which is a development framework for Ethereum.
Run the following command to install the Truffle library:

$ npm install -g truffle

Next, we will initialize a new Truffle project by running this command in a new folder:

$ truffle init

You will notice that some initial files and directories were created. We need to modify the truffle-config.js so that Truffle knows how to connect to our network. Use the following content for that file, considering that for the port number you need to use the port where your first node is running, and for the from the address you must complete the address of the first account created in that node:
Next, open the contracts folder and create a new file called hello.sol. Complete it with the following code, which is a simple contract written in the Solidity language:
The next step is to update the migrations file so that Truffle knows that it needs to compile and migrate the contract that we just created. Open the 1_initial_migration.js file located in the migrations folder and modify its content to match the following:
We can now use Truffle to compile our contract and deploy it into our network. Notice that Truffle will also compile and deploy its migrations contract, which is used to track the deployed versions of our contracts and keep them updated.
Go to the contracts folder and run the following command:

$ truffle compile

Next, we need to unlock the account in the first node again, as we are going to deploy the contract using that account. Go to the terminal that is attached to that node and run this command:

> personal.unlockAccount(eth.accounts[0])

Finally, go back to the contracts folder and run this command to deploy the contract:

$ truffle migrate

The contract should now be deployed in your network at a new address.
The contract is deployed in our network
Cheers !!

Axat Bhardwaj,
Blockchain Enthusiast & Developer,
Connect with me on LinkedIn: https://www.linkedin.com/in/axatbhardwaj