About DAO: Decentralized Autonomous Organizations

Original title: "About DAO: Decentralized Autonomous Organizations"

Original source: DAOSquare

This is in our series of articles 's seventh and penultimate article, "Getting an API on the Blockchain". So far, we've covered the API connection problem and highlighted a few major components of our solution, namely first-party oracles and quantifiable security. This post highlights another major component of our design.

Italian futurist painter Gerardo Dottori.1930

< p>There has been a lot of discussion about decentralized governance in the form of DAOs, and it is still being discussed today. This is because the more we discuss various ways of running DAOs, the more we need an objective function to measure the success of DAOs in order to compare good/bad/better DAO structures and operating mechanisms. The creation of any purpose in this field inevitably involves the following questions: How do we best organize the masses? And, I don't think it's controversial at all: it's still an unresolved issue.

My personal thoughts on the future of DAOs will be addressed in my own article. So, to keep this post short, I'll quickly share some links to previous articles on the topic of DAOs to provide some context for our discussion and spark our philosophical aesthetic before I move on to more practical issues

How does decentralized governance benefit users who receive on-chain data sources? Why  API3 DAO instead of a centralized project?

That said, I'd rather answer these questions with concrete examples of specific project reasons than some form of platitude that "decentralization is good ” argument (in general, I do believe it, but it wasn’t the original “hot spot”).

Theory: Why DAO is needed

The DAO was created to help blockchain protocols deal with the unknown. That is, if the protocol can be perfectly designed from the beginning, then creating a DAO to oversee changes to the protocol is completely unnecessary

Autonomous Agents are one of the hardest things to create because in order to succeed they need to be able to operate in an environment that is not only complex and rapidly changing, but also hostile .

The ideal of a decentralized autonomous organization is easy to describe: it is an entity that lives on the Internet and exists autonomously, but also relies heavily on Hiring individuals to perform certain tasks that automated mechanisms cannot do by themselves.

—Vitalik Buterin, 2014

< img alt="How do cryptocurrency projects benefit from DAO governance? Take API3 as an example" src="https://img.chainnews.com/material/images/5f04dbbf07306fab7f283a4ee5a0ae3b.jpg-article">

The bee became trapped in the amber and became part of the fossil. Nick Szabo has previously used the "fly trapped in amber" analogy to explain blockchains, specifically immutability and block confirmation times. (Image via George Poinar Jr./OSU)

In many ways, one of the greatest advantages of the blockchain is its immutability; however, like all Like everything else, there is always a negative side hidden behind the positive. What if a sub-optimal implementation of the protocol becomes immobilized in the blockchain like amber?

Perhaps one could create an autonomous agent that lives on the blockchain and is so perfectly designed for its particular environment that it never needs to Human input (or, perhaps, use for a short time.) But the more complex the protocol, the less likely this assumption of perfect engineering holds.

When a protocol is created, there will be many unknowns. In fact, many blockchain projects are able to specify, before they even get started, what uncertainties (known unknowns) their protocols will have to resolve in the future; like the price of ETH faced by many mortgage lending platforms Variation and volatility. These known unknowns are usually resolved through the use of oracles. More worryingly, however, the protocol is likely to encounter unknown unknowns. The presence of these types of unknowns is either ignored, causing the project or fork to fail, or they are anticipated and prepared for by the DAO.

Nowadays, many projects rightly recognize that the future will inevitably encounter unknown problems, so choose to open up their protocols in order to decentralize through DAO Propose and agree on future amendments (to maintain the good looks of an end-to-end decentralized system) in a consistent manner.

How to best structure a DAO

The title of this section may be a bit misleading, Because I'm not going to offer a solution (and there's no way to offer one right now). Instead, I'll simply mention some good articles and some good points on the topic.

In this 2014 article, Vitalik Buterin contrasts/compares DAOs to traditional institutions and even robots and AI (Autonomous Agents) Define DAOs. He ends with a number of open-ended questions (“difficulties”), including: “Should membership [in a DAO] be a corporation, with shares that can be sold and transferred, or a non-profit, where members can vote other members"? Should the DAO try to maintain balances in other currencies, or just reward behavior by issuing its own internal tokens?

There is also an excellent article written by Daniel Kronovet last year. In the book, he compares the technical implementations and fundamental perspectives of four major DAOs: Aragon, DAOstack, Colony, and Moloch. Kronovet also poses several open-ended questions that are difficult to answer: How permeable should organizational boundaries be (ease of entry into the organization)? How influential should each individual be? How can individuals be protected from the bad behavior of others? • How difficult is it to get involved?

In a recent article by Joshua Tao, he argues that DAOs are not just a bunch of smart contracts; An entity composed of individuals. He therefore focused his attention on a holistic approach to DAOs, combining technical engineering and social design. Four key concepts are defined as Institution, Organization, Constitution, Computable Constitution, and combined to create a framework within which to examine the current DAO landscape. His conclusions are open, like the others: but there is still much to explore.

I see all these discussions are roughly boiled down to push-pull/yin-yang everywhere structure vs. variability (or rigidity vs. flow, or order vs. chaos, ...). How many DAOs need to be hardcoded and immutable? How much of it can be changed and modified? How true is "code is law"? Is the structure of the DAO solely enforced and maintained on the blockchain via immutable smart contracts, or does the structure also exist as a social contract enforced by social consensus?

These very basic questions quickly break the domain of political science, sociology, and a few other major disciplines. In this brief article, we will not discuss these things again anyway. But I do want to point out that we've been paying attention to these issues.

My personal opinion is that just like human language usually evolves in a beautiful and complex structure that does not disintegrate, is stable and constantly changing, DAO It is also possible to balance systems and mobility so that they develop and strengthen as they embark on uncharted paths. (My belief in this was also increased by encountering the word DAO (道), which is an ancient Chinese word that symbolizes the fusion of road, path and doctrine.)

Now, let's discuss some more practical issues.

Practice: How API3 Benefits from Being a DAO

By solving the API connection problem, we Not only dealing with the blockchain, but also with the off-chain world, through which it has unique advantages. Creating autonomous agents (via smart contracts) that can seamlessly interact with all the rich data types in the world (on-chain and off-chain) becomes even more difficult. This requires the creation of a DAO to manage the protocol.

Four practical use cases below highlight why DAOs are particularly beneficial for API3 projects.

Organizational Scalability

By default, DAOs have members creating proposals and Vote (change/modify the blockchain protocol) to work. This default behavior is not particularly efficient or scalable. However, DAOs have the potential to be more efficient than their traditional corporate counterparts.

An example governance topology consisting of master DAOs, sub DAOs, and teams distributed on-chain. DAO entities manage by selectively allocating funds and decentralizing power. When a task reaches a size that a team can no longer complete, it is assigned to a child DAO

Compared to traditional corporate hierarchies, DAOs work through child DAOs And teams that support multisig are easier to parallelize (or fractal). This is because such substructures can function fairly independently, with minimal interference from larger governing entities, while still being driven by carefully designed incentives and constrained by certain procedural constraints.

The API3 DAO will vote on advanced parameters about the system, such as encouraging the best staking rewards. Additionally, the DAO will provide grants from the DAO Bank, which will determine the overall direction of the project. More granular tasks will be performed through a layered team structure.

Furthermore, uniquely, the API3 DAO will be initialized as a number of milestones, providing major signposts (or non-linear roadmaps) for the larger API3 goals, Thereby guiding the overall direction of the project. These are the themes and elements of the API3 story that will unite the community.

The foundation of all human cooperation is a belief in a shared story.

Yuval Harari: A Brief History of Humanity

Transparent data source structure

Users with data feed experience may want to know the accuracy, credibility and reliability of data sources . Especially if their system is particularly sensitive to errors and inaccuracies (e.g. a blockchain protocol with liquidation).

When using API3 DAO, the construction of new data sources is a completely open process, because each data source will have a proposal before it is implemented. DAOs will crowdsource and/or assign teams to evaluate API providers (and their accuracy, trustworthiness, and reliability) and translate opinions into appropriate data filtering and aggregation methods.

Each new data type introduced to the blockchain requires a custom specialized analysis approach. To illustrate this, consider the following: aggregating weather data from sensors (located in different locations), aggregating price data from multiple exchanges (representing different volumes), and aggregating binary yes/no responses. These are not the same thing, nor should data be treated as such.

The structure of the data source must be transparent and flexible. Anyone who digs deep into data understands that transparency and custom data analysis are critical, after all, data science is as much an art as it is a science.

Regulatory arbitrage

Hercules and the Hydra 1921. John Singer Sargent

By decentralizing control, one can Decentralizes the enforcement goals of the governors, resulting in a freer system. The advantage of DAOs is that regulators don't even have to go after them (either because they think they're benign, or they think it's futile to do so).

From a legal perspective, the proof that a blockchain is fully decentralized is that no one can control the system, and no one is legally responsible for it. It is not subject to regulations (such as securities laws) that usually apply in similar situations.

Central point of failure elimination

Data source and/or "decentralized" The centralized management of the oracle network means that these corresponding smart contract sets can be configured by a centralized single entity. This is a single point of failure. Importantly, this can cause administrative errors to go unnoticed, and can lead to data feed error reporting even when the underlying API and oracle are functioning normally. We have seen examples of this.

Centralized management has the power to reorganize data sources, which means switching oracles and the data sources they each represent. This is necessary for the long-term maintenance of the data source, but it exposes data source users to various abuses and attacks by the governance. It is easy for a centralized administrator to use substandard practices opaquely and, even more obviously, use their power to maliciously misreport. In any case, centralized governance of the oracle network and data transmission is not justified.

Conclusion and Final Blog Post Preview

We have discussed the evolving theory of DAOs , and more practically discusses how DAO governance can benefit the API3 project. Certain subtleties of the API connection problem make its solution particularly beneficial to decentralized governance.

If you have followed this series from the beginning, I am happy to tell you that I have now introduced you to the main ideas behind the design of API3, albeit with some coherent. Next week, in the final article in this series, I'll lay out these pieces again and show how they fit together to solve API connection problems.

Original link< /blockquote>

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia