WhyManySmartContractUseCasesAreSimplyImpossible - kukgini/blockchain GitHub Wiki

Why Many Smart Contract Use Cases Are Simply Impossible 요약

스마트 컨트랙트에 대한 3가지 오해중 첫번째 Contaxting external services 가 오라클이 필요한 이유를 설명한다.

Often, the first use case proposed is a smart contract that changes its behavior in response to some external event. For example, an agricultural insurance policy which pays out conditionally based on the quantity of rainfall in a given month.

스마트 컨트렉트가 외부 사건에 따라 다른 행동을 하도록 한다. 예를 들어 농업 보험이 그달의 강수량에 기반하여 지불되는 경우.

The imagined process goes something like this: The smart contract waits until the predetermined time, retrieves the weather report from an external service and behaves appropriately based on the data received.

상상한 프로세스는 이럴 것임: 스마트 컨트랙트가 정해진 시간동안 외부 서비스에서 날씨 리포트를 받고 나서 받은 데이터를 기반으로 적절히 행동한다.

This all sounds simple enough, but it’s also impossible. Why? Because a blockchain is a consensus-based system, meaning that it only works if every node reaches an identical state after processing every transaction and block.

아주 쉬워 보이지만 불가능하다. 왜냐하면 블록체인은 컨센선스 기반 시스템이기 때문. 이말은 모든 노드가 트랜젝션과 블록을 처리한 후 동일한 상대에 도달해야만 시스템이 동작을 한다는 것이다.

Everything that takes place on a blockchain must be completely deterministic, with no possible way for differences to creep in. The moment that two honest nodes disagree about the chain’s state, the entire system becomes worthless.

블록체인에서 일어나는 일은 결정론적이어야 함. 두 노드가 체인의 상태에 다른 의견을 가지면 전체 시스템은 쓸모없어짐.

Now, recall that smart contracts are executed independently by every node on a chain. Therefore, if a smart contract retrieves some information from an external source, this retrieval is performed repeatedly and separately by each node. But because this source is outside of the blockchain, there is no guarantee that every node will receive the same answer.

모든 노드에서 스마트 컨트렉트는 독립적으로 실행됨을 상기하자. 그러므로 만약 스마트 컨트렉트가 외부 자원을 조회하면 이것은 모든 노드에서 반복해서 실행될 것이다. 하지만 이 정보가 블록체인 밖에서 들어오므로 모든 노드가 같은 답을 받아온다는 보장이 없다.

Perhaps the source will change its response in the time between requests from different nodes, or perhaps it will become temporarily unavailable. Either way, consensus is broken and the entire blockchain dies.

아마 소스는 시간에 따라 바뀔것이다. 또는 일시적 장애가 발생할 수도 있다. 어느쪽이던 컨센선스는 망가지고 전체 블록체인은 죽는다.

So, what’s the workaround? Actually, it’s rather simple. Instead of a smart contract initiating the retrieval of external data, one or more trusted parties (“oracles”) creates a transaction which embeds that data in the chain. Every node will have an identical copy of this data, so it can be safely used in a smart contract computation. In other words, an oracle pushes the data onto the blockchain rather than a smart contract pulling it in.

회피할 방법은? 단순하다. 스마트 컨트랙트가 외부 자원을 가져오는 대신, 신뢰할 수 있는 제3자 즉, 오라클 이 데이터를 트랜젝션에 담아 밀어 넣어 주는 것이다. 모든 노드는 동일한 데이터 사본을 가지므로 스마트 컨트랙트에서 안전하게 사용할 수 있다.

When it comes to smart contracts causing events in the outside world, a similar problem appears. For example, many like the idea of a smart contract which calls a bank’s API in order to transfer money. But if every node is independently executing the code in the chain, who is responsible for calling this API?

스마트 컨트랙트가 외부 세계 사건의 원인인 경우, 비슷한 문제가 발생함. 예를 들어, 스마트 컨트랙트가 은행 API 를 호출하여 돈을 전송하는 아이디어를 좋아한다. 하지만, 모든 노드가 독립적으로 실행된다면 누가 API 호출의 책임이 있는가?

If the answer is just one node, what happens if that particular node malfunctions, deliberately or not? And if the answer is every node, can we trust every node with that API’s password? And do we really want the API called hundreds of times? Even worse, if the smart contract needs to know whether the API call was successful, we’re right back to the problem of depending on external data.

만약 한 노드라고 한다치면, 그 특정 노드가 의도적이던 아니던 간에 오작동 하면 어쩌나? (즉, 비잔틴 노드이면 어쩌나?) 만약 모든 노드라고 치면, 모든 노드의 API 비밀번호를 믿어야 해? 그리고 API 가 수백번 호출되도록 내버려 둘래? 더 최악은 API 실행이 성공했는지 확인하는 과정이 외부 자원에 의존하는 아까 그 상황으로 되돌아 간다.

As before, a simple workaround is available. Instead of the smart contract calling an external API, we use a trusted service which monitors the blockchain’s state and performs certain actions in response. For example, a bank could proactively watch a blockchain and perform money transfers which mirror the on-chain transactions. This presents no risk to the blockchain’s consensus because the chain plays an entirely passive role.

아까와 마찬가지로 단순한 해법이 있다. 스마트 컨트랙트가 외부 API 를 호출하는 대신 블록체인의 상태를 모니터하다가 필요한 행위를 하는 믿을만한 서비스를 이용하는 것임. 예를 들어 은행이 능동적으로 블록체인을 보고 있다가 돈을 전송할 수 있다. 이렇게 하면 블록체인이 수동적인 역할을 하므로 컨센선스에 아무 위험을 초래하지 않음.

Looking at these two workarounds, we can make some observations.

이 두가지 잔머리를 보고 있자니 다음 몇가지를 관측할 수 있음.

First, they both require a trusted entity to manage the interactions between the blockchain and the outside world. While this is technically possible, it undermines the goal of a decentralized system.

둘째, 둘 다 블록체인과 외부 시스템 사이에 믿을 만한 누군가가 있어야 함. 이게 기술적으로 가능하긴 하지만, 탈중앙화는 훼손하는 것임.

Second, the mechanisms used in these workarounds are straightforward examples of reading and writing a database. An oracle which provides external information is simply writing that information into the chain. And a service which mirrors the blockchain’s state in the real world is doing nothing more than reading from that chain. In other words, any interaction between a blockchain and the outside world is restricted to regular database operations.

둘째, 둘 다 데이터베이스를 읽고 쓰는 간단한 것임. 외부 정보를 제공하는 오라클은 그저 정보를 체인에 쓰는 것임. 블록체인의 상태를 반영하는 서비스는 체인을 읽는 것 일 뿐임. 다시 말하면, 블록체인과 외부 시스템 간 상호작용이란 일반적인 데이터베이스 기능으로 제한됨.