From an outsider's perspective, tokens are a way for Sam to take from you to give to Caroline. But under the hood, this question prompted curiosity: an approach to seeing tokens from a first-principles lens. Channeling my inner Ted Lasso, I thought it might be time for me to “be curious, not judgmental” regarding these cryptocurrencies.

When I started investing in the space, I did not have an insightful answer to this question. I viewed tokens as a mechanism of protocol ownership, as one would view public company shares. This knee-jerk understanding of tokens shifted over time, but few explicitly stated the “so-what” behind these now-demonized tools for decentralization.

Through the Scam Coin era of 2020–21, there’s been a proliferation of Web3 tokens for the sake of rug pulls, scams, and get-rich-quick-schemes. This has been bad for the industry: the original purpose of tokens in decentralized protocols diverged from its bull market use case. The hope is that this article provides a framework for investment scrutiny of tokens peddled or shilled to the public, or worse, Crypto Twitter.

This essay is my attempt at having a curious, open-minded understanding of a token’s role in Web3.

I. Introduction and Background

Cryptocurrencies, Explained

Cryptocurrencies, or tokens, are atomic digital currencies used as a medium of exchange through a decentralized computer network. Bitcoin and Ethereum are decentralized computer networks, meaning they are run as a collective rather than by a centralized entity or institution. Each network has the characteristic of being open and permissionless: anyone can download the software required to run an instance of each network and participate in validating transactions. This is the meaning behind the phrase “run by a collective” — the code verifies transactions, and the people running and maintaining the code (node operators, as they are called) come to a consensus on all valid transactions. Each network has its own digital currency, which acts as the atomic unit for that network; in this case, it’s BTC for Bitcoin and Ether for Ethereum.

As we’ve previously covered here, tokens are derived and built through a few lines of computer code called smart contracts, which are then executed and run on a decentralized network.

Computer networks like Ethereum allow users to build tokens atop its blockchain, whereas Bitcoin does not. Before Ethereum, individuals or projects had to create a separate and unique blockchain to issue a new cryptocurrency. The Ethereum ERC-20 standard enabled anyone with access to a computer to spin up their attempt at digital alchemy on Ethereum without reinventing a new blockchain network. This standard led to the Initial Coin Offering (ICO) boom of 2017.

To show you how easy it is to start an ERC-20 token, I decided to ask ChatGPT to write me the code to launch an ERC-20 token contract:

pragma solidity ^0.5.0;

import "https://github.com/OpenZeppelin/openzeppelin-solidity/contracts/token/ERC20/SafeERC20.sol";
contract MyToken is SafeERC20 {
    // Public variables of the token
    string public name;
    string public symbol;
    uint8 public decimals;
    uint public totalSupply;
    // This creates an array with all balances
    mapping (address => uint) public balanceOf;
    // This generates a public event on the blockchain that will notify clients
    event Transfer(address indexed from, address indexed to, uint value);
    // Constructor function
    constructor(uint initialSupply, string memory tokenName, string memory tokenSymbol, uint8 decimalUnits) public {
        balanceOf[msg.sender] = initialSupply;             
         // Give the creator all initial tokens
        totalSupply = initialSupply;                        
        // Update total supply
        name = tokenName;                                   
        // Set the name for display purposes
        symbol = tokenSymbol;                               
        // Set the symbol for display purposes
        decimals = decimalUnits;                            
        // Amount of decimals for display purposes
    }
    // Send coins function
    function transfer(address _to, uint _value) public {
        require(balanceOf[msg.sender] >= _value && _value > 0);
        balanceOf[msg.sender] -= _value;                    
        // Subtract from the sender
        balanceOf[_to] += _value;                           
        // Add the same to the recipient
        emit Transfer(msg.sender, _to, _value);             
        // Notify anyone listening that this transfer took place
    }
}

Impressive, huh?

Armed with these tokens, individuals can take partial ownership of a decentralized computer network. Because of the blockchain, all the nodes in the network maintain the same record of who owns which tokens and in what amount, along with the transfer record since inception. Hence the moniker, decentralized ledger. As you’ll recall, a node is a computer linked to a blockchain network that assists in producing, receiving, and moving data, which is what makes a blockchain stateful (e.g., able to record/remember transactions).

As you’ve seen from the code block, the smart contract defines the rights a token holder receives, such as the ability to send and receive tokens from and to their Web3 wallets.

Tokens and Their Analog Parallels

Tokens are not a new concept. Tokens in Web3 reflect many analog world counterparts: gift cards, ID cards, airline points, and club memberships. Even fiat money can be an extension of the token definition.

The main underlying difference has to do with issuance. For many of the aforementioned examples, the tokens’ allocation, distribution, and maintenance rely on a centralized intermediary to ensure validity and maintain the permissions they afford. Though not issued by a centralized institution, cryptographic tokens, by contrast, have their validity upheld through code, forming the basis of trust in code. Whereas confidence in a club membership “token” stems from that club’s financial stability and physical structure, assets, and quality therein, a cryptographic token’s validity is based on the code in its smart contract and maintains its records through the network’s distributed ledger and consensus mechanism.

To summarize, tokens are nothing new. What’s new is how the authenticity of those tokens is represented: through a decentralized computer network that records to a distributed ledger.

Cryptographic Tokens, Explored

Cryptographic tokens have all the qualities of general tokens (gift cards, ID cards, memberships, among others) people have interacted with before. They can provide access rights to property or public services (using the Bitcoin network to send payments to recipients abroad) or private (using an NFC-digital wallet card to enter into an Airbnb). The tokens' roles vary based on the specifications encoded in the smart contract.

As we’ve covered in What’s In Your (Web3) Wallet, tokens aren’t held in an individual’s crypto wallet. They are not digital files stored locally but entries on ledgers that map (point) to a particular blockchain address. The token holder’s identity is recorded through their wallet’s public key rather than physically possessing those tokens in their wallet.

To extend this example, if in this wallet we have a token that represents a ticket to a Broadway show, the owner of the owner would be able to sign a transaction with the private key transferring ownership to another individual if that capacity was encoded in the token’s smart contract. The functionality of the token, though owned by an individual, is dependent on the function the code enabled.

The example above illustrates a core component of tokens: a token's function depends on its code. This is significant because it opens the framework for assessing the function of other tokens. Take, for example, the Ethereum token standard ERC-721. These are non-fungible tokens or NFTs. Whereas ERC-20 tokens are infinitely tradable, as in the case of one dollar for another dollar or ten one-dollar bills for two five-dollar bills, NFTs are unique. While an ERC-20 token acts like a fungible good, an ERC-721 token acts like a non-divisible asset representing a finite and limited digital good.

Today, NFTs represent digital collectibles, cultures, and tribes. The ERC-721 standard implies that this code set can enable more complex digital assets ranging from representing identities to voting rights in elections. The extended use cases enabled by code take tokens beyond a means to incentive participation to secure a network or merely the exchange of value between two parties.

Tokens can represent non-tradable digital assets, known as soul-bound tokens or EIP-5484. These tokens would be a particular type of NFT that cannot be transferred. In other words, the ownership would be immutable. This is a unique improvement in tokens: we can now codify digital identity, reputation, and characteristics in an independently verified, non-transferable, and permanent manner. I cover a framework for building out a decentralized identity system here.

Tokens, Summarized

Thus far, we’ve covered the “what” behind tokens. We’ve analyzed how “easy” it can be to launch a token (thanks, ChatGPT ), which is why we have seen a proliferation of these internet coins over the last 36 months, many with the purpose of trading, speculating, and demonstrating the greater-fool-theory. We’ve covered the technological primitives behind these tokens, ranging from the fungibility of ERC-20 tokens, the non-fungibility and uniqueness inherent in ERC-721 tokens, and the potential for new identity systems and reputation to be captured through soul-bound tokens.

The next logical step of exploration is understanding the “why” behind these token features of a blockchain. Token usage as a means to safeguard and incentivize cooperation and maintenance of a decentralized network was covered earlier in Securing The Network with Proof of Work. The following section acts as an extension of that essay, seeking to clarify the usage of tokens for decentralized applications.

With that, let’s dive in.

II. The Purpose of Tokens in Decentralized Applications

History Of Open Source Systems and the Emergence of Read-Write-Own

Tokens represent a unique innovation for cultivating ownership and social coordination across software developers, contributors, and users. A protocol refers to the set of rules that computers of a network use to communicate with one another. A protocol is defined in the context of open-source systems; open-source refers to software that is free to use, study, modify, and distribute for any purpose. This is in contrast to closed-source or proprietary code, in which the code represents intangible, proprietary assets, as in the case of Tesla’s self-driving code or Google’s ranking algorithm.

For background, the modern internet was built and predicated on many open-source systems that govern standardization:

• HyperText Transfer Protocol (HTTP): used for accessing and receiving HTML files

• Simple Mail Transfer Protocol (SMTP): used for transferring e-mail between computers

• Transmission Control Protocol and Internet Protocol (TCP/IP): TCP ensures a reliable internet connection while checking for errors / IP tells information packets (collection of data) what their destination is and how to get there (through a web of links)

These open-source protocols created the foundation for the free and modern internet we experience today.

At the time the consumer-versions of the Internet came to fruition in the late 1980s/early 1990s, there was an array of competition between protocols jostling to become the “default,” similar to the proliferation of Layer 1 blockchains, each vying for developer and user attention.

When Web 2.0 began to take shape in the early to mid-2000s, many centralized intermediaries took advantage of what these protocols enabled to create winner-take-all platforms, as in the case of Google being the canonical search engine to the point where its name has emerged as a verb.

Web 1.0 became a prime target for rent extraction given its statelessness — its inability to keep a record of activities. The durability of business models didn’t emerge until Web 2.0 companies enabled “statefulness” for the internet built upon these free and open protocols. They took much of the value accrual for facilitating this innovation, as in the case of Meta being able to upload all your photos of your recent vacation or Shopify updating your shopping cart after you add an item.

In the axiom of Web 1.0 being read-only, Web 2.0 became read-write as producing, contributing, and distributing content reached a marginal cost of zero.

Web 3.0 is the next layer of innovation that will allow for a user to have a more thoughtful experience with the internet: one that isn’t defined or curated by a select few of legacy service providers. While Web 1.0 was oriented toward being free and open source, Web 3.0 ushers in a social coordination and incentive mechanism that is token-driven and open source. It creates a system of network ownership and shared incentives. This is one of the critical features of Web 3.0 that cultivates the read-write-own paradigm.

This is significant because tokens allow for a decentralized business model for protocols that weren’t possible prior. For the first time, software code was able to codify digital scarcity and authenticity. That was the core innovation that the Bitcoin Whitepaper introduced: the ability for a group of people to create digital scarcity in a socially-maintained and applied mechanism-design theory. In other words, safeguards were coded such that a participant could not double-spend tokens. Attempts at creating digital money with a centralized intermediary were attempted prior, but for the first time, a group of people could “trust in code” absent a centralized institution. If they tried to double-spend or alter the consensus-determined state of the record, punishments were so severe that the benefits of trying to lie/cheat even more punitive than it’s potential gain to discourage dishonest behavior.

Web 3.0 offers the potential for a renewed internet experience, just as the internet protocols of Web 1.0 faced when introduced to the developer community; there is always a cold-start problem in upstart marketplaces (e.g., how valuable is an Uber with no drivers or an eBay with no sellers)?

III. The Why Behind Tokens — An Answer to a Decentralized Cold-Start Problem

Cold start problems are the forces that make starting a competitor to Facebook or Uber complex and costly. It has to do with winner-take-all dynamics supported by Metcalfe’s law: “the value of a network is proportional to the square of the number of connected users of the system.” Therefore, the more people that use a network, the more valuable it becomes and the more challenging it is for a competitor to create a wedge and survive.

Web3 protocols are no different than the marketplaces (e.g., matching drivers and riders, writers and readers, buyers and sellers, etc.) we see in Web2, but they are run differently. While the Uber of today may charge drivers 30% of the ride cost and offer them no upside through stock ownership, a Web3 Uber could redefine who accrues the value of each ride, determined by all network users. The issue with developing a “decentralized Uber for X” today is that a protocol needs users. For consumers, the philosophical benefit of Web3 doesn’t outweigh the convenience and UI/UX of using entrenched, centralized incumbents — a barrier of convenient complacency.

A solution to start an initial community base is to give these early adopters ownership in the protocol, incentivizing adoption and their early contributions to the protocol. This ownership comes in the form of a digitally scarce good tied to the use of the network, which for Web3, is a cryptographic token or cryptocurrency. A token acts as a conduit for early adopters to be rewarded with something beyond the pride of being first: there may be price appreciation or rewards down the line. While this may sound farfetched, this is how Bitcoin incentivized early miners when there was no broad use case for BTC beyond a social experiment around a decentralized P2P payment network. Tokens, in this case, help address the cold-start problem inherent in new networks.

Therefore, the shift from Web2 to Web3 is fundamental and philosophical. Whereas a centralized intermediary would extract rent from creating, maintaining, and growing a marketplace or internet tool, a Web3 protocol replaces the centralized intermediary with transparent, user-driven coordination in which early contributors and builders benefit from a network’s use, popularity and utility through distributed token ownership. The network usage increases with this shift, and the network effects grow and deepen as users become owners of the network with potential value accrual: fee streams charged by these protocols are then redistributed or shared with their users. This is a fundamental shift from how the value is extracted today from Web 2.0 counterparts.

While there is a hint of speculation inherent in seeing a token appreciate for the sake of being early, there are additional features within a distributed system that aren’t possible in Web 2. One example is a hedge against the typical bait-and-switch policies seen through Web 2. When services like Facebook first started, the novelty and utility of staying connected created a meaningful experience for many first-time users, an actual utility. But once Facebook hit a critical mass of users, policies shifted to support ad-driven experiences. The goal became less of keeping people connected meaningfully and instead optimized for screen time (e.g., ad exposure) they could extract from a user’s day. These bait-and-switch tactics are at the core of concern regarding a lack of transparency and voice in how these policies may affect early and current users.

In Web3, the bait-and-switch tactics are less possible. A protocol’s token puts skin in the game for all stakeholders, aligning incentives through utility and the policies guiding a protocol’s evolution. However, the beauty of Web 3’s open architecture is that if users, in part or whole, disagree with a protocol’s direction, a group can “fork” (copy and paste) the code and recreate the protocol that best aligns with their values and expectations. I’ve written about protocol forks here.

The internet experience moves from a passive one to an active one in Web 3.

Decentralized Business Models

A common retort is that Web3 protocols, being that they are open-source, are easily forked and, therefore, can’t possess any business durability. No “trade secrets” or “IPs” protect a protocol from being copied and pasted.

This retort has validity a first glance. But the rebuttal is simple: marketplaces. An alternative to eBay or Uber would possess defensibility from network effects. Fee streams and delightful user experience in matching the goods and services of one group with the demands and preferences of another embed user lock-in. Conversely, with open source, there is a critical delineation between **open **source code libraries, which anyone with access to the internet to view, copy, and use, and the networks from which that code enables.

Only when the code is utilized, along with memes of production, is durability brought to life through a protocol and its community.

It’s important to note that the same components that make a traditional Web2 company durable, as in the case of Microsoft, are the same elements at play for open-source networks in Web3.

These features entrench existing players, building upon the network effects and generating defacto product lock-in. Take branding: Web3 protocols can share mind space as they establish a strong reputation, a loyal customer base assuming a delightful user experience and protocol utility, and offering services that would be hard to replicate. To expand on the last point, many of the services that make Web3 protocols useful are based on interoperability between services. These relationships are intangible, often cultivated offline, and consummated through code. These “integrations” with other services create their defensibility because a fork cannot simply copy over the “human element” to build a brand. Additionally, many of the protocols that have survived through bear cycles (e.g, post-2017 and post-2021) achieve early steps toward a Lindy Effect: the idea that the future life expectancy of some non-perishable is proportional to its current age, meaning that each additional period of survival implies longer remaining life expectancy. Assuming it is a decentralized protocol and not a centralized entity like FTX/Celsius/Voyager/BlockFi, the more time a protocol has been in the market, the longer you can expect it to be. The product ingredients entrench existing players, build upon the network effects, and generate switching costs.

Progressive Decentralization as a Framework

IV. Challenges and Straying Further From The Truth

The primary purpose of a token, primarily as it exists for a decentralized application (dApp), is to achieve progressive decentralization of that dApp. The goal of a token shouldn’t be to launch it to the public, with the expectation that insiders (founders, advisors, and early investors) sell token shares purchased at a significant discount to “dump on retail.” Unfortunately, that’s been the modus operandi for Web3, which offers validity to the distaste prudent, traditional investors have for the space.

The point of the token is progressive decentralization.

If we operate under the assumption that the “hero” of a protocol isn’t the code but rather the community, then building a framework that allows the protocol to be maintained, improved, and governed by the community serves to create and serve the “greater good.” This means that teams, initially, should be small and focused on building value-driven, delightful-to-use protocols while slowly and deliberately creating mechanisms to bring the community into the planning and execution process, from which the protocol’s tokens can be used to incentive these early adopters. Over these small iterations, the founding team is soon no longer the hero of the story but evolves into the role of the initial catalyst. Just as the Constitution allowed the US to operate in a framework of principles over the last 200 years, absent additional influence or changes from its writers, Web3 protocols can offer the same experience to early users and create long-term, principle-driven buy-in using tokens to decentralized ownership.

V. Conclusion

Tokens have diverged from their social coordination use-case and since evolved into unregistered securities, and quick pathways for insiders (teams, early investors, exchanges) to quickly market (pump) and sell (dump) to retail for the sake of making a quick buck. A terrible product, a horrendous user experience, and a solution in search of a problem became the expected norm. This became the prevalent outsider view. As a professional investor in the space, it was hard to watch and even harder to avoid participating in the cash grab that was the last bull market.

But returning to this hard-won, fundamental perspective in the why and how behind tokens provided the filter necessary not to be caught swimming naked when the tide went out.

Tokens are crucial in driving early adoption and achieving progressive decentralization on protocols that redefine how humans interact and experience the internet. Tokens are niche and controversial — they will be seen as a breakthrough in the proliferation of open networks, combining the social good of open protocols with the financial benefits of proprietary networks. They are the pathway towards a decentralized future and a tool that, if used correctly, can accelerate our ability to find more meaningful interactions with each other through the Internet.

Sources:

“Continuations by Albert Wenger : Crypto Tokens and the Coming Age of Protocol…” Tumblr, 28 July 2016, https://continuations.com/post/148098927445/crypto-tokens-and-the-age-of-protocol-innovation.

Dixon, Chris. “Crypto Tokens: A Breakthrough in Open Network Design | by Chris Dixon | Medium.” Medium, Medium, 1 June 2017, https://medium.com/@cdixon/crypto-tokens-a-breakthrough-in-open-network-design-e600975be2ef.

Ehrsam, Fred. “Blockchain Tokens and the Dawn of the Decentralized Business Model | by Fred Ehrsam | The Coinbase Blog | Medium.” Medium, The Coinbase Blog, 1 Aug. 2016, https://medium.com/the-coinbase-blog/app-coins-and-the-dawn-of-the-decentralized-business-model-8b8c951e734f.

“Soulbound.” Vitalik Buterin’s Website, https://vitalik.ca/general/2022/01/26/soulbound.html. Accessed 3 Feb. 2023.

Tomaino, Nick. “Cryptoeconomics 101. Much Has Been Discussed About… | by Nick Tomaino | The Control.” Medium, The Control, 4 June 2017, https://thecontrol.co/cryptoeconomics-101-e5c883e9a8ff.

— -. “On Token Value. Millions of New People Have Entered The… | by Nick Tomaino | The Control.” Medium, The Control, 6 Aug. 2017, https://thecontrol.co/on-token-value-e61b10b6175e.

— -. “Our Process for Evaluating New Tokens | by Nick Tomaino | The Control.” Medium, The Control, 8 Jan. 2018, https://thecontrol.co/our-process-for-evaluating-new-tokens-4627ed97f500.

— -. “Tokens, Tokens and More Tokens. Over $331M Has Been Raised in Token… | by Nick Tomaino | The Control.” Medium, The Control, 1 May 2017, https://thecontrol.co/tokens-tokens-and-more-tokens-d4b177fbb443.

Voshmgir, Shermin. Token Economy. Token Kitchen, 2020.

Walden, Jesse. “Crypto’s Business Model and Who Benefits From It | Future.” Future, 8 Apr. 2020, https://future.com/crypto-business-model/.

Part II goes deeper into smart contracts. In this article, we evaluate features of smart contracts, namely immutability, and report a mechanism to work around editing and amending contracts. The second half of the article lists some of the most common vulnerabilities of smart contracts across the “deployment stack.” There’s also a fun appendix that outlines the smart contract lifecycle and how it is compiled into the Ethereum running environment.

With that, let’s check out Part II.

Part I, How Can We Amend an Immutable Smart Contract?

Do we want immutability?

“The best thing about us is often the worst, too.” This applies well to the features that accompany smart contracts: transparency, permissionlessness, and immutability. Choosing to focus on the final point, it’s hard to see why anyone would want to engage in an agreement that doesn’t allow for last-minute amendments or changes. This is a critical shortcoming of smart contracts. Modifying a smart contract after deployment can be more costly and technically challenging than leveraging traditional lawyers to write a text-based contract.

While addressing this concern is critical, it’s worth noting that there are mechanisms in place to change smart contracts after deployment. This is particularly valuable in the case of a hack, which for whatever reason, crypto has no shortage of :)

Immutability becomes less so through a concept explained by Preethi Kasireddy. It’s duly called a backdoor approach. It was first proposed by OpenZeppelin, one of the premier smart contract auditors.

To create a backdoor in a smart contract, a programmer needs to create two separate smart contracts: a proxy contract and a logic contract. In this setup, a user would only interact with the proxy contract. When a user initiates a smart contract, a function (set of instructions) is “called” by the user, passing along the expected and required inputs. In turn, the proxy contract would then delegate, or pass along, those parameters to the logic contract. The logic contract is what contains the executable instructions that update the state of the blockchain. The data from the logic contract would then make its way back to the proxy contract, which would then return some output or outcome to the users as desired.

How is this a backdoor? Since you can call a smart contract from another, you can always change which logic contract is called in the proxy contract. The only change is which logic contract is being called (e.g., logic contract v1 vs. logic contract v2).

With this functionality in place, one would have the ability to “update” and amend a seemingly immutable smart contract since only the proxy contract is the interface with which a set of users or participants in an agreement engage. Additional details for how a proxy contract can call upon different logic contracts are beyond the scope of this essay but can be found here.

Part II, Smart Contract Vulnerabilities

A smart contract is a bit of a misnomer: a smart contract is only as smart as those who code it. To give you a quick example of how smart our smart contract coders are today, it would only be fair that I show some major hacks courtesy of our friends from REKT. Some quick examples are here, here, here, here, and here, too.

When approaching smart contracts through a first-principles lens, we need to be transparent about the vulnerabilities. I tried to explain some of these vulnerabilities in plain English, along with links to a more thorough analysis, in the hopes that the next time a hack occurs, you can have some idea of why and how it happened.

From a high level, though, naive builders will always be a target for fraud. There’s not much you can do to get around it. Assuming a developer didn’t implement a backdoor approach as discussed in Part III, there’s often no recourse. Vulnerabilities and behavior testing must be a necessity for these groups to build businesses on the backs of smart contracts. Given the lack of standardization around vulnerability testing, it is difficult for the industry to identify, categorize, and analyze these vulnerabilities before they happen.

With that, let’s dive in.

What are the major smart contract vulnerabilities?

We will analyze smart contract vulnerabilities across three different levels:

1. Solidity (how code is written)

2. Ethereum Virtual Machine (where code is compiled)

3. Blockchain (how code changes the state of a distributed ledger)

The list below is by no means exhaustive, but it provides proper context as to just how complex identifying these vulnerabilities can be.

Solidity Level

Re-entrancy

• A reentrancy attack occurs between two smart contracts, A and B, where an attacking smart contract exploits the code in a vulnerable contract to drain it of its funds. This is accomplished by having the attacking smart contract repeatedly call the withdraw function before the vulnerable smart contract has had time to update the balance.

• An example is a bank teller who doesn’t update your balance until you are finished with all the money requests you make. You consistently withdraw $1,000 repeatedly, but your account balance never updates until you finish all your requests.

• Example: The DAO Attack

Arithmetic Issues

• Due to the lack of floating-point support (think long decimals after a whole number), smart contracts generally represent values as integers. Using whole numbers to represent values requires reducing the value to a smaller unit to allow sufficient precision.

• An example is an integer overflow. Computers, for example, have a maximum value of integers that can be calculated. When the max value is reached, the computer returns to the starting point, typically the minimum value. This opens up a vulnerability as follows: if a person (or program) tries to subtract 5 from 3 in an unsigned integer (these a positive, whole numbers), it will cause an overflow error. The outcome is an output of a very large number outside the scope of a program’s range, leading to a potential exploit.

• An example is a token holder with 5 ether but attempts to spend 6 ether. If the contract doesn’t check for this, the attack might be allowed to spend more tokens than originally possessed.

• Example: The PoWH Coin

Self-Destruct Function

• This function is used to delete a smart contract from a blockchain. The manner is by removing all bytecode (the instructions for the virtual machine to execute) from the contract address, then sending all the ether stored in the contract to a different designated address. This operation saves on gas and is an excellent mechanism to stop a deployed smart contract, especially when utilized with multisig authorization.

• An example is when an attacker changes the deployed self-destruct address to their own address, usually through a vulnerability where the smart contract library is stored, then triggers the self-destruct function. This allows them to take full custody of ether still in the contract.

• Example: Parity Bug

External Contract Referencing

• Because smart contracts are open-source and public on the blockchain, other contracts can call them. This is part of a smart contract’s composability, which is often described as programming Lego pieces. This tends to be safe from a code audit perspective, however, if a malicious actor were to change an address from a smart contract’s library, a security hole is created. A malicious actor can then create a new smart contract, dubbed a honey pot, and use that same address to mask malicious code. This malicious code could then exploit others that call the original contract.

• Example: Honey Pot – Reddit Post

Ethereum Virtual Machine

Short address/parameter issues

• The parameters of smart contract functions are converted into code before passing the data to the Ethereum virtual machine (EVM). The encoded parameters are 32 bytes, and the EVM will concatenate all the encoded parameters together. If a smart contract received some parameters shorter than 32 bytes, the EVM tries to fill the missing bytes with zeros. If the inputs are not later validated, these added zeros are considered valid inputs, which open vulnerabilities and execution of data that is not expected.

Freezing ether (greedy contract/locked money)

• A smart contract is designed to be able to send and receive ether. A freezing-ether situation is a contract that could only receive Ether but has no means to send Ether out. A contract can be greedy, and ether sent to its address is frozen if there are no defined withdraw functions.

Blockchain

Transaction order dependence

• Transactions change the blockchain state from one to another. The state of contracts depends on the order that transactions are executed. An Ethereum miner typically decides the execution order. This non-deterministic feature of execution can make it difficult for an actor to forecast the state before transactions are submitted. With limited knowledge on how a state change can occur between blocks, submitted transactions with shifted transaction orders can cause buying or selling items at unexpected prices. An example of this is frontrunning, in which observers of pending transactions (viewable in the mempool) can see and react to an action before it is included in a block.

• Note: an equivalent in traditional finance markets is Payment For Order Flow (PFOF), which isn’t technically a vulnerability.

• Example: Bancor Frontrunning

Generating Randomness

• Generating randomness is difficult for many programming languages. The current practice is usually leveraged by the function block.timestamp. If a historical blocks’ timestamp is used, attackers can use the same random number-generation process to obtain the same result because historical blocks never change,

• Example: Predicting Random Numbers

Conclusion

As we move away from a centralized internet to a decentralized one, smart contracts will be one of the most important tools for humans to be at the crux of peer-to-peer interaction. The internet will reform itself to one of human interaction creating the highest value, as opposed to machine interaction. This two-part article analyzed why smart contracts are important to this shift, how they are behind used today, how immutability as a feature is as much a strength as it is a weakness and provided a keen understanding of some of the most common vulnerabilities in smart contracts.

The appendix below contains a deeper dive into the details for smart contract components, known as Ethereum accounts, and reviews the life cycle of a smart contract’s development. If those topics interest you, I welcome you to read further.

Appendix: Technical Background - How Smart Contracts Run on Ethereum

Ethereum Accounts

The basic element behind Ethereum are accounts, which is otherwise known as account states. Each account typically has four data fields:

1. Nonce – the transaction counter

2. Balance – amount of ether the account possesses

3. Storage – memory space for code and its execution

4. Code – where a smart contract is stored

Within accounts, there are two types: external accounts and contract accounts. External accounts are controlled by private-key pairs. These accounts can alter the state of the blockchain through a transaction, which after execution, is broadcasted to the entire blockchain. These transactions are not free and require a gas fee paid in ether. Assuming this gas fee is paid, a miner would need to choose to pick up a transaction from the mempool (the pending transactions), execute it, then propagate that state change to the rest of the network. The gas fee compensates the miner for this work.

The second type is contract accounts. These are smart contracts deployed to the Ethereum network and are controlled by the code, which is why there is no need for a private key pair. Some key differences between these accounts are that external accounts are free to create, whereas control accounts require a gas fee because the code takes up network storage. Contract accounts are also input-only contracts, meaning that they can only send transactions after having received an initiated transaction.

Life Cycle of Smart Contracts

A smart contract is written using Solidity, a Turing-complete, JavaScript-like language. Once a contract is written, it can be deployed to the network. A developer could initiate a transaction, pass along the proper input data, and instruct the contract to compile corresponding code as bytecodes, the readable input for an Ethereum Virtual Machine (EVM). This action would return a different code fragment stored in the EVM running environment to be executed when a smart contract is called. During execution, a deployed smart contract will receive input data from transactions that call the smart contract. The EVM will execute the instructions from the smart contract’s code until the program is finished running, or it runs out of gas. Execution occurs when a new block is minted on the Ethereum blockchain. The final stage is completion, in which states are updated, and the transaction is stored on the blockchain.

Ethereum Running Environment

Blockchain blocks, the Ethereum Virtual Machine, and smart contract codes together make up the running environment for Ethereum. The block mining process identifies legitimate transactions and combines the corresponding state’s change into a new block. A miner will pick the transactions that they want to include onto their block from a mempool, execute the codes within the smart contracts, update the state, calculate the nonce (proof of work), and attach the newly minted block onto the previous block on the blockchain before broadcasting the state change to the rest of the network.

Special thanks to Zoe Enright and Sam Wheeler for their help on this post.

References:

“Aave and Flash Loans.” Gemini, https://www.gemini.com/cryptopedia/aave-flashloans. Accessed 25 Sept. 2022.

Konstantopoulos, Georgios. “How to Secure Your Smart Contracts: 6 Solidity Vulnerabilities and How to Avoid Them (Part 1).” Loom Network, 6 Feb. 2020, https://medium.com/loom-network/how-to-secure-your-smart-contracts-6-solidity-vulnerabilities-and-how-to-avoid-them-part-1-c33048d4d17d.

“Learn Hub.” Ethereum.Org, https://ethereum.org. Accessed 25 Sept. 2022.

Lipton, Alex, and Stuart Levi. “An Introduction to Smart Contracts and Their Potential and Inherent Limitations.” The Harvard Law School Forum on Corporate Governance, 26 May 2018, https://corpgov.law.harvard.edu/2018/05/26/an-introduction-to-smart-contracts-and-their-potential-and-inherent-limitations/.

Monolith. “TKN and Short Address Attack Mitigation:” Monolith, 31 Oct. 2018, https://medium.com/monolith/tkn-and-short-address-attack-mitigation-88cc895734ba.

“Real World Examples of Smart Contracts.” Gemini, https://www.gemini.com/cryptopedia/smart-contract-examples-smart-contract-use-cases. Accessed 25 Sept. 2022.

Smart Contracts 101 - What to Know & Where to Start - Wharton | Wharton - Economics of Blockchain and Digital Assets. https://www.web3.wharton.upenn.edu/blog/smart-contracts-101-what-to-know-where-to-start-wharton. Accessed 25 Sept. 2022.

Valaitis, Alex. “A Deep Dive on Chainlink.” Web3 Pills by Alex Valaitis, 28 July 2022, https://web3pills.substack.com/p/a-deep-dive-on-chainlink.

Voshmgir, Shermin. Token Economy: How Blockchains and Smart Contracts Revolutionize the Economy. 1st edition, 2nd amended printing, BlockchainHub, 2019.

Zhou, Haozhe, et al. “The State of Ethereum Smart Contracts Security: Vulnerabilities, Countermeasures, and Tool Support.” Journal of Cybersecurity and Privacy, vol. 2, no. 2, May 2022, pp. 358–78. DOI.org (Crossref), https://doi.org/10.3390/jcp2020019.

Let’s chat about (not so) smart contracts. A key theme we’ve analyzed is that the original internet was optimized for communication between machines as opposed to people. Web3 changes that. Smart contracts are part of the “how” that enables this change: they change how we can transact on the internet without the friction of an intermediary.

This is a two-part article. Part one analyzes what a smart contract is and why it matters for enabling the future of the internet. Secondly, the article looks deeper at the early use cases for smart contracts today, ranging from decentralized finance to tokenizing real-world assets.

Part II of this article, to be published later this week, evaluates features of smart contracts, namely immutability, and reports a mechanism to work around editing and amending contracts. Lastly, the article lists some of the most common vulnerabilities of smart contracts across the “deployment stack.” There’s also a fun appendix that outlines the smart contract lifecycle and how it is compiled into the Ethereum running environment.

With that, let’s ride.

Part I, Foundation

What are smart contracts, and why do they matter? A smart contract is a coded agreement stored and executed on a blockchain. These agreements are the backbone to Web3 enabling a native settlement layer on the internet. To show why this matters, let’s revisit a previous example:

eBay, in the early 2000s, had an incredible marketplace coordination problem. Before Paypal, eBay would pass along coordination of goods exchange to the buyer and seller:

After a successful auction, the buyer had to mail a check to a buyer physically, and the seller would then have to trust that a check would clear. The buyer would then have to trust the seller’s reputation to ship the product described in the listing.

Described succinctly, conducting commerce of any type on the internet incurred friction. Unknown actors had to solve the coordination problem themselves, as Web 1.0 companies could only facilitate the match up to the point.

To create a hack for this coordination problem, Web 2.0 intermediaries presented themselves as trusted third parties to help facilitate transactions and reduce friction. Now, users didn’t have to place trust in the other party, so long as they trusted Visa or PayPal to manage the reputations of their user base. It doesn’t take too much effort to conclude that many of the agreements we reach over the internet can’t be met with an intermediary.

The need for trusted intermediaries paved the way for smart contracts - they address the “how” portion of achieving a settlement layer on the Internet. Smart contracts are used to formalize and execute agreements between unknown participants through code, as opposed to through an intermediary (like PayPal in the previous example). In using code, these smart contracts reduce the cost (and in the future, friction) of enforcing an agreement between two parties.

So, how does a smart contract work? A smart contract is like a coin laundry machine. The rules of what can be done with the laundry machine are pre-programmed in code and executed by the machine. A user selects the wash options offered by the laundry machine, and the machine, in turn, requests payment via coins. Once payment is made by the user, the machine is programmed to run the options selected by the user. If a user does not input enough money, the machine wouldn’t run the selected option, and the user would be able to receive their coins back. Coin laundry provides continuous availability of its service to users without the requirement of an operator or middleman to broker and settle the service.

Using this simple example as a starting point, we can expand smart contracts further.

A smart contract is a self-enforcing agreement formalized as code through a set of conditional if-then statements between two or more parties. The code reflects a set of rules that all parties must agree with to interact with one another. Since smart contracts are public and stored on the blockchain, anyone can view the business logic coded within. When the rules or conditions are met, as in the case of inputting an adequate amount of money in the laundry machine, the agreement is automatically executed. The “state” change (i.e. clothes being washed, and a lower coin balance for the washer) resulting from the smart contract is then recorded on the blockchain.

Smart contracts stored on the blockchain allow for some unique features: they are immutable (changeless), irrevocable, and executable. However, given that smart contracts can’t be changed, there are vulnerabilities from errors or edge cases that smart contract developers may not foresee or hedge. We get into ways around this, as well as some vulnerabilities that smart contracts inherit.

High Level Applications

Smart contracts have far-reaching applications. Use cases range across industries and sectors, which is why input from a broad range of domain experts and participants is required to bring these contracts more mainstream. Some areas of potential application: • Banking • Insurance • Energy • Telecommunications • Music/Film • Fine Art • Education

Final Thoughts on Smart Contract Basics To summarize, a smart contract, executed by two parties, works as follows:

1. Reach an agreement

2. Formalize the agreement via code

3. Enforce the agreement via blockchain

From this breakdown, a smart contract can code legal obligations into an automated process. Returning to our original example, a decentralized eBay would allow both a seller and a buyer to execute the same transaction through a smart contract, placing funds in escrow until there is satisfaction and verification of delivery from the buyer. An intermediary wouldn’t be required to facilitate and ensure adherence to an agreement, thereby reducing the value extraction inherent in such a model.

When programmed with prudence, a smart contract can encode transactions in a manner superior to traditional contract law, allowing for reduced coordination and enforcement.

Part II, Smart Contract Use Cases

As we’ve already discussed, smart contracts carry out a set of conditional instructions written in code and executed through a blockchain. What can these instructions facilitate?

Decentralized Autonomous Organizations (DAOs)

One area in which we’ve seen the application of smart contracts is through Decentralized Autonomous Organizations (DAOs), popularized in mainstream media during The Constitution DAO. These organizations wouldn’t exist without the smart contract’s ability to code for business logic. DAOs leverage smart contracts to formalize the governance of an organization through self-enforcing code. DAOs enable multiple individuals across geographies, ages, skill sets, education levels, and otherwise to come together and work towards a common goal or vision for the future – some even anonymously. In pursuing that goal, the ability to standardize operations, voting, and decision-making through smart contracts has created a novel mechanism for human organization and achievement. A deep dive into DAOs will be a topic of a forthcoming post.

Finance

Decentralized Finance (DeFi), as a sector, could not have emerged if not for smart contracts. Building upon the ethos of Web3, DeFi embodies the same features, it is trustless, permissionless, and transparent. Anyone can see the transactions made on an open blockchain, and anyone can review and read the smart contracts that individuals in a network interact with.

DeFi largely parallels the traditional finance sector in both function and products offered. Whether relating to lending, borrowing, trading, or investing, smart contracts have provided a mechanism by which all of this can take place in the absence of a centralized intermediary such as a bank. Thanks to smart contracts, DeFi transactions can be achieved with reduced costs, higher latency, near-instant settlement, and constant availability.

While easy for critics to claim that DeFi is just a skeuomorphic representation of its traditional finance counterparts, it ignores the reality of banking in developing countries. Banking services in these regions tend to be reserved for those with education, wealth, or connections. Alternatively, DeFi provides a similar, though not perfect, substitute for anyone, regardless of age, wealth level, education level, gender, or race to access financial markets with merely a Web3 wallet.

Example: Aave - Open Source Liquidity Protocol

One such application of smart contracts in decentralized finance is AAVE. This decentralized application provides for the borrowing and lending of assets in an open-source protocol. Users can borrow collateral for a transparent APR or lend out their assets for a transparent APY. These assets are typically ETH (the token asset of Ethereum) or other blue-chip token assets. While parallel traditional finance services would require a credit score and other safeguards, AAVE simply leverages the ETH a user pledges. If the value of the collateral falls, an AAVE smart contract has pre-conditioned instructions to liquidate any collateral position that falls below the 85% collateral limit. This counterparty risk is buoyed through oracles, which provide a decentralized, trusted mechanism for determining the market price of pledged collateral.

Gaming

Crypto and Gaming have a storied history. Back when Bitcoin was of limited popularity, players from Magic the Gathering would use the Mt. Gox exchange to transact their cards using Bitcoin as a medium of exchange. It didn’t take long for them to exchange Bitcoin directly through this marketplace.

The extension of smart contracts to Web3 gaming is less difficult to wrap one’s head around - there was already some adoption through various gaming niches. Now, however, it’s not just about players exchanging BTC amongst each other but rather enabling individuals to own and trade digital assets coded for via smart contracts. To understand why this is significant, we must understand the lack of interoperability and asset ownership offered by gaming companies prior to smart contracts.

Traditionally, gaming companies supply their own proprietary marketplaces for digital goods. Whether it be a shield power-up, avatar skin, or unique map unlocked through experience points, those characteristics were always owned by the issuer, never the buyer. Buyers are beholden to the policies surrounding ownership and interoperability set by the developer and, in most cases, are powerless. If they lost access to an account or were banned, there was no recourse given the lack of property rights embedded in those digital goods.

Smart contracts enable digital asset value accrual to be expanded more broadly for both game developers and players. The mechanism that allows this value expansion is driven by non-fungible tokens (NFTs). NFTs deserve their own separate post, but given that they are enabled by smart contracts, we will touch upon them briefly. NFTs are unique, rare, and indivisible (unlike a JPEG that can be copied and pasted, any NFT secures provable scarcity, interoperability, and immutability, thanks to the smart contract that enables them).

Now, as an application to the gaming industry, these smart contracts can allow an individual to purchase or earn in-game digital assets, sell them on any marketplace, or port them over to different games (e.g., a Fornite skin could be used in Call of Duty: Warzone, assuming interoperability was encoded in the NFT). The benefits accrue to the end user, as opposed solely to the developer, creating a more equitable outcome. That is not to say developers would not still have a hand in the marketplace - the smart contracts for the NFTs can include code to allow developers to take a cut of any secondary sales. Some games that broadened the usage of digital assets as smart contracts include Axie Infinity and Splinterlands.

The Tokenization of Real World Assets

Another use case of smart contracts lies in the tokenization of real-world assets. Anything that has some sort of utility can be tokenized. Accordingly, there are two types of tokens, fungible and non-fungible.

1. Fungible tokens are both interchangeable and divisible. In the case of the U.S. Dollar, one dollar equals one dollar, and separately, 100 pennies equal one dollar. There is versatility in how it is exchanged and valued.

2. Non-Fungible tokens in the context of asset tokenization have three features: (a) non-interchangeable, (b) non-divisible, and (c) unique. An example could be the fractional ownership of a home tokenized on a distributed ledger: different ownership percentages can be represented by unique fractional NFTs.

Given the abovementioned features, tokenization can range across assets and use cases. As such, they allow for some unique features:

• Higher liquidity through fractionalized ownership

• Near-zero transaction fees, as middlemen/brokers are replaced with smart contracts

• Transparency and provability of ownership through a public blockchain ledger

The main benefits of tokenization range from higher levels of liquidity and reduced coordination costs. An individual could tokenize their home equity value both on-chain (so it can be represented on a distributed ledger) and off-chain (so that the liens to the home are recorded in county offices and other required government institutions) such that they could tap into their home equity while still preserving the asset as their livable space. Soon, such a practice could be more efficient and cost-effective than a traditional bank offering. Given that many of the steps in making this possible can be automated, the need for lawyers, brokers, and bankers to facilitate this transaction wanes, reducing friction and facilitation costs.

Conclusion

Smart contracts will require contributions from everyone, as each domain and industry will have its own use cases and requirements. While Web3 as a whole will make the internet more human-driven as opposed to machine-driven, smart contracts will be one of the first tools to showcase how powerful this paradigm shift will be, allowing exchange between people over the internet absent action rent-seeking intermediaries.

Special thanks to Zoe Enright and Sam Wheeler for their help on this post.

References:

“Aave and Flash Loans.” Gemini, https://www.gemini.com/cryptopedia/aave-flashloans. Accessed 25 Sept. 2022.

Konstantopoulos, Georgios. “How to Secure Your Smart Contracts: 6 Solidity Vulnerabilities and How to Avoid Them (Part 1).” Loom Network, 6 Feb. 2020, https://medium.com/loom-network/how-to-secure-your-smart-contracts-6-solidity-vulnerabilities-and-how-to-avoid-them-part-1-c33048d4d17d.

“Learn Hub.” Ethereum.Org, https://ethereum.org. Accessed 25 Sept. 2022.

Lipton, Alex, and Stuart Levi. “An Introduction to Smart Contracts and Their Potential and Inherent Limitations.” The Harvard Law School Forum on Corporate Governance, 26 May 2018, https://corpgov.law.harvard.edu/2018/05/26/an-introduction-to-smart-contracts-and-their-potential-and-inherent-limitations/.

Monolith. “TKN and Short Address Attack Mitigation:” Monolith, 31 Oct. 2018, https://medium.com/monolith/tkn-and-short-address-attack-mitigation-88cc895734ba.

“Real World Examples of Smart Contracts.” Gemini, https://www.gemini.com/cryptopedia/smart-contract-examples-smart-contract-use-cases. Accessed 25 Sept. 2022.

Smart Contracts 101 - What to Know & Where to Start - Wharton | Wharton - Economics of Blockchain and Digital Assets. https://www.web3.wharton.upenn.edu/blog/smart-contracts-101-what-to-know-where-to-start-wharton. Accessed 25 Sept. 2022.

Valaitis, Alex. “A Deep Dive on Chainlink.” Web3 Pills by Alex Valaitis, 28 July 2022, https://web3pills.substack.com/p/a-deep-dive-on-chainlink.

Voshmgir, Shermin. Token Economy: How Blockchains and Smart Contracts Revolutionize the Economy. 1st edition, 2nd amended printing, BlockchainHub, 2019.

Zhou, Haozhe, et al. “The State of Ethereum Smart Contracts Security: Vulnerabilities, Countermeasures, and Tool Support.” Journal of Cybersecurity and Privacy, vol. 2, no. 2, May 2022, pp. 358–78. DOI.org (Crossref), https://doi.org/10.3390/jcp2020019.

Many critics of Web3 claim that there are few, if any, use cases of Web3 that surpass the benefits of a comparable Web2 company. It’s not the fault of critics - few have come close to demonstrating a vision of what the future of networks will look like. Just as it was impossible to see the impact of the Internet in the early 2000s, the same can be said for the impact of blockchain today. The technology is too early. Yet, those who dismiss it publicly (i.e., Steve Ballmer)  have continued to see their remarks as exemplary in what not to do: bet against the future.

As I came to reflect on where Web3 could step in to provide bona fide improvement over the current state of the Internet, I, too, was hard-pressed to come up with an example. For most, the onboarding onto Web3 is too tricky, the communities are gate-kept, and the technology is slow. Why would anyone leverage this technology over a reasonable Web2 counterpart?

I explored a set of pressing technological problems to find an answer. Starting with a problem-solution-based decision tree, I sought to answer the following: What is an issue we are dealing with today, and can we back-solve to a scenario where a blockchain-enabled solution is the most optimal path?

Enter: Decentralized Identity.

Problem Statement

Before we can jump into decentralized identity, we need to discuss why it is a topic worth discussing.

When trying to determine a valid use-case for Web3, solving the concerns around identity was one of the few ideas that could stand on its own legs. In this lens, the benefits of Web3 become more tangible without the gate-keeping and strenuous onboarding effort.

One area that the Internet failed to optimize for was digital identity. As I previously discussed, Web3 is remarkable in providing a native settlement layer for the Internet, removing the need for any middlemen.

For network actors on the Internet to interact with each other, digital identification needed to be solved. This was a natural place for service providers to play a role. Let’s take early eBay as an example. Before eBay’s integration and eventual purchase and spinoff of PayPal, the buying and selling experience was fraught with trust concerns. A buyer would purchase an item, send a check through the mail, and hope that the seller’s reputation would provide enough incentive for them to ship the item as promised. Businesses like eBay, and later, Stripe, PayPal, Affirm, etc., created information hubs to verify identity across Internet actors so that goods could be exchanged over the Internet. They helped to answer pressing questions:

1. [Buyers] Can I trust the service provider to deliver my order?

2. [Sellers] What is the likelihood I will be paid?

A native identity layer did not exist for the Web 1.0 Internet and was not solved during the Web 2.0 iteration, either. The solution is a bit of a hack: the problem supported a hub-and-spoke model, by which traffic and identity are facilitated through a trusted third party whose application layer lives atop the Internet. As such, these facilitators of commerce would take a fee for creating a standard of trust for unknown network actors.

We can summarize Web2 as middleman oriented. As the Internet Protocol has no built-in mechanism for managing identities, centralized intermediaries stepped in to provide identity management, capturing, tracking, and managing identities on privately-managed servers. Each centralized intermediary manages a proprietary identity management database, whether a social media platform, email provider, or online bank.

All these disparate service providers hold a piece of our identity on their servers. Each retains its individual security, format, and storage conditions, making it almost impossible to create interoperability outside single-sign-on providers like Google, Meta, or Apple.

Problems, Examined

There are a set of issues that I find the most pressing when addressing identity management through a centralized lens.

One such concern is a lack of control and sovereignty of our data. We become subject to the ethics and policies of centralized institutions that possess our information. If a company fails to live up to the terms of services for which any of us have agreed, there typically is limited to no recourse.

There are also concerns about fraud. Credentialing matters for just about every online merchant. There is a latency issue between when a purchase is made and when merchants learn that a customer’s private information has been comprised or stolen credit information was used to make a purchase. These were the same issues I dealt with when I ran an online store - the worst part were the chargebacks. Even if I refunded the order, I was still hit with a $35 processing charge for every fraudulent charge made on my site, even though I was just a vendor. The impact of this is enormous, to the tune of $36 billion a year, according to Fiserv.

The hub-and-spoke model even impacts the way we manage our passwords and accounts. The number of usernames and passwords we’ve created over the last decade is enormous - so much so that standalone businesses are made just to manage this digital footprint and credentialing problem. Fortunately, with the help of Google and Apple, the headache of managing, recalling, and inputting many of the passwords is an almost non-existent burden. Yet, this opens a vulnerability for us users. At any point in time, Google and Apple retain both the right and ability to revoke access to any of our accounts. This only compounds the issues of password management and reflects the fragility of our digital identity.

As an extension to the previous point, the companies that manage our username and passwords and those who possess any portion of our private, personal information (PPI) have put themselves at technological and reputational risk. As a honeypot of PPI, they indirectly invite hackers and other nefarious actors to focus on these bigger fish, as a single exploited vulnerability yields outside returns in terms of PPI.

While less of a technological and more of a philosophical concern, today's current identity management system only serves to centralize the Internet further. Referencing famed Internet analyst Ben Thompson, the powers accumulate to the aggregators. The hold that these aggregators possess, as in the case of Amazon or Walmart, only purports their network effects. Their robust data analytics and harvesting mechanics only better service us with finely tuned advertisements and profiling to generate more spending. The ability of smaller merchants to compete against such an engine is almost nonexistent, hurting competition and market entry for challengers in the space. After all, how can a start-up e-commerce site compete with Amazon knowing all your wants and needs from its enormous pile of user data?

Defining Identity

Before we can understand Decentralized Identity and define a solution to the problem set, we must define identity. Identity represents an individual’s/institution’s/objects sense of “self” characterized by a unique set of characteristics. These characteristics are often referred to as Identifiers. Some examples include one’s name, social security number, address, passport, date of birth, or phone number.

Though one’s identity can be intangible, it does not preclude it from being “managed.” Identity management covers the process by which “identifiers” or distinctive characteristics can be identified, authenticated, and certified.

Separately, identity management covers the secure holding of one’s social security card or driver’s license and extends to its footprint on the Internet. Referencing our first principle’s approach to Web3, the Internet was not created to be a native settlement layer. It was merely a network by which information could be created and shared broadly. As such, economic activity cannot be conducted without some form of our identity blueprint “shared” on the Internet.

The following list demonstrates the extent that we take identity management as given:

·Government-issued (birth certificates, passports, social security)

·Education-issued (diploma credentialing)

·Healthcare-issued (health care records, insurance information)

·Banking-issued (bank account data, banking records, KYC/AML data, credit card numbers, etc.)

Identity Types

There are a few monomers worth defining for our discussion of decentralized identity. The main components are identifiers, authentication, and credentials/claims.

Identifiers are the characteristics associated with a person, institution, or object. Some conditions of an identifier within this context are unique and persistent (unchanged) over time. A residential address (or Snapchat username) wouldn’t meet these qualifications, whereas a social security number (in most cases), a passport number, or a driver’s license number tends to work well.

Authentication (often through attestations) references the mechanisms required to prove identity. This could relate to ownership of the identification (e.g., social security number), secret knowledge (e.g., a pin), or personal characteristics (e.g., biometrics or physical signature). An extension of authentication is a username/password combination.

Lastly, we will assess identity through the lens of credentials and claims. These components are claims made by one entity about another. These attestations contain identifiers that reference a particular identity, allowing an owner to make claims about an attribute related to their identity. This could be a claim that you are over a certain age, legally allowed to drive, or conferred a four-year university degree.

An important note is that without unique identifiers linked to a person, institution, or object, then identity would be useless. An identity must be able to provide distinction.

Web3 Decentralized Identity

As we’ve discussed, the Web 2.0 Internet did not include a native identity layer, as it was optimized for the flow of information between computers, as opposed to people.

Given the problems highlighted by Web2 identity management, there is a clear use case for decentralized identity. Such a process would improve identity management standards and greater personal data control. Individuals would be able to make decisions about what type of information is shared with third parties and how. In short, a decentralized identity would allow any individual to *own* an identity (Web3: Read. Write. Own).

Three parties are required to implement a robust, Decentralized Identity System that puts a user at its center.

1. Identity Issuers

2. Identity Owners/Holders

3. Identity Verifiers

An identity issuer is any entity that provides some identifier to a particular identity owner/holder. An identity issuer (e.g., a trusted institution) would provide a claim or credential to an identity owner. The issuer then signs (writes) their attestation (authentication mechanism) to a distributed blockchain or data registry. Separately, an identity verifier could request proof that a credential presented by the identity holder is valid. The process would be to check (read) the attestation from the identity issuer to determine if the public-key signature matches the entry on the distributed ledger. The verifier would not need to see the claim/credential but merely trust that the signature on the ledger matched that which the issuer of the credential provides.

Recall that in most Web3 settlement layers such as Bitcoin and Ethereum, users must create a wallet from which they are given a public/private key signature pair. The public key acts as a username, and the private key acts as a password. The primary distinction is that only the owner knows the correct private key (assuming no theft) and can generate messages, or in this case, attestations, which are “signed” by the issuing party. There is no way to create a message signed from a different private key, making authentication of signatures a source of truth.

There is a lot to unpack here. A decentralized identity stem allows anyone to verify if an issued credential/claim is valid by checking the validity of a trusted issuer’s attestation. This all happens without having the identity holder reveal details of the claim or credential, preserving their PPI.

Let us use an example with an off-chain attestation. Say a recently graduated student from Stanford University needs to have his diploma verified by a potential employer. In this case, Stanford (the issuer) would generate an attestation (digital academic transcript), sign its attestation with its public-key pair to a distributed ledger, and issue the credential to the student (the identity owner). The student can then prove his academic qualifications to the evaluating employer by merely sharing the attestation from Stanford in his Web3 wallet. The potential employer (the verifier) could confirm the presented credential's validity by checking the attestation's signature and referencing it to the public-key pair from Stanford University. In this case, the academic transcript was never revealed, per se, but was verified as authentic and genuine through this mechanism.

While this sounds like an email attachment with extra steps, it is, in fact, an “elegant” solution to the problems we laid out at the beginning of this article: preservation of one’s digital footprint. Because the employer couldn’t download and retain the private and sensitive information directly, the prospective employee can feel better knowing that his personal information does not now sit on a siloed, centralized server owned by the company, which at any point, can release the data to outside, unprivileged parties either by choice or by accident.

There is a requirement for three parties in such a system. To move away from the centralized hub and spoke model of Web2 identity, more players are required to divide the responsibility of identity management. From verifying to updating data, the more parties involved, the more built-in decentralization, and therefore security, exists in the system.

Beyond parties are the tools: the Web3 wallet. In this application, a Web3 wallet is more than a pointer to data on the blockchain: it can replace a physical wallet. While a physical wallet can hold an array of state-issued licenses, loyalty cards, and membership cards, among money and other records, so can a Web3 wallet with a higher level of security. Someone may be able to steal your physical wallet and your social security card, but a Web3 wallet adds layers of protection that require a password and wallet signature to verify any transaction. Not only can we preserve our information, but we also have added data portability, security, and ownership of these credentials. As adoption increases for this type of system and Web3 wallet, so will the amount and type of credentials that the digital wallet can represent.

Concluding Remarks

The Web 2.0 Internet is optimized for communication between computers across networks, as opposed to people across networks. When the need for identity management entered the fray, the system was a hack - no native identity layer meant limited protection for users and their data.

As the Internet’s evolution matures, the emergence of ownership within digital networks will be paramount. Distributed ledgers and public-key cryptography are the only building blocks for this next epoch. As we converge toward adhered-to standards and specifications, decentralized identity can offer a critical missing piece to the future of the internet.

References:

Decentralized Identifiers (DIDs) v1.0. https://www.w3.org/TR/did-core/. Accessed 16 Aug. 2022.

“Decentralized Identity.” Ethereum.Org, https://ethereum.org. Accessed 16 Aug. 2022.

Voshmgir, Shermin. Token Economy: How Blockchains and Smart Contracts Revolutionize the Economy. 1st edition, 2nd amended printing, BlockchainHub, 2019.

“What Is Decentralized Identity And Why Should You Care?” Hashnode Web3, https://web3.hashnode.com/what-is-decentralized-identity. Accessed 16 Aug. 2022.

A blockchain wallet is software written to store your private key, public key, and blockchain address. It is the interface that allows you to interact with a blockchain network (and in some cases, more than one!). Web3 wallets also enable:

• Sending tokens from your wallet

• Viewing tokens that are “held” by the wallet

• Inspecting the metadata of tokens sent to you

But how does a Web3 wallet work? And why is it that when you go on Twitter, your feed is filled with repeated advice: “not your keys, not your crypto”?

Let’s dive in.

Web3 Wallets: The Technical Details

Cryptocurrency is not stored in the wallet. The wallet holds the keys that point to the tokens that are held in the transaction records of the blockchain. The wallet’s keys merely point to these transaction records.

How Private Keys, Public Keys, and Blockchain Addresses are Derived

When you create a crypto wallet, assuming it is one not sponsored by a centralized exchange, the wallet generates a key pair consisting of a private and public key (centralized exchange wallets, or custodial wallets, retain the keys on your behalf).The first step in setting up a wallet is generating the private key. The private key is a 256-bit integer. A bit defines the smallest unit of data inside of a computer, which can only hold a value of 1 or 0. Different numbers can be created and represented by just these binary numbers, for example, “11” represents 3, “100” represents 4, and “101” represents 5. In other words, a 256-bit number is a number that can be represented using 256 ones and zeros. From this 256-bit integer, the wallet turns the value into a decimal, and from decimal into hexadecimal, which is something you may recognize from your own crypto wallet:

Turning a 256-bit integer into a decimal:

108165236279178312660610114131826512483935470542850824183737259708197206310322

Turning a decimal into a hexadecimal:

ef235aacf90d9f4aadd8c92e4b2562e1d9eb97f0df9ba3b508258739cb013db2

Once a private key is created, a public key is then derived using elliptic curve cryptography, which is a method traditionally used for digital signatures and pseudo-random generators.

The elliptic curve process involves randomly assigning a starting point on the curve, called the generator point. If you look at the image below, this is represented by point 1.

To output a random set of numbers from the elliptic curve, coordinate point “multiplication” is applied. Let’s say we “multiply” the coordinate point by 2. To illustrate the effect, let’s look at the graph above.

When we apply the coordinate point “multiplication”, we move from point 1 to 2G (the intersection). To get from 1 to 2G, we first draw a tangent from 1, find the intersection to the curve from that tangent, which is in this case, 2, then take the inverse, which results in point 2G.

This is a single round of elliptic curve “multiplication.” I put multiplication in quotations as this is not standard multiplication, but elliptic curve multiplication, which results in a random output compared to a standardized one. The implication of elliptic multiplication is that the outputs of the coordinate multiplication result in a dynamic change throughout each position on the curve, creating a truly random output. Note how different the coordinate point is from 1 to 2G simply by multiplying by 2.

Now, instead of using a simple example of multiplying by 2, we extend this foundational logic to deriving the public key: instead of multiplying a generator point by a single number, we apply coordinate point multiplication “private key” a number of times. The bouncing around of the coordinates and the subsequent random, dynamic outputs is what creates your public key.

From this process, you can see the difficulty in trying to derive a private key from its corresponding public key. This is symmetric encryption for key agreement.

There are two reasons why it is important to use an elliptical curve to derive the public key:

1. The multiplication is a “trapdoor function” or one-way hash, which makes it impossible to go backward to find the private key

2. The public key is still mathematically connected to the private key, which can act as a digital signature on transactions, verifying its authenticity (more on this below)

To add security, a blockchain address is then derived from the public key, though through a different method. The blockchain address is what is given to other parties for them to send you tokens. The blockchain address is shorter than the original public key, and the address is derived in a simple process:

Take your public key and run it through a SHA 256 hash function

(SHA256(publickey))

Take the output from the SHA 256 hash function and run it through a RIPEMD160 hash function

RIPEMD160(SHA256(publickey))

Taking the hexadecimal from the start of this article, here’s the output once placed into a RIPEMD160 hash function:

Hexadecimal:

     *ef235aacf90d9f4aadd8c92e4b2562e1d9eb97f0df9ba3b508258739cb013db2*

Applying the RIPEMD160 hash function:

                                *b334d3207ee8f1f0365f8e49cc6e2f92a34e115b*

The fact that we took a public key derived using an elliptic curve multiplication and ran it through two additional hashing functions reflects the security embedded into these key pairs. In the case that a nefarious agent knew your blockchain address and successfully unraveled the elliptic-key cryptography to see your public key, there is still another layer of security: the encryption from the public key to the private key.

As such, a blockchain address acts as a digital fingerprint of the public key but doesn’t give away any information about the public key. This is akin to an email address when sending an email. You may know where it came from, but it doesn’t mean you have access to the account itself!

Web3 Wallet – Digital Signatures

A blockchain wallet creates digital signatures for blockchain transactions. It allows the network of validators to verify if the sender is who they say they are, and if they hold the corresponding keys that give them the right to send tokens from one wallet to another. The private key is what signs a token transaction, while a public key is used by validating nodes to verify the authenticity of the signature.

A digital signature allows you to show that your private key corresponds mathematically to your public key (as used for verification by network validators), but you need not reveal the private key itself, as the digital signature acts as a method of authenticity. To prevent other agents from using a digital signature they did not create, each transaction that is “signed” has its own unique digital signature, such that it can only be used for that particular transaction. If an agent tried to reuse the digital signature for a different transaction, whether they owned the private key or not, the network validator nodes would recognize that a digital signature had been used previously, and the network will not accept it.

These digital signatures, as with most components of a blockchain network, are created using math. A private key is combined with transaction data, which after some math, creates a digital signature. This digital signature can then be combined with the original transaction data and the wallet’s corresponding public key, and output confirmation as to if the true private key generated the digital signature. The security behind authenticating a transaction is one of the core, but overlooked, features that Web3 wallets enable.

What’s In Your Wallet?

At the beginning of this section, I explained that a wallet doesn’t contain any tokens. Now that we understand private-public key pairs and block addresses, we can extend that understanding to the fact that a Web3 wallet only stores pointers to the tokens for which a private key can access. As such, the term wallet is a misnomer. It’s more like a fancy, digital keychain. A digital keychain that provides access to your house…of crypto.

Key Management

Given that a private key acts as the key to one’s home, it is imperative that it is kept, well, private. If you were to lose access to your wallet without having saved the private key or seed phrase, you will lose access to the tokens. They will still exist on the blockchain, but there will be no way to access them without the corresponding private key verifying the wallet’s ownership of those tokens.

Seed Phrase

Seed phrase? Yes. A seed phrase represents the large randomly generated number set that makes up your private key but instead represents the hexadecimal as a sequence of words. This is for human readability, as opposed to anything else. A seed phrase is generally 12 to 24 words and is derived from the private key. The mnemonic sentence comes from a fixed list of 2048 words, and the first four letters of each word are unique. In the case that you lost your wallet, you could recover or create a new private key from the mnemonic seed phrase. The word choices are specified by BIP39, which is the standard for which seed phrases are created for deterministic wallets. I linked to the GitHub documentation for those that want to dive in deeper.

Wallet Types: To Custody or To Not Custody?

There are a few distinctions to make when it comes to wallets: non-custodial and custodial wallets. A non-custodial wallet (the preferred) means that you, as an individual, retain the private keys to the wallet. As you possess the private key, you could always have a right to recover the assets held in the wallet through the private key or its corresponding seed phrase. The other type of wallet (the not-preferred) is a custodial wallet, in which you do not retain the private keys. Most exchanges offer custodial wallets, which comes at a major risk: given the function of wallets in Web3, you may own the “house” but you don’t own the key to get into the “house.” The dangers are highlighted in the recent events with both Celsius and Voyager freezing crypto account access and token transfer. If you don’t own the keys to your crypto, you don’t own it at all.

Non-Custodial Wallet Types: Hot and Cold

There are a few non-custodial wallet types: hardware wallets (cold wallets) and web/mobile-based wallets (hot wallets). A hardware wallet is a physical device that is not connected to the internet. For a transaction to be signed, a hardware wallet requires the physical device present along with the device password. A key distinction is that the signing of a transaction takes place “in-device,” which provides an extra layer of security since a transaction can only be approved if signed through the device itself.

A web-based wallet (hot wallet) is one in which the wallet is built into a browser extension connected to the internet. These are the most prone to attack given that the private keys are stored directly in your browser, so if an attacker had accessed your browser, they would also be able to access your private keys, and therefore, your crypto too! For added protection, a mobile wallet through an app can leverage second-layer security through facial recognition or a digital fingerprint to confirm a transaction.

Conclusion

The key message is that wallets are vital to interacting with the blockchain, but not because they hold your cryptocurrencies - they don’t! Wallets are important because they contain your private keys, and by extension, your digital signature. This feature is what allows for fraud prevention to be built into the internet settlement layer (blockchain). Analyzing the mathematics behind the process that derives the public key and subsequent address showcases the security built in. The next time someone asks, what’s in your wallet, you’ll know the answer :)

Sources:

Bottinelli, Paul. “An Illustrated Guide to Elliptic Curve Cryptography Validation.” NCC Group Research, 18 Nov. 2021, https://research.nccgroup.com/2021/11/18/an-illustrated-guide-to-elliptic-curve-cryptography-validation/.

How Does Bitcoin Work? https://learnmeabitcoin.com/. Accessed 14 July 2022.

Jameson Lopp’s Bitcoin Resources. https://www.lopp.net/bitcoin-information.html. Accessed 14 July 2022.

Voshmgir, Shermin. Token Economy: How Blockchains and Smart Contracts Revolutionize the Economy. 1st edition, 2nd amended printing, BlockchainHub, 2019.

Foundation

Cryptography is the art of writing codes. Broken down further, cryptography is a subfield of cryptology and refers to the encryption of messages. For secure communication, cryptography creates a mechanism for two parties to communicate privately. A message is encrypted when a piece of information is converted to something incomprehensible, known as ciphertext. Unless a recipient of the ciphertext has the corresponding cipher to decrypt the message, the message can’t be read.

Cryptography has had extensive historical use. One of the more prominent examples is its use during World War II, after the introduction of early computers. Computers allowed for more complex cipher encoding with the ability to process calculations faster than humans. However, with the ability to process more data computers also made it easier for nefarious actors to apply brute-force attacks in solving these ciphers (The Imitation Game is a good watch on the subject). Today, modern algorithms are almost impossible to crack, given the time and effort required. I discussed this in my post on Proof-of-Work, in which I demonstrated the features that made consensus mechanisms fault and attack-intolerant. 

Traditionally, cryptography has been used across digital payments, password management, identity authentication, digital signature, and beyond.  However, in blockchain, cryptography’s main use is identification, verification, and security.

Implications

Hash Functions

Hash functions are mathematical operations that convert any data of any size (referred to as the message) into data of a fixed size (referred to as the hash value). In other words, the hash functions take input data and turn it into a standardized data output, such as a string of numbers. The only way to recreate the original message from the hash output is to try all combinations of the hash operation to see if they create a match. This process is time-consuming and effortful, so hash functions are referred to as “one-way” functions.

Some conditions must be met for hash functions to be considered well-designed:

●       The same message should always result in the same hash.

●       The time and energy to guess the input value should be economically infeasible.

●       It is not possible for two different inputs to result in the same hash output.

Assuming these criteria are met, a hash function can be leveraged for more complex uses. Some examples include determining the authenticity of digital files, fingerprinting, and digital signatures. Hashing enables content-based addressing, which means that if the content is not corrupted or changed, the hash will always be the same. For bankers, any linked excel sheets that suddenly have a switched file path, you know this issue well. Hashing solves this.

Symmetric Key Cryptography

Symmetric key cryptography refers to a method in which two parties would exchange encrypted messages using an encryption key that they exchanged in a non-cryptographic way. An example of this you may be familiar with is the Caesar Cipher, where letters of the alphabet are shifted by a certain number of letters. The same key (the number of letters shifted in the previous example) would be used to both encrypt and decrypt the message. The key would be derived and transmitted via secret meetings or through couriers. Up until WWII, this was the default method of encryption.

This mechanism, as you’d expect, does not scale. It created a coordination problem between involved parties. When you add the internet into the mix, the method isn’t viable given the unknown, untrusted actors interacting over a public network.

Asymmetric Key Cryptography

To solve symmetric encryption's coordination and scaling problem, asymmetric encryption introduced public-key cryptography. The method introduced two keys: a public key and a private key.

The private key is a string of numbers only known to the owner. It must be kept confidential, whereas the public key can be given freely to anyone. If I were to send you some BTC, I could send it to your public key, but only you could access the BTC because only your private key could decrypt the “message,” which in this case is some BTC.

Compared to symmetric encryption, two parties don’t need to agree on a shared key to decrypt messages sent between them. They can leverage their private keys, share an encrypted “message” to a public key, and the other party can “unlock” the “message” using their private key.

The image below has one significant difference from the symmetrical encryption image – the public and private keys.

Cryptography and Bitcoin

Public Key Cryptography

Bitcoin, as a canonical example, uses public-key encryption. The keys create a digital signature demonstrating ownership of those private keys' tokens. An analogy is that the public key is like a physical check, and the private key is the signature on the check verifying ownership and instructions for sending funds, “the message.”

Applying the information in the hash function section of this post, a public key can be derived from a private key, but not the other way around. The computational power needed to create a public key from a private key is effortless, but the other way is arduous. Since a number generally represents the private key, the longer the string of numbers, the more difficult it is to guess that number from someone who doesn’t know it. This embeds security between parties.

Without these mechanisms, the ability to communicate and send “messages” from one person to another in an untrusted, distributed network like the internet would be burdened with scaling and coordination issues.

Applying Hashing as an Example

Hashing transforms large amounts of data into a standardized string of numbers, making it difficult to guess the original. You could hash almost anything, whether a piece of text or an image; applying a hash would turn the original bit-length into the standardized hash. This acts as a method of validity because if someone changes one letter in, say, a ten-thousand-word document, the entire hash will change, which is known as an avalanche effect.

Here's a quick example of how hashing works (using the SHA-256 algorithm) when small changes are applied.

Let’s add a question mark:

As you can see, even the change of a single punctuation point dramatically impacted the hash. The implication is that the hash value serves as a cryptographic derivative of the original message. This serves as a digital fingerprint, ensuring the message’s validity and preserving its integrity.

Cryptography is essential because, without public-key cryptography, the ability to trust the input and output functions of the blockchain would not exist. The public-key cryptography provides a source of truth and guarantees that only those intended to receive the message maintain that privilege.

Special thanks to Samuel Wheeler for editing!

There are three components that define a decentralized blockchain: Open-Source, Permissionless, and Public. Open source allows anyone to contribute to a protocol. Permissionless allows anyone to evaluate a ledger and change the state of a blockchain. Public allows anyone to be a user of the blockchain and view the entire history of transactions. 

These features lead to protocol forks. A fork is when blockchain developers copy the open-source code of an existing blockchain and change it, creating a derivative. There are two types of forks, hard and soft. A hard fork makes for two blockchains: the original blockchain and a new one. This new blockchain will not be backward compatible with the original, which requires blockchain miners to update their software to adhere to the specifications of the new blockchain, assuming they want to join this new fork. In this context, backward compatibility means that nodes running the software for the original blockchain could write to the new blockchain. Conversely, a soft fork creates two blockchains that are backward compatible, meaning that the blockchain has merely received new features and functionality, but does not require a change to the rules miners must follow in the original protocol. 

Types of Forks

Early forks of Bitcoin include ZCash, which is a payment protocol implementing more robust security features like encryption to preserve the privacy of its users. While forks of BTC are more oriented toward payment transfer, the open nature of its code inspired more alternatives. Take Arweave, from which this post is hosted. It is a decentralized storage network that stores data permanently in what is called the permawe. Arweave’s tools include capacity for UI hosting, database queries, and smart contract programming. This protocol provides a decentralized alternative to Amazon Web Services and other database-type centralized providers. 

Forks are what have brought Web3 to its state today. One notable example was the introduction of Ethereum, as introduced in Vitalik Buterin’s seminal whitepaper. What made Ethereum such a pivotal shift in Web3 was the introduction of smart contracts. Before Ethereum, a developer would need to create their own, special purpose blockchain to perform a set of actions. Smart contracts allowed developers to build on top of Ethereum, increasing the rate of innovation and speed to launch (we’ll cover the complexities of smart contracts in a future post). 

The key statement is that with public blockchains, forks are a necessary feature that propel the industry forward. It allows developers to build from a more resource-driven starting point, and in conjunction with stellar computer engineering skills, to create new blockchains that optimize for different use cases, as in the case of Solana, Avalanche, Algorand, and NEAR (among many others). 

While the core components of a decentralized blockchain are oriented around openness and access, the technology itself has inspired other alternatives. One such example is Estonia’s government placing both identification and health records on a permissioned (private access) blockchain, accessible with the proper key pair. Similarly, banks had come together through the R3 to provide cross-border payments, only accessible to permissioned members. In these types of forks, decentralization of data is the key optimization. It reduces the fault-tolerant features of centralized providers, but does not match the three key features of open-source, permissionless, and public. 

Purpose

Without the open and transparent nature of the Bitcoin protocol, innovation within the blockchain space would be much more difficult to achieve and even more knowledge-siloed than it is now. Since the code to Bitcoin is available to anyone to look through, anyone can copy the code, replace parts, and develop their own protocol optimizing for features left out by the original. Forking breeds purposeful creation. Communities are built, innovation flourishes and hypotheses are tested. Take this in comparison with the protective stances taken by pharmaceutical companies: how much more could we accomplish if we all could look under the hood?

Special thanks to Zoe Enright and Samuel Wheeler for their suggestions.

In my last post, I discussed how protocols design systems to discourage participants from manipulating the network and how important this is in the absence of a centralized institution. What is to prevent a network validator with a copy of a ledger from sending false information to other nodes?

Bitcoin’s Solution

Bitcoin solved this Peer-to-Peer (P2P) issue. The network was designed to prevent anonymous actors from corrupting the network. Bitcoin leveraged code to facilitate trust.

PoW presented computationally intensive, arbitrary math puzzles that must be solved to “write” (e.g., add a transaction) to the network. These math puzzles take a considerable number of computational resources to solve making it economically damaging to try to corrupt the network. The effort balances deterrence and reward: each validated block yields a token reward to the miner.

The science behind PoW blends cryptography, mechanism design, and networks. These factors made up the building blocks for a network to become more fault intolerant. The design started with the assumption all participants are corrupt and worked backward to reward proper behaviors and discourage malicious ones.

This matters for one reason: it enabled participants to trust code as an enforceable contract instead of relying on a legal agreement and, by extension, a centralized institution.

Diving Deeper in Proof of Work

Bitcoin enabled something remarkable: code as a settlement layer. Since this writing is centered around first principles, we need to build up an understanding of PoW before we dive into other elements of Web3.

I mentioned PoW in concept but did not define it explicitly: PoW is a mechanism to verify if a transaction sent on a network is valid. Verification is the critical component. If there is no centralized institution like Visa to confirm a transaction, you need some transparency within the protocol for network participants to trust the system and feel confident in participating.

Let’s look at this from an example:

I send you some BTC tokens on the Bitcoin network. Referencing the last article, we learned that tokens are just entries on a ledger. So, when I send tokens to you, the network validators (nodes) compete to add the entry (change of state) to the distributed ledger. The competition is based on which node can solve a complex mathematical problem fastest.

Under the Hood

A node will attempt to collect all recent network transactions, including their metadata, verify those transactions, guess a random, single-use number called a “nonce,” and then execute that data into an algorithm (SHA-256 or Secure Hashing Algorithm) to find the hash of the newly created block. It makes your eyes bleed in trying to parse apart what’s going on here, but it also gives some indication as to why it is called Proof-of-Work. 😊

Circling Back to Competition

If a node is the first to find the hash value, the node can add that hash value to the next block and, subsequently, the ledger. The node would then broadcast the blockchain’s new “state” to the other nodes. The other nodes will then validate the presented hash – if it matches. When validated, other nodes will add the hash of the newly minted block to their copy of the distributed ledger until the entire network converges on this state of the blockchain.

The process of determining the hash is complicated. It takes effort and energy. But what is incredible about Bitcoin’s design is that while finding the hash is hard, verifying the hash is easy: it leverages a simple matching function.

The node that is the first to determine the hash value receives a “block reward.” This is one of the PoW components I mentioned earlier in this post: As a reward, the validator received mined tokens, acting as the incentive for being a network validator.

Rewards

Per Bitcoin’s whitepaper, each validated block currently rewards the network validator 6.25 BTC per block. The reward rate halves every 210,000 blocks, which comes out to every four years. Each block takes about 10 minutes to validate, so after 210,000 blocks, roughly four years will pass between each halving. Recall that the rewards act as incentives for participants to put in the effort to verify transactions. Without these incentives in place, there is no draw to validate the network besides interest or hobby.

Game Theory

Guessing the correct nonce to match the hash requires work: a computer’s processing power and electricity. For a nefarious actor to present an invalidated hash, the attempt would require a significant amount of energy and power to fake. Consequently, any attempt at manipulation is economically prohibitive. When you hear the media complain about the power Bitcoin miners consume, this is the process to which they refer.

Advantages and Disadvantages of Proof of Work

The main advantages of a proof of work system include a high level of security, as demonstrated by the effort and mechanism design employed in verifying new blocks to the ledger. It is also the first method of verifying transactions in a decentralized, permissionless manner – there’s no need for a Visa to play a role in verifying a BTC transfer. Additionally, network validators (nodes) are given the chance to earn rewards to the role they play in the ecosystem.

One disadvantage is inefficiency: each block takes roughly 10 minutes to mine, whereas newer layer ones that leverage Proof-Of-Stake like Solana allows for one block every 400 milliseconds. Given how computationally intensive the verification process is, it also takes up an incredible amount of energy. Lastly, the fees paid to network validators are more expensive than other consensus mechanisms.

Conclusion

Proof of Work defines the consensus mechanism popularized by the Bitcoin network. It requires a considerable amount of “effort” based on computing power and energy to participate, acting as a deterrent to malicious actors. Without PoW, it would be difficult for a group of outsiders to trust code as a source of truth.

Remarks

Special thanks for Zoe Enright and Samuel Wheeler for their feedback and edits on this post.

In Bitcoin’s whitepaper, Satoshi Nakamoto coined a term that has since captivated a generation: “chain of blocks.” Nakamoto used this term to describe the mechanism required to create bona fide internet money. At a high level, the concept proposed a set of programming in which all computers in a peer-to-peer (P2P) network held the same ledger. This was a verifiable catalog of transactions with which all copies could be used to validate past transactions, acting as an immutable point of reference. As laid out in the whitepaper, its function cemented how a blockchain ledger is collectively managed and updated, leveraging game theory and tokens to ensure cooperation.

For the first time, individuals, regardless of their education, background, or geographic location, could have the ability to participate in and own internet money in a permissionless manner.

To understand how the blockchain works, we need to lay out a clear set of definitions for its building blocks. Otherwise, deeper dives into the technology may become too demanding, turning off others without the proper background. The last statement is an assumption but is driven mainly by my own experience 😊

Definitions

Blocks-Chained

In a blockchain network, token transactions are recorded on “hashed blocks.” A cryptographic hash is a unique digital marker, like an invoice number for a business. Each cryptographic hash is also a record of the previous block’s hash, such that as the transaction list grows, so too does the trail of cryptographic hashes that map transactions in each progressive block.

These cryptographic hashes link all the blocks together to create a ledger of historical state changes. Once a block is hashed, it cannot be changed without changing the hash value of all succeeding blocks. Since all network validators have a copy of the ledger and its block hashes, it is challenging and almost impossible to alter the hash record of the chained blocks. In summary, the blocks are chained together by a history of hashes that yield a verifiable system of record: a ledger.

Ledgers (Distributed)

A ledger, as referenced above, is a system of records verifiable by a history of hashes. This digital file contains records of all transactions made on a particular blockchain in its history. Given that each network validator has a copy of this record, it can be trusted – any manipulation would change the hash value, and as a result, not match the record on each network validator’s copy. This acts as a counterfeit-prevention measure.

A ledger is open for anyone to inspect, but no single person has direct control over it. All ledgers must match, which requires a consensus mechanism for network validators to find alignment in new additions to the chained blocks. Since trust is built into the mechanisms for recording and maintaining the record, the blockchain circumvents the need for centralized institutions to act as a validator of sorts.

Tokens

These are interesting. From a technical perspective, a token is merely a recorded entry on a ledger that corresponds to a blockchain address (the holder). These tokens can only be accessed by someone with the “private keys” or passphrase corresponding to the wallet that holds the address.

Applying chained blocks, ledgers, and tokens to Bitcoin

As an example, let’s walk through how a network uses these components to send a transaction without any centralized intermediary:

Bitcoin (BTC), a token, can be sent from me to you without a bank because of the mechanisms listed above. The node operators (network validators) check their copies of the distributed ledger against others to maintain validity. Then, through a majority vote or consensus, verify the transaction by performing some mathematical work. All operates are trusted equally. The power of the collective harnesses the validation of an institution without the indirect privacy and permission costs.

Protocol

A protocol is a set of code that outlines parameters or rules. These parameters define how node validators reach a consensus for a transaction. You can think of a protocol as the rules a bank follows, determining whether a particular transaction is valid. It also defines the rewards network validators are entitled to, typically a protocol’s native token. These rules are not set in stone – parameters can change depending on proposals made to the community of token holders or validators (also depending on the rules) and associated voting rules. Though an imperfect comparison, a protocol is like a nascent nation’s constitution. Rules and procedures are clearly outlined; however, amendments can be proposed or ratified based on the process outlined in the document. This is how blockchains function: through code and its evolution over time.

Cryptography

Cryptography, in a reductive sense, is a coded message. It enables two or more parties to send encrypted messages to each other. Cryptography is why features of the blockchain can include network security, token transfers, and privacy (pseudonymously).

Tokenomics

Tokenomics is a new word – even my word processor doesn’t think it’s a real word 😊 Tokenomics has a few constantly evolving definitions. Tokenomics can be defined as a protocol’s application of game theory such that network participants adhere to the rules set forth. This also includes punishments for those who fail to act truthfully. An entire book can be written on tokenomics ranging from supply-side to demand-side analysis, inflation rates, and behavioral economics, but for a general definition, think of it as the designing of the carrot and stick for a protocol.

Consensus

For the state of a blockchain network to be altered (e.g., a transaction to be hashed and recorded to the ledger), network validators must reach an agreement based on the rules set forth by the protocol. This is considered to reach “consensus.” Protocol tokenomics schemes are designed to assume that all network participants are corrupt. It becomes onerous and costly to manipulate the distributed ledger for a network.

Blockchain Address (Crypto Identity)

A blockchain address represents a pseudonymous digital identity that “owns” the rights to digital tokens. Since the tokens are mapped to a particular blockchain address, only the owner of that address (through private keys) holds the right to transfer those tokens. For the network to validate the owner of the tokens, the owner must “sign” a transaction using a private key. All aspects of deriving and validating a blockchain address and its associated ownership rights are a matter of solving a set of mathematic proofs by network validators. More on this will be outlined in future posts.

Blockchain Transparency: Block Explorers

Since all transactions and their details are public by design, blockchain ledgers can be analyzed and tracked. It is a reason why less than 0.62% of crypto transactions relate to money laundering or other illegal activities, according to Chainalysis. Block explorers like Etherscan allow anyone to analyze on-chain transactions and their data, similar to a search engine indexing its webpages and populating results in a digestible manner. Without a block explorer, you’d need to run a node to be able to download the history of every transaction for a blockchain.

Conclusion

In this article, we took a step back to find alignment of critical definitions and words often used but rarely explicitly defined. We outlined some of the building blocks of web3 in “blocks-chained,” how they come together to build out a ledger of recorded activity, and how tokens fit into the two. We then defined what a protocol is, how it leverages cryptography and game theory to align participants' behaviors, and how it all comes down to achieving consensus. We walked through the consensus mechanism and why it is necessary to execute transactions and trust a ledger’s output. And lastly, we brought it all together with how a blockchain address allows us to interact with the preceding items and how to gain further insights into what had taken place in a blockchain’s history.

Web3 pundits highlight the graph below and say: “You are still early to Web3!” The problem is that they never justify it beyond user metrics similarities across their respective adoption timelines. Statements like these are reductive: graphs alone fail to explain why being early matters.

In 1991, the internet brought about the ability to create tremendous, read-only webpages. The functionality and tools available through the early years of the internet were optimized for those who took the time to develop hard-won, unpopular skills in web design. The low-grade user experience lent itself as a barrier to mass adoption, but at minimum, represented possibilities.

All in all, Web1’s revolution contribution was read-only.

It took an entire decade later for the world to move beyond online directories and forums into what we’ve coined as Web2: read-write. This epoch allowed trillions of dollars of value to be created in a comparatively short timeframe, allowing participants to spin up startups at record-low costs. With some time on your hands and a willingness to learn the language, even young teenagers played a significant role in shaping how Web2 has emerged. Even without the proper skills, platforms such as Facebook, Twitter, Shopify, et cetera permitted anyone with an internet connection to contribute to the abundance of information, resources, and interactions that make up Web2.

Web3

And now, we’ve come to the beginning stages of Web3, whose fundamental contribution to the way humans and machines interact is based upon read-write-own. What does ownership even mean, and why does it matter?

Web3 has allowed for ownership of digital goods in ways not possible prior. In Web2, a centralized platform facilitated ownership rights, and even then, ownership of digital goods was controlled principally by the platform as opposed to the user. The canonical example is the Bored Ape Yacht Club NFT Collection. Though anyone could right-click-save the image, the blockchain allows for verifiable ownership available to anyone who has access to an internet connection. Since the blockchain is a public ledger, anyone can verify ownership, and the usage of the NFT can be carried over to other mediums: it’s not locked into a single service. This is a marked difference from digital goods offered by gaming companies, as the skins or upgrades purchased by game players are more so rented than owned and are completely platform-specific, barring any interoperability with other games or platforms.

This shift is new, and understanding it makes you early to Web3. There’s a significant amount left to discover what Web3 makes possible, much like the unknowns of Facebook’s impact on culture, politics, and the global economy back in 2004. Across all domains, Web3 has the potential to make the same if not more of an impact than Web2, and we have little idea as to what that looks like or how they will shape human-machine interaction. You are early, so things still don’t make sense. 🙂

Beyond just “owning” digital goods, Web3 transforms the way people work together deliberately and even anonymously. A significant component of Web3 is tokens, which can act as incentives for developers, contributors, and community members. For a Decentralized Autonomous Organization (DAO), tokens that are paid out as incentives work similarly to unrestricted stock compensation in a traditional company. Though simple, it is significant. Let’s evaluate why.

Protocols or DApps (decentralized applications) can make something worthwhile for an individual working within a collective that wouldn’t be worthwhile for a centralized entity on its own. The example that comes to mind is Google Maps - the cars that allow us to zoom in on our childhood home cost roughly $500,000/year each. For less densely populated areas, the cost-benefit analysis discourages Google from continuing to build out mapping in those areas. However, a new startup in Web3 is making what is too costly and burdensome for a company enticing and worthwhile for an individual.

Enter Hivemapper. For Google, it is too expensive to operate a 3-D mapping car in low-population areas, but an individual with a dashcam can do just as good a job for significantly less cost as they go about their day-to-day routes. They operate as individuals, contribute through a collective, and receive rewards through a value-add token. This is the power of Web3 - the ability to inspire contribution from individuals who otherwise wouldn’t have the leverage or network to make such an impact possible on their own.

Everyone Wins

The best part about being at the forefront of new technology is that the sector’s ethos is win-for-all. There are very few instances of zero-sum interactions in blockchain networks, barring crypto trading. Everyone’s perspective and contributions are needed to take a nascent technology and allow it to thrive under the guidance of the collective. Web3 needs everyone to come together because no one person can contribute to the impact that Web3 will have on economics, politics, culture, education, et cetera 🙂

Large-reach mediums like the media and social media serve their audience’s bounded rationality: they take the evolving complexity of Web3 and reduce it to what makes sense for readers: cryptocurrencies and tokens. Web3 hasn’t “clicked” for the masses because mass-audience writers reduce concepts for understanding in the moment at the cost of foundational knowledge in the long term. It is easy to dismiss that which you do not understand.

You can be early to almost any technological epoch. Still, suppose you don’t put in the effort, time, and toil that evolves you as a thinker within the space. In that case, you are no better than Robert Metcalfe’s assessment of the internet in 1995: “The Internet...will soon go spectacularly supernova and in 1996 catastrophically collapse.”

It’s no wonder that everyday individuals dismiss the potential of blockchain networks when their principal source of trusted news reduces the technology to articles of speculation: cryptocurrencies. This comes at the cost of understanding the “own” aspect in “read-write-own.” Some examples of impact through ownership include:

• Control over private data instead of being sold in exchange for access to a service

• Verifiable intellectual property rights over digital assets (NFTs)

• Insight into the supply-chain of goods and services we receive, money transfer included

• Native payment settlement no longer requires third-party intermediation

Instead of being at the mercy of Web2 centralized platforms and their service providers, the users of blockchain networks now have ownership over how they interact with machines, instead of machine designers determining the rule book.

Conclusion

Things don’t make sense because Web3 is still early, and there are knowledge silos preventing ease of onboarding or proper breakdowns. I hope this post allowed you to glimpse into what Web3 means, why it is great to be early, and how everyone’s contribution to the space is needed now more than ever.

Special thanks to Zoe Enright and Sam Wheeler for their comments and guidance on this post.

What can you learn about Web3 as a budding investor in six months if you dedicate your entire time to it? From my experience, not much :)

Web3 is cryptic…foundational knowledge in the space is guarded closely by gatekeepers who tend not to engage with anyone who joined Web3 after the 2020 bull market - but, I can see why that would happen.

Suppose you didn’t hold crypto before 2020. In that case, you are viewed as someone following the newest, shiniest object at the cost of the true ethos of what Web3 represents: inclusivity, interoperability, and transparency. Perhaps I am projecting my own experience a bit here, but that ethos has been shrinking precipitously, as new entrants who want to contribute to Web3 for the long term face an uphill battle of onboarding themselves with limited guidance.

There are tremendous alternative resources for learning about Web3 from those who have spent years in the space, ranging from Bankless to Nat Eliason and others. Still, without a first-principled approach to understanding the building blocks of crypto, these well-explained terms and concepts fail to convey their intended meaning. Web3’s baseline requirements of knowledge have become muddled. Crypto teachers today assume that baseline of knowledge, at the cost of the next majority of adopters feeling overburdened and left behind.

This newsletter aims to bridge Web3 foundational knowledge and the Web3 ethos. A journey, no matter how arduous, is better experienced with friends :)

Purpose

My goal with writing is to break down Web3 into its atomic components and expand upon them. Much of the “learning” we are recognized for in life comes from surface-level understanding: passively reading an article or book, listening to a podcast, or briefly mentioning it in a conversation to appear in vogue (hint, speaking from experience). Proper depth of knowledge comes from being able to understand, explain, and, most importantly, teach others. In other words, I am selfishly using you, the reader, as a way for me to learn more deeply about the things that I foolishly assume I “know.”

I prescribe to the assessment of Roman poet Publius Terentius, “Nothing has yet been said that’s not been said before.” I mention this as my work is not original. I made crypto my full-time job after ten years of industry validation from others who were ridiculed. I am standing on the shoulders of giants, leveraging the ideas, thoughts, and learnings of the past and repackaging them in the hopes that reframing these concepts may help people see things they did not prior.

That is not to say that this journey and willingness to share what I’ve learned is not without its fair share of fear, but in light of this fear, I believe there is no better way to increase your surface area of luck than to gain leverage on your ideas. The internet has made the flow of information and ideas more accessible, and who are you, to deny yourself the opportunity to see how far your ideas can go?

Topics

There are a few topics that I hope to cover through this medium:

• First-principle, Web3 concepts and explanations

• Crypto investment thesis and its evolution over time

• Investment memos on Web3 investments

Conclusion

I hope you join me on this journey of confidence building in Web3, starting from first principles. :)