Transaction Model
During the development of the ASC-20 trading market, we encountered several dilemmas that required careful consideration. One of the specific dilemmas we encountered is which transaction model we should use. The UTXO model or Account model.
Let’s talk about the difference between the two:
Transfer Account
In the provided Account model, the Nonce is explained as follows: It must be an integer starting from 0 and must strictly adhere to the rules of self-increment. This requirement is implemented to address data security concerns often faced by current indexes and to enhance the security verification of transactions to a certain extent.
For instance, let's consider Alice and her three pieces of data within the block height range of 1 to 200. The respective nonces for these data items are 1, 2, and 3. In this scenario, a transaction with a Nonce of 1 is associated with a block at height 5, a transaction with a Nonce of 2 is linked to a block at height 15, and a transaction with a Nonce of 3 is connected to a block at height 200.
In situations where data processing encounters unavoidable issues, such as the block height range of 14-15, the presence of the Nonce becomes crucial. Without the Nonce, the third transaction would be considered valid data, leading to abnormalities and potentially impacting the security of funds.
In summary, the Nonce plays a significant role in maintaining the integrity and security of the data by ensuring proper transaction verification and preventing potential anomalies in the event of processing disruptions.
Transfer UTXO
The trading model's security relies on the individual funds themselves, and it is essential to have a clear source for each previous transaction. Consequently, we implement a refund to ourselves operation to ensure transparency.
In Bitcoin, transactions are processed using OP encoding. To enhance clarity on the Avalanche network, we utilize the JSON inscription format. The transaction data should be similar to that of BTC, but certain keys have been modified to optimize gas consumption.
One notable difference between the transaction mode and Account mode JSON is the alteration of the "to" field to "vin" and "vout". These fields explicitly specify transaction details, and for each input, "txid" and "vout" need to be utilized.
Compared to the Account mode, this processing introduces a more transparent data verification approach within the block, ensuring greater clarity and security.
This is example:
---- Mint ----
Encoded and sent to the recipient, and does not support contracts
---- Transfer Account ----
---- Transfer UTXO ----
When selecting the technical path for the transaction model, we encountered a dilemma regarding the account model. We decided to implement stricter nonce requirements in order to effectively handle emergencies. However, it is important to consider that using UTXO may result in increased gas costs. On the positive side, this approach significantly enhances security. Additionally, by recursively tracing the latest transaction, it becomes possible to track back to the original Mint transaction. This dilemma highlights the trade-offs and considerations involved in choosing the technical path for the transaction model.
We asked help from the community and we raised a voting. The final voting result shows that users would choose UTXO model for safer and more secure transactions.
Last updated
