Blockchain's built-in tokens are often an economic incentive model

Source: Internet
Author: User
Tags bitcoin blockchain digital currencies blockchain framework blockchain startup

Corda

Corda was developed by R3CEV, a New York-based blockchain startup, and its R3 blockchain alliance has attracted dozens of giant banks, including Wells Fargo, Bank of America, and Mellon New York. Bank, Citibank, Commerzbank, Deutsche Bank, HSBC, Mitsubishi UFJ Financial Group, Morgan Stanley, National Australia Bank, Royal Bank of Canada, Swedish Nordic Bank (SEB), Societe Generale, etc. As can be seen from the composition of R3 members, Corda is a technical architecture dedicated to banking and interbank business. Although R3 claims that Corda is not a blockchain, it has some important features of the blockchain.


Corda is developed by Java and Kotlin and relies heavily on Java in its various functions, such as smart contracts, data access interfaces, and more. Corda's design goals are mainly:


No global ledger

Solving the multiple payment problem of a transaction by Notaries

Only the participants and notaries of the transaction can see the transaction.

For this reason, all of Corda's transactions will not be broadcast to the entire network, and all nodes are directly communicating, there is no P2P network. This has led to the network scale being limited to a small scale, the inability to form a large-scale alliance chain, and the applicable business scenarios are relatively narrow.


Technical comparison

Next, we will conduct a series of technical comparisons on the blockchain frameworks mentioned in the previous section, and discuss their differences and similarities from multiple dimensions.


Digital assets

Blockchain's built-in tokens are often an economic incentive model and a means of preventing junk transactions. Bitcoin is born with one and only one built-in token, so all "transactions" in the Bitcoin system are essentially transfer behavior, unless additional digital assets are added to Bitcoin through an external protocol layer.

Ethereum and Onchain DNA have built-in tokens that provide a fee-based channel for system built-in functionality in addition to the economic incentives and spam prevention mentioned above. For example, Ethereum's smart contract operation needs to consume GAS, and Onchain DNA's digital asset creation also needs to consume a certain amount of tokens (optional).

Ethereum and Fabric do not have a variety of built-in digital asset support, but through smart contracts to achieve the corresponding functions. The advantage of this approach is that the system design can be very simple, and the behavior of the assets can be arbitrarily specified, and the degree of freedom is extremely high. However, such a design can also have a series of negative effects, such as all asset creators have to write their own repeated business logic, and users have no way to operate their assets in a unified way.

In contrast, Onchain DNA and Corda use a way to support multiple digital assets at the bottom, allowing asset creators to easily create their own asset types, and users can manage all assets in the same client. For business scenarios with more complex logic, they can also leverage smart contracts to enhance the functionality of assets or create business logic that is independent of assets.


Account system

UTXO (Unspent Transaction Output) is a mechanism in which each digital currency is registered under the ownership of an account. A digital currency has two states, either that it has not been spent or has been spent. When a digital currency is needed, its status is marked as spent, and a new equivalent digital currency is created, registering its ownership under the new account. In this process, the digital currency marked as spent has been called the input of the transaction, and the new digital currency created is called the output of the transaction. In a transaction, it can contain multiple inputs and multiple Output, but the sum of the input sum and the output must be equal. When calculating the balance of an account, simply add the denominations of all the digital currencies registered under the account.

Bitcoin and Corda use an account mechanism like UTXO, while Ethereum uses a more intuitive balance mechanism: each account has a status, the status directly records the current balance of the account, the logic of the transfer is from a A portion of the amount is subtracted from the account and the corresponding amount is added to the other account. The subtracted portion plus the added portion must be equal. Onchain DNA is compatible with both modes on the account mechanism.

So what is the difference between UTXO mode and balance mode? The biggest advantage of UTXO is that UTXO-based transactions can be verified in parallel and arbitrarily ordered, because all UTXOs are unrelated, which is very helpful for the future scalability of the blockchain, and the balance-based design is There is no such advantage. In turn, the advantage of balance design is that the design idea is very simple and intuitive, and it is easy to implement the program. Especially in smart contracts, it is very difficult to deal with the state of UTXO. This is why Ethereum chose the balance design with smart contracts as its main function, while Bitcoin, OnchainDNA, and Corda, which are digital asset-centric architectures, are more inclined to UTXO design.

Regarding identity authentication, Bitcoin and Ethereum have basically no identity authentication design. The reason is very simple, because the design ideas of both are emphasis on privacy and anonymity, against supervision and centralization, and identity authentication is necessary to introduce some centers or weaken Central institution.

Fabric, Onchain DNA, and Corda have chosen to use digital certificates to authenticate users because they all have design goals for existing financial systems, and financial systems must consider compliance and regulatory compliance. In addition, the existing financial system has adopted a digital certificate scheme on a large scale, so that it can be quickly integrated with the blockchain system.


Consensus mechanism

The consensus mechanism is the core algorithm of the distributed system. Because the data of the distributed system is scattered among the participating nodes, the scattered data must be consistent by an algorithm, otherwise the system will not work properly. Unlike traditional distributed systems, blockchain is a decentralized system and can carry large amounts of financial assets, so it may face a large number of Byzantine failures rather than general failures, while centralized distributed systems Very few Byzantine failures are encountered. Therefore, the consensus mechanism of the blockchain is quite different from the traditional distributed system.

Bitcoin and Ethereum use a Proof-of-Work mechanism to ensure the consistency of the ledger data. The proof of workload is also a kind of token distribution mechanism. It encourages nodes to participate in the construction process of blocks through economic incentives. When constructing blocks, nodes need to exhaust a random number to make the blocks meet the required difficulty requirements. Once the blockchain is forked, the honest node will choose a chain with a larger workload and discard the smaller workload. Since all nodes are assumed to be profit-seeking, choosing a chain with a small workload will invalidate the incentives that you get, so all nodes will be honest, so that the blockchain data of each node is consistent.

In order to maintain the blockchain of such a workload proof mechanism, it is necessary to have a large-scale computing power support to ensure the security of the network, otherwise the book data may be tampered with. In addition, even if a large amount of computing power is maintained to protect the network, the workload proof cannot fundamentally guarantee the finality of the transaction. For example, Bitcoin often produces Orphaned Blocks, and transactions included in isolated blocks. It may be revoked. Therefore, Bitcoin usually requires the user to wait for the confirmation of 6 blocks, that is, about 1 hour, in order to conclude that the transaction has been completed with an acceptable probability, and this probability is not final - you will never Knowing if there is a huge calculation in the dark that is far more than the whole network is trying to cancel the previous transaction. The cost of electricity spent to maintain large computing power is also considerable. Therefore, Ethereum has been designing a solution to switch from the workload proof mechanism to other consensus mechanisms.

Both Fabric and Onchain DNA have designed a consensus mechanism based on the Byzantine Fault Tolerance model. Nodes are divided into ordinary nodes and accounting nodes (Validating Peer). Only the accounting nodes participate in the construction process of the blocks. The separation of such roles allows the designer of the algorithm to have the limit of the number of nodes running the consensus algorithm. Within a controlled scale.

The Byzantine fault-tolerant model makes assumptions and requirements for nodes in the network: if there are n nodes in the consensus that there will be Byzantine faults, then at least 3f+1 nodes need to participate in the consensus to avoid network bifurcation. Under this model, the construction process of each block requires at least 2f+1 nodes to complete, unlike each node in the workload proof mechanism. Once a block is constructed, it cannot be undone because 2f+1 honest accounting nodes do not sign and authenticate two different blocks at the same height.

In comparison, the workload proof mechanism provides extremely high flexibility and usability, because each node constructs a block independently and almost no other nodes are involved. The node can join or exit the network at any time, even if only the whole network is left. The next node, the network can still continue to work, but it also loses the finality of the transaction; while the Byzantine fault-tolerant mechanism is the opposite, sacrificing flexibility and availability, the accounting node must provide services online but not Exiting the network, once 1/3 of the accounting nodes are down, the network will become unavailable, but it guarantees the finality of the transaction.

Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.