Open the beta version of KAHF wallet and switch to Meer (Testnet). You must have seen that in addition to the Meer currency, there are two cute assets named QITID and METID. These two are the first-generation secondary assets issued by Qitmeer's MeerToken asset issuance system. They seem ordinary, but they are actually very interesting. Qitmeer has positioned the project as an infrastructure for the circulation of inclusive value since its inception, so the requirements for the underlying public chain are stability, security, and efficiency. Therefore, the ledger of the MeerToken asset issuance system did not adopt the account model as was popular at the time, but adopted the more stable classic UTXO model. The seemingly simple choice of ledger model actually involves difficult trade-offs, because it is not just about choosing a value circulation model, but more importantly, it is about choosing a smart contract model. The account model emerged with the emergence of Ethereum smart contracts, because in terms of value circulation, UTXO is already good enough, and there is no need to reinvent a new ledger model. In the so-called "Blockchain 2.0" era represented by Ethereum, where "smart contracts are justice", many new public chain projects will give priority to quickly supporting smart contracts, so they will directly expand based on Ethereum's code. As for whether the underlying ledger model meets the positioning of the project, it is not a priority. Although prioritizing the engineering implementation of smart contracts is a rational choice for most projects to pursue community recognition, there are also projects with similar concepts to Qitmeer . As far as I know, NervOS 's ledger model Cell is an enhanced UTXO model, and its smart contracts are generated and calculated by the contract generator (Generator) off-chain , but verified on -chain . The advantage is that the calculation on the chain becomes very simple, the stability is greatly enhanced, and the programming interface of the smart contract becomes very flexible and efficient. For example, the current development framework Capsule based on a safe and efficient high-level language such as Rust is used . It has stronger language expression ability and development environment than Ethereum's smart contract language Solidity . If necessary, it can also support development frameworks in other languages in the future. First of all, it must be stated that whether smart contracts are supported or not has nothing to do with whether it is an account model or UTXO. Whether smart contracts are supported is only related to whether the transaction supports total order. This is easy to understand, because it is entirely possible that two concurrent transactions include operations for the same smart contract account. There are two levels of problems here. First, is the smart contract an on-chain or off-chain smart contract? Second, if it is on-chain, whether smart contracts are supported.
For the first question, NervOS is the most representative case. As mentioned above, the ledger of NervOS is essentially a UTXO model. The UTXO model generally does not support full transaction ordering unless there is a special need for consensus expansion. This is actually very easy to understand. For example, in the figure below, the two transactions Tx3 and Tx4 are generated concurrently (note that concurrent rather than parallel is used here. Concurrency only requires that they occur at the same time logically, while parallelism requires that they also occur at the same time in time). Although strictly speaking, there must be a time sequence, because these two transactions are completely independent, the order of which one comes first does not affect the security of the transaction, so UTXO does not require the order of the two transactions to be determined. The advantage is that the transaction confirmation can be as fast as possible. This should be easy to understand. If I don’t care about the order of the two transactions, the node can verify and confirm any transaction once it receives it (note that this is just a simple confirmation, not a security confirmation. The security confirmation needs to wait until it is theoretically difficult to overturn the transaction). If sequencing is to be considered, because the order in which transactions arrive is unstable due to network factors, it may take some time after receiving and verifying until enough transactions are received before confirmation can be made. This requires a consensus protocol to ensure this. Since the Cell model of NervOS does not support transactions, how does NervOS support smart contracts? This brings us back to the first level of the question I mentioned at the beginning, whether it is an on-chain contract or an off-chain contract. Obviously, NervOS does not support the on-chain model, but it can be fully supported off-chain. One thing to add here is that although the concept of NervOS is very similar to Qitmeer, there are still some differences. Although both are UTXO models and are off-chain smart contracts (Qitmeer's cross-chain smart contracts are also off-chain smart contract solutions), the starting point is also the stability of the underlying public chain. However, Qitmeer's underlying chain uses the MeerDAG protocol enhanced based on the UTXO model, which supports full transaction sorting, so it has the ability to support on-chain smart contracts. There is no intention to belittle NervOS here. In fact, if necessary, NervOS can enhance the consensus protocol to achieve the same effect. In fact, MeerDAG supports full transaction sorting more for the consideration of the overall architecture, such as supporting fairer reward rules. MeerDAG also explored the SPECTRE protocol based on relatively weak scalability but faster confirmation speed at the beginning, and finally turned to the GhostDAG protocol based on stronger scalability and faster confirmation speed after comprehensive consideration. When discussing MeerDAG in the future, I will share the development process of the Qitmeer consensus protocol in a more comprehensive way. So here comes the second level of question, whether it supports smart contracts on the chain. Like NervOS, Qitmeer does not support it at present, but as mentioned just now, the MeerDAG consensus protocol can be expanded to support smart contracts on the chain. As for the reason for not supporting it yet, it is more of a trade-off between engineering implementation and project positioning. Because the Ethereum virtual machine is based on the account model, many projects will develop based on Ethereum code in order to facilitate the implementation of smart contract engineering. As for whether the account model or the UTXO model is more suitable for project positioning, it is not a priority. If the implementation of the Ethereum smart contract is based on the UTXO model, they may also choose the UTXO model. Qitmeer thinks that UTXO is more reasonable from the perspective of project positioning, so it chooses the unique off-chain smart contract solution of cross-chain. The above is a relatively detailed sharing of MeerToken’s journey based on the UTXO model with friends in the community. The ledger model determines the design of the asset issuance mechanism. For example, Ethereum’s asset issuance mechanism is actually a simplified version of a smart contract. Next, I will continue to share the principles of Qitmeer’s asset issuance mechanism based on UTXO, as well as its advantages and disadvantages compared to asset issuance mechanisms represented by Ethereum. Stay tuned. |
