In the case of an ‘untrusted’ peer-to-peer network, we can’t necessarily trust any of the peers, how to ensure that the bad peers won't corrupt the system?

CONSENSUS: How to resolve conflicts?

A very basic conflict is when multiple miners create blocks at the same time. As the blocks take time to be shared across the network, which one should be considered a legit block?

Example: Let’s consider that all the nodes on the network have synchronised their blockchains, and they are all on block number 80.
If three different miners create ‘Block 81’ at roughly the same time, which ‘Block 81’ should be considered valid? Remember that each ‘Block 81’ will look slightly different: They will certainly contain a different payment address for the 25 BTC block reward, and they may contain a different set of transactions. Let’s call them 81a, 81b, 81c.

Which block will be considered the legit one?
How to resolve this?

Longest chain rule. In Bitcoin, this conflict is resolved by a rule called the “longest chain rule”.

In the example above, you would assume that the first ‘Block 81’ you see is valid. Let’s say you see 81a first. You can start building the next block on that, trying to create 82a:

Treat the first block you see as legitimate.

However, in a few seconds, you may see 81b. If you see this, you keep an eye on it. If later you see 82b, the “longest chain rule” says that you should regard the longer ‘b’ chain as the valid one (…80, 81b, 82b) and ignore the shorter chain (…80, 81a). So you stop trying to make 82a and instead, start trying to make 83b:

Longest chain rule: If there are multiple blocks, treat the longest chain as legitimate.

The “longest chain rule” is the rule that the Bitcoin blockchain ecosystem uses to resolve these conflicts which are common in distributed networks.

However, with a more centralised or trusted blockchain network, we can make decisions by using a trusted, or senior validator to arbitrate in these cases.

DEFENCE: How do you make it hard for baddies?

The most common issue with permissionless, or open networks is that they can be attacked easily. So we need to make sure the network as a whole needs to be trustworthy, even if few nodes aren't.

Understanding the Miscreant's Capabilities

A dishonest miner, despite causing concern, is confined in terms of the harm they can inflict. Here are some actions a dishonest miner can take:

1. Refusal to relay valid transactions: A dishonest miner can choose not to pass valid transactions to other nodes within the network.

2. Manipulating block contents: They can attempt to create blocks that selectively include or exclude specific transactions according to their preferences.

3. Attempting to construct a longer chain: By creating a sequence of blocks that surpasses the existing main chain, a dishonest miner can render previously accepted blocks as "orphans," thereby excluding them from the primary chain.

However, a dishonest miner is unable to execute the following actions:

1. Generating bitcoins out of thin air: While theoretically possible, creating bitcoins out of nothing remains unfeasible. If such transactions are attempted, other nodes will reject them, emphasizing the importance of confirming transactions across multiple nodes.

2. Stealing bitcoins from your account: The security measures in place prevent a dishonest miner from pilfering bitcoins from a user's account.

3. Impersonation or unauthorized payments: A dishonest miner cannot conduct payments on behalf of others or pretend to be someone else within the network.

Transaction Security

The impact of a dishonest miner's actions on transactions is limited, primarily due to the presence of honest nodes in the network. If the majority of nodes are honest, they will reject any invalid transactions introduced by the miscreant. Moreover, these honest nodes will propagate valid transactions to ensure their inclusion in subsequent blocks, even if the dishonest miner refuses to relay them.

Block Security

In the context of blocks, the influence of a miscreant with significant block creation power becomes more pronounced. They can delay a specific transaction by omitting it from their blocks. However, other honest nodes will recognize this transaction as an "unconfirmed transaction" and incorporate it into their blocks.

A more significant concern arises when a dishonest miner manages to construct a longer chain of blocks compared to the rest of the network. By invoking the "longest chain rule," the miscreant can effectively undermine a transaction. Here's an overview of this strategy:

1. Creating dual payments: Initiate two payments with the same bitcoins—one to an online retailer and the other to another address under your control.

2. Broadcasting the retailer payment: Only share the payment intended for the retailer with the network.

3. Retailer payment confirmation: As the payment is included in an honest block, the retailer dispatches the ordered goods.

4. Secretly constructing a longer chain: Covertly generates a longer chain of blocks that excludes the payment to the retailer but includes the payment to yourself.

5. Publishing the longer chain: When the longer chain is published, nodes following the "longest chain rule" ignore the honest block containing the retailer payment. Instead, they continue building on the longer chain, effectively orphaning the honest block.

6. Invalidating the retailer payment: Due to the existence of the longer chain, honest nodes deem the original payment to the retailer invalid, as the bitcoins associated with it have already been spent according to your longer chain.

The “double spend” attack.

This is called a “double spend” because the same bitcoins were spent twice – but the second one was the one that became part of the eventual blockchain, and the first one eventually gets rejected.

How to make it hard for dishonest miners to create blocks?

Remember, this is only a problem for ledgers where block-makers aren’t trusted.

Essentially you want to make it hard, or expensive for baddies to add blocks. In Bitcoin, this is done by making it computationally expensive to add blocks. Computationally expensive means “takes a lot of computer processing power” and translates to financially expensive (as computers need to be bought then run and maintained).

The computation itself is a guessing game where block-makers need to guess a number, which when crunched with the rest of the block data contents, results in a hash/fingerprint that is smaller than a certain number. That number is related to the ‘difficulty’ of mining which is related to the total network processing power. The more computers join in to process blocks, the harder it gets, in a self-regulating cycle.

Every 2,016 blocks (roughly every 2 weeks), the Bitcoin network adjusts the difficulty of the guessing game based on the speed in which the blocks have been created.

This guessing game is called “Proof of work”. By publishing the block with a fingerprint that is smaller than the target number, you are proving that you did enough guesswork to satisfy the network at that point in time.

What is a blockchain?

Basically, blockchain is a Data Structure. Very similar to other data structures like databases (rows, columns, tables), text files, CSV, images, lists, and so on. Blockchain competes most closely with a database.

For an analogy, let's visualize blockchain as pages in a book
Chain = Book
Block = Page
Blocks in Chain = Pages in Book
Each page in a book contains:

• text: content/story

• information about the page: chapter number/title, page number

Similarly in a blockchain block, each block has:

• contents of the block: Transaction details in cryptocurrency, or any data which we prefer to store

• header: Metadata - data about the block. Some sort of technical info about the block, a reference to the previous block, and a fingerprint (hash) of the data for the current block

In blockchains, each block references the previous block by a computed hash value called the block’s fingerprint. The fingerprint is computed based on the contents of the block.

The concept of maintaining a reference to the previous blocks can be visualized as a linked list structure. In the linked list each node holds a reference to the next node, whereas in the blockchain each block holds a reference to the previous block.

This creates the fancy structure called the blockchain!

The fingerprint in each block is responsible for taking care of the consistency and validity of the data. If someone tries to meddle with any of the data, they have to end up regenerating all the fingerprints from that point forwards and the blockchain will look different. This is basically impossible as the process of creating fingerprints is difficult and slow. Therefore, if someone wants to re-write parts of the blockchain, it will take them a long time, and they have to catch up with and overtake the rest of the honest network. Which is not feasible.

Hence the blockchain is called immutable (as it cannot be changed).

The below image shows the inside of a blockchain block: the fingerprints are unique to the block’s contents.

Data Distribution

There are two ways of distributing data in a network: Client-Server and Peer to peer. Blockchain is built on top of the peer-to-peer model.

Client-server
This is a traditional approach where the server holds 100% of the data, and the clients connect via required protocols to access/consume the data.

Peer-to-peer
In peer-to-peer models, each peer has 100% of the data (or as close to it as possible), and updates are shared around. This is less efficient than client-server, as data is replicated many times. However, it's more robust as there is no central server that can be controlled, so closing down peer-to-peer networks is harder.

But on the contrary, the peer-to-peer model comes with its downsides. In the real world each peer on the network is gonna process and update at its own speed and latency and end up having varied states at a given timestamp. Deciding on which peer holds the valid data and which peer has stale or tampered data is ambiguous.

This conflict is resolved by a rule called the “longest chain rule” - If you see multiple blocks, treat the longest chain as legitimate. We can discuss in-depth on this conflict resolution and consensus in a separate article.

Conclusion

Blockchain is not something that is associated with only Bitcoin. Ethereum is a great variant of blockchain with smart contracts. There are significant challenges involved.
On the other hand, private or internally distributed ledgers and blockchains can be deployed to solve a wide range of problems and use cases.

Setup

To get started, visit the installation page and find instructions on how to install GitHub CLI for your preferred OS. The easy-peasy way for Windows users is to use scoop package manager.

Below are snapshots of install instructions for each supported platform:

• Windows:

    scoop bucket add github-gh https://github.com/cli/scoop-gh.git
    scoop install gh
  

• macOS:

    brew install github
  

• Debian/Ubuntu Linux:

    sudo apt install git && sudo dpkg -i gh_*_linux_amd64.deb
  

Authenticate GitHub CLI

Authenticate CLI to access your GitHub account.

gh auth login

Select Login with a Web browser

$ gh auth login
? What account do you want to log into? GitHub.com
? What is your preferred protocol for Git operations? HTTPS
? Authenticate Git with your GitHub credentials? Yes
? How would you like to authenticate GitHub CLI? Login with a web browser

! First copy your one-time code: 1DD9-7BD3
Press Enter to open github.com in your browser... 
✓ Authentication complete.
- gh config set -h github.com git_protocol https
✓ Configured git protocol
✓ Logged in as pvishnuprasaath

GitHub CLI Command Struct

gh command is structured like a tree for grabbing easily. There are basically two levels of commands. The first level consists of the below commands:

• auth

• browse

• issue

• pr

• release

• repo

• codespace

• gist

Each command has a second level of command where you specify the operation to perform — such as gh pr create or gh repo view.

Let's dive deep into the most commonly used commands.

GitHub Repo Command

Cloning a repo with the gh command is easier than using the git command. You no longer need to type or copy-paste the long Git URL to clone

gh repo clone OWNER/REPO
gh repo clone mui/material-ui

You can also fork existing repositories to your account easily from the command line.

gh repo fork cli/cli

To view the description and README of a project hosted on GitHub use the gh repo view command.

gh repo view facebook/react

Let's create a new GitHub repository from the command line. First, we need to create a new project.

$ npx create-next-app sample-app
$ cd sample-app

To create a repo from the command line, just run the following:

$ gh repo create --public
✓ Created repository pvishnuprasaath/sample-app on GitHub
✓ Added remote https://github.com/pvishnuprasaath/sample-app.git

# Push your project code to your new remote repository
$ git push -u origin main

Pull Request Command

If you know classic git flow, creating PR is quite an effort. GitHub CLI makes it easy to create PR directly from your terminal. After a git commit, you can execute gh pr create. It will prompt a couple of inputs. Post that, the PR link is displayed in the terminal.

Here’s the full output:

$ gh pr create
Creating pull request for feature-1 into master in pvishnuprasaath/sample-app
? Title Added new feature
? Body Implemented and testted new feature for ABC
? What is  next? Submit
Enumerating objects: 6, done.
Counting objects: 100% (6/6), done.
Delta compression using up to 8 threads
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 328 bytes | 328.00 KiB/s, done.
Total 4 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote:
remote: Create a pull request for 'feature-1' on GitHub by visiting:
remote:      https://github.com/pvishnuprasaath/sample-app/pull/new/feature-1
remote:
To https://github.com/pvishnuprasaath/sample-app.git
* [new branch]      HEAD -> feature-1
Branch 'feature-1' set up to track
remote branch 'feature-1' from 'origin'.
https://github.com/pvishnuprasaath/sample-app/pull/3

A short version:

gh pr create --title "PR title" --body "PR body"

To view all the pull requests in the current repo, run gh pr list

$ gh pr list
Showing 1 of 1 pull request in pvishnuprasaath/sample-app
#3  Added new feature  feature-1

Use the command gh pr checkout <number> to checkout a PR. This command will pull the remote feature branch and switch to it. gh pr diff will show the delta for the current PR.

Let’s take a look at the gh pr merge command. As you’re probably aware, GitHub checks for vulnerabilities in your code and provides solutions via bump pull requests. Here’s an example:

Merging multiple PRs one by one is a tiring process. gh pr merge makes it easy to merge a particular PR directly from the terminal.

$ gh pr merge 4
? What merge method would you like to use? Create a merge commit
remote: Counting objects: 100% (1/1), done.
remote: Counting objects: 100% (1/1), done.
remote: Total 1 (delta 0), reused 0 (delta 0), pack-reused 0        
Unpacking objects: 100% (1/1), 624 bytes | 89.00 KiB/s, done.       
From https://github.com/pvishnuprasaath/sample-app   
 * branch            main       -> FETCH_HEAD
   09f8c52..7a8a3f2  main       -> origin/main
Updating 09f8c52..7a8a3f2
Fast-forward
 src/data/data.ts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
✓ Deleted branch FixLink and switched to branch main

Additional gh pr commands

• gh pr view: displays the title, body, and other information about a pull request.

• gh pr status: show the status of relevant pull requests.

• gh pr ready: make a pull request as ready for review.

• gh pr review: add a review to a pull request.

• gh pr close: close a pull request.

• gh pr reopen: reopen a pull request.

By now, there isn't a way to revert PR from the GitHub CLI yet :(

Issue Command

Issues are used to keep track of bugs, tasks and feature requests associated with a GitHub project repo. The command gh issue create is used to create a new issue via the terminal:

$ gh issue create
Creating issue in pvishnuprasaath/sample-app
? Title Fix Docker skill link

? Title Fix Docker skill link
? Body <Received>
? What's next? Submit
https://github.com/pvishnuprasaath/sample-app/issues/6

gh issue list command lists all issues in the current repo.

The rest of gh issue commands are quite similar to gh pr commands. Below is a quick summary:

• gh issue view: displays the title, body, and other information about an issue.

• gh issue status: show the status of relevant issues.

• gh issue close: close an issue.

• gh issue reopen: reopen an issue.

GitHub CLI Cheat Sheet

Creating, deleting and configuring repo

gh repo create

gh repo create <name_of_repo> --public

gh repo create my-project --private --source=. --remote=upstream

gh repo edit --visibility <visibility-string>

gh repo sync

gh repo create --disable-issues=true --public

gh repo list

gh repo delete <name_of_repo>

gh repo clone <name_of_repo>

gh repo fork <name_of_repo>

To easily save a piece of code online use Gist:

Creating a gist

touch index.js // after create content for it

gh gist create index.js --public

gh gist create -

gh gist edit <gist_id> 

gh gist list --public 

gh gist list --secret

Handling issues

gh issue create

gh issue list

gh issue status

git issue close <#number_issue>

gh list -A "<name_issue>"

Handling Pull requests

gh pr create 

gh pr checkout <name>

gh pr diff <#number_of_pr>

gh review -c -b "nice work"

gh pr close <#number_of_pr> -d

gh pr reopen <#number_of_pr>

gh pr status

gh for sure saves up time in devflow. Gives additional hands to your terminal for managing the repository. Refer to the official docs for new features and detailed info on using the existing commands.

This workflow created on GitHub Actions will take care of automatically building and deploying the app on GitHub Pages. Can add testing and linting if needed. We will be triggering this workflow on every push event on the main/master branch.

Consider going over my prev blog-post on setting up your React app hosting on GitHub Pages.

Configure React App

A tiny bit of configuration is required on the React app side.

Add the below homepage property to your package.json file.

For free GitHub user site, add this: 
"homepage": "https://{username}.github.io"

If you own a domain, add this:
"homepage": "https://mydomainname.com"

Add both predeploy and deploy property scripts to the package.json as below

"predeploy": "npm run build",
"deploy": "gh-pages -d build"

Getting Started with GitHub Actions WorkFlow

First, create a workflow.yml file inside .github\workflows dir

The complete workflow is as below:

name: Build and Deploy

on:
  push:
    branches: ["main"]

permissions:
  contents: write

jobs:
  build-deploy:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [18.x]

    steps:
    - name: Checkout
      uses: actions/checkout@v3
    - name: Use Node.js ${{ matrix.node-version }}
      uses: actions/setup-node@v3
      with:
        node-version: ${{ matrix.node-version }}
        cache: "npm"
    - name: Install Packages
      run: npm ci
    - name: Build
      run: npm run build
    #- name: Test
    #  run: npm test
    - name: Deploy🚀
      uses: JamesIves/github-pages-deploy-action@v4
      with:
        branch: gh-pages
        folder: build

Let's understand each field put up here.

The on section describes the events which should trigger the job. In this workflow we want the jobs to be triggered whenever someone does a push into the main branch.

on:
  push:
    branches: ["main"]

Our job needs write access to modify files in the gh-pages branch. The final build files are pushed into the gh-pages branch of your repo. Using GitHub Secrets can also help achieve the same result.

permissions:
  contents: write

Let's get into the interesting section of defining the actual job to be executed. build-deploy is the user-defined name for the job.

We need to mention the type of runner on which the job needs to be executed. Pick ubuntu-latest.

jobs:
  build-deploy:
    runs-on: ubuntu-latest

When we want the same job to be executed on multiple variants of the node version, we can use the strategy matrix. Here we will stick to just 1 node version.

strategy:
  matrix:
    node-version: [18.x]

The first step in any job is to checkout the repo at that particular instance. This ensures we have the latest code base for the further process.

- name: Checkout
  uses: actions/checkout@v3

Set up Node.js on the freshly brought-up runner. To optimize the workflow execution we can cache the npm packages.

 - name: Use Node.js ${{ matrix.node-version }}
   uses: actions/setup-node@v3
   with:
     node-version: ${{ matrix.node-version }}
     cache: "npm"

Then we instruct the job to perform npm ci, npm run build, npm test. This covers the Build and Test phase.

- name: Install Packages
  run: npm ci
- name: Build
  run: npm run build
- name: Test
  run: npm test

Finally, it's time to deploy and give life to the app. We will use the popular JamesIves/github-pages-deploy-action@v4 action for deploying straight into the gh-pages. Specify the branch name on where the built files will be pushed to. Also, mention the source dir from where to find the built files. In our case, npm run build will dump files into the ./build dir.

- name: Deploy 🚀
  uses: JamesIves/github-pages-deploy-action@v4
  with:
    branch: gh-pages
    folder: build

In the Actions tab, we can see the execution status and log.

References

• https://github.com/features/actions

• https://pages.github.com/

• https://create-react-app.dev/docs/deployment#github-pages

• https://help.github.com/pt/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows

• https://github.com/actions/cache

In this wiki, we will dockerize both the development and production environment via separate Dockerfiles.

Step 1: Project setup

Initialized a pretty standard react project using the default create react app (CRA) template. Or pick your existing React app. Below is the sample project folder structure.

├── node_modules
├── public
│   ├── favicon.ico
│   ├── index.html
│   ├── manifest.json
│   └── robots.txt
├── src
│   ├── App.css
│   ├── App.js
│   ├── index.css
│   ├── index.js
│   └── logo.svg
├── package.json
└── yarn.lock

Step 2: Init .dockerignore

Add a .dockerignore file, this will help us ignore node_modules, .env etc

.git
.gitignore
**/node_modules
**/npm-debug.log
build

Step 3: Dockerize Development env

Init Dockerfile

Start by adding a Dockerfile.dev

FROM node:14-alpine AS development
ENV NODE_ENV development

# Add a work directory
WORKDIR /app

# Cache and Install dependencies
COPY package.json .
COPY yarn.lock .

#RUN yarn install
RUN npm i

# Copy app files
COPY . .

# Expose port
EXPOSE 3000

# Start the app
CMD [ "yarn", "start" ]

Init docker-compose

Create a docker-compose.dev.yml. Additionally, we will mount our code in a volume so that our code changes are in sync with the container during development.

version: "3.8"

services:
  app:
    container_name: app-dev-c
    image: app-dev-i
    build:
      context: .
      dockerfile: Dockerfile.dev
    volumes:
      - ./src:/app/src
    ports:
      - "3000:3000"

Let's start our React app for development!

docker-compose -f docker-compose.dev.yml up

To make life easier add docker-compose commands to package.json

"docker-dev-up": "docker-compose -f docker-compose.dev.yml up"
"docker-dev-down": "docker-compose -f docker-compose.dev.yml down"

Let's check our container!

> docker ps

REPOSITORY          TAG                   IMAGE ID       CREATED              SIZE
app-dev            latest                5867f4e40c98   About a minute ago    436MB

Visit the app at http://localhost:3000

Step 4: Dockerize Production env

Let's use nginx to serve our static assets and help resolve routes when we're using React Router or any kind of routing.

Configure nginx

Create a nginx.conf with the below content. This will help handle URI changes during routing.

server {
  listen 80;

  location / {
    root /usr/share/nginx/html/;
    include /etc/nginx/mime.types;
    try_files $uri $uri/ /index.html;
  }
}

Init Dockerfile

Start by adding a Dockerfile.prod

FROM node:14-alpine AS builder
ENV NODE_ENV production

# Add a work directory
WORKDIR /app

# Cache and Install dependencies
COPY package.json .
COPY yarn.lock .
RUN npm i

# Copy app files
COPY . .

# Build the app
RUN npm run build

# Bundle static assets with nginx
FROM nginx:1.21.0-alpine as production
ENV NODE_ENV production

# Copy built assets from builder
COPY --from=builder /app/build /usr/share/nginx/html

# Add your nginx.conf
COPY nginx.conf /etc/nginx/conf.d/default.conf

# Expose port
EXPOSE 80

# Start nginx
CMD ["nginx", "-g", "daemon off;"]

Init docker-compose

Add a docker-compose.prod.yml file

version: "3.8"

services:
  app:
    container_name: app-prod-c
    image: app-prod-i
    build:
      context: .
      dockerfile: Dockerfile.prod
    ports:
        - "8080:80"

Build production image

docker-compose -f docker-compose.prod.yml build

Let's check out our built production image

> docker images

REPOSITORY          TAG                   IMAGE ID       CREATED              SIZE
app-prod           latest                c5db8d308bb9   About a minute ago   23.1MB

Start our production container on port 80 with the name react-app

docker run -p 8080:80 --name react-app app-prod

Visit the app at http://localhost:8080

Here is how the final project struct looks:

├── node_modules
├── public
│   ├── index.html
│   ...
│   └── manifest.json
├── src
│   ├── App.css
│   ...
│   └── index.js
├── package.json
├── yarn.lock
├── .dockerignore
├── Dockerfile.dev
├── Dockerfile.prod
├── docker-compose.dev.yml
└── docker-compose.prod.yml

Hurrayyy!! We can now use docker in our workflow and deploy our production images faster to any platform.

But this doc will guide you to host react app at https://<git_user>.github.io (no need to cling the repo name with URL)
ex: adam.github.io , vishnu.github.io

This approach is preferred for hosting a portfolio or dev-profile website.

There are three types of GitHub Pages sites:

1. User Site

2. Project Site

3. Organization Site

This blog is inclined toward setting up a User Site

Let's get started!

Step 1 - Create a repo on GitHub

Create a new GitHub repo named username.github.io (replace username with your current git user name) and make it Public (to host private repo in GH pages you need a GitHub Enterprise account)

Step 2 - Create React app and Push to repo

Create your react app following the official doc - https://create-react-app.dev/docs/getting-started/

Init git and push it to the above-created repo

git init
git commit -m "first commit"
git branch -M main
git remote add origin https://github.com/username/username.github.io.git
git push -u origin main

Step 3 - Setup gh-pages

The npm package gh-pages helps in configuring and deploying your app to GitHub pages

npm install gh-pages — save-dev

Homepage property

Add the below homepage property to your package.json file.

For free GitHub user site, add this: 
"homepage": "https://{username}.github.io"

If you own a domain, add this:
"homepage": "https://mydomainname.com"

Deploy Script

Add both predeploy and deploy property scripts to the package.json as below

"predeploy": "npm run build",
"deploy": "gh-pages -d build"

predeploy - bundle the react application
deploy - deploy the bundled file.

Push these changes to the git repo

git commit -m "configure gh-pages"
git push

Step 4 - Deploy the app to GitHub Pages

Run the below command to deploy your react application to GitHub Pages

npm run deploy

Step 5 - Finally access the deployed site

• Go to the GitHub repo

• Click Settings menu

• Go to the Code and Automation -> Pages section

• In the Build and Deployment section, select Source to Deploy from a branch

• Select the branch to "gh-pages" and click on the "Save" button

Visit username.github.io and check out your site.

Yayy!

Your website is hosted for FREEEE in GitHub Pages and accessible to the world.