Money in general is a social construct which provides a medium of exchange. Crypto-currencies are also transferrable right? You can transfer a certain amount of Bitcoin etc to any other address. When you transfer fiat money, you will hand-over hard cash or transfer it to someone’s else account digitally or maybe you will exchange it for certain goods. However, all of these transactions can be validated right? If you want to pay the cash then cash itself is the proof of receipt. When you send digitally then the receipt is provided by your bank or the third party provider via whom you send the money digitally.

In cryptocurrencies, this is done by storing the transactions on a public Blockchain. A blockchain, as the name suggests, is made of multiple blocks containing data somehow linked to each other forming a chain. In cryptocurrency blockchains, each block can contain multiple transactions. By using cryptographic techniques (calculating hash of the block and adding it to the next block thereby generating Merkle tree or by making DAG etc), all of the blocks of transactions are linked to form a chain. These transactions are publicly visible to anyone and anyone can validate them no matter who they are.

But there are different ways of storing and creating transactions and thereby creating different types of Blockchains that process and manipulate the transaction in their own way. Put simply, how does a public blockchain remembers what is the current balance of a public address say XYZ. Suppose the newly inserted block in the Bitcoin blockchain has a transaction where the XYZ has received some number of BTC. Then how will XYZ redeem it? How will the balance of the XYZ be updated? Bitcoin blockchain uses something known as Unspent transaction Output. But there are basically three ways

• UTXOs (Unspent Transaction outputs)
• Account model (popularly used by Ethereum)
• EUTXOs (Extended Unspent Transaction output) is used by Cardano and possesses the properties of both UTXO and Account model.

Before going into the nitty gritty details of each of those models, we need to familiar with some of the basic concepts:

Public and Private Keys:
Keys are basically your identities on the Blockchain! Essentially, using some cryptographic technique (Elliptic curve usually), a key-pair is generated. One is called your Public key and the other one is your Private Key. The public key is visible to everyone. The public key is the one you share with your friends or someone else if you want to receive the funds in your account.

Your private key should be known only to you. The private key is then used for spending the funds that were transferred to your corresponding public key address.  So, if you lose your private key, then your funds are essentially gone. Usually, you are provided with a mnemonic phrase which can contain multiple words (like Apple tree orange with etc etc) defined in BIP-39 specification. Your secret phrase can generate your private key(s). Store the mnemonic phrase securely!

The public key and private key are generated in such a way that the data encrypted with the public key can only be decrypted with the corresponding private key and vice-versa. So, if I encrypt (say hello) with your public key then it will generate a random string (depending on the algorithm used). That random string can then be converted back to “hello” by using the corresponding private key only.

Hash:
Hash functions provide a way of generating a randomly looking string of character for some data that is fed to it. For a particular input, the hash will always be same. SHA-512 is a great hash-generating algorithm. It generates 512 bits long ouput for any input that is given to it. Here's a website where you can calculate the hash using various different algorithms.

If you calculate the SHA-512 hash of "Apple" (without quotes) you will get something like "393374c...e7680ba9e2". No matter how many times (or different sites you use) the calculated SHA-512 hash will be same for "Apple". And if you change the word from "Apple" to "apple" i.e., the capital "A" is replaced by "a", the whole hash will change! Looks completeley random but it isn't.

Digital Signature:
These are analogous to our signature in the physical world. A digital signature provides non-repudiation as well as integrity. Essentially, they provide a proof that the data has not been changed by some adversary and a way to make sure that the sender of the data is really who they claim to be.

So, if I send you a message which says something like, “ I am Prince of Nigeria. Send me some Bitcoin and I will send double the amount within 2 days”, then my digital signature is something that can prove to you (and everyone who has access to my public key) that I am really who I claim to be and the data (which is the message) has not been altered.

Here’s the good part. I can digitally sign a transaction that says "I have sent 1 BTC to your public address from my account". Since the transaction is digitally signed by my Private key (which is known only to me), the whole network can be sure that I sent the transaction. The signature will contain the hash of the transaction. Someone on the network will verify the transaction. They will calculate the hash of transaction they receive on the network. If that hash matches with the hash that was encrypted as digital signature then it is also proved that the transaction has not been altered by anyone. You can think of signing the transaction as "Encrypting the hash of transaction with my private key". Will do a separate article relating how digital signature and hash function actually works. Here's a pictorial explaination:

So, in total:

• Data encryped (transformed) using your public key can only be decrypted (converted back to original form) using your private key and vice-versa.
• Your private key is used to encrypt the hash of your transaction to create a digital signature which is sent along with the transaction.
• Anyone using your public key can decrypt the digital signature to get the hash of the transaction. Since you own the private key, only you must have created the signature. Therefore, your identity is verified.
• Using the same hash function, hash of the received transaction is generated by the validator. If this generated hash matches with the hash that was obtained by decrypting your digital signature, then it is guranteed that the transaction has not been modified by some adversary.

Also, since I sent the Bitcoin to your public key, only YOU can redeem it using your private key. The whole community on the blockchain will know that I have sent a Bitcoin to you since the transaction is publicly available. Your public key is your account on the blockchain and your private key is the secret using which you can send the fund to someone else.

Now, with these basic concept out of our way (and hopefully in your mind!), we can move on to the various models. The first model we will be talking about is the Account model. The model is fairly easy to understand and is almost works the way we usually think of how the ledger works. The other models require some change in our defacto views. They will be covered in the upcoming articles seperately.

Account Model:

It requires global perspective of the Blockchain. In the account model, a ledger is maintained which is synced across all the nodes. This ledger stores the balance of all the private-key controlled account. The nodes are responsible for maintaining the blockchain. Imagine the blockchain as a book and the pages of the book are the blocks containing transaction. Nodes are responsibles for writing pages (adding blocks) in the book (blockchain) and making sure there is no error. As previously stated, Ethereum uses this model. Every account in Ethereum ledger has balance, storage space and code-space from where different accounts/address can be called. So, how does transaction works in the Account Model?

It works similar to how the transaction works in our Centralized banks. You have an account in a bank with say $500. If you send $50 to me, then your account balance will be deducted by $50 and mine will increment by the same. In the Blockchain, the ledger will be updated similarly and all the nodes will change the balance so that they can remain in sync.

• I create a transaction with your public address as the receiver and the amount that I want to transfer to you.
• I sign the transaction using my private key and send the transaction out on the network.
• My public key will be used check whether the signature is valid and then the transaction can be validated i.e., Check whether I have the required amount in my account.
• If the transaction is valid, then it is added to a block which will then be added on blockchain. Once the block is confirmed the accounts in the ledger are updated accordingly.

There is an issue of replay attack here. Suppose, you sent 1 Ethereum, in 2016, to my public address. What if I take this old transaction and then again send the same transaction onto the network?

• If your account has 1 Ethereum or more in your ledger balance, then the amount is valid.
• The transaction is signed using your private key. No issue there too.

What’s preventing me from sending the same transaction as many times as I want till your account is completely Empty. Maybe you will have 0.9 Ethereum left in your account. In that case, I cannot do anything. Why? Because if I change the amount in the transaction to 0.9 ETH then I will have to generate the hash and encrypt it using your Private key. I donot have your private key. And if I encrypt it using some random key then during the verification of the transaction, the digital signature will not match. So, the transaction will fail. However, if you have 100.09 ETH, then I can send the 1 Ethereum transaction 100 times which will leave you with 0.09 ETH and I will really be the Prince of Nigeria!

The solution to this is something called NONCE. NONCE stands for Number Used ONCE. Every account will have a unique publicly viewable NONCE. Whenever there is outgoing transaction from the account, that number has to be incremented by 1. Suppose your NONCE is 1967. So, before you digitally sign my transaction, you add a field in the transaction “nonce: 1968”.

Now, I cannot do a replay attack, because if I want to use the transaction again then I will have to update the Nonce to 1969. But this will change the hash and then the signature of the transaction. This means the transaction verification will fail.

This will also prevent double spending. In double spending, Suppose I have 1 ETH. I will send two transactions simultaneously. One transaction will send 1 ETH to you and the other transaction will 1 ETH to my other account. However, since NONCE needs to be updated both times, one of these transactions is guaranteed to fail. If my original nonce was 1968, then one transaction will have a nonce of 1969 and other will have 1970 as nonce. In this case, the transaction with nonce 1970 will fail because I will have no avialable balance.

If I keep the same nonce for both transactions i.e. 1969, even then one of these transactions will fail. Suppose both of the transaction (with same nonce value of 1969) enters into different blocks. Now, one of the blocks get confirmed. The other transaction will simply fail because the already updated nonce is 1969 and so the next transaction should have a nonce of 1970 and not 1969.

So the advantage of Accounting model is that it is Simple to understand and intuitive to work on. Creating Smart contracts is also easy. There is also inherent coin mixer built within the model itself. When you get coins from various addresses, it is not possible to track which ones you are spending since they are inherently combined into a single balance in your account. This one will be more clear when you will understand the UTXO model.

As you will see there are disadvantages associated with this as well as the other models too. In account model, parallelization is very harder to acheive. Imagine updating the balance (maybe by trying to make 5 withdrawals simultaneoulsly) in your account parallely. As you saw in double spending, each request will require a new NONCE for Ethereum. So, parallelization is kinda hard to acheive if you are working on the same balance (Can work on different smart contracts parallely). 

Also, the global public ledger needs to be updated every few seconds (or even faster) depending on how fast new blocks are being added. The updated ledger also needs to be kept in sync on every validating node. For this reason, usually when a new block is added, it is not marked as confirmed. Only after some more blocks have been added on top of it, then it is marked as confirmed. In Ethereum, usually 12 block confirmations or more is advised. This means that when 12 or more blocks have been added on top of the block containing your transaction, you can be completely sure that your transaction is confirmed. 

Note: Transaction on Ethereum are not free and neither are they free on many other Blockchain. You will have to pay a fees for your transaction to be confirmed. You can think of this as the fees required for the computation power required to process your transaction. Nano (XNO) is one of the blockchain with no fees at all. More about Nano here.

Up next will be the UTXO model. Till then, peace!