帐号和无UTXOs

比特币和它的很多衍生物，存储用户的余额都是基于未消费的交易输出 unspent tx outputs(UTXOs)：整个系统的状态就是由UTXOs来组成（可以把它想象成“币”），这样每个币都有所有者和价值，每一个交易需要一个多个币，并创造出一个或多个币，它们依赖如下的验证约束：

1. 每个相关输入必须有效并且未花费
2. 每个交易必须有签名，并且符合每个输入的所有者的
3. 总的输入等于输出

Bitcoin, along with many of its derivatives, stores data about users' balances in a structure based on unspent transaction outputs (UTXOs): the entire state of the system consists of a set of "unspent outputs" (think, "coins"), such that each coin has an owner and a value, and a transaction spends one or more coins and creates one or more new coins, subject to the validity constraints:
Every referenced input must be valid and not yet spent
The transaction must have a signature matching the owner of the input for every input
The total value of the inputs must equal or exceed the total value of the outputs

用户的“余额”就是总的这些“币”，并且用户可以提供私钥来产生有效的签名。

A user's "balance" in the system is thus the total value of the set of coins for which the user has a private key capable of producing a valid signature.

(Image from https://bitcoin.org/en/developer-guide)

以太坊拒绝了这种方法，而采用了一种简单的办法：每个账户有一个balance状态，和以太坊特定的数据一样（code和内部storage），如果发送方有足够的余额支付，那么一个tx是有效的，发送方扣除金额，接受方记入金额。如果接受方还有代码，代码执行，内部状态可能还会变化，并且可能会发送额外的消息到其它账户，导致进一步的扣款和收款。

Ethereum jettisons this scheme in favor of a simpler approach: the state stores a list of accounts where each account has a balance, as well as Ethereum-specific data (code and internal storage), and a transaction is valid if the sending account has enough balance to pay for it, in which case the sending account is debited and the receiving account is credited with the value. If the receiving account has code, the code runs, and internal storage may also be changed, or the code may even create additional messages to other accounts which lead to further debits and credits.
The benefits of UTXOs are:

UTXOs的好处：

1. 高度的隐私：如果用户使用一个新地址来做交易，比较难把它和其他账户关联起来。这非常适用于货币，但是对于dapps就太武断，因为dapps经常会涉及到记录复杂的一系列用户状态，并不是像货币那样的简单的状态。
2. 潜在的扩展范式：UTXOs理论上更兼容特定的可扩展性范式，我们可以仅仅依靠一些币的所有者来维护Merkle proof的所有权，即使每个人包括所有者决定忘记这些数据，也只有所有者受害。在账户范式中，每一个丢失了Merkle tree对应一个账户部分的人，就不能处理影响到这个账户的操作，包括给它发送消息。尽管如此，非UTXO依赖的扩展范式也是存在的。

Higher degree of privacy: if a user uses a new address for each transaction that they receive then it will often be difficult to link accounts to each other. This applies greatly to currency, but less to arbitrary dapps, as arbitrary dapps often necessarily involve keeping track of complex bundled state of users and there may not exist such an easy user state partitioning scheme as in currency.

Potential scalability paradigms: UTXOs are more theoretically compatible with certain kinds of scalability paradigms, as we can rely on only the owner of some coins maintaining a Merkle proof of ownership, and even if everyone including the owner decides to forget that data then only the owner is harmed. In an account paradigm, everyone losing the portion of a Merkle tree corresponding to an account would make it impossible to process messages that affect that account at all in any way, including sending to it. However, non-UTXO-dependent scalability paradigms do exist.

The benefits of accounts are:

账户的好处：

1. 节省大量空间：例如，如果一个账户有5个UTXO，然后切换UTXO模式到账户模式可以减少的空间是(20 + 32 + 8) * 5 = 300 bytes(20 for the address, 32 for the txid and 8 for the value) 到 20 + 8 + 2 = 30 bytes (20 for the address, 8 for the value, 2 for a nonce(see below))。在实际中，可能没有这么多，因为账户需要存储在Patricia tree (see below) ，但是依然节省了大量空间。另外，交易可以变小（例如：以太坊100 bytes VS. 200-250 bytes比特币)，因为每一个交易只需要一个引用，一个签名和产生一个输出。

Large space savings: for example, if an account has 5 UTXO, then switching from a UTXO model to an account model would reduce the space requirements from (20 + 32 + 8) * 5 = 300 bytes (20 for the address, 32 for the txid and 8 for the value) to 20 + 8 + 2 = 30 bytes (20 for the address, 8 for the value, 2 for a nonce(see below)). In reality savings are not nearly this massive because accounts need to be stored in a Patricia tree (see below) but they are nevertheless large. Additionally, transactions can be smaller (eg. 100 bytes in Ethereum vs. 200-250 bytes in Bitcoin) because every transaction need only make one reference and one signature and produces one output.

2. 更大的替换性：因为这里没有区块链意义上的币，所以UTXO变得不符合实际，无论是技术上还是法律上，需要去建立红名单／黑名单计划，去区分币的来源。

Greater fungibility: because there is no blockchain-level concept of the source of a specific set of coins, it becomes less practical, both technically and legally, to institute a redlist/blacklisting scheme and to draw a distinction between coins depending on where they come from.

3. 简单：容易编码和理解，尤其是一旦更复杂的脚本被引入。如果让所有的去中心化应用套用UTXO模式，本质上脚本来限制那种UTXO可以被消费，让脚本去执行包含消费的UTXO，这样的范式更复杂，而且丑陋。

Simplicity: easier to code and understand, especially once more complex scripts become involved. Although it is possible to shoehorn arbitrary decentralized applications into a UTXO paradigm, essentially by giving scripts the ability to restrict what kinds of UTXO a given UTXO can be spent to, and requiring spends to include Merkle tree proofs of change-of-application-state-root that scripts evaluate, such a paradigm is much more complicated and ugly than just using accounts.

4. 常量轻客户端引用：轻客户端可以在任何点引用所有和账户关联的数据，通过扫描状态树用特定的方法。在一个UTXO范式中，每个交易的引用变化，对于一个长期运行的dapps来讲，会造成特定的烦恼，如果采用上面讲的UTXO范式机制的话。

Constant light client reference: light clients can at any point access all data related to an account by scanning down the state tree in a specific direction. In a UTXO paradigm, the references change with each transaction, a particularly burdensome problem for long-running dapps that try to use the above mentioned state-root-in-UTXO propagation mechanism.

我们这样决定，因为我们要处理任意的状态和代码，帐户的优点要远远大于其他选择方案。另外，我们提到过“无特性”的原则，如果有人关心隐私，mixers和 coinjoin可以被内置通过在合约中加密数据包的方式。

We have decided that, particularly because we are dealing with dapps containing arbitrary state and code, the benefits of accounts massively outweigh the alternatives. Additionally, in the spirit of the We Have No Features principle, we note that if people really do care about privacy then mixers and coinjoin can be built via signed-data-packet protocols inside of contracts.

账户范式的一个弱点是，为了防止重放攻击，每一个交易都必须需要一个“序号”，账户需要跟踪这个序号的使用，如果序号比最后一个序号大一就接受这个序号。这意味着，长期未使用的账号不能被账户状态剔除。一个简单的解决办法是，包含交易的块号，让他们在一段时间内避免重放，一旦每段周期过后再重置nonce。矿工或者其他用户可以“ping”未使用的账户来从状态中删除他们，作为协议一部分来全扫描是非常昂贵的。我们没有实现这个机制只是为了加速1.0的开发；在1.1或者后续的版本会有这样的系统。

译者注：关于更多tx的nonce的资料，有一个有趣的问题。
What happens when a transaction nonce is too high?

这是有人做的总结：
Summary

• Transactions with too low a nonce get immediately rejected.

• Transactions with too high a nonce get placed in the transaction pool queue.

• I If transactions with nonces that fill the gap between the last valid nonce and the too high nonce are sent and the nonce sequence is complete, all the transactions in the sequence will get processed and mined.

• When the geth instances are shut down and restarted, transactions in the transaction pool queue disappear.

• The transaction pool queue will only hold a maximum of 64 transactions with the same From:
  address with nonces out of sequence.

• The geth instance can be crashed by filling up the transaction pool queue with 64 transactions with the same From:

  • address with nonces out of sequence by, for example:Creating many accounts with a minimal amount of ethers (0.05 ETH in my tests)
  • Sending 64 transactions from each account with a large data payload
  • For the 4 Gb memory limit that I placed on my geth instance, 400 x 64 transactions with a payload of about 4,500 bytes would crash the geth instance (from my limited testing anyway).
  • These transactions with too high a nonce do NOT propagate to other nodes and crash other nodes on the Ethereum network.

• The Ethereum World Computer cannot be brought down with transactions with too high a nonce. Good work, developers!

具体的实验方法可以参考链接：http://ethereum.stackexchange.com/questions/2808/what-happens-when-a-transaction-nonce-is-too-high。

One weakness of the account paradigm is that in order to prevent replay attacks, every transaction must have a "nonce", such that the account keeps track of the nonces used and only accepts a transaction if its nonce is 1 after the last nonce used. This means that even no-longer-used accounts can never be pruned from the account state. A simple solution to this problem is to require transactions to contain a block number, making them un-replayable after some period of time, and reset nonces once every period. Miners or other users will need to "ping" unused accounts in order to delete them from the state, as it would be too expensive to do a full sweep as part of the blockchain protocol itself. We did not go with this mechanism only to speed up development for 1.0; 1.1 and beyond will likely use such a system.