DEV Community: Ajay Singh

Blockchain Trilemma

Ajay Singh — Mon, 12 Jun 2023 20:03:03 +0000

Blockchain technology, which underpins cryptocurrencies, is a distributed ledger that allows transactions to be recorded in a secure and transparent way. However, there is a fundamental problem that developers and users of blockchain technology face, known as the Blockchain Trilemma. The blockchain trilemma refers to the challenge of achieving scalability, security, and decentralization, all at the same time.

Scalability
Scalability refers to the ability of a blockchain network to handle a large number of transactions. Currently, most blockchain networks have limited scalability, which means they can only process a few transactions per second. This is a major problem for blockchain adoption, as it limits the number of users who can use the network at the same time.

Security
Security refers to the ability of a blockchain network to resist attacks and prevent malicious actors from hacking or manipulating the network. Blockchain networks are secured through a process called consensus, where nodes in the network agree on the validity of transactions. However, achieving security can be difficult, especially in the face of determined attackers.

Decentralization
Decentralization refers to the distribution of nodes that maintain the blockchain network. A decentralized network is more secure and resistant to attacks because there is no single point of failure. However, achieving decentralization can be difficult, especially as the network grows and more nodes are needed to maintain it.

Achieving all three goals of scalability, security, and decentralization at the same time is a challenge that has yet to be fully solved. Most blockchain networks have had to make trade-offs between these goals. For example, some networks sacrifice decentralization to achieve greater scalability, while others sacrifice scalability for greater security. You can at anytime successfully only cater to one side of the above triangle.

Learning Bitcoin Part -1

Ajay Singh — Tue, 06 Jul 2021 22:20:28 +0000

Over the next few days we would be learning the basics and fundamentals of bitcoin.

Today we will be talking about the origin of bitcoin

Who created Bitcoin?

This is one of the well-guarded secret and mystery.
No one actually know who created bitcoin, but we have a name attributed to it - Satoshi Nakamoto.
This Person or Collection of person have authored a whitepaper titled Bitcoin: A Peer-to-Peer Electronic Cash System, on October 31, 2008.
This whitepaper was posted on cryptography mailing list below is the original content of the email.

I've been working on a new electronic cash system that's fully
peer-to-peer, with no trusted third party.

The paper is available at:
http://www.bitcoin.org/bitcoin.pdf

The main properties:
Double-spending is prevented with a peer-to-peer network.
No mint or other trusted parties.
Participants can be anonymous.
New coins are made from Hashcash style proof-of-work.
The proof-of-work for new coin generation also powers the
network to prevent double-spending.

Bitcoin: A Peer-to-Peer Electronic Cash System

Abstract. A purely peer-to-peer version of electronic cash would
allow online payments to be sent directly from one party to another
without the burdens of going through a financial institution.
Digital signatures provide part of the solution, but the main
benefits are lost if a trusted party is still required to prevent
double-spending. We propose a solution to the double-spending
problem using a peer-to-peer network. The network timestamps
transactions by hashing them into an ongoing chain of hash-based
proof-of-work, forming a record that cannot be changed without
redoing the proof-of-work. The longest chain not only serves as
proof of the sequence of events witnessed, but proof that it came
from the largest pool of CPU power. As long as honest nodes control
the most CPU power on the network, they can generate the longest
chain and outpace any attackers. The network itself requires
minimal structure. Messages are broadcasted on a best effort basis,
and nodes can leave and rejoin the network at will, accepting the
longest proof-of-work chain as proof of what happened while they
were gone.

Full paper at:
http://www.bitcoin.org/bitcoin.pdf

Satoshi Nakamoto

On 9 January 2009, Nakamoto released version 0.1 of the bitcoin software on SourceForge, and launched the network by defining the genesis block of bitcoin (block number 0), which had a reward of 50 bitcoins.

Bitcoin is combination of existing Technology

Bitcoin is not something which has popped up out of blue, but it was combination of various technologies which lead to it.

Below are a few technology inventions that “Satoshi Nakamoto” uses, mentions, and gives credit via his whitepaper:

1) digital cash technology and protocol called ecash by David Chaum and Stefan Brands
2) “proof of work” system called hashcash by Adam Back for spam monitoring and control, which was eventually built upon by Hal Finney, who created a reusable proof-of-work protocol
3) distributed scarcity system built upon “b-money” created by Wei Dai
4) technology called “bitgold” by Nick Szabo that proposed a mechanism for market inflation control

Key point to mention all of the above mentioned folks have denied being Satoshi Nakamoto or being part of the group being called "Satoshi Nakamoto"

Etherscan.io down No worries

Ajay Singh — Thu, 15 Apr 2021 18:08:17 +0000

In case you all are not able to access etherscan.io for your transaction verification.
Do not worry feel free to visit DL Eth Explorer https://dlethexplorer.dltlabs.com/

Linux Capacity Planning Part -2

Ajay Singh — Sun, 24 May 2020 22:56:50 +0000

In the last post Linux Capacity Planning-1, we discussed about -

The linkage between capacity planning and performance
Package sysstats - its installation on various Linux flavours.

In this post, we will do a deep dive in iostat utility present in the sysstats package.

Iostat command is a command used to monitor the system's input/output (I/O) device load by observing the time the devices are active in relation to their average transfer rates. The iostat create reports that can be used to change system configuration to better balance the input/output between physical disks.

sample of Iostat command run without passing any argument will look as below

[root@ip-10-25-57-107 ec2-user]# iostat
Linux 4.14.173-137.229.amzn2.x86_64 (ip-10-25-57-107.ap-south-1.compute.internal)       05/24/2020      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.02    0.00    0.01    0.01    0.00   99.96

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              0.59         1.32         4.20     206156     654551

When the command is run without arguments, it generates a detailed report containing information since the system was booted. You can provide two optional parameters to change this:

iostat [option] [interval] [count]

interval parameter specifies the duration of time in seconds between each report
Count parameter allows you to specify the number of reports that are generated before iostat exits.

The first report generated by the iostat command provides statistics concerning the time since the system was booted unless the -y option is used (in this case, this first report is omitted). Each subsequent report covers the time since the previous report. All statistics are reported each time the iostat command is run. The report consists of a CPU header row followed by a row of CPU statistics. On multiprocessor systems, CPU statistics are calculated system-wide as averages among all processors. A device header row is displayed followed by a line of statistics for each device that is configured.

The interval parameter specifies the amount of time in seconds between each report. The first report contains statistics for the time since system startup(boot) unless the -y option is used (in this case, this report is omitted). Each subsequent report contains statistics collected during the interval since the previous report. The count parameter can be specified in conjunction with the interval parameter. If the count parameter is specified, the value of count determines the number of reports generated at interval seconds apart. If the interval parameter is specified without the count parameter, the iostat command generates reports continuously.

[root@ip-10-25-57-107 ec2-user]# iostat 1 5
Linux 4.14.173-137.229.amzn2.x86_64 (ip-10-25-57-107.ap-south-1.compute.internal)       05/24/2020      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.02    0.00    0.01    0.01    0.00   99.96

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              0.59         1.32         4.19     206164     655868

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.00    0.00    0.00  100.00

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.00    0.00    0.00  100.00

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.00    0.00    0.00  100.00

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              0.00         0.00         0.00          0          0

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.00    0.00    0.00  100.00

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
xvda              0.00         0.00         0.00          0          0

[root@ip-10-25-57-107 ec2-user]#

The iostat command generates two types of reports, the CPU Utilization and Device Utilization report.
The first section of the report is related to

CPU Utilization Report

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.00    0.00    0.00    0.00    0.00  100.00

For multiprocessor systems, the CPU values are global averages among all processors.

The report has the following format:

%user - Show the percentage of CPU utilization that occurred while executing at the user level (application).

%nice- Show the percentage of CPU utilization that occurred while executing at the user level with nice priority.

%system- Show the percentage of CPU utilization that occurred while executing at the system level (kernel).

%iowait- show the percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.

%steal- Show the percentage of time spent in involuntary wait by the virtual CPU or CPUs while the hypervisor was servicing another virtual processor.

%idle- Show the percentage of time that the CPU or CPUs were idle and the system did not have an outstanding disk I/O request.

2.The Device Utilization Report
The device report provides statistics on a per physical device or partition basis. Block devices and partitions for which statistics are to be displayed may be entered on the command line. If no device nor partition is entered, then statistics are displayed for every device used by the system, and providing that the kernel maintains statistics for it. If the ALL
keyword is given on the command line, then statistics are displayed for every device defined by the system, including those that have never been used.
Transfer rates are shown in 1K blocks by default unless the environment variable POSIXLY_CORRECT is set, in which case 512-byte blocks are used. The
report may show the following fields, depending on the flags used:

Device- device/partition name as listed in /dev directory

tps- number of transfers per second that were issued to the device. Higher tps means the processor is busier

Blk_read/s- show the amount of data read from the device expressed in a number of blocks (kilobytes, megabytes) per second

Blk_wrtn/s- amount of data written to the device expressed in a number of blocks (kilobytes, megabytes) per second

Blk_read- show the total number of blocks read

Blk_wrtn- show the total number of blocks written

You get more detailed information by extending - using -x option with iostat.

iostat -x

[root@ip-10-25-57-107 ec2-user]# iostat -x
Linux 4.14.173-137.229.amzn2.x86_64 (ip-10-25-57-107.ap-south-1.compute.internal)       05/24/2020      _x86_64_        (1 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.02    0.00    0.01    0.01    0.00   99.96

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
xvda              0.00     0.02    0.08    0.51     1.30     4.16    18.62     0.00    3.06    1.19    3.35   0.17   0.01

[root@ip-10-25-57-107 ec2-user]#

Below are the details of the fields

%util: how much time did the storage device have outstanding work (was busy).
svctm: indicate how fast does your I/O subsystem respond requests overall when busy. Actually, less you load your system, higher svctm is.

await: indicates how fast do requests go through. It is just an average.

avgqu-sz: how many requests are there in a request queue. Low = either your system is not loaded, or has serialized I/O and cannot utilize underlying storage properly. High = your software stack is scalable enough to load properly underlying I/O.

avgrq-sz: Just an average request size. can indicate what kind of workload happens.

wsec/s & rsec/s: Sectors read and written per second. Divide by 2048, and you’ll get megabytes per second.

r/s & w/s: Read and write requests per second. These numbers are the ones that are the I/O capacity figures, though of course, depending on how much pressure underlying I/O subsystem gets (queue size!), they can vary.

rrqm/s & wrqm/s: How many requests were merged by block layer.

We will continue with iostat in the next post.

Linux Capacity Planning Part -1

Ajay Singh — Sat, 23 May 2020 03:16:04 +0000

This is going to be a series of blog post which will in introduce you with knowledge and tools necessary to analyze the historical data and plan for the increased resource to meet your future need as well as able to identify the resource bottleneck in your host machine.

We would be considering the Amazon Linux 2 as Linux operating system.

In this part, we will first look at a few important considerations which we should look during the planning.

when you discuss the capacity, in reality, you are initiating a discussion about the performance. Capacity and Performance always go hand in hand.
When we discuss performance we are trying to discuss the performance of an application on the system.
You have to measure and monitor performance to do any sort of capacity planning.

Below are the few important parameters which determine the capacity of your system and impact performance of your application.

CPU
RAM
IOPS (disk read and write)
list of open files
Network transfer rate

One of the tools which can help us in measuring these parameters in present in package name as sysstat.
The above package come by default installed on Amazon Linux 2 AMI.
The distro on which it is not installed you can install it by running below commands.

Command to install on different Distros:

On RedHat / CentOS / Fedora

yum install sysstat

On Debian / Ubuntu / Linux Mint

apt-get install sysstat

Once you have started the EC2 instance you can go and check if the sysstat service is active.

[root@ip-10-25-57-107 ec2-user]# service sysstat status
Redirecting to /bin/systemctl status sysstat.service
● sysstat.service - Resets System Activity Logs
   Loaded: loaded (/usr/lib/systemd/system/sysstat.service; enabled; vendor preset: enabled)
   Active: active (exited) since Sat 2020-05-23 02:21:42 UTC; 3min 34s ago
  Process: 2690 ExecStart=/usr/lib64/sa/sa1 --boot (code=exited, status=0/SUCCESS)
 Main PID: 2690 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/sysstat.service

May 23 02:21:41 localhost systemd[1]: Starting Resets System Activity Logs...
May 23 02:21:42 localhost systemd[1]: Started Resets System Activity Logs.

In next post, we will look into various utilities provided under sysstat package.

Introducing new avatar of DL Gateway

Ajay Singh — Wed, 11 Dec 2019 20:02:49 +0000

We are thrilled to announce that the newly updated DL Gateway platform has been launched! Packed with cutting edge features and system improvements, we think you will absolutely love the upgraded environment.

Some of our new features and improvements include:

Signup and login directly to the Ethereum and Hyperledger Fabric blockchain infrastructures
Create and manage projects using Ethereum and Hyperledger Fabric
Collaborate and work on projects with other users registered on the platform
View detailed project statistics, including total project transactions and top API calls, in a clean UI that is easy to navigate
Monitor end-to-end blockchain network statistics
Personalize your account with a photo or avatar image

With more than five million transactions to date and growing, we’d like to remind you that this world-class system is 100% free to use. Please join us, collaborate with your team and create something amazing.

Keep Docker alive during docker daemon downtime

Ajay Singh — Thu, 08 Aug 2019 21:56:59 +0000

When the docker daemon terminates by default it shutdowns the running docker containers. From Docker Engine 1.12, you can configure the daemon so that containers remain running even if the daemon becomes unavailable.
This functionality is named is live restore. The live restore option helps reduce container downtime due to daemon crashes, planned outages, or upgrades.

How do we enable live restore?

There are two ways to enable live restore

Add the configuration to the daemon configuration file. On Linux, this defaults to /etc/docker/daemon.json

Use the following JSON to enable live-restore.
```
  {
     "live-restore": true
   }
```
you can restart the docker daemon now. If you are using systemd, then use the command systemctl reload docker.
you can also start the dockerd process manually with the --live-restore flag.

Impact of live restore on running containers

If the daemon is down for a long time, running containers may fill up the FIFO log the daemon normally reads. A full log blocks containers from logging more data. The default buffer size is 64K. If the buffers fill, you must restart the Docker daemon to flush them.

On Linux, you can modify the kernel’s buffer size by changing /proc/sys/fs/pipe-max-size.

Live restore and swarm mode

The live restore option only pertains to standalone containers, and not to swarm services. Swarm services are managed by swarm managers. If swarm managers are not available, swarm services continue to run on worker nodes but cannot be managed until enough swarm managers are available to maintain a quorum.

Live restore during upgrades

Live restore supports keeping containers running across Docker daemon upgrades, though this is limited to patch releases and does not support minor or major daemon upgrades.

If you skip releases during an upgrade, the daemon may not restore its connection to the containers. If the daemon can’t restore the connection, it cannot manage the running containers and you must stop them manually.

Live restore upon restart

The live restore option only works to restore containers if the daemon options, such as bridge IP addresses and graph driver, did not change. If any of these daemon-level configuration options have changed, the live restore may not work and you may need to manually stop the containers.

Intro to ps command

Ajay Singh — Tue, 06 Aug 2019 23:09:54 +0000

The aim of the article is to give an idea about ps command and various option it is used to run.
I have seen people running commands like

ps -ef

without understanding the reason for adding the parameters ( they do because of somewhere they have seen in StackOverflow or seen their colleagues using it while debugging some issue).

To start with what does ps command is used for: displays information about a selection of the active processes.

ps accepts several kinds of options which can be clubbed as below

1 UNIX options, which may be grouped and must be preceded by a dash.
2 BSD options, which may be grouped and must not be used with a dash.
3 GNU long options, which are preceded by two dashes.

ps command works by reading files in the proc filesystem. The directory /proc/PID contains various files that provide information about process PID. The content of these files is generated on the fly by the kernel when a process reads them.

ps
By default, ps selects all processes with the same effective user ID (euid=EUID) as the current user and associated with the same terminal as the invoker.

It displays the process ID (pid=PID), the terminal associated with the process (tname=TTY), the cumulated CPU time in [DD-]hh:mm:ss format (time=TIME), and the executable name (ucmd=CMD).Output is unsorted by default.

[ajays@ip-10-40-19-132 ~]$ ps
  PID TTY          TIME CMD
20244 pts/0    00:00:00 bash
20342 pts/0    00:00:00 ps
[ajays@ip-10-40-19-132 ~]$ who
ajays    pts/0        2019-08-06 20:38 (ip-10-19-12-119.ca-central-1.compute.internal)
[ajays@ip-10-40-19-132 ~]$

So as per the explanation, the ps command would have only shown the process with the same user and associated as with the same terminal as invoker. The next command list down the invoker ( ajays ) and terminal ( pts/0 ). So the output of the ps command is the process associated with ajays and attached to terminal pts/0.

The options used by ps can be classified in mainly below categories.

Process selection ( simple or by list )
Output format control and modifiers
Thread display

Each of the above categories has a lot of option which we cannot cover in this article but will try to cover some common ones.

ps -f

The -f option is UNIX option. It is used to do full-format listing.
The out show following details UID, PID, PPID, C, STIME, TTY, TIME, CMD.

UID - The name of the user who have started the process.

PID - This act as the identification no of the process running in the memory.

PPID- It is parent process id. This id is the pid of the process because of
which these process has been started.

C- Processor utilization information in %.

STIME- This is the start time of the process.

TTY- This is the terminal from which the process was started.

TIME- Total time for which the process has utilized cpu.

CMD- The command and arguments executed.

[ajays@ip-10-40-19-132 ~]$ ps -f
UID        PID  PPID  C STIME TTY          TIME CMD
ajays    20244 20213  0 20:38 pts/0    00:00:00 -bash
ajays    29906 20244  0 22:12 pts/0    00:00:00 ps -f
[ajays@ip-10-40-19-132 ~]$

ps -ef

Now we have attached one more argument -e (this is a UNIX based option).
This option is a select option. Select all processes.
a snippet of this command looks like below

5984      6011  5341  0 Jul31 ?        00:00:00 /opt/couchdb/bin/couchjs -S 268435456 /opt/couchdb/share/server/ma
5984      6012  5341  0 Jul31 ?        00:00:01 /opt/couchdb/bin/couchjs -S 268435456 /opt/couchdb/share/server/ma
5984      6013  5341  0 Jul31 ?        00:00:00 /opt/couchdb/bin/couchjs -S 268435456 /opt/couchdb/share/server/ma
5984      6014  5341  0 Jul31 ?        00:00:03 /opt/couchdb/bin/couchjs -S 268435456 /opt/couchdb/share/server/ma
5984      6015  5341  0 Jul31 ?        00:00:09 /opt/couchdb/bin/couchjs -S 268435456 /opt/couchdb/share/server/ma
5984      6016  5341  0 Jul31 ?        00:00:07 /opt/couchdb/bin/couchjs -S 268435456 /opt/couchdb/share/server/ma
5984      6017  5341  0 Jul31 ?        00:00:08 /opt/couchdb/bin/couchjs -S 268435456 /opt/couchdb/share/server/ma
ajays    23552 20244  0 23:07 pts/0    00:00:00 ps -ef
postfix  24642  3429  0 22:01 ?        00:00:00 pickup -l -t unix -u

ps -af

Now we have attached -a ( this is UNIX based option ).
Select all processes except both session leaders and processes not associated with a terminal.
So the difference between -a and -e is evident, -e will also return the process which are not associated to a terminal where -a will only return process which are associated with a terminal.

Session Leaders are the process where PID=SID.

Why Go is better?

Ajay Singh — Fri, 19 Jul 2019 22:59:58 +0000

The GoLang was conceived and developed by developers at Google.
It is reported that it was conceived while they were waiting for the project to have complied.

Go or GoLang, as it is called, is a robust system-level language used for programming across large-scale network servers and big distributed systems. Golang emerged as an alternative to C++ and Java for the app developers in the context of what Google needed for its network servers and distributed systems

Let's discuss one by one factor which makes go different from the majority of existing programming language.

1) Multithreading And Concurrency

A vast majority of programming languages lack concurrent execution when working with multiple threads. They often slow down the pace of programming, compiling and execution. This is where Go comes as the most viable option to support multi-threading environment and concurrency both.
With time the hardware manufacturers have kept on adding more core to the system to ensure better performance.
Go was conceived at the time multi-core processors became widely available across sophisticated hardware. The creators of Go gave particular focus on concurrency. Go works with goroutine which allow it to handle concurrently large number of tasks.

2) Simplicity of Go

No Generics:

Generics or templates which remained a mainstay for various programming languages often add to the obscurity and difficulties of understanding. Go designers by deciding to go without it made things simple.

Single Executable:

GoLang comes without any separate runtime library. It can produce a single executable code that can be deployed by just copying. This helps in removing all the concerns of committing mistakes on dependencies or versions mismatch.

No Dynamic Libraries:

Go just decided to do away with any dynamic library to keep the language simple and straightforward. Although, in the latest Go 1.10 version the developers are given the option to upload dynamic libraries through plug-in packages. This has just been included only as an extended capability.

Logical Components in blockchain

Ajay Singh — Tue, 16 Jul 2019 13:54:27 +0000

This article points out and gives an outline of the various logical components in the blockchain.

When one takes a first look in Blockchain space it looks very confusing and complicated and there is no doubt about it, as the low-level programming and mathematics involved to create and implement blockchain ecosystem come with difficulty.

In this article, I will explain the purpose of the individual logical component that makes up any blockchain ecosystems.

To understand how blockchain technology works irrespective of its flavor or application, it is necessary to understand the logical component of blockchain ecosystem and their role.

The Blockchain Ecosystem can be logically segregated in these 4 logical components.

node application
shared ledger
consensus algorithm
virtual machine

Node Application
Any Machine who want to be part of the blockchain ecosystem, need to run a node of the specific Blockchain. Using bitcion as an example , the machine must be running Bitcion wallet Application.
Shared Ledger
Consider it as a data structure, which is inside the node application. If you are running the Ethereum client, you can see the Ethereum ecosystem ledger and interact according to the rules of that ecosystem (smart contracts, payments, etc.). If you are running the Bitcoin client, you can participate in the Bitcoin ecosystem, according to the rules set out in the program code of the Bitcoin node application.
You may run as many node application of any blockchain ecosystem, but there will be only one shared ledger of the particular blockchain ecosystem.
Consensus Algorithm
This logical component provides the "rules and regulation" on how the single view of the shared ledger will be reached in blockchain ecosystem.Different ecosystems have different methods for attaining consensus depending on the desired features the ecosystem needs. The various famous consensus algorithms are - Proof of Work, Proof of Authority, Proof of Stake, Proof of Elapsed Time.
Virtual Machine
This is the final logical component of the blockchain ecosystem. It acts a bucket or container where all the logical components rest, act and interact.

A virtual machine is a representation of a machine (real or imaginary) created by a computer program and operated with instructions embodied in a language.It is an abstraction of a machine inside a machine.

This post was first originally posted here - https://www.linkedin.com/pulse/logical-components-blockchain-ajay-singh/