이 글을 이해하기 위해서 컴퓨터 공학 지식이 필요하지 않습니다.
Oracle Problem
Oracle Problem 은 Blockchain 을 이용하여 서비스를 만든다면 반드시 겪게 되는 문제 중 하나입니다.
Blockchain 에 기록되어 있는 Transaction 을 비롯한 데이터는 Blockchain Network 에 의해 검증되는데, 이때 사용되는 근거는 이전에 발생한 Transaction 이 됩니다.
예)
- B는 A에게 $100 을 소비할 수 있도록 Transaction 을 만들었다.
- A는 B가 만들어준 Transaction 을 소비하여 C에게 $100을 소비할 수 있도록 Transaction 을 만들었다.
- A는 B가 만들어준 Transaction 이 없었다면, C에게 Transaction 을 만들어 줄 수 없습니다.
Node 는 Blockchain 내에 존재하는 과거의 데이터를 통해 현재를 검증하며, Blockchain 은 닫힌 계 (closed system) 라고 할 수 있습니다.
하지만 실제 서비스를 작성하기 위해서는, 외부의 데이터가 필요한 경우가 생깁니다.
예)
- A와 B는 특정 일에 비가 오면 보험금을 지급하는 Smart Contract 를 작성했습니다.
- 특정일에 비가 왔다는 조건은 Blockchain 내부에서 찾을 수 있는 데이터가 아닙니다. 따라서, Blockchain Network 는 이를 검증할 수 없습니다.
여기서 Oracle 이 등장합니다.
Oracle 은 사전적 의미로, 신탁 혹은 신탁을 주는 사제를 말하는데, 뜻 그대로 Oracle 은 Blockchain 에게 신탁을 주는 일을 합니다.
- Oracle 은 외부의 데이터 를 블록체인에 전달하거나 (OffChain -> OnChain), 블록체인의 데이터를 외부로 옮기는 역할 (OnChain -> OffChain) 을 합니다.
- Blockchain Network 는 Oracle 이 전달해 준 데이터를 검증 없이 그대로 신뢰합니다.
- 신은 자신의 말이 사실이라는 증거를 제시하지 않지만, 신을 믿을 수 있다면, 신의 말 역시 믿을 수 있을 것입니다.
Decentralized And Oracle
일반적으로, 서비스의 구성에 Oracle 이 포함되면 Decentralize 는 손상됩니다.
Decentralize 가 성립하기 위해서는 서로를 감시하고, 견제하며, 검증할 수 있어야 하는데, Oracle 은 검증 불가능한 상황을 만들기 때문입니다.
예)
- Oracle 은 비가 왔음에도 비가 오지 않았다고 거짓 말을 합니다.
- Smart Contract 는 Oracle 의 말을 신뢰하고, 비가 오지 않았다고 결정하여 보험금 지급을 하지 않습니다.
예)
- Lottery Smart Contract 에서 당첨 번호를 맞춘 사람에게 보상을 주기로 합니다.
- Lottery Smart Contract 에 당첨 번호를 Oracle 이 입력한다면, Oracle 이 임의로 당첨자를 선택하는 것과 같습니다.
최대한 Oracle 이 필요한 상황을 피하는게 좋지만, Oracle 없이 서비스를 만드는 건 사실 쉽지 않은 일입니다. 그렇다고 해서, Oracle 에게 어떠한 제약도 없다면, 신뢰 문제가 발생하기 때문에, 보완이 필요합니다.
정답은 정해져 있지 않지만, Blockchain Network 를 구성할 때와 마찬가지로 Vote 를 기반하는 경우가 많습니다. 여러 Oracle 을 선정하고, 이들에 의해 데이터를 결정하도록 하되, Oracle 이 결탁할 가능성을 배제할 수 없으므로 PoS와 같은 제약이 필요합니다.
결정 방식은 최다 득표 (혹은 최빈) 을 선택하거나, median 을 선택하는 것을 생각해 볼 수 있습니다.
단일 Admin 에게 모든 Oracle 권한을 주는 경우도 있고, PoS 를 기반으로 한 Governance 구성을 하는 경우도 발견할 수 있습니다.