Perspectives | Incomplete Contracts and Blockchain Expansion

Editor's Note: This article quotes the famous "incomplete contract" theory in the field of contract economics. Although there is a suspicion of being moved, there is no lack of insight into the relationship between automation and expansion. In addition, there is no clear definition of "scale" and "scalability" ("scalability") in this article, but if this ambiguity can give us more insights, it may be worthwhile to maintain this ambiguity.

When analyzing different blockchain projects, we can draw on the perspective of contract theory. There is a saying in the field of law: "In addition to the simplest contract, all contracts are incomplete." That is to say, contractual arrangements cannot foresee all possible events because of the total human affairs coordinated by the contract. It is complex and fast-changing.

Because of the incompleteness of specific contracts, the operation of contracts must rely on renegotiations at the time of unexpected events, such as corporate bankruptcy, regulatory changes, and even simple changes in the details. In the event of these circumstances, the contracting parties often need a third party like the legal system to mediate, although the outcome of the mediation is still unpredictable. Therefore, contracts are always associated with the handling of unknown events, incentives for both parties, and governance.

However, as long as we accept the notion that “contract is the logic of decision-making, analogy to computer programs”, we can think about different types of smart contracts and blockchain projects and their scalability like contract theory analysis contracts. (including governance issues).

• Futures positions are bullish, bull market is not over yet?
• Thai Customs will use IBM and Maersk's blockchain platform to streamline cargo tracking processes
• "False" gold disrupts the market, BTC or demand soars

Let's start a thought experiment: We divide the blockchain project into two categories: one is dedicated to creating a "complete contract" and the other is due to its own complexity, it can only be an "incomplete contract." Although this distinction is obviously too simple, the purpose of our work is to highlight how these projects can be extended.

Let's first define those (almost) "complete contracts" projects. The goal of such projects is to achieve an end-to-end system that minimizes the need for subjective interpretation, renegotiation, and external governance. In programming techniques, the goal of such systems is to "correct by construction." Bitcoin's workload proves that mining is such a system. The completeness of Bitcoin comes from its verifiable computational process: deterministic hashing algorithms, plus hard-coded game incentives. The two work together, allowing the entire system to move toward a conforming blockchain, while minimizing the need for subjective interpretation or external governance.

Ethereum also meets this requirement because the workload in the Ethereum network is similar. The application developed on Ethereum also inherits this "completeness" and extends this completeness to create automated software applications. One example is Uniswap, a well-designed token exchange whose logic and incentives are fully coded as unchangeable smart contracts. The incentive mechanism hard-coded in the contract allows market makers to participate voluntarily, opening up the liquidity network effect without any continuous centralized operators.

In all of the above examples, completeness is tied to automation. A well-designed system can run automatically without human intervention. Nick Szabo's famous view is that such automated systems are “socially scalable,” because their collaboration provides a guarantee that can sustain the number of participants and even engage others. Minimizing external subjective factors reduces the complexity of coordination activities and allows the entire system to scale as members grow.

For projects that exist in this "complete contract" world, the design space must be limited. Because the ability to achieve scalability through automation is limited to those that can be deterministically verified with a computer. If a computer program is a contract or decision logic, such programs generally require that the input decisions be digitized, quantifiable, or machine readable.

Let's start with those almost complete plans. These programs are dedicated to building end-to-end systems that seek to reduce the likelihood of subjective interpretation, renegotiation, and external management. In software terminology, the goal pursued by such systems is called "correct by construction." Bitcoin workload proof systems are just such systems. The integrity of Bitcoin is attributed to its function of verifying operations with a deterministic hash algorithm and hard-coded game theory incentives. These factors are only for producing a chain that avoids human intervention or is influenced by external decisions.

So what is an "incomplete contract" project? Incomplete contract projects are projects that require dynamic, subjective input to maintain their operations and are difficult to verify and automate with calculations.

MakerDAO is such a project. Although most of Maker's logic is deterministically run on Ethereum (that is, it can be said to be highly "complete"), it retains "incomplete" attributes in a small number of key areas, ie, it requires Participants dynamically adjust the parameters to maintain the price anchor of the stable currency Dai and its underlying collateral rate. Today, setting up these parameters is too complicated to automate; instead, it is determined by community voting.

Similarly, MolochDAO is an association dedicated to promoting Ethereum infrastructure. They also use voting to make decisions, such as who can join the association and which projects can get their financial support. Although the voting results are derived from smart contracts, Moloch's organizational structure is “incomplete” because the input to the organizational structure includes complex and unquantifiable inputs such as honors, social capital, and project feasibility; these inputs are subject to The subjective interpretation of human beings makes sense.

Although these projects can adapt to change, they cannot be extended by automation. Moreover, taking the vote as a coordination mechanism may expose you to the risk of “the more people drag and drop”. Therefore, “incomplete contract” projects require other ways to achieve social scalability.

Summarize:

“Incomplete Contracts” Project: Governance and Expansion

 

If “incomplete” contracts depend on human decision making, how do they replicate the success of Bitcoin and Ethereum? How do you surpass these pioneers in scale?

Some people think that it can be governed by agents as in companies that cooperate with each other, and ownership is used to ensure the incentive compatibility of decision makers. Historically, over time, the most successful cooperative organizations have incorporated a hierarchical decision-making model similar to a company: shareholders specifically assign a management team to represent their interests and make daily decisions. This is an extension of the overall vote than everything else. Other community-supported projects like Wikipedia have developed a structural governance model based on community credibility (although this has not happened at first). While the hierarchical governance system is incompatible with the decentralized culture that permeates the circle, this may be a more viable path for most complex, incomplete “incomplete” contract projects.

Is the “incomplete contract” project feasible?

 

People often criticize "incomplete" systems that do not take advantage of the certainty or "trust-free" nature of the underlying computing platform. But I want to argue that attributes that are native to the blockchain will still provide powerful new tools for incomplete contracts:

• Value distribution capabilities. Because blockchain (by tokens) makes value distribution as simple as information distribution, blockchain computers allow communities to create startups that are native to the network, and shareholder ownership and expression rights can be consistent by default.
• Deterministic processes for organizing operations, such as assigning agents with authority to make decisions (liquidity democracy), triggering bonuses, transferring funds, and so on.
• The ability to quit at any time. Because we can copy the code, which reduces the cost of migrating to competing products.

In general, interesting projects are adaptable and can evolve, which will surprise people. I always feel that the most interesting project built on the blockchain will be "incomplete." Perhaps we will eventually prove that it is not that the “incomplete contract” makes full use of the underlying platform to execute its business logic; more importantly, whether these blockchain-based organizations make full use of efficient organization and scalability. Sex model. Software can't solve the completeness of all contracts in one step, but it can help – and, by tokens to achieve ownership, the community can overcome startup problems and promote innovation.

(Finish)

Original link:

Https://medium.com/dydxderivatives/getting-started-with-dydx-part-2-borrowing-d7d1236a572d

Author: Everett Hu

Translation & Proofreading: ViolaH & Ajian

(This article is from the EthFans of Ethereum fans, and it is strictly forbidden to reprint without the permission of the author.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!