오라클 문제는 왜 어려울까?

Published in

IOTRUST : Team Blog

14 min readJul 8, 2020

본 글에서는 오라클 문제가 왜 풀기 어려운지 다루고자 합니다.

오라클이란 신탁 혹은 예언자라는 의미를 가지며 외부 세계의 전달자를 뜻하는 용어로, 블록체인에서는 외부(Off-chain)에서 발생한 사건이나 결과를 내부(On-chain)로 유입하는데 필요한 시스템을 의미합니다. 오라클 문제는 블록체인 외부의 일을 내부로 가져올 때, 블록체인내에서 검증되어야하는 신뢰 문제를 다루기 때문에 어렵습니다.

출처 : Wikipedia, 오라클(신탁)은 외부 세계의 전달자를 의미하는 용어입니다.

비트코인은 채굴(Mining)로 인한 화폐 발행과 인센티브 체계를 도입함으로써 다수의 참여자에게 동기를 부여하여 TTP(Trusted Third Party)없이 이중 지불 문제를 해결하고 신뢰할 수 있는 탈중앙화 화폐를 만듭니다. 블록체인이 해결하는 문제는 이중 지불 문제가 발생하지 않도록 관리해주는 신뢰 기관의 역할을 대신하는 것입니다. 여기서 이중 지불 문제를 일으키는 자산인 암호 화폐의 잔액 상태는 블록체인 상에 기록되어 관리되기 때문에, 이중 지불이 발생하였을 때 검증이 가능합니다.

반면, 오라클 문제는 블록체인과 상관없는 외부 세계에서 발생하는 신뢰에 관한 문제입니다. 블록체인이 이중 지불 문제를 확인하기 위해 필요했던 TTP를 탈중앙화 시키는데 기여했다면, 오라클 문제는 또 다른 외부 세계의 신뢰 문제를 해결해야 하는 것이기 때문에 마치 블록체인이 나오기 이전으로 돌아 간 것 같은 느낌을 줍니다. 약 1년전 비탈릭 부테린의 오라클 문제 관련 기사가 나온 것도 이러한 어려움이 반영된 것으로 보입니다.

오라클 접근 방식 : Voting vs Protocol

몇 가지 유명한 오라클관련 프로젝트로는

2014년부터 이더리움에서 서비스를 시작한 예측시장 Augur
2019년에 암호 화폐 시가 총액이 급상승한 Chainlink
블록체인 업계의 위키피디아를 목표로 하는 Band Protocol
MakerDAO와 같은 스테이블 코인의 가격 피드 오라클

등이 있습니다.

De-fi(Decentralized Finance)는 현재 암호 화폐 생태계에서 실제 사용자를 확보하고 운영이 가능한 어플리케이션 중 가장 강력한 유즈케이스로, 스테이블 코인 운영을 위한 법정 화폐 담보에서 현재의 환율 혹은 시장 가격 등이 필요하게 되고 이 때 오라클이 필요합니다.

현재는 어느 정도 하나의 솔루션으로 좁혀지는 듯한 방법이, 외부 압력을 받지 않을 만큼 강력한 21개의 오라클 노드를 두고 이들 간의 투표를 통해 데이터를 결정하는 방식입니다. 단순히 “현재 비트코인의 달러 가격”이 필요한 경우에는 위 방법으로도 충분할 수 있지만, 다양한 데이터의 활용될 경우 매번 투표를 시행하는 것이 효율적인가는 생각해볼 문제입니다.

21개의 오라클 노드를 이용한 Chainlink의 BTC 가격 결정. 출처 : https://feeds.chain.link/btc-usd

다음 표는 TU berlin에서 발표한 논문[1]에서 분류한 오라클 문제 해결에 대한 접근 방식입니다. 웹에 존재하는 데이터를 가져오기 위한 방법으로 HTTPS 프로토콜을 지원하는 TLS(Transport Layer Security)기반의 방식과 탈중앙화에 우선 순위를 두고 설계해 나가는 투표 기반의 방식으로 분류한 것을 볼 수 있습니다. Town Crier도 결국 TLS 프로토콜을 활용하기 위한 하나의 방법이기 때문에 크게 두 가지 접근 방법으로 분류해도 무방합니다. 본 글에서는 TLS 기반의 오라클을 중점적으로 문제의 어려움을 설명하겠습니다.

Comparison of Oracle Approaches, paper “From Oracles to Trustworthy Data On-chaining Systems”

먼저, 투표를 기반으로 하는 오라클의 핵심은 누구나 참여할 수 있고, 특별한 하드웨어(e.g. Intel SGX)를 요구하지 않으며, 활동에 대한 보상 체계와 이의제기 절차를 적절히 구현하는 것입니다. 장점은 당연히 탈중앙화 철학을 고수할 수 있다는 것이고, 단점으로는 투표 과정에서 드는 On-chain TX 비용이나 시간이 오래걸리는 점을 꼽을 수 있습니다.

TLS 기반의 오라클은 이미 외부에 존재하는 데이터를 블록체인으로 가져올 때 기존 인프라인 TLS와 PKI(Public Key Infrastructure)를 이용하여 외부 데이터 소스에서 블록체인까지의 인증(Authenticity) 문제를 해결하는 것에 초점을 두고 있습니다. TLS는 서버-클라이언트 통신에서 서버측이 CA(Certificate Authority)로 부터 발급받은 인증서를 가지고 있는지를 확인한 후 웹 사이트에 접근하는 형태로 HTTPS 프로토콜을 지원합니다. 각 프로토콜 별로 간략히 요약하면 다음과 같습니다.

TLS-Notary[2] : 오라클이 제시하는 값에 대해 제3자 검증을 제공, Oraclize(현재 Provable)가 과거 서비스에서 TLS-Notary를 활용
TLS-N[3] : 오라클과 웹사이트간의 모든 통신 과정을 블록체인에서 검증 가능한 형태로 증명하는 프로토콜
Town Crier[4] : 오라클 노드의 전달 과정에서 인증 프로토콜을 TEE (Trusted Execution Environment) 기반으로 구성, Chainlink가 인수

TLS 기반 오라클의 장점은 현재 존재하는 인프라를 활용하여 방대한 양의 데이터를 전달할 수 있다는 것이고, 단점은 가정된 부분이 많아 바로 적용하기 어렵다는 것입니다. 예컨대 CoinMarketCap에서 제공한 데이터 자체를 신뢰할 수 있다고 가정하고, 이 데이터를 블록체인으로 가져오는 과정에 위변조가 없었음을 증명하는 방식으로 프로토콜이 구현됩니다.

따라서, 당장 운영 가능한 서비스를 위한 기업들은 운영 비용이 비효율적이더라도 전자를 선택할 것이고, 장기적인 흐름으로 기술의 발전을 도모하는 학계에서는 후자의 연구가 계속될 것입니다. Chainlink가 이 분야에서 인지도가 높은 것은 후자의 기술(Town Crier)을 충분히 이해하고, 현재 서비스를 위해 전자(투표 기반으로 21개 노드 운영)를 택한 전략이 주요한 것이라고 생각이 됩니다.

오라클 문제의 세부사항

먼저 오라클을 단일 노드 시스템으로 구성할 것인지 다수 노드로 구성할 것인지 부터 결정해야 합니다. 단일 지점 장애 문제와 탈중앙화 관점에서 봤을 때, 다수의 노드로 설계하는 것이 바람직해 보입니다. 따라서 다수의 오라클 노드를 운영하는 경우를 생각해보겠습니다.

다음으로는 데이터 소스를 믿을 수 있는가에 대한 것입니다. 예컨대 최근 Binance가 CoinMarketCap 인수 후 거래소 순위 산정 방식에 따라 기존과 변동 된 것을 볼 수 있는데요. “현재 BTC의 가격이 얼마인가?” 라는 질문에는 변동이 없을지라도 “현재 1위 거래소는 어느곳인가?” 라는 질문은 순위 산정 방식에 따라 달라질 수 있습니다. 따라서 외부 데이터 소스를 하나에서 가져오는 것은 해당 업체를 신뢰할 수 있느냐의 문제로 귀결되고, 이를 회피하기 위해서 다수의 데이터 소스를 이용하는 것이 필요합니다.

다수의 오라클 노드와 다수의 데이터 소스를 운영하게 될 경우, 다음과 같은 문제를 고려해봐야 합니다.

Freeloading problem and Privacy

다수의 오라클이 존재할 경우, 각 오라클은 스마트 컨트랙트에 기재된 URL로 요청을 보내고, 응답받은 값을 집계(Aggergation)하는 과정을 수행합니다. 여기서 실제 일을 하지 않고 집계에 참여하는 동의 혹은 비동의 하는 사례가 있을 수 있습니다. 이에 해당하는 문제를 freeloading 문제라고 합니다.

웹사이트의 접근 비용이 싸든 비싸든, 오라클은 외부 사이트에 존재하는 곳에 요청을 하여 응답을 받고 자신의 입장을 표명해야 하는데, 이 일을 실제로 수행 하고서 동의를 했는지 알 수 없기 때문입니다. 단순히 평판 관리만을 위해서 다른 오라클 노드가 비트코인 가격이 1000만원이라고 하니 조회하지 않고 그냥 1000만원이라 하고 끝내 버릴 수 있고, 이렇게 되면 오라클 시스템이 정상적으로 기능하지 못할 수 있습니다.

freeloading을 막기 위해서는 다수의 노드가 답을 먼저 정하고 후에 공개하는 방식의 commit-reveal 구조를 적용할 수 있겠지만 두 번의 on-chain TX은 비용을 더욱 비싸게 만들 수 있습니다. 물론 reveal 단계를 꼭 on-chain으로 구현해야 하는 것은 아니지만, 스마트 컨트랙트를 동작 시키기 위해 명확한 값의 전달이 요구되기도 합니다.

혹은 블록체인 상에 공개되는 데이터가 환율 정보같은 공개 정보가 아니라 특정 누군가의 자산이라던가, 보험을 위한 스마트 컨트랙트에 제출되는 병력 등의 정보일 경우 프라이버시 문제가 발생할 수 있습니다. 실제 세계에서 계약서 상의 대부분의 정보는 개인의 민감한 정보를 담고 있기에, 스마트 컨트랙트가 실생활에 가까이 이용되기 위해서는 이 부분도 해결되어야 할 필요가 있습니다. 블록체인에 프라이버시 보호를 위한 zk-SNARK(zero knowledge Succinct Non-interactive ARgument of Knowledge)은 오라클에서도 추 후 필수적인 기술이 될 것입니다.

Data Source Modification and Adoption

TLS를 활용하는 주된 이유는 글로벌 CA에 의해 확인된 사이트임을 증명하는 PKI 인프라를 갖추고 있기 때문입니다. CA에 의해 인증서를 발급 받은 사이트의 경우 HTTPS 연결 표시로 자물쇠가 주소 창에 나타납니다. 2018년 개정된 TLS 1.3부터는 상호 인증에 사용되던 대칭키 기반의 MAC(Message Authentication Code)이 아닌 공개키 암호를 지원하는 대대적인 변화가 있었습니다. 하지만, TLS 공개키 암호는 HTTPS를 위한 ECDH 같은 키 교환에 사용될 뿐 어플리케이션 계층의 전자 서명을 지원하지는 않습니다. 전자 서명의 기능인 인증과 무결성은 MAC으로 대체가능하지만, 부인 방지 기능은 전자 서명으로만 가능합니다. 즉, TLS 1.3 인프라 만으로는 서버가 제시한 데이터를 클라이언트가 제3자(스마트 컨트랙트 혹은 외부 검증자)에게 증명할 수 있는 부인방지 기능이 없음을 의미합니다.

TLS-N Overview, paper “TLS-N : Non-repudiation over TLS Enabling Ubiquitous Content Signing”

이러한 문제점을 TLS-N에서는 프로토콜을 수정하여 데이터 소스 서버로부터 데이터 제공 시 전자 서명을 함께 받아 블록체인에 제출하여 검증하는 방법을 제시하였습니다. 하지만 이런 방식은 데이터 소스 서버의 수정을 요구하는 것으로 새로운 TLS-N 프로토콜로 변경해야 함을 의미합니다. 현재 TLS 1.3 인프라가 표준인 가운데, 데이터 소스 입장에서는 업무상 협약을 통해 높은 비용을 요구할 수도 있고, 오라클 시스템을 운영하는데 있어 오라클 자체보다 데이터 소스 서버 운영에 더 큰 비용 할당으로 이어질 수 있습니다. 또는 서버가 이를 채택 할 경우, 의도적으로 데이터를 감추거나 조작하는 등의 검열저항성에 위배되는 행동을 할 염려도 있기 때문에 서버는 블록체인의 프로토콜과 상관없이 활동할 수 있어야 합니다.

Hardware Vulnerability

Town Crier는 오라클 노드의 무결성을 검증하기 위해 TEE를 사용하는 프로토콜입니다. 웹 서버의 수정을 요구하지 않으면서, TEE내에 TLS 프로토콜을 구현하여 데이터 소스로부터 가져온 데이터를 블록체인에 전달하기까지 조작되지 않았음을 입증할 수 있습니다. TEE를 구현한 Intel SGX는 프로토콜을 enclave로 수행함으로써, 악성코드의 위협이나 노드 자체의 악성 행위도 예방하는 역할을 합니다. Town Crier 자체는 단일 서버에 해당하는 프로토콜이지만, Chainlnk는 Town Crier 인수 후 분산 프로토콜로 변형하기 위한 시도를 하고 있습니다.

출처 : https://software.intel.com, Intel SGX Application

하지만, TEE가 절대적으로 안전성을 보장하는 것은 아닙니다. 암호의 안전성은 수학적 안전성(소인수 분해, 이산 대수 문제 등)에 기반하는데 반해, TEE는 하드웨어 기술에 기반하여 안전성을 보장하는 것입니다. 암호 화폐 분야같이 해킹이 곧 큰 금액의 손실로 이어지는 상황에서 TEE의 안전성을 담보로 큰 돈을 움직이는 시스템을 보장하기에는 조금 이르다고 보여집니다.

TEE의 공격을 위한 취약점과 방어 기법은 지금도 계속해서 보안 학술대회에서 발표되면서 발전하고 있지만, Meltdown, Spectre[5]와 같은 취약점 발생 시 Intel 측의 대응이나 , TEE가 하드웨어 제조사에 의존되는 기술이라는 점도 신뢰성에 의문을 갖게 되는 주요 원인입니다.

오라클 문제 해결을 바라보는 관점

오라클 문제에 대한 해결책을 결정하기에는 아직 시기상조라고 보여집니다. 보다 많은 연구와 활용 사례가 더 구체적으로 검증되어야 합니다. 확실한 것은 블록체인이 탈중앙화를 유지하면서 암호 화폐 이외의 실용화를 이루기 위해서 오라클 문제는 반드시 극복해야할 문제입니다.

개인적으로 앞으로 두 가지 항목을 주의깊게 살펴 보고자 합니다.

첫번째는 DApp 중심의 노드 운영입니다. 블록체인에서 발생하는 문제들은 결국 기존의 인터넷에서 겪었던 문제에 탈중앙화라는 요소가 더해진 것이기 때문에, 이에 대한 대안으로 다수의 협력 업체로 구성된 노드를 운영함으로써 많은 부분을 해결 할 수 있으리라 봅니다.

두번째는 TEE, ZKP, MPC와 같은 off-chain computing 기술 개발의 진보입니다. 수학적으로나 하드웨어적으로 프로그램 연산의 실행 결과의 무결성을 증명하는 것은 최근 몇 년간 속도 면에서 큰 성장을 이루었습니다. 클라우드 환경에 이어 블록체인 환경에서 증명자와 검증자의 관계에서 필요한 암호 프로토콜의 설계가 점점 활발해지고 있습니다.

무엇보다도, 암호의 세부사항을 알지 못해도 구현 할 수 있도록 개발자를 지원하는 ‘프로그래밍 언어 전문가들의 블록체인 및 암호 기술로의 유입’도 눈여겨 볼 만한 이슈입니다. 영지식 증명의 경우, libsnark을 high-level language로 변환 하는 도구들이 개발되어왔고, 지난 해에 발표된 zkay[6]는 단순한 변수 타입만으로 이를 지원하여 간단하게 구현할 수 있도록 하는 연구도 있었습니다. 이것은 어떤 개발자라도 영지식 증명과 같은 암호 알고리즘을 쉽게 쓸 수 있음을 의미합니다.

두 가지 관점을 통해 오라클은 점차 탈중앙화 되고, 외부 세계의 신뢰 문제를 해결해 나갈 것으로 보입니다.

마치며

본 글에서는 오라클 문제를 해결하기 위한 접근 방식과 해결하기 어려운 기술적 이유에 대해서 설명하였습니다. 블록체인 붐이 일어난 2016년 부터 약 5년이 지난 지금, 당시 가장 큰 문제였던 확장성 문제는 여러가지 방법으로 해결이 되는 것처럼 보입니다. 오라클 문제가 본격적으로 수면위로 등장하게 된 것이 2019년이라고 보았을 때 아직 조금 더 시간이 걸려야 제대로 된 방법이 나오지 않을까 예상해 봅니다.

아이오트러스트도 오라클 기술과 관련하여 꾸준히 연구와 개발을 통해 국내에서 오라클 사업을 위한 발판을 마련하고자 합니다. 관련하여 궁금하신 점은 본 글의 댓글이나 아래 링크로 문의주시기 바랍니다.