leaf

December 29, 2016 This is a mirror of The Mail https://medium.com/@VitalikButerin/a-proof-of-stake-design-philosophy-506585978d51

Systems like Ethereum (as well as Bitcoin, NXT, and Bitshares) are a brand new cryptoeconomic organism—a decentralized, jurisdiction-free entity that exists entirely in cyberspace, maintained by a combination of cryptography, economics, and social consensus. They are somewhat like BitTorrent, but they are also not like BitTorrent, because BitTorrent lacks the concept of state—this distinction becomes crucial. They are sometimes described as decentralized autonomous organizations, but they are also not entirely companies—you can't just hard fork Microsoft. They are somewhat like open-source software projects, but not entirely so—you can fork a blockchain, but it's not as easy as forking OpenOffice.

These cryptoeconomic networks come in various styles—ASIC-based PoW, GPU-based PoW, naive PoS, delegated PoS, and soon to be Casper PoS—each style inevitably has its own underlying philosophy. A well-known example is the maximalist view of proof of work, where the "correct" blockchain, in the singular, is defined as the chain created by miners burning the maximum amount of economic capital. This mechanism was originally just a branch selection rule within a protocol, but in many cases has been elevated to a sacred principle—see my discussion with Chris DeRose on Twitter for example, where someone seriously attempted to defend this idea in its purest form, even in the face of hard forks changing the protocol due to hashing algorithms. 'Bitshares' delegated proof of stake proposes another coherent philosophy, where everything stems from a single principle, but this principle can be described more simply: shareholder voting.

Each philosophy—Satoshi consensus, social consensus, shareholder voting consensus—will draw its own set of conclusions and form a value system that makes sense from its own perspective—though they will certainly be criticized when compared to each other. Casper consensus also has a philosophical foundation, although it has not yet been succinctly expressed.

Myself, Vlad, Dominic, Jae, and others all have our own views on why stake-based proof of stake protocols exist and how to design them, but here I intend to explain my personal perspective.

I will list observations and conclusions directly.

• Cryptography is indeed special in the 21st century because cryptography is one of the few domains where hostile conflicts continue to severely favor the defender. Castles are far easier to destroy than to build, islands can be defended but still attacked, yet an ordinary person's ECC key is secure enough to withstand even nation-state actors. The cypherpunk philosophy fundamentally aims to leverage this precious asymmetry to create a world that better protects individual autonomy, and cryptoeconomics is in some sense an extension of this philosophy, only this time protecting the security and vitality of complex coordination and cooperation systems, not just the integrity and confidentiality of private information. Systems that consider themselves ideological heirs of the cypherpunk spirit should maintain this fundamental property; destroying or compromising them is far more costly than using and maintaining them.

• The "cypherpunk spirit" is not just about idealism; creating systems where defense is easier than attack is also simple rational engineering.

• On a medium to long-term scale, humanity is very good at consensus. Even if adversaries have infinite hashing power and launch a 51% attack on any major blockchain, convincing the community that this chain is legitimate is much more difficult than simply surpassing the hashing power of the main chain. They need to subvert block explorers, every trusted member in the community, the New York Times, archive.org, and many other sources on the internet; in short, they need to convince the world that the new attack chain is the one that first appeared in the information technology-intensive 21st century, just as difficult as convincing the world that the moon landing never happened. In the long run, these social factors will ultimately protect any blockchain, regardless of whether the blockchain community acknowledges this (noted that Bitcoin Core does acknowledge this primacy of the social layer).

• However, blockchains protected solely by social consensus are too inefficient, too slow, and can easily allow disagreements to persist indefinitely (though it is difficult, it has happened); thus, economic consensus plays an extremely important role in protecting activity and security properties in the short term.

• Because proof of work can only come from collective rewards (in Dominic Williams' words, it lacks two of the three e's), and miners' incentives can only come from the risk of losing future large rewards, proof of work must necessarily be based on a logic where immense power exists under the incentive of huge rewards. Recovering from a PoW attack is very difficult: the first time it happens, you can hard fork to change PoW, making the attacker's ASICs useless, but the second time you no longer have that option, so the attacker can attack again and again. Therefore, the mining network must be very large so that attacks are unimaginable. By making the network spend X every day to prevent attackers smaller than X from appearing. I reject this logic because it kills trees, and (ii) it fails to realize the cypherpunk spirit—attack costs and defense costs are at a 1:1 ratio, so there is no advantage for the defender.

• Proof of stake breaks this symmetry because it does not rely on security rewards but rather on penalties. Validators put their funds ("deposits") at risk and receive a slight reward for locking up their capital and maintaining nodes and taking extra precautions to ensure their private keys are secure, but the majority of the cost of recovering from a transaction comes from penalties that are hundreds or thousands of times greater than the rewards they simultaneously receive. Thus, the "one-sentence philosophy" of proof of stake is not "security comes from burning energy," but "security comes from proposing economic loss values." If you can prove that unless malicious nodes collude to attempt to cause the exchange to incur an internal loss of value $X, no equivalent termination level of any conflicting block or state can be achieved, then the given block or state has $X security.

• In theory, a conspiracy of the majority of validators could take over a proof of stake chain and begin to act maliciously. However, (I) through clever protocol design, their ability to earn extra profits through such manipulation can be limited as much as possible, and more importantly (ii) if they attempt to prevent new validators from joining or execute a 51% attack, then the community can simply coordinate a hard fork to remove the deposits of the violating validators. A successful attack might cost $50 million, but the process of cleaning up the aftermath won't be that much heavier than the geth/parity consensus failure on 2016.11.25. Two days later, the blockchain and community are back on track, the attacker loses $50 million, and others in the community may be richer because the attack causes the token's value to drop upwards due to the ensuing supply shortage. That is the attack/defense asymmetry for you.

• The above should not be understood as unplanned hard forks becoming a frequent occurrence; if necessary, a single 51% attack on proof of stake can certainly be set to a permanent cost of 51% attack, and the pure cost and ineffectiveness of the attack should ensure that it is almost never attempted in practice.

• Economics is not everything. Individual actors may be incentivized by off-protocol motives, they may be hacked, they may be kidnapped, or they may simply be drunk and decide one day to destroy the blockchain, letting the costs go to hell. Moreover, on the positive side, individual moral restraint and poor communication efficiency often raise the cost of attacks to levels far exceeding the nominal loss values set by the protocol. This is an advantage we cannot rely on, but at the same time, it is one we should not unnecessarily discard.

• Therefore, the best protocols are those that work well under various models and assumptions—the economic rationality of coordinated choices, the economic rationality of individual choices, simple fault tolerance, Byzantine fault tolerance (ideally, adaptive and non-adaptive adversary variants), behavioral economics models inspired by Ariely/Kahneman ("We all lie a little"), ideally any other model that is realistically feasible. It is important to have two layers of defense: economic incentives to prevent centralized cartels from taking antisocial actions, and anti-centralization incentives to prevent the formation of cartels from the start.

• Consensus protocols that work as quickly as possible are risky and should be approached with great caution, because if the possibility is very fast related to incentives to do so, this combination will reward very high levels of network-level centralization that trigger systemic risks (for example, all validators running from the same hosting provider). Consensus protocols do not care much about the speed at which validators send messages, as long as they send messages within some acceptable long time interval (e.g., 4-8 seconds, as we know from experience that delays in Ethereum are typically around ~500 milliseconds to 1 second). A possible middle ground is to create protocols that can work very quickly, but mechanisms similar to Ethereum's uncle mechanism ensure that the marginal returns of nodes increasing their network connectivity beyond some easily achievable point are relatively low.

From here, of course, there are many details and many ways to diverge on the details, but the above are at least the core principles on which my version of Casper is based. From here, we can certainly discuss the trade-offs between competing values. Are we giving ETH a 1% annual issuance rate and incurring a $50 million forced remedial hard fork cost, or giving ETH a zero annual issuance rate and incurring a $5 million forced remedial hard fork cost? Under the economic model, when do we increase the security of a protocol in exchange for reducing its security in the fault tolerance model? Are we more concerned about predictable security levels or predictable issuance levels? These are questions for another post, as well as the different trade-offs in executing these values are more questions for more posts. But we will get to that.

Hard Forks, Soft Forks, Defaults, and Enforcement#

The Chinese translation is as follows:

When new consensus rules are released, nodes that do not upgrade will produce invalid blocks due to their ignorance of the new consensus rules, resulting in temporary forks.

So, a simple understanding is that soft forks are actually temporary; they can potentially revert to the latest chain state as long as the non-upgraded nodes upgrade to the latest state, then they can return to the updated chain. In the chain where a soft fork occurs, non-upgraded nodes can validate blocks produced by upgraded nodes, and upgraded nodes can also validate blocks produced by non-upgraded nodes. Let's illustrate this with an image.

Characteristics of soft forks:

1. Better compatibility, allowing the use of previous version functionalities without upgrading.

2. There are no forks in the blockchain, as shown in the image, there is only a distinction between new blocks and old blocks.

3. Long-term allowance for non-upgrading, coexistence of new and old blocks.

2. Hard Forks

Here, I also quote the English description from the Bitcoin official website:

A permanent divergence in the blockchain, commonly occurs when non-upgraded nodes can’t validate blocks created by upgraded nodes that follow newer consensus rules.

The Chinese translation is as follows:

A permanent divergence occurs in the blockchain when new consensus rules are released, and some non-upgraded nodes cannot validate blocks produced by upgraded nodes, which usually leads to a hard fork.

In other words, a hard fork is a permanent fork; once it forks, it cannot return to the original fork. With the blockchain version update, non-upgraded nodes refuse to validate blocks generated by upgraded nodes, while upgraded nodes can validate blocks produced by non-upgraded nodes, leading to the continuation of two different chains. As the saying goes: "Paths that differ cannot conspire." Since we disagree, my old node does not accept your new node, so we each govern ourselves, and no one needs to bother the other. Similarly, let's use an image again.

Characteristics:

1. No compatibility, incompatible with previous versions, emphasizing upgrades.

2. The blockchain splits into two chains, as shown in the image.

3. Requires unanimous agreement to upgrade within a certain time; those who disagree enter the old chain.

II. Why Hard Forks Occur
The reason for soft or hard forks, in my personal understanding, is mainly due to various proposals raised due to certain issues, but because each side feels their proposal is better, disagreements arise, and everyone refuses to yield, leading to each pursuing their own proposal, resulting in a fork. For example, various proposals have been made regarding the scaling issue.

In the original Bitcoin system, a block's capacity was set at 1M, and the confirmation time for a block was 10 minutes, meaning each block could process about 7 transactions per second. This processing capacity is indeed a bit low, easily causing congestion, ultimately leading to collapse. Therefore, some proposed block expansion. Some suggested changing it to 2M, some to 20M, and some to unlimited capacity. Who should we listen to? No one can decide, so everyone can only pursue their own version.

The most well-known hard forks are ETC and ETH. In July 2016, the Ethereum development team forcibly transferred all funds of The DAO (Decentralized Autonomous Organization) and its sub-DAOs to a specific refund contract address by modifying the Ethereum software code at block 192000, thereby reclaiming the Ether controlled by the hacker. This then formed two chains, one ETC (the original chain) and one ETH (the forked chain).

An important debate in the blockchain field is whether hard forks or soft forks are the preferred protocol upgrade mechanism. The fundamental difference between the two is that soft forks change the protocol rules by strictly reverting the effective transaction set, so nodes following the old rules will still enter the new chain (assuming most miners/validators implement the fork), while hard forks allow previously invalid transactions and blocks to become valid, so clients must upgrade their clients to stay on the hard fork chain. Hard forks also have two subtypes: strictly expanding hard forks, which strictly expand the effective transaction set, so the old rules are effectively a soft fork relative to the new rules, and bilateral hard forks, where the two rule sets are mutually incompatible.

Here is a Venn diagram to illustrate the types of forks:

The benefits of both are usually listed as follows.

• Hard forks allow developers greater flexibility when upgrading protocols, as they do not have to ensure that new rules "fit" old rules.

• Soft forks are more convenient for users, as users can stay on the chain without upgrading.

• Soft forks are less likely to cause chain breaks.

• Soft forks only require consent from miners/validators (because even if users still use old rules, if the nodes constituting the chain use new rules, then only things valid under the new rules will enter the chain); hard forks require opt-in user consent.

In addition, a major criticism of hard forks is that they are "mandatory." The kind of coercion implied here is not physical coercion; rather, it is coercion through network effects. In other words, if the network changes the rules from A to B, then even if you personally prefer A, if most other users prefer B and switch to B, then you must switch to B, even if you personally disagree with this change, in order to interact with others on the same network.

Supporters of hard forks are often mocked for attempting to "maliciously take over" the network and "force" users to follow them. Moreover, the risk of chain breaks is often used to view hard forks as "unsafe."

My personal view is that these criticisms are misguided and, in many cases, completely regressive. This view is not unique to Ethereum, Bitcoin, or any other blockchain; it arises from the general nature of these systems and applies to any system. Furthermore, the arguments below only apply to controversial changes where at least one group (miners/validators and users) largely disagrees with these changes; if a change is uncontroversial, then it can usually be safely accomplished regardless of the format of the fork.

First, let's discuss the issue of coercion. Both hard forks and soft forks change the protocol in ways that some users may not like; any protocol change that does not receive 100% support will do so. Moreover, it is almost inevitable that at least some dissenters in any case will value the network effects of sticking with the larger group more than their own preferences for the protocol rules. Therefore, from the perspective of network effects, both types of forks are coercive.

However, hard forks and soft forks have an essential difference: hard forks are opt-in, while soft forks do not allow users to "opt out." For a user to join a hard fork chain, they must personally install the software package that implements the fork rules, and those users who disagree with the rule change can theoretically simply remain on the old chain—indeed, such an event has already occurred.

This is true for both strictly expanding hard forks and bilateral hard forks. However, in the case of soft forks, if the fork is successful, there is no unforgeable chain. Therefore, soft forks are institutionally more inclined to coercion rather than splitting, while hard forks have the opposite inclination. My own moral viewpoint makes me more inclined towards separation rather than coercion, although others may disagree (the most common argument is that network effects are really, really important and it is crucial that “one coin rules them all”, although there are also more moderate versions).

If I had to guess why, despite these debates, soft forks are often promoted as "less coercive" than hard forks, I would say it is because it feels like hard forks "force" users to install software updates, while with soft forks users do not "have to" do anything at all. However, this intuition is misguided: what matters is not whether individual users must perform the simple bureaucratic step of clicking the "download" button, but whether users must do so under coercion to accept changes to the protocol rules they would prefer not to accept. By this standard, as noted above, both types of forks are ultimately coercive, with hard forks performing better in protecting user freedom.

Now, let's look at the controversial forks, particularly those where the preferences of miners/validators conflict with those of users. There are three scenarios: (1) bilateral hard forks, (2) strictly expanding hard forks, and (3) so-called "user-activated soft forks" (UASF). A fourth category is miner-activated soft forks without user consent; we will discuss this later.

First, bilateral hard forks. In the best case, the situation is simple. These two coins trade on the market, and traders decide their relative value. In the case of ETC/ETH, we have overwhelming evidence that, regardless of their own ideological views, miners are very likely to simply allocate their hash power to the coin based on price ratios to maximize their profits.

Even if some miners acknowledge an ideological lean towards one side, it is highly likely that there will be enough miners willing to arbitrage any mismatch between price ratios and purchasing power ratios, keeping both in line. If a miner cartel tries to form to not mine on one chain, there is excessive motivation to defect.

There are two extreme scenarios. The first possibility is that due to inefficient difficulty adjustment algorithms, the value of mining coins declines as prices drop, but difficulty does not decrease to compensate, making mining very unprofitable, and no miner is willing to mine at a loss to keep the chain moving until difficulty restores balance. Ethereum is not like this, but it is likely Bitcoin is. Thus, minority chains are unlikely to take off and will die. Note that the normative question of whether this is a good thing depends on your view of coercion and splitting; as you can imagine from what I wrote above, I personally think this minority chain hostile difficulty adjustment algorithm is bad.

The second edge case is that if the gap is very large, the large chain can 51% attack the smaller chain. Even in the case where ETH/ETC split at a 10:1 ratio, this scenario did not occur; so it is certainly not inevitable. However, if miners on the dominant chain prefer coercion over allowing separation and act according to those values, this is always possible.

Next, let's look at strictly expanding hard forks. In SEHF, there is a property that under the fork rules, the non-fork chain is valid, so if the price of the fork chain is lower than that of the non-fork chain, then its hash power will be lower than that of the non-fork chain, and thus the non-fork chain will ultimately be accepted as the longest chain by both the original client and the fork client rules—so the forked chain will be "annihilated" as stated.

There is a view that such forks exist with a strong inherent bias towards success because the possibility of the forked chain being annihilated will be factored into the price, pushing the price down, making it more likely to be annihilated... this argument seems quite strong to me, so it is a good reason to prefer any controversial hard fork to be bilateral rather than strictly expanding.

Bitcoin Unlimited developers suggested solving this problem by manually creating bilateral hard forks, but a better option is to internalize the bilateral nature; for example, in the case of Bitcoin, a rule could be added to prohibit some unused opcodes, and then include transactions containing that opcode on the non-fork chain, so under the fork rules, the non-fork chain would henceforth be considered permanently invalid. In Ethereum's case, due to various details about how state computation works, almost all hard forks are nearly automatically bilateral. Other chains may have different properties depending on their structure.

The last type of fork mentioned above is user-activated soft forks. In UASF, users open the soft fork rules without bothering to gain consensus from miners; for economic reasons, miners may join in. If many users disagree with the UASF, then there will be a coin split, leading to a scenario similar to that of strictly expanding hard forks, except—this is the clever and circuitous part of this concept—the same "risk of annihilation" pressure strongly disadvantages the forked chain in strictly expanding hard forks while strongly favors the forked chain in UASF. Even if UASF is opt-in, it uses economic asymmetry to tilt towards success (although this bias is not absolute; if UASF is absolutely unpopular, it will not succeed and will only lead to chain splits).

However, UASFs are a dangerous game. For example, let’s assume a project's developers want to create a UASF patch that converts an unused opcode that previously accepted all transactions into one that only accepts transactions conforming to some cool new features, even though this is politically or technically controversial and disliked by miners. Miners have a clever and cunning countermeasure: they can unilaterally implement a miner-activated soft fork that causes all transactions created with that soft fork's features to always fail.

Now, we have three sets of rules:

1. Opcode X is always valid under the original rules.

2. Opcode X is only valid if the rest of the transaction conforms to the new rules.

3. Opcode X is always invalid under the new rules.

Note that

(2) is a soft fork relative to (1), while (3) is a soft fork relative to (2).

Now, there is strong economic pressure supporting (3), so the soft fork fails to achieve its goal.

The conclusion is this. Soft forks are a dangerous game, and if they are controversial, and miners start to push back, they become even more dangerous. Strictly expanding hard forks are also a dangerous game. Miner-activated soft forks are coercive; user-activated soft forks are less coercive, although they are still quite coercive due to economic pressures, and they also have their dangers. If you really want to make a controversial change and have already decided that the high social costs of doing so are worth it, then just make a clean bilateral hard fork, take some time to add some appropriate replay protection, and let the market sort it out.

March 14, 2017

Defining the Problem

So what does a good token sale mechanism look like? One starting point is to observe the criticisms currently faced by sales models and find a list of popular features.

Let's do this together. Some inherent features include:

1. Certainty of Valuation: If you participate in a sale project, you must at least determine what the upper limit of valuation is (or say, the maximum proportion of tokens you can receive).

2. Certainty of Participation: If you want to participate in such a sale project, you must have the intention to succeed.

3. Funding Cap: To avoid criticisms of greed (or to eliminate the risk of regulatory scrutiny), the sale must limit the amount of funding.

4. No Central Bank: The initiators of the token sale cannot hold too many tokens to avoid controlling the market.

5. Efficiency: The sale cannot lead to economic inefficiencies or unnecessary losses.

Does that sound reasonable?

Well, here comes the less interesting part.

1. (1) and (2) cannot be satisfied simultaneously.

2. At least if no tricks can be taken, (3), (4), and (5) cannot be satisfied simultaneously.

These can be referred to as the "first token sale dilemma" and the "second token sale trilemma."

The proof of the first dilemma is simple: suppose you offer users a certain valuation of $100 million in the sale. Now suppose a user wants to invest $101 million. At least some will fail. Simple supply and demand can prove the second trilemma. If you satisfy item (4), you must sell all or a fixed share of the total tokens, so the valuation you sell is proportional to the price you sell. If you satisfy item (3), you set an upper limit on the price. However, the quantity you sell may correspond to an equilibrium price that exceeds your set price limit, leading to a situation where supply cannot meet demand: (i) the digital equivalent of waiting 4 hours in line at a busy restaurant; (ii) the digital equivalent of ticket scalping, resulting in unnecessary losses and conflicting with (5).

The first dilemma cannot be overcome; certainty of valuation and participation is unavoidable, although it is preferable to choose certainty of participation over certainty of valuation when possible. The closest result we can derive is to sacrifice full participation to guarantee partial participation. This can be achieved through proportional refunds (for example, buying tokens worth $101 million at a valuation of $100 million, with everyone receiving a 1% refund). We can also consider this mechanism as an unlimited sale, where partial payments represent locked funds rather than consumption; however, from this perspective, it can be determined that the requirement for locked funds is a loss of efficiency, so this mechanism cannot satisfy (5). If Ether shares are not allocated well, it may favor wealthy shareholders, harming fairness.

The second dilemma is difficult to overcome. Many attempts to overcome it may lead to failures or unpredictable bad outcomes. For example, Bancor's token sale considered limiting the gas price of purchase transactions to 50 entropy (about 12 times the regular gas price). However, this means the optimal strategy for buyers is to set up multiple accounts, sending a transaction from each account to trigger the contract, and then buy in (circumventing the risk of buyers accidentally exceeding their expected buy-in, reducing capital requirements). The more accounts buyers set up, the higher their potential buy-in. Thus, in equilibrium, this could exacerbate congestion on the Ethereum blockchain, even exceeding BAT-type sales; the transaction fee for such sales is at least $6,600 rather than the denial-of-service attacks the network suffers. Moreover, any type of on-chain transaction competition severely harms fairness because the cost of participating in the competition is fixed, while the rewards are related to your capital amount, so the result will disproportionately favor wealthy shareholders.

Next Steps

There are three wise things you can do. First, you can conduct a reverse Dutch auction like Gnosis, but with an adjustment: do not hold unsold tokens, but use them for the public good. Simple examples include: (i) airdrops (redistributing to Ether holders); (ii) donations to the Ethereum Foundation; (iii) donations to Parity, Brainbot, Smartpool, or other companies and individuals building infrastructure independently in the Ethereum space; (iv) combining the first three, possibly according to the ratio voted by token buyers.

Second, you can retain unsold tokens, but solve the "central bank" problem by automatically deciding how tokens are spent. The reasoning here is similar to why many economists are interested in rules-based monetary policy: even if centralized institutions can significantly control powerful resources and eliminate the political uncertainty arising from that by following certain usage rules, they can do so. For example, unsold tokens can be given to market makers to maintain the stability of token prices.

Third, you can conduct capped sales. Limit the amount each person can buy. Effectively doing this requires a KYC process, but fortunately, KYC institutions can accomplish this task in one go; after confirming that an address represents a specific individual, a whitelist of user addresses can be created, and this list can be reapplied to each token sale and other applications that may benefit from this model, such as voting in the Akasha game. There is still unnecessary loss (efficiency), which may lead uninterested individuals to participate in the sale because they know they can quickly profit from it in the market. However, this may not be so bad: it creates a basic income for everyone in cryptocurrency, and if behavioral economics assumptions like the "endowment effect" have even a little accuracy, it will achieve the goal of ensuring token distribution is widespread.

Is Single-Round Sales Good?

Returning to the topic of "greed." I would say that, in principle, there are not many people opposed to a development team that can spend $500 million creating a great project that earns $500 million. What people oppose is: (i) a brand new untested development team receiving $50 million all at once; (ii) more importantly, the time lag between developer rewards and token buyer interests. In a single-round sale, developers only have one chance to receive funding for project creation, which is close to the time period when the development process begins. There is no feedback mechanism: the team first receives a small amount of funding to prove themselves, and then, after proving they are reliable and can succeed, they receive more funding over time. During the sale, the information for distinguishing excellent and poor development teams is relatively scarce, and once the sale is complete, the developers' motivation to continue working is lower compared to traditional companies. "Greed" does not refer to receiving a lot of money, but rather not putting in the effort to prove they can spend this money wisely while wanting to receive a large sum.

If you want to hit the nail on the head, how do we solve this? I would say the answer is simple: focus on mechanisms, not single-round sales.

I can propose several examples for reference:

Angelshares, this project sold in 2014, selling a fixed proportion of AGS daily over several months. Every day, people could provide unlimited funding to the crowdfunding project, and the daily AGS allocation would be divided among several contributors. Essentially, this is like maintaining hundreds of "small round trades" without a sales cap for nearly a year; I would say the duration of this sale could be extended even longer.

Mysterium, conducted a six-month small sale before the large-scale sale, which hardly anyone noticed.

Bancor, recently agreed to hand over all funding to market makers, allowing them to maintain the stability of the token price while capping the lowest price at 0.01 Ether. These funds cannot be withdrawn for two years.

It seems difficult to see the connection between Bancor's strategy and solving this time lag, but here is an element of that solution. To understand, consider two scenarios. In the first case, suppose a sale raises $30 million, with a cap of $10 million, but a year later everyone agrees the project has failed. In this case, the token price may drop below 0.01 Ether, and the market maker may lose all funds due to maintaining the minimum price, leaving the team with only $10 million in operating funds. In the second case, suppose the sale raises $30 million, with a cap of $10 million, and two years later everyone is satisfied with the project. In this case, the market maker would not be triggered, and the team could receive all $30 million in funds.

A related proposal comes from Vlad Zamfir's "safe token sale mechanism." This concept is broad and can be parameterized in various ways, but one way is to sell tokens at the highest price, then receive slightly below the highest price as the minimum price, and then gradually widen the gap between the two prices over time; if the price can maintain itself, development funds are gradually released.

The above three may not be sufficient. We want to extend the duration of the sale projects, allowing us more time to understand which development teams are the most trustworthy before providing a large amount of funding. However, this seems to be the most fruitful direction to explore.

Breaking the Dilemma

Summarizing the above analysis, it can be clearly concluded that although the above dilemmas and trilemmas cannot be directly overcome, they can be gradually broken through by innovative thinking and overcoming less severe similar issues. We can reach consensus on participation, using time as the third dimension to eliminate the impact: if you did not participate in the N-th round sale, you can wait for the N+1 round a week later, when the price may not differ much.

We can conduct sales without caps, but must include different cycles, setting no cap on sales within each cycle; thus, without proving the ability to handle small amount sales, the team will not demand large amounts of funding. We can sell small portions of tokens at once, automatically selling the remaining supply according to a pre-set formula through contract agreements, eliminating the political uncertainty it brings.

Here are some feasible mechanisms that follow these ideas:

Conduct a reverse Dutch auction similar to Gnosis, setting a lower cap (e.g., one million dollars). If the auction sells less than 100% of the total supply of tokens, the remaining funds will automatically transfer to another auction two months later, setting a cap 30% higher. Repeat this process until all issued tokens are sold.

Sell tokens at a price of X dollars without limit, depositing 90% of the proceeds into a smart contract, guaranteeing its minimum price at 0.9 times X over five years, while the maximum price can increase indefinitely, and the minimum price can approach zero.

Imitate AngelShares' approach, but extend the time to five years instead of months.

Conduct a reverse Dutch auction similar to Gnosis; if the auction sells less than 100% of the total supply of tokens, transfer the remaining funds to an automatic market maker to maintain the stability of the token price (if the price continues to rise, the market maker can sell tokens, with part of the proceeds going to the development team).

Immediately transfer all tokens to market makers, setting parameters and X variables (X being the minimum price), s (the share of tokens sold), t (the time the sale has been ongoing), T (the expected duration of the sale, e.g., five years), to sell tokens at a price of k / (t/T - s) (this is a bit strange, perhaps requiring economic analysis).

Note that other mechanisms for solving the token sale issue must also be attempted, such as handing over proceeds to multiple custodians, only releasing funds once a certain threshold is reached; this idea is interesting and worth exploring further. However, the design space is multidimensional, and there are many ways to try.

Translation: Annie_Xu

Although the ideas behind the current Ethereum protocol have been relatively stable for two years, Ethereum did not suddenly appear with its current concept fully formed. Before the blockchain was launched, the protocol underwent many significant developments and design decisions. The purpose of this article will be to introduce the various evolutions the protocol underwent from its inception to its release; the countless work done in terms of protocol implementation, such as Geth, cppethereum, pyethereum, and EthereumJ, as well as the history of applications and businesses in the Ethereum ecosystem, are deliberately beyond the scope.

The history of Casper and sharding research is also outside the scope. While we could certainly publish more blog posts discussing the various ideas proposed and abandoned by Vlad, Gavin, myself, and others, including "proof of work," hub-and-spoke chains, hypercubes, shadow chains (arguably... plasma), chain fibers, and various iterations of Casper, as well as the rapidly evolving thoughts of Vlad regarding the incentives and properties of actors in consensus protocols, this would also be too complex a story to tell in one article, so we will omit it for now.

Let’s start with the earliest version that ultimately became Ethereum, when it was not even called Ethereum. When I visited Israel in October 2013, I spent quite a bit of time with the Mastercoin team and even suggested some features to them. After spending some time thinking about what they were doing, I submitted a proposal to make their protocol more general, supporting more types of contracts without adding the same large and complex feature set:

https://web.archive.org/web/20150627031414/http://vbuterin.com/ultimate_scripting.html

Note that this is far from the later broader vision of Ethereum: it purely focused on the area that Mastercoin was already trying to focus on, namely bilateral contracts, where party A and party B would both put in funds, and then they would receive funds according to some formula specified in the contract (for example, a bet might say "if X happens, give all funds to A, otherwise give all funds to B"). The scripting language was not Turing complete.

The Mastercoin team was impressed, but they were not interested in abandoning everything they were doing to move in this direction, and I became increasingly convinced that this was the right choice. A second version emerged around December:

https://web.archive.org/web/20131219030753/http://vitalik.ca/ethereum.html

Here, you can see the result of a major reorganization, primarily the result of my hiking trip to San Francisco in November, when I realized that smart contracts had the potential to be fully generalized. The scripting language was not just a way to describe the terms of a relationship between two parties; the contracts themselves were fully-fledged accounts capable of holding, sending, and receiving assets, and even maintaining permanent storage (at the time, permanent storage was referred to as "memory," and the only temporary "memory" was 256 registers). This language transitioned from a stack-based machine to a register-based machine according to my own will; I had no objections to this, I just felt it seemed more complex.

Additionally, note that there is now a built-in fee mechanism:

At this point, Ether is essentially gas; after every computational step, the contract balance called by the transaction decreases a little, and if the contract funds run out, execution stops. Note that this "receiver pays" mechanism means that the contract itself must require the sender to pay a fee to the contract, and if this fee does not exist, it exits immediately; the protocol specifies 16 free execution steps, allowing contracts to reject non-paying transactions.

This was when the Ethereum protocol was entirely my own creation. However, from here, new participants began to join the circle. So far, the most prominent in terms of etiquette is Gavin Wood, who contacted me in December 2013 with a message about my work.

“Hey Jeremy, great to see you interested in Ethereum…”

Gavin's initial contributions were twofold. First, you may notice that the contract call model in the original design was asynchronous: while contract A could create an "internal transaction" to contract B (the term "internal transaction" is jargon from Etherscan; initially, they were just called "transactions," later referred to as "message calls" or "calls"), the internal transaction would only begin executing once the first transaction had fully executed. This meant that transactions could not use internal transactions as a way to obtain information from other contracts; the only way to do this was the EXTRO opcode (somewhat like SLOAD, which could be used to read the storage of other contracts), which was later removed with the support of Gavin and others.

When implementing my initial specification, Gavin naturally synchronized the implementation of internal transactions, not even realizing the intent was different—that is, in Gavin's implementation, when one contract calls another, the internal transaction is executed immediately, and once execution is complete, the VM returns to the contract that created the internal transaction and continues with the next opcode. This approach seemed superior to both of us, so we decided to make it part of the specification.

Second, a discussion between him and me (during a walk in San Francisco, so the exact details will forever be lost to the winds of history, although there may be one or two copies in the NSA's deep archives) led to a reworking of the transaction fee model, shifting from the "contract pays" method to the "sender pays" method and switching to a "gas" architecture. Instead of each individual transaction step immediately taking away a little Ether, the transaction sender pays and is allocated some "gas" (roughly speaking, a counter of computational steps), and the computational steps are drawn from the allowed amount of that gas. If a transaction runs out of gas, the gas is still forfeited, but the entire execution is reverted; this seems to be the safest approach, as it eliminates a whole class of "partial execution" attacks that contracts previously had to worry about. When the transaction execution is complete, any unused gas fees are refunded.

Gavin can also largely be credited with the subtle shift in vision, from viewing Ethereum as a platform for building programmable currency, where contracts based on the blockchain can hold digital assets and transfer them according to pre-set rules, to a general computing platform. This began with subtle shifts in focus and terminology, and later this influence became stronger with the increasing emphasis on the overall "Web 3," which views Ethereum as part of a set of decentralized technologies, the other two being Whisper and Swarm.

In early 2014, there were also some changes suggested by others. After Andrew Miller and others proposed the idea, we ultimately returned to a stack-based architecture.

Charles Hoskinson suggested switching from Bitcoin's SHA256 to the newer SHA3 (or more accurately, keccak256). While there was some controversy for a time, discussions with Gavin, Andrew, and others led to the establishment that the size of values on the stack should be limited to 32 bytes; another option being considered, infinite-sized integers, had the problem that it was difficult to calculate how much addition, multiplication, and other operations would cost.

As early as January 2014, the initial mining algorithm in our minds was a device called Dagger:

https://github.com/ethereum/wiki/blob/master/Dagger.md

Dagger is named after the mathematical structure "Directed Acyclic Graph" (DAG) used in the algorithm. The idea is that every N blocks, a new DAG will be pseudo-randomly generated from a seed, and the underlying DAG will be a collection of nodes that require several thousand gigabytes to store. However, generating any single value in the DAG only requires computing a few thousand entries. "Dagger computation" involves fetching some values from random positions in the underlying dataset and hashing them together. This means there is a fast way to perform DAG computations—data is already in memory, and a slow but memory-free way—regenerating each value you need from the DAG from scratch.

The purpose of this algorithm is to have the same "memory hardness" property as the algorithms popular at the time (like Scrypt), while still being lightweight client-friendly. Miners would use the fast way, so their mining would be limited by memory bandwidth (theoretically, consumer-grade RAM has already been heavily optimized, making it difficult to further optimize with ASICs), but lightweight clients could use the memory-free but slower version for verification. The fast method might take a few microseconds, while the slow but memory-free method might take a few milliseconds, so it remains quite feasible for lightweight clients.

From here, the algorithm would change several times during Ethereum's development. The next idea we went through was "adaptive proof of work"; here, proof of work would involve executing randomly selected Ethereum contracts, and there was a clever reason to explain why this would be ASIC-resistant: if ASICs were developed, competing miners would have the incentive to create and publish many contracts that ASICs are not good at executing. The story is that there are no ASICs for general computation because it is just a CPU, so we can use this opposing incentive mechanism to prove work that is essentially executing general computation.

The reason for failure is simple: long-range attacks. An attacker can start a chain from block 1, filling it with simple contracts for which they can create dedicated hardware, and quickly surpass the main chain. Thus... back to the drawing board.

The next algorithm was called random circuits, described in a Google document here, proposed by me and Vlad Zamfir, and analyzed by Matthew Wampler-Doty and others. The idea here was also to simulate general computation in mining algorithms, this time by executing randomly generated circuits. There is no conclusive evidence that something based on these principles cannot work, but we were quite pessimistic about this from the computer hardware experts we contacted in 2014. Matthew Wampler-Doty himself proposed a proof of work based on SAT solving, but this was also ultimately rejected.

Finally, we circled back to an algorithm called "Dagger Hashimoto." Sometimes referred to as "Dashimoto," it drew on many of Thaddeus Dryja's work on proof of work, which pioneered the concept of "I/O bound proof of work," where the main limiting factor on mining speed is not hashes per second, but megabytes of RAM accessed per second. However, it combined the concept of Dagger's lightweight client-friendly DAG generation dataset. After several rounds of adjustments by me, Matthew, Tim, and others, these ideas ultimately coalesced into what we now call the algorithm Ethash.

By the summer of 2014, the protocol was quite stable, with the main exception being that the proof of work algorithm did not reach the Ethash stage until early 2015, and the semi-formal specification existed in Gavin's yellow paper.

In August 2014, I developed and introduced a mechanism that allowed Ethereum's blockchain to have shorter block times and higher capacity while reducing centralization risks. This was introduced as part of PoC6.

Discussions with the Bitshares team led us to consider adding a stack as a first-class data structure, although due to time constraints, we ultimately did not do so, but later security audits and DoS attacks would show that doing this securely was actually much more difficult than we had imagined at the time.

In September, Gavin and I planned the next two major changes in protocol design. First, in addition to the state tree and transaction tree, each block would also contain a "receipt tree." The receipt tree would include hashes of logs created by transactions, as well as the intermediate state root. The logs would allow transactions to create "outputs," which are stored on the blockchain and can be accessed by lightweight clients but cannot be accessed by future state computations. This could be used to allow decentralized applications to easily query events such as token transfers, purchases, creation and completion of trade orders, auction starts, and so on.

Other ideas were also considered, such as creating a Merkle tree from the entire execution trace of a transaction to allow proof of anything; the choice of logs was made because they are a compromise between simplicity and completeness.

The second idea was the concept of "precompiles," which addressed the issue of allowing complex cryptographic computations to be available in the EVM without having to deal with EVM overhead. We also went through many more ambitious ideas of native contracts—"if miners optimized the execution of certain contracts, they could 'vote' to lower the gas price of those contracts, so contracts that most miners could execute faster would naturally have lower gas prices; however, all these ideas were rejected because we could not come up with a cryptoeconomic secure way to implement such things. Attackers could always create contracts that execute some trapdoor cryptographic operations, distribute the trapdoors to themselves and their friends to allow them to execute that contract faster, then vote to lower the gas price and use it to deny the network. Instead, we chose a less ambitious approach, specifying a small number of precompiles in the protocol for common operations like hashing and signature schemes.

Gavin was also a major advocate for the development of the idea of protocol abstraction—moving many parts of the protocol (such as Ether balances, transaction signature algorithms, randomness, etc.) into contracts within the protocol itself, with the theoretical ultimate goal being to reach a point where the entire Ethereum protocol could be described as function calls to a virtual machine with some pre-initialized state. There was not enough time to get these ideas into the initial Frontier version, but these principles were expected to begin to be slowly integrated through some changes in Constantinople, Casper contracts, and sharding specifications.

This was all implemented in PoC7; after PoC7, the protocol did not change much except for some minor but in some cases important details discovered through security audits...

In early 2015, Jutta Steiner and others organized pre-release security audits, which included software code audits and academic audits. The software audits primarily targeted the C++ and Go implementations, respectively overseen by Gavin Wood and Jeffrey Wilcke, although there was also a smaller audit targeting my pyethereum implementation. In the two academic audits, one was conducted by Itai Eyal (famous for "selfish mining"), and the other was conducted by Andrew Miller and other less authoritative figures. The Eyal audit led to a small protocol change: the total difficulty of a chain would not include uncles. This least authority audit focused more on smart contracts and gas economics, as well as Patricia trees. This audit led to several protocol changes. A small example is using sha3(addr) and sha3(key) as trie keys instead of directly using addresses and keys; this made worst-case attacks on the trie more difficult.

This is a warning that may be a bit ahead of its time...

Another important issue we discussed was the gas limit voting mechanism. At the time, we were already worried about the lack of progress in the Bitcoin block size debate and wanted Ethereum to have a more flexible design that could adjust as needed. But the challenge was: what is the optimal limit? My initial idea was to create a dynamic limit that locks the target at 1.5 times the long-term exponentially moving average of actual gas consumption, so that on average, the data blocks would be filled to 23. However, Andrew pointed out that this could be exploited in some ways—specifically, miners wanting to raise the limit could simply include transactions consuming a lot of gas in their own blocks but take very little time to process, thus always creating full blocks without increasing their own costs. Therefore, the security model, at least in the upward direction, was equivalent to simply letting miners vote to decide the gas limit.

We did not come up with a gas limit strategy that was unlikely to be breached, so Andrew's recommended solution was simply to let miners explicitly vote on the gas limit, with the default voting strategy set to the 1.5 times moving average rule. The rationale was that we still did not know the correct way to set the maximum gas limit, and the risk of any specific method failing seemed greater than the risk of miners abusing their voting rights. Therefore, we might as well let miners vote on the gas limit and accept the risk of it being set too high or too low in exchange for the benefits of flexibility and the ability for miners to cooperate to quickly raise or lower the limit as needed.

This increased the opportunity for market manipulation, as manipulators could not only waste their money fighting a single equilibrium but could indeed successfully push a given currency from one equilibrium to another and profit from the successful "prediction" that led to this shift. This also meant that there was a lot of path dependence, and established brands were very important; witness the epic battle over which branch of the Bitcoin blockchain could be called Bitcoin, to give one particularly striking example.

Another perhaps more important conclusion is that the market cap of appcoins critically depends on holding time H. If someone creates a very efficient exchange that allows users to buy appcoins in real-time and then immediately use them in the application, and then allows sellers to cash out immediately, then the market cap will plummet. If a currency is stable or has optimistic prospects, this may not matter, as users actually prefer holding tokens over holding anything else (i.e., zero "effective cost"), but if the prospects begin to turn sour, then such a well-functioning exchange may accelerate its demise.

You might think exchanges are inherently inefficient, requiring users to create accounts, log in, deposit coins, wait for 36 confirmations, trade, and log out, but in fact, ultra-efficient exchanges are about to emerge. Here is a thread discussing the design of fully autonomous synchronous on-chain transactions that can convert token A to token B and even possibly use token B to do something, in a single transaction. Many other platforms are also under development.

All of this suggests that relying purely on the argument of exchange media to support token value, while attractive because it seems to have the ability to print money out of thin air, is ultimately very fragile. Due to irrationality and the implicit zero cost of holding tokens, protocols using this model may last for a while, but it is a model that always carries the inevitable risk of collapsing at any time.

So what are the alternatives? A simple alternative is the etherdelta method, where the application simply charges fees in the interface. A common criticism is: but can't someone fork the interface and take the fees out? A rebuttal is: someone can also use ETH, BTC, DOGE, or whatever users prefer to use instead of your protocol token. People can make a more complex argument that is difficult because "pirated" versions must compete with the "official" version for network effects, but people can also easily create an official paid client that refuses to interact with non-paying clients; this execution method based on network effects is similar to the typical VAT enforcement methods in Europe and elsewhere. Official client buyers will not interact with non-official client sellers, and official client sellers will not interact with non-official client buyers, so a large group of users would need to simultaneously switch to the "pirated" client to successfully evade fees. This is not very robust, but it is certainly as good as creating new protocol tokens.

If developers want upfront revenue to fund initial development, they can sell tokens and use all paid fees to buy back some tokens and burn them; this would support the tokens with the future expected value of the upcoming fees spent within the system. This design can be transformed into a more direct utility token by requiring users to pay with utility tokens, and if users do not have tokens, the interface can automatically purchase tokens using exchanges.

Importantly, for tokens with stable values, it is very beneficial for the token supply to have the characteristic of sinking—where tokens actually disappear, so the total amount of tokens decreases over time. This way, there are more transparent and clearer fees paid by users, rather than highly variable, hard-to-calculate "effective costs," and there is also a more transparent and clearer way to calculate what the value of the protocol token should be.

November 19, 2022

The earliest attempts by exchanges to prove to users that they are not cheating can be traced back a long time. In 2011, the largest Bitcoin exchange MtGox proved they had funds in a transaction that moved to address 424242 that had been pre-announced. In 2013, discussions began about how to address the other side of the problem: proving the total scale of customer deposits. If you prove that customer deposits equal X ("proof of liabilities") and prove ownership of the private keys to X coins ("proof of assets"), then you have a proof of solvency: you have proven that the exchange has enough funds to repay all depositors.

The simplest way to prove deposits is to simply publish a list of (username, balance) pairs. Each user can check whether their balance is included in the list, and anyone can check the complete list to see (i) that each balance is non-negative, and (ii) that the sum is the required amount. Of course, this violates privacy, so we can slightly modify the scheme: publish (hash(username, salt), balance) pairs and privately send each user their salt value. But even this leaks balances and reveals patterns of balance changes. The desire to protect privacy led us to the next invention: Merkle tree technology.

Merkle tree technology involves placing the customer balance table into a Merkle sum tree. In a Merkle sum tree, each node is a (balance, hash) pair. The underlying leaf nodes represent individual customer balances and salted username hashes. In each higher-level node, the balance is the sum of the two balances below, and the hash is the hash of the two nodes below. Like Merkle proofs, Merkle sum proofs are branches of the tree, consisting of sister nodes along the path from leaf to root.

Exchanges will send each user a Merkle sum proof of their balance. Then, users will ensure that their balance is correctly included in the total. A simple example code implementation can be found here.

# The function for computing a parent node given two child nodes
def combine_tree_nodes(L, R):
    L_hash, L_balance = L
    R_hash, R_balance = R
    assert L_balance >= 0 and R_balance >= 0
    new_node_hash = hash(
        L_hash + L_balance.to_bytes(32, 'big') +
        R_hash + R_balance.to_bytes(32, 'big')
    )
    return (new_node_hash, L_balance + R_balance)

# Builds a full Merkle tree. Stored in flattened form where
# node i is the parent of nodes 2i and 2i+1
def build_merkle_sum_tree(user_table: "List[(username, salt, balance)]"):
    tree_size = get_next_power_of_2(len(user_table))
    tree = (
        [None] * tree_size +
        [userdata_to_leaf(*user) for user in user_table] +
        [EMPTY_LEAF for _ in range(tree_size - len(user_table))]
    )
    for i in range(tree_size - 1, 0, -1):
        tree[i] = combine_tree_nodes(tree[i*2], tree[i*2+1])
    return tree

# Root of a tree is stored at index 1 in the flattened form
def get_root(tree):
    return tree[1]

# Gets a proof for a node at a particular index
def get_proof(tree, index):
    branch_length = log2(len(tree)) - 1
    # ^ = bitwise xor, x ^ 1 = sister node of x
    index_in_tree = index + len(tree) // 2
    return [tree[(index_in_tree // 2**i) ^ 1] for i in range(branch_length)]

# Verifies a proof (duh)
def verify_proof(username, salt, balance, index, user_table_size, root, proof):
    leaf = userdata_to_leaf(username, salt, balance)
    branch_length = log2(get_next_power_of_2(user_table_size)) - 1
    for i in range(branch_length):
        if index & (2**i):
            leaf = combine_tree_nodes(proof[i], leaf)
        else:
            leaf = combine_tree_nodes(leaf, proof[i])
    return leaf == root

The privacy leakage in such designs is much lower than a completely public list, and can be further reduced by adjusting branches each time the root is published, but some privacy leakage still exists: Charlie learns that someone has a balance of 164 ETH, some two users' balances total 70 ETH, and so on. An attacker controlling many accounts still has the potential to learn a lot about the exchange's users.

An important subtlety of this scheme is negative balances: if an exchange with 1390 ETH in customer balances but only 890 ETH in reserves tries to make up the difference by adding a -500 ETH balance under some false account in the tree, what happens? It turns out that this possibility does not break the scheme, although this is why we specifically need a Merkle sum tree rather than a regular Merkle tree. Suppose Henry is a false account controlled by the exchange, and the exchange puts -500 ETH there.

Greta's proof verification will fail: the exchange will have to give her Henry's -500 ETH node, and she will reject it as invalid. Eve and Fred's verifications will also fail because the total ETH above Henry will be -230, making it invalid as well! To escape theft, the exchange would have to hope that no one checks their balance proofs in the entire right half of the tree.

If the exchange can identify 500 users they are confident are either too lazy to check the evidence or will not be believed when they complain about never receiving evidence, they could escape theft. However, the exchange could also exclude these users from the tree and achieve the same effect. Thus, Merkle tree technology is essentially the best level that a debt proof scheme can achieve if merely achieving debt proof is the goal. But its privacy properties are still not ideal. You could go further and use Merkle trees more cleverly, such as making every single leaf a separate leaf, but ultimately with more modern techniques, there are better ways.

ZK-SNARKs are a powerful technology. The impact of ZK-SNARKs on cryptography is akin to transformers in artificial intelligence: a general technology so powerful that it will completely defeat a series of application-specific technologies, solving a range of problems developed decades ago. Therefore, of course, we can use ZK-SNARKs to greatly simplify and improve the privacy of proof of solvency protocols.

The simplest thing we can do is place all users' deposits into a Merkle tree (or more simply, a KZG commitment), and use ZK-SNARKs to prove that all balances in the tree are non-negative and sum to a claimed value. If we add a layer of hashing for privacy, each user's Merkle branch (or KZG proof) will show nothing about the balances of other users.

The simplest version of asset proof is the protocol we saw above: to prove you hold X coins, you simply move X coins in a transaction that either occurs at a pre-agreed time or contains the phrase "these funds belong to Binance" in the data field. To avoid paying transaction fees, you can sign an off-chain message; both Bitcoin and Ethereum have standards for... off-chain message signing.

This simple asset proof technique has two practical problems:

• Handling cold storage

• Parallel double spending

For security reasons, most exchanges "cold store" the vast majority of customer funds: on offline computers, transactions require manual signatures and are uploaded to the internet. Literal air gaps are common: my cold storage setup for personal funds involved a permanently offline computer that generated a QR code containing signed transactions, which I would scan from my phone. Given the high value involved, the security protocols used by exchanges are crazier, often involving multi-party computation across several devices to further reduce the chances of a single device being hacked and leaking keys. Given this setup, creating an additional message to prove control over an address is an expensive operation!

Exchanges have several avenues:

• Retain some public long-term use addresses. The exchange generates several addresses, publishes a proof of ownership for each address once, and then reuses those addresses. This is by far the simplest option, although it adds some constraints on how to protect security and privacy.

• Have many addresses, randomly prove a few. The exchange will have many addresses, possibly even using each address only once and reclaiming it after one transaction. In this case, the exchange may have a protocol where a few addresses are randomly selected from time to time and must be "opened" to prove ownership. Some exchanges have already done something similar through auditors, but in principle, this technique could be turned into a fully automated program.

• More complex ZKP options. For example, the exchange could set all its addresses to 2-of-1 multisig, where one key for each address is different, and the other is a hidden version of some "large" emergency backup key stored in a very high-security manner, such as 16-of-12 multisig. To protect privacy and avoid exposing its entire address set, the exchange could even run zero-knowledge proofs on the blockchain, proving the total balance of all addresses in this format.

Another major issue is preventing incidental double spending. It is easy for exchanges to pass collateral back and forth between each other to prove reserves, allowing them to pretend to be solvent when they are not. Ideally, proof of solvency would be done in real-time and updated after each freeze. If this is impractical, the next best approach is to coordinate a fixed schedule between different exchanges, for example, proving reserves every Tuesday at 1400 UTC.

The last question is: Can you do asset proof on fiat? Exchanges hold not only cryptocurrencies but also fiat currency within the banking system. Here, the answer is: yes, but such a program will inevitably rely on a "fiat" trust model: banks themselves can prove balances, auditors can prove balance sheets, and so on. Given that fiat cannot be verified with cryptography, this is the best that can be done within this framework, but it is still worth doing.

Another approach is to completely separate one entity from another (USDC itself), where the former operates the exchange, handling USDC and other asset-backed stable accounts, while the latter handles the cash flow processes between the crypto and traditional banking systems. Since USDC's "liabilities" are just ERC20 tokens on-chain, proof of liabilities is "free," requiring only proof of assets.

Suppose we want to go further: we do not want to merely prove that the exchange has funds to repay its users. Instead, we want to completely prevent exchanges from stealing user funds.

The first significant attempt at this was plasma, a scaling solution popular in the Ethereum research circle in 2017 and 2018. The way plasma works is by dividing balances into a set of independent "coins," each assigned an index and located at a specific position in the Merkle tree of the plasma block. Effectively transferring a coin requires placing the transaction in the correct position in the tree, the root of which is published on-chain.

A simplified diagram of plasma. Coins are held in a smart contract that executes the rules of the plasma protocol upon withdrawal.

OmiseGo attempted to build a decentralized exchange on this protocol, but since then, they have shifted to other ideas—in this regard, the plasma group itself is now an optimistic EVM rollup project Optimism.

It is not worth looking at the technical limitations of plasma conceived in 2018 (e.g., proof of coin defragmentation) as some moral story about the whole concept. Since the peak of plasma discourse in 2018, ZK-SNARKs have become more feasible for scale-related use cases, as we mentioned above, ZK-SNARKs change everything.

A more modern version of the plasma idea is what Starkware calls [validium](https://ethereum.org