이번 세미나에서는 ’11장. 오라클’을 다룹니다.

Oraclize나 TrueBit와 같은 구체적인 오라클에 대한 내용은 이 장의 설명 만으로 이해하기 어렵습니다. 해당 부분의 내용 이해가 어려우면 본문 내용을 읽었다 정도로 만족하고 넘어갑니다.

본문 내용을 한 번 읽고, 아래 정리한 내용을 다시 한 번 읽어 봅니다.

트랜잭션 데이터와 블록체인 내(on-chain)의 정보로만 스마트 컨트랙트를 실행할 수 있으면 좋겠지만, 날씨 데이터나 코인이나 토큰 가격 같이 블록체인 밖(off-chain)에서 추가적인 정보를 제공받아야 하는 경우가 있을 수 있습니다. 블록체인 밖에서 스마트 컨트랙트 실행에 필요한 정보를 제공하는 역할을 오라클이라고 합니다. 오라클은 온체인에서 실행하는 비용이 크거나 불가능한 계산을 하는데 사용할 수도 있습니다.

오라클의 문제는 정보 제공자를 신뢰해야 한다는 점입니다. 이것은 trust less(신뢰가 필요 없는 – 신뢰를 보증해 주는 주체 없이도, 누군가를 믿어야 한다는 신뢰를 전제하지 않고도)라는 블록체인의 기본 전제를 무너뜨리게 됩니다.

스마트 컨트랙트로 실세계 문제를 해결하려다 보면 외부 데이터가 필요한데, 외부 데이터를 가져오려다 보니 외부 데이터를 제공하는 제 3자를 신뢰해야 하는, 그렇게 되면 블록체인이 궁극적으로 해결하려고 했던 trust less가 무너지는 딜레마가 있는 것입니다.

오라클 문제는 블록체인이 해결해야 하는 중요한 문제 중 하나입니다. truss less라는 대 전제를 지킬수 밖에 없다면 결국 오라클 문제는 탈중앙화로 풀 수 밖에 없다는 것을 직관적으로 알 수 있을 것입니다. 체인링크는 탈중앙화 오라클 네트워크를 제안하는대표 주자입니다. 궁극적인 문제 해결에 도전하고 있는 체인링크, 관심 있게 쳐다볼 수 밖에 없겠지요.

아래 인용한 본문 내용은 여러 번 반복해서 읽어봅니다.

• Why Oracles Are Needed
  • A key component of the Ethereum platform is the Ethereum Virtual Machine, with its ability to execute programs and update the state of Ethereum, constrained by consensus rules, on any node in the decentralized network. In order to maintain consensus, EVM execution must be totally deterministic and based only on the shared context of the Ethereum state and signed transactions. This has two particularly important consequences: the first is that there can be no intrinsic source of randomness for the EVM and smart contracts to work with; the second is that extrinsic data can only be introduced as the data payload of a transaction.
  • Note that pseudorandom functions, such as cryptographically secure hash functions (which are deterministic and therefore can be, and indeed are, part of the EVM), are not enough for many applications. Take a gambling game that simulates coin flips to resolve bet payouts, which needs to randomize heads or tails—a miner can gain an advantage by playing the game and only including their transactions in blocks for which they will win.
  • So how do we get around this problem? Well, all nodes can agree on the contents of signed transactions, so extrinsic information, including sources of randomness, price information, weather forecasts, etc., can be introduced as the data part of transactions sent to the network. However, such data simply cannot be trusted, because it comes from unverifiable sources. As such, we have just deferred the problem. We use oracles to attempt to solve these problems.
  • Oracles, ideally, provide a trustless (or at least near-trustless) way of getting extrinsic (i.e., “real-world” or off-chain) information, such as the results of football games, the price of gold, or truly random numbers, onto the Ethereum platform for smart contracts to use. They can also be used to relay data securely to DApp frontends directly. Oracles can therefore be thought of as a mechanism for bridging the gap between the off-chain world and smart contracts. Allowing smart contracts to enforce contractual relationships based on real-world events and data broadens their scope dramatically.

이더리움 EVM은 sandbox로 실행되고 온체인 데이터만 사용할 수 있기 때문에 오프체인 데이터를 온체인에서 사용하려면 먼저 온체인 데이터로 저장되어야 합니다. 따라서 오라클은 오프체인에서 수집된 데이터를 서명된 메시지로 온체인에 전송하고 스마트 컨트랙트의 스토리지에 저장하고, 다른 컨트랙트에서 오라클 컨트랙트의 스토리지에 접근할 수 있도록 해야 합니다.

오라클을 구축하는 방법으로는 요청-응답(request–response), 게시-구독(publish-subscribe), 즉시 읽기(immediate-read)가 있습니다. 아래 인용한 본문 내용을 다시 한 번 주의를 기울여 읽어 봅니다.

• Immediate-read
  • It provide data that is only needed for an immediate decision, like “Is this person over 18?” Those wishing to query this kind of data tend to do so on a “just-in-time” basis; the lookup is done when the information is needed and possibly never again.
  • The data stored by the oracle is likely not to be the raw data that the oracle is serving, e.g., for efficiency or privacy reasons. A university might set up an oracle for the certificates of academic achievement of past students. However, storing the full details of the certificates (which could run to pages of courses taken and grades achieved) would be excessive. Instead, a hash of the certificate is sufficient. Likewise, a government might wish to put citizen IDs onto the Ethereum platform, where clearly the details included need to be kept private. Again, hashing the data (more carefully, in Merkle trees with salts) and only storing the root hash in the smart contract’s storage would be an efficient way to organize such a service.
• publish–subscribe
  • It effectively provides a broadcast service for data that is expected to change (perhaps both regularly and frequently) is either polled by a smart contract on-chain, or watched by an off-chain daemon for updates.
  • Polling is very inefficient in the world of web servers, but not so in the peer-to-peer context of blockchain platforms: Ethereum clients have to keep up with all state changes, including changes to contract storage, so polling for data changes is a local call to a synced client. Ethereum event logs make it particularly easy for applications to look out for oracle updates, and so this pattern can in some ways even be considered a “push” service. However, if the polling is done from a smart contract, which might be necessary for some decentralized applications (e.g., where activation incentives are not possible), then significant gas expenditure may be incurred.
  • In a broadcast or multicast pattern, an oracle would post all messages to a channel and subscribing contracts would listen to the channel under a variety of subscription modes. For example, an oracle might publish messages to a cryptocurrency exchange rate channel. A subscribing smart contract could request the full content of the channel if it required the time series for, e.g., a moving average calculation; another might require only the latest rate for a spot price calculation. A broadcast pattern is appropriate where the oracle does not need to know the identity of the subscribing contract.
• request–response
  • It is the most complicated: this is where the data space is too huge to be stored in a smart contract and users are expected to only need a small part of the overall dataset at a time.
  • It is also an applicable model for data provider businesses. In practical terms, such an oracle might be implemented as a system of on-chain smart contracts and off-chain infrastructure used to monitor requests and retrieve and return data.
  • A request for data from a decentralized application would typically be an asynchronous process involving a number of steps. In this pattern, firstly, an EOA transacts with a decentralized application, resulting in an interaction with a function defined in the oracle smart contract. This function initiates the request to the oracle, with the associated arguments detailing the data requested in addition to supplementary information that might include callback functions and scheduling parameters. Once this transaction has been validated, the oracle request can be observed as an EVM event emitted by the oracle contract, or as a state change; the arguments can be retrieved and used to perform the actual query of the off-chain data source. The oracle may also require payment for processing the request, gas payment for the callback, and permissions to access the requested data. Finally, the resulting data is signed by the oracle owner, attesting to the validity of the data at a given time, and delivered in a transaction to the decentralized application that made the request—either directly or via the oracle contract. Depending on the scheduling parameters, the oracle may broadcast further transactions updating the data at regular intervals (e.g., end-of-day pricing information).

데이터 소스가 신뢰할 만하고 오라클과 요청-응답 메커니즘이 별개의 주체에 의해 운용된다고 가정했을 때 반환된 데이터의 무결성을 입증할 수 있는 오프체인 방식의 검증 방법이 중요해집니다. 전송 중에 데이터가 변조될 가능성이 있기 때문입니다.

데이터 인증에 대한 두 가지 공통적인 접근 방법은 진위성 증명(authenticity proof)과 신뢰할 수 있는 실행 환경(trusted execution environment)입니다. 진위성 증명은 데이터가 변조되지 않았음을 암호학적으로 보증하는 것입니다.

Oraclize는 감사 가능한 서비스를 신뢰할 수 있도록 함으로 중앙화된 오라클을 사용할 수 있도록 합니다.

좀 더 탈중앙화된 솔루션을 위해 트루비트를 사용할 수 있습니다. 트루비트는 확장성과 검증가능한 오프체인 계산을 위한 솔루션을 제공합니다.

체인링크는 탈중앙화 오라클입니다.

아래 인용한 본문 내용을 여러 번 다시 읽어 봅니다.

Generally, when considering the use of an oracle be very careful about the trust model. If you assume the oracle can be trusted, you may be undermining the security of your smart contract by exposing it to potentially false inputs. That said, oracles can be very useful if the security assumptions are carefully considered.