Empowering an Autonomous Decentralized Corporation: Engaging with the External Landscape

In the initial segment of this series, we discussed how the web enables the creation of decentralized companies, entities that operate solely as distributed networks across the internet, executing the calculations that sustain them “alive” across numerous servers. Remarkably, these networks can also hold a Bitcoin balance and engage in transactions. These two abilities: the capability to reason, and the ability to preserve resources, are theoretically all that a market participant requires to thrive, assuming that its reasoning and resources enable it to generate sellable value rapidly enough to meet its own resource requirements. Nevertheless, in real-life scenarios, one significant obstacle persists: how to genuinely interact with the environment surrounding them.

Acquiring Information

The first of the two primary obstacles in this context is that of data input – how can a decentralized corporation acquire any information about the physical world? It is theoretically feasible for a decentralized corporation to operate without facts; a computing network might incorporate the Zermelo-Fraenkel set theory axioms from the outset and then embark on an infinite loop validating all potential mathematical theorems – although in practice even such a mechanism would need to somehow ascertain what types of theorems are of interest to the world; otherwise, we may simply discover that a+b=b+a, a+b+c=c+b+a,a+b+c+d=d+c+b+a and so forth. Conversely, a corporation possessing some insight into what people desire, and what resources are available to fulfill those desires, would be far more beneficial to society at large.

Here, we must differentiate between two types of data: self-validating data and non-self-validating data. Self-validating data is information that, once processed in a specific manner, in some sense, “confirms” its own legitimacy. For instance, if a specific decentralized corporation is searching for prime numbers containing the sequence ‘123456789’, then one can simply input ‘12345678909631’, and the corporation can computationally confirm that the number is indeed prime. The current temperature in Berlin, by contrast, is not self-validating whatsoever; it could be 11°C, yet it could also equally well be 17°C, or even 231°C; without external data, all three figures seem equally plausible.

Bitcoin presents an intriguing example to examine. Within the Bitcoin framework, transactions are partially self-validating. The notion of a “correctly signed” transaction is entirely self-validating; if the transaction’s signature passes the elliptic curve digital signature verification algorithm, then the transaction is deemed legitimate. In theory, one might assert that the correctness of the transaction’s signature is contingent on the public key in the preceding transaction; however, this does not detract from the self-validating characteristic – the transaction submitter can always be required to also submit the previous transaction. Nonetheless, there is one element that is not self-validating: time. A transaction cannot utilize funds before those funds were received and, even more significantly, a transaction cannot utilize funds that have already been expended. Given two transactions spending the same funds, either one could have hypothetically occurred first; there is no method to self-validate the correctness of one history over the other.

Bitcoin essentially addresses the time dilemma through a computational democracy. If the majority of the network concurs that events transpired in a specific order, that order is accepted as fact, and the incentive is for every participant in this democratic procedure to act honestly; if any participant fails to do so, then unless the rogue participant possesses more computational power than the rest of the network combined, their version of history will always represent a minority viewpoint and will therefore be rejected, denying the wrongdoer of any block rewards.

In a broader context, the fundamental principle we can extract from the blockchain concept is this: we can utilize some type of resource-democracy mechanism to vote on the accurate value of a certain fact, and ensure that individuals are encouraged to provide precise estimates by depriving everyone whose report does not align with the “mainstream opinion” of monetary incentives. The question remains, can this same principle be applied in other scenarios as well? One enhancement to Bitcoin that many people desire, for instance, is a form of price stabilization; if Bitcoin could monitor its own price concerning other currencies or commodities, for instance, the algorithm could issue additional bitcoins if the price is high and fewer if the price is low – naturally stabilizing the price and mitigating the significant fluctuations that the existing system endures. However, thus far, no one has identified a practical way to achieve such a goal. But why not?

The explanation lies in precision. It is certainly feasible to create such a protocol in theory: miners can express their own perception of the Bitcoin price in every block, and an algorithm utilizing that data could retrieve it by calculating the median of the last thousand blocks. Miners not within a certain margin of the median would face penalties. Nevertheless, the issue is that the miners are incentivized and have considerable flexibility to commit fraud. The argument is as follows: suppose the actual Bitcoin price is 114 USD, and you, as a miner with a significant share of network power (e.g., 5%), understand that there is a 99.99% probability that 113 to 115 USD will fall within the safe margin, so if you report a figure within that range, your blocks will not be rejected. What should you claim the Bitcoin price is? The solution is, something like 115 USD. The reasoning is that if you raise your estimate, the median provided by the network could end up being 114.05 BTC instead of 114 BTC, and the Bitcoin network will utilize this information to produce more funds – subsequently increasing your own future earnings at the expense of existing savers. Once everyone does this, even honest miners will feel compelled to adjust their estimates upwards to safeguard their own blocks from rejection due to insufficient price reports. At that juncture, the cycle resumes: the price is 114 USD, you are 99.99% confident that 114 to 116 USD will be within the secure margin, so you report 116 USD. Following that cycle, it’s 117 USD, then 118 USD, and before long, the entire network collapses in an episode of hyperinflation.

The problem outlined above specifically stemmed from two realities: firstly, there exists a range of acceptable possibilities regarding what the price is, and secondly, voters possess an incentive to nudge the result in a specific direction. If, rather than proof of work, proof of stake were implemented (i.e., one bitcoin = one vote instead of one clock cycle = one vote), then the inverse problem would emerge: all individuals would attempt to push the price down, as stakeholders do not wish for any new bitcoins to be minted at all. Could proof of work and proof of stake possibly be integrated to resolve the issue? Perhaps, perhaps not.

There exists yet another feasible method to tackle this dilemma, particularly for applications that operate at a higher level than the underlying currency: consider not the reported market rates, but the actual market rates. Suppose, for instance, there is already a framework akin to Ripple (or perhaps something utilizing colored coins) that incorporates a decentralized exchange for various cryptographic assets. Some assets may represent items like gold or US dollars, others might signify shares in a company, others smart property, and there would obviously also be trustless cryptocurrency like Bitcoin in the mix. Therefore, for any deceitful actors to exploit the system, they would not merely have to declare prices that are marginally inaccurate in their preferred way but also manipulate the genuine prices of these commodities – essentially, akin to a LIBOR-style price manipulation scheme. Furthermore, as demonstrated by experiences over the past few years, LIBOR-like price manipulation conspiracies are challenges that even human-governed systems may struggle to surmount.

Moreover, this intrinsic flaw that complicates the acquisition of precise prices without a crypto-market is not universally applicable. Regarding prices, there is undoubtedly significant potential for deceit – and what has been discussed above scarcely scratches the surface of the total corruption that is feasible. If we anticipate Bitcoin to endure considerably longer than specific fiat currencies, for example, we might want the currency generation procedure to focus on Bitcoin’s price in terms of various commodities, rather than singular currencies like the USD, thus leaving the inquiry about which commodities to employ open to various “interpretations”. Nevertheless, in several other instances, such issues do not arise. If we aim to establish a decentralized database to track weather conditions in Berlin, for example, there is no substantial incentive to manipulate it one way or another. Technically, if decentralized entities began engaging in crop insurance, this situation could alter to some degree, but even in that scenario, the risk would diminish, as there would be two factions pulling in opposing directions (namely, farmers who might want to exaggerate drought conditions, and insurers who would rather deny such occurrences). Consequently, even with contemporary technology, a decentralized weather network remains entirely feasible to create.

Influencing The Environment

With a kind of democratic voting framework, as reasoned above, it is conceivable for a decentralized entity to acquire knowledge about the world. However, is it feasible to reverse this process? Can a corporation indeed exert influence on its environment in ways that are more significant than merely waiting for individuals to attribute value to its database entries as Bitcoin does? The response is affirmative, and several mechanisms exist to fulfill this objective. The first, and most apparent, is to utilize APIs. An API, or application programming interface, is a set of protocols designed explicitly to enable software applications to interact with a specific website or software application. For instance, dispatching an HTTP GET request tohttp://blockchain.info/address/1AEZyM6pXy1gxiqVsRLFENJLhDjbCj4FJz?format=json sends a command to blockchain.info’s servers, which, in turn, provide a file containing the latest transactions to and from the Bitcoin address 1AEZyM6pXy1gxiqVsRLFENJLhDjbCj4FJz in a format that is easy for computers to process. Throughout the last decade, as commerce has progressively transitioned online, the availability of services accessible via API has surged. We have internet search, weather data, online discussion forums, stock trading, and new APIs are being developed every year. With Bitcoin, we possess one of the most vital components: an API for currency.

Nevertheless, one significant, and somewhat ordinary, issue persists: it is presently impossible to issue an HTTP request in a decentralized manner. The request ultimately must reach the server in one complete segment, requiring it to be assembled wholly somewhere. For inquiries solely intended to retrieve public data, like the blockchain query outlined above, this does not pose a significant problem; a voting protocol can resolve it. However, if the API necessitates a private key for access, as all APIs facilitating activities like purchasing resources inherently do, having the private key exposed in its entirety, in plaintext, anywhere other than the final recipient, immediately jeopardizes the confidentiality of the private key. Mandating requests to be signed mitigates this issue; signatures, as previously discussed, can be generated in a decentralized manner, and signed requests cannot be altered. Unfortunately, this demands additional effort from API developers to implement, and thus far, we are far from universally adopting signed API requests as a norm.

Even with that challenge addressed, another complication remains unresolved. Communicating with an API poses no challenge for a computer application; however, how does the application initially learn about that API? How does it adapt to changes in the API? What if the organization managing a specific API experiences a total shutdown, while others emerge to fill the gap? What happens if the API is terminated, with no alternatives available? Lastly, what if the decentralized corporation needs to modify its own source code? These are dilemmas that computers find far more challenging to tackle. To this, there exists only one solution: depend on humans for assistance. Bitcoin relies significantly on humans to sustain its operation; in March 2013, we witnessed how a blockchain fork necessitated active participation from the Bitcoin community to resolve issues, and Bitcoin is among the most stable decentralized computing protocols conceivable. Even in the event of a 51% attack, should a blockchain fork divide the network into three segments, and a DDoS attack disable the five major mining pools simultaneously, once the situation stabilizes, some form of blockchain will likely emerge victorious, the miners will rally around it, and the network will simply continue moving forward from there. More intricate corporations will undoubtedly be more vulnerable; if a currency-holding network inadvertently exposes its private keys, the consequence could lead to bankruptcy.

But how can humans be utilized without placing excessive trust in them? If the humans involved are assigned narrowly defined tasks that are easily measurable, such as constructing the fastest possible miner, then there is no problem. However, the tasks that humans must undertake are precisely those that are more challenging to quantify; how do you determine how much to reward an individual for uncovering a new API? Bitcoin addresses this challenge by simplifying the complexity by ascending one level of abstraction: Bitcoin’s stakeholders gain if the price escalates, so stakeholders are motivated to engage in activities that boost the price. In fact, regarding Bitcoin, an entire quasi-religion has developed around supporting the protocol and aiding its expansion and broader adoption; it is difficult to envision every corporation cultivating anything even remotely similar to such passionate allegiance.

Aggressive Acquisitions

In addition to the “future proofing” challenge, there exists another matter that necessitates attention: that of “aggressive acquisitions”. This constitutes theequivalent of a 51% assault in the scenario of Bitcoin, but the risks are greater. A hostile acquisition of a company managing funds implies that the aggressor acquires the capability to empty the entire treasury of the organization. A hostile acquisition of Decentralized Dropbox, Inc suggests that the intruder can access everyone’s documents (although ideally, those documents are encrypted; in the event of a breach, the intruder can still withhold access to everyone’s files). A hostile acquisition of a decentralized web hosting firm can result in significant damages not solely for those with hosted sites but also their patrons, as the intruder secures the power to alter web pages to transmit customers’ private information to their own server upon each customer logging in. How could a hostile acquisition be executed? In the context of the 501-out-of-1000 private key scenario, the solution is straightforward: impersonate countless different servers simultaneously and integrate into the organization with each one. By relaying communications through millions of infected machines belonging to a botnet, this can be achieved without being detected. Once you control over half of the servers in the network, you can swiftly proceed to liquidate assets.

Fortunately, the existence of Bitcoin has generated several solutions, with the proof of work employed by Bitcoin itself being merely one. Because Bitcoin serves as an ideal API for currency, any sort of protocol involving monetary scarcity and incentives is now accessible for computer networks to implement. Proof of stake, necessitating each participating node to demonstrate control over, for instance, 100 BTC, is one potential remedy; if this is achieved, executing a hostile acquisition would require more resources than all the legitimate nodes combined. The 100 BTC could even be transferred to a multisignature wallet partially owned by the network as a safety deposit, both deterring nodes from cheating and incentivizing their owners to act collectively to sustain the corporation.

Another option could simply involve permitting the decentralized corporation to have shareholders, granting them special voting rights alongside the entitlement to a portion of the profits in exchange for their investment; this would likewise motivate the shareholders to safeguard their investment. Conducting a more granular evaluation of an individual employee is likely impractical; a more effective solution might be to utilize financial rewards to guide individuals’ actions on a broader scale, and then allow the community to self-organize for more precise modifications. The degree to which a corporation focuses on a community for investment and engagement, rather than on specific individuals, is determined by its initial developers. On one hand, concentrating on a community can facilitate collaborative problem-solving among human supporters in large collectives. Conversely, maintaining individual separation can help avert collusion, thereby minimizing the probability of a hostile acquisition.

Thus, it is clear that considerable challenges persist before any form of decentralized corporation can achieve viability. The issue will likely be addressed incrementally. First, with the emergence of Bitcoin, a self-sustaining layer of cryptographic currency has been established. Subsequently, with Ripple and colored coins, we anticipate the rise of crypto-markets which could provide crypto-corporations with precise pricing information. Simultaneously, we are likely to witness the development of an increasing number of crypto-friendly APIs tailored to meet the demands of decentralized systems. Such APIs will be essential regardless of whether decentralized corporations ever materialize; given the current difficulties in securing cryptographic keys, the requirement for infrastructure suited for multiparty signing will probably become crucial. For instance, major certificate signing authorities possess private keys that could lead to massive security breaches worth hundreds of millions of dollars if they were to fall into malicious hands, prompting these organizations to often adopt some form of multiparty signing already.

Ultimately, it will still require time for individuals to clearly define how these decentralized corporations will function. Software technology is increasingly emerging as the paramount foundational element of our contemporary world, yet until now, research in this area has largely concentrated on two domains: artificial intelligence, which operates autonomously, and software tools that assist human users. The key inquiry is: is there something that falls between these two?. If such a balance exists, the concept of software guiding humans—namely, the decentralized corporation—fits that description perfectly. Contrary to apprehensions, this wouldn’t manifest as a malevolent, unfeeling robot imposing tyrannical control over humanity; in reality, the tasks that would need to be outsourced by the corporation are precisely those that demand the most human liberty and innovation. Let’s explore if this is feasible.

See also:

http://bitcoinmagazine.com/7050/bootstrapping-a-decentralized-autonomous-corporation-part-i/