English
10470
|
Bitcoin and its many derivatives, the user's balance is stored based onunspent tx outputs(UTXOs): The state of the entire system is composed of UTXOs (think of it as a "coin"), so that each coin has an owner and a value. Each transaction requires one or more coins and creates one or more coins. They rely on the following verification constraints: 1. Each relevant input must be valid and unspent 2. Each transaction must be signed and matched by the owner of each input 3. Total input equals output The user's "balance" is the total of these "coins", and the user can provide a private key to generate a valid signature.  (Image from https://bitcoin.org/en/developer-guide) Ethereum rejected this approach and adopted a simple approach: each account has a balance state, which is the same as Ethereum-specific data (code and internal storage). If the sender has enough balance to pay, then a tx is valid, the sender deducts the amount, and the recipient credits the amount. If the recipient still has code and the code is executed, the internal state may change and additional messages may be sent to other accounts, resulting in further deductions and collections. Benefits of UTXOs: 1. High degree of privacy: If a user uses a new address to make transactions, it is more difficult to associate it with other accounts. This works well for currencies, but is too arbitrary for dapps, because dapps often involve recording a complex series of user states, not simple states like currencies. 2. Potential scalability paradigm: UTXOs are theoretically more compatible with specific scalability paradigms. We can only rely on the owners of some coins to maintain the ownership of the Merkle proof. Even if everyone including the owner decides to forget this data, only the owner will suffer. In the account paradigm, everyone who loses the part of the Merkle tree corresponding to an account cannot process operations that affect this account, including sending messages to it. Nonetheless, extension paradigms that are not dependent on UTXO also exist. Account benefits: 1. Save a lot of space: For example, if an account has 5 UTXO, then switching UTXO mode to account mode can reduce the space by (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 practice, there may not be so many, since the accounts need to be stored in the Patricia tree (see below), but it still saves a lot of space. Additionally, transactions can be made smaller (eg: 100 bytes for Ethereum vs. 200-250 bytes for Bitcoin) because each transaction only requires one reference, one signature and produces one output. 2. Greater replaceability: Because there is no currency in the blockchain sense, UTXO becomes unrealistic. Whether technically or legally, a red list/blacklist plan needs to be established to distinguish the source of the currency. 3. Simplicity: Easy to code and understand, especially once more complex scripts are introduced. If all decentralized applications were to apply the UTXO model, in essence, scripts would limit which UTXOs could be consumed and let the scripts execute UTXOs that include consumption. This paradigm would be more complex and ugly. 4. Constant light client references: Light clients can reference all data associated with an account at any point, by scanning the state tree using specific methods. In a UTXO paradigm, the reference changes of each transaction will cause specific troubles for long-running dapps, if the UTXO paradigm mechanism mentioned above is adopted. We decided that since we were dealing with arbitrary states and tags, the advantages of accounts far outweighed the other options. Additionally, we mentioned the "featureless" principle, if one cares about privacy, mixers and coinjoin can be built in by encrypting packets in the contract. One weakness of the account paradigm is that in order to prevent replay attacks, each transaction must require a "sequence number". The account needs to track the use of this sequence number and accept this sequence number if the sequence number is one greater than the last sequence number. This means that accounts that have not been used for a long time cannot be removed from the account status. A simple solution is to include the transaction's block number so that they avoid replay for a period of time, and then reset the nonce once each period has elapsed. Miners or other users can "ping" unused accounts to remove them from status, and full scans as part of the protocol are very expensive. We did not implement this mechanism just to speed up the development of 1.0 ； There will be such a system in 1.1 or subsequent versions. 原文：https://github.com/ethereum/wiki/wiki/Design-Rationale#accounts-and-not-utxos Translator's note: Regarding more information about tx's nonce, there is an interesting question. What happens when a transaction nonce is too high? This is a summary someone made: Summary
For specific experimental methods, please refer to the link: http://ethereum.stackexchange.com/questions/2808/what-happens-when-a-transaction-nonce-is-too-high. |
|
|
|
|
|
