Blockchain
Decentralization
Consensus
Everyone coming to an agreement
1980 Two general problem
Imagine you live in the Land of Computing and you’re a general of the army. Your title is General A. You and your soldiers are strategically positioned in a valley to the west of the enemy’s fortified stronghold. General B is in the valley to the east. The only way you can defeat the enemy is if your soldiers and General B’s soldiers make a coordinated attack from opposite sides of the valley. But in the Land of Computing, there is only one way to communicate with General B to set a time for the attack. You have to send messengers on a high-risk path through enemy lines.
Now we have a problem, General. There’s no way of knowing whether your messengers have completed their mission safely. If General B sends a confirmation message back to you, your runners must return through enemy territory. They might not make it, but General B won’t know that. He’ll go ahead with the attack at the agreed time and be defeated.
What’s a General to do? It doesn’t matter how many messengers you send back and forth; the problem remains the same. It’s unsolvable. In the Land of Computing, there’s no radio communication, carrier pigeon, binoculars, or semaphore to help you with this operation.
If the channel for message transfer is unreliable, it is unsolvable.
In the above case, consider this. The messenger could potentially get caught in the city and replaced by a fake news messenger, who will intentionally try to deceive the other general to attack the city at the wrong time, dooming our army to a loss.
There is no way to check if the message is authentic, so how do we, as the finest military strategists in the land, create a “trustless” system that ensures victory in attacking the city?
Another problem: The two general problems with more than two generals
We will now consider reliable channels and problems in them.
Byzantine General Problem
Consider if one of the generals is malicious and acts differently as expected.
And that’s the Byzantine Generals Problem.
If the channel for message transfer is reliable, it can be solved.
If the nodes are faulty i.e they don't behave as they are expected. Faulty nodes failure can be classified into crash failure and byzantine failure.
Crash failure: Refers to some node crashes and it is not disturbing others but is not responding
Byzantine failure: Refers to nodes performing maliciously like they may send conflicting values to others.
Type of channel of message transfer -
Synchronous: We know the upper time limit in which the message will be delivered is known. i.e if acknowledgment is not received, we can send the message again.
Asynchronous: We don't know the upper time limit or upper limit is too high. It's Unsolvable
Partial synchronous
A reliable and asynchronous channel is also unsolvable. (even for simple crash failure)
FLP Impossibility result - The FLP impossibility result for asynchronous deterministic consensus. In a fully asynchronous message-passing distributed system, in which at least one process may have a crash failure, it has been proven in the famous FLP impossibility result that a deterministic algorithm for achieving consensus is impossible.
No of users -
Any number of users
Finite
Algorithm
Deterministic
Probabilistic
Byzantine General Problem (proposed by Leslie Lamport)
When a complex system consists of multiple computer systems, the BFT algorithm solves the problem of guaranteeing the accuracy and uniformity of the whole system when some of the computer systems are at fault. For example, when some Byzantine generals are attacking a city, in case some generals are traitors, how the remaining loyal generals obey the orders from their commander in sync. This is also the origin of the BFT algorithm.
The thesis first stated the problem faced by the Byzantine generals: 1 commander gives an order to n-1 generals, guaranteeing:
IC1) All loyal lieutenants obey the same order
IC2) If the commanding general is loyal, then every loyal lieutenant obeys the order he sends.
To complicate matters, the generals are so far apart from each other that messengers are required in order for the generals to communicate. Also, one or more lieutenants may be a traitor, intending to sabotage the situation.
So, given these conditions and the commander-lieutenant set-up, can the army execute a strategy?
The solution to the problem relies on an algorithm that can guarantee that:
All loyal lieutenant generals decide upon the same plan of action, and
A small number of traitors cannot cause the loyal lieutenants to adopt a bad plan.
The loyal lieutenants will all do what the algorithm says they should, but the traitors may do anything they wish. The algorithm must guarantee the first condition regardless of what the traitors do. The loyal lieutenants should not only reach an agreement but should agree upon a reasonable plan.
Oral message solution
Consider the following scenario
n = 4 (3 Lietunant + 1 General)
f = 1 (One faulty node - Byzantine failure)
According to the Leslie algorithm, for a solution, we should have the number of nodes greater than 3 times the number of faulty nodes i.e
n>3f
In the case of deciding majority for a decision, if there is a tie the default value is chosen that is defined initially before running the algorithm. Ex - retreat is chosen as the default value.
Consider the case -
n = 3 and f = 1
In the above case, L1 receives {a,r} in both the cases so he can't determine whether commander or lieutenant is corrupt.
Complexity
Complexity is measured in terms of the number of messages sent.
Consider n nodes are present and f faulty nodes
Messages sent at level 1 = n-1 (To other remaining nodes -> sent by the commander)
Messages sent at level 2 = n-2 (Remaining nodes except commander and itself) x n-1 (Number of nodes)
Messages sent at level 3 = (n-1)x(n-2)x(n-3)
...
and so on.
T(n) = (n-1) + (n-1)x(n-2) + (n-1)x(n-2)x(n-3) + ...........
When f = 1, upto f+1 level i.e T(n) = (n-1) + (n-1)x(n-2) = O(n²)
Generalized expression -
T(n) = O(nᶠ⁺¹) = O(nᶠ) (approx.)
\=> Exponential
Signed message solution: Using Digital signature
Byzantine agreement problem
The problem we studied till now was the Byzantine broadcast problem in which there was one commander and the rest generals.
Here, in the Byzantine agreement problem, there is no commander i.e no one will be dictating the other.
All loyal lieutenants follow the same order
If every loyal lieutenant has initially value v, all should agree on v.
Consider there are 4 Lieutenants. Make each one a commander one by one and run the Byzantine broadcast problem and now every Lieutenant gets 4 values from which the majority can be chosen and act accordingly. For this case too, we need n>3f
State machine replication (SMR)
State Machine Replication is a fundamental approach in distributed computing for building fault-tolerant systems.
State machine: A state machine, at any point, stores a state of the system. It receives a set of inputs (also referred to as commands). The state machine applies these inputs in a sequential order using a transition function to generate an output and an updated state. A succinct description of the state machine is as follows:
state = init
log = []
while true:
on receiving cmd from a client:
log.append(cmd)
state, output = apply(cmd, state)
send output to the client
Here, the state machine is initialized to an initial state init. When it receives an input cmd from a client, it first adds the input to a log. It then executes the cmd by applying the transition function apply to the state. As a result, it obtains an updated state and a result output. The result is then sent back to the client.
Fault-Tolerant State machine replication (FT-SMR): In a client-server setting, the servers simulate a state machine in a fault-tolerant manner. Clients send commands as if there is a single state machine. Maintaining a single server is prone to crashes or Byzantine faults. Thus, instead of maintaining a single server, an SMR system uses multiple server replicas, some of which can be faulty. The group of servers presents the same interface as that of a single server to the client.
All loyal servers should be in the same state.
The server replicas all initially start with the same state. However, when they receive concurrent requests from a client, honest replicas first need to agree on the sequence of client commands received by them. This problem is called log replication, and it is a multi-shot version of consensus. After the sequence is agreed upon, the replicas apply the commands in the log, one by one, using the apply transition. Assuming the transition is deterministic, all honest server replicas maintain an identical state at all times.
Thus, a Fault Tolerant SMR system needs to perform log replication efficiently and then execute the commands on the log. Specifically, it needs to guarantee the following:
(Safety) Any two honest replicas store the same sequence of commands in their logs.
(Liveness/Termination) Honest server replicas will eventually execute a command proposed by a client.
***Note - ***
In asynchronous channel, the consensus is not possible because time is not known when it will be delivered but consensus will happen eventually
Asynchronous - No termination - No algorithm
Partial synchronization
Agreement/Safety
Termination/Liveness
PAXOS Consensus algorithm
No Byzantine failure
The consensus problem can be stated in a basic, generic manner: One or more systems may propose some value. How do we get a collection of computers to agree on exactly one of those proposed values?
Paxos is an algorithm that is used to achieve consensus among a distributed set of computers that communicate via an asynchronous network. One or more clients propose a value to Paxos and we have a consensus when a majority of systems running Paxos agree on one of the proposed values.
The Paxos algorithm was developed by Leslie Lamport. Paxos works in three phases to make sure multiple nodes agree on the same value in spite of partial network or node failures. The first two phases act to build consensus around a value, the last phase then communicates that consensus to the remaining replicas.
Prepare phase: establish the latest Generation Clock and gather any already accepted values.
Accept phase: propose a value for this generation for replicas to accept.
Commit Phase: let all the replicas know that a value has been chosen.
In the first phase (called prepare phase), the node proposing a value (called a proposer) contacts all the nodes in the cluster (called acceptors) and asks them if they will promise to consider its value. Once a quorum of acceptors returns such a promise, the proposer moves onto the second phase. In the second phase (called the accept phase) the proposer sends out a proposed value, if a quorum of nodes accepts this value then the value is chosen. In the final phase (called the commit phase), the proposer can then commit the chosen value to all the nodes in the cluster.
Phase 1 -
(a) Proposer (PREPARE)
A proposer initiates a PREPARE message, picking a unique, ever-incrementing value. i.e
A proposer selects a proposal number n and sends a prepare request with number n to a majority of acceptors.
ID = cnt++;
send PREPARE(ID)
(b) Acceptor (PROMISE)
An acceptor receives a PREPARE(ID) message.
If an acceptor receives a prepare request with a number n greater than that of any prepare request to which it has already responded, then it responds to the request with a promise not to accept any more proposals numbered less than n and with the highest-numbered proposal (if any) that it has accepted.
if (ID <= max_id)
do not respond (or respond with a "fail" message)
else
max_id = ID // save highest ID we've seen so far
if (proposal_accepted == true) // was a proposal already accepted?
respond: PROMISE(ID, accepted_ID, accepted_VALUE)
else
respond: PROMISE(ID)
**Phase 2 - **
(a) Proposer (PROPOSE)
The proposer now checks to see if it can use its proposal or if it has to use the highest-numbered one it received from among all responses.
If the proposer receives a response to its prepared requests (numbered n) from a majority of acceptors, then it sends an accept request to each of those acceptors for a proposal numbered n with a value v, where v is the value of the highest-numbered proposal among the responses or is any value if the responses reported no proposals.
did I receive PROMISE responses from a majority of acceptors?
if yes
do any responses contain accepted values (from other proposals)?
if yes
val = accepted_VALUE // value from PROMISE message with the highest accepted ID
if no
val = VALUE // we can use our proposed value
send PROPOSE(ID, val) to at least a majority of acceptors
(b) Acceptor (ACCEPT)
If an acceptor receives an accept request for a proposal numbered n, it accepts the proposal unless it has already responded to a prepare request having a number greater than n. i.e
Each acceptor receives a PROPOSE(ID, VALUE) message from a proposer. If the ID is the highest number it has processed then accept the proposal and propagate the value to the proposer and to all the learners.
if (ID == max_id) // is the ID the largest I have seen so far?
proposal_accepted = true // note that we accepted a proposal
accepted_ID = ID // save the accepted proposal number
accepted_VALUE = VALUE // save the accepted proposal data
respond: ACCEPTED(ID, VALUE) to the proposer and all learners
else
do not respond (or respond with a "fail" message)
If a majority of acceptors accept ID, value then consensus is reached. Consensus is on the value, not necessarily the ID.
Failure examples
Acceptor fails in phase 1
Suppose an acceptor fails during phase 1. That means it will not return a PROMISE message. As long as the proposer still gets responses from a majority of acceptors, the protocol can continue to make progress.
Acceptor fails in phase 2
Suppose an acceptor fails during phase 2. That means it will not be able to send back an ACCEPTED message. This is also not a problem as long as enough of the acceptors are still alive and will respond so that the proposer or learner receives responses from a majority of acceptors.
The proposer fails in the Prepare phase
If the proposer fails before it sent any messages, then it is the same as if it did not run at all.
What if the proposer fails after sending one or more PREPARE msgs? An acceptor would have sent PROMISE responses back but no ACCEPT messages would follow, so there would be no consensus. Some other node will eventually run its version of Paxos and run as a proposer, picking its own ID. If the higher ID number works, then the algorithm runs. Otherwise, the proposer would have its request rejected and have to pick a higher ID number.
What if the proposer fails during the ACCEPT phase? At least one ACCEPT message was sent. Another node proposes a new message with PREPARE(higher-ID). The acceptor responds by telling that proposer that an earlier proposal was already accepted:
PROMISE(higher-ID, <old_ID, Value>)
If a proposer gets any PROMISE responses with a value then it must choose the response with the highest accepted ID and change its own value. It sends out:
ACCEPT(higher-ID, Value)
If the proposer fails in the ACCEPT phase, any proposer that takes over finishes the job of propagating the old value that was accepted.
Suppose a majority of acceptors receive PREPARE messages for some ID followed by PROPOSE messages. That means a majority of acceptors accepted for that ID. No PREPARE messages with lower IDs can now be accepted by a majority. To do so would require a majority of promises for the lower numbered ID but we already made promises for the higher numbered ID. No PROPOSE messages with higher IDs and different values will be accepted by a majority either. At least one acceptor will know the ID and corresponding value that it accepted, which it will propagate back to the proposer. You can have proposals with higher IDs, but the proposer is obligated to give them the same value. If a proposer sends:
PREPARE(high-ID)
At least one acceptor will respond back with the previously accepted ID and value:
PROMISE(high-ID, accepted-ID, value)
The proposer will have to return back a PROPOSE(high-ID, value). This is how proposers & learners can learn about what was accepted and ultimately create a majority outcome.
Proposer fails in the ACCEPT phase
Here, a proposer that takes over does not know it is taking over a pending consensus. It simply proposes a value but does not realize that the consensus protocol was already in progress. There are two cases to consider here:
The proposer does not get any responses from a majority of acceptors that contain an old proposal ID and corresponding value. That means there has been no majority agreement yet. The proposer then just executes normally and finishes its protocol.
The proposer that takes over knows it is taking over a pending consensus because it gets at least one response that contains an accepted proposal # and value. It just executes using that previous value and finishes the protocol.
PBFT
Byzantine failure
The pBFT model primarily focuses on providing a practical Byzantine state machine replication that tolerates Byzantine faults (malicious nodes) through an assumption that there are independent node failures and manipulated messages propagated by specific, independent nodes.
The algorithm is designed to work in asynchronous systems and is optimized to be high-performance with an impressive overhead runtime and only a slight increase in latency.
Essentially, all of the nodes in the pBFT model are ordered in a sequence with one node being the primary node (leader) and the others referred to as the backup nodes.
All of the nodes within the system communicate with each other and the goal is for all of the honest nodes to come to an agreement of the state of the system through a majority.
Nodes communicate with each other heavily, and not only have to prove that messages came from a specific peer node, but also need to verify that the message was not modified during transmission.
For the pBFT model to work, the assumption is that the number of malicious nodes in the network cannot simultaneously equal or exceed ⅓ of the overall nodes in the system in a given window of vulnerability.
Each round of pBFT consensus (called views) comes down to 4 phases. This model follows more of a “Commander and Lieutenant” format than a pure Byzantine Generals’ Problem, where all generals are equal, due to the presence of a leader node. The phases are below.
A client sends a request to the leader node to invoke a service operation.
The leader node multicasts the request to the backup nodes.
The nodes execute the request and then send a reply to the client.
The client awaits f + 1 (f represents the maximum number of nodes that may be faulty) replies from different nodes with the same result. This result is the result of the operation.
The requirements for the nodes are that they are deterministic and start in the same state. The final result is that all honest nodes come to an agreement on the order of the record and they either accept it or reject it.
The leader node is changed in a round-robin type format during every view and can even be replaced with a protocol called view change if a specific amount of time has passed without the leader node multicasting the request.
A supermajority of honest nodes can also decide whether a leader is faulty and remove them with the next leader in line as the replacement.
Permissioned vs Permissionless blockchain
The number of nodes in the permissioned blockchain is fixed(finite) whereas, in permissionless blockchain, the number of users is not fixed.
A permissioned blockchain needs prior approval before using whereas a permissionless blockchain lets anyone participate in the system.
Permissioned blockchain
These blockchains, also known as private blockchains, can be thought of as closed ecosystems that can only be accessed by those who are allowed access. Anyone who is interested in validating transactions or viewing data on the network needs to get approval from a central authority. This is useful for companies, banks, and institutions that are comfortable complying with the regulations and are very concerned about having complete control of their data. Ripple is a perfect example of a permissioned blockchain.
Characteristics of Permissioned Blockchains
Transparency and Anonymity
These blockchains need not be transparent, but they can choose to be so, depending on the inner organization of businesses. In terms of privacy, these are not needed on a central level and can be determined on a user-case basis. These blockchains store an extensive amount of data relating to the operations and transactions carried out by users.Varying Decentralization
Members of this blockchain are free to negotiate and come to a decision about the level of decentralization the network can have. Private blockchains can be fully centralized or partially decentralized. These are free to choose the consensus algorithms they wish to employ.Governance
Here, governance is decided by the members of the business network. There are various dynamics to determine how decisions are made on a central level. But here, there is no need for consensus-based mechanisms where the entire network must agree to a change.
Permissionless blockchain
Popular blockchains such as Bitcoin, Ethereum, Litecoin, Dash, and Monero fall under this category. Also known as public blockchains, these allow anyone to transact and join as a validator. The data on these blockchains is publicly available, and complete copies of the ledgers are stored across the globe. This is what makes it hard to censor or hack these systems. This blockchain does not have anyone who controls it, and one can remain relatively anonymous as there is no need for identifying themselves to get an address and perform transactions.
Characteristics of Permissionless Blockchains
Digital Assets
In a permissionless network, there is a user-incentivizing token that can increase or decrease in value based on the relevancy and state of the blockchain they belong to. Depending on the purpose, these blockchains either employ monetary or utility tokens.Transparency
According to default design, these are bound to be transparent. Users of the network must be incentivized to trust the network. A transparent network must give users access to all information apart from just the private keys, and this can include addresses, freedom to see transactions processed by the network, and the way in which transactions are processed into blocks.Decentralization
These are decentralized as there is no central entity that shuts down the network, changes its protocols, or edits the ledger. These are based on consensus protocols. This means that network changes of any type can be achieved only if 51% of the users agree to it.
Crypto vs Banking
Cryptocurrencies are digital assets that function like traditional money and can serve as means of exchange. They are usually bought through crypto exchange platforms and stored in safe crypto wallets. These digital currencies are decentralized, and they operate in a very secure way with minimal human interactions. As a result, many now classify them as the future of the finance sector.
Banks are the current financial systems in the world. They offer financial support like loans, savings, and other transactions. However, unlike cryptos, they have many setbacks since they are centralized and subject to biases. They are also relatively slower than cryptos, and some charge too high interests on loans and some transactions.
Drawbacks of banking systems
Accessibility The banks are usually not available during the weekend. Therefore, people usually encounter many problems when expecting to complete essential transactions on weekends and holidays. The banks also require people's physical appearance to complete huge transactions, which takes up too much time.
Financial Inclusion The traditional banking systems use different techniques to market their work. They set aside some projects for select groups of people which cannot be available to the others. These groups get some favors like soft loans, prolonged payment durations, and lower interest rates. As a result, the systems end up being unfair and devoid of financial inclusion.
Security Issues Skilled technicians can hack many mobile banking apps. As a result, some people end up losing large sums of cash from their accounts. The systems are also prone to fraud and money embezzlement. These occurrences may result in loss of hard-earned money.
Extra Fees and Slow Transactions Banks come with extra fees and taxes during transaction periods. For example, the sending and receiving banks usually impose very high transaction fees and taxes during international remittances. Due to slow protocols, these transactions also take a long time, especially for large sums of cash.
Can Be Biased Since bank transactions and financial services depend on account numbers and names, they are open to biases. In case of a feud with the officials of a certain bank, the financial service issuing officer can deliberately delay the transactions.
How Cryptocurrencies Can Offer More than Banking Systems?
Decentralized Nature Cryptocurrencies are completely free of the control of third parties, unlike banks. This decentralized nature minimizes human interactions, which makes them free from biases. They are more secure and reliable since it is hard to tamper with them because they use anonymous ID numbers in transactions.
Security Concerns The biggest issue surrounding financial systems is security concerns. Cryptocurrencies run on blockchain technology which is highly intact and free from major security threats like hacking.
It is also free from fraudulent activities since the system automatically processes the transactions with minimal human interactions. Therefore, if cryptos innovate more ways to deal with security concerns, they can remain better than banks.**Smart Contracts ** Cryptocurrencies can also have smart contracts running in their blockchain networks. These smart contracts have a design to give computer instructions and process them with minimal human interactions. Therefore, they can serve excellently in doing away with fraudulent activities and corruption, which is a challenge to banks.
Many crypto platforms also encourage investors to take a positive initiative to buidl and ensure the growth of coins. In turn, users and holders can actively contribute to the boom of not only their tokens but also other tokens at large; hence, securing a brighter future for crypto adoption and spreading crypto's diversification. One building tactic is leveraging smart contracts during transactions.
4)** Financial Inclusion** Cryptocurrencies have minimal entry barriers. As a result, they are easily accessible to everyone regardless of their status. This feature is encouraging since they may help improve the economy wholesomely as everyone gets equal chances.
- Accessibility Unlike banks, cryptocurrencies use automatic systems that do not require too many human interactions. Therefore, they are accessible every time of the day, including the weekend and holidays.
As a result, their incorporation into financial systems may make them better than banking systems due to better uptime.
Bitcoin
The Bitcoin system is a collection of computers (also referred to as "nodes" or "miners") that all run Bitcoin's code and store its blockchain. Figuratively speaking, a blockchain can be thought of as a collection of blocks. In each block is a collection of transactions. Because all of the computers running the blockchain have the same list of blocks and transactions and can transparently see these new blocks as they're filled with new Bitcoin transactions, no one can cheat the system.
Bitcoin is one of the first digital currencies to use peer-to-peer (P2P) technology to facilitate instant payments. The independent individuals and companies who own the governing computing power and participate in the Bitcoin network—Bitcoin "miners"—are in charge of processing the transactions on the blockchain and are motivated by rewards (the release of new Bitcoin) and transaction fees paid in Bitcoin.
Need of consensus
Public blockchains that operate as decentralized, self-regulating systems work on a global scale without any single authority. They involve contributions from hundreds of thousands of participants who work on verification and authentication of transactions occurring on the blockchain, and on the block mining activities.
In such a dynamically changing status of the blockchain, these publicly shared ledgers need an efficient, fair, real-time, functional, reliable, and secure mechanism to ensure that all the transactions occurring on the network are genuine and all participants agree on a consensus on the status of the ledger. This all-important task is performed by the consensus mechanism, which is a set of rules that decides on the legitimacy of contributions made by the various participants (i.e., nodes or transactors) of the blockchain.
Mempool
A mempool (a contraction of memory and pool) is a cryptocurrency node’s mechanism for storing information on unconfirmed transactions. It acts as a sort of waiting room for transactions that have not yet been included in a block.
When a transaction is a broadcast, it is sent from a node to its peers, who will then pass it on to their peers. This continues until the transaction has been widely propagated, ready for miners to add it to a block. It’s vital that this buffer zone exists, as transactions are not added to the blockchain immediately.
Nodes will run a series of checks to ensure that the transaction is valid – i.e., verifying that signatures are correct, outputs do not exceed inputs, and funds have not already been spent. If it fails to satisfy these conditions, it is rejected.
We often speak of the mempool, but it should be noted that there is no universal pool shared by all nodes. Each one is configured differently and receives transactions at different times. Lower-end devices with limited resources may only dedicate small amounts of memory to logging transactions, whereas higher-end ones might devote considerably more.
As miners are motivated chiefly by profits, transactions with higher fees attached are those most likely to be discarded from the mempool first as they’re confirmed. Accurately estimating fees is difficult, particularly when block space is limited, and demand is high, but the mempool provides a starting point.
To estimate fees, one can look to the current unconfirmed transactions. It stands to reason that users should not overpay in times of low throughput. Nor should they underpay for time-sensitive transactions at peak times, as it may be a while before it gets confirmed. By taking into account the spread of fees at a given moment, they can make an educated guess at how quickly their transaction will be included.
Bitcoin block
A blockchain network witnesses a great deal of transaction activity. When used in cryptocurrency, maintaining a record of these transactions helps the system track how much was or wasn't used and which parties were involved. The transactions made during a given period are recorded into a file called a block, which is the basis of the blockchain network.
A block stores information. There are many pieces of information included within a block, but it doesn't occupy a large amount of storage space. Blocks generally include these elements, but they might vary between different types:
Magic number: A number containing specific values that identify that block as part of a particular cryptocurrency's network.
Blocksize: Sets the size limit on the block so that only a specific amount of information can be written in it.
Block header: Contains information about the block.
Transaction counter: A number that represents how many transactions are stored in the block.
Transactions: A list of all of the transactions within a block.
The transaction element is the largest because it contains the most information. It is followed in storage size by the block header, which includes these sub-elements:
Version: The cryptocurrency version being used.
Previous block hash: Contains a hash (encrypted number) of the previous block's header.
Hash Merkle root: Hash of transactions in the Merkle tree of the current block.
Time: A timestamp to place the block in the blockchain.
Bits: The difficulty rating of the target hash, signifying the difficulty in solving the nonce.
Nonce: The encrypted number that a miner must solve to verify the block and close it.
Merkle tree
Rather, each transaction is hashed, then each pair of transactions is concatenated and hashed together, and so on until there is one hash for the entire block. (If there is an odd number of transactions, one transaction is doubled and its hash is concatenated with itself.)
The hashes on the bottom row are referred to as "leaves," the intermediate hashes as "branches," and the hash at the top as the "root." The Merkle root of a given block is stored in the header.
Blockchain mining
At its core, the term ‘Blockchain mining’ is used to describe the process of adding transaction records to the bitcoin blockchain. This process of adding blocks to the blockchain is how transactions are processed and how money moves around securely on Bitcoins. This process of Blockchain mining is performed by a community of people around the world called ‘Blockchain miners.’
Anyone can apply to become a Blockchain miner. These Blockchain miners install and run a special Blockchain mining software that enables their computers to communicate securely with one another. Once a computer installs the software, joins the network, and begins mining bitcoins, it becomes what is called a ‘node.’ Together, all these nodes communicate with one another and process transactions to add new blocks to the blockchain which is commonly known as the bitcoin network.
Nonce and difficulty
The nonce is the only data that a miner can add. A nonce is an additional number entered by the miner to change the hash output so that it has a low value or equal to the mining target. Miners can only guess the nonce numbers to produce a hash target that starts with the number 0. So, you can say nonce is a brute force way to achieve mining targets.
What is the purpose of mining difficulty?
Bitcoins are mined every 10 minutes on average and this should be constant in the long run. With the increasing computer power, it is certain that miners will find it easier to find hashes. To ensure that Bitcoin is mined constantly every 10 minutes, the mining difficulty must be adjusted as well, so that if the number of computer hardware and the miners increase, it will not affect the time to find new blocks. The higher the mining difficulty, the smaller the value of the valid hash (or the more zeros in front of the hash).
Why 10 minutes?
Ten minutes was specifically chosen by Satoshi as a tradeoff between first confirmation time and the amount of work wasted due to chain splits. After a block is mined, it takes time for other miners to find out about it, and until then they are actually competing against the new block instead of adding to it. If someone mines another new block based on the old blockchain, the network can only accept one of the two, and all the work that went into the other block gets wasted. For example, if it takes miners 1 minute on average to learn about new blocks, and new blocks come every 10 minutes, then the overall network is wasting about 10% of its work. Lengthening the time between blocks reduces this waste.
Forking
Blockchain forks are essentially a split in the blockchain network. The network is open-source software, and the code is freely available. This means that anyone can propose improvements and change the code. The option to experiment on open source software is a fundamental part of cryptocurrencies, and also facilitates software updates to the blockchain.
Forks occur when the software of different miners becomes misaligned. It’s up to miners to decide which blockchain to continue using. If there isn’t a unanimous decision, then this can result in the creation of two versions of the blockchain. There can be periods of increased price volatility around such events.
Longest chain rule
The longest chain is what individual nodes accept as the valid version of the blockchain.
The rule that nodes adopt the longest chain of blocks allows every node on the network to agree on what the blockchain looks like, and therefore agree on the same transaction history.
A blockchain with more blocks in it will have taken more energy to build than a chain with fewer blocks in it, and as a rule nodes will always adopt this chain over a “shorter” one.
Why do nodes adopt the longest chain?
Resolving disagreements when two blocks are mined at the same time.
Protecting blocks already mined on to the blockchain.
Why do miners build on the longest chain?
Because a miner can claim a block reward if they can mine a block.
Furthermore, the bitcoins from this block reward can only be spent if the block becomes 100 blocks deep in the longest chain. Therefore, this block reward incentivizes miners to always try and mine new blocks that will become part of the longest chain
Proof of work(PoW)
The proof-of-work model is a consensus mechanism used to confirm and record cryptocurrency transactions.
Every cryptocurrency has a blockchain, which is a public ledger made up of blocks of transactions. With proof-of-work cryptocurrencies, each block of transactions has a specific hash. For the block to be confirmed, a crypto miner must generate a target hash that's less than or equal to that of the block.
To accomplish this, miners use mining devices that quickly generate computations. The aim is to be the first miner with the target hash because that miner is the one who can update the blockchain and receive crypto rewards.
The reason proof of work in cryptocurrency works well is that finding the target hash is difficult but verifying it isn't. The process is difficult enough to prevent the manipulation of transaction records. At the same time, once a target hash is found, it's easy for other miners to check it.
Example of proof of work
Here's an example of how Bitcoin uses proof of work to maintain the integrity of its blockchain.
When Bitcoin transactions occur, they go through a security verification and are grouped into a block to be mined. Bitcoin's proof-of-work algorithm then generates a hash for the block. The algorithm Bitcoin uses is called SHA-256, and it always generates hashes with 64 characters.
Miners race to be the first to generate a target hash that's below the block hash. The winner gets to add the latest block of transactions to Bitcoin's blockchain. They also receive Bitcoin rewards in the form of newly minted coins and transaction fees. Bitcoin has a fixed maximum supply of 21 million coins, but, after that, miners will continue receiving transaction fees for their service.
The proof-of-work algorithm used by Bitcoin aims to add a new block every 10 minutes. To do that, it adjusts the difficulty of mining Bitcoin depending on how quickly miners are adding blocks. If mining is happening too quickly, the hash computations get harder. If it's going too slowly, they get easier.
Security issues
A) Node can send blocks quickly
Generally, Block creation time > Block propagation time
If the above condition is false i.e when block creation time is small then chances of forking increase which means chances of double spending will increase.
i.e why mining or block creation should take an average of 10 minutes.
No of confirmations ∝ Security Average 7 confirmations per transaction are considered.
Block size increases => Transmission delay increases => Forking increases
Selfish mining attack
Eclipse attack
B) Attacker controls 51% of computing power
Selfish mining attack
Selfish mining can be done by a coalition that commands less than 1/4 of the resources. This threshold is lower than the wrongly assumed 1/2 bound but better than the current reality where a coalition of any size can compromise the system.
Selfish mining is a deceitful cryptocurrency mining strategy in which one miner or a group solves a hash, opens a new block, and withholds it from the public blockchain. This action creates a fork, which is then mined to get ahead of the public blockchain.
If the group's blockchain gets ahead of the honest blockchain, it can introduce its newest block to the network. The network is geared to recognize the most recent block, so the group's fork would overwrite the original blockchain. The miners could effectively steal cryptocurrency from other users by altering the blockchain.
Selfish mining is a deceptive cryptocurrency mining strategy in which a solo miner or group work to alter the blockchain to their benefit.
In this strategy, miners “hide” their generated blocks from the main blockchain.
Instances of selfish mining have not been observed in the real world, but the lack of observance doesn't mean it hasn't or won't happen.
How Does Selfish Mining Work?
"Mining" is the process in which nodes in the blockchain's network validate and confirm transactions. Miners earn newly minted tokens in return for their computational effort. With selfish mining, the cartel obscures newly created blocks from the main chain, revealing them at a later point in time.
Selfish mining was first identified by Cornell researchers Emin Gün Sirer and Ittay Eyal in a 2013 paper. They proved that it was possible to earn more bitcoins by hiding newly-generated blocks from the main blockchain, creating a blockchain fork. Theoretically, the miners could introduce it to the network at the right time and alter the blockchain.
The Bitcoin and other cryptocurrency networks using the proof-of-work consensus mechanism rely on miners whose mining software discovers the solution to the randomly-generated encrypted hash number. When the hash is solved, a new block opens up on the blockchain, and the miner who solved it receives a transaction fee and a reward.
In their 2013 paper, Sirer and Eyal demonstrated that miners can increase their overall revenue share by hiding new blocks and making them available to systems within their private network. This practice speeds up the discovery process and irons out infrastructure problems related to mining, such as network latency and electricity costs.
Initially, the forked blockchain will be shorter than the public blockchain. The private chain mines new blocks within its pool and hides any newly-generated blocks. The mining process is repeated until the private blockchain reaches a block height greater than that of the public blockchain.
Selfish miners then strategically time the introduction of their new blocks to the honest blockchain such that the public blockchain joins the newly introduced chain. The public network mines the new blockchain, and the selfish miners receive the cryptocurrency rewards and transaction fees for their newly accepted blocks.
Sirer and Eyal analyzed resources wasted for both chains. They postulated that selfish miners possessed a competitive advantage over miners on the public blockchain because their rewards are comparatively greater after accounting for wasted resources.
Eclipse attack
An eclipse attack is a relatively simple attack that a malicious actor may deploy to interfere with nodes on a network. As the name may suggest, the attack aims to obscure a participant’s view of the peer-to-peer network, in order to cause general disruption or to prepare for more sophisticated attacks.
Bitcoin miners require specialized equipment in order to generate new blocks, but non-mining (or full) nodes are easily run on minimal computational power. This aids the decentralization of Bitcoin, as anyone can spin up a node on a low-spec device. The software maintains a database of transactions that it synchronizes with its immediate peers, so as to remain in lockstep with the network.
A limiting factor for many nodes is bandwidth. Though there is a tremendous amount of devices running the software, the average device is unable to connect directly to many of them due to limitations set out in the Bitcoin software (which only permits a maximum of 125 connections).
In an eclipse attack, the malicious actor will ensure that all of the target’s connections are made to attacker-controlled nodes. The entity will first flood the target with its own IP addresses, which the victim will likely connect to upon the restart of their software. A restart can either be forced (i.e. with a DDoS attack on the target), or the attacker can simply wait for it to occur. Once this has occurred, the unsuspecting victim is at the mercy of the malicious nodes– with no view of the wider network, they can be fed incorrect data by the attacker.
***0-confirmation double spends - ***
***N-confirmation double spends - ***
UTXO Model
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. UTXOs are processed continuously and are responsible for beginning and ending each transaction. Although confirmation of transaction results in the removal of spent coins from the UTXO database, a record of the spent coins still exists on the ledger.
UTXO or unspent transaction outputs are used in cryptocurrency transactions. These are the transactions that are left unspent after someone completes a transaction, similar to the change someone receives after conducting a cash transaction at the store.
Here's how it works. A UTXO database is used to store change from cryptocurrency transactions. This database or ledger is initially set to empty or zero. As transactions multiply, the database becomes populated with change records from various transactions. When a transaction is completed and there are outputs that aren't spent, they are deposited back into a database as inputs that can be used at a later date for a new transaction. Cryptocurrency transactions—such as those used for bitcoins—are similar to cashier checks. You cannot exchange them for custom amounts and must spend the entire amount stored in that data byte.
But cryptocurrencies like bitcoin are also unique in that transactions can be conducted using fractions of the cryptocurrency. This means spending does not take place using a single data byte. Instead, multiple fractions of bitcoin are retrieved by the algorithm to fulfill a spending request. For example, a purchase worth 1 bitcoin may retrieve 0.6 BTC from one byte and 0.4 BTC from another. Change from each of these fractions is then sent to the UTXO database to be spent at a later date.
Full node vs light node
A full node is a node that fully enforces all of the rules of the blockchain, while a light client (also known as a lightweight node) is referencing a trusted full node’s copy of the blockchain.
Lightning network
The lightning network is a second layer technology applied to bitcoin that uses micropayment channels to scale its blockchain’s capability to conduct transactions more efficiently. Transactions conducted on lightning networks are faster, less costly, and more readily confirmed than those conducted directly on the bitcoin blockchain (i.e., on-chain).
By taking transactions away from the main blockchain and making them off-chain, the lightning network was designed to de-congest the bitcoin blockchain and reduce associated transaction fees. The lightning network can also be used to conduct other types of off-chain transactions involving exchanges between cryptocurrencies.
The problem the lighting network was devised to solve is the slow transaction time and throughput of bitcoin.
If it is to achieve its potential of becoming a medium for daily transactions, bitcoin will need to reach tens or hundreds of thousands of transactions per second, similar to credit cards or electronic payments networks. Due to the nature of its decentralized technology that requires consensus from all nodes within its network, bitcoin is laden with such problems in its current state.
For example, approving and storing transactions will become expensive and time-consuming if their numbers on bitcoin’s network multiply. An increase in transaction numbers also requires orders of magnitude improvement in the processing power of the computers that are required to execute transactions involving bitcoin. Additionally, the energy necessary to compute this information is enormous, making maintaining bitcoin for day-to-day transactions prohibitively expensive.
The lightning network proposed to solve the scaling problem by creating a second layer on bitcoin’s main blockchain. That second layer consists of multiple payment channels between parties or bitcoin users. A lightning network channel is a transaction mechanism between two parties. Using channels, the parties can make or receive payments from each other.
These transactions are processed differently compared to standard transactions occurring on bitcoin’s blockchain. They are only updated on the main blockchain when two parties open and close a channel.
Between those two acts, the parties can shift funds between themselves endlessly without informing the main blockchain about their activities. This approach dramatically speeds up a transaction’s speed because all transactions are not required to be approved by all nodes within a blockchain. Individual payment channels between various parties combine to form a network of lightning nodes that can route transactions among themselves. The interconnections between various payment channels result in the Lightning Network.
How does it work?
The idea behind LN is that not all transactions are required to be recorded on the Blockchain.
Imagine you and I transact quite a few times among ourselves. In such a case, we can bypass recording the transactions on the Blockchain and carry them off the chain.
In the simplest terms, how it’ll work is -- we’ll open something called a payment channel between us and record its opening on the Blockchain. Now, you and I can transact any number of times through this payment channel and it can stay open for any number of hours, days, weeks or decades. The only time we would touch the Blockchain ever again will be when we would want to close the channel. Then, we’ll write the final status of the transactions that occurred through the channel on the Blockchain.
Using this idea of a payment channel, we can create a network of payment channels such that it would be only rarely required for the transaction on the Blockchain. Imagine there are three characters - Xan, Yelena, and Zeke.
If Xan and Yelena have a payment channel opened between them and Yelena and Zeke have a payment channel opened between them, then Xan can send money to Zeke via Yelena.
Suppose Xan wants to send 2 BTC to Zeke, Yelena will send 2 BTC to Zeke, and Xan will reimburse Yelena with 2 BTC.
That’s what the idea of Lightning Network is. Because you won’t be touching the Blockchain often, the transactions will be happening at lightning speed. As you might have guessed by now, all the magic happens in the payment channels. Let’s learn the magic trick then.
It’s like a safety deposit box where two people deposit equal amounts of money and each put a lock on it.
This action of depositing equal amounts of money in a common box is recorded on the Blockchain in the form of an ‘Opening Transaction’ and thereafter a payment channel is open between those two people.
The idea behind locking money in such a box is that no one person can spend the money in the box without the other. The money in this box is then used to transact between each other.
Imagine, Xan and Yelena pool in 10 BTC each in the common box. And now, if Xan wants to send 2 BTC to Yelena, how would he do that?
To do that, he would transfer a promise of ownership for two of his Bitcoins in the common box to Yelena. After this transfer of promise, if the box is unlocked, Xan will be able to take 8 BTC from it and Yelena will be able to claim 12 BTC.
But they will not open the box because they want to continue transacting between themselves. That’s the beauty of this arrangement.
Now, if the next day, Yelena has to send 1 BTC to Xan, she would do the same - transfer a promise of ownership for one of her Bitcoins to Xan. After these two transactions, if the box is opened, Xan can claim 9 BTC, and Yelena can get 11 BTC.
To imagine what off-chain transactions look like, consider this:
To sum it up, a payment channel is nothing but a combination of pooling some money together and then transferring the promise of ownership of the pooled-in money in an agreed-upon manner. If ever either Xan or Yelena wants to close the channel, they can.
Closing a channel would simply mean opening up the box and taking the money inside. This opening of the box happens on the Blockchain and the who owns how much from the box is recorded forever.
That’s how payment channels work. But that doesn’t even come close to defining their true potential. Their true power is unleashed when two or more payment channels work together to form a network - The Lightning Network.
LN works by moving the value from the ownership of the Bitcoins to the promise of ownership of the Bitcoins.
This shift is huge. As always, we will use an example to understand this. Imagine there are three people - Xan, Yelena, and Zeke - such that there’s a payment channel open between Xan and Yelena, and there’s another channel open between Yelena and Zeke. Note that Xan and Zeke have no payment channel between them.
In such a situation, if Xan wants to transfer 2 BTC to Zeke, he can use the payment channel between Yelena and Zeke to do that. What does that look like?
Xan asks Yelena to transfer a promise of 2 BTC to Zeke on the Yelena-Zeke payment channel and then he reimburses Yelena with 2 BTC on the Xan-Yelena channel.
With such a network of payment channels, a huge chunk of transactions can be off-loaded from the Blockchain to be carried out off the chain, therefore, freeing up the chain’s bandwidth. Using a network of payment channels, millions of transactions can happen, and that too without a hefty transaction fee.
That’s the Lightning Network.
Payment channels
A payment channel connecting two participants of the network is nothing else than a common multisig wallet. The first transaction, determining the balance of the channel, is known as the funding transaction or the anchor transaction. This transaction should be sent into the network and mined to create the channel.
Having done that, the parties exchange mutually signed commitment transactions that modify the initial balance of the channel. These transactions are valid and can be sent into the bitcoin network but they are kept outside, waiting for the closure of the channel. In this way, the state of the balance can change thousands of times per second, limited only by the time needed by the parties to create, sign and send each other commitment transactions.
Each time the parties exchange a new commitment transaction, they invalid the previous state of the channel; therefore, only the most recent commitment transaction can be carried out. The goal is to prevent fraud by the parties, barring them from sending to the blockchain one of the previous states of the channel, the most advantageous for them.
Finally, the channel can be closed both by mutual consent — by sending the closing transaction (settlement transaction) to the blockchain — or by the decision of one of the parties, that would send the last commitment transaction to the blockchain. It allows to prevent a case of one party going offline and ‘locking’ the funds of another party on the channel.
During the whole existence of the channel, only two transactions are sent to the bitcoin network and recorded in the blockchain (the funding transaction and the settlement transaction). Between those two, the parties may exchange any number of commitment transactions that would never make it to the blockchain.
Example of a simple payment channel
In our example, we have two participants, Emma and Fabian. Fabian provides a video streaming service paid through the channel by micropayments — one second of the video costs 0.00001 BTC, which amounts to 0.036 BTC per hour. Emma is an ordinary user that wished to watch a video.
Emma and Fabian use a special program that allows working both with the payment channel and the video. Emma launches this program in her Internet browser, Fabian uses it on his server. The program has all the functions of an ordinary bitcoin wallet, can create and sign transactions. The whole mechanism of the payment channel is hidden from the users who see only the fact that the video is paid for every second.
Let us now see how it will function. To create a channel, Emma and Fabian have to establish a 2-of-2 multisig address. From the user’s side, the program creates a P2SH address (a multisig wallet) and asks to top-up it with enough funds to pay for one hour. Emma transfers 0.036 BTC to the wallet and this transaction becomes an opening one (a funding transaction).
As soon as the funding transaction is confirmed and the channel is open, the video streaming starts. On the first second, the user’s party creates and signs a commitment transaction that changes the balance of the channel: 0.00001 BTC belongs now to Fabian and 0.03599 to Emma. The transaction uses the output of the funding transaction (0.036) and contains two new outputs that have just been mentioned. On the service’s side, the program receives this transaction, signs it, and sends it back together with the first second of the video. Now both parties have a mutually signed commitment transaction reflecting the latest state of the channel that both can send to the bitcoin network if necessary.
A new commitment transaction is created during the 2nd second, using the same output as the first one, and new outputs are 0.00002 to Fabian and 0.03598 to Emma. This transaction is the payment for two downloaded seconds of the video. It is then sent to the second side etc.
Let us assume that Emma watched 10 minutes of the video and then got tired and stopped watching. Over this period, 600 commitment transactions were sent and signed (for 600 seconds of streaming). The last of them has two outputs: 0.03 to Emma and 0.006 to Fabian. Emma closes the channel, sending this commitment transaction to the bitcoin network as the ‘settlement transaction’. Therefore, only two transactions get into the blockchain.
Trustless channels
Of course, everything functions in this example but only if both parties are honest. It is not difficult to imagine a scenario in which one of the parties may cheat to get an advantage or the channel would not work adequately.
While the channel is open, Emma needs Fabian’s signature to withdraw the funds because the channel is a 2-of-2 multisig address. If Fabian disappears, Emma’s funds may stay forever locked in the channel.
While the channel is open, Emma can use any commitment transaction signed by both parties. After watching the video for 10 minutes, she can take the very first commitment transaction and send it to the bitcoin network without Fabian’s consent.
Justice transaction
We examine lightning channel closure scenarios and the incentives to punish dishonest parties and prevent them from stealing funds. This punishment mechanism is called a “Justice Transaction”.
Watchtowers
A watchtower is a third-party lightning node, that can detect if a dishonest party attempts to steal funds and then broadcast a justice transaction, sending the funds back to the honest party, even when the honest node is offline.
Watchtowers implement unlinkable channel monitoring and recovery for Lightning network channels. A watchtower is a program that watches the blockchain to see when a particular transaction is broadcast to the mempool.
Example:
When Alice’s payment channel state gets updated (Bob transfers 0.1 BTC to Alice), Alice sends to a LN watchtower encrypted signatures authorizing the movement of all channel’s funds back to Alice. The package sent by Alice has no info about state balances, so Alice’s privacy should be safe (disputable) unless the channel will be closed unilaterally.
Basically, Alice is pre-signing a transaction of all channel funds back to her, so she can be offline at the time the breach happens. Each sent package also contains a “hint” about how to find potential breaching on-chain transactions, so the LN watchtower constantly watches blockchain by checking all new transactions against its hash table of “hints”.
Bob decides to cheat Alice by closing the LN channel unilaterally with the old state (i.e. a state before he sent 0.1 BTC to Alice). When the LN watchtower spots the breaching transaction, it’s able to decrypt the signatures from Alice’s package and reconstruct the penalty transaction which moves all funds back to Alice.
Since a channel was closed unilaterally, there is a time-lock on funds, so LN watchtower has some time to react before Bob would be able to spend the “stolen” funds.
Algorand
Algorand is a pure proof of stake blockchain cryptocurrency protocol that is scalable by solving the blockchain trilemma with its consensus mechanism. The Algorand platform supports smart contracts, and its consensus algorithm is based on proof of stake and a Byzantine agreement protocol.
Algorand is a smart contract platform trying to solve the blockchain trilemma (scalability, decentralization, security) and help democratize finance.
Bitcoin, Ethereum, and other traditional cryptocurrency networks are typically very congested. Transactions are processed slowly and are expensive to make. The Algorand network aims to solve this problem by reducing gas fees and making transactions faster.
Algorand works on the pure PoS mechanism. “The pure PoS system which Algorand employs randomly selects committees from the participating ALGO holders to validate and approve the next block in the chain. This randomization is a result of a unique cryptographic tool called the VRF (Verifiable Random function) invented by Algorand’s founder, that seeks to solve the blockchain trilemma”
In Algorand’s blockchain network, only a select set of miners will be given a reward block of its token ALGO after they have successfully lent their computer’s processing power to the network. The users are picked randomly, irrespective of the size of the assets they have pledged to the blockchain, thereby maintaining a fair chance for everyone. This tweaked mechanism is what allows Algorand its incredible transaction processing speed feature.
“It is a mechanism to achieve distributed consensus. ‘Pure’ refers to users not having to lock up or bond their algos to participate in this process, which differs from other PoS blockchains that require stakers/validators to lock up tokens to be able to participate in validating transactions. In pure PoS, users' power is proportional to their stake and participating users are randomly selected to propose/validate blocks”
Lightning network
Note:
HTLC is a contract that stands for Hash Time Lock Contract.
A Hashed TimeLock Contract or HTLC is a smart contract that allows transactions to be sent between parties who do not have a direct channel on the Lightning Network.
A hashed timelock contract (HTLC) reduces counterparty risk in decentralized smart contracts by effectively creating a time-based escrow that utilizes a cryptographic passphrase.
This type of smart contract requires the receiver of payment to acknowledge it within a certain period of time or forfeit it.
We have five participants: Alice, Bob, Carol, Diana, and Eric. Every one of them has open payment channels with others with the balance of 2 bitcoins on every side of every channel. So, having a chain of channels, let us try to execute the payment from Alice to Eric.
Let us assume that Alice wants to transfer 1 bitcoin to Eric. However, as we see, they are not connected by a direct channel, and opening a new channel requires time and money. Luckily, Alice is connected to the Lightning Network and can make an indirect payment with the help of a series of HTLC contracts. Let us examine this payment step by step.
Eric creates a secret R and communicates its hash to Alice (he does not show the secret itself to anyone).
Alice uses this hash to create an HTLC with a timelock set on 10 blocks forward, for the amount of 1.003 BTC. The additional 0.003 BTC will be used as a fee to the intermediate participants for their participation in the chain. So, Alice locks her balance of 1.003 BTC in the HTLC, using the following rule: “Alice will pay Bob 1.003 BTC if he finds the secret R during the next 10 blocks, otherwise the funds will return to Alice.” The balance of the channel was changed by a commitment transaction and is now as follows: Bob has 2 BTC, Alice has 0.997 BTC, and 1.003 BTC are locked in the HTLC.
In his turn, Bob, having at his disposal Alice’s commitment transaction (the HTLC sent to the channel that connects them), creates an HTLC on the channel that connects him to Carol for the amount of 1.002 BTC with a timelock set on 9 blocks forward. He uses the same hash as Alice. Bob knows that Carol will have to find out the secret R to unblock the HTLC sent by him, and as soon as she does it, he will also learn it and will therefore be capable to unlock the 1.003 BTC sent to him by Alice. If Carol cannot find out the secret R, Bob and Alice will simply retrieve their funds on the expiration of the timelock. Let us also remark that the amount of funds sent by Bob is 0.001 BTC smaller than the funds he receives: it is a fee he took for his participation in the chain. The balance of the channel between Bob and Carol is as follows: Carol has 2 BTC, Bob has 0.998 BTC, and 1.002 BTC are locked in the HTLC.
Carol, having received Bob’s commitment transaction, creates an HTLC (using the hash that Bob used) on the channel with Diana for the amount of 1.001 BTC with a timelock set on 8 blocks forward. If Diana can discover the secret R before the 8 blocks are over and unblock the HTLC to get 1.001 BTC, Carol will also learn the secret and will therefore be able to unblock the 1.002 BTC sent to her by Bob, therefore earning 0.001 BTC. The balance of the channel between Carol and Diana is now as follows: Diana has 2 BTC, Carol has 0.999 BTC, and 1.001 BTC are locked in the HTLC.
Finally, Diana sends an HTLC (always using the same hash) to her channel with Eric for the amount of 1 BTC and a timelock set on 7 blocks forward. The balance of the channel between Diana and Eric is now as follows: Eric has 2 BTC, Diana has 1 BTC, and 1 BTC is locked in the HTLC.
Now, we have arrived to the end of our chain. Eric, having the secret R, whose hash was used in all the HTLC commitment transactions, can unlock the HTLC sent to him by Diana and obtain 1 BTC. As soon as Eric uses the secret to receive the funds, it becomes available to Diana as well. The balance of the channel between Diana and Eric is now as follows: Eric has 3 BTC and Diana has 1 BTC.
Diana, having received the secret, unblocks 1.001 BTC sent by Carol and, by doing so, reveals her the secret. The balance of their channel is now as follows: Diana has 3.001 BTC and Carol has 0.999 BTC.
Carol, having received the secret, unlocks 1.002 BTC sent by Bob and, by doing so, reveals him the secret. The balance of their channel is now as follows: Carol has 3.002 BTC and Bob has 0.998.
Finally, Bob uses the secret to obtain 1.003 BTC from the channel between him and Alice. The balance of their channel is now as follows: Bob has 3.003 BTC and Alice has 0.997.
In this way, Alice paid Eric 1 BTC without opening a new channel that would link them directly. No one of the chain participants were obliged to trust others, and they earned 0.001 BTC as a fee for their role as middlemen.
Broken channel
In the first case, let us imagine that the funds have successfully reached the end of the chain, but on the way back (when the secret should escalate the chain, reaching the very beginning) a problem has emerged when one participant refused or was unable to cooperate. In our example, it would be Bob.
Diana, when the chain has reached her, immediately retrieves her funds, using the secret and revealing it to Carol. Carol also wishes to get her money back from Bob but he does not respond so, to avoid risk, she closes the channel, sending the last commitment transaction (the HTLC contract previously sent by Bob) into the blockchain and, with the help of the secret, retrieves the funds. In this case, Bob still has three days to surface and took his money from Alice (as the transaction has made it to the blockchain, he can easily find it and see the R). Otherwise, at the expiration of the timelock, she will be able to retrieve all her money.
It can be seen that if a participant for some reason leaves the system, he or she is the only one who risks losing funds, while all other participants of the chain are safe.
Lightning network routing
Gossip: Node discovery, channel discovery, and channel updates are broadcasted through gossip messages on the Lightning network. Rather than relying on a third party to distribute information, Lightning relies on announcements containing information with network updates
Route finding protocol: Gossip protocol to find the topology
Path finding: Path with least transaction fees
If a large amount of bitcoins is to be transferred, it can be broken into chunks. Example- 100 = 30 + 30 +30 + 10
Onion Routing
Onion routing is a technique for anonymous routing of payments over the Lightning Network. Routing messages are encapsulated in layers of encryption, analogous to layers of an onion. The encrypted data is transmitted through nodes on the network, each of which "peels" away from a single layer, uncovering the data's next destination. When the final layer of routing information is decrypted, the message arrives at its destination. The sender remains anonymous because each intermediary knows only the location of the immediately preceding and following nodes.
Onion routing means that each note only sees the immediate hope before it and the immediate hop after that. It is called onion routing because the routing information is wrapped in layers. So a node receives an encrypted package from the node one hop before it, and doesn't know where the final destination is. You unwrap one layer which tells you to go for the next
Lightening network privacy
The concept of privacy and anonymity set on LN is determined by our “neighbors”.
The anonymity set (privacy) of the Lightning user, when sending a payment, is relative to the nodes and channels that it has as “neighbors”. In particular, a routing node only knows the immediately preceding and following nodes: the routing node does not know whether its immediate neighbors in the payment path are the sender or the final recipient. Therefore, the anonymity set of a node in Lightning is approximately equal to its neighbors.
The more paths and channels there are on the Lightning Network, the more the privacy of users is preserved.