해시넷
오라클 (블록체인)
오라클(oracle)은 블록체인 외부의 데이터를 블록체인 안으로 들여오고, 블록체인의 데이터를 외부로 내보내는 것을 말한다. 오라클은 고립된 블록체인 생태계를 외부와 연결 시켜주는 하나의 다리(bridge) 역할을 한다.
목차
개요
그리스 신화에서 미래에 대한 비전을 볼 수 있으며 신들과 소통하는 사람이라는 뜻에서 유래된 오라클은 블록체인에서 외부에서 일어나는 문제들에 대한 정보를 알려주는 시스템이다. 이상적으로 오라클은 분산적으로 운영되어 탈중앙화 원칙을 바탕으로 작동하기 때문에 신뢰가 필요 없는(trustless) 시스템이다. 가상머신은 탈중앙화된 네트워크상의 모든 노드에서 합의의 규칙에 따라 상태를 업데이트하고 프로그램을 실행할 수 있는데, 합의를 유지하기 위해서 가상머신 실행은 완전히 결정론적이고, 상태와 서명된 트랜잭션의 공유 컨텍스트에 기반을 두고 있어야 한다. 이로 인해 두 가지 결론이 나온다. 첫 번째는 가상머신 및 스마트 계약과 같이 동작하는 임의성을 위한 고유한 소스가 없다는 뜻이고, 두 번째는 트랜잭션 페이로드(payload)를 통해서만 외부 데이터가 유입될 수 있다는 것이다.[1]
가상머신에서 스마트 계약에 임의성을 제공하기 위해 난수 함수(a true random function)의 사용을 금지하는 것을 이해하기 위해서는 난수 함수를 실행한 후에 어떻게 합의를 달성하기 어려워지는지를 살펴봐야 한다. 예를 들어 A라는 노드가 특정 스마트 계약의 명령어를 실행하고 스토리지에 5라는 값을 저장하는 반면, 노드 B는 같은 스마트 계약을 실행하고도 9라는 값을 저장한다고 가정해보자. 노드 A와 B가 동일한 컨텍스트에서 정확하게 동일한 코드를 실행했음에도 그 결과 상태는 다르다. 즉 동일한 원장을 공유해야 하는데, 서로 다른 원장을 가지고 있게 되는 것으로, 이는 곧 스마트 계약이 실행될 때마다 다른 결과 상태가 나올 수 있다는 가능성을 의미한다. 결과적으로 전 세계의 여러 노드가 독립적으로 실행되는 네트워크에서 결과 상태가 무엇인지에 관한 탈중앙화된 합의는 불가능하게 될 것이다.[2]
다양한 애플리케이션에서 사용하기에 암호화된 보안 해시 함수와 같은 의사 난수 함수들은 충분하지 못하다. 동전의 앞이나 뒤를 무작위로 추출해서 내기에 따른 금액을 지급하는 동전 뒤집기 도박 게임을 생각해보면, 이 게임에 참여하는 채굴자는 자신이 이기는 값을 가진 트랜잭션만을 블록에 포함할 수 있기 때문에 유리한 입장에 놓이게 된다. 이런 문제를 해결하기 위해서 모든 노드가 서명된 트랜잭션의 내용에는 동의할 수 있으므로 임의성의 소스, 가격 정보, 일기 예보 등 외부 정보를 네트워크로 전송하는 트랜잭션 데이터의 일부로 포함시키면 해결될 수도 있다. 하지만 이런 데이터는 신뢰할 수 없는 출처에서 나온 것일 수 있기 때문에, 이는 문제를 해결하는 것이 아니라 다른 곳으로 전가시킨 것에 지나지 않는다. 이러한 문제에 대한 대안으로 오라클 시스템이 등장한 것이다.[3]
특징
오라클은 이상적으로 스마트 계약을 위해 이더리움 플랫폼으로 축구 경기의 결과나 금 가격, 혹은 순수 난수와 같은 외부 정보를 가지고 오는 데 신뢰가 필요 없는 방법을 제공한다. 또한 오라클은 디앱 프론트앤드로 직접 데이터를 안전하게 전송하는 곳에도 사용할 수 있다. 그러므로 오라클은 오프체인 세계와 스마트 계약 사이의 격차를 줄이기 위한 메커니즘으로 생각할 수 있다. 스마트 계약을 통해 실세계 이벤트와 데이터를 기반으로 계약적인 관계를 강화하면 오라클의 사용 범위는 크게 확대된다. 하지만 외부 정보는 이더리움 보안 모델에 위험을 초래할 수 있다. 사람이 사망했을 때 자산을 분배해야 하는 스마트 유언(smart will) 계약을 생각해보면 이는 스마트 계약 영역에서 자주 논의되는 것으로, 제3자에 대한 신뢰에 기반한 오라클의 위험을 잘 드러내 준다. 이런 계약에 의해서 제어되는 상속 금액이 상당히 많다며 소유자가 사망하기 전에 오라클을 해킹하고 자산을 분배하려 할 것이다.[2]
일부 오라클은 학력 증명서나 정부 아이디 같은 특정 프라이빗 데이터 출처에 의존하는 데이터를 제공한다. 대학이나 정부 부처 같은 곳은 데이터의 출처에 대한 완전한 신뢰가 필요하고, 따라서 데이터의 진실성은 주관적 문제가 된다. 이런 주관적인 데이터는 독립적으로 객관적 사실을 검증할 수 없기 때문에 신뢰가 필요 없이 제공될 수는 없다. 그러하기에 이러한 데이터 출처도 오라클의 범주의 정의에 포함시키는데, 그 이유는 이것 또한 스마트 계약을 위한 데이터 연결 고리를 제공하기 때문이다. 그리고 이런 데이터는 일반적으로 여권이나 성취 기록 같은 증명서 형식을 취한다. 증명은 특히 신원이나 평판 검증과 연관된 문제와 관련하여 향후 블록체인 플랫폼 성공의 큰 부분이 될 것이므로 블록체인 플랫폼에서 증명을 어떻게 제공할 수 있는지 생각해보는 것이 중요하다.[3]
오라클이 제공할 수 있는 데이터의 예는 다음과 같다.
데이터 종류 예시 양자 및 열처리와 같은 물리적인 소스로부터 발생되는 난수 및 엔트로피 복권 스마트 계약에서 당첨자를 공정하게 뽑는 것 자연재해에 대한 파라미터 트리거 지진 채권을 위한 리히터(Richiter) 규모 측정 환율 데이터 법정 화폐에 대한 암호화폐의 정확한 교환 비율 자본 시장 데이터 토큰화된 자산 및 증권의 가격 책정 벤치마크 참고 데이터 금리를 스마트 금융 파생 상품에 통합하는 것 정적 및 유사 정적 데이터 증권 식별자, 국가 코드, 화폐 코드 등 시간 및 간격 데이터 정확한 시간 측정에 근거한 이벤트 트리거 날씨 데이터 일기예보에 기초한 보험료 계산 정치적 사건 예측 시장 결과 제공 스포츠 이벤트 예측 시장 결과 제공 및 판타지 스포츠 계약 지리적 위치 데이터 공급망 추적에 사용되는 데이터 피해 확인 보험 계약 다른 블록체인에서발생하는 이벤트 상호운용성 함수 이더 시장 가격 법정 화폐 기준 이더 가스 가격 오라클 비행 통계 항공편 티켓 풀링(pooling)에 사용된 그룹 또는 클럽의 통계[1]
기능
모든 오라클은 정의에 따라 몇 가지 핵심 기능을 제공한다. 데이터가 스마트 계약의 스토리지에서 사용할 수 있게 되면 오라클 스마트 계약의 retrieve 함수를 작동시키는 메시지 호출을 통해 다른 스마트 계약이 접근할 수 있다. 또한 이더리움 노드나 네트워크 사용 가능 클라이언트가 오라클 저장소를 조사하여 직접 접근할 수도 있다. 오라클을 설정하는 세 가지 주요 방법은 즉시 읽기, 게시-구독, 요청-응답으로 분류할 수 있다.
즉시 읽기
즉시 읽기(immediate-read) 오라클은 즉각적인 결정에만 필요한 데이터만을 제공한다. 이런 종류의 데이터 질의는 정보가 필요할 때 적시에 조회하고 나면 아마도 다시는 수행하지 않는 경향이 있다. 이런 오라클의 예로는 학술 인증서, 전화번호, 기관 회원권, 공학 식별자, 자치 아이디 등과 같이 조직에 대한 데이터 또는 조직에 의해 발행된 데이터를 보유하는 것들이 있다. 이런 종류의 오라클은 계약 저장소에 데이터를 저장하고, 다른 스마트 계약은 오라클 계약에 요청을 해서 이러한 데이터를 검색할 수 있다. 그리고 이 데이터는 업데이트될 수도 있다. 오라클 스토리지에 있는 데이터는 블록체인 기반, 즉 이더리움 클라이언트에 연결된 애플리케이션에 의해 직접 조회될 수 있기 때문에 번거로운 절차를 거치거나 트랜잭션을 처리하는 가스 비용도 필요하지 않다. 술을 판매할 때 고객의 나이를 확인하고 싶은 가게는 이런 식으로 오라클을 사용할 수 있다.[4]
이런 유형의 오라클은 이와 같은 데이터 요청에 응답하기 위해 서버를 운영하고 유지관리해야 하는 조직이나 회사에 매력적이다. 효율성 또는 프라이버시를 이유로 오라클에 저장된 데이터는 오라클이 처리하는 원시 데이터가 아닐 가능성이 크다. 대학은 과거 학생들의 학업성적 증명서용 오라클을 만들 수 있다. 그러나 증명서의 전체 세부사항을 저장하는 것은 지나친 것이 될 수도 있다. 대신, 증명서의 해시를 저장하는 것만으로 충분하다. 마찬가지로, 예를 들어 정부는 이더리움 플랫폼에 시민 아이디를 넣고 싶을 수도 있다. 여기에 포함된 세부 정보는 분명 비공개로 유지해야 한다. 데이터를 해싱하고 스마트 계약의 저장소에 단지 루트 해시를 저장하는 것으로도 그러한 서비스를 효율적으로 구성할 수 있다.[3]
게시-구독
게시-구독(publish-subscribe)형의 오라클은 정기적으로 혹은 잦은 변경될 것으로 예상되는 데이터에 대한 브로드캐스트 서비스를 효과적으로 제공하는 역할을 하며, 이 데이터는 온체인 스마트 계약에 의해 폴링(polling)되거나 업데이트를 위한 오프체인 데몬에 의해 모니터링된다. 이 카테고리는 RSS 피드, WebSub 등과 유사한 패턴을 지닌다. 오라클은 새로운 정보로 업데이트되고, 플래그는 새로운 데이터를 쓸 수 있음을 구독 대상들에게 알린다. 데이터를 받는 쪽에서는 최신 정보가 변경되었는지 여부를 확인하기 위해 오라클을 폴링하거나 오라클 계약에 대한 업데이트 소식을 기다리다가 업데이트가 발생하면 필요한 조치를 수행한다.[4]
예를 들어 가격 정보, 기상 정보, 경제 또는 사회 통계, 교통 정보 등이 있다. 폴링은 웹 서버 세계에서는 매우 비효율적이지만, 블록체인 플랫폼의 피투피 세계에서는 그렇지 않다. 예를 들어 이더리움 클라이언트는 계약 저장소 변경을 포함하여 모든 상태 변경사항을 알아야 하므로 데이터 변경사항에 대한 폴링은 동기화된 클라이언트에 대한 로컬 호출이다. 이더리움 이벤트 로그를 사용하면 애플리케이션에서 오라클 업데이트를 확인할 수 있기 때문에 어떤 면에서는 이 패턴을 푸시(push) 서비스로 볼 수도 있다. 그러나 폴링이 스마트 계약으로부터 수행되어야 하는 경우는 상당한 가스 비용이 발생할 수 있는데, 일부 탈중앙화된 애플리케이션에서 이러한 폴링이 필요할 수도 있다.[3]
요청-응답
요청-응답(request-response) 카테고리는 가장 복잡하다. 이 유형은 데이터 공간이 너무 커서 스마트 계약에 저장할 수 없으며, 사용자는 한 번에 전체 데이터 중 일부만 필요한 경우에 사용된다. 또한 이것은 데이터 공급자 사업 영역에 적용 가능한 모델이기도 하다. 실제로 오라클은 요청을 모니터링하고 데이터를 검색 및 반환하는데 사용되는 온체인 스마트 계약과 오프체인 인프라 시스템으로 구현될 수 있다. 탈중앙화된 애플리케이션의 데이터 요청은 일반적으로 여러 단계에 걸친 비동기 프로세스다. 이 패턴에서는 우선 EOA가 탈중앙화된 애플리케이션과 연결해서 오라클 스마트 계약에 정의된 함수와 상호작용한다. 이 함수는 오라클에 요청을 보내는데, 이때 요청하는 데이터의 세부 사항을 지정하는 인수와 더불어 콜백 함수, 스케줄링 파라미터 등의 추가적인 정보도 포함할 수 있다. 이 트랜잭션이 검증되면 오라클 요청은 오라클 계약에 의해 발생한 가상머신 이벤트 또는 상태 변화를 통해서 확인할 수 있으며, 이것의 인수를 받아서 오프체인 데이터 소스에 대한 검색을 실제 수행하는데 사용할 수 있다. 또한 오라클은 요청 처리, 콜백에 대한 가스 지급, 요청 데이터에 대한 접근 권한을 요구할 수 있다.[5] 마지막으로, 결과 데이터는 오라클 소유자의 서명을 받아 주어진 시간상의 데이터의 유효성을 입증하고 직접 또는 오라클 계약을 통해 요청한 탈중앙화 애플리케이션에 트랜잭션으로 전달된다. 스케줄링 파라미터에 따라 오라클은 데이터를 일정한 간격으로 업데이트하는 추가 트랜잭션을 브로드캐스트 할 수 있다.[4]
요청-응답 오라클의 단계는 다음과 같이 요약될 수 있다.
- 디앱으로부터 질의를 받는다.
- 질의를 분석한다.
- 비용이 지급되었는지, 데이터에 대한 접근 권한이 있는지 확인한다.
- 오프체인 소스에서 관련 데이터를 검색하고 필요한 경우에는 암호화한다.
- 데이터가 포함된 트랜잭션에 서명한다.
- 트랜잭션을 네트워크로 브로드캐스트한다.
- 알림 등 필요한 추가 트랜잭션을 스케줄링한다.
이외의 다른 유형들도 가능하다. 예를 들어, 오라클 스마트 계약 없이도 EOA가 직접 데이터를 요청하고 받을 수 있다. 이와 비슷하게, 요청과 응답은 사물 인터넷이 사물 인터넷 기능을 가진 하드웨어 센서를 통해 이루어질 수 있다. 따라서 오라클은 인간, 소프트웨어 또는 하드웨어가 될 수 있다. 여기서 설명한 요청-응답 패턴은 서버-클라이언트 아키텍처에서 일반적으로 볼 수 있다. 이것은 애플리케이션이 양방향 대화를 할 수 있게 해주는 유용한 메시징 패턴이지만, 특정 조건에서는 적절하지 않을 수 있다. 예를 들어 오라클에 금리를 요청하는 스마트 채권은 금리가 항상 정확한지 확인하기 위해서 요청-응답 패턴으로 매일 데이터를 요청해야 할 수도 있다. 금리가 자주 변경되지 않는다는 점을 고려할 때, 특히 제한된 대역폭을 고려할 때 게시-구독 패턴이 더 적절할 수 있다.[1]
게시-구독은 게시자가 수신자에게 직접 메시지를 보내는 것이 아니라, 게시된 메시지를 별개의 클래스로 분류하는 패턴이다. 구독자는 하나 이상의 클래스에 관심을 표명하고 관심 있는 메시지만 검색할 수 있다. 이런 패턴에서 오라클은 변경될 때마다 자체 내부 스토리지에 이자율 같은 데이터를 기록할 수 있다. 여러 가지 구독 디앱은 오라클 계약에서 이를 읽음으로써 네트워크 대역폭에 미치는 영향을 줄임과 동시에 스토리지 비용을 최소화할 수 있다. 브로드캐스트 또는 멀티캐스트 패턴에서 오라클은 모든 메시지를 채널에 게시하고 구독 계약은 다양한 구독 모드에서 채널을 청취한다. 예를 들어, 오라클은 암호화폐 환율 채널에 메시지를 게시할 수 있다. 구독 스마트 계약은, 예를 들어 이동 평균 계산과 같이 시간 경과에 따른 연속적인 관측값이 필요한 상황에 해당 채널의 전체 콘텐츠를 요청할 수도 있고, 다른 경우는 현물 가격 계산을 위한 최신 환율만 요구할 수도 있다.[6] 오라클이 가입 계약의 신원을 알 필요가 없는 경우 브로드캐스트 패턴이 적절하다.[3]
종류
계산 오라클
오라클은 임의의 계산을 수행하는 데 사용될 수도 있다. 계산 오라클은 데이터의 요청 및 응답에만 사용되는 것뿐만 아니라, 온체인에서 실행 불가능한 계산에 대한 입력을 받아 결과를 돌려보내는 데 사용할 수 있다. 예를 들어, 계산 오라클을 사용하여 계산 집약적인 희귀 계산을 수행하여 채권 계약의 수익률을 추정할 수 있다. 중앙화되었지만 감사 가능한 서비스를 신뢰할 수 있다면, 오라클라이즈(Oraclize)를 사용할 수 있다. 오라클라이즈는 탈중앙화된 애플리케이션이 샌드박스형 AWS 가상머신에서 수행하는 계산 결과를 요청할 수 있는 서비스를 제공한다. 사용자가 구성한 도커파일(docker file)은 아카이브 형태로 분산형 파일 시스템(IPFS)에 업로드되며, AWS 인스턴스는 이를 통해 실행 가능한 컨테이너를 만든다. 요청에 따라 오라클라이즈는 해시를 사용하여 이 아카이브를 검색한 다음, AWS에서 도커 컨테이너를 초기화 및 실행하고, 애플리케이션에 제공되는 모든 인수를 환경 변수로 전달한다. 컨테이너화된 애플리케이션은 시간제한에 따라 계산을 수행하고 표준 출력에 결과를 기록한다. 그 출력 결과는 오라클라이즈로 검색하여 탈중앙화 애플리케이션에 반환할 수 있다. 오라클라이즈는 현재 감사 가능한 t2.micro AWS 인스턴스에서 이 서비스를 제공하고 있다. 따라서 계산이 상당히 중요한 경우라면 지정된 정확한 도커 컨테이너가 실행되었는지 확인할 수 있다. 그런데도 불구하고 이것은 진정한 탈중앙화 솔루션이 아니다.[1]
마이크로소프트에서는 입증할 수 있는 오라클 신뢰를 위한 표준인 크립트렛(cryptlet) 개념이 좀 더 광범위한 ESC 프레임워크의 일부로 공식화되어 제공하고 있다. 크립트렛은 암호화된 캡슐 내에서 I/O 같은 인프라를 추상화하고, 크립토델리게이트(CryptoDelegate)가 첨부되어 송수신 메시지가 자동으로 서명, 유효성 검사, 검증되도록 실행된다. 크립트렛은 분산 트랜잭션을 지원하므로 계약 논리는 복잡한 다단계, 다중 블록체인, 외부 시스템 트랜잭션을 ACID 방식으로 처리할 수 있다. 이를 통해 개발자는 스마트 계약에서 사용하기 위해 오라클의 신뢰에 대한 포터블하고, 독립적이며, 프라이빗한 솔루션을 만들 수 있다. 크립트렛은 다음의 샘플 코드를 따른다.[7]
public class SampleContractCryptlet : Cryptlet
{
public SampleContractCryptlet(Guid id, Guid bindingId, string name,
string address, IContainerServices hostContainer, bool contract)
: base(id, bindingId, name, address, hostContainer, contract)
{
MessageApi = new CryptletMessageApi(GetType() .FullName,
new SampleContractConstructor())
트루비트(TrueBit)는 보다 탈중앙화된 솔루션으로 확장성과 검증 가능한 오프체인 계산을 위한 솔루션을 제공한다. 이것은 계산자와 검증자 시스템을 사용하는데, 계산의 수행과 검증에 대해 이들에게 보상을 각각 제공하다. 만약 어떤 계산 결과에 대해 챌린지가 나오면, 계산의 하위 집합에 대한 반복적인 검증 프로세스가 온체인에서 수행되며, 이는 일종의 검증 게임(verification game)이 된다. 게임은 일련의 라운드를 진행하며, 각각은 계산의 더 작은 하위 집합을 반복적으로 확인한다. 결국 게임은 최종 라운드에 이르게 되는데, 챌린지가 온체인에서 수행될 만큼 충분히 작아졌으므로 심판관은 솔루션에 대한 챌린지가 맞았는지 최종 판결을 온체인에서 할 수 있다. 사실상 트루비트는 컴퓨테이션 시장을 구현한 것인데, 이것은 탈중앙화된 애플리케이션들이 네트워크 밖에서 검증 가능한 컴퓨테이션을 살 수 있도록 해주되, 검증 게임의 룰은 이더리움에 의해 강제되도록 만들어준다. 이론상으로는 신뢰가 필요 없는 스마트 계약을 통해 모든 계산 작업을 안전하게 수행할 수 있다.[7]
트루비트 같은 시스템에는 머신러닝에서부터 작업증명(PoW) 검증에 이르기까지 다양한 애플리케이션이 있다. 후자의 예로, 도지-이더리움 브리지는 도지코인(Dogecoin)의 작업증명을 검증하기 위해 트루비트를 사용하는데, 이는 이더리움 블록 가스 한도 내에서는 계산할 수 없는 메모리를 많이 사용하고 계산 집약적인 함수가 검증된다. 트루비트를 이용한 검증 작업을 수행함으로써 이더리움의 린케비(Rinkeby) 테스트 네트워크에서 스마트 계약으로 도지코인 트랜잭션을 안전하게 확인할 수 있다.[3]
탈중앙화 오라클
많은 애플리케이션에서 중앙화된 데이터 또는 계산 오라클은, 특히 이더리움 네트워크에서는 단일 실패 지점(Single Point of Failure, SPOF)이 생긴다.[8] 데이터 가용성을 보장하고 온체인 데이터 집계 시스템을 갖춘 개별 데이터 제공자의 네트워크를 만드는 수단으로서 탈중앙화 오라클의 아이디어를 둘러싼 여러 가지 계획이 제안되었다. 체인링크(ChainLink)는 평판(reputation) 계약, 오더매칭(order-matching) 계약, 그리고 집계(aggregation) 계약이라는 세 가지 주요 스마트 계약과 데이터 공급자의 오프체인 레지스트리로 구성된 탈중앙화 오라클 네트워크를 제안했다. 평판 계약은 데이터 제공자의 성과를 추적하는 데 사용된다. 평판 계약의 점수는 오라클로부터 입찰가를 선택한다. 그런 다음, 쿼리 파라미터와 필요한 오라클 수를 포함하는 서비스 수준 계약을 완료한다. 즉, 구매자는 개별 오라클과 직접 트랜잭션 할 필요가 없다. 집계 계약은 여러 오라클로부터 응답을 수집하고, 쿼리의 최종 집합 결과를 계산하고, 마침내 그 결과를 평판 계약으로 피드백해 준다.[9]
이러한 탈중앙화된 방식의 주요 문제점 중 하나는 집계 함수의 공식화이다. 체인링크는 각 오라클 응답에 대해 유효성 점수가 보고되도록 가중치 응답을 계산하는 것을 제안하고 있는데, 이것은 각각의 응답에 대해 하나의 유효성 점수를 부여하는 것을 허용한다. 여기에서 유효하지 않은 점수를 식별하기는 쉽지 않은 문제인데, 왜냐하면 이것은 다른 피어들이 제공한 응답으로부터 차이가 많이 나는 값들은 부정확한 것으로 전제하는 것이기 때문이다. 유효성 점수를 응답 점수의 분포도상에서의 위치를 기준으로 계산하면, 평균을 벗어나는 값들에 대한 페널티를 받게 된다. 따라서 체인링크는 표준 집계 계약도 제공하지만, 사용자의 집계 계약도 지정할 수 있다.
이와 관련된 아이디어로서 쉘링코인(Schelling Coin) 프로토콜이 있다. 여기서는 여러 참가자가 값을 보고하고 중간값을 올바른(correct) 대답으로 취한다.[9] 리포터들은 보증금을 내고 참가해야만 하는데, 이 보증금은 중간값에 가장 가까운 값을 제시한 사람순으로 재분배되기 때문에 다른 사람들과 비슷한 값을 보고하도록 동기부여를 하게 된다. 쉘링포인트로도 알려진 이 공통 값(common value)은 응답자들이 협조해서 구해야 할 자연스럽고 명백한 값으로 간주할 것이고, 따라서 실제 값에 근접할 것으로 예상할 수 있다.[1]
트루비트의 제이슨 토이치(Jason Teutsch)는 최근 탈중앙화형 오프체인 데이터 가용성 오라클을 위한 새로운 디자인을 제안했다. 이 디자인은 등록된 데이터가 특정 에포크 동안 사용 가능한지 여부를 정확하게 보고할 수 있는 전용 작업증명 블록체인을 활용한다. 채굴자는 현재 등록된 모든 데이터를 다운로드, 저장 및 전파하려고 시도하므로 데이터를 로컬에서 사용할 수 있다. 이런 시스템은 모든 채굴 노드가 등록된 모든 데이터를 저장하고 전파한다는 점에서 비싸지만, 등록 기간이 끝나면 데이터를 삭제해서 저장 공간을 재사용할 수 있게 한다.[3]
문제점과 해결방안
- 데이터 인증
- 디앱이 질의하는 데이터 소스는 신뢰할 수 있다지만 오라클과 요청-응답 메커니즘이 별개의 주체에 의해 운영될 수 있다고 가정하면, 그 데이터를 온체인으로 올리는 주체를 어떻게 믿어야 하는 것인가에 대한 의구심이 생긴다. 전송 중에 데이터가 변조될 가능성이 분명히 있기 때문에 반환된 데이터가 변조되지 않았다는 무결성을 입증할 수 있는 오프체인 방식의 검증 방법이 매우 중요하다. 검증하기 위한 두 가지 공통적인 접근 방법은 진위성 증명(authenticity proof)과 신뢰할 수 있는 실행 환경(trusted execution environment, TEE)이다.[10] 진위성 증명은 데이터가 변조되지 않았음을 암호학적으로 보증하는 것이다. 이것은 다양한 입증 기법들, 예를 들어 디지털 사인 된 증명을 사용함으로써 데이터 운반자에 대한 신뢰 문제를 데이터 입증자의 문제로 전환한다. 스마트 계약은 체인상의 진위성 증명을 검증함으로써 데이터를 처리하기 전에 데이터의 무결성을 검증할 수 있다.[3]
- 오라클라이즈(Oraclize)
- 진위성 증명은 데이터가 변조되지 않았다는 것을 암호학적으로 보장한다. 오라클라이즈는 다양한 진위성 증명을 활용하는 오라클 서비스의 예이고, TLSNotary 증명이 그 중 하나이다. 현재 이더리움 메인 네트워크의 데이터 질의에 사용할 수 있는 그런 증거 중 하나가 TLSNotary 증명이다. TLS 일반 증명을 사용하면 클라이언트는 클라이언트와 서버 간에 HTTPS 웹 트래픽이 발생했다는 증거를 제3자에게 제공할 수 있다.[9] HTTPS 자체는 안전하지만 데이터 서명은 지원하지 않는다. 결과적으로 TLSNotary 증명은 전송 계층 보안(transport layer security, TLS) 프로토콜을 활용하여 접근 후 데이터에 서명하는 TLS 마스터키를 서버(oracle), 감사대상자(oraclize), 감사인(AWS instance)의 세 당사자 간에 분할할 수 있다.[1] 감사인은 TLSNotary secret를 저장하고 있어 진위성 증명을 제공하며, 인스턴스화 이후에 수정되지 않았다는 것이 검증될 수 있다.
- 오라클라이즈는 아마존 웹 서비스(Amazon Web Services, AWS) 가상 시스템 인스턴스를 감사자로 사용하며, 인스턴스화 이후에 수정되지 않았음이 검증될 수 있다.[11] 이 AWS 인스턴스는 TLSNotary 암호를 저장하여 진위성 증명을 제공한다. 순수한 요청-응답 메커니즘보다 데이터 변조에 대한 높은 확신을 제공하지만, 이 접근 방식은 아마존 자체가 VM 인스턴스를 변경하지 않는다는 가정을 필요로 한다.[3]
- 타운 크리에(Town Crier)
- 타운 크리에는 TEE(신뢰할 수 있는 실행 환경) 접근 방식에 기반한 인증된 데이터 피드 오라클 시스템이다. 이런 방법은 데이터의 무결성을 보장하기 위해 하드웨어 기반의 보안 영역을 사용한다. 타운 크리에는 인텔의 SGX(Software Guard eXtensions)라고 불리는 소프트웨어 보안 확장판을 사용하여 HTTPS 질의의 진위성을 검증할 수 있다. SGX는 한 영역 내에서 실행되는 애플리케이션이 다른 프로세스에 의해 변조되지 않게 CPU에 의해 보호받도록 하여 무결성을 보장한다. 또한 기밀성을 제공하여 한 영역 내에서 실행될 때 애플리케이션의 상태가 다른 프로세스에 보이지 않도록 한다. 마지막으로, SGX는 해당 빌드의 해시로 확실하게 식별된 애플리케이션이 실제로 보안 영역 내에서 실행된다는 디지털 서명 증명을 생성하여 인증이 가능하도록 한다. 이 디지털 서명을 확인함으로써 탈중앙화된 애플리케이션이 타운 크리에 인스턴스가 SGX 영역 내에 안전하게 실행되고 있음을 증명할 수 있다.[1]
- 이것은 결국 인스턴스가 변경되지 않았으며, 타운 크리에에서 나온 데이터가 신뢰할 수 있음을 증명한다. 기밀성 속성은 타운 크리에 인스턴스의 공개키를 사용하여 데이터 쿼리를 아호화함으로써 타운 크리에는 프리이빗 데이터를 처리할 수 있다. SGX와 같은 보안 영역 안에서 오라클의 질의 및 응답을 수행하기 때문에 오라클이 신뢰할 수 있는 제3자 하드웨어 상에 안전하게 실행되고 있으며, 요청된 데이터가 변조되지 않고 반환되었다는 것을 보장받을 수 있다.[3]
각주
- ↑ 1.0 1.1 1.2 1.3 1.4 1.5 1.6 modolee, 〈(Mastering Ethereum) Oracle〉, 《스팀잇》
- ↑ 2.0 2.1 HAS3ONG, 〈(Ethereum) Oracle, 오라클 -1-〉, 《티스토리》, 2019-06-20
- ↑ 3.0 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 박성훈, 류길성, 강동욱, Mastering Ethereum BUILDING SMART CONTRACTS AND DAPPS, 제이펍, 2019
- ↑ 4.0 4.1 4.2 HAS3ONG, 〈(Ethereum) Oracle, 오라클 기능-2-〉, 《티스토리》, 2019-06-20
- ↑ WATERGLASSCLAP, 〈Java 관련 기초 지식들〉, 《블로그스팟》, 2018-01-21
- ↑ 〈마스터링 이더리움 스마트 컨트랙트 및 댑 구축하기 책소개〉, 《교보문고 공식 홈페이지》
- ↑ 7.0 7.1 HAS3ONG, 〈(Ethereum) Oracle, 계산 오라클 -3-〉, 《티스토리》, 2019-06-20
- ↑ kimwntjd77, 〈IT 서비스〉, 《네이버 블로그》, 2017-04-11
- ↑ 9.0 9.1 9.2 오라클리아, 〈Oraclize〉, 《네이버 블로그》, 2019-05-08
- ↑ 이본느 림(Yvonne Lim), 〈젬알토, 2012 모바일 월드 콩그레스서 새로운 NFC, M2M, LTE 혁신 선보여〉, 《뉴시스》, 2012-02-27
- ↑ 장현, 〈(기고) 클라우드 서비스 제공자 어떻게 선택해야 하는가〉, 《아이티데일리》, 2015-10-01
참고자료
- 박성훈, 류길성, 강동욱, Mastering Ethereum BUILDING SMART CONTRACTS AND DAPPS, 제이펍, 2019
- 〈마스터링 이더리움 스마트 컨트랙트 및 댑 구축하기 책소개〉, 《교보문고 공식 홈페이지》
- HAS3ONG, 〈(Ethereum) Oracle, 오라클 -1-〉, 《티스토리》, 2019-06-20
- HAS3ONG, 〈(Ethereum) Oracle, 오라클 기능-2-〉, 《티스토리》, 2019-06-20
- HAS3ONG, 〈(Ethereum) Oracle, 계산 오라클 -3-〉, 《티스토리》, 2019-06-20
- modolee, 〈(Mastering Ethereum) Oracle〉, 《스팀잇》
- WATERGLASSCLAP, 〈Java 관련 기초 지식들〉, 《블로그스팟》, 2018-01-21
- 오라클리아, 〈Oraclize〉, 《네이버 블로그》, 2019-05-08
- kimwntjd77, 〈IT 서비스〉, 《네이버 블로그》, 2017-04-11
- 이본느 림(Yvonne Lim), 〈젬알토, 2012 모바일 월드 콩그레스서 새로운 NFC, M2M, LTE 혁신 선보여〉, 《뉴시스》, 2012-02-27
- 장현, 〈(기고) 클라우드 서비스 제공자 어떻게 선택해야 하는가〉, 《아이티데일리》, 2015-10-01
같이 보기
이 오라클 (블록체인) 문서는 블록체인 기술에 관한 글로서 검토가 필요합니다. 위키 문서는 누구든지 자유롭게 편집할 수 있습니다. [편집]을 눌러 문서 내용을 검토·수정해 주세요.
