UTXO SO VỚI MÔ HÌNH TÀI KHOẢN
Để tiền kỹ thuật số hữu ích, nó cần phải được chuyển nhượng. Việc chuyển tiền trên blockchain được bắt đầu bởi chủ sở hữu, tạo ra một giao dịch. Giao dịch này thông báo cho mạng về số tiền đang đổi chủ và chủ sở hữu mới là ai.
Cho đến nay, chúng tôi đã giải thích những dữ liệu nào bao gồm một giao dịch khi chúng tôi xem blockchain như một cấu trúc dữ liệu. Khi chúng tôi nói về mật mã khóa công khai, chúng tôi đã đề cập đến cách quyền sở hữu được chứng minh và xác minh trên blockchain, một khía cạnh quan trọng của việc cho phép các giao dịch an toàn.
Trong bài viết này, chúng ta sẽ xem xét các mô hình kế toán / cân bằng được sử dụng trong blockchain. Chúng tôi đã giới thiệu mô hình UTXO thường được sử dụng trong Cấp độ nâng cao của chúng tôi và giả định kiến thức cơ bản về nó cho bài viết này. Phương pháp thứ hai để theo dõi số dư người dùng, như được áp dụng trong Ethereum, là mô hình tài khoản.
Chúng tôi sẽ bắt đầu bằng cách xem xét sự tương đồng của chúng và sau đó đi sâu vào từng mô hình riêng lẻ. Cuối cùng, chúng tôi sẽ so sánh hai mô hình và chỉ ra ngắn gọn cách chúng có thể được kết hợp để tạo ra một hệ thống lai.
Blockchain là một cỗ máy nhà nước
Trước khi chúng ta đi vào các mô hình cân bằng khác nhau, thật hợp lý khi lùi lại một bước và nhìn vào blockchain theo các thuật ngữ chung hơn - như một cỗ máy nhà nước.
Theo Wikipedia, "một hệ thống được mô tả là trang nghiêm nếu nó được thiết kế để ghi nhớ các sự kiện hoặc tương tác của người dùng trước đó; Thông tin được ghi nhớ được gọi là trạng thái của hệ thống". Do đó, một blockchain đủ điều kiện như một hệ thống trang nghiêm. Toàn bộ mục đích của nó là ghi lại các sự kiện trong quá khứ và tương tác của người dùng. Với mỗi khối mới, hệ thống trải qua quá trình chuyển đổi trạng thái xảy ra theo logic chuyển tiếp trạng thái được xác định trong giao thứccủa nó .
Mỗi blockchain, bất kể nó sử dụng UTXO hoặc mô hình tài khoản, đều tuân theo kế hoạch này. Các tương tác của người dùng, chủ yếu là các giao dịch, được phát sóng đến mạng và với mỗi khối mới, một tập hợp chúng được ghi lại vĩnh viễn. Số dư của các bên giao dịch được cập nhật khi hệ thống chuyển sang trạng thái mới. Sự khác biệt giữa UTXO và mô hình tài khoản nằm ở cách xử lý sổ sách kế toán. Với sổ sách kế toán, chúng tôi có nghĩa là ghi lại trạng thái và chuyển từ tiểu bang này sang tiểu bang khác.
Ghi lại nhà nước
Sự khác biệt đáng kể đầu tiên giữa hai mô hình cân bằng là cách ghi lại trạng thái của hệ thống. Trong mô hình UTXO, sự chuyển động của tài sản được ghi lại dưới dạng biểu đồ chu kỳ định hướng (DAG) giữa các địa chỉ, trong khi mô hình tài khoản duy trì cơ sở dữ liệu về các trạng thái mạng.
Một biểu đồ được định nghĩa là một tập hợp các nút hoặc đỉnh được kết nối bởi các cạnh. Trong một biểu đồ định hướng, mỗi cạnh có một hướng, thường được chỉ định thông qua mũi tên. Đồ thị tuần hoàn hướng không cho phép mối quan hệ tròn giữa các nút. Chúng tôi có một cái nhìn chi tiết hơn về đồ thị ở đây.
Đồ họa ở trên cho thấy một biểu đồ chu kỳ hướng của mô hình UTXO ở bên trái. Mỗi tiểu bang đại diện cho một khối trong blockchain. Mỗi đầu ra giao dịch bao gồm một nút trong DAG và mỗi giao dịch được thể hiện bằng một hoặc nhiều cạnh có nguồn gốc từ đầu ra giao dịch. Do đó, đầu ra giao dịch chưa chi tiêu không có lợi thế bắt nguồn từ nó. Trong ví dụ trên, đầu ra giao dịch 3, 5, 6 và 7 không được chi tiêu.
Ở bên phải, đồ họa hiển thị một đại diện của các trạng thái khác nhau trong mô hình tài khoản. Với mỗi khối mới, trạng thái của hệ thống được cập nhật theo các giao dịch có trong khối. Số lượng tài khoản vẫn không đổi và độc lập với số lượng giao dịch được thực hiện, miễn là số lượng người dùng hoặc hợp đồng thông minh không đổi.
Trong mô hình UTXO, toàn bộ biểu đồ đầu ra giao dịch, chi tiêu và chưa chi tiêu, đại diện cho trạng thái toàn cầu. Trong mô hình tài khoản, chỉ có bộ tài khoản hiện tại và số dư của chúng đại diện cho trạng thái toàn cầu. Trong ví dụ trên, đây là tập hợp các tài khoản A, B và C và số dư tương ứng của chúng.
Sự khác biệt về khái niệm là mô hình tài khoản cập nhật số dư người dùng trên toàn cầu. Mô hình UTXO chỉ ghi lại biên lai giao dịch. Trong mô hình UTXO, số dư tài khoản được tính ở phía khách hàng bằng cách cộng các đầu ra giao dịch chưa chi tiêu có sẵn (UTXOs).
Mô hình UTXO
Mô hình UTXO không kết hợp tài khoản hoặc ví ở cấp độ giao thức. Mô hình này hoàn toàn dựa trên các giao dịch riêng lẻ, được nhóm lại theo khối. Chúng ta có thể so sánh điều này với những người nắm giữ một lượng tiền mặt nhất định.
- Một người dùng nắm giữ 50 ZEN có thể kiểm soát một UTXO duy nhất trị giá 50 ZEN hoặc kết hợp các UTXOs thêm tới 50 ZEN.
- So sánh nó với tiền mặt, nếu người dùng có 50 đô la, anh ta có thể giữ một hóa đơn 50 đô la hoặc kết hợp các mệnh giá nhỏ hơn.
Đầu ra giao dịch phải được chi tiêu toàn bộ vì các bản ghi trong các khối trước đó không thể được chỉnh sửa (giảm). Khi một giao dịch đang chi tiêu UTXO và người dùng không muốn chuyển toàn bộ số tiền của nó, số tiền dư thừa (chênh lệch giữa kích thước UTXO và số tiền người dùng sẵn sàng chi tiêu) được gửi đến một địa chỉ tự kiểm soát như thay đổi.
- Chi tiêu 10 ZEN từ UTXO trị giá 50 ZEN có nghĩa là tạo ra hai đầu ra trong giao dịch: đầu ra 10 ZEN cho người trả tiền và thay đổi đầu ra 40 ZEN cho chủ sở hữu ban đầu.
- Chi tiêu 10 đô la với hóa đơn 50 đô la có nghĩa là giao tiền của bạn và nhận được 40 đô la tiền lẻ từ người nhận sau đó.
Tuy nhiên, có hai điểm khác biệt quan trọng:
- Trong thanh toán bằng tiền mặt, bạn dựa vào đối tác của mình để trả lại tiền lẻ. Trong trường hợp của mô hình UTXO, người trả tiền không bao giờ kiểm soát được sự thay đổi ngay từ đầu.
- Sự khác biệt khác là tiền mặt tồn tại trong các mệnh giá được xác định, rời rạc. Có tờ 1 đô la, 5 đô la, 10 đô la, v.v. Đầu ra giao dịch trong mô hình UTXO có thể có các giá trị tùy ý, ví dụ: 11.79327 ZEN.
Vì không có khái niệm về tài khoản hoặc ví ở cấp độ giao thức, "gánh nặng" của việc duy trì số dư của người dùng được chuyển sang phía khách hàng. Ví duy trì hồ sơ tất cả các địa chỉ được kiểm soát bởi người dùng và theo dõi blockchain cho tất cả các giao dịch liên quan. Tổng của tất cả các đầu ra giao dịch chưa chi tiêu mà nó có thể kiểm soát xác định số dư hiện tại.
Chuyển tiếp trạng thái trong Mô hình UTXO
Mỗi giao dịch trong mô hình UTXO có thể chuyển đổi hệ thống sang trạng thái mới, nhưng chuyển sang trạng thái mới với mỗi giao dịch là không khả thi. Tất cả người tham gia mạng phải đồng bộ về trạng thái hiện tại. Thiết kế một cơ chế đồng thuận giữ cho tất cả các nút được đồng bộ hóa trở nên khó khăn hơn, khi quá trình chuyển đổi trạng thái xảy ra thường xuyên hơn. Điều này trở nên trực quan khi bạn xem xét rằng khoảng thời gian giữa các khối cho phép các nút có cơ hội tải xuống khối gần đây nhất và xử lý nó. Thời gian để các nút cập nhật trạng thái càng ngắn, cơ hội đạt đến trạng thái không nhất quán, nơi một số nút có cái nhìn khác về các sự kiện trong quá khứ so với các nút khác. Kết quả là, các giao dịch được phân lô thành các khối và mỗi khối mới trình bày một quá trình chuyển đổi trạng thái hệ thống.
Trong ví dụ dưới đây, chúng tôi xem xét quá trình chuyển đổi trạng thái UTXO chỉ với một giao dịch giả định duy nhất để đơn giản.
Giả sử Alice muốn chuyển tám ZEN cho Bob, và cô điều khiển một UTXO duy nhất trị giá mười ZEN. Giao dịch mà cô tạo ra tiêu thụ đầu ra giao dịch chưa chi tiêu trước đây của cô như một đầu vào. Để chi tiêu một UTXO, nó cần phải được "mở khóa".
Kịch bản Pubkey bao gồm trong mỗi đầu ra giao dịch xác định các điều kiện chi tiêu. Dữ liệu cần thiết để đáp ứng kịch bản này được cung cấp với giao dịch chi tiêu và bao gồm chữ ký số của chủ sở hữu - trong trường hợp này là Alice.
Tiếp theo, cô ấy xác định những gì sẽ xảy ra với tiền của mình. Cô ấy làm điều này bằng cách tạo đầu ra giao dịch. Alice muốn chuyển tám ZEN cho Bob, vì vậy cô tạo ra hai đầu ra: một trả bob và một trả lại số tiền dư thừa cho một địa chỉ tự kiểm soát. Đối với cả hai đầu ra, các điều kiện chi tiêu cũng được xác định trong giao dịch do Alice tạo ra.
Lưu ý làm thế nào tổng đầu ra không bằng toàn bộ đầu vào tiêu thụ. Sự khác biệt giữa đầu ra và đầu vào được định nghĩa là phí giao dịch ở cấp độ giao thức. Trong trường hợp này, phí TX là 0,001 ZEN.
Kích thước của phí giao dịch được ước tính bởi ví dựa trên lượng dữ liệu được ghi lại trên chuỗi. Các thợ mỏ chỉ có thể đặt một lượng dữ liệu hạn chế trong một khối và bằng cách sử dụng số liệu 'tiền trên mỗi lượng dữ liệu', các thợ mỏ có thể xác định giao dịch nào sẽ bao gồm trong khối. Họ thường sẽ chọn các giao dịch có phí cao nhất cho mỗi byte.
Mô hình Tài khoản
Mô hình giao dịch dựa trên tài khoản đại diện cho tài sản dưới dạng số dư trong tài khoản, tương tự như tài khoản ngân hàng. Ethereum sử dụng mô hình giao dịch này. Có hai loại tài khoản khác nhau:
- tài khoản người dùng được kiểm soát khóa riêng và
- tài khoản ký hợp đồng được kiểm soát mã.
Khi bạn tạo ví Ether và nhận giao dịch đầu tiên, tài khoản được kiểm soát khóa riêng sẽ được thêm vào trạng thái toàn cầu và được lưu trữ trên tất cả các nút trên mạng. Triển khai một hợp đồng thông minh dẫn đến việc tạo ra một tài khoản được kiểm soát mã. Các hợp đồng thông minh có thể tự nắm giữ tiền, mà họ có thể phân phối lại theo các điều kiện được xác định trong logic hợp đồng. Mỗi tài khoản trong Ethereum đều có số dư, lưu trữ và không gian mã để gọi các tài khoản hoặc địa chỉ khác.
Một giao dịch trong mô hình dựa trên tài khoản kích hoạt các nút để phá hủy số dư tài khoản của người gửi và tăng số dư tài khoản của người nhận. Để ngăn chặn các cuộc tấn công phát lại, mỗi giao dịch trong mô hình tài khoản đều có một nonce đính kèm. Một cuộc tấn công phát lại là khi người trả tiền phát sóng một giao dịch gian lận, trong đó họ được trả tiền lần thứ hai. Nếu giao dịch gian lận thành công, giao dịch sẽ được thực hiện lần thứ hai - nó được phát lại - và người gửi sẽ bị tính phí gấp đôi số tiền họ muốn chuyển.
Để chống lại hành vi này, mỗi tài khoản trong Ethereum có một nonce có thể xem công khai được tăng lên bởi một tài khoản với mỗi giao dịch đi. Điều này ngăn chặn giao dịch tương tự được gửi đến mạng nhiều hơn một lần.
Phí giao dịch cũng hoạt động khác nhau trong mô hình tài khoản: chúng được tính dựa trên số lượng tính toán cần thiết để hoàn thành quá trình chuyển đổi trạng thái. Ethereum trở thành một máy tính thế giới. Do đó, họ quyết định rằng phí nên dựa trên số lượng tài nguyên tính toán được tiêu thụ thay vì dung lượng lưu trữ được thực hiện.
Mô hình tài khoản theo dõi tất cả số dư như một trạng thái toàn cầu. Trạng thái này có thể được hiểu là cơ sở dữ liệu của tất cả các tài khoản, khóa riêng và mã hợp đồng được kiểm soát và số dư hiện tại của các tài sản khác nhau trên mạng.
Trạng thái toàn cầu trong mô hình UTXO là tập hợp tất cả các đầu ra giao dịch (đồ họa thứ hai ở bên trái). Trạng thái toàn cầu luôn là toàn bộ biểu đồ của UTXOs. Trạng thái trong mô hình tài khoản là danh sách các tài khoản và số dư của chúng. Vì vậy, trong đồ họa thứ hai, trạng thái toàn cầu (n +3) là danh sách 3 tài khoản (A, B và C) và số dư của chúng.
Sự khác biệt chính đến từ trạng thái toàn cầu trong mô hình UTXO chỉ được mở rộng với CÁC UTXOs mới, trong khi trong mô hình tài khoản, trạng thái toàn cầu được cập nhật và số dư thay đổi.
State Transitions in the Account Model
In a straightforward model, a transaction presents an event that triggers a state transition of the blockchain subject to the state transition logic. Just like in the UTXO model, it is infeasible to transition the system to a new state with every transaction without risking an inconsistent state. Transactions are also batched into blocks in the account model, and with each new block, the system transitions to a new state. Just like we did before, we consider a simple example where a single transaction transitions the system to a new state below.
The setting is the same as before: Alice wants to transfer 8 ZEN to Bob. Her wallet will create a transaction that defines the spending account, the receiving account, and the amount to transfer. This transaction is then signed with Alice’s private key. In this case, she is spending from her address, the receiver is Bob, and the amount to transfer is 8 ZEN.
When the system transitions to a new state (n+1) with the next block, Alice’s account balance will globally be reduced to 2 ZEN, whereas Bob’s balance will be increased to 9 ZEN.
The PubKey- and Signature Script do not exist in account-based blockchains. The verification of signatures in account-based blockchain, Ethereum for example, is based on three parameters, r, s, and V provided by the sender. These three values comprise the signature. Solidity, the programming language used in Ethereum, provides a method, ecrecover that returns an address given these parameters. If the returned address matches the sender’s address, the signature, and in return, the transaction is valid.
Where in the UTXO model part of the verification process is checking if a transaction output in unspent, nodes in the account model check if the sender’s balance is larger than or equal to the transferred amount. This is true for the native asset of the chain, e.g., ether, as well as all other tokens on the network.
A transaction in the account-based model is an instruction for how to transition two or more accounts to the next state. The actual transition is executed by the nodes. Because the final state is not specified in the transaction, the resulting transaction size is a lot smaller than in the UTXO model.
The state of accounts in Ethereum is not stored on the blockchain but computed and stored locally by the nodes. The blockchain only stores the instructions (read: transactions) for how the system should transition from one state to another.
Comparing the UTXO and Account Model
Below, we will compare the strengths and weaknesses of the UTXO and account model. We will start by comparing them at a high-level computational view, and then move onto scalability, privacy, smart contract capabilities, and more.
In short, The UTXO model is a verification model. This means users submit transactions that specify the results of the state transition, defined as new transaction outputs spendable by the receiver(s). Nodes then verify if the consumed inputs are unspent and if the signature(s) satisfy the spending conditions.
The account model, on the other hand, is a computational model. In this model, users submit transactions instructing nodes on what state transitions should look like. The network then computes the new state based on the instructions. This method comes with specific implications regarding second layer scalability solutions like state channels and sharding.
Scalability
There are several approaches we can use to compare the scalability of the UTXO and the account model. One way is to focus on the overall storage requirements of each system. Another way is to consider which model is better suited for the deployment of second-layer technologies on top of the main blockchain.
One second layer technology, state- and payment channels moves the exchange of data from the blockchain to a dedicated trustless network of bidirectional communication channels.
The other approach that could arguably be referred to as a second layer technology is sharding. Sharding is a term originating from the traditional database world. It describes partitioning a database into several shards in order to keep each individual partition more performant, in turn improving the entire system. Horizen’s [Sidechains](/horizen/expert/sidechains/ can be considered a sharding mechanism.
We’ll now compare both accounting methods and will assume that both systems have similar user and transaction counts.
Size of the Blockchain
The account model has more efficient memory usage. Storing a single account balance saves memory compared to storing several UTXOs that comprise a user’s total balance. Transactions in the account model are also smaller in size because they only specify the sender, receiver, the transfer amount, and a single digital signature. Additionally, just by doing away with change outputs, a lot of data can be saved in the account model.
On a conceptual level, this is intuitive. Since a UTXO transaction specifies the state after the transition (the newly generated transaction outputs), it needs to include more data than an account transaction. It may also consume several UTXOs as inputs, whereas the account transaction only specifies which account balance to deduct an amount from. To give you an idea, Ethereum’s account model takes about 100 bytes, whereas a UTXO transaction in Horizen takes about 200-300 bytes.
This also means that it’s faster to get new nodes online in a system running the account model because less data is needed to get them in synch. The number of accounts will generally be much smaller than the total UTXO set in a comparably sized system.
State- and Payment Channel Constructions
Currently, the most advanced payment channel construction is the Lightning Network on Bitcoin. It uses a proof submission and verification mechanism as assets move into and out of the second layer. As mentioned above, the UTXO model is essentially a verification model, whereas the account model is a computational model. Hence, a UTXO construction is more suitable for these types of scalability approaches.
Sharding
Partitioning a blockchain into shards or sidechains is also easier while using the UTXO model. Aggregating spendable transaction outputs and defining the outputs happens on the client-side, reducing the stress on the overall system. In the account model, every node has to localize the sender’s and receiver’s account across different shards and edit both.
Of course, there is more to sharding then these rather straight forward modifications, and using one balance model over the other comes with second and third-order effects. Generally, the UTXO model allows data structure partitioning more simply.
Privacy
When it comes to privacy, there are merits to both the UTXO and the account model. The UTXO model makes it harder to link transactions, whereas the account model provides better fungibility.
When change addresses are consequently used in the UTXO model, it makes tracking the ownership of coins harder compared to the account model. A newly generated address doesn’t have a known owner and requires advanced chain analysis to be linked to a single user. The account model implicitly encourages address reusage and hence makes creating a transaction history for a single user easier.
With regard to fungibility, the account model offers better privacy. There is complete transparency of UTXO movements (read assets) in the UTXO model when no privacy-preserving techniques are applied. However, the account model comes with a built-in “coin mixer” of sorts. When an account is funded with several transactions, the result is a single balance. When a payment from this account is made, an observer cannot determine which of the incoming coins is being spent. Consider the example of the account model above where Alice sends 8 ZEN to Bob, and his balance is updated to 9 ZEN. When Bob subsequently spends 1 ZEN, nobody can determine if the single ZEN stems from Alice or a different source. This is a very simplified view. Even when assets cannot reliably be assigned to a funding transaction, analytic tools can determine if coins are tainted, but the general idea remains.
Smart Contract Capabilities
The account model offers clear advantages when it comes to enabling smart contracts.
First, the account model logic is more intuitive. Adding and subtracting balances makes it easier for developers to create transactions that require state information or involve multiple parties. A signed transaction is valid as long as the sending account has a sufficient balance to pay for the execution. Checking a balance is computationally less expensive than verifying if a transaction output is spent or unspent. This is especially true for code controlled accounts that interact with other smart contracts. Internal transactions between contracts can be carried out in a virtual machine by adjusting the balances of the contracts. The UTXO model creates computational overhead because all spending transactions must be explicitly recorded.
Smart contracts in a UTXO model would need to include logic for choosing which outputs to use when sending assets, and logic to handle change outputs. Because the UTXO model is inherently stateless, it forces transactions to include state information, complicating the overall design.
Other Differences
One benefit of the UTXO model is that it allows for the simpler parallelization of transactions in smart contracts. Multiple UTXOs used in different transactions can be processed at the same time since they all refer to independent inputs.
In the account model, the result of a transaction depends on the input state. Executing transactions in parallel must be handled carefully. Generally, transactions affecting the same account should be executed sequentially.
A key takeaway is that the UTXO model is better when dealing with simple transactions. The account model is beneficial when dealing with more complex logic. Hence a popular trend with current smart contract platforms is using a hybrid model where the UTXO model is used for balances, and the account model is used for smart contracts.
Hybrid Systems
QTUM is one example of a blockchain that utilizes a hybrid system of UTXOs and accounts.
“Early on when Qtum was first being designed, the thought process was to build a business-ready blockchain that was versatile yet secure. To accomplish these motivations, Qtum chose the underlying UTXO (Unspent Transaction Output) model that Bitcoin is built on over the Accounts model that Ethereum style blockchains are built on.” - Dev Bharel
The UTXO model was used as the basis for the overall architecture because it was considered “significantly securer” at the time of conception. On top of this UTXO layer, QTUM enables “creating and executing smart contracts using the account model offered by Ethereum” through a construction they call the Account Abstraction Layer (AAL)
The AAL combines UTXOs for a given contract in a new transaction as soon as there are two or more of them available to the contract code. By using the UTXO model as a base layer, QTUM is also able to implement BlackCoin’s Proof of Stake Protocol, which requires parallel proofs and UTXO activity.
Summary
To finish off, let’s recap what we’ve covered. We started by pointing out the similarities between the UTXO and the account model. The blockchain can be considered a state machine independently of the accounting scheme used. In both cases, transactions trigger state transitions in batches - with each new block added to the blockchain.
In the UTXO model, the movement of assets is recorded in the form of a directed acyclic graph made of transaction outputs. New outputs are added with each additional block. In the account model, balances are stored as a global state of accounts, kept by each node, and updated with every block. This is similar to a database.
Transactions in the UTXO model are larger in size and place more burden on the user and their wallet. The UTXO model is a verification model, whereas the account model is a computational model.
Account-based systems offer storage benefits because the account’s state and transactions are smaller. The UTXO is more efficient at simplifying scaling solutions like state and payment channel constructions, as well a sharding.
Both models have pros and cons regarding privacy. For example, the account model makes it easier to link transactions to a single user, but also offers a higher degree of fungibility.
The account model offers clear advantages in regard to smart contracts. Many new smart contract platforms use hybrid models where UTXOs are used for balances and accounts are used for the contracts.
In the end, it depends on the use case, which model is better suited for the job. You can shoehorn most applications into one or the other balance model. The question is if you should do this, and why you would want to do this in the first place. Because we could not phrase it much better we want to finish this article with a quote:
“Within cryptocurrency platforms, there are a diverse set of design concepts and technical mechanisms that go into the platform being able to function as a viable, secure, and usable system. The transaction models used by such platforms employ the use of cryptography to verify ownership of tokens across the network. The UTXO scheme works superbly for Bitcoin, while the account-based model used in Ethereum is geared to supporting its more complex application and contract needs.” - Brian Curran
