¶ What is a blockchain transaction?
To the Sovryn Dojo readers who have reached this far in their studies: Congratulations! If you are new to this series you can begin with Episode 1, Determinism. We have prepared this episode with easy explanations to get you up to speed with the subcategory of transactions on a blockchain. Enjoy reading and stay Sovryn.
We will begin with a recap of relevant content from previous chapters:
¶ A full node
A full node is a program that fully validates transactions and blocks. Almost all full nodes also help the network by accepting transactions and blocks from other full nodes, validating those transactions and blocks, and then relaying them to further full nodes.
Most full nodes also serve lightweight clients by allowing them to transmit their transactions to the network and by notifying them when a transaction affects their wallet. If not enough nodes perform this function, clients won’t be able to connect through the peer-to-peer network—they’ll have to use centralized services instead.
For information on how to set up a full Bitcoin node, see: https://www.youtube.com/watch?v=xc_TxlByxeY&t=2s
¶ Miners
Miners are not trusted to validate blocks, this is what full nodes are for. All miners do is proof of work. If they want their proof of work to be worth anything, they should validate the blocks they are building. But the proof of work is not itself a proof of validity. It is simply a hash that satisfies the difficulty target set by bitcoin's consensus protocol. However, the role in which miners are involved is the process of ensuring that the same amount of an asset is not being used twice and is actually still owned by the sender. This process is one of the two checks that need to happen before every Bitcoin transaction. The way Bitcoin miners do this check is that they will use their full nodes to download the blockchain and compute the state of the current sender balance.
¶ How are transactions handled in a decentralized manner?
Before we get into a transaction itself, we need to describe how transactions are handled on a blockchain. The aim is to keep data integrity untouched, while the data remains accessible to everyone.
¶ Data integrity
With centralized non-blockchain solutions, transactions are handled by servers and are then stored in a database. This database creates a possible single point of failure, which attackers can abuse in an attempt to change its records in their favor, using a single hacking attempt. On a blockchain, nothing like this is possible because of how blockchains are designed. Instead of one central database, all records that happened on the blockchain are redistributed through all nodes in a blockchain network, where each node has its own copy of the blockchain. If the attacker rewrote a simple copy from one node, the network would find this re-write invalid if it does not satisfy the consensus rules of the chain. This is how decentralization keeps the data secure.
¶ Data transparency
Centralized non-blockchain solutions store their data in an unencrypted way, hence the reason it needs to stay hidden and not reside in publicly accessible databases, stored somewhere on a server. Users in this database are recorded using their real names or other types of private data, such as email. Many databases storing this sensitive information can be protected through anonymisation and other security methods, but the underlying data is always processed at one central point.
Of course, centralized databases can also be encrypted, but they are not so by default. For example, all Dropbox data is encrypted at REST (backend). Centralized databases can even apply end-to-end encryption, like for example with CryptPad instances are centralized but the data is end-to-end encrypted so only the end-users with the private keys can read their data.
In a blockchain, users are known only by the hash of their wallet, which acts as a wallet address. Thus, even though you can track a particular blockchain address using a block explorer (which will be covered in the next section), the privacy of users is kept private. Similarly, even though the blockchain is designed for anybody to see, the true identities hidden behind these hashes stay anonymous. The hashes that represent them act as a unique pseudonym.
Even though blockchain users generally start off only identifiable by their address (a hash) their usage can easily result in their address and blockchain activity being tied to their identity. For example, if they post their address on social media and say "this is my address!" or if they shop at an online merchant, pay using their blockchain address, and use their legal name and address for the shipping information. From that moment on, a user can be tracked since the wallet was tied by an assumption to their personalities. But remember, the way of using several wallets for different purposes is still an option and protects your privacy.
Finally, thanks to the facts mentioned above, we can imagine the blockchain, which is a subset of decentralized ledger technology, as an open account ledger book in the sky. It is up there, in the blue vastness for everybody to see. That is absolute blockchain transparency. But then, of course, this quote does not take into account blockchains that are fully encrypted, such as Aztec.
¶ Purpose of blockchain transactions
Blockchains exist to provide a consistent and continuous view on transactions of digital assets, such as:
- financial (asset) movements
- supply chain management
- keeping records about purchases and ownership
- proving of the originality of goods
- or any interaction of a ledger of some sort
Blockchain does all this using two kinds of operations, “read” and “write”. Reading is a simple operation of interpreting data from a blockchain. The writing operations are much more challenging because of the verification process, which protects blockchain data integrity. This verification process is performed by full nodes which confirm the details needed for fulfilling the transaction by scanning a blockchain history. Now, what information are they scanning for?
They are scanning for information acquired from operations that denote ownership of the assets in question. These essential operations are:
- validating a transaction
- recording it on the blockchain
¶ Validating a transaction
Before a transaction can happen on a blockchain, the following checks need to be performed:
Being in possession of assets to be able to send them:
A user's full node will download the blockchain and compute what the user's current balance is based on the most up-to-date UTXO set. The term UTXO refers to the amount of digital currency someone has left remaining after executing a cryptocurrency transaction such as bitcoin. The letters stand for unspent transaction output. Each bitcoin transaction begins with coins used to balance the ledger. This way a user knows how much BTC they have and which UTXOs they can spend. They can then create spend transactions based on this information.
Ensure the assets are not being used twice and are actually owned by the sender::
Bitcoin miners will use their full nodes to download the blockchain and compute what the current UTXO set is. They will then check new transactions in the mempool against the UTXO set to make sure that:
the coins being spent are part of the UTXO set
the user attempting to spend the coins actually owns them (by checking the signature). Miners who perform this full validation will then only put new transactions that are valid into the blocks they build.
So, before starting a transaction, the state of the sender’s balance must declare that the assets checked in step 1 have not been sent somewhere else already. If the assets have been already used, it would mean a “double-spend” attempt. That's why these full nodes verify if the asset was sent away between obtaining it and now.
¶ Recording the transaction on the blockchain
A block is created ("recorded, timestamped, linked to the previous block in a chain, and lastly cryptographically sealed") and then sent to the network of full nodes for verification and inclusion in the chain (as long as it's part of the longest, most difficult valid chain). After a block is recorded on the blockchain, details of the transaction (asset, fee, height of the block, and ownership) are recorded, verified, and settled across all nodes. A verified change registered on anyone's ledger is also simultaneously noted on all copies of the ledger on the nodes. If two different nodes receive two different valid blocks at the same block height, they will record different changes until enough blocks are built on top of one block or the other to resolve the temporary fork. Since each transaction, or at least the one that was not being reorganized out of the chain, is transparently and permanently recorded across all ledgers, there is no need for centralized third-party verification.
¶ A simple definition
A transaction is, simply put, sending a message. This message can be used for:
- sending assets
- sharing or requesting information
- performing a confirmation
- order to change the state of anything digital
If a user sends a message to another user, the receiving user's inbox will obtain more data. When a banker sends a money transaction (message) to a client, the client's bank account balance is modified by receiving additional money. In both cases, transactions changed the state of data. Thus, in turn, a transaction on a blockchain is an operation that changes the state of data recorded on the blockchain.
Every single transaction conducted on a blockchain has this unique identifier called Tx. Tx stands for Transaction Hash and is also known as Transaction ID (TxID), represented by alphanumeric characters such as these two famous Bitcoin transactions that happened in 2010:
The first bitcoin transaction from Bitcoin's creator Satoshi Nakamoto to the computer scientist Hal Finney:
f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16
Transaction that fulfilled the most expensive pizza order for 10,000 BTC in 2010. In May of 2021, this amount of BTC was worth 367,991,000.00 USD: a1075db55d416d3ca199f55b6084e2115b9345e16c5cf302fc80e9d5fbf5d48d
¶ An example of a transaction and its validation
The internet is jam-packed with all those “Alice and Bob" examples, in which “Bob gives a banana or BTC to Alice since he is the king of the jungle.” Even though Bob sending things to Alice may be fairly representative of monetary transactions on the internet, let's change it up and use the names of the Sovryn documentation heroes instead. Let's get into it.
Scotti sends 2 million SOV over the RSK network to Uni, since he is Uni’s biggest fan. This token transferring transaction is generated by Scotti.
Scotti has two things to prove to the RSK blockchain and one problem he needs to solve by himself (apart from sending his beloved SOV somewhere else, which can be hard).
Scotti now has to prove that he owns these 2 million RSK tokens. So, somewhere in the RSK blockchain history - there has to be a block in which Scotti obtained these tokens. The other thing that Scotti has to prove is that it's him who is generating the transaction (not The Gimp or somebody else who is just pretending to be Scotti). For this purpose, Scotti takes advantage of a cryptographic primitive called "Digital Signature". He signs the transaction with his private key, which claims that he is the one and only owner of his wallet, and not The Gimp. Scotti then submits this transaction to the network; any node that receives this transaction and tries to validate it needs to provide the two checks discussed above:
Full nodes check that Scotti received 2m SOV at some point in the history of the RSK Network blockchain. This is done by a transversal move in the history of the blockchain until the point where Scotti became the owner of those 2 mills. When this is verified, the first check is over.
Now, full nodes try to confirm that Scotti actually possesses 2 million SOV as well that up till now Scotti has not tried to send these tokens to anybody else. Simply imagine a situation where Scotti has already paid out his tokens to MickeyMaler. In such a case, he is not the current owner of these tokens, even though he was at some point in the past. When several independent full nodes reach the mutual agreement of Scotii being the asset owner who has not sent them away yet, the second check is over.
When the transaction passes both these checks, also known as “verifications needed to send a transaction”, the next step is to record it on the blockchain and redistribute it on the network through all blockchain nodes. This finally marks the transaction as finished successfully.
¶ Consensus
In a centralized, non-blockchain system, sending assets would be a straightforward operation, where all trusted nodes perform only bureaucratic procedures. However, in a fully decentralized network like the RSK blockchain (Bitcoin native sidechain), this is a significantly more complex action. It is caused by a presence of a protective mechanism in which all the untrusted nodes have to reach an agreement among themselves over whether they are going to write this piece of data (meaning the transaction) to the blockchain or not. This is where the matter of consensus comes into the picture.
Consensus means multiple nodes (or servers, if you want) within a network reach an agreement about the current state of data stored on a blockchain. In the case of Bitcoin (Bitcoin blockchain) or Sovryn (RSK blockchain) tokens, this consensus occurs as a result of both Proof-of-Work and block verification by full nodes sharing block and transaction data in a peer-to-peer network. And the more transactions these blockchain hustlers put their stamps of approval on, the more significant rewards they get from the blockchain network, in the form of fees.
Congratulations. You made the sixth step in becoming a blockchain expert.
This series is mirrored on the Sovryn Blog here. It is also published on Hackernoon.
See you later in episode 7, where we will investigate what a Bitcoin block is and what data a block consists of. Be prepared for your guided blockchain explorer experience.
Until then, stay Sovryn!