Category Archives: Decoding Whitepapers

We take deep dive into whitepapers in the web3 space and explain them in a clear and concise manner in bullet points.

Decoding Ethereum (ETH) Whitepaper

Read Time:5 Minute
eth home icon Decoding Ethereum (ETH) Whitepaper
Decoding Ethereum (ETH) Whitepaper 2


  • The blockchain technology can be used to create “contracts” that can be used to encode arbitrary state transition functions.
  • Bitcoin’s ledger can be thought of as a state transition system, where there is a “state” consisting of the ownership status of all existing bitcoins and a “state transition function” that takes a state and a transaction and outputs a new state.
  • The algorithm for checking if a block is valid requires that the sum of the denominations of all input UTXO is less than the sum of the denominations of all output UTXO.
  • The purpose of the proof-of-work requirement is to make block creation computationally “hard”, thereby preventing sybil attackers from remaking the entire blockchain in their favor.
  • In order to compensate miners for their work, the miner of every block is entitled to include a transaction giving themselves 25 BTC out of nowhere.
  • If any transaction has a higher total denomination in its inputs than in its outputs, the difference also goes to the miner as a “transaction fee”.
  • An attacker’s strategy is to produce another transaction sending the same 100 BTC to himself and try to convince the network that his transaction to himself was the one that came first.
  • In order for the attacker to make his blockchain the longest, he would need to have more computational power than the rest of the network combined in order to catch up (hence, “51% attack”).

Scripting and Alternative Applications

  • Bitcoin’s scalability is due in part to its use of a multi-level data structure called the Merkle tree.
    The Merkle tree allows for a piecemeal delivery of data, which is essential for long-term sustainability.
  • The Bitcoin protocol can be used to create a variety of alternative applications, including Namecoin and Colored Coins.
  • The Bitcoin protocol has limitations, including a lack of Turing-completeness and value-blindness.
  • There are three approaches to building advanced applications on top of cryptocurrency: building a new blockchain, using scripting on top of Bitcoin, and building a meta-protocol on top of Bitcoin.

Ethereum State Transition Function

  • Ethereum is an alternative protocol for building decentralized applications
  • Ethereum accounts contain four fields: the nonce, the account’s current ether balance, the account’s contract code (if present), and the account’s storage (empty by default)
  • There are two types of Ethereum accounts: externally owned accounts (controlled by private keys) and contract accounts (controlled by their contract code)
  • In Ethereum, the state is made up of objects called “accounts”
  • Transactions in Ethereum contain the recipient of the message, a signature identifying the sender, the amount of ether to transfer from the sender to the recipient, and an optional data field
  • Messages in Ethereum are virtual objects that are never serialized and exist only in the Ethereum execution environment; a message is produced when a contract currently executing code executes the CALL opcode
  • The Ethereum state transition function can be defined as follows: check if the transaction is well-formed, calculate the transaction fee, transfer the transaction value from the sender’s account to the receiving account, and if the value transfer failed because the sender did not have enough money, or the code execution ran out of gas, revert all state changes except the payment of the fees

Code Execution – Mining and Applications

  • The code in Ethereum contracts is written in a low-level, stack-based bytecode language, referred to as “Ethereum virtual machine code” or “EVM code”.
  • The code consists of a series of bytes, where each byte represents an operation.
  • Code execution is an infinite loop that consists of repeatedly carrying out the operation at the current program counter (which begins at zero) and then incrementing the program counter by one, until the end of the code is reached or an error or STOP or RETURN instruction is detected.
  • The operations have access to three types of space in which to store data: the stack, memory, and the contract’s long-term storage.
  • The code can also access the value, sender and data of the incoming message, as well as block header data, and the code can also return a byte array of data as an output.
  • The formal execution model of EVM code is surprisingly simple.
  • The Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences. The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state.
  • In general, there are three types of applications on top of Ethereum: financial applications, semi-financial applications, and non-financial applications.
  • Token systems are surprisingly easy to implement in Ethereum. The key point to understand is that all a currency, or token system, fundamentally is, is a database with one operation: subtract X units from A and give X units to B, with the proviso that (i) A had at least X units before the transaction and (2) the transaction is approved by A.
  • Financial derivatives are the most common application of a “smart contract”, and one of the simplest to implement in code.

Decentralization and Further Applications

  • The key piece of technology for a decentralized file storage system is the “decentralized Dropbox contract”. This contract allows users to store their files on a decentralized network of nodes, with the contract rewarding nodes for storing the file.
  • A decentralized autonomous organization (DAO) is a virtual entity that is controlled by a group of shareholders. The shareholders can vote to change the code of the DAO or to allocate its funds.
  • DAOs can be used for a variety of purposes, such as savings wallets, crop insurance, or smart multi signature escrow.
  • Prediction markets can be used to predict the outcome of events, and can be implemented on the Ethereum blockchain.

Scaling and Conclusion

  • The Ethereum protocol was conceived as an upgraded version of a cryptocurrency, providing advanced features such as on-blockchain escrow, withdrawal limits, financial contracts, gambling markets and the like via a highly generalized programming language.
  • The Ethereum protocol would not “support” any of the applications directly, but the existence of a Turing-complete programming language means that arbitrary contracts can theoretically be created for any transaction type or application.
  • What is more interesting about Ethereum, however, is that the Ethereum protocol moves far beyond just currency. Protocols around decentralized file storage, decentralized computation and decentralized prediction markets, among dozens of other such concepts, have the potential to substantially increase the efficiency of the computational industry, and provide a massive boost to other peer-to-peer protocols by adding for the first time an economic layer.
  • The concept of an arbitrary state transition function as implemented by the Ethereum protocol provides for a platform with unique potential; rather than being a closed-ended, single-purpose protocol intended for a specific array of applications in data storage, gambling or finance, Ethereum is open-ended by design, and we believe that it is extremely well-suited to serving as a foundational layer for a very large number of both financial and non-financial protocols in the years to come.

Decoding Ripple (XRP) Whitepaper

Read Time:3 Minute
xrp logo Decoding Ripple (XRP) Whitepaper
Decoding Ripple (XRP) Whitepaper 4


  • The Ripple Protocol is a distributed payment system that uses collectively-trusted sub-networks to achieve low-latency consensus.
  • The trust required of these sub-networks is minimal, and can be further reduced with principled choice of member nodes.
  • The Ripple Protocol is correct, in agreement, and useful in the face of Byzantine failures.

Definitions – Previous Work and Formalization

  • The Ripple Protocol consensus algorithm (RPCA) is applied every few seconds by all nodes, in order to maintain the correctness and agreement of the network.
  • The RPCA proceeds in rounds. In each round, each server takes all valid transactions it has seen prior to the beginning of the consensus round that have not already been applied, and makes them public in the form of a list known as the “candidate set”.
  • Each server then amalgamates the candidate sets of all servers on its UNL, and votes on the veracity of all transactions.
  • Transactions that receive more than a minimum percentage of “yes” votes are passed on to the next round, if there is one, while transactions that do not receive enough votes will either be discarded, or included in the candidate set for the beginning of the consensus process on the next ledger.
  • The final round of consensus requires a minimum percentage of 80% of a server’s UNL agreeing on a transaction. All transactions that meet this requirement are applied to the ledger, and that ledger is closed, becoming the new last-closed ledger.

Ripple Consensus Algorithm

  • The Ripple consensus algorithm (RPCA) proceeds in rounds, with each server taking all valid transactions it has seen prior to the beginning of the consensus round that have not already been applied, and making them public in the form of a list known as the “candidate set”.
  • Each server then amalgamates the candidate sets of all servers on its UNL, and votes on the veracity of all transactions.
  • Transactions that receive more than a minimum percentage of “yes” votes are passed on to the next round, if there is one, while transactions that do not receive enough votes will either be discarded, or included in the candidate set for the beginning of the consensus process on the next ledger.
  • The final round of consensus requires a minimum percentage of 80% of a server’s UNL agreeing on a transaction. All transactions that meet this requirement are applied to the ledger, and that ledger is closed, becoming the new last-closed ledger.
  • In order to achieve correctness, given a maximal amount of Byzantine failures, it must be shown that it is impossible for a fraudulent transaction to be confirmed during consensus, unless the number of faulty nodes exceeds that tolerance.
  • Agreement is not inherently guaranteed by the correctness proof, since the UNLs for each server can be different.
  • To satisfy the agreement requirement, it must be shown that all non faulty nodes reach consensus on the same set of transactions, regardless of their UNLs.
  • The limiting factor for the termination of the algorithm is the communication latency between nodes. In order to bound this quantity, the response-time of nodes is monitored, and nodes who’s latency grows larger than a preset bound b are removed from all UNLs.
  • A latency bound heuristic is enforced on all nodes in the Ripple Network to guarantee that the consensus algorithm will converge. In addition, there are a few other heuristics and procedures that provide utility to the RPCA, including a mandatory 2 second window for all nodes to propose their initial candidate sets in each round of consensus, and a network split detection algorithm.

Simulation Code

  • The Ripple Protocol consensus algorithm (RPCA) is a method for achieving consensus in a distributed system.
  • The RPCA satisfies the conditions of correctness, agreement, and utility, which allows the Ripple network to function as a fast and low-cost global payment network with well-understood security and reliability properties.
  • The RPCA is provably secure up to the bounds outlined in section 3, which, while not the strongest available in the literature for Asynchronous Byzantine consensus, do allow for rapid convergence and flexibility in network membership.

Decoding Solana (SOL) Whitepaper

Read Time:8 Minute
dark horizontal.c3a5eb36 Decoding Solana (SOL) Whitepaper
Decoding Solana (SOL) Whitepaper 6


  • The paper proposes a new blockchain architecture based on Proof of History (PoH) – a proof for verifying order and passage of time between events.
  • PoH is used to encode trustless passage of time into a ledger – an append only data structure.
  • When used alongside a consensus algorithm such as Proof of Work (PoW) or Proof of Stake (PoS), PoH can reduce messaging overhead in a Byzantine Fault Tolerant replicated state machine, resulting inn sub-second finality times.
  • The paper also proposes two algorithms that leverage the time keeping properties of the PoH ledger – a PoS algorithm that can recover from partitions of any size and an efficient streaming Proof of Replication (PoRep).
  • The combination of PoRep and PoH provides a defense against forgery of the ledger with respect to time (ordering) and storage.
  • The protocol is analyzed on a 1 gbps network, and the paper shows that throughput up to 710k transactions per second is possible with todays hardware.

Proof of History

  • Proof of History is a system for providing a sequence of hashes that can be used to record the order in which events have occurred.
  • The system can be used to verify that some piece of data was created before a particular hash index was generated.
  • The system can be scaled horizontally by synchronizing multiple Proof of History generators.
  • Clients can enforce consistency of the generated sequence by inserting the last observed output of the sequence they consider valid into their input.
  • The system is resistant to attacks by reversing the order of events or by generating a faster hidden sequence.

Proof of Stake Consensus

  • The purpose of the Proof of Stake algorithm is to provide quick confirmation of the current sequence produced by the Proof of History generator, for voting and selecting the next Proof of History generator, and for punishing any misbehaving validators. This algorithm depends on messages eventually arriving to all participating nodes within a certain timeout.
  • Bonds are equivalent to a capital expense in Proof of Work. A miner buys hardware and electricity, and commits it to a single branch in a Proof of Work blockchain. A bond is coin that the validator commits as collateral while they are validating transactions.
  • Slashing is the proposed solution to the nothing at stake problem in Proof of Stake systems. When a proof of voting for a different branch is published, that branch can destroy the validators bond. This is an economic incentive designed to discourage validators from confirming multiple branches.
  • A super majority is 2/3rds of the validators weighted by their bonds. A super majority vote indicates that the network has reached consensus, and at least 1/3rd of the network would have had to vote maliciously for this branch to be invalid. This would put the economic cost of an attack at 1/3rd of the market cap of the coin.
  • A bonding transaction takes a amount of coin and moves it to a bonding account under the users identity. Coins in the bonding account cannot be spent and have to remain in the account until the user removes them. The user can only remove stale coins that have timed out. Bonds are valid after super majority of the current stakeholders have confirmed the sequence.
  • It is anticipated that the Proof of History generator will be able to publish a signature of the state at a predefined period. Each bonded identity must confirm that signature by publishing their own signed signature of the state. The vote is a simple yes vote, without a no.
  • If super majority of the bonded identities have voted within a timeout, then this branch would be accepted as valid.
  • Missing N number of votes marks the coins as stale and no longer eligible for voting. The user can issue an unbonding transaction to remove them. N is a dynamic value based on the ratio of stale to active votes. N increases as the number of stale votes increases. In an event of a large network partition, this allows the larger branch to recover faster then the smaller branch.
  • Election for a new PoH generator occur when the PoH generator failure is detected. The validator with the largest voting power, or highest public key address if there is a tie is picked as the new PoH generator.
  • A super majority of confirmations are required on the new sequence. If the new leader fails before a super majority confirmations are available, the next highest validator is selected, and a new set of confirmations is required.
  • To switch votes, a validator needs to vote at a higher PoH sequence counter, and the new vote needs to contain the votes it wants to switch. Otherwise the second vote will be slashable. Vote switching is expected to be designed so that it can only occur at a height that does not have a super majority.
  • Once a PoH generator is established, a Secondary can be elected to take over the transactional processing duties. If a Secondary exists, it will be considered as the next leader during a Primary failure.
  • The platform is designed so that the Secondary becomes Primary and lower rank generators are promoted if an exception is detected or on a predefined schedule.
  • Forked Proof of History generator PoH generators are designed with an identity that signs the generated sequence. A fork can only occur in case the PoH generators identity has been compromised. A fork is detected because two different historical records have been published on the same PoH identity.
  • A network timeout would trigger an election.
  • Slashing occurs when a validator votes two separate sequences. A proof of malicious vote will remove the bonded coins from circulation and add them to the mining pool. A vote that includes a previous vote on a contending sequence is not eligible as proof of malicious voting. Instead of slashing the bonds, this vote removes remove the currently cast vote on the contending sequence.

Streaming Proof of Replication

  • Filecoin proposed a version of Proof of Replication in order to have fast and streaming verifications of Proof of Replication.
  • Replication is not used as a consensus algorithm, but is a useful tool to account for the cost of storing the blockchain history or state at a high availability.
  • To generate a proof, the key is used to seed a pseudorandom number generator that selects a random 32 bytes from each block.
  • A merkle hash is computed with the selected PoH hash prepended to the each slice.
  • The root is published, along with the key, and the selected hash that was generated.
    The replication node is required to publish another proof in N hashes as they are generated by Proof of History generator, where N is approximately 1/2 the time it takes to encrypt the data.
  • With N cores, each core can stream encryption for each identity.
  • Each core can then be used to generate all the proofs that derived from the current encrypted block.
  • Total time to verify proofs is expected to be equal to the time it takes to encrypt.
  • Keys are rotated periodically and each replication is re-encrypted with a new key that is tied to a unique Proof of History sequence.
  • Rotation needs to be slow enough that its practical to verify replication proofs on GPU hardware, which is slower per core than CPUs.
  • Hash is published at a periodic counter that is roughly equal to 1/2 the time it takes to encrypt the data set. Each replication identity must use the same hash, and use the signed result of the hash as the seed for byte selection, or the encryption key.
  • The period that each replicator must provide a proof must be smaller than the encryption time. Otherwise the replicator can stream the encryption and delete it for each proof.
  • A malicious generator could inject data into the sequence prior to this hash to generate a specific hash.
  • The Proof of History node is not expected to validate the submitted Proof of Replication proofs.
  • A proof is expected to be verified when the replicator is able to sign the proof by a super majority of the validators in the network.
  • A malicious user could create many replicator identities and spam the network with bad proofs.
  • A replicator node could attempt to partially erase some of the data to avoid storing the entire state.
  • A replicator identity that is colluding with the Proof of History generator could inject a specific transaction at the end of the sequence before the predefined hash for random byte selection is generated.
  • The cost of adding an additional replicator identity is expected to be equal to the cost of storage.
  • The cost of adding extra computational capacity to verify all the replicator identities is expected to be equal to the cost of a CPU or GPU core per replication identity.
  • This creates an opportunity for a denial of service attack on the network by creating a large number of valid replicator identities.

System Architecture

  • The Leader is an elected Proof of History generator. It consumes arbitrary user transactions and outputs a Proof of History sequence of all the transactions that guarantees a unique global order in the system.
  • After each batch of transactions, the Leader outputs a signature of the state that is the result of running the transactions in that order.
  • The Verifier nodes replicate the blockchain state and provide high availability of the blockchain state.
  • The Validators are virtual nodes that consume bandwidth from Verifiers.
  • The Leader is expected to be able to take incoming user packets, orders them the most efficient way possible, and sequences them into a Proof of History sequence that is published to downstream Verifiers.
  • On a 1gbps network connection, the maximum number of transactions possible is 1 gigabit per second / 176 bytes = 710k tps max.
  • A naive implementation of the state as a 50% full hashtable with 32 byte entries for each account, would theoretically fit 10 billion accounts into 640GB.
  • Smart contracts are a generalized form of transactions. These are programs that run on each node and modify the state.
  • In the above example, two different user programs call the same intrinsic. Each program is suspended until the batch execution of the intrinsics is complete.

Decoding Cardano (ADA) Whitepaper

Read Time:4 Minute
cardanologo 5bfc32b1c9e77c0026b65328 Decoding Cardano (ADA) Whitepaper
Decoding Cardano (ADA) Whitepaper 8


  • Cardano is a project that began in 2015 with the goal of changing the way cryptocurrencies are designed and developed.
  • The overall focus is on providing a more balanced and sustainable ecosystem that better accounts for the needs of its users.
  • Cardano embraces a collection of design principles, engineering best practices, and avenues for exploration.
  • The project has a long-term view on improving the design of cryptocurrencies.
  • Cardano is standards-driven and uses a dedicated foundation to lock down the final protocol design.
  • The project seeks to find a healthy middle ground for regulators to interact with cryptocurrency commerce.

Proof of Stake and Social Elements of Money

  • Cryptocurrencies are a prime example of the social component of money.
  • A large part of the value of a cryptocurrency is derived from its community, the way it uses the currency, and its level of engagement in the currency’s evolution.
  • Disagreements about philosophy, monetary policy, or even just between the core developers lead to fragmentation and forks.
  • Cardano will implement a system of overlay protocols built on top of CSL to accommodate the needs of its users.
  • Funding discussions force a relation of long and short term goals, the cryptocurrency’s social contract, priorities and the belief in value creation with particular proposals.
  • The use of formal methods, machine understandable specifications and merging a treasury with this process for financial incentives are being explored as possible avenues for inspiration.

Designing in Layers – Cardano Settlement Layer

  • When designing protocols and languages, one should look to history for inspiration, as many great ideas have been lost over time.
  • Simplicity usually wins over complexity.
  • Once a standard is set, it is likely to stick around, regardless of whether it is optimal.
  • Bad ideas can evolve into good ones if there is a will to do so.
    Cardano is a financial system that accepts its social nature.
  • Cardano’s design borrows from TCP/IP the concept of separation of concerns.
  • Blockchains are ultimately databases ordering facts and events with guarantees about timestamps and immutability.
  • Adding complex computation by storing and executing programs is an orthogonal concept.
  • It is incredibly tempting to choose the latter as Ethereum has done because it is more flexible, but it violates the design principles above.
  • Figuring out the story means that a single protocol has to be able to understand arbitrary events, script arbitrary transactions, permit arbitration in cases of fraud and even potentially reverse transactions when new information is made available.
  • Thus, we have chosen the position that the accounting of value should be separated from the story behind why the value was moved. In other words, separation of value from computation.
  • This separation does not mean that Cardano will not support smart contracts. On the contrary, by making the separation explicit, it permits significantly more flexibility in the design, use, privacy and execution of smart contracts.

Scripting – Sidechains – Signatures

  • Cardano is a cryptocurrency that is based upon Composing contracts, an adventure in financial engineering.
  • The primary advantage of Cardano is that security and execution can be extremely well understood.
  • Cardano will support a new protocol developed by Kiayias, Miller and Zindros (KMZ sidechains) based upon prior results from proofs of proofs of work.
  • In order to securely move value from Alice to Bob, Alice needs to prove she has the right to move the funds. The most direct and reliable way of accomplishing this task is to use a public key signature scheme where funds are connected to a public key and Alice controls an associated private key.
  • Cardano has been designed with special extensions that will allow us to add more signatures schemes through a soft fork.

Whats is the Point of All of it?

  • The main purpose of Cardano is to provide a vision for a self-evolving financial stack that can be used in jurisdictions where traditional banking systems are too expensive to deploy.
  • Cardano has been designed with feedback from hundreds of experts in the cryptocurrency industry, and it features tireless iteration, peer review, and the incorporation of great ideas from other projects.
  • Even if Cardano does not succeed in its ultimate goal, it can still make a significant impact on the way cryptocurrencies are designed, evolved, and funded.


  • The Cardano project is designed to create a reference library of Marketplace DAOs for smart contract developers to use.
  • The goal of the project is to promote decentralization and to encourage the community to participate in the governance of the protocol.
  • IOHK is working with a team of researchers from Lancaster University to develop a reference treasury model for Cardano.
  • IOHK is also working on a mechanism to formalize the process of proposing and vetting changes to the protocol.
  • Finally, work is being done to improve the incentives for Ouroboros, the proof-of-stake protocol used by Cardano.


  • Cardano is a cryptocurrency that is designed to be better than previous protocols.
  • The team behind Cardano has been careful to avoid cognitive biases, learn from history, and follow a rigorous process.
  • Cardano is meant to be a digital embodiment of the evolutionary process, able to adapt to changing needs.
  • The goal of Cardano is to be a pragmatic dreamer that is a good citizen in its community and always finds a way to pay its bills.