Reposted from: old yuppie
US presidential candidate Mitt Romney reminds us that corporations are made of individuals. Whether you agree with him or not, there's a lot of truth in that statement. After all, why is it called a company and not a group of people working together under certain rules? When a corporation owns property, the legal contract states that the property can only be under the control of the board of directors. If a company does something, it's because its board of directors has agreed that it should be done. If a company hires an employee, it means that the employee agrees to provide services to the company's clients according to a specific set of rules, especially when payments are involved. When a company has limited liability, it means specific people are granted additional privileges to act, reducing the fear of legal prosecution by the government — a group of people has more rights than the average person acting alone, but ultimately an individual. In any case, it's nothing more than people and contracts all the way down.
However, a very interesting question arises here: do we really need people? On the one hand, the answer is yes: while in some post-singularity future machines will be able to survive on their own, for the foreseeable future human behavior and interaction with the physical world will be required. On the other hand, however, over the past 200 years, the answer to this question has increasingly been no. The Industrial Revolution allowed us to replace human labor with machines on a large scale for the first time, and now we have advanced digital factories and robotic arms that can produce complex goods such as cars by ourselves. But that's just automation at the bottom of the base. Eliminate the need for ordinary manual labor and use a handful of professionals to maintain the robots while the company's management remains the same. The real question is, can we approach this problem from another direction? Even if we still need humans to perform certain specialized tasks, can we remove management from the equation?
Most companies have some sort of mission statement; usually to make money for shareholders; at other times include some ethical obligation related to the product, and other goals like helping the community get involved sometimes, at least in theory. Currently, that mission statement exists only if it is interpreted by the board of directors and ultimately shareholders. But what if, with the power of modern information technology, we could encode our mission statement into code? That is, create an inviolable contract that generates revenue, pays people to perform certain functions, and finds itself the hardware to run on, all without top-down human direction?
As Daniel Larmier of Let's Talk Bitcoin points out in his own exploration of the concept, in a sense Bitcoin itself could be considered an early prototype of such a thing. There are 21 million shares in Bitcoin, which are owned by Bitcoin shareholders. It has employees, and has an agreement to pay them: 25 bitcoins to a random employee approximately every ten minutes. It even has its own marketing department, largely staffed by shareholders themselves. However, it's also very limited, it knows next to nothing about the world, it can't change any aspect of its function other than difficulty, and it doesn't really have anything in itself; it just exists, and is left for the world to recognize it. The question is: can we do better?
calculate
The first challenge is obvious: how would such a company actually make any decisions? It's easy to write code that, given a predictable environment, takes a given input and calculates the action to take. But who will run the code? If the code exists only as a computer program on a particular machine, what prevents the owner of that machine from shutting down the entire device, or even modifying the code to send all the funds to himself? There is only one valid answer to this question: distributed computing.
However, the distributed computing we are looking for here is not the same as in projects like SETI@home and Folding@home; in these cases there is still a central server collecting data from distributed nodes and sending requests. Instead, we need the kind of distributed computation we see in Bitcoin: a set of rules for decentralized, self-validating computation. In Bitcoin, this is done with simple majority voting: if you do not contribute to computing the blockchain with majority network power, your block will be discarded and you will not receive any block rewards. The theory is that no single attacker has enough computing power to break this mechanism, so the only viable strategy is to "go with the flow" and act honestly to help support the network and earn one's block reward.
So can we simply apply this mechanism to decentralized computing? That is, can we simply ask every computer in the network to evaluate a program, and reward only those whose answer matches the majority vote? Unfortunately, the answer is no. Bitcoin is a special case because Bitcoin is simple: it is just a currency that does not carry property or private data of its own. On the other hand, virtual companies may need to store private keys into their bitcoin wallets — data that should be completely available to no one , nor is it available to everyone like bitcoin transactions. But, of course, the private key must still be available. Therefore, we need some transaction signature system that can be computed in a decentralized way, and even generate bitcoin addresses. Fortunately, Bitcoin allows us to do just that.
The first solution that immediately comes to mind is multi-signature addresses. Given a thousand computers, those computers might go on to support the companies, have each of them create a private key, and generate a 501-of-1000 multi-signature address between them. To spend these funds, simply construct a transaction with signatures from any 501 nodes and broadcast it to the blockchain. The problem here is obvious: the transaction volume is too large. Each signature contains about 70 bytes, so 501 of them will be 35 KB transactions - which is very difficult to be accepted by the network, because bitcoind rejects any transaction with a script larger than 10,000 bytes by default. Second, the solution is for the bit currency; if a company wants to store private data for non-financial purposes, multi-signature scripts are useless.
Multi-signature addresses work because there is a bitcoin network evaluating them, and based on whether the evaluation was successful, the transaction is put into the blockchain. In the case of private data, a similar solution would basically require some decentralized authority to store the data and only send it out as needed if the request has 501 signatures out of 1000 - back to the beginning The place.
However, another solution still holds promise; the common name given to it by cryptographers is "secure multi-party computation." In Secure Multiparty Computation, the input to the program (or, more precisely, the input to the simulated "circuit", since Secure Multiparty Computation cannot handle "if" statements and conditional loops) is split using an algorithm called Shamir's secret sharing, And a piece of information is given to each participant. Shamir's secret sharing can be used to split any data into N pieces such that any K of them (but no K-1) are enough to recover the original data - you choose what K and N are when you run the algorithm. 2-of-3, 5-of-10 and 501-of-1000 are all possible. Fragments of data can then be evaluated in a decentralized fashion, so that at the end of the computation everyone has a fragment of the result of the computation, but during the computation no one gets even the slightest glimpse of what is going on.
Finally, the pieces are put together to show the results. The running time of the algorithm is O(n3), which means that the number of computation steps required for the evaluation computation is roughly proportional to the cube of the number of participants; at 10 nodes, 1000 computation steps, at 1000 nodes, 1 billion steps. On my own laptop, a simple C++ billion-step loop takes about 20 seconds, while the server can do it in a fraction of a second, so 1000 nodes is roughly at the limit of computational practicality right now.
It turns out that secure multi-party computation can be used to generate Bitcoin addresses and sign transactions. For address generation, the protocol is simple:
Everyone generates a random number as a private key.
Everyone calculates the public key corresponding to the private key.
Everyone discloses their public key and uses Shamir's secret sharing algorithm to compute a public key that can be reconstructed from any 501 of the thousand public keys disclosed.
An address is generated from this public key.
Because public keys can be added, subtracted, multiplied and even divided by integers, surprisingly, this algorithm works exactly as you'd expect. If everyone put together a 501-of-1000 private key in the same way, that private key would be able to send money to addresses generated by applying the 501-of-1000 algorithm to the corresponding public key spend. This works because Shamir's secret sharing is really just an algebraic formula — that is, it uses only addition, subtraction, multiplication, and division, and it can be computed "by" a public key as easily as an address; So it doesn't matter whether the conversion of private key to public key is done before or after the algebra. Signing a transaction can be done in a similar fashion, although the process is slightly more complicated.
The beauty of secure multi-party computation is that it is not limited to Bitcoin; it can easily be used to run the artificial intelligence algorithms that companies rely on to run. So-called "machine learning" is the generic name for a set of algorithms that detect patterns in real-world data and allow computers to model them without human intervention, and are used in things like spam filters and self-driving cars. widely used in the field. "Just algebra", can also be implemented in secure multi-party computation. In fact, any computation can, if the computation is broken down into circuits on the individual bits of the input. There are naturally some limits to the possible complexity. Converting a complex algorithm to a circuit often introduces additional complexity, and as mentioned above, Shamir's Secret Sharing itself becomes expensive. As such, it should only really be used to implement the "core" of the algorithm; more complex high-level thinking tasks are best tackled by external contractors.
By Vitalik Buterin September 19, 2013
YouQuan
Aaron
Alex
Hui Xin
Brian