위키원
"오라클 (블록체인)"의 두 판 사이의 차이
(새 문서: '''오라클'''(oracle)은 블록체인 외부의 데이터를 블록체인 안으로 들여오고, 블록체인의 데이터를 외부로 내보내는 것을 말한다. 오라클...) |
leejia1222 (토론 | 기여) |
||
| 1번째 줄: | 1번째 줄: | ||
'''오라클'''(oracle)은 [[블록체인]] 외부의 데이터를 블록체인 안으로 들여오고, 블록체인의 데이터를 외부로 내보내는 것을 말한다. 오라클은 고립된 블록체인 생태계를 외부와 연결 시켜주는 하나의 다리(bridge) 역할을 한다. | '''오라클'''(oracle)은 [[블록체인]] 외부의 데이터를 블록체인 안으로 들여오고, 블록체인의 데이터를 외부로 내보내는 것을 말한다. 오라클은 고립된 블록체인 생태계를 외부와 연결 시켜주는 하나의 다리(bridge) 역할을 한다. | ||
| + | ==개요== | ||
| + | 오라클은 그리스 신화에서 신의 계시를 전달하고 미래의 모습을 보는 사람이라는 뜻에서 유래되었다. 블록체인에서 오라클은 외부에서 일어나는 문제들에 대한 정보를 알려주는 시스템이다. 이상적으로 오라클은 신뢰가 필요 없는(trustless) 시스템인데, 그 이유는 탈중앙화 원칙을 바탕으로 작동하기 때문이다. 가상 머신은 탈중앙화된 네트워크상의 모든 노드에서 합의의 규칙에 따라 프로그램을 실행하고 상태를 업데이트할 수 있다. 합의를 유지하기 위해서 가상 머신 실행은 완전히 결정론적이고, 상태와 서명된 트랜잭션의 공유 컨텍스트에 기반을 두고 있어야 한다. 이것은 두 가지 중요한 결과를 낳는다. 첫 번째는 가상 머신 및 스마트 계약과 같이 동작하는 임의성을 위한 고유한 소스가 없다는 뜻이고, 두 번째는 외부 데이터가 트랜잭션의 데이터 페이로드(payload)로서만 유입될 수 있다는 것이다. | ||
| + | |||
| + | 가상 머신에서 스마트 계약에 임의성을 제공하기 위해 난수 함수(a true random function)의 사용을 금지하는 것을 이해하려면, 난수 함수를 실행한 후에 어떻게 합의를 달성하기 어려워지는지를 살펴봐야 한다. 노드 A는 특정 스마트 계약의 명령어를 실행하고 스토리지에 3을 저장하는 반면, 노드 B는 동일한 스마트 계약을 실행하고도 7을 저장한다고 가정해보자. 노드 A와 B가 동일한 컨텍스트에서 정확하게 동일한 코드를 실행했음에도 결과 상태가 다르게 나온다. 그야말로 스마트 계약이 실행될 때마다 다른 결과 상태가 나올 수 있다. 따라서 전 세계의 여러 노드가 독립적으로 실행되는 네트워크에서 결과 상태가 무엇인지에 관한 탈중앙화된 합의는 불가능하게 될 것이다. 실제로는 훨씬 상황이 안 좋아질 수 있는데, 그 이유는 연쇄효과가 기하급수적으로 쌓일 것이기 때문이다. | ||
| + | |||
| + | 암호화된 보안 해시 함수와 같은 의사 난수 함수들은 다양한 애플리케이션에서 사용하기에는 충분하지 못하다. 동전의 앞이나 뒤를 무작위로 추출해서 내기에 따른 금액을 지급하는 동전 뒤집기 도박 게임을 생각해보자. 이 게임에 참여하는 채굴자는 자신이 이기는 값을 가진 트랜잭션만을 블록에 포함할 수 있기 때문에 유리한 입장에 설 수 있다. 이런 문제를 해결하기 위해서 모든 노드가 서명된 트랜잭션의 내용에는 동의할 수 있으므로 임의성의 소스, 가격 정보, 일기 예보 등 외부 정보를 네트워크로 전송하는 트랜잭션 데이터의 일부로 포함시키면 해결될 수 있을지도 모른다. 그러나 이런 데이터는 확인할 수 없는 출처에서 비롯되어 전혀 신뢰할 수 없다. 이것은 문제를 해결하는 것이 아니라 다른 곳으로 전가시킨 것에 지나지 않는다. 이 문제를 해결하기 위해 오라클을 사용하는 것이다. | ||
| + | |||
| + | ==기능== | ||
| + | 모든 오라클은 정의에 따라 몇 가지 핵심 기능을 제공한다. 데이터가 스마트 계약의 스토리지에서 사용할 수 있게 되면 오라클 스마트 계약의 retrieve 함수를 작동시키는 메시지 호출을 통해 다른 스마트 계약이 접근할 수 있다. 또한 이더리움 노드나 네트워크 사용 가능 클라이언트가 오라클 저장소를 조사하여 직접 접근할 수도 있다. 오라클을 설정하는 세 가지 주요 방법은 즉시읽기, 게시구독, 요청응답으로 분류할 수 있다. | ||
| + | |||
| + | ===즉시읽기=== | ||
| + | 즉시읽기(immediate-read) 오라클은 즉각적인 결정이 필요한 데이터만을 제공한다. 이런 종류의 데이터 질의는 정보가 필요할 때 적시에 조회하고 나면 아마도 다시는 수행하지 않는 경향이 있다. 이런 오라클의 예로는 학술 인증서, 전화번호, 기관 회원권, 공학 식별자, 자치ID 등과 같이 조직에 대한 데이터 또는 조직에 의해 발행된 데이터를 보유하는 것들이 있다. 이런 종류의 오라클은 계약 저장소에 데이터를 저장하고, 다른 스마트 계약은 오라클 계약에 요청을 해서 이러한 데이터를 검색할 수 있다. 그리고 이 데이터는 업데이트될 수도 있다. 오라클 스토리지에 있는 데이터는 블록체인 기반, 즉 이더리움 클라이언트에 연결된 애플리케이션에 의해 직접 조회될 수 있기 때문에 번거로운 절차를 거치거나 트랜잭션을 처리하는 가스 비용도 필요하지 않다. 술을 사려는 고객의 나이를 확인하고 싶은 가게는 이런 식으로 오라클을 사용할 수 있다. | ||
| + | |||
| + | 이런 유형의 오라클은 이와 같은 데이터 요청에 응답하기 위해 서버를 운영하고 유지관리해야 하는 조직이나 회사에 매력적이다. 오라클에 의해 저장된 데이ㅓ는 효유성이나 프라이버시 때문에 오라클이 제공하는 원시 데이터가 아닐 가능성이 높다. 대학은 과거 학생들의 학업성적 증명서용 오라클을 만들 수 있다. 그러나 증명서의 전체 세부사항을 저장하는 것은 지나친 것이 될 수도 있다. 대신, 증명서의 해시를 저장하는 것만으로 충분하다. 마찬가지로, 예를들어 정부는 이더리우 플랫폼에 시민 ID를 넣고 싶을 수도 있다. 여기에 포함된 세부 정보는 분명 비공개로 유지해야 한다. 데이터를 해싱하고 스마트 계약의 저장소에 단지 루트 해시를 저장하는 것으로도 그러한 서비스를 효율적으로 구성할 수 있다. | ||
| + | |||
| + | ===게시구독=== | ||
| + | 게시구독(publish-subscribe)형의 오라클은 정기적 혹은 잦은 변화가 예상되는 데이터를 효과적으로 브로드캐스트하는 역할을 하며, 이 데이터는 온체인 스마트 계약에 의해 폴링(polling)되거나 업데이트를 위한 오프체인 데몬에 의해 모니터링된다. 이 카테고리는 RSS 피드, WebSub 등과 유사한 패턴을 지닌다. 오라클은 새로운 정보로 업데이트되고, 플래그는 새로운 데이터를 쓸 수 있음을 구독 대상들에게 알린다. 데이터를 받는 쪽에서는 최신 정보가 변경되었는지 여부를 확인하기 위해 오라클을 폴링하거나 오라클 계약에 대한 업데이트 소식을 기다리다가 업데이트가 발생하면 필요한 조치를 수행한다. | ||
| + | |||
| + | 예를 들어 가격 정보, 기상 정보, 경제 또는 사회 통계, 교통 정보 등이 있다. 폴링은 웹 서버 세계에서는 매우 비효율적이지만, 블록체인 플랫폼의 피투피 컨텍스트에서는 그렇지 않다. 예를 들어 이더리움 클라이언트는 컨트랙트 저장소 변경을 포함하여 모든 상태 변경사항을 알아야 하므로 데이터 변경사항에 대한 폴링은 동기화된 클라이언트에 대한 로컬 호출이다. 이더리움 이벤트 로그를 사용하면 애플리케이션에서 오라클 어데이트를 매우 쉽게 볼 수 있으므로 이 패턴은 어떤 면에서 푸시(push) 서비스로 간주할 수 있다. 그러나 폴링이 스마트 계약으로부터 수행되어야 하는 경우는 상당한 가스 비용이 발생할 수 있는데, 일부 탈중앙화된 애플리케이션에서 이러한 폴링이 필요할 수도 있다. | ||
| + | |||
| + | ===요청응답=== | ||
| + | 요청응답(request-response) 카테고리는 가장 복잡하다. 이 유형으 스마트 계약에 저장하기에는 데이터 공간이 너무 크고, 사용자는 전체 데이터 중 한 번에 일부만 필요로 하는 경우에 사용된다. 또한 이것은 데이터 공급자 사업 영역에 적용 가능한 모델이기도 하다. 실용적인 측면에서 보자면, 오라클은 요청을 모니터링하고 데이터를 검색하고 반환하는 데 사용되는 | ||
== 같이 보기 == | == 같이 보기 == | ||
* [[오라클 문제]] | * [[오라클 문제]] | ||
2019년 8월 30일 (금) 15:07 판
오라클(oracle)은 블록체인 외부의 데이터를 블록체인 안으로 들여오고, 블록체인의 데이터를 외부로 내보내는 것을 말한다. 오라클은 고립된 블록체인 생태계를 외부와 연결 시켜주는 하나의 다리(bridge) 역할을 한다.
개요
오라클은 그리스 신화에서 신의 계시를 전달하고 미래의 모습을 보는 사람이라는 뜻에서 유래되었다. 블록체인에서 오라클은 외부에서 일어나는 문제들에 대한 정보를 알려주는 시스템이다. 이상적으로 오라클은 신뢰가 필요 없는(trustless) 시스템인데, 그 이유는 탈중앙화 원칙을 바탕으로 작동하기 때문이다. 가상 머신은 탈중앙화된 네트워크상의 모든 노드에서 합의의 규칙에 따라 프로그램을 실행하고 상태를 업데이트할 수 있다. 합의를 유지하기 위해서 가상 머신 실행은 완전히 결정론적이고, 상태와 서명된 트랜잭션의 공유 컨텍스트에 기반을 두고 있어야 한다. 이것은 두 가지 중요한 결과를 낳는다. 첫 번째는 가상 머신 및 스마트 계약과 같이 동작하는 임의성을 위한 고유한 소스가 없다는 뜻이고, 두 번째는 외부 데이터가 트랜잭션의 데이터 페이로드(payload)로서만 유입될 수 있다는 것이다.
가상 머신에서 스마트 계약에 임의성을 제공하기 위해 난수 함수(a true random function)의 사용을 금지하는 것을 이해하려면, 난수 함수를 실행한 후에 어떻게 합의를 달성하기 어려워지는지를 살펴봐야 한다. 노드 A는 특정 스마트 계약의 명령어를 실행하고 스토리지에 3을 저장하는 반면, 노드 B는 동일한 스마트 계약을 실행하고도 7을 저장한다고 가정해보자. 노드 A와 B가 동일한 컨텍스트에서 정확하게 동일한 코드를 실행했음에도 결과 상태가 다르게 나온다. 그야말로 스마트 계약이 실행될 때마다 다른 결과 상태가 나올 수 있다. 따라서 전 세계의 여러 노드가 독립적으로 실행되는 네트워크에서 결과 상태가 무엇인지에 관한 탈중앙화된 합의는 불가능하게 될 것이다. 실제로는 훨씬 상황이 안 좋아질 수 있는데, 그 이유는 연쇄효과가 기하급수적으로 쌓일 것이기 때문이다.
암호화된 보안 해시 함수와 같은 의사 난수 함수들은 다양한 애플리케이션에서 사용하기에는 충분하지 못하다. 동전의 앞이나 뒤를 무작위로 추출해서 내기에 따른 금액을 지급하는 동전 뒤집기 도박 게임을 생각해보자. 이 게임에 참여하는 채굴자는 자신이 이기는 값을 가진 트랜잭션만을 블록에 포함할 수 있기 때문에 유리한 입장에 설 수 있다. 이런 문제를 해결하기 위해서 모든 노드가 서명된 트랜잭션의 내용에는 동의할 수 있으므로 임의성의 소스, 가격 정보, 일기 예보 등 외부 정보를 네트워크로 전송하는 트랜잭션 데이터의 일부로 포함시키면 해결될 수 있을지도 모른다. 그러나 이런 데이터는 확인할 수 없는 출처에서 비롯되어 전혀 신뢰할 수 없다. 이것은 문제를 해결하는 것이 아니라 다른 곳으로 전가시킨 것에 지나지 않는다. 이 문제를 해결하기 위해 오라클을 사용하는 것이다.
기능
모든 오라클은 정의에 따라 몇 가지 핵심 기능을 제공한다. 데이터가 스마트 계약의 스토리지에서 사용할 수 있게 되면 오라클 스마트 계약의 retrieve 함수를 작동시키는 메시지 호출을 통해 다른 스마트 계약이 접근할 수 있다. 또한 이더리움 노드나 네트워크 사용 가능 클라이언트가 오라클 저장소를 조사하여 직접 접근할 수도 있다. 오라클을 설정하는 세 가지 주요 방법은 즉시읽기, 게시구독, 요청응답으로 분류할 수 있다.
즉시읽기
즉시읽기(immediate-read) 오라클은 즉각적인 결정이 필요한 데이터만을 제공한다. 이런 종류의 데이터 질의는 정보가 필요할 때 적시에 조회하고 나면 아마도 다시는 수행하지 않는 경향이 있다. 이런 오라클의 예로는 학술 인증서, 전화번호, 기관 회원권, 공학 식별자, 자치ID 등과 같이 조직에 대한 데이터 또는 조직에 의해 발행된 데이터를 보유하는 것들이 있다. 이런 종류의 오라클은 계약 저장소에 데이터를 저장하고, 다른 스마트 계약은 오라클 계약에 요청을 해서 이러한 데이터를 검색할 수 있다. 그리고 이 데이터는 업데이트될 수도 있다. 오라클 스토리지에 있는 데이터는 블록체인 기반, 즉 이더리움 클라이언트에 연결된 애플리케이션에 의해 직접 조회될 수 있기 때문에 번거로운 절차를 거치거나 트랜잭션을 처리하는 가스 비용도 필요하지 않다. 술을 사려는 고객의 나이를 확인하고 싶은 가게는 이런 식으로 오라클을 사용할 수 있다.
이런 유형의 오라클은 이와 같은 데이터 요청에 응답하기 위해 서버를 운영하고 유지관리해야 하는 조직이나 회사에 매력적이다. 오라클에 의해 저장된 데이ㅓ는 효유성이나 프라이버시 때문에 오라클이 제공하는 원시 데이터가 아닐 가능성이 높다. 대학은 과거 학생들의 학업성적 증명서용 오라클을 만들 수 있다. 그러나 증명서의 전체 세부사항을 저장하는 것은 지나친 것이 될 수도 있다. 대신, 증명서의 해시를 저장하는 것만으로 충분하다. 마찬가지로, 예를들어 정부는 이더리우 플랫폼에 시민 ID를 넣고 싶을 수도 있다. 여기에 포함된 세부 정보는 분명 비공개로 유지해야 한다. 데이터를 해싱하고 스마트 계약의 저장소에 단지 루트 해시를 저장하는 것으로도 그러한 서비스를 효율적으로 구성할 수 있다.
게시구독
게시구독(publish-subscribe)형의 오라클은 정기적 혹은 잦은 변화가 예상되는 데이터를 효과적으로 브로드캐스트하는 역할을 하며, 이 데이터는 온체인 스마트 계약에 의해 폴링(polling)되거나 업데이트를 위한 오프체인 데몬에 의해 모니터링된다. 이 카테고리는 RSS 피드, WebSub 등과 유사한 패턴을 지닌다. 오라클은 새로운 정보로 업데이트되고, 플래그는 새로운 데이터를 쓸 수 있음을 구독 대상들에게 알린다. 데이터를 받는 쪽에서는 최신 정보가 변경되었는지 여부를 확인하기 위해 오라클을 폴링하거나 오라클 계약에 대한 업데이트 소식을 기다리다가 업데이트가 발생하면 필요한 조치를 수행한다.
예를 들어 가격 정보, 기상 정보, 경제 또는 사회 통계, 교통 정보 등이 있다. 폴링은 웹 서버 세계에서는 매우 비효율적이지만, 블록체인 플랫폼의 피투피 컨텍스트에서는 그렇지 않다. 예를 들어 이더리움 클라이언트는 컨트랙트 저장소 변경을 포함하여 모든 상태 변경사항을 알아야 하므로 데이터 변경사항에 대한 폴링은 동기화된 클라이언트에 대한 로컬 호출이다. 이더리움 이벤트 로그를 사용하면 애플리케이션에서 오라클 어데이트를 매우 쉽게 볼 수 있으므로 이 패턴은 어떤 면에서 푸시(push) 서비스로 간주할 수 있다. 그러나 폴링이 스마트 계약으로부터 수행되어야 하는 경우는 상당한 가스 비용이 발생할 수 있는데, 일부 탈중앙화된 애플리케이션에서 이러한 폴링이 필요할 수도 있다.
요청응답
요청응답(request-response) 카테고리는 가장 복잡하다. 이 유형으 스마트 계약에 저장하기에는 데이터 공간이 너무 크고, 사용자는 전체 데이터 중 한 번에 일부만 필요로 하는 경우에 사용된다. 또한 이것은 데이터 공급자 사업 영역에 적용 가능한 모델이기도 하다. 실용적인 측면에서 보자면, 오라클은 요청을 모니터링하고 데이터를 검색하고 반환하는 데 사용되는
같이 보기
