We use cookie to improve your experience on our site. By using our site you consent cookies.
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:
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.
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.
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.
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.
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.
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.
Blockchains exist to provide a consistent and continuous view on transactions of digital assets, such as:
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:
Before a transaction can happen on a blockchain, the following checks need to be performed:
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.
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 transaction is, simply put, sending a message. This message can be used for:
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 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:
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.
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.
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!