WHAT EXACTLY IS A BLOCKCHAIN!?

To all those people who are scratching their head still wondering what exactly this blockchain thing is, it can be understood in terms of a globally shared transactional database which means that anyone can read entries in the database just by participating in the network.
If a person has to change something in the database, it has to create a transaction which has to be accepted universally by others.
A transaction is defined as any one execution of a user program in a DBMS and differs from an execution of a program outside the DBMS in important ways. Note that executing the same program several times will generate several transactions An example of a transaction would be a C program executing on UNIX.

Following are the properties of a transaction:-

• Atomicity
  Users should be able to regard the execution of each transaction as atomic: either all actions are carried out or none are. Users should not have to worry about the effect of incomplete transactions (say, when a system crash occurs).

• Consistency
  Each transaction run by itself with no concurrent execution of other transactions and must preserve the consistency of the database. This property is called consistency, and the DBMS assumes that it holds for each transaction. Ensuring this property of a transaction is the responsibility of the user.

• Isolation
  Users should be able to understand a transaction without considering the effect of other concurrently executing transactions, even if the DBMS interleaves the actions of several transactions for performance reasons. This property is sometimes referred to as isolation: Transactions are isolated, or protected, from the effects of concurrently scheduling other transactions.

• Durability
  Once the DBMS informs the user that a transaction has been successfully completed, its effects should persist even if the system crashes before all its changes are reflected on disk. This property is called durability.

These are often known as ACID properties of a transaction and are explained further below:-

• Consistency
  Users are responsible for ensuring transaction consistency. That is, the user who submits a transaction must ensure that when run to completion by itself against a ‘consistent’ database instance, the transaction will leave the database in a ‘consistent’ state. For example, the user may have the consistency criterion that fund transfers between bank accounts should not change the total amount of money in the accounts. To transfer money from one account to another, a transaction must debit one account, temporarily leaving the database inconsistent in a global sense, even though the new account balance may satisfy any integrity constraints with respect to the range of acceptable account balances. The user’s notion of a consistent database is preserved when the second account is credited with the transferred amount.

• Isolation

The isolation property is ensured by guaranteeing that even though actions of several transactions might be interleaved, the net effect is identical to executing all transactions one after the other in some serial order. For example, if two transactions T1 and T2 are executed concurrently, the net effect is guaranteed to be equivalent to executing all of T1 followed by executing T2 or executing T2 followed by executing T1.

• Atomicity and Durability
  Transactions can be incomplete for three kinds of reasons:-
  -A transaction can be aborted, or terminated unsuccessfully, by the DBMS because some anomaly arises during execution. If a transaction is aborted by the DBMS for some internal reason, it is automatically restarted and executed anew.
• The system may crash (e.g., because the power supply is interrupted) while one or more transactions are in progress.
• A transaction may encounter an unexpected situation (for example, read an unexpected data value or be unable to access some disk) and decide to abort (i.e., terminate itself).

Of course, since users think of transactions as being atomic, a transaction that is interrupted in the middle may leave the database in an inconsistent state. Thus a DBMS must find a way to remove the effects of partial transactions from the database, that is, it must ensure transaction atomicity: either all of a transaction’s actions are carried out, or none are. A DBMS ensures transaction atomicity by undoing the actions of incomplete transactions. This means that users can ignore incomplete transactions in thinking about how the database is modified by transactions over time. To be able to do this, the DBMS maintains a record, called the log, of all writes to the database. The log is also used to ensure durability: If the system crashes before the changes made by a completed transaction are written to disk, the log is used to remember and restore these changes when the system restarts.

One should also understand that a transaction is always cryptographically signed by the sender which makes it straightforward to guard access to specific modifications of the database