스마트 컨트랙트 (4) | 이더리움, DAO

Ethereum is the community-run technology powering the cryptocurrency ether (ETH) and thousands of decentralized applications. @Ethereum.org https://ethereum.org/en/

 

1. 이더리움의 유래

 

[비탈릭 부테린과 Colored Coin, 마스터 코인의 조우]

 

이더리움의 유래에 대해 간략히 짚고 넘어가자. 이더리움의 창시자인 비탈릭 부테린은, 2011년 비트코인 매거진에서 비트코인 관련 아티클을 작성하기 시작하면서 암호화폐 생태계에 발을 들였다. 2013년 대학교에 입학했으나 이내 학업을 멈추고, 비트코인 커뮤니티를 돌아다니고자 여행을 떠난다. 이전 글에서도 다뤘듯, 비트코인을 하부 구조 삼아 스크립트에 데이터를 담는 새로운 코인, 컬러드 코인 프로젝트들이 당시 유행했고, 그렇게 여행에서 컬러드코인의 대표주자, 마스터코인 팀을 만나게 된다. 

 

[BITCOIN IN ISRAEL: INTERVIEW WITH MENI ROSENFELD AND RON GROSS, PART I]

Although it has faded somewhat from the press in recent months, Israel remains one of the major hubs of the Bitcoin community worldwide. The country may only have a population of 8 million, but its technological and financial center, Tel Aviv, (...), and is arguably the birthplace of a Bitcoin technology that has seen a considerable amount of attention in the past few weeks: colored coins. The theoretical background behind the idea was developed with the help of Meni Rosenfeld, an Israeli mathematician who has also been a main organizer of the Israeli Bitcoin community for the last two and a half years. The furthest developed implementation of the project today, Webcoinx, was written mostly by Ukrainian developer Alex Mizrahi, but was funded by eToro, a popular “social investing” network whose main offices are also located in Tel Aviv.
...
In this multipart interview, Meni Rosenfeld and Ron Gross will talk about developments in the Israeli Bitcoin community, their own efforts in organizing community events and meetups, their other Bitcoin-related projects and the vision that they have for the Israeli Bitcoin Association.

Vitalik Buterin, 2013-10-17, Bitcoin Magazine
https://bitcoinmagazine.com/culture/bitcoin-in-israel-interview-with-meni-rosenfeld-and-ron-gross-part-i-1382036609 

 

[BITCOIN IN ISRAEL, PART 3: INTERVIEW ON ALTERNATIVE CURRENCIES]

More recently, a new type of cryptocurrency has started to appear: Bitcoin blockchain-based overlay currencies. These currencies, of which Bitshares and Mastercoin are currently the two leading contenders, do not try to live on their own blockchains; rather, they are a sort of overlay networks on top of Bitcoin, piggybacking on the Bitcoin transaction system to store data. Every Mastercoin transaction is a Bitcoin transaction, but the way in which the transaction is interpreted is different; what a Bitcoin client might see as an innocent transfer of a few satoshis a Mastercoin client may well see as the creation of a whole new currency inside the Mastercoin network. Are alternative currencies the future? Are any of the current ones likely to succeed, or is there still a missing piece of the puzzle? Read this interview for a glimpse into the state of alternative currencies right now.

Ron Gross is heavily involved in the Mastercoin project, but also runs Bitblu, a business whose goal is to make it easier for people to diversify their savings across many different alternative currencies, and Meni Rosenfeld is a cryptocurrency enthusiast and a key Bitcoin community organizer in Israel.

Vitalik Buterin, 2013-10-26, Bitcoin Magazine
https://bitcoinmagazine.com/business/bitcoin-in-israel-part-3-interview-on-alternative-currencies-1382840361 

 

 

 

[마스터 코인에 새로운 스크립트 언어를 추가하는 방법을 제안]

 

앞서 만남을 가진 마스터코인팀에게, 비탈릭 부테린은 보다 보편성을 가지는 방안에 대해 제안을 했고, 그 일화는 아래 링크 및 아티클에 자세히 소개되어 있다. 

 

[A Prehistory of the Ethereum Protocol]

Let us first begin with the very earliest version of what would eventually become Ethereum, back when it was not even called Ethereum. When I was visiting Israel in October 2013, I spent quite a bit of time with the Mastercoin team, and even suggested a few features for them. After spending a couple of times thinking about what they were doing, I sent the team a proposal to make their protocol more generalized and support more types of contracts without adding an equally large and complex set of features: https://web.archive.org/web/20150627031414/http://vbuterin.com/ultimatescripting.html 

Notice that this is very far from the later and more expansive vision of Ethereum: it specialized purely in what Mastercoin was trying to specialize in already, namely two-party contracts where parties A and B would both put in money, and then they would later get money out according to some formula specified in the contract (eg. a bet would say "if X happens then give all the money to A, otherwise give all the money to B"). The scripting language was not Turing-complete.

The Mastercoin team was impressed, but they were not interested in dropping everything they were doing to go in this direction, which I was increasingly convinced is the correct choice. So here comes version 2, circa December: https://web.archive.org/web/20131219030753/http://vitalik.ca/ethereum.html 

Vitalik Buterin, 2017-09-14, Blog
https://vitalik.ca/general/2017/09/14/prehistory.html 

A Prehistory of the Ethereum Protocol

 

그의 제안 사항은 아래의 원문에서 보다 자세히 확인할 수 있다.

 

[Ultimate Scripting: A Platform for Generalized Financial Contracts on Mastercoin]

Perhaps the key advantage of Mastercoin over the raw Bitcoin protocol is the potential to include much more advanced transaction types, including transactions that specify behavior based on future information well off into the future. For example, Mastercoin joins Ripple in being one of the only two major cryptocurrency networks that include the ability for users to make binding exchange offers as a type of transaction. From there, the Mastercoin Foundation intends to integrate even more complex contracts, including bets, contracts for difference and on-blockchain dice rolls. However, up until this point Mastercoin has been taking a relatively unstructured process in developing these idea, essentially treating each one as a separate "feature" with its own transaction code and rules. This document outlines an alternative way of specifying Mastercoin contracts which follows an open-ended philosophy, specifying only the basic data and arithmetic building blocks and allowing anyone to craft arbitrarily complex Mastercoin contracts to suit their own needs, including needs which we may not even anticipate.

The underlying idea behind this specification is to allow anyone to create a contract which pays out according to an arbitrary formula. The formula will be defined in a Bitcoin-like stack-based scripting language, consisting of numbers and opcodes.

https://web.archive.org/web/20150627031414/http://vbuterin.com/ultimatescripting.html 

 

 

[프로토콜의 범용 플랫폼으로서의 이더리움]

 

그리고 그 제안은 팀에게 거절당했지만, 이를 기반으로 비탈릭 부테린은 이더리움 백서를 작성했고, 그 백서를 통해 그의 문제의식에 공감한 팀이 모여 이더리움을 탄생시켰다. 아래는 그의 이더리움 구상 초기의 글이다.  

 

[Ethereum: The Ultimate Smart Contract and Autonomous Corporation Platform on the Blockchain]


In the last few months, there has been a great amount of interest into the area of using the Bitcoin blockchain, the mechanism that allows for the entire world to agree on the state of a public ownership database, for more than just money. Perhaps the first, and oldest, such alternative application is colored coins, which is a protocol that allows users to label specific bitcoins and treat them as assets representing some real world value - whether company shares, collectibles or even existing currencies like gold and USD. A more independent alternative, Ripple, also includes the ability to create custom currencies and assets, but adds a decentralized exchange. More recently, Mastercoin has started to go even further, allowing more complex financial contracts such as hedging, trust-free dice rolls, binary options and self-stabilizing currencies - essentially, almost any common financial instrument imaginable. Taken together, all of these projects can be thought of as initial efforts toward a sort of "cryptocurrency 2.0" - they are to Bitcoin what Web 2.0 was to the World Wide Web circa 1995.

At the same time, there has been significant interest in "decentralized autonomous corporations" - autonomous entities that operate on the blockchain in a completely transparent and publicly managed way without any central control whatsoever. Rather than the relationships of the investors, owners and employees of the corporation being mediated by a legal contract or a set of organizational bylaws, the funds and corporate resources are managed directly on the blockchain. However, decentralized autonomous corporations are difficult to implement today, simply because the scripting systems of Bitcoin, and even proto-cryptocurrency 2.0 alternatives like Ripple and Mastercoin, are far too limited to allow the kind of arbitrarily complex computation that DACs require. Although these platforms have begun to offer increasingly complex contracts such as financial derivatives, order matching and trust-free bets, the way that the protocols are set up is inherently limited and closed-ended: each of these use cases is treated as a specific transaction type, not allowing any way for users to build contracts that the developers have not specifically chosen to include.

What this project intends to do is take cryptocurrency 2.0, and generalize it - create a fully-fledged, Turing-complete (but heavily fee-regulated) cryptographic ledger that allows participants to encode arbitrarily complex contracts, autonomous agents and relationships that will be mediated entirely by the blockchain. On-chain currencies, futures contracts, prediction markets, Namecoin-style domain name systems and even provably fair gambling sites will become trivial to implement, existing as simple, hundred-line-of-code contracts on the chain.

...

The Ethereum protocol's design philosophy is in many ways the opposite from that taken by many other cryptocurrencies today. Other cryptocurrencies aim to add complexity and increase the number of "features"; Ethereum, on the other hand, takes features away. The protocol does not "support" multisignature transactions, multiple inputs and outputs, hash codes, lock times or many other features that even Bitcoin provides. Instead, all complexity comes from an all-powerful, Turing-complete assembly language, which can be used to build up literally any feature that is mathematically describable. The language itself follows an Orwellian Newspeak principle; any instruction which can be replaced by a sequence of less than four other instructions has been removed. As a result, we have a cryptocurrency protocol whose codebase is very small, and yet which can do anything that any cryptocurrency will ever be able to do.

https://web.archive.org/web/20131219030753/http://vitalik.ca/ethereum.html 

 

 

[From Programmable Money Platform To General Computing Platform]

 

나아가 이더리움 아이디어는 팀원이었던 Gavin Wood의 제안으로 일반 컴퓨팅 플랫폼 개념으로 확장된다. 이더리움은 하나의 컴퓨터로 전세계 누구나 접속해 사용 가능한, 자동 운영되는 월드 컴퓨터라는 개념이다. 

 

Gavin can also be largely credited for the subtle change in vision from viewing Ethereum as a platform for building programmable money, with blockchain-based contracts that can hold digital assets and transfer them according to pre-set rules, to a general-purpose computing platform. This started with subtle changes in emphasis and terminology, and later this influence became stronger with the increasing emphasis on the "Web 3" ensemble, which saw Ethereum as being one piece of a suite of decentralized technologies, the other two being Whisper and Swarm.

A Prehistory of the Ethereum Protocol, Vitalik Buterin, 2017-09-14
https://vitalik.ca/general/2017/09/14/prehistory.html 

 

 

 

 

 

 

 

2. Autonomous Corporation, DAO

 

이미 이전 글에서 스마트 컨트랙트의 의의를 설명할 때 기존 계약의 주체를 사람이 아닌 암호화폐 지갑, 프로그램이 대체할 수 있는 미래를 이야기한 바 있다. 이러한 비젼은 이더리움의 핵심적인 개념 중 하나이다. 스마트 컨트랙트, 프로그램의 범용 플랫폼으로서의 이더리움은 이를 기반으로 자율적 경제 주체의 실현을 꿈꾸었기 때문이다. 앞서 인용한 이더리움 백서 초안의 제목이 'Ethereum: The Ultimate Smart Contract and Autonomous Corporation Platform on the Blockchain'으로, "Autonomous Corporation Platform"이라는 단어가 핵심 주제어로 들어가 있음을 통해서 알 수 있다. 

 

이 개념의 유래는 댄 라리머의 글에서 찾아볼 수 있다.

 

[Overpaying For Security]

But before getting into some of these ideas, I would like to take a moment to introduce a new metaphor for explaining crypto-‘currencies’.

Think of a crypto-currency as shares in a Decentralized Autonomous Corporation (DAC) where the source code defines the bylaws. The goal of the DAC is to earn a profit for the shareholders by performing valuable services for the free market. With this goal in mind set out to maximize shareholder value at every stage as you design the bylaws that govern operation of the DAC.

The DAC only has one way that it can acquire the services it requires to operate and that is to pay for them with shares in the decentralized company. One service that is required is transaction validation, another is security against double-spend attacks by private (for-profit) criminals. Another service that is required is a viral marketing campaign. Other services include but are not limited to privacy for the customers and defense against traffic filtering.

The goal of a for-profit DAC is to maximize value and minimize costs. In this case, we only want the DAC to pay for useful security, but no more than necessary to maximize shareholder value.

Daniel Larimer, co-founder Invictus Innovations, Inc
2013-09-07, Let's Talk Bitcoin (LTB Network)
https://letstalkbitcoin.com/is-bitcoin-overpaying-for-false-security 

 

그에 공감한 비탈릭 부테린의 탈중앙화 자율 조직 관련 연재 아티클은 아래에서 찾아볼 수 있다.

 

[Bootstrapping A Decentralized Autonomous Corporation]

What is a corporation, after all, but a certain group of people working together under a set of specific rules? When a corporation owns property, what that really means is that there is a legal contract stating that the property can only be used for certain purposes under the control of those people who are currently its board of directors – a designation itself modifiable by a particular set of shareholder. If a corporation does something, it’s because its board of directors has agreed that it should be done. If a corporation hires employees, it means that the employees are agreeing to provide services to the corporation’s customers under a particular set of rules, particularly involving payment. When a corporation has limited liability, it means that specific people have been granted extra privileges to act with reduced fear of legal prosecution by the government – a group of people with more rights than ordinary people acting alone, but ultimately people nonetheless. In any case, it’s nothing more than people and contracts all the way down.

However, here a very interesting question arises: do we really need the people? On the one hand, the answer is yes: although in some post-Singularity future machines will be able to survive all on their own, for the forseeable future some kind of human action will simply be necessary to interact with the physical world. On the other hand, however, over the past two hundred years the answer has been increasingly no. The industrial revolution allowed us, for the first time, to start replacing human labor with machines on a large scale, and now we have advanced digitized factories and robotic arms that produce complex goods like automobiles all on their own. But this is only automating the bottom; removing the need for rank and file manual laborers, and replacing them with a smaller number of professionals to maintain the robots, while the management of the company remains untouched. The question is, can we approach the problem from the other direction: even if we still need human beings to perform certain specialized tasks, can we remove the management from the equation instead?

...

The first challenge is obvious: how would such a corporation actually make any decisions? It’s easy to write code that, at least given predictable environments, takes a given input and calculates a desired action to take. But who is going to run the code? If the code simply exists as a computer program on some particular machine, what is stopping the owner of that machine from shutting the whole thing down, or even modifying its code to make it send all of its money to himself? To this problem, there is only one effective answer: distributed computing.

(...) We need the kind of distributed computing that we see in Bitcoin: a set of rules that decentrally self-validates its own computation. In Bitcoin, this is accomplished by a simple majority vote: if you are not helping to compute the blockchain with the majority network power, your blocks will get discarded and you will get no block reward. (...) So can we simply apply this mechanism to decentralized computation? That is, can we simply ask every computer in the network to evaluate a program, and then reward only those whose answer matches the majority vote? The answer is, unfortunately, no. Bitcoin is a special case because Bitcoin is simple: it is just a currency, carrying no property or private data of its own. A virtual corporation, on the other hand, would likely need to store the private key to its Bitcoin wallet – a piece of data which should be available in its entirety to no one, not to everyone in the way that Bitcoin transactions are. But, of course, the private key must still be usable. Thus, what we need is some system of signing transactions, and even generating Bitcoin addresses, that can be computed in a decentralized way. Fortunately, Bitcoin allows us to do exactly that.

The first solution that might immediately come to mind is multisignature addresses; given a set of a thousand computers that can be relied upon to probably continue supporting the corporations, have each of them create a private key, and generate a 501-of-1000 multisignature address between them. To spend the funds, simply construct a transaction with signatures from any 501 nodes and broadcast it into the blockchain. The problem here is obvious: the transaction would be too large. Each signature makes up about seventy bytes, so 501 of them would make a 35 KB transaction – which is very difficult to get accepted into the network as bitcoind by default refuses transactions with any script above 10,000 bytes. Second, the solution is specific to Bitcoin; if the corporation wants to store private data for non-financial purposes, multisignature scripts are useless. Multisignature addresses work because there is a Bitcoin network evaluating them, and placing transactions into the blockchain depending on whether or not the evaluation succeeds. In the case of private data, an analogous solution would essentially require some decentralized authority to store the data and give it out only if a request has 501 out of 1000 signatures as needed – putting us right back where we started.

However, there is still hope in another solution; the general name given to this by cryptographers is “secure multiparty computation”. In secure multiparty computation, the inputs to a program (or, more precisely, the inputs to a simulated “circuit”, as secure multiparty computation cannot handle “if” statements and conditional looping) are split up using an algorithm called Shamir’s Secret Sharing, and a piece of the information is given to each participant. Shamir’s Secret Sharing can be used to split up any data into N pieces such that any K of them, but no K-1 of them, are sufficient to recover the original data – you choose what K and N are when running the algorithm. 2-of-3, 5-of-10 and 501-of-1000 are all possible. A circuit can then be evaluated on the pieces of data in a decentralized way, such that at the end of the computation everyone has a piece of the result of the computation, but at no point during the computation does any single individual get even the slightest glimpse of what is going on. Finally, the pieces are put together to reveal the result. The runtime of the algorithm is O(n3), meaning that the number of computational steps that it takes to evaluate a computation is roughly proportional to the cube of the number of participants; at 10 nodes, 1000 computational steps, and at 1000 nodes 1 billion steps. A simple billion-step loop in C++ takes about twenty seconds on my own laptop, and servers can do it in a fraction of a second, so 1000 nodes is currently roughly at the limit of computational practicality.

(...)

Part 1: Posted by Vitalik Buterin on December 31, 2013
https://blog.ethereum.org/2013/12/31/bootstrapping-a-decentralized-autonomous-corporation-part-i/ 



[Part 2: Interacting With the World]

In practice, however, one major challenge still remains: how to actually interact with the world around them.

The first of the two major challenges in this regard is that of input – how can a decentralized corporation learn any facts about the real world? It is certainly possible for a decentralized corporation to exist without facts, at least in theory; a computing network might have the Zermelo-Fraenkel set theory axioms embedded into it right from the start and then embark upon an infinite loop proving all possible mathematical theorems – although in practice even such a system would need to somehow know what kinds of theorems the world finds interesting; otherwise, we may simply learn that a+b=b+a, a+b+c=c+b+a,a+b+c+d=d+c+b+a and so on. On the other hand, a corporation that has some data about what people want, and what resources are available to obtain it, would be much more useful to the world at large.

Here we must make a distinction between two kinds of data: self-verifying data, and non-self-verifying data. Self-verifying data is data which, once computed on in a certain way, in some sense “proves” its own validity. For example, if a given decentralized corporation is looking for prime numbers containing the sequence ’123456789′, then one can simply feed in ’12345678909631′ and the corporation can computationally verify that the number is indeed prime. The current temperature in Berlin, on the other hand, is not self-verifying at all; it could be 11′C, but it could also just as easily be 17′C, or even 231′C; without outside data, all three values seem equally legitimate.

...

In a more general case, the fundamental idea that we can gleam from the blockchain concept is this: we can use some kind of resource-democracy mechanism to vote on the correct value of some fact, and ensure that people are incentivized to provide accurate estimates by depriving everyone whose report does not match the “mainstream view” of the monetary reward. The question is, can this same concept be applied elsewhere as well? One improvement to Bitcoin that many would like to see, for example, is a form of price stabilization; if Bitcoin could track its own price in terms of other currencies or commodities, for example, the algorithm could release more bitcoins if the price is high and fewer if the price is low – naturally stabilizing the price and reducing the massive spikes that the current system experiences. However, so far, no one has yet figured out a practical way of accomplishing such a thing. But why not?

...

With some kind of democratic voting protocol, we reasoned above, it’s possible for a decentralized corporation to learn facts about the world. However, is it also possible to do the opposite? Is it possible for a corporation to actually influence its environment in ways more substantial than just sitting there and waiting for people to assign value to its database entries as Bitcoin does? The answer is yes, and there are several ways to accomplish the goal. The first, and most obvious, is to use APIs. An API, or application programming interface, is an interface specifically designed to allow computer programs to interact with a particular website or other software program. (...) Over the past ten years, as business has increasingly migrated onto the internet, the number of services that are accessible by API has been rapidly increasing. We have internet search, weather, online forums, stock trading, and more APIs are being created every year. With Bitcoin, we have one of the most critical pieces of all: an API for money.

However, there still remains one critical, and surprisingly mundane, problem: it is currently impossible to send an HTTP request in a decentralized way. The request must eventually be sent to the server all in one piece, and that means that it must be assembled in its entirety, somewhere. For requests whose only purpose is to retrieve public data, like the blockchain query described above, this is not a serious concern; the problem can be solved with a voting protocol. However, if the API requires a private API key to access, as all APIs that automate activities like purchasing resources necessarily do, having the private key appear in its entirety, in plaintext, anywhere but at the final recipient, immediately compromises the private key’s privacy. Requiring requests to be signed alleviates this problem; signatures, as we saw above, can be done in a decentralized way, and signed requests cannot be tampered with. However, this requires additional effort on the part of API developers to accomplish, and so far we are nowhere near adopting signed API requests as a standard.

Even with that issue solved, another issue still remains. Interacting with an API is no challenge for a computer program to do; however, how does the program learn about that API in the first place? How does it handle the API changing? What about the corporation running a particular API going down outright, and others coming in to take its place? What if the API is removed, and nothing exists to replace it? Finally, what if the decentralized corporation needs to change its own source code? These are problems that are much more difficult for computers to solve. To this, there is only one answer: rely on humans for support. Bitcoin heavily relies on humans to keep it alive; we saw in March 2013 how a blockchain fork required active intervention from the Bitcoin community to fix, and Bitcoin is one of the most stable decentralized computing protocols that can possibly be designed. Even if a 51% attack happens, a blockchain fork splits the network into three, and a DDoS takes down the five major mining pools all at the same time, once the smoke clears some blockchain is bound to come out ahead, the miners will organize around it, and the network will simply keep on going from there. More complex corporations are going to be much more fragile; if a money-holding network somehow leaks its private keys, the result is that it goes bankrupt.

But how can humans be used without trusting them too much? If the humans in question are only given highly specific tasks that can easily be measured, like building the fastest possible miner, then there is no issue. However, the tasks that humans will need to do are precisely those tasks that cannot so easily be measured; how do you figure out how much to reward someone for discovering a new API? Bitcoin solves the problem by simply removing the complexity by going up one layer of abstraction: Bitcoin’s shareholders benefit if the price goes up, so shareholders are encouraged to do things that increase the price. In fact, in the case of Bitcoin an entire quasi-religion has formed around supporting the protocol and helping it grow and gain wider adoption; it’s hard to imagine every corporation having anything close to such a fervent following.

(...)

Part 2: Posted by Vitalik Buterin on December 31, 2013
https://blog.ethereum.org/2013/12/31/bootstrapping-an-autonomous-decentralized-corporation-part-2-interacting-with-the-world/ 



[Part 3: Identity Corp]

However, there is still one question that we have not answered: what might such corporations be useful for? Bitcoin developer Jeff Garzik once suggested that one application migh be a sort of decentralized Dropbox, where users can upload their files to a resilient peer-to-peer network that would be incentivized to keep those files reliably backed up. But aside from this particular example, what other applications might there be? What are the industries where decentralized corporations will not simply be a gimiick, but will rather be able to survive on their own merits and provide genuine value to society?

Arguably, there are three major categories where this is the case. First, there are the natural monopolies. For certain kinds of services, it simply makes no sense to have many hundreds of competing offerings all working at the same time; software protocols, languages and to some extent social networks and currencies all fit into this model. However, if the providers of these services are not held in check by a competitive market, the question is, who does hold them in check? Who ensures that they charge a fair market price for their services, and do not set monopoly prices thousands of times above what the product actually costs to produce? A decentralized corporation can theoretically be designed so that no one involved in the price-setting mechanism has any such incentive. More generally, decentralized corporations can be made invulnerable to corruption in ways unimaginable in human-controlled system, although great care would certainly need to be taken not to introduce other vulnerabilities instead; Bitcoin itself is a perfect example of this.

Second, there are services that violate government laws and regulations; the use of decentralized file-sharing networks for copyright infringement, and to a much lesser extent the use of Bitcoin on sites like Silk Road, are both examples. As Satoshi Nakamoto put it, “Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.”

Finally, there are those cases where a decentralized network can simply maintain itself more efficiently and provides better services than any centralized alternative; the peer-to-peer network used by Blizzard to distribute updates to its massively multiplayer online game World of Warcraft is perhaps one of the purest examples.

(...)

Part 3: Posted by Vitalik Buterin on December 31, 2013
https://blog.ethereum.org/2013/12/31/bootstrapping-a-decentralized-autonomous-corporation-part-3-identity-corp/ 

Bootstrapping A Decentralized Autonomous Corporation: Part I

 

그의 생각은 아래의 아티클에서 더 찾아볼 수 있다.

 

[DAOS ARE NOT SCARY, PART 1: SELF-ENFORCING CONTRACTS AND FACTUM LAW]

Many of the concepts that we promote over in Ethereum land may seem incredibly futuristic, and perhaps even frightening, at times. We talk about so-called “smart contracts” that execute themselves without any need, or any opportunity, for human intervention or involvement, people forming Skynet-like “decentralized autonomous organizations” that live entirely on the cloud and yet control powerful financial resources and can incentivize people to do very real things in the physical world, decentralized “math-based law”, and a seemingly utopian quest to create some kind of fully trust-free society. To the uninformed user, and especially to those who have not even heard of plain old Bitcoin, it can be hard to see how these kinds of things are possible, and if they are why they can possibly be desirable. The purpose of this series will be to dissect these ideas in detail, and show exactly what we mean by each one, discussing its properties, advantages and limitations.

The first installment of the series will talk about so-called “smart contracts”. Smart contracts are an idea that has been around for several decades, but was given its current name and first substantially brought to the (cryptography-inclined) public’s attention by Nick Szabo in 2005. In essence, the definition of a smart contract is simple: a smart contract is a contract that enforces itself. That is to say, whereas a regular contract is a piece of paper (or more recently PDF document) containing text which implicitly asks for a judge to order a party to send money (or other property) to another party under certain conditions, a smart contract is a computer program that can be run on hardware which automatically executes those conditions. (...)

(...)

At this point, however, one obvious question arises: how are these contracts going to be enforced? Just like traditional contracts, which are not worth the paper they’re written on unless there’s an actual judge backed by legal power enforcing them, smart contracts needs to be “plugged in” to some system in order to actually have power to do anything. The most obvious, and oldest, solution is hardware, an idea that also goes by the name “smart property”. Nick Szabo’s vending machine is the canonical example here. Inside the vending machine, there is a sort of proto-smart-contract, containing a set of computer code that looks something like this: (...)

(...)

However, physical property is very limited in what it can do. Physical property has a limited amount of security, so you cannot practically do anything interesting with more than a few tens of thousands of dollars with a smart-property setup. And ultimately, the most interesting contracts involve transferring money. But how can we actually make that work? Right now, we basically can’t. We can, theoretically, give contracts the login details to our bank accounts, and then have the contract send money under some conditions, but the problem is that this kind of contract is not really “self-enforcing”. The party making the contract can always simply turn the contract off just before payment is due, or drain their bank account, or even simply change the password to the account. Ultimately, no matter how the contract is integrated into the system, someone has the ability to shut it off.

How can we solve the problem? (...) With Bitcoin, however, we have a new kind of money: factum money. The difference between fiat money and factum money is this: whereas fiat money is put into existence, and maintained, by a government (or, theoretically, some other kind of agency) producing it, factum money just is. Factum money is simply a balance sheet, with a few rules on how that balance sheet can be updated, and that money is valid among that set of users which decides to accept it. Bitcoin is the first example, but there are more. For example, one can have an alternative rule, which states that only bitcoins coming out of a certain “genesis transaction”, count as part of the balance sheet; this is called “colored coins”, and is also a kind of factum money (unless those colored coins are fiat or commodity-backed).

The main promise of factum money, in fact, is precisely the fact that it meshes so well with smart contracts. The main problem with smart contracts is enforcement: if a contract says to send $200 to Bob if X happens, and X does happen, how do we ensure that $200 actually gets sent to Bob. The solution with factum money is incredibly elegant: the definition of the money, or more precisely the definition of the current balance sheet, is the result of executing all of the contracts. Thus, if X does happen, then everyone will agree that Bob has the extra $200, and if X does not happen then everyone will agree that Bob has whatever Bob had before.

(...)

However, there are places where smart contracts are not so good. Consider, for example, the case of an employment contract: A agrees to do a certain task for B in exchange for payment of X units of currency C. The payment part is easy to smart-contract-ify. However, there is a part that is not so easy: verifying that the work actually took place. If the work is in the physical world, this is pretty much impossible, since blockchains don’t have any way of accessing the physical world. Even if it’s a website, there is still the question of assessing quality, and although computer programs can use machine learning algorithms to judge such characteristics quite effectively in certain cases, it is incredibly hard to do so in a public contract without opening the door for employees “gaming the system”. Sometimes, a society ruled by algorithms is just not quite good enough.

Fortunately, there is a moderate solution that can capture the best of both worlds: judges. (...) Judges in a factum world, on the other hand, are very much different. A smart contract for employment might look like this:(...) In short, what this introduces is “judges as a service”. Now, in order to become a “judge” you need to get hired at a private arbitration firm or a government court or start your own. In a cryptographically enabled factum law system, being a judge simply requires having a public key and a computer with internet access. As counterintuitive as it sounds, not all judges need to be well-versed in law. Some judges can specialize in, for example, determining whether or not a product was shipped correctly (ideally, the postal system would do this). Other judges can verify the completion of employment contracts. Others would appraise damages for insurance contracts. It would be up to the contract writer to plug in judges of each type in the appropriate places in the contract, and the part of the contract that can be defined purely in computer code will be.

(...)

Vitalik Buterin, 2014-02-24, Bitcoin Magazine
https://bitcoinmagazine.com/technical/daos-scary-part-1-self-enforcing-contracts-factum-law-1393297672 

DAOs Are Not Scary, Part 1: Self-Enforcing Contracts And Factum Law