위키원
오라클 (블록체인)
오라클(oracle)은 블록체인 외부의 데이터를 블록체인 안으로 들여오고, 블록체인의 데이터를 외부로 내보내는 것을 말한다. 오라클은 고립된 블록체인 생태계를 외부와 연결 시켜주는 하나의 다리(bridge) 역할을 한다.
개요
오라클은 그리스 신화에서 신의 계시를 전달하고 미래의 모습을 보는 사람이라는 뜻에서 유래되었다. 블록체인에서 오라클은 외부에서 일어나는 문제들에 대한 정보를 알려주는 시스템이다. 이상적으로 오라클은 신뢰가 필요 없는(trustless) 시스템인데, 그 이유는 탈중앙화 원칙을 바탕으로 작동하기 때문이다. 가상 머신은 탈중앙화된 네트워크상의 모든 노드에서 합의의 규칙에 따라 프로그램을 실행하고 상태를 업데이트할 수 있다. 합의를 유지하기 위해서 가상 머신 실행은 완전히 결정론적이고, 상태와 서명된 트랜잭션의 공유 컨텍스트에 기반을 두고 있어야 한다. 이것은 두 가지 중요한 결과를 낳는다. 첫 번째는 가상 머신 및 스마트 계약과 같이 동작하는 임의성을 위한 고유한 소스가 없다는 뜻이고, 두 번째는 외부 데이터가 트랜잭션의 데이터 페이로드(payload)로서만 유입될 수 있다는 것이다.
가상 머신에서 스마트 계약에 임의성을 제공하기 위해 난수 함수(a true random function)의 사용을 금지하는 것을 이해하려면, 난수 함수를 실행한 후에 어떻게 합의를 달성하기 어려워지는지를 살펴봐야 한다. 노드 A는 특정 스마트 계약의 명령어를 실행하고 스토리지에 3을 저장하는 반면, 노드 B는 동일한 스마트 계약을 실행하고도 7을 저장한다고 가정해보자. 노드 A와 B가 동일한 컨텍스트에서 정확하게 동일한 코드를 실행했음에도 결과 상태가 다르게 나온다. 그야말로 스마트 계약이 실행될 때마다 다른 결과 상태가 나올 수 있다. 따라서 전 세계의 여러 노드가 독립적으로 실행되는 네트워크에서 결과 상태가 무엇인지에 관한 탈중앙화된 합의는 불가능하게 될 것이다. 실제로는 훨씬 상황이 안 좋아질 수 있는데, 그 이유는 연쇄효과가 기하급수적으로 쌓일 것이기 때문이다.
암호화된 보안 해시 함수와 같은 의사 난수 함수들은 다양한 애플리케이션에서 사용하기에는 충분하지 못하다. 동전의 앞이나 뒤를 무작위로 추출해서 내기에 따른 금액을 지급하는 동전 뒤집기 도박 게임을 생각해보자. 이 게임에 참여하는 채굴자는 자신이 이기는 값을 가진 트랜잭션만을 블록에 포함할 수 있기 때문에 유리한 입장에 설 수 있다. 이런 문제를 해결하기 위해서 모든 노드가 서명된 트랜잭션의 내용에는 동의할 수 있으므로 임의성의 소스, 가격 정보, 일기 예보 등 외부 정보를 네트워크로 전송하는 트랜잭션 데이터의 일부로 포함시키면 해결될 수 있을지도 모른다. 그러나 이런 데이터는 확인할 수 없는 출처에서 비롯되어 전혀 신뢰할 수 없다. 이것은 문제를 해결하는 것이 아니라 다른 곳으로 전가시킨 것에 지나지 않는다. 이 문제를 해결하기 위해 오라클을 사용하는 것이다.
특징
디앱이 질의하는 데이터 소스가 권위있고 신뢰할 만하다고 가정하면, 중요한 질문이 하나 남는다. 오라클과 요청응답 메커니즘이 별개의 주체에 의해 운영될 수 있다고 가정하면, 어떻게 이 메커니즘을 신뢰할 수 있는가이다. 전송 중에 데이터가 변조될 가능성이 명백히 있기 때문에 반환된 데이터의 무결성을 입증할 수 있는 오프체인 방식의 검증 방법이 매우 중요하다. 데이터 인증에 대한 두 가지 공통적인 접근 방법은 진위성 증명(authenticity proof)과 신뢰할 수 있는 실행 환경(trusted execution environment,TEE)이다. 진위성 증명은 데이터가 변조되지 않았음을 암호학적으로 보증하는 것이다. 이것은 다양한 입증 기법들, 예를 들어 디지털 사인된 증명을 사용함으로써 데이터 운반자에 대한 신뢰 문제를 데이터 입증자의 문제로 전환시킨다. 스마트 계약은 체인상의 진위성 증명을 검증함으로써 데이터를 처리하기 전에 데이터의 무결성을 검증할 수 있다. 오라클라이즈(Oraclize)는 다양한 진위성 증명을 활용하는 오라클 서비스의 예다. 현재 이더리움 메인 네트워크의 데이터 질의에 사용할 수 있는 그런 증거 중 하나가 TLSNotary 증명이다. TLS 일반 증명을 사용하면 클라이언트는 클라이언트와 서버 간에 HTTPS 웹 트래픽이 발생했다는 증거를 제3자에게 제공할 수 있다. HTTPS 자체는 안전하지만 데이터 서명은 지원하지 않는다. 결과적으로 TLSNotary 증명은 전송 계층 보안(transport layer security, TLS) 프로토콜을 활용하여 접근 후 데이터에 서명하는 TLS 마스터 키를 서버, 감사대상자, 감사인의 세 당사자 간에 분할할 수 있다. 오라클라이즈는 아마존 웹 서비스(Amazon Web Services, AWS) 가상 시스템 인스턴스를 감사자로 사용하며, 인스턴스화 이후에 수정되지 않았음이 검증될 수 있다. 이 AWS 인스턴스는 TLSNotary 암호를 저장하여 진위성 증명을 제공한다. 순수한 요청응답 메커니즘보다 데이터 변조에 대한 높은 확신을 제공하지만, 이 접근 방식은 아마존 자체가 VM 인스턴스를 변경하지 않는다는 가정을 필요로 한다.
타운 크리에(Town Crier)는 TEE 접근 방식에 기반한 인증된 데이터피드 오라클 시스템이다. 이런 방법은 데이터의 무결성을 보장하기 위해 하드웨어 기반의 고립된 보안 영역을 사용한다. 타운 크리에는 인텔의 SGX(Software Guard eXtensions)라고 불리는 소프트웨어 보안 확장판을 사용하여 HTTPS 질의에 대한 응답을 인증된 것으로 확인할 수 있다. SGX는 한 영역 내에서 실행되는 애플리케이션이 다른 프로세스에 의해 변조되지 않게 CPU에 의해 보호받도록 하여 무결성을 보장한다. 또한 기밀성을 제공하여 한 영역 내에서 실행될 때 애플리케이션의 상태가 다른 프로세스에 보이지 않도록 한다. 마지막으로, SGX는 해당 빌드의 해시로 확실하게 식별된 애플리케이션이 실제로 보안 영역 내에서 실행된다느 ㄴ디지털 서명 증명을 생성하여 인증이 가능하도록 한다. 이 디지털 서명을 확인함으로써 탈중앙화된 애플리케이션이 타운 크리에 인스턴스가 SGX 영역 내에 안전하게 실행되고 있음을 증명할 수 있다. 이것은 결국 인스턴스가 변경되지 않았으며, 타운 크리에에서 나온 데이터가 신뢰할 수 있음을 증명한다. 기밀성 속성은 타운 크리에 인스턴스의 공개키를 사용하여 데이터 쿼리를 아호화함으로써 타운 크리에는 파리이빗 데이터를 처리할 수 있다. SGX와 같은 보안 영역 안에서 오라클의 질의 및 응답을 수행하기 때문에 오라클이 신뢰할 수 있는 제3자 하드웨어상에 안전하게 실행되고 있으며, 요청된 데이터가 변조되지 않고 반환되었다는 것을 보장받을 수 있다.
기능
모든 오라클은 정의에 따라 몇 가지 핵심 기능을 제공한다. 데이터가 스마트 계약의 스토리지에서 사용할 수 있게 되면 오라클 스마트 계약의 retrieve 함수를 작동시키는 메시지 호출을 통해 다른 스마트 계약이 접근할 수 있다. 또한 이더리움 노드나 네트워크 사용 가능 클라이언트가 오라클 저장소를 조사하여 직접 접근할 수도 있다. 오라클을 설정하는 세 가지 주요 방법은 즉시읽기, 게시구독, 요청응답으로 분류할 수 있다.
즉시읽기
즉시읽기(immediate-read) 오라클은 즉각적인 결정이 필요한 데이터만을 제공한다. 이런 종류의 데이터 질의는 정보가 필요할 때 적시에 조회하고 나면 아마도 다시는 수행하지 않는 경향이 있다. 이런 오라클의 예로는 학술 인증서, 전화번호, 기관 회원권, 공학 식별자, 자치ID 등과 같이 조직에 대한 데이터 또는 조직에 의해 발행된 데이터를 보유하는 것들이 있다. 이런 종류의 오라클은 계약 저장소에 데이터를 저장하고, 다른 스마트 계약은 오라클 계약에 요청을 해서 이러한 데이터를 검색할 수 있다. 그리고 이 데이터는 업데이트될 수도 있다. 오라클 스토리지에 있는 데이터는 블록체인 기반, 즉 이더리움 클라이언트에 연결된 애플리케이션에 의해 직접 조회될 수 있기 때문에 번거로운 절차를 거치거나 트랜잭션을 처리하는 가스 비용도 필요하지 않다. 술을 사려는 고객의 나이를 확인하고 싶은 가게는 이런 식으로 오라클을 사용할 수 있다.
이런 유형의 오라클은 이와 같은 데이터 요청에 응답하기 위해 서버를 운영하고 유지관리해야 하는 조직이나 회사에 매력적이다. 오라클에 의해 저장된 데이ㅓ는 효유성이나 프라이버시 때문에 오라클이 제공하는 원시 데이터가 아닐 가능성이 높다. 대학은 과거 학생들의 학업성적 증명서용 오라클을 만들 수 있다. 그러나 증명서의 전체 세부사항을 저장하는 것은 지나친 것이 될 수도 있다. 대신, 증명서의 해시를 저장하는 것만으로 충분하다. 마찬가지로, 예를들어 정부는 이더리우 플랫폼에 시민 ID를 넣고 싶을 수도 있다. 여기에 포함된 세부 정보는 분명 비공개로 유지해야 한다. 데이터를 해싱하고 스마트 계약의 저장소에 단지 루트 해시를 저장하는 것으로도 그러한 서비스를 효율적으로 구성할 수 있다.
게시구독
게시구독(publish-subscribe)형의 오라클은 정기적 혹은 잦은 변화가 예상되는 데이터를 효과적으로 브로드캐스트하는 역할을 하며, 이 데이터는 온체인 스마트 계약에 의해 폴링(polling)되거나 업데이트를 위한 오프체인 데몬에 의해 모니터링된다. 이 카테고리는 RSS 피드, WebSub 등과 유사한 패턴을 지닌다. 오라클은 새로운 정보로 업데이트되고, 플래그는 새로운 데이터를 쓸 수 있음을 구독 대상들에게 알린다. 데이터를 받는 쪽에서는 최신 정보가 변경되었는지 여부를 확인하기 위해 오라클을 폴링하거나 오라클 계약에 대한 업데이트 소식을 기다리다가 업데이트가 발생하면 필요한 조치를 수행한다.
예를 들어 가격 정보, 기상 정보, 경제 또는 사회 통계, 교통 정보 등이 있다. 폴링은 웹 서버 세계에서는 매우 비효율적이지만, 블록체인 플랫폼의 피투피 컨텍스트에서는 그렇지 않다. 예를 들어 이더리움 클라이언트는 컨트랙트 저장소 변경을 포함하여 모든 상태 변경사항을 알아야 하므로 데이터 변경사항에 대한 폴링은 동기화된 클라이언트에 대한 로컬 호출이다. 이더리움 이벤트 로그를 사용하면 애플리케이션에서 오라클 어데이트를 매우 쉽게 볼 수 있으므로 이 패턴은 어떤 면에서 푸시(push) 서비스로 간주할 수 있다. 그러나 폴링이 스마트 계약으로부터 수행되어야 하는 경우는 상당한 가스 비용이 발생할 수 있는데, 일부 탈중앙화된 애플리케이션에서 이러한 폴링이 필요할 수도 있다.
요청응답
요청응답(request-response) 카테고리는 가장 복잡하다. 이 유형으 스마트 계약에 저장하기에는 데이터 공간이 너무 크고, 사용자는 전체 데이터 중 한 번에 일부만 필요로 하는 경우에 사용된다. 또한 이것은 데이터 공급자 사업 영역에 적용 가능한 모델이기도 하다. 실용적인 측면에서 보자면, 오라클은 요청을 모니터링하고 데이터를 검색하고 반환하는 데 사용되는 온체인 스마트 계약과 오프체인 인프라 시스템으로 구현될 수 있다. 탈중앙화된 애플리케이션의 데이터 요청은 일반적으로 여러 단계에 걸친 비동기 프로세스다. 이 패턴에서는 우선 EOA가 탈중앙화된 애플리케이션과 연결해서 오라클 스마트 계약에 정의된 함수와 상호작용한다. 이 함수는 오라클에 요청을 보내는데, 이때 요청하는 데이터의 세부 사항을 지정하는 인수와 더불어 콜백 함수ㅡ, 스케줄링 파라미터 등의 추가적인 정보도 포함할 수 있다. 이 트랜잭션이 검증되면 오라클 요청은 오라클 계약에 의해 발생한 가상 머신 이벤트 또는 상태 변화를 통해서 확인할 수 있으며, 이것의 인수들을 받아서 오프체인 데이터 소스에 대한 검색을 실제 수행하는데 사용할 수 있다. 또한 오라클은 요청 처리, 콜백에 대한 가스 지급, 요청 데이터에 대한 접근 권한을 요구할 수 있다. 마지막으로, 결과 데이터는 오라클 소유자의 서명을 받아 주어진 시간상의 데이터의 유효성을 입증하고 직접 또는 오라클 계약을 통해 요청한 탈중앙화 애플리케이션에 트랜잭션으로 전달된다. 스케줄링 파라미터에 따라 오라클은 데이터를 일정한 간격으로 업데이트하는 추가 트랜잭션을 브로드캐스트 할 수 있다.
요청-응답 오라클의 단계는 다음과 같이 요약될 수 있다.
- 디앱으로부터 질의를 받는다.
- 질의를 분석한다
- 비용이 지불되었는지, 데이터에 대한 접근 권한이 있는지 확인한다.
- 오프체인 소스에서 관련 데이터를 검색하고 필요한 경우에는 암호화한다.
- 데이터가 포함된 트랜잭션에 서명한다.
- 트랜잭션을 네트워크로 브로드캐스트한다.
- 알림 등 필요한 추가 트랜잭션을 스케줄링한다.
이외의 다른 유형들도 가능하다. 에를 들어, 오라클 스마트 계약 없이도 EOA가 직접 데이터를 요청하고 받을 수 있다. 이와 비슷하게, 요청과 응답은 사물 인터넷이 사물 인터넷 기능을 가진 하드웨어 센서를 통해 이루어질 수 있다. 따라서 오라클은 인간, 소프트웨어 또는 하드웨어가 될 수 있다. 여기서 설명한 요청 응답 패턴은 클라이언트-서버 아키텍처에서 일반적으로 볼 수 있다. 이것은 애플리케이션이 양방향 대화를 할 수 있게 해주는 유용한 메시징 패턴이지만, 특정 조건에서는 적절하지 않을 수 있다. 예를 들어 오라클에 금리를 요청하는 스마트 채권은 금리가 항상 정확한지 확인하기 위해서 요청응답 패턴으로 매일 데이터를 요쳥해야 할 수도 있다. 금리가 자주 변경되지 않는다는 점을 고려할 때, 특히 제한된 대역폭으 고려할 때 게시구독 패턴이 더 적절할 수 있다.
게시구독은 게시자가 수신자에게 직접 메시지를 보내는 것이 아니라, 게시된 메시지를 별개의 클래스로 분류하는 패턴이다. 구독자는 하나 이상의 클래스에 관심을 표명하고 관심 있는 메시지만 검색할 수 있다. 이런 패턴에서 오라클은 변경될 때마다 자체 내부 스토리지에 이자율 같은 데이터를 기록할 수 이싿. 여러 가지 구독 디앱은 오라클 계약에서 이를 읽음으로써 네트워크 대역폭에 미치는 영향을 줄임과 동시에 스토리지 비용을 최소화할 수 있다. 브로드캐스트 또는 멀티캐스트 패턴에서 오라클은 모든 메시지를 채널에 게시하고 구독 계약은 다양한 구독 모드에서 채널을 청취한다. 예를 들어, 오라클은 암호화폐 환율 채널에 메시지를 게시할 수 있다. 구독 스마트 계약은, 예를 들어 이동 평균 계산과 같이 시간 경과에 따른 연속적인 관측값이 필요한 경우에 해당 채널의 전체 콘텐츠를 요청하 룻도 있고, 다른 경우는 현물 가격 계산을 위한 최신 환율만 요구할 수도 있다. 오라클이 가입 계약의 신원을 알 필요가 없는 경우 브로드캐스트 패턴이 적절하다.
같이 보기
