Blockchain Transactions

What’s going on under the hood?

About a month ago or so, I wrote a brief overview of blockchain. If you missed it and would appreciate a little insight into this encrypted world, go check it out and come on back. Anyways, Where I left off before was just about where someone would desire to make a transaction, so for part ii of this series, we’ll explore what a transaction is and how your funds are secure. A whopping $600+ million was stolen in a cyberattack on Poly Network this week if you've been keeping up with current events. Poly Network reasoned with the hackers to return their huge haul. At the time of publication, all but $33 million has been accounted for and is already in the process of being transferred back to Poly Network. But more importantly, back to the men and women who had coins stolen from them.

Bitcoin Transactions

We define a bitcoin as a chain of digital signatures. Each owner transfers bitcoin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership.

— Satoshi Nakamoto

This is from the Bitcoin Whitepaper, published in 2008, serving as the backdrop for the first blockchain to live beyond a theory. Given there are no actual coins, what exactly happens when you make a crypto transaction? In all reality, all you own when assuming “ownership” of bitcoin(s) is the right to a pair of keys. This key pairing unlocks the contents contained within.

Public Key

If you are familiar with encryption tactics, cryptocurrency transactions employ the same tactics, as to be expected, considering ‘crypto’ is in the name. A set of keys are used to encrypt, with the public key needing the corresponding private key to unlock the treasures inside. According to Bitcoin, public keys are regarded ‘as an address to which some amount of bitcoin was previously sent.’. Let’s think about how that works. Electronic coins have a misleading moniker; most people think of coins in relation to physical change. But, in the digital world, coins are a chain of digital signatures. When you transfer a coin to another person, you sign a hash containing the previous transaction, then digitally sign the public key of the next owner. These signatures are then added to the coin, giving the current owner a way to verify the transaction and ownership of the coin. This key is shared with everyone, and it takes the name ‘public key’ for a reason. They

Private Key

Private keys should never be shared with anyone!!! I’ll repeat it, NEVER SHARE YOUR PRIVATE KEY WITH ANYONE. This key is used to authorize the coin previously sent to the above public key. If someone has access to your private key, they can essentially steal everything you have of value encrypted within the chain. Private keys are the passwords that open the public key it corresponds with. No amount of safeguarding is too much concerning your private key.

Timestamp Server & Proof-of-work

With all things transactional, verification is the most critical, and since blockchain has a decentralized network with no home base, per se, there needs to be a way to verify each transaction. Bitcoin proposed a standalone timestamp server that is run by a peer-to-peer network. Each transaction is assigned a timestamp. Like the blockchain process, each timestamp contains the transaction's timestamp before forming a separate chain of timestamps running parallel to the blockchain.

Now for the fun part, proof-of-work. According to the Blockchain Whitepaper: ‘…proof-of-work involves scanning for a value that, when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash.”. Here’s how they describe the process of implementing the proof-of-work. On a transaction, “a nonce in the block” is incremented “until a value is found that gives the blocks’ hash the required zero bits.” Blocks that have been sent off with a satisfied proof-of-work cannot be changed without undoing the work, and with each incoming transaction, each block would then have to be changed and so and so on.

Chain of Events

A series of events is kicked off when a new transaction is made to initiate the incoming transaction. New transactions are broadcast to all nodes within the network. All the new transactions are then collected into a block within each node. After collection, the nodes then begin satisfying the proof-of-work for the transaction(s). Upon satisfaction being completed, this block is then broadcast back out to all the nodes in the network. The nodes then verify each transaction within the said block before being accepted. Upon acceptance of the new block, this block is then used to create the next block in the chain, using its hash as the hash to be checked against in the timestamp server. The cycle continues over and over, with each incoming block strengthening the chain against cyber attackers.

Ethereum

Ethereum employs a similar tactic and was kind enough to give us some examples of what a crypto transaction would look like. Submitted transactions are grouped into an object. This object will have the keys: recipient, signature, value, data, gasLimit, maxPriorityFeePerGas, and maxFeePerGas. Gas is something I was not very familiar with. But it made sense once I looked into it. Gas is the fee required by a miner to process the transaction. There will be a code snippet provided to provide context to the Gas fee.

The initial transaction object will look similar to this:

As you can see, there is a to and from, which is compromised of the public keys of both parties involved in the transaction. The gasLimit is 21000, maxFeePerGas is 300, maxPriorityFeePerGas is 10, nonce is 0, and value is 1,000,000,000 ETH. The value key will always be the amount of ETH the sender is transferring to the recipient. But there is something to make this transaction complete; we need the private key of the sender to sign the transaction. That call would look something similar to this:

And the corresponding response would look akin to this:

Notice the result object contains the raw and tx keys. The raw value is the transaction after being signed in RLP(Recursive Length Prefix) encoded form. And the tx value is the JSON version of the signed transaction.

GAS

Last but not least, there is the transaction fee for the work of making your transaction a success. Ethereum charges 21000 units of Gas per transaction. 21000 units of gas comes out to 0.0042ETH. The miner keeps the portion of the fee that was not burnt up in the process. For example:

Say I want to send you 1ETH at a baseFeePerGas of 190 gwei. Gwei is equal to 0.000000001 ether. The maxPriorotyFeePerGas of this transaction happens to be 10. This all turns out to a fee of 4,200,000 units of gwei, or roughly 0.0042 ETH. The miner will keep roughly 0.000197 ETH, with the rest of the fee being burnt up in the process.