DEV Community: Noah Hein

Why People Hate Web3

Noah Hein — Thu, 11 Nov 2021 03:25:30 +0000

Setting the Stage

Satoshi Nakamoto released bitcoin over a decade ago, and since then has inspired builders such as Vitalik Buterin to build Ethereum. The ability to add code to a blockchain has been considered a revolutionary concept to many in the web3 community.

In the last year or so, Ethereum has absolutely taken off and has spawned a new class of internet citizens. Coming from all different kinds of backgrounds, they rallied around this new chain. A chain that, for many, revolutionized their life in a truly mind-boggling fashion.

The ethos of Ethereum has always been open, and permissionless. Instead of corporations and the 1% owning everything, it is owned by all of the users. A platform where the unit of measurement isn't a business, but an individual.

In the realm of Twitter, where much of the crypto community resides, there is a battle going on. A line has been drawn, and a fence erected; crypto enthusiasts on one side, and web native citizens on the other. My goal is to articulate where the tension comes between these two parties.

Background

As a disclaimer: I work at a blockchain company, and that has changed the trajectory for my life in a truly massive way. I catapulted from under the poverty line to the top 1% of earners for my age in the course of a year. Let it be known I am biased and do not apologize for it.

However, before I started my crypto journey, I was teaching myself to code. Trying desperately to get a job as a web developer. I met some of the most welcoming people I've bumped into on the internet in these discords.

I met my first developer friends in these communities. And while I don't hang around in these corners of the internet anymore, I have a huge amount of respect for these people, and bump into them regularly in my Twitter feed.

These communities represent diverse people that come from many walks of life, and are all unique in their own ways. However a unifying trait among all of them, is the majority are either skeptical, or outright hostile towards the technology and community of crypto.

The Disconnect

There is a divide between these two groups. The red-pilled crypto natives have seen truly life-changing amounts of money, and see a bright future for those who follow in their footsteps. They envision a world where people literally get dropped money for being users of products that participate in this ecosystem. They are being educated in the most radical way on how the current financial system works. They see now that these opportunities exist in the current iteration of the internet. But are locked-out out of participation due to geographical location, socio-economic status, or political legislation.

They speak daily in revolutionary vocabulary. A new iteration of the internet. A new way of being. Rebuilding the corrupt system they see from the ground-up. Everything is spoken in absolutes, and critique is shoved aside and labeled as small-minded, or ignorant.

The current incumbents are pragmatists. They are working every day on the tools that billions of people and businesses rely upon. They are incredibly passionate about the web, and want to see it thrive. They see the talk of web3 and wonder what's wrong with web2? Is web2 even a thing? I thought it was just the web?

Certainly one would expect to see a myriad of improvements if we were going to call it web3. What they see instead are zealots, defending their religion of blockchain tooth-and-nail. They are told they simply don't understand the technology. People with cartoon avatars of animals telling them they're ngmi.

And the technology in question? A distributed ledger that contains money with no real-world backing, touted by those who have already made millions off of the platform. A ledger that runs on everyone's computer. Spending tons of electricity for unnecessary redundancy.

Maybe they've dabbled in psychedelics and can get behind the idea that all money is made up anyways. And the aforementioned cons have some unforeseen pro to them.

But upon digging into the technology, one rapidly comes into some troubling questions. This "web3" technology is supposed to revolutionize the financial system, but costs $150 to send a jpeg with some pointer that you own it?

This sounds more and more like the four letter word that gets under any crypto enthusiast's skin. It sounds like a scam. Web3 starts to sound like Web 0.5 more and more by the second.

Moving Forward

I think that there needs to be some voices in the middle. There are concerns that need to be addressed now and not later. Conversations need to be held where people on both sides of the aisle can admit where there are trade-offs. From those conversations we can make tangible progress. Progress that creates a more inclusive, and less radicle environment for everyone.

What's always excited me about web3 is the potential to build a new system where EVERYONE is included. Systems that are built by the people, for the people. Systems that work regardless of where you are in the world, or what corrupt laws are in place. A system where you can rely upon your fellow individual, and not some billion dollar US corporation. A place where anyone's voice can be heard, and seen. A system that distributes power and control instead of consolidating it. That's what excites me.

I don't care to tell you that you could make $1M from 15k if you invest in whatever coin or NFT. I don't care to tell you that SHIB to the MOON!!!

On the other hand, I don't care to hear you dunk on harmless, well-intentioned messages like 'gm'. And I certainly don't care to have a VP of Google or Facebook tell me that what I'm doing is a scam or morally wrong.

I do care to talk to you however! Yes you reader. Whatever your opinion is, if you can communicate it clearly, respectfully, and with as little bias as you can, I'm willing to meet you half-way and do the same.

Preferably in public spaces so others can see, but in my dms is fine as well. You can find me @nheindev on the bird app.

How to Stake Funds on SushiSwap using Arbitrum

Noah Hein — Sat, 02 Oct 2021 19:29:03 +0000

Intro

Sushiswap is a DeFi platform where you can provide liquidity to pools and earn interest, as well as borrow collateral and swap various tokens.

Arbitrum is a layer-two Ethereum Network. That means it does not operate directly on Ethereum, but instead only "settles" on the layer one. All of the computing is done off-chain, which results in lower gas fees for the users, while still retaining the decentralized, secure, consensus mechanisms that run Ethereum.

Getting funds to arbitrum

You will need to use the Arbitrum bridge to get all of your current Ethereum from the mainnet to Arbitrum.

It can take up to 10 minutes for your funds to show up on the network, so do not freak out if you are unable to see your funds immediately.

After that you can then begin operating on SushiSwap through the Arbitrum Network.

Staking on Sushi

Go to SushiSwap and make sure your wallet is connected, and then change the network to Arbitrum.

It should look like this when you're done:

After that you will need to find a pool you want to provide liquidity in.

It is sorted currently top to bottom by %APR. The more liquidity is needed, the better the returns. After you find a pool you want to stake in, you will need to go to the swap tab to swap for the relevant tokens.

For example, if you wanted to farm the "WETH/LINK" pool, you will need an equal value amount of each token. You can use the swap feature on Sushi to obtain the correct amount of each token.

After you have the tokens, you will be able to provide liquidity to the pool by depositing it like so:

After depositing the two tokens to the pool, you will receive some SLP/KLP, which you can then move over to the "staking" tab. You will then begin farming rewards from the pool, in the relevant token. Each pool will show you what the rewards you will be getting are.

Having done those steps, you can then pull out your rewards, stake, and tokens at a later date of your choosing!

Disclaimer that none of this is financial advice!!

Running Your Own Ethereum Node with Geth

Noah Hein — Sat, 01 May 2021 15:46:54 +0000

Introduction

You may want to run your own Ethereum node for a multitude of reasons. If you do, you need to run an Ethereum client of some sort. There are plenty out there, but I settled on geth. An easier alternative, and one that has a nice GUI is ganache. I've also heard of hardhat.

I won't speak to the other tools I just mentioned, but I know geth can be used to deploy to the mainnet, and I wanted to futureproof my knowledge a bit. That means it doesn't have a few of the bells and whistles built-in like those other clients do.

So while we will be deploying a local node for testing a dapp; this could be used to mine real ether, transfer funds, and all the other blockchain goodies that you would expect.

This was a bit of a pain to do and I had to go scrounging through github issues to find something that worked for me. There wasn't any offical documentation that I could tell, so maybe that can be my first PR for geth. Or maybe you'll beat me to it after reading this!

Installation

I'm running Linux Mint and all commands will be listed as such

You will need to install Ethereum before anything else.

Setup the launchpad repoistory

sudo add-apt-repository -y ppa:ethereum/ethereum

I recommend using the stable version:

sudo apt-get update
sudo apt-get install ethereum

However, you can also use the development version like so:

sudo apt-get update
sudo apt-get install ethereum-unstable

If you are on another OS you can check here.

Genesis Creation

Every blockchain has to start with a single block, and that is commonly referred to as the genesis block. It doesn't hold any transactions or any relevant data. It is merely a point for all the other blocks to be based off of.

Fun bit of history, you can see Ethereum's first block here.

I will use gethTutorial as my root folder for this example.

mkdir gethTutorial && cd gethTutorial

You will want to create a folder inside of whatever root directory you're in called private.

mkdir -p private && cd private

Now for your first geth command! You will run this inside the private directory

puppeth

It will ask you for a network name. I used nheintestnet. You can use whatever you'd like.

It will ask you 6 questions, and I'll list the proper responses here:

What would you like to do? 2. configure new genesis
What would you like to do? 1. Create new genesis from scratch
Which consensus engine to use? 1. Ethash - proof-of-work
Which accounts should be pre-founded? Default option (hit enter)
Should the precompile-addresses (0x1 .. 0xff) be pre-founded with 1 wei? Default option (hit enter)
Specify your chain/netowrk ID if you want an explicit one: 4224

After that it will create a new series of questions:

What would you like to do? 2. Manage existing genesis
- 2. Export genesis configurations
- which folder to save genesis spec into? Default option (hit enter)

It will continue to ask questions, but you can exit the interface with CRTL+C at this point.

you should have 4 .json files at this point. The one of note is the plain one that has no "-" suffix. In my case: nheintestnet.json

Populating the Blockchain

We now are going to create a place to store the blockchain data and the keystores. Keystores will hold your private keys that are associated with the accounts you make on this node.

geth --datadir ~/gethTutorial/private init nheintestnet.json

You should now see chaindata and keystore folders.

Creating Accounts

Well we have a blockchain now, we just need to get some accounts to get things going.

geth --datadir . account new

It will ask you to enter a password.

Do this process 2 more times so that you have 3 accounts in total.

You should be able to see all your accounts by running

geth --datadir . account list

Starting Up the Blockchain

in your private folder create a file: startnode.sh

inside you will want to paste this:

geth --networkid 4225 --mine --miner.threads 1 --datadir "/home/noah/gethTutorial/private" --nodiscover --rpc --rpcport "8545" --port "30303" --rpccorsdomain "\*" --nat "any" --rpcapi eth,web3,personal,net --unlock 0 --password /home/noah/gethTutorial/private/password.sec --ipcpath "~/Library/Ethereum/geth.ipc" --allow-insecure-unlock

You will want to change your locations of the --datadir flag, and the --password flag arguments. You can try your luck with the ~ in the file names. The documentation says it should work from what I read, but I couldn't get it to work. I reccomend just writing the /home/user/ in the arguments.

In the private folder, create a file: password.sec

In this file, put the password of the first account you created.

To make the script executable

chmod +x startnode.sh

Then execute the script:

./startnode.sh

This will create a running Ethereum server in the terminal you ran the script in. Leave this terminal running.

Connecting to the Blockchain

Create a new terminal, and let's try to connect to our new server.

geth attach http://127.0.0.1:8545

This should open up a Geth Javascript console. You can run JS code here.

for a quick test, try to list the accounts that we have connected to this blockchain.

eth.accounts

It should spit back an array of the 3 account addresses we created.

You are now running a geth node on your computer, and also successfully connected to it! Congrats!

Building a Blockchain in Go Pt V - Wallets

Noah Hein — Mon, 26 Apr 2021 22:00:37 +0000

Hello Readers!

You may have guessed that we will be building a wallet module. You would be correct.

code can be found here

What is a Wallet?

Excellent question!

In the real world a wallet may hold your money, along with maybe your credit/debit cards or ID. However in the blockchain world your wallet does not hold any money at all. It holds all of your private keys. You went over transactions, in the previous post and used a pseudo-key to see if you were eligible to spend the money in the block that the key unlocked. This is the functionality of what keys do in the blockchain.

If you were to come up with a diagram, it would look a little something like this.

Wallet makes private key -> key unlocks block -> block releases money.

So a wallet holds keys.

That's great, but....

What is a Key?

Excellent question!

Wow, you sure do have a lot of those. Good thing I anticiapted you being such a smart cookie.

As you remember from the last section, a key will unlock the data that is representative of your money.

The thing about this "key", is there is actually two of them. They are tied together, there is a public key, and a private key.

You have a private key, and this is the one that you wallet holds. You don't want to share this with anyone, as anyone that has your private key can access all of the money that belongs to you.

You also have a public key which is tied to your private key. This key may be used by anyone, and when someone sends money to you, they use your public key to lock the funds up.

If I were to use an analogy, it would be slapping your own personal branded padlock on something. Everyone knows its your padlock, and everyone knows that only your private key will unlock it. Anyone can take your padlock and lock funds up that they want to send to you.

So in recap, you have the two keys. Your wallet generates both of them, and they are tied together. Your wallet keeps your private key a secret from everyone, while simultaneously sharing your public key with anyone who wants it.

Public keys let people lock funds up under your name.

Private keys let you unlock said funds.

Keep in mind that this is not a perfect analogy, and depending on the form of encryption you are using, these roles may be reversed. Just remember that either can lock, and whichever one locked it, the other one can unlock.

It is this mechanic where the phrase, "not your keys, not your coins" comes from.

If you are on an exchange that abstracts this wallet idea from you as a user, they are holding your keys. While this is not typically an issue, it is certainly a potential one. Many people who join blockchain technology for the decentralization and security aspect will not stomach such vulnerability.

Hopefully you now know a bit more about wallets and keys and why they are important. However, I am talking encryption here and I would be doing you a disservice to not talk about the underlying algorithms that make your keys safe from ne'er-do-wells.

A wallet has an address that is unique to itself, and is the address that people will see and use when sending you money.

This mental model is pretty simple to visualize.

However, how we generate these keys and derive the address from them is a bit more complicated. This will become apparent as we start to build out the wallet.

BUT FIRST!

House Cleaning

As per usual, there is a bit of refactoring to do before we go further.

I think it's time you boot up ye-olde code editor to follow along!

Cli Cleanup

I like my main.go files to be a bit cleaner than what it looks like currently. I'm going to abstract all of this CLI business to its own folder and have it be its own package.

You will want to create a cli folder in your root directory, and inside of it make a cli.go file.

We are going to move everything that is not inside our main function over to cli.go. The only thing to change here is you need to make the run() command start with a capital R to indicate to the go complier that it is a public method and can be called as such.

//cli.go
func (cli *CommandLine) Run(){
// Big fat function here
}

That should leave your main.go file looking like this:

//main.go
package main

import (
    "os"

    "github.com/nheingit/learnGo/cli"
)

func main() {
    defer os.Exit(0)

    cmd := cli.CommandLine{}

    cmd.Run()
}

Everything else should be in the cli.go file, with a package cli up top to declare a new package for importing. With that done we can now move on to our transactions, since our wallet will be dealing with those.

Transaction Cleanup

Most of your transaction implementation and logic will be left alone. I would like to pull out the Input and Output, along with their methods. You can place these in a new file tx.go

//tx.go

package blockchain

type TxOutput struct {
    Value int

    PubKey string
}

//Important to note that each output is Indivisible.
//You cannot "make change" with any output.
//If the Value is 10, in order to give someone 5, we need to make two five coin outputs.

type TxInput struct {
    ID []byte
    Out int
    Sig string

}

func (in *TxInput) CanUnlock(data string) bool {
    return in.Sig == data
}

func (out *TxOutput) CanBeUnlocked(data string) bool {
    return out.PubKey == data
}

That should be everything for cleanup! Good job.

Wallet Building

First off, you will want to navigate over to your Blockchain folder and add a wallet folder. Inisde wallet You should make util.go and wallet.go files.

Wallet.go

Important to note that this will be a new package

As with any go file, we need to start with our package, and import statement. I will also go ahead and include the global variable we will be using. You won't really understand it at this point. That's okay, don't worry!

//wallet.go
package wallet

import (
    "crypto/ecdsa"
    "crypto/elliptic"
    "crypto/rand"
    "crypto/sha256"
    "log"

    "golang.org/x/crypto/ripemd160"
)

const (
    checksumLength = 4
    //hexadecimal representation of 0
    version = byte(0x00)
)

After our boilerplate, we will be creating.......You guessed it! A struct.

//wallet.go
type Wallet struct {
    //ecdsa = eliptical curve digital signiture algorithm
    PrivateKey ecdsa.PrivateKey
    PublicKey  []byte
}

Now here you can see a data type that most of you will not recognize. ecdsa.Privatekey is a data type that has quite a bit going on behind the scenes. So much going on that I didn't want to just refer you to some other content.

Here's a 5 minute video explaining public/private keys, and the underlying logic.

Something not mentioned in the video is what the heck ECDSA stands for.

Elipitic Curve Digial Signature Algorithm.

With that overhead out of the way, let us continue onto generating the keys.

//wallet.go
func NewKeyPair() (ecdsa.PrivateKey, []byte) {
    curve := elliptic.P256()

    private, err := ecdsa.GenerateKey(curve, rand.Reader)
    if err != nil {
        log.Panic(err)
    }

    pub := append(private.PublicKey.X.Bytes(), private.PublicKey.Y.Bytes()...)

    return *private, pub
}

Fun Fact: This algorithm can generate potentially 10^77 number of keys. For a reference of how big that number is; it is currently estimated that there are approximately 10^80 number of atoms in the observable universe

We have a wallet, and some keys. This is where the magic happens. We now need to create a wallet address that uses our public key (created from our private key), and does a bunch of stuff to it, and then gives us an address where people can send us money!

Before you get into that, move over to your util.go file for a moment to add some utility functions.

Utility Functions

All you need to do here is add the encode and decode function for base58 algorithms.

//util.go
package wallet

import (
    "log"

    "github.com/mr-tron/base58"
)

func base58Encode(input []byte) []byte {
    encode := base58.Encode(input)

    return []byte(encode)
}

func base58Decode(input []byte) []byte {
    decode, err := base58.Decode(string(input[:]))
    if err != nil {
        log.Panic(err)
    }
    return decode
}

The only thing funny in here is we do a bit of type casting to ensure that we recieve bytes, and return bytes. The base.58Decode() method expects us to give it a string.

This portion is necessary because the base58 encode will give us a wallet address that is more readable.

It ensures that we get a shorter output, and one that doesn't have the trouble of characters like: 0, O, l, I

(zero, capital O, capital i, lowercase L)

While we will typically be copy/pasting any wallet addresses, it is nice to be able to read them and type in if necessary.

To generate this wallet address, our key is going to go through a number of processes. Here is a diagram of the pipeline our publickey will run through

Now that may be a lot to take in, so I'll break it down step-by-step for you here:

Take our public key (in bytes)
Run a SHA256 hash on it, then run a RipeMD160 hash on that hash. This is called our PublicHash
take our Publish Hash and append our Version (the global variable from earlier) to it. This is called the Versioned Hash
Run SHA256 on our Versioned Hash twice. Then take the first 4 bytes of that output. This is called the Checksum
Then we will add our Checksum to the end of our original Versioned Hash. We can call this FinalHash
Lastly, we will base58Encode our FinalHash. This is our wallet address!

Now that was quite a lot. You have to make sure your keys stay secure! Doing that while also giving people a public wallet address is a bit tricky, but this manages to do that.

Let me walk you through all of those steps, and make sure we have the functionality to do all of them.

Step 1

Take our public key (in bytes)

You have your public key available already with the NewKeyPair() function.

Step 2

Run a SHA256 hash on it, then run a RipeMD160 hash on that hash. This is called our PublicHash

We will make a function to do this.

//wallet.go
func PublicKeyHash(publicKey []byte) []byte {
    hashedPublicKey := sha256.Sum256(publicKey)

    hasher := ripemd160.New()
    _, err := hasher.Write(hashedPublicKey[:])
    if err != nil {
        log.Panic(err)
    }
    publicRipeMd := hasher.Sum(nil)

    return publicRipeMd
}

Step 3

take our Publish Hash and append our Version (the global variable from earlier) to it. This is called the Versioned Hash

This is achievable through simply calling an append() method on our hash, so this is doable already.

Step 4

Run SHA256 on our Versioned Hash twice. Then take the first 4 bytes of that output. This is called the Checksum

We can make a Checksum function:

//wallet.go
func Checksum(ripeMdHash []byte) []byte {
    firstHash := sha256.Sum256(ripeMdHash)
    secondHash := sha256.Sum256(firstHash[:])

    return secondHash[:checksumLength]
}

Step 5

Then we will add our Checksum to the end of our original Versioned Hash. We can call this FinalHash

Same as step 3, we will be able to append this to our hash, no function necessary here.

Step 6

Lastly, we will base58Encode our FinalHash. This is our wallet address!

We just built out our utility function for this. It looks like we're ready to go.

All that's left is to put it all together!

//wallet.go
func (w *Wallet) Address() []byte {
    // Step 1/2
    pubHash := PublicKeyHash(w.PublicKey)
    //Step 3
    versionedHash := append([]byte{version}, pubHash...)
    //Step 4
    checksum := Checksum(versionedHash)
    //Step 5
    finalHash := append(versionedHash, checksum...)
    //Step 6
    address := base58Encode(finalHash)
    return address
}

The next thing will be a way to initialize a wallet. We can call this MakeWallet()

//wallet.go
func MakeWallet() *Wallet {
    privateKey, publicKey := NewKeyPair()
    wallet := Wallet{privateKey, publicKey}
    return &wallet
}

That's everything for the wallet.go file!

Wallet(s)

Now that we have everything in place for a singular wallet, it would be a good idea to pluralize the functionality.

Start by making a wallets.go file

The purpose of our wallets.go file is to add persistence to our wallets, and to incorporate the CLI functions that we will be calling.

We won't be using badger for the persistence of this. We want to keep the blockchain logic and the wallet logic seperate.

Here's how the begining of your file should look:

//wallets.go
package wallet

import(
    "bytes"
    "crypto/elliptic"
    "encoding/gob"
    "fmt"
    "io/ioutil"
    "log"
    "os")

const walletFile = "./tmp/wallets.data"

Then we can add the Wallets struct.

//wallets.go
type Wallets struct {
  Wallets map[string]*Wallet
}

Now we will need a way to save and load our wallets, using the global file we made at the top.

This will need to use the encoder and ioutil libaries, in addition to the elliptic libary. This is because we need to encode our wallets on the same elliptic curve that we used originally.

Here's the save file method:

//wallets.go
func (ws *Wallets) SaveFile() {
  var content bytes.Buffer

  gob.Register(elliptic.P256())

  encoder := gob.NewEncoder(&content)
  err := encoder.Encode(ws)
  if err != nil {
    log.Panic(err)
  }

  err = ioutil.WriteFile(walletFile, content.Bytes(), 0644)
  if err != nil {
    log.Panic(err)
  }
}

Then the load will be pretty much the same thing, but opposite, in that we're using the decoder instead of the encoder

//wallets.go
func (ws *Wallets) LoadFile() error {
  if _, err := os.Stat(walletFile); os.IsNotExist(err) {
    return err
  }

  var wallets Wallets

  fileContent, err := ioutil.ReadFile(walletFile)

  gob.Register(elliptic.P256())
  decoder := gob.NewDecoder(bytes.NewReader(fileContent))
  err = decoder.Decode(&wallets)
  if err != nil {
    return err
  }

  ws.Wallets = wallets.Wallets

  return nil
}

Now we need a way to create a wallet. This will create a wallet using the MakeWallet() method that we created earlier, and then adding it to the list of wallets.

//wallets.go
func CreateWallets() (*Wallets, error) {
  wallets := Wallets{}
  wallets.Wallets = make(map[string]*Wallet)
  err := wallets.LoadFile()

  return &wallets, err
}

Now we don't want to create a new Wallets{} struct every time, so we will add a way to append to our Wallets{} struct.

//wallets.go
func (ws *Wallets) AddWallet() string {
  wallet := MakeWallet()
  address := fmt.Sprintf("%s", wallet.Address())

  ws.Wallets[address] = wallet

  return address
}

The last things we need is a way to look up a wallet by its address, and a way to list ALL of the wallets' addresses.

Here's the former:

//wallets.go
func (ws Wallets) GetWallet(address string) Wallet {
  return *ws.Wallets[address]
}

and the latter:

//wallets.go
func (ws *Wallets) GetAllAddresses() []string {
  var addresses []string

  for address := range ws.Wallets {
    addresses = append(addresses, address)
  }
  return addresses
}

That's everything we need for our wallets.go file. Now we can add the functionality to our cli.

CLI Implementation

First you will want to add your wallet package into your imports:
You will need to adjust yours based off of whatever you initialized in your go.mod file. This is mine.

//cli.go
import (
    "flag"
    "fmt"
    "log"
    "os"
    "runtime"
    "strconv"

    "github.com/nheingit/learnGo/blockchain"
    "github.com/nheingit/learnGo/blockchain/wallet" // This is the new one

)

Then we can update the printUsage method to add our new commands

//cli.go
func (cli *CommandLine) printUsage() {
    // ...
    // ...
    // Rest of commands above
    fmt.Println("createwallet - Creates a new wallet")
    fmt.Println("listaddresses - Lists the addresses in the wallet file")
}

Then to add the two methods that our CLI will call.

First up the listAddresses() method

//cli.go
func(cli *CommandLine) listAddresses() {
    wallets, _ := wallet.CreateWallets()
    addresses := wallets.GetAllAddresses()

    for _, address := range addresses {
        fmt.Println(address)
    }

}

Second, the createWallet() method.

//cli.go
func(cli *CommandLine) createWallet() {
    wallets, _ := wallet.CreateWallets()
    address := wallets.AddWallet()
    wallets.SaveFile()

    fmt.Printf("New address is: %s\n", address)

}

Next roadblock is our Run() method. We will need to add the flags, the switch statements, and then the if statements.

I'm going to dump the entire method out right here, and comment where you need to look, as I think doing these one at a time would be much too long for not much reason.

//cli.go
func (cli *CommandLine) Run() {
    cli.validateArgs()

    getBalanceCmd := flag.NewFlagSet("getbalance", flag.ExitOnError)
    createBlockchainCmd := flag.NewFlagSet("createblockchain", flag.ExitOnError)
    sendCmd := flag.NewFlagSet("send", flag.ExitOnError)
    printChainCmd := flag.NewFlagSet("printchain", flag.ExitOnError)
    createWalletCmd := flag.NewFlagSet("createwallet", flag.ExitOnError) // this Cmd is new
    listAddressesCmd := flag.NewFlagSet("listaddresses", flag.ExitOnError) // this Cmd is new

    getBalanceAddress := getBalanceCmd.String("address", "", "The address to get balance for")
    createBlockchainAddress := createBlockchainCmd.String("address", "", "The address to send genesis block reward to")
    sendFrom := sendCmd.String("from", "", "Source wallet address")
    sendTo := sendCmd.String("to", "", "Destination wallet address")
    sendAmount := sendCmd.Int("amount", 0, "Amount to send")

    switch os.Args[1] {
    case "getbalance":
        err := getBalanceCmd.Parse(os.Args[2:])
        if err != nil {
            log.Panic(err)
        }
    case "createblockchain":
        err := createBlockchainCmd.Parse(os.Args[2:])
        if err != nil {
            log.Panic(err)
        }
    case "printchain":
        err := printChainCmd.Parse(os.Args[2:])
        if err != nil {
            log.Panic(err)
        }
    case "send":
        err := sendCmd.Parse(os.Args[2:])
        if err != nil {
            log.Panic(err)
        }
    case "listaddresses": // this case statement is new
        err := listAddressesCmd.Parse(os.Args[2:])
        if err != nil {
            log.Panic(err)
        }
    case "createwallet": // this case statement is new
        err := createWalletCmd.Parse(os.Args[2:])
        if err != nil {
            log.Panic(err)
        }
    default:
        cli.printUsage()
        runtime.Goexit()
    }

    if getBalanceCmd.Parsed() {
        if *getBalanceAddress == "" {
            getBalanceCmd.Usage()
            runtime.Goexit()
        }
        cli.getBalance(*getBalanceAddress)
    }

    if createBlockchainCmd.Parsed() {
        if *createBlockchainAddress == "" {
            createBlockchainCmd.Usage()
            runtime.Goexit()
        }
        cli.createBlockChain(*createBlockchainAddress)
    }

    if printChainCmd.Parsed() {
        cli.printChain()
    }

    if sendCmd.Parsed() {
        if *sendFrom == "" || *sendTo == "" || *sendAmount <= 0 {
            sendCmd.Usage()
            runtime.Goexit()
        }

        cli.send(*sendFrom, *sendTo, *sendAmount)
    }
    if listAddressesCmd.Parsed() { // this if statement is new
        cli.listAddresses()
    }
    if createWalletCmd.Parsed(){ // this if statement is new
        cli.createWallet()
    }
}

With this change, you should now be able to boot up the command line with go run main.go
and be greeted with this:

Usage: 
getbalance -address ADDRESS - get balance for ADDRESS

createblockchain -address ADDRESS creates a blockchain and rewards the mining fee

printchain - Prints the blocks in the chain

send -from FROM -to TO -amount AMOUNT - Send amount of coins from one address to another

createwallet - Creates a new wallet

listaddresses - Lists the addresses in the wallet file

You can use go run main.go createwallet and get an output that looks something like this:

New address is: 1HMHzfY8RsNaH2JG5cNLLrZk6UBGnFEmnV

then finally go run main.go listaddresses after running createwallet a few times, will look something like this:

1HSJhCX9y6YhyPffG8vMXphfYZABJ3aaK9
15kR566wYiNDf8dCsJG91JfrVgCiQqTsFC
1M76k9VZdhvmxMong4yZQ9SqZBVZiQLnfS
1NTBAtCZjiWCXorNP45S19gyzVtdwYzV6T

That's everything for this portion!

You are done building!

You may have noticed that the interaction between our wallets and our transactions aren't integrated. Currently the wallet address is just an arbitrary string. In the next module we will incorporate the two, and add in the signature functionality of the wallets.

As always I hope you learned a thing or two, and I hope to see you in the next module!

Building a Blockchain in Go PT: IV - Transactions

Noah Hein — Thu, 15 Apr 2021 16:58:08 +0000

You can find the code here

Hello everyone!

Last I left off I was adding the ability to print out the chain that we have stored in the database. I would like to start approaching something that people would find a bit more recognizable as a blockchain. That would be crypto! Many people that aren't in the thick of things would tell you that bitcoin and blockchain are the same thing. So to take a step into the mainstream I would like to add wallets.

Wallets have many moving parts to them, so we are looking at one piece of the puzzle specifically. That will be transactions.

Building Transactions

A wallet module is a bit complicated. I thought transactions would be a good place to start. In order to have transactions, we need to have a transaction struct. We also need a way to generate some "coins". This allows us to actually insert something into the transaction. As I talked about earlier in the series, bitcoin "miners" get fees for doing the expensive work of blockchain mining. We can start there.

The `Transaction` struct

So to start things out, as in our previous chapters, we will make a new file in our Blockchain folder called transaction.go

//transaction.go
type Transaction struct {
    ID      []byte
    Inputs  []TxInput
    Outputs []TxOutput
}

Looks pretty straightforward right? A transaction should have a unique ID to differentiate itself from the many other transactions. It goes TO someone, and it comes FROM someone. That means we need Inputs and Outputs fields.

Don't get too ahead of yourself though, you'll notice those aren't primitive data types. We are gonna have to make those inputs and outputs ourselves. Let's see what that looks like.

type TxOutput struct {
    Value int
    //Value would be representative of the amount of coins in a transaction
    PubKey string
    //The Pubkey is needed to "unlock" any coins within an Output. This indicated that YOU are the one that sent it.
    //You are indentifiable by your PubKey
    //PubKey in this iteration will be very straightforward, however in an actual application this is a more complex algorithm
}
//TxInput is representative of a reference to a previous TxOutput
type TxInput struct {
    ID []byte
    //ID will find the Transaction that a specific output is inside of
    Out int
    //Out will be the index of the specific output we found within a transaction.
    //For example if a transaction has 4 outputs, we can use this "Out" field to specify which output we are looking for
    Sig string
    //This would be a script that adds data to an outputs' PubKey
    //however for this tutorial the Sig will be indentical to the PubKey.
}

With that piece finished we can get onto initializing our first transaction.

Coinbase Transaction

Not THAT coinbase. The first transaction in a block is called a Coinbase. Our first transaction will be when a new block is "mined" as it were. So upon our Genesis call, we will want to add some coins inside of the block to be rewarded to whoever is fortunate enough to crack the code. Similar to our Blocks, we don't have any previous transactions to point back to. This means we will need to set an empty TxInput for our first transaction.

The following function should incorporate everything I just mentioned above.

//transaction.go

func CoinbaseTx(toAddress, data string) *Transaction {
    if data == "" {
        data = fmt.Sprintf("Coins to %s", toAddress)
    }
    //Since this is the "first" transaction of the block, it has no previous output to reference.
    //This means that we initialize it with no ID, and it's OutputIndex is -1
    txIn := TxInput{[]byte{}, -1, data}

    txOut := TxOutput{reward, toAddress}

    tx := Transaction{nil, []TxInput{txIn}, []TxOutput{txOut}}

    return &tx

}

You may get a warning because you are referencing reward which is undefined currently. Go to the top of your file, and initialize a constant global variable named reward with a value of 100.

const reward = 100

Great! We have the goody egg on standby.

Utility functions.

I won't go over these too much as I believe they explain themselves quite nicely.

You are reading the code right?

SetID will encode and hash our Transactions ID field. We then use the CanUnlock and CanBeUnlocked methods to check that the Sig and the PubKey are correct. The last one is checking a transaction to see if it was a coinbase transaction.

//transaction.go

func (tx *Transaction) SetID() {
    var encoded bytes.Buffer
    var hash [32]byte

    encoder := gob.NewEncoder(&encoded)
    err := encoder.Encode(tx)
    Handle(err)

    hash = sha256.Sum256(encoded.Bytes())
    tx.ID = hash[:]

}

func (in *TxInput) CanUnlock(data string) bool {
    return in.Sig == data
}
func (out *TxOutput) CanBeUnlocked(data string) bool {
    return out.PubKey == data
}

func (tx *Transaction) IsCoinbase() bool {
    //This checks a transaction and will only return true if it is a newly minted "coin"
    return len(tx.Inputs) == 1 && len(tx.Inputs[0].ID) == 0 && tx.Inputs[0].Out == -1
}

I think that is everything we need for transaction for now.

Let's go add it to our Blocks!

Implementing Transactions

We are done with our transaction.go file for now. Let us move over to our block.go file.
Since we now have transactions, this will replace our Data field in our Block struct.

//block.go
type Block struct {
    Hash     []byte
    Transactions []*Transaction
    PrevHash []byte
    Nonce    int
}

With that done you will notice your entire project becomes inundated with errors.

Do not worry, we will be working through our refactoring, and hopefully when we're done everything will compile!

Updating Methods

In our CreateBlock method, we will want to change the Data string in our parameters. Instead we will put in txs []*Transaction.

//block.go
func CreateBlock(txs []*Transaction, prevHash []byte) *Block {
    block := &Block{[]byte{}, txs, prevHash, 0}
    pow := NewProofOfWork(block)
    nonce, hash := pow.Run()

    block.Hash = hash[:]
    block.Nonce = nonce

    return block
}

With that out of the way, we meander our way to the Genesis function. We need to add an empty Transaction to our Genesis block.

//block.go
func Genesis(coinbase *Transaction) *Block {
    return CreateBlock([]*Transaction{coinbase}, []byte{})
}

Data Hashing

The last thing we have to do is build a method that takes all of the transactions existing in a block and hashes them.

//block.go
func (b *Block) HashTransactions() []byte {
    var txHashes [][]byte
    var txHash [32]byte

    for _, tx := range b.Transactions {
        txHashes = append(txHashes, tx.ID)
    }
    txHash = sha256.Sum256(bytes.Join(txHashes, []byte))

    return txHash[:]
}

That should be all of the changes we need to make in our block.go file for the time being.

Time to hop over to proof.go!

Proof of Work Changes

This one should be super quick, we just need to change the InitData method. Since it calls to Block.Data which no longer exists. However, this is where our previous function comes in handy. Since this method is expecting everything to be in bytes, we can call our new function. Our refactored InitData method should look like this.

//proof.go
func (pow *ProofOfWork) InitData(nonce int) []byte {
    data := bytes.Join(
        [][]byte{
            pow.Block.PrevHash,
            pow.Block.HashTransactions(), // THIS IS THE LINE WE CHANGED
            toHex(int64(nonce)),
            toHex(int64(Difference)),
        },
        []byte{},
    )
    return data
}

Great job! We're all done here.

We can now move onto our last file in the blockchain folder, which is blockchain.go.

Blockchain Changes

Alrighty, back to the fun stuff we were doing with the database before!

Moving forward, we need to add a few more global constants at the top of our blockchain.go file. We want to add a dbFile, and genesisData. so right under our imports we want to initialize our constants like so:

//blockchain.go
const (
    dbPath = "./tmp/blocks"

    // This can be used to verify that the blockchain exists
    dbFile = "./tmp/blocks/MANIFEST" 

    // This is arbitrary data for our genesis block
    genesisData = "First Transaction from Genesis" 
)

You may have noticed when you finished part III, that whenever you ran the code, in the /tmp/blocks folder that it creates a Manifest file. This is what we are setting the dbFIle to.

It allows us to check if a blockchain already exists or not.

The genesisData is simply some data to provide our genesis block so it won't be empty.

We will need to Breakup our InitBlockChain function so we can more easily reference our transactions using the cli later. Currently there a large if/else block, that essentially checks if we've already got a database, and responds conditionally.

We will break this up into an InitBlockChain and ContinueBlockChain function. We can break this function cleanly at the if/else junction. The logic that is inside each portion will be placed into its own function. The only caveat is we will need to duplicate the extra code that is required to make database transactions.

Before I show you what each function looks like, I would like to add a quick utility that we can use to check if the blockchain exists already.

//blockchain.go

//DBexists checks to see if we've initialized a database
func DBexists(db) bool {
    if _, err := os.Stat(db); os.IsNotExist(err) {
        return false
    }
    return true
}

With this we can pass the dbFile constant to the function, and it will give us a Boolean value in return.

Alrighty, back to the splitting of our initBlockChain function. As stated before, we will split the if/else logic into its own function. One will handle if the database exists, and one will handle if it doesn't exist.

The main difference being, if the database/blockchain does not exist, we need to add the CoinbaseTx.

We want to get some transaction action goin' on!

Enough explanation, SHOW ME THE CODE!

//blockchain.go
func InitBlockChain(address string) *BlockChain {
    var lastHash []byte

    if DBexists(dbFile) {
        fmt.Println("blockchain already exists")
        runtime.Goexit()
    }

    opts := badger.DefaultOptions(dbPath)
    db, err := badger.Open(opts)
    Handle(err)

    err = db.Update(func(txn *badger.Txn) error {

        cbtx := CoinbaseTx(address, genesisData)
        genesis := Genesis(cbtx)
        fmt.Println("Genesis Created")
        err = txn.Set(genesis.Hash, genesis.Serialize())
        Handle(err)
        err = txn.Set([]byte("lh"), genesis.Hash)

        lastHash = genesis.Hash

        return err

    })

So that's the first one.

Here's the ContinueBlockChain function.

//blockchain.go

//I Know we don't reference address anywhere in here. Keep it anyway.
func ContinueBlockChain(address string) *BlockChain {
    if DBexists(dbFile) == false {
        fmt.Println("No blockchain found, please create one first")
        runtime.Goexit()
    }

    var lastHash []byte

    opts := badger.DefaultOptions(dbPath)
    db, err := badger.Open(opts)
    Handle(err)

    err = db.Update(func(txn *badger.Txn) error {
        item, err := txn.Get([]byte("lh"))
        Handle(err)
        err = item.Value(func (val []byte) error {
            lastHash = val
            return nil
        })
        handle(err)
        return err
    })
    Handle(err)

    chain := BlockChain{lastHash, db}
    return &chain
}

The main difference, is now the InitBlockChain has a parameter that we can pass an argument to. This argument will be the address of the person that mined the block.
Now that we have done that, we will be able to get to the good stuff.

Adding Transactions

So with those two functions split up we will have a way to implement the CLI to check the balance of an account as well as being able to send coins from one account to another.

You may have noticed that while an TxOutput is representative of some action between two addresses, TxInput is merely a reference to a previous TxOutput.

This may not be immeaditely apparent, but because of this we are able to figure out the balance of an account. This is because we can check for all of the outputs that an account has linked to it, and then check all of the inputs. Whichever outputs do not have an input pointing to it will be spendable.

Let me say that again. Transactions that have outputs, but no inputs pointing to them are spendable. We will call these Unspent Transactions.

Let's build that out.

Finding Unspent Transactions

Remember when I said I wouldn't be teaching you go?
This may be one of those moments where you have to pause and read some other material for a bit if you aren't quite familiar with everything yet.

However, I will send you along with some relevant resources.

I use this site all the time. Many people think you go through it once and that's it. That couldn't be farther from the truth. I encourage you do run through this one multiple times and refer back to it often.

Here it is https://gobyexample.com/

This is a good place to start for maps.

Here is a resource for labesl as well.

//blockchain.go
func (chain *BlockChain) FindUnspentTransactions(address string) []Transaction {
    var unspentTxs []Transaction

    spentTXNs := make(map[string][]int)

    iter := chain.Iterator()

    for {
        block := iter.Next()

        for _, tx := range block.Transactions {
            txID := hex.EncodeToString(tx.ID)

        Outputs:
            for outIdx, out := range tx.Outputs {
                if spentTXNs[txID] != nil {
                    for _, spentOut := range spentTXNs[txID] {
                        if spentOut == outIdx {
                            continue Outputs
                        }
                    }
                }
                if out.CanBeUnlocked(address){
                    unspentTxs = append(unspentTxs, *tx)
                }
            }
            if tx.IsCoinbase() == false {
                for _, in := range tx.Inputs {
                    if in.CanUnlock(address) {
                        inTxID := hex.EncodeToString(in.ID)
                        spentTXNs[inTxID] = append(spentTXNs[inTxID], in.Out)
                    }
            }
        }
        if len(block.PrevHash) == 0 {
            break
        }
    }
    return unspentTxs

}

This is a lot to unpack!

We can break this function down into a few parts.

We need to loop through our entire chain, and we can do that like we did before using the chain.Iterator().Next() method.

We want to loop through each blocks Transactions.
As we loop through the Transactions, we also want to take a look at all of the Outputs that each one has.
If at anypoint during this we find a txID we know this Output has been spent.
At this point we hit the continue Outputs line and continue to our next conditional.
We now loop through the outputs that are available for spending.

We know they are spendable because they have no inputs associated with them

Now we can check if these Outputs can be unlocked.

Using our CanBeUnlocked method, we just need to pass in the address.

If that returns true we can add it to our unspentTxs variable that we declared at the top of the method.

With all of that is done; we can move on to the next portion of the method.

Keep in mind that we are still looping through each blocks transactions at this point.

Now we check if the Transaction is a coinbase transaction.

If it isn't, we can look through all of the Inputs.

If an input has a matching address, we can add the Input's ID to the spentTXNs map that we were checking our outputs against above.

At the end, return all of the unspent transactions that we gathered for the particular address.

Congradulations! We're all done here.

Finding Unspent Transaction Outputs

Luckily that above function is the most complicated thing we will be dealing with. Now that we have a way to find all of the unspent transactions, we can narrow it down a bit and look for the unspent outputs.

//blockchain.go
func (chain *BlockChain) FindUTXO(address string) []TxOutput {
    var UTXOs []TxOutput
    unspentTransactions := chain.FindUnspentTransactions(address)
    for _, tx := range unspentTransactions {
        for _, out := range tx.Outputs {
            if CanBeUnlocked(address) {
                UTXOs = append(UTXOs, out
            }
        }
    }

    return UTXOs
}

Loop through all of the unspent transactions and see if we can unlock the outputs.

Add them all to an array and return that array of TxOutputs

Finding Unspent Transaction Outputs That Are Spendable

Now to the fun bit! we have narrowed down our search into the thing we actually care about. Spending money!

Currently the only way to make a transaction is to be a coinbase transaction which defeats the purpose of the whole "blockchain" thing we have goin' on. What point is there in having money if you can only make more by mining it?

We should be able to spread the wealth. In order to do that we need to find all of the spendable outputs. Just because there is an output that hasn't been spent, doesn't mean that ANYONE can spend it. Only the person with the key has those honors.

The following will be a function that takes an account's address, and the amount that we would like to spend. It returns a tuple that contains the amount we can spend, and a map of the aggregated outputs that can make that happen.

//blockchain.go
func (chain *BlockChain) FindSpendableOutputs(address string, amount int) (int, map[string][]int) {
    unspentOuts := make(map[string][]int)
    unspentTxs := chain.FindUnspentTransactions(address)
    accumulated := 0

Work:
    for _, tx := range unspentTxs {
        txID := hex.EncodeToString(tx.ID)
        for outIdx, out := range tx.Outputs {
            if out.CanBeUnlocked(address) && accumulated < amount {
                accumulated += out.Value
                unspentOuts[txID] = append(unspentOuts[txID], outIdx)

                if accumulated >= amount {
                    break Work
                }
            }
        }
    }
    return accumulated, unspentOuts
}

Alrighty, with that done we can make the last change in our blockchain.go file.

Our AddBlock method is still using data as a paramter, and passes it down to createBlock as an argument. We need to change both of those to be transactions. The new function will be shown below. Try not to just copy/paste everything. Look for what changed and why! Understanding the flow of data in your program is critical.

//blockchain.go
//DATA STRING ---> TRANSACTIONS []*TRANSACTION
func (chain *BlockChain) AddBlock(transactions []*Transaction) {
    var lastHash []byte

    err := chain.Database.View(func(txn *badger.Txn) error {
        item, err := txn.Get([]byte("lh"))
        Handle(err)
        err = item.Value(func(val []byte) error {
            lastHash = val
            return nil
        })
        Handle(err)
        return err
    })
    Handle(err)

    newBlock := CreateBlock(transactions, lastHash) //THIS LINE CHANGED
    err = chain.Database.Update(func(transaction *badger.Txn) error {
        err := transaction.Set(newBlock.Hash, newBlock.Serialize())
        Handle(err)
        err = transaction.Set([]byte("lh"), newBlock.Hash)

        chain.LastHash = newBlock.Hash
        return err
    })
    Handle(err)
}

We can now save our blockchain file with no more errors and move onto the rest of our program.

Spending Coins!

With all of our data running smoothly through our blockchain, we can go back to our transaction.go file and add our last function before moving onto our CLI.

We need this function to do a few things:

Find Spendable Outputs
Check if we have enough money to send the amount that we are asking
If we do, make inputs that point to the outputs we are spending
If there is any leftover money, make new outputs from the difference.
Initialize a new transaction with all the new inputs and outputs we made
Set a new ID, and return it.

Let's get typing!

//transaction.go
func NewTransaction(from, to string, amount int, chain *BlockChain) *Transaction {
    var inputs []TxInput
    var outputs []TxOutput

    //STEP 1
    acc, validOutputs := chain.FindSpendableOutputs(from, amount)

    //STEP 2
    if acc < amount {
        log.Panic("Error: Not enough funds!")
    }

    //STEP 3
    for txid, outs := range validOutputs {
        txID, err := hex.DecodeString(txid)
        Handle(err)

        for _, out := range outs {
            input := TxInput{txID, out, from}
            inputs = append(inputs, input)
        }
    }

    outputs = append(outputs, TxOutput{amount, to})

    //STEP 4
    if acc > amount {
        outputs = append(outputs, TxOutput{acc - amount, from})
    }

    //STEP 5
    tx := Transaction{nil, inputs, outputs}
    //STEP 6
    tx.SetID()

    return &tx
}

Awesome! That's all we need to complete the transaction.go file.

Updating The CLI

Okay, so we're all done with the heavy lifting, now we just have some updating of functions.

Moving to main.go

Let's start by simplifying our lives a bit.

We're going to remove the blockchain field within our CommandLine struct.

It should now look like this:

type CommandLine struct {}

Now to update our printUsage method.

We will no longer support the addBlock method. We can delete that whole function.

Afterwards we will want to add 3 more functions.

getbalance
createblockchain
send

That means we need to tell our users how this cli operates. The new printUsage should look like:

 //main.go
 func (cli \*CommandLine) printUsage() {

 fmt.Println("Usage: ")

 fmt.Println("getbalance -address ADDRESS - get balance for ADDRESS")

 fmt.Println("createblockchain -address ADDRESS creates a blockchain and rewards the mining fee")

 fmt.Println("printchain - Prints the blocks in the chain")

 fmt.Println("send -from FROM -to TO -amount AMOUNT - Send amount of coins from one address to another")

}

After this go to printChain and remove the line that was displaying the data field of the block, as data no longer exists.

Now to create the new methods that we outlined in our printUsage method.

first createBlockChain:

 //main.go

 func (cli *CommandLine) createBlockChain(address string) {
    newChain := blockchain.InitBlockChain(address)
    newChain.Database.Close()
    fmt.Println("Finished creating chain")
}

WIth that out of the way we can move to getBalance

//main.go
func (cli *CommandLine) getBalance(address string) {
    chain := blockchain.ContinueBlockChain(address)
    defer chain.Database.Close()

    balance := 0
    UTXOs := chain.FindUTXO(address)

    for _, out := range UTXOs {
        balance += out.Value
    }

    fmt.Printf("Balance of %s: %d\n", address, balance)
}

Fantastic, moving through at a blazing pace! Time to send money!

//main.go

func (cli *CommandLine) send(from, to string, amount int) {
    chain := blockchain.ContinueBlockChain(from)
    defer chain.Database.Close()

    tx := blockchain.NewTransaction(from, to, amount, chain)

    chain.AddBlock([]*blockchain.Transaction{tx})
    fmt.Println("Success!")
}

Now we have to update all of our CLI flags and strings inside the run method. Feel free to copy paste this bit honestly. It was very painful to write out.

//main.go
func (cli *CommandLine) run() {
    cli.validateArgs()

    getBalanceCmd := flag.NewFlagSet("getbalance", flag.ExitOnError)
    createBlockchainCmd := flag.NewFlagSet("createblockchain", flag.ExitOnError)
    sendCmd := flag.NewFlagSet("send", flag.ExitOnError)
    printChainCmd := flag.NewFlagSet("printchain", flag.ExitOnError)

    getBalanceAddress := getBalanceCmd.String("address", "", "The address to get balance for")
    createBlockchainAddress := createBlockchainCmd.String("address", "", "The address to send genesis block reward to")
    sendFrom := sendCmd.String("from", "", "Source wallet address")
    sendTo := sendCmd.String("to", "", "Destination wallet address")
    sendAmount := sendCmd.Int("amount", 0, "Amount to send")

    switch os.Args[1] {
    case "getbalance":
        err := getBalanceCmd.Parse(os.Args[2:])
        if err != nil {
            log.Panic(err)
        }
    case "createblockchain":
        err := createBlockchainCmd.Parse(os.Args[2:])
        if err != nil {
            log.Panic(err)
        }
    case "printchain":
        err := printChainCmd.Parse(os.Args[2:])
        if err != nil {
            log.Panic(err)
        }
    case "send":
        err := sendCmd.Parse(os.Args[2:])
        if err != nil {
            log.Panic(err)
        }
    default:
        cli.printUsage()
        runtime.Goexit()
    }

    if getBalanceCmd.Parsed() {
        if *getBalanceAddress == "" {
            getBalanceCmd.Usage()
            runtime.Goexit()
        }
        cli.getBalance(*getBalanceAddress)
    }

    if createBlockchainCmd.Parsed() {
        if *createBlockchainAddress == "" {
            createBlockchainCmd.Usage()
            runtime.Goexit()
        }
        cli.createBlockChain(*createBlockchainAddress)
    }

    if printChainCmd.Parsed() {
        cli.printChain()
    }

    if sendCmd.Parsed() {
        if *sendFrom == "" || *sendTo == "" || *sendAmount <= 0 {
            sendCmd.Usage()
            runtime.Goexit()
        }

        cli.send(*sendFrom, *sendTo, *sendAmount)
    }
}

The very last thing to do is remove the database portion of the main command!

The new one should look like this:

func main() {
    defer os.Exit(0)
    cli := CommandLine{}
    cli.run()

Now we're all done!

I won't hold your hand through how to use this as I'm sure with the wonderful usage flags we made you'll be able to figure it out. The only thing to be aware of is if you have an existing chain in your tmp/blocks folder you will need to delete that before using this new fancy stuff as we can only have one chain at a time currently.

Please leave any questions you may have in the comments and I'll try my best to help you out!

Until next time!

Building a Blockchain in Go PT: III (extended) - CLI

Noah Hein — Sun, 04 Apr 2021 15:46:26 +0000

Hey everyone! I hope you've stuck through with me this far. Things start to get a bit more complicated as we go along. I am trying to structure these in such a way that you don't need to stop between portions to learn other relevant material before coming back, but don't feel bad if you do have to do that.

I left off with a bit of a cliffhanger as I gave you an entirely new main.go file and just told you "Good luck!". This post will hopefully demystify that file for you if you didn't quite comprehend it. Maybe you took it upon yourself to see what was actually going on without my explaining of it. If you did, maybe you could comment below what the hardest part was for you?

Command Line

Alrighty, so we are looking to add cli capability to our app. If you have noticed a trend here, anytime I'm adding functionality, I start with a struct. This keeps things easier to reason about in my head.

//main.go
type CommandLine struct {
    blockchain *blockchain.BlockChain
}

Notice that we have *blockchain.Blockchain. That is because we are no longer working within the blockchain package itself, so we have to call the package blockchain, and then the BlockChain struct within that package.

With that out of the way we can start adding methods to our new struct. I think a good place to start would be an introduction to the cli. Similar to a --help flag in many of your favorite packages or frameworks.

//main.go
//printUsage will display what options are availble to the user
func (cli *CommandLine) printUsage() {
    fmt.Println("Usage: ")
    fmt.Println(" add -block <BLOCK_DATA> - add a block to the chain")
    fmt.Println(" print - prints the blocks in the chain")
}

Next we will want to close out our runtime if the user passes an invalid argument to our cli.

//main.go
//validateArgs ensures the cli was given valid input
func (cli *CommandLine) validateArgs() {
    if len(os.Args) < 2 {
        cli.printUsage()
        //go exit will exit the application by shutting down the goroutine
        // if you were to use os.exit you might corrupt the data
        runtime.Goexit()
    }
}

Next we can use the AddBlock() method that we modified in our previous tutorial to......Add a block.

//main.go
//addBlock allows users to add blocks to the chain via the cli
func (cli *CommandLine) addBlock(data string) {
    cli.blockchain.AddBlock(data)
    fmt.Println("Added Block!")
}

As a quick recap, we have a way to tell the user how the cli functions, we can add blocks to the chain, and users don't get stuck when providing invalid input. Next it would be nice if we could view our chain. Let's see what that looks like!

//main.go
//printChain will display the entire contents of the blockchain
func (cli *CommandLine) printChain() {
    iterator := cli.blockchain.Iterator()

    for {
        block := iterator.Next()
        fmt.Printf("Previous hash: %x\n", block.PrevHash)
        fmt.Printf("data: %s\n", block.Data)
        fmt.Printf("hash: %x\n", block.Hash)
        pow := blockchain.NewProofOfWork(block)
        fmt.Printf("Pow: %s\n", strconv.FormatBool(pow.Validate()))
        fmt.Println()
        // This works because the Genesis block has no PrevHash to point to.
        if len(block.PrevHash) == 0 {
            break
        }
    }
}

Here we were able to use the Next() method that we coded in the previous post. This method is how we are able to navigate a for loop to print out our entire blockchain.

The last thing to do is code up a run() method. We will use a switch statement and the Parsed method that we get from the flag package.

//main.go
//run will start up the command line
func (cli *CommandLine) run() {
    cli.validateArgs()

    addBlockCmd := flag.NewFlagSet("add", flag.ExitOnError)
    printChainCmd := flag.NewFlagSet("print", flag.ExitOnError)
    addBlockData := addBlockCmd.String("block", "", "Block data")

    switch os.Args[1] {
    case "add":
        err := addBlockCmd.Parse(os.Args[2:])
        blockchain.Handle(err)

    case "print":
        err := printChainCmd.Parse(os.Args[2:])
        blockchain.Handle(err)

    default:
        cli.printUsage()
        runtime.Goexit()
    }
    // Parsed() will return true if the object it was used on has been called
    if addBlockCmd.Parsed() {
        if *addBlockData == "" {
            addBlockCmd.Usage()
            runtime.Goexit()
        }
        cli.addBlock(*addBlockData)
    }
    if printChainCmd.Parsed() {
        cli.printChain()
    }
}

Now we have all the tools in place to actually run a very barebones cli for our blockchain. The last thing we have to do is stick it in our main function.

//main.go
func main() {
    defer os.Exit(0)

    chain := blockchain.InitBlockChain()
    defer chain.Database.Close()

    cli := CommandLine{chain}

    cli.run()

}

The defer keyword that we use is in place to make sure that we don't corrupt any of the bytes going into our database. It essentially just lets everything shutdown nicely. This is similar to why we use the Goexit() call instead of the similar OS exit that is also available. It allows time for all of our I/O to the database to finish up before exiting the program.

I hope you learned something from this. Maybe you already taught yourself all of this since I posted part III earlier! That's always where you learn the most, when you have to struggle a bit for that knowledge!

As always leave a comment if you have any questions or concerns. I'd love to help you out.

Building a Blockchain in Go PT: III - Persistence

Noah Hein — Mon, 29 Mar 2021 00:45:53 +0000

Alrighty everyone, its time to put on the adult pants today. We're going to be adding persistence to our blockchain. You may have noticed that we've been generating a new blockchain each time we run the program. As soon as you close your terminal, poof it vanishes. Maybe you're into that, I don't know your life. I however, very much like it when things stick around after I'm done programming them.

For this endeavor I wanted to have something very quick and simple. I wanted to use something unique to the Golang ecosystem. I also hadn't used a key/value database before, and this felt like a wonderful excuse to learn more about it.

With these criteria it felt like there was an obvious option, as it nailed all three of these requirements. It is easy to setup, unique to go, and is a key/value store. I would like to introduce to you, BadgerDB! We will use V 1.6.2 for this tutorial. This database is the owner of that incredibly cute mascot you see next to our beloved gopher above.

We know we want to add a database, and we also know what tech we're going to use to do it. So, without further ado, let's hop into it!

Refactoring

More refactoring! You thought you were done after part II didn't you? WRONG! This is just as much to show you how a project evolves as you add functionality to it, as it is to show you how to add the functionality itself.

tmp/blocks

In our root directory, we want to make a tmp folder, and inside that we want to make a blocks folder.

So after you are done with that your directory should look like this

That's all we need to do for now. We will come back to this later.

block.go

In our block.go file we're going to need to add some utility functions. I'm going to want to Serialize/Deserialize our Blocks. In addition to that we are going to have quite a lot of errors returned, and we will want a way to handle them. All-in-all a total of 3 functions to add; let's get to it.

Handle()

Go handles errors differently than many other languages. many of the functions we are calling will return an error, along with the value. We need to make sure these errors are empty before proceeding.

Error handling in go is a whole topic with different opinions and areas to dive deep in. So keep in mind this function is about as bare-bones as it gets.

//block.go
func Handle(err error) {
    if err != nil {
        log.Panic(err)
    }
}

Alrighty! Moving on.

Serialize()

To convert our Block struct into bytes we are going to use the encoder/gob library.

//block.go
func (b *Block) Serialize() []byte {
    var res bytes.Buffer
    encoder := gob.NewEncoder(&res)

    err := encoder.Encode(b)

    Handle(err)

    return res.Bytes()
}

This will take our Blocks, encode everything down into bytes, handle the error, and then return the bytes.

Deserialize()

So we have a way to go from Blocks to bytes. It would be helpful if I had a way to reverse that process.

//block.go
func Deserialize(data []byte) *Block {
    var block Block

    decoder := gob.NewDecoder(bytes.NewReader(data))

    err := decoder.Decode(&block)

    Handle(err)

    return &block
}

Excellent!

We now have a way to turn our blocks into bytes and vice versa. We can handle any errors that may come along the way as well. However, there is another matter to attend to. There are a few functions in our block.go file that are dealing with BlockChain logic. I would like to move these to a separate blockchain.go file, so that we can expand upon its' functionality.

This means we will be moving the BlockChain struct, InitBlockChain method and AddBlock method to a new file.

blockchain.go

In our blockchain folder, add a blockchain.go file. This is going to house all of our new blockchain logic and how we are going to connect to our database.

As always with a new go file, the first line needs to declare what package it is. After that we need to do some imports, and then we can start coding from there. Here's what we should start out with:

//blockchain.go
package blockchain

import (
    "fmt"

    "github.com/dgraph-io/badger" // This is our database import

)

The next thing we will want to do is decide where we would like to store our new blockchain. Luckily for you, I had you do this already! Our tmp/blocks folder is a wonderful place to store all of your data.
We just need to add a constant to use throughout our code.

const dbPath = "./tmp/blocks"

After this we want our new BlockChain struct. We need to make some changes to it. Before it was just an array of pointers to other Blocks, but now we need to get the database involved. Below is what our new struct will look like.

//blockchain.go
type BlockChain struct {
    LastHash []byte
    Database *badger.DB
}

InitBlockChain()

Now for the InitBlockChain method from earlier. We can scrap the old one entirely. When you create a new blockchain, you will need to do a few things if you want to have the blockchain be persistent. What this means is you need to have some requirements in mind before we start banging it out. Your blockchain needs to do the following:

Open a connection to the database
Check if there is already a blockchain
If there isn't, create one
If there is, grab it

Now that we have a plan in mind, we can begin executing on it. BadgerDB uses transactions to access the database. You can only access the key/value pairs that exist within the database inside of a transaction. This means every time we are going into the database, we need to open up a transaction. With an opened transaction, we can extract whatever data we were looking for and handle errors.

I think you are properly equipped at this point to start writing out some code! This function is a bit bigger, so we will follow the steps that I outlined above to keep on track.

Open a connection to the database

//blockchain.go

func InitBlockChain() *BlockChain {
    var lastHash []byte

    opts := badger.DefaultOptions(dbPath)

    db, err := badger.Open(opts)
    Handle(err)
    //part 1 finished
}

There is some configuration that you can do within the badger.Options, but for our purposes the default options will be just fine.

Check if there is already a blockchain.

checking is just one line, so we will combine checking if it exists, and making a new one if it doesn't.

//blockchain.go
func InitBlockChain() *BlockChain {
    var lastHash []byte

    opts := badger.DefaultOptions(dbPath)

    db, err := badger.Open(opts)
    Handle(err)
    //part 1 finished

    err = db.Update(func(txn *badger.Txn) error {
        // "lh" stand for last hash
        if _, err := txn.Get([]byte("lh")); err == badger.ErrKeyNotFound {
            fmt.Println("No existing blockchain found")
            genesis := Genesis()
            fmt.Println("Genesis proved")
            err = txn.Set(genesis.Hash, genesis.Serialize())
            Handle(err)
            err = txn.Set([]byte("lh"), genesis.Hash)

            lastHash = genesis.Hash

            return err
            //part 2/3 finished
}

Starting at the top we try to get a byte with the "lh" (last hash) key. This will grab the most recently added block in the chain if it exists. However it returns an error that we should check before going further. We can use the badger.ErrKeyNotFound to determine whether or not the "lh" key exists. If that error comes back, we create a new block using our Genesis function. At that point we can Serialize our Block and use txn.Set() to place it in the database.

That was steps 1-3, now we can do the last step:

If it is there, grab it.

//blockchain.go
func InitBlockChain() *BlockChain {
    var lastHash []byte

    opts := badger.DefaultOptions(dbPath)

    db, err := badger.Open(opts)
    Handle(err)
    //part 1 finished

    err = db.Update(func(txn *badger.Txn) error {
        // "lh" stand for last hash
        if _, err := txn.Get([]byte("lh")); err == badger.ErrKeyNotFound {
            fmt.Println("No existing blockchain found")
            genesis := Genesis()
            fmt.Println("Genesis proved")
            err = txn.Set(genesis.Hash, genesis.Serialize())
            Handle(err)
            err = txn.Set([]byte("lh"), genesis.Hash)

            lastHash = genesis.Hash

            return err
            //part 2/3 finished
        } else {
            item, err := txn.Get([]byte("lh"))
            Handle(err)
            err = item.Value(func(val []byte) error {
                lastHash = val
                return nil
            })
            Handle(err)
            return err
        }
    })
    Handle(err)

    blockchain := BlockChain{lastHash, db}
    return &blockchain
    //that's everything!
}

Awesome! We now have a way to make a new blockchain that will live after we close the terminal.

AddBlock()

With our initialization out of the way, we can loop back around to our AddBlock function that we had previously implemented.

In order to do this, we will need to grab the lastHash of the most recent Block in our BlockChain. Following that, we will use a BadgerDB Transaction to Set our new block. Then we can serialize our data, set the new block hash, and then set the last hash.

Putting together everything we just outlined above, we will end up with a function like this.

//blockchain.go
func (chain *BlockChain) AddBlock(data string) {
    var lastHash []byte

    err := chain.Database.View(func(txn *badger.Txn) error {
        item, err := txn.Get([]byte("lh"))
        Handle(err)
        err = item.Value(func(val []byte) error {
            lastHash = val
            return nil
        })
        Handle(err)
        return err
    })
    Handle(err)

    newBlock := CreateBlock(data, lastHash)

    err = chain.Database.Update(func(transaction *badger.Txn) error {
        err := transaction.Set(newBlock.Hash, newBlock.Serialize())
        Handle(err)
        err = transaction.Set([]byte("lh"), newBlock.Hash)

        chain.LastHash = newBlock.Hash
        return err
    })
    Handle(err)
}

I won't go into as much detail on this implementation. If you are able to understand the logic of the previous function, you will see the similarity. The difference here being we use the CreateBlock method vs the Genesis method that we used previously.

Things are starting to come together! There are only two more functions, and one struct that we need to add to our blockchain.go file.

BlockChainIterator struct

So we have our BlockChain struct, that holds the lastHash, as well as a pointer to our database. I think it would be useful to be able to iterate through our BlockChain. In order to do this I would like this new struct to have the same database pointer, but to point to the current hash instead of the previous hash.

//blockchain.go
type BlockChainIterator struct {
    CurrentHash []byte
    Database    *badger.DB
}

Coolio, new struct accomplished!

Iterator()

So now that we have the new struct, we need to be able to turn our BlockChain into a BlockChainIterator. This is our utility function for doing so:

//blockchain.go
func (chain *BlockChain) Iterator() *BlockChainIterator {
    iterator := BlockChainIterator{chain.LastHash, chain.Database}

    return &iterator
}

Donezo! In-the-bag! Mission accomplished!

Alright that's enough celebrating, onto the next function.

Next()

While BadgerDB does offer a way to iterate through the database, I found building this out to be educational, and I hope you do as well. What we are calling here is the same View function that we used before, and then setting the CurrentHash of our BlockChainIterator to the PrevHash of the Block that we are looking at.

//blockchain.go
func (iterator *BlockChainIterator) Next() *Block {
    var block *Block

    err := iterator.Database.View(func(txn *badger.Txn) error {
        item, err := txn.Get(iterator.CurrentHash)
        Handle(err)

        err = item.Value(func(val []byte) error {
            block = Deserialize(val)
            return nil
        })
        Handle(err)
        return err
    })
    Handle(err)

    iterator.CurrentHash = block.PrevHash

    return block
}

This allows us to pick at all of the info of a block, and then call the Next() method to take a look at the next one in the chain.

That's everything in our blockchain.go file! congrats, we now have database functionality.

Main.go

Here is the contents of the changed main.go file:

package main

import (
    "flag"
    "fmt"
    "os"
    "runtime"
    "strconv"

    "github.com/nheingit/learnGo/blockchain"
)

type CommandLine struct {
    blockchain *blockchain.BlockChain
}

//printUsage will display what options are availble to the user
func (cli *CommandLine) printUsage() {
    fmt.Println("Usage: ")
    fmt.Println(" add -block <BLOCK_DATA> - add a block to the chain")
    fmt.Println(" print - prints the blocks in the chain")
}

//validateArgs ensures the cli was given valid input
func (cli *CommandLine) validateArgs() {
    if len(os.Args) < 2 {
        cli.printUsage()
        //go exit will exit the application by shutting down the goroutine
        // if you were to use os.exit you might corrupt the data
        runtime.Goexit()
    }
}

//addBlock allows users to add blocks to the chain via the cli
func (cli *CommandLine) addBlock(data string) {
    cli.blockchain.AddBlock(data)
    fmt.Println("Added Block!")
}

//printChain will display the entire contents of the blockchain
func (cli *CommandLine) printChain() {
    iterator := cli.blockchain.Iterator()

    for {
        block := iterator.Next()
        fmt.Printf("Previous hash: %x\n", block.PrevHash)
        fmt.Printf("data: %s\n", block.Data)
        fmt.Printf("hash: %x\n", block.Hash)
        pow := blockchain.NewProofOfWork(block)
        fmt.Printf("Pow: %s\n", strconv.FormatBool(pow.Validate()))
        fmt.Println()
        // This works because the Genesis block has no PrevHash to point to.
        if len(block.PrevHash) == 0 {
            break
        }
    }
}

//run will start up the command line
func (cli *CommandLine) run() {
    cli.validateArgs()

    addBlockCmd := flag.NewFlagSet("add", flag.ExitOnError)
    printChainCmd := flag.NewFlagSet("print", flag.ExitOnError)
    addBlockData := addBlockCmd.String("block", "", "Block data")

    switch os.Args[1] {
    case "add":
        err := addBlockCmd.Parse(os.Args[2:])
        blockchain.Handle(err)

    case "print":
        err := printChainCmd.Parse(os.Args[2:])
        blockchain.Handle(err)

    default:
        cli.printUsage()
        runtime.Goexit()
    }
    // Parsed() will return true if the object it was used on has been called
    if addBlockCmd.Parsed() {
        if *addBlockData == "" {
            addBlockCmd.Usage()
            runtime.Goexit()
        }
        cli.addBlock(*addBlockData)
    }
    if printChainCmd.Parsed() {
        cli.printChain()
    }
}

func main() {
    defer os.Exit(0)

    chain := blockchain.InitBlockChain()
    defer chain.Database.Close()

    cli := CommandLine{chain}

    cli.run()

}

I rewrote it to use a cli to add blocks to the chain. Unfortunately this post would go over 3000 words if I were to break all of this down. I will most likely write up a smaller blogpost later this week to explain how it works. What YOU need to know is how to use it!

Previously we would run go run main.go and watch it do its thing. Now you have two options:

go run main.go add -block "YOUR BLOCK DATA HERE"
go run main.go print

With these two commands you will be able to add blocks to your chain, and then you can print them out!

You can check out what the finished code should look like here!

As always I hope you learned something, and if you have any questions just leave a comment below, or find me on twitter!
@nheindev

Building a Blockchain in Go PT: II - Proof Of Work

Noah Hein — Sun, 21 Mar 2021 00:45:25 +0000

Alright everyone. Congratulations on making a simple blockchain! If you are coming to this post and haven't checked out part 1, I suggest you do that before reading further. Although I'm just a guy on the internet, so do what you want I suppose.

If you aren't interested in how the tech works, you can go down to the "Building the Algorithm" portion of the post.

Proof Of Work

From where we left off, we can simply add blocks to the chain willy-nilly. This is a bit of a problem if we want to sell others on the security aspect of the blockchain. Blockchains are secured by doing "work," which can be recreated to tell the other nodes that the new data you are trying to add is legit. This "work" is simply high levels of computational power.

To recreate a new chain, you would have to compute every single hash leading up to the block you were trying to create. As you can imagine, calculating all of the hashes would take a very long time. By the time you got to the block you were originally trying to create, the chain would have already left you behind. This is what makes the blockchain secure from attacks from bad actors.

The technology that allows this to happen is an algorithm called proof of work or PoW. The idea is that lots of work has to be done to create a new block on the chain. But there is another piece; we need to be able to verify that the work has actually been done. PoW in a nutshell says that performing the algorithm is hard "work", but proving that the "work" was done should be easy.

Analogies always help me, so in the name of learning we will use a moat. It is very hard to actually dig a moat, but very easy to see that someone did in fact dig it. Imagine you dig a moat and call it the "Moat of Neverland". In the blockchain world, someone would have to dig that exact moat down to the last inch of dirt before they could claim it as the new "Moat of Neverland". Not only is there a high barrier to entry, but they would have to do all that work before you made a single change to your moat.

This is how the blockchain stays secure. Anyone is welcome to grab a shovel and help you with the official moat, which is what bitcoin "miners" do. But to create a new one and pretend that it's your moat, is very, very difficult.

Okay enough of the idea behind proof of work and yadda yadda. Let's write a proof of work algorithm and add it to our program.

Building the Algorithm

First we need to refactor our program a bit.

Refactoring

Everything is in main.go currently, and I would like to add a bit of structure to our program. Go ahead and create a blockchain folder, and add block.go and proof.go to the folder. We will be moving most of the logic in main.go to the blockchain folder, and main.go will be responsible only for the printing out of the blockchain. This will also get you some experience with making your own go packages.

There is one thing to quickly note before hopping into the file. Normally in a PoW algorithm, the "work" that has to be put in is itself an entire algorithm. This allows the difficulty of the "work" put in to be dynamic, so that blocks are created at a consistent rate.

We will not be implementing this feature in our chain. At least not yet. For the time being we are just sticking a global variable at the top of our file, and we will reference that. You can start with this file, and add code below it for the remainder of this post.

// proof.go

package blockchain

import (
    "bytes"
    "crypto/sha256"
    "encoding/binary"
    "fmt"
    "log"
    "math"
    "math/big"
)
const Difficulty = 12

Alright, with the new files in place, we will open up Proof.go and begin work there. Having gone over what we want the PoW to accomplish, you may be left wondering how we actually make that happen with code. We are going to set a requirement: The first few bytes must contain 0's. With this in mind, the step-by-step looks something like this:

Grab the data from the block
Create a nonce
Create a hash of the data from the block + the nonce
Check the proceeding hash to see if it meets the requirements we listed above. (the first few bytes must be 0's).

Now that we know what we're trying to accomplish, things should be a bit more clear.

ProofOfWork struct

We will want a struct for PoW like we did with the blocks:

type ProofOfWork struct {
  Block *Block
  Target *big.Int
}

This struct will hold the contents of the block, as well as the Target.

Initializing the struct

I think it would be a good idea to have a way to create this struct we just made, and to be able to adjust the difficulty to show you how it affects how much "work" needs to be done.

func NewProofOfWork(b *Block) *ProofOfWork {
    target := big.NewInt(1)
    target.Lsh(target, uint(256-Difficulty))

    pow := &ProofOfWork{b, target}

    return pow
}

I think this explains itself pretty well besides the target.Lsh() function. We're shifting the first arg target, however many units left we set our 2nd arg. The closer we get to 256, the easier the computation will be. Increasing our difficulty will increase the runtime of our algorithm.

Since we have a way to hold our data now, we should probably make something worth holding. We'll start with a function to initialize our nonce, and put it into our Block.

That means our function will need to return a byte. I think we should make a utility function that will help us out with that. Don't worry if this doesn't completely make sense, essentially this is just a way to convert int --> []byte.

func ToHex(num int64) []byte {
    buff := new(bytes.Buffer)
    err := binary.Write(buff, binary.BigEndian, num)
    if err != nil {
        log.Panic(err)
    }
    return buff.Bytes()
}

Creating a nonce

With that out of the way, we can loop back to the initialization of our nonce.

func (pow *ProofOfWork) InitNonce(nonce int) []byte {
    data := bytes.Join(
        [][]byte{
            pow.Block.PrevHash,
            pow.Block.Data,
            ToHex(int64(nonce)),
            ToHex(int64(Difficulty)),
        },
        []byte{},
    )
    return data
}

Running the algorithm

This should allow us to have all of the information about our block, including the counter all in one spot so we can hash it, and then see if it meets our target requirements. If it doesn't, then we can increment our nonce, and try again. Let's see what that looks like.

func (pow *ProofOfWork) Run() (int, []byte) {
    var intHash big.Int
    var hash [32]byte

    nonce := 0
        // This is essentially an infinite loop due to how large
        // MaxInt64 is.
    for nonce < math.MaxInt64 {
        data := pow.InitNonce(nonce)
        hash = sha256.Sum256(data)

        fmt.Printf("\r%x", hash)
        intHash.SetBytes(hash[:])

        if intHash.Cmp(pow.Target) == -1 {
            break
        } else {
            nonce++
        }

    }
    fmt.Println()

    return nonce, hash[:]
}

This is taking the block, along with our nonce, and hashing it. After we have it hashed, we then compare it to the target. If we've got a valid hash then we stop, otherwise we increment our nonce and try it all over again. Hashing is quite CPU intensive, and running all of these hashes and checking them is what creates the "work" we've been referring to.

Validating the algorithm

With a way to actually create valid blocks, we now need a way to validate them in a way that isn't as work intensive. Since we return a tuple from our previous function, we have preserved the nonce that was used to create a successful hash. This means that we should be able to use the data from the block, along with the nonce from the tuple, and run that one hash. The hash we just made should equal the target we set from ProofOfWork.

To reiterate, our function needs to return a boolean, should be comparing the hash that the block generated, vs the hash that this function generates, and then giving us the true/false value resulting from that evaluation.

func (pow *ProofOfWork) Validate() bool {
    var intHash big.Int

    data := pow.InitNonce(pow.Block.Nonce)

    hash := sha256.Sum256(data)
    intHash.SetBytes(hash[:])

    return intHash.Cmp(pow.Target) == -1
}

Implementing the algorithm

Now we are done with proof.go, we will start working on the block.go file. You are a smart cookie, I'm sure, and might have speculated that this is where the logic for the individual blocks will go. You are correct. We will also go ahead and put our blockchain functionality in here for now, as it doesn't make sense for us to have an entire file just for the blockchain struct.

Modifying structs

We can start with moving the structs over. We will also want to add the Nonce to our Block struct.

// block.go

package blockchain

type BlockChain struct {
    Blocks []*Block
}

type Block struct {
    Hash     []byte
    Data     []byte
    PrevHash []byte
    Nonce    int
}

More Refactoring

After this we can remove the DeriveHash() function from main.go. Then we will copy over the CreateBlock, AddBlock, Genesis, and InitBlockChain functions over to block.go. At this point your block.go file should look like this:

package blockchain

type BlockChain struct {
    Blocks []*Block
}

type Block struct {
    Hash     []byte
    Data     []byte
    PrevHash []byte
    Nonce    int
}

func CreateBlock(data string, prevHash []byte) *Block {
    block := &Block{[]byte{}, []byte(data), prevHash}
        block.DeriveHash()
    return block
}

func (chain *BlockChain) AddBlock(data string) {
    prevBlock := chain.blocks[len(chain.blocks)-1]
    new := CreateBlock(data, prevBlock.Hash)
    chain.blocks = append(chain.blocks, new)
}

func Genesis() *Block {
    return CreateBlock("Genesis", []byte{})
}

func InitBlockChain() *BlockChain {
    return &BlockChain{[]*Block{Genesis()}}
}

We no longer have the DeriveHash function. This is a bit of a problem, as we aren't hashing the blocks at all! We need to implement this hot, new, sexy, PoW functionality we built out a few moments ago.

Adding PoW to our blocks

Now we need to do the hashing in our CreateBlock function like we were doing before with the DeriveHash.

func CreateBlock(data string, prevHash []byte) *Block {
    block := &Block{[]byte{}, []byte(data), prevHash, 0} 
    // Don't forget to add the 0 at the end for the nonce!
    pow := NewProofOfWork(block)
    nonce, hash := pow.Run()

    block.Hash = hash[:]
    block.Nonce = nonce

    return block
}

So walking through the above, we are:

Making an empty block
Making a NewProofOfWork
Running the algorithm on the pow
Storing the Hash of the new block
Storing the Nonce of the new block

Conclusion

That's it! We've added a Proof of Work algorithm to our blockchain. The only thing left is to add some printout statements in our main.go file to see what happens. Below is what your main.go file should look like after all of our refactoring.

// main.go

package main

import (
    "fmt"
    "strconv"

    "github.com/nheingit/learnGo/blockchain"
)

func main() {

    chain := blockchain.InitBlockChain()

    chain.AddBlock("first block after genesis")
    chain.AddBlock("second block after genesis")
    chain.AddBlock("third block after genesis")

    for _, block := range chain.Blocks {

        fmt.Printf("Previous hash: %x\n", block.PrevHash)
        fmt.Printf("data: %s\n", block.Data)
        fmt.Printf("hash: %x\n", block.Hash)

        pow := blockchain.NewProofOfWork(block)
        fmt.Printf("Pow: %s\n", strconv.FormatBool(pow.Validate()))
        fmt.Println()
    }

}

To see the fruit of your labor, run go run main.go in your command line. If you would like to see how the difficulty changes how much "work" needs to be done, try changing the difficulty from 12 to 18! Play around and have fun with it.

The end result of your code should look like this

I hope you learned a thing or two following along. I know I sure learned a few things teaching all of this. I'll see you next time! :)

Building a Blockchain in Go PT: I - The Hello World of Blockchains

Noah Hein — Tue, 09 Mar 2021 02:18:52 +0000

Hello everyone!

I recently have been trying to learn go, and with all of the recent hype around NFT and crypto, I thought instead of learning solidity I would go ahead and power through and continue learning go. However I still wanted the super trendy hip developer kudos for doing something with the blockchain. I looked up some tutorials and then after following them and having a bit of trouble, I thought to share with all of you.

There were two things I was learning throughout this process. They were go and blockchain. If I have learned anything in the time that I have been writing and trying to share knowledge, it is that we should stick to explaining one thing at a time. In light of this newfound wisdom, I will not be teaching you much of the go syntax, as I think it is the easier of the two to grok. Go does have some complex paradigms around channels and routines, but we won't be using that in this tutorial.

I will teach you one thing about golang. We will need to configure go to compile onto our local machine. I am in Windows, and so that is the perspective that you will find here. It honestly should not be different on macOS/Linux as I far as I am aware.

Go Configuration

You will want to install go over here

Normally if you look at a tutorial of Go and how to get it configured you will hear a lot about a GOPATH. This was a big pain and I only figured out afterwards that you do not in fact need to setup all of this. There is a go module system, which works similarly to npm or pip.

All we need to get started is to have go installed at this point.

Now we make a new project folder and sling some code.

mkdir learnBlockChain && cd learnBlockChain

Excellent. Now we can get the go module system going. you can name it whatever you would like, but I would recommend following my format but substituting your username.

go mod init github.com/nheingit/learnBlockChain

This should get you a new file in your project folder called go.mod

//go.mod
1 module github.com/nheingit/learnBlockChain

You will be able to use whatever 3rd party package, and then whenever you use the run command, it will pull in the relevant packages and import them into your project. If you do not have the package already downloaded, it will usually give you the relevant command in the error message. Very neat.

Now that we have our mod system configured, you should be able to follow along without doing any importing. You can simply call the method as if it were already part of your project, and it should take care of the rest.

However, if that is not the case, I will put this snippet here as a backup. We are only importing 3 things, so if you get stuck on this portion you can just copy this code and carry on.

Import

//main.go
1 package main
2 
3 import (
4   "bytes"
5   "crypto/sha256"
6   "fmt"
7 )
//rest of code here
//..
//..
//..

Let's Block Out!

Now that the configuration gods have been satiated we may now begin the actual ceremony. Just follow along, and remember that while I am giving you all of the code here, you will learn much more if you type out everything.

You need to build the muscle memory for the go syntax, and to actually think through what it is your code is doing. If you weren't interested in actually learning, you could just go to the git repo and copy paste the code, but you wouldn't gain too much from that.

In your terminal we can runtouch main.go

//go.main

1 package main
2 
3 func main() {
4 
5 }

Now that we have our main.go file ready, we need to reason about what a blockchain is at a lower level. Luckily for us, as with most compound words we can break up the words into their separate parts and divine some meaning from it.

Block

Let us start with the block. Our block from the blockchain will need to consist of three different fields. Since the main appeal of the blockchain is how secure it is, we are going to need some hashing. Hashing wouldn't be particularly useful unless there was some data inside that was worth protecting or preserving in some fashion, so we also need some data. The last element will be how our blocks chain together, so we will also want the previous hash from the block that was before us.

If we translate everything I just said into golang we should come up with something that looks like this

// main.go
type Block struct {
  Hash     []byte
  Data     []byte
  PrevHash []byte
}

Congratulations, you now have a Block®. Well a block by itself is not very useful now is it. Let's get a chain for this sucker and get it goin'!

Chain

The chain portion of a blockchain is just the collection of blocks all together. I think that sounds like a good use case for an array.

// main.go
type BlockChain struct{
  blocks []*Block
}

Excellent! Now you are the proud owner of ye olde block 'n' chain.

But there's a problem now of we can't really do anything with just this. It needs some functionality. I bet a function could help us out with that.

Functions

// All of these functions will be in main.go

I think a useful place to start would be to hash the data that we give the block. We will hash the current data in the block, as well as the block before us, to create a dependency chain. This hashing of the previous block is integral to the dependability of the blockchain. Without this string of connections, we would not be able to verify the integrity of the system programmatically.

func (b *Block) DeriveHash() {
  info := bytes.Join([][]byte{b.Data, b.PrevHash}, []byte{})
  // This will join our previous block's relevant info with the new blocks
  hash := sha256.Sum256(info)
  //This performs the actual hashing algorithm
  b.Hash = hash[:] 
  //If this ^ doesn't make sense, you can look up slice defaults
}

Now that we are able to hash our data how we would like, I think the next step would be to actually use this hashing capability. creating a new block sounds like a great place to flex our sick hashing skills.

func CreateBlock(data string, prevHash []byte) *Block {
    block := &Block{[]byte{}, []byte(data), prevHash}
        //If this is gibberish to you look up
        // pointer syntax in go
    block.DeriveHash()
    return block
}

Great job! We can now create all of the blocks.
However creating many many blocks will not do too many interesting things in this case. We need a blockchain to tie everything together.

func (chain *BlockChain) AddBlock(data string) {
    prevBlock := chain.blocks[len(chain.blocks)-1]
    new := CreateBlock(data, prevBlock.Hash)
    chain.blocks = append(chain.blocks, new)
}

With the ability to AddBlock to the chain, we can start wrapping up here. There is just one catch. We have no way to make the first block in the chain. This is because in all of our functions we are relying upon a PrevHash from the block before us. So we need to create the OG block for the chain.

func Genesis() *Block {
    return CreateBlock("Genesis", []byte{})
}

Last thing we need to do before we're Blockin' 'n' Chainin' to our hearts content is to initialize a new blockchain with the new Genesis block we made.

func InitBlockChain() *BlockChain {
    return &BlockChain{[]*Block{Genesis()}}
}

Now we have all the functionality we need to make a blockchain! that means we get to start writing in our main function. In the vein of "hello world" scope of tutorial for blockchains, I want to print out the fields of all of my Blocks in my BlockChain and call it a day.

func main() {

    chain := InitBlockChain()

    chain.AddBlock("first block after genesis")
    chain.AddBlock("second block after genesis")
    chain.AddBlock("third block after genesis")

    for _, block := range chain.blocks {
        fmt.Printf("Previous hash: %x\n", block.PrevHash)
        fmt.Printf("data: %s\n", block.Data)
        fmt.Printf("hash: %x\n", block.Hash)
    }

}

We now put this in the terminal go run main.go

That should yield you an output of something like this:

Previous hash: 
data: Genesis
hash: 81ddc8d248b2dccdd3fdd5e84f0cad62b08f2d10b57f9a831c13451e5c5c80a5
Previous hash: 
data: first block after genesis
hash: ce6cc03696fed9f5d0f45d0b26fd4f654df50201281be273248e2184e507586e
Previous hash: 
data: second block after genesis
hash: 7e964d1d2887bb2def988d7dfc85d935836d686ce7d101cbcb61716229d74386
Previous hash: 
data: third block after genesis
hash: f5fc87251c9c8d0be886c0d180b42beb9662de3224c2d87df4ee75427655dc45

You should note that you can see that first Genesis block doesn't have a Previous hash, which is why we needed that special functionality.

I hope you enjoyed reading and didn't find anything too easy, or too difficult! I'll close out here by showing a few resources that I used to make this application!

Shoutouts/Resources

the code you should end up with.

If you would like to watch the video where I learned how to do this whole blockchain thing, its right here. You will learn to code this exact project in video form from this excellent gentleman.

Here's the repo: https://github.com/tensor-programming/golang-blockchain

also another great learning resource if you're really trying to get into developing crypto and Ethereum with solidity is DappUniversity

Shoutouts/Resources

If you would like to watch the video where I learned how to do this whole blockchain thing, its right here. You will learn to code this exact project in video form from this excellent gentleman.

Here's the repo: https://github.com/tensor-programming/golang-blockchain

also another great learning resource if you're really trying to get into developing crypto and Ethereum with solidity is DappUniversity

Redwood's Revenge Walkthrough PT I, Storybook

Noah Hein — Fri, 05 Feb 2021 08:22:24 +0000

Redwood is a full-stack framework that combines many of our favorite JavaScript libraries into a fully integrated development experience that allows you to optimize for productivity and scalability.
It's catch phrase is:

Bringing full-stack to the jamstack

I want to take you along my journey learning RedwoodJS, starting with part II of the tutorial on the official website.

# Prerequisites

There is nothing too complicated about Redwood if you are already familiar with the underlying technologies and is even a good way to learn some of them, however where I will be starting this blog won't make much sense if you haven't read my friend Anthony's RedwoodJS Series.

# Beginning

Alright, so you have done some reading, gotten through the first portion of the redwood tutorial, and have yourself a nice blog site to call your very own. If you are following the PT II tutorial they say you can continue with your repo from the first portion of the tutorial; however you would be unable to follow along 1-for-1. I used the new repo, however you may find the additional work you do in keeping parity with the tutorial leads you to learn more than you otherwise would.

# Storybook

This piece of tech was completely new to me going into this tutorial; if I am being honest I was rather skeptical of how exactly it was going to be useful. After using it in just the brief time that I have, I can not imagine going back to doing something else. Simply put, if you are using reusable components in your UI that have props passed into them, storybook gives you a incredible developer workflow.

Pieces of tech like this aren't normally of great value to a newer developer such as myself, as learning to actually integrate it into my workflow takes even longer than my potential productivity gains. My projects tend to be smaller in scope, so I would have traditionally viewed this as more of an "enterprise" tool. However, Redwood gives this tooling and integration with your project for the low configuration cost of......Free! It Just Works ™. If you have picked up on ANYTHING in the Redwood philosophy, it should be that adding new technologies to your project does not need to be so painful.

With no prior experience to Storybook or any similar tech, I was able to quickly get productive with it. I understood what its' purpose was, how to use it, and how to navigate the docs to dig deeper if I needed to. It felt almost like a form of testing, but instead of testing code, it tested design. I could quickly slap code together to see how things looked. The real kicker for me was that all of it would be based off of data that had the same shape I would be using.

This portion of the data was a big selling point for me. All of the other stuff is non-trivial, and I don't want to discount how great all of it is. That being said, having redwood create a file for me that would allow me to mock the data without actually making a graphql call was mind blowing to me. I adjusted my SomeCell.mock.js, and then with no other code changes Story Book would display new data.

Story book seemed good, but the Redwood functionality sprinkled on top pushed it over the edge for me. When I am building an mvp, I like to do my UI portion first, and then build out my queries for my use-cases.
This usually involves a bit of breaking, fixing, and re-breaking my frontend as I fully integrate my api into my UI. Storybook with Redwood fixes all of that.

# Lessons Learned

Storybook is good. Storybook with RedwoodJS is AMAZING. If you have not given it a whirl before, the tutorial is a great place to get a feel for how it feels to build out a redwood application. In addition, if you don't have figurative streaks of grey in your programming beard, Redwood is an excellent way to learn some of the proper development workflows that not only keep you productive, but keep your code hygienic.

Really, try it out.

Seriously.

# Conclusion

I know I did not go over individual lines of code, but I really want to have this series be my impressions of the tutorial, as it is excellently written by Rob Cameron on the core Redwood team. I haven't found myself needing to go elsewhere to figure out why something isn't working. I would be foolish however to not tell you where to go should you come into a problem that you can't fix on your own!
The community around this project is truly like none other, and you could not ask for a friendlier bunch of folks. You can catch people over on the community forums. There is also a discord if you want to pop in and say hi, or if you have a quick question you need help with.

CSS Hyperlink Animation

Noah Hein — Mon, 01 Feb 2021 06:55:39 +0000

# Intro

Hey everybody!

I'm wanted to show everyone a pretty neat CSS trick that I picked up while writing out some code earlier today. I found myself wanting to write some animations for my portfolio project. For this particular animation I didn't need any JS logic and my CSS skills are not quite where I would like them to be. This led me to wanting a CSS animation, and from what I had read transforms and translates are the most performant animations that had the widest browser support. I'll give you a brief description of my particular use case, the idea of what I wanted to do, and then what the actual code was that got me there.

# The Use Case

Enough talking about this as some ephemeral entity. I had a navbar that I wanted to add hover animations to. A bit of pop that adds a hint of elbow-grease that you like to see in a website, and makes you feel like you aren't looking at someone's 2006 myspace page.

This is what it looks like currently:

I wanted my text to change to orange whenever you hovered over the link, and for it to "slide" over the text as you hovered.

Here's a sneak peak of what it'll look like when we're done

Enough with what it looks like, lets move on to the fun stuff!

#The HTML

So really all we're doing here is putting what I envision as a "ghost" span between the anchor tags. So it'll look something like this.

<a><span></span>About</a>

What we will do is when the anchor tags are hovered over, the "ghost" span will slide in over it with the new color.

We will need to add some HTML attributes to get it there however, so let me break that down really quick.

We're Going to want to add alt tags on our <a> tags for accessibility reasons. In same name of a11y we are also going to add
aria-hidden="true" to our span tags so that screen readers don't read the link value twice. The last thing we're going to add is also to our span, and that is the data-content attribute.

This attribute lets us add the "ghost" portion that I was talking about, as we don't need to actually assign the span tags a value, only the data-content. We are going to push the span tags together without putting a value between them.

After adding all of that you should end up with something like this:

<a alt='link to about page' href='/about'><span data-content='About' aria-hidden='true'></span>About</a>

This is our final HTML piece, the only thing left to do is some CSS to make the magic happen.

#The CSS

So first things first we are going to be putting an orange span smack-dab on top of our anchor tag, and that could be a problem for us. Let's take care of that.

span{
position: absolute;
overflow: hidden;
transform: translateX(-100%);
transition: transform 275ms ease;
}

So we want it absolutely positioned so we don't displace the rest of our wonderful page. Afterwards we want the overflow hidden because if we don't, we are going to see the entire word sliding form the left as if we were pushing out some play-doh, and that just was not the look I was going for. The next two lines are the fun ones as you can tinker with these a bit to git a different animation if you would like. My goal was to have the color slide in from the left. transform: translateX(-100%)
I also wanted it to be a pretty smooth and quick animation.
transition: transform 275ms ease;

Having understood and broken down that bit of CSS you will hopefully be familiar with the rest. I will link a code-pen with the rest of the code so you can play with it and maybe use it yourself!

I am quickly falling in love with animation, and actually finding out CSS doesn't have to be so awful has been a very freeing realization. I definitely learned a bit of CSS today, and I hope this post brought you something as well!

Getting Yourself Acquainted with TypeORM

Noah Hein — Thu, 28 Jan 2021 06:24:40 +0000

# Intro

Hi everyone, I wanted to share with you all my experience with TypeORM. In my most recent project, I used TypeORM to build a full stack application for a food delivery service similar to Blue Apron. You can check out the code for my project here and you can see the end product here. In this post we will go over TypeORM from a top-level overview, where it fits in your application architecture, and how you can use it with a SQL database to make working with your database a little bit easier

## What Is TypeORM?

If you take a a look at their website, TypeORM describes themselves as:

... an ORM that can run in NodeJS, Browser, Cordova, PhoneGap, Ionic, React Native, NativeScript, Expo, and Electron platforms and can be used with TypeScript and JavaScript.

While that is certainly descriptive, it doesn't do you much good if you don't know what an ORM is, so let's backup to that part.

From Wikipedia's ORM page:

Object-relational mapping (ORM, O/RM, and O/R mapping tool!) in computer science is a programming technique for converting data between incompatible type systems using object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language.

While I wanted to include that description because that is 100% what it is, If you aren't already familiar with the lingo in the database world, it's pretty much 100% gibberish.

How I think of an ORM in my head is the following:
An ORM is a tool that allows me to convert my SQL data tables into JavaScript objects that I can then manipulate and put back into my database. While not 100% correct, for my use-case this was pretty spot on.

## Cool, Where In my App Do I put it?

TypeORM interfaces between your server and your Database, much like how GraphQL sits between your client and your server.

Here's a graphic that uses a nest application as an example.

This allows TypeORM to do quite a lot of magic as far as the structure of your Data is concerned, as it gets to touch every request that you decide to send to the database, and structures it in a way that makes it easier for you to manipulate. However, all this juicy magic doesn't do you much good if you can't get it working.

## Configuration

After you install typeORM in whatever stack it is that you are using, you need to do a bit of configuration before you get all the goodies. I am going to assume that you already have a DB setup in whatever environment you are using. I used Postgres, so that is what I will use in this example, however TypeORM supports pretty much every SQL database, as well as some noSQL.

In your root directory you need to make a ormconfig.json file, and in it you are going to need to establish a connection to your database. your ormconfig.json should have the following:

{
   "type": "postgres",
   "host": "localhost",
   "port": 3306,
   "username": "test",
   "password": "test",
   "database": "test"
}

This will connect you to your DB, and allow you to start enjoying the TypeORM magic. This is the most basic connection, and there are many many more options to tailor TypeORM to exactly what your use-case is. You can find many of these options at node-postgres.

Once you have the correct credentials plugged in here you only have to do one more thing which is head over to your index.{ts/js} file and put in a few lines of code. After this step the configuration is done and you will be able to start building out whatever objects you would like.

Two lines of code here will get the job done.

import { createConnection } from "typeorm";


await createConnection();

If you want to see the exact structure of what my index.ts file looks like you can use the above link to look at my source code.

## Using TypeORM

For my application I did not have complex data needs. I only needed to record Users, and the columns that my Users had were not complicated at all. This should be a nice introduction as our data model isn't crazy and you can delve deeper into TypeORM on your own if you like what you see here.

If you are following along using my code you will want to take a look in entity/User.ts, where you fill find the following:


import {Entity, PrimaryGeneratedColumn, Column, BaseEntity} from "typeorm";

@Entity()
export class User extends BaseEntity {

    @PrimaryGeneratedColumn()
    id: number;

    @Column("text", {nullable: true})
    postalCode: string | null;

    @Column("text",{nullable: true})
    priceId: string;

    @Column("text", {nullable: true})
    stripeId: string;

    @Column("text", {nullable: true})
    ccLast4: string;

    @Column("text")
    email: string;

    @Column("text", {default: "free-trial"})
    type: string;

    @Column("text")
    password: string;
}

While this may seem like a lot, it really isn't. Let me break it down for you.
TypeORM defines everything using decorators.
Our very first line we're going to define an Entity by using the @Entity decorator. Entities are simply classes that map to SQL database tables.

@Entity()
export class User extends BaseEntity

I won't elaborate on the BaseEntity part, as it has to do with TypeORM supporting both Active Record and Data Mapper patterns, which is outside the scope of this post. However I opted to use Active Record, which is why we are extending the BaseEntity instead of just exporting the User class.

With the two lines above, I'm creating a new class User to work with in JavaScript. This class then maps to a table in Postgres. I am also exporting it so I can then use this User elsewhere in my code. I use GraphQL in this app, so I am able to import { User } from "entity/User" in my resolvers and then manipulate the data how I want, and put it back in my database.

TypeORM has some rules however. Every Entity must have a minimum of one primary column. There are several different primary columns but here I use:

@PrimaryGeneratedColumn()
id: number;

This is going to automatically generate a number value that gets auto-incremented as more Users are created.

From here we can understand the rest of this code. We are just adding regular columns to our User class. You can customize the columns quite a bit. I will quickly go over what I do in my next column and then you'll be off to the races!

@Column("text", {nullable:true})
postalCode: string | null;

in the @Column("text", {nullable:true}) we are defining a @column, the datatype which is going to be "text"
We are allowing it to be null with {nullable:true}.
In the next line postalCode: string | null; we are naming the column postalCode and then using TypeScript to give it types.

That covers pretty much everything that I learned when using TypeORM in this project. I hope you were able to follow along and learn a thing or two!

DEV Community: Noah Hein

Why People Hate Web3

Setting the Stage

Background

The Disconnect

Moving Forward

How to Stake Funds on SushiSwap using Arbitrum

Intro

Getting funds to arbitrum

Staking on Sushi

Running Your Own Ethereum Node with Geth

Introduction

Installation

Genesis Creation

Populating the Blockchain

Creating Accounts

Starting Up the Blockchain

Connecting to the Blockchain

Building a Blockchain in Go Pt V - Wallets

What is a Wallet?

What is a Key?

House Cleaning

Cli Cleanup

Transaction Cleanup

Wallet Building

Wallet.go

Utility Functions

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Wallet(s)

CLI Implementation

Building a Blockchain in Go PT: IV - Transactions

Building Transactions

The Transaction struct

Coinbase Transaction

Utility functions.

Implementing Transactions

Updating Methods

Data Hashing

Proof of Work Changes

Blockchain Changes

Adding Transactions

Finding Unspent Transactions

Finding Unspent Transaction Outputs

Finding Unspent Transaction Outputs That Are Spendable

Spending Coins!

Updating The CLI

Building a Blockchain in Go PT: III (extended) - CLI

Command Line

Building a Blockchain in Go PT: III - Persistence

Refactoring

tmp/blocks

block.go

Handle()

Serialize()

Deserialize()

blockchain.go

InitBlockChain()

AddBlock()

BlockChainIterator struct

Iterator()

Next()

Main.go

Building a Blockchain in Go PT: II - Proof Of Work

Proof Of Work

Building the Algorithm

Refactoring

ProofOfWork struct

Initializing the struct

Creating a nonce

Running the algorithm

Validating the algorithm

Implementing the algorithm

Modifying structs

More Refactoring

Adding PoW to our blocks

The `Transaction` struct