edenchain: the programmable economy platform james ......edenchain: the programmable economy...

EdenChain: The Programmable Economy Platform

James Ahn

Technical Whitepaper

Version 1.2



1

면책 조항(Disclaimer)

면책 조항을 다 읽기 전까지는 어떠한 행동도 취하지 마십시오. 본 문서는 EdenChain 의 연구

개발, 비지니스 사항 등에 대한 정보를 담고 있습니다.

만약 귀하가 어떤 의심이 있다면 법률, 금융, 세무 혹은 다른 전문가와 상의해야 하며,

EdenChain 개발에 기여하지 말아야 합니다.

EdenChain 의 기술 백서 및 홈페이지에 게시된 정보 등은 유가 증권이나 투자를 유치하기

위한 안내서나 권유서가 아닙니다. EdenChain 에서 발행하는 토큰은 그 어떤 관할권 내에서

통용되는 유가 증권이나 혹은 그에 상응하는 것이 아닙니다. 만약 귀하가 EdenChain 개발에

기여하기로 결정했다면, EdenChain 에 대한 귀하의 기부는 EdenChain 의 증권, 투자 단위 및

주식 등의 형태에 대한 암호화폐의 판매 또는 교환을 포함하지 않으며, EdenChain 토큰

보유자는 배당금 또는 기타 수익을 받지 않습니다.

미국의 법적 규제의 불확실성으로 인해 미국 거주자나 영주권자는 EdenChain 에 기부하고

토큰을 받을 수 없습니다. 만약 허위 정보를 제공해 EdenChain 에 기부한다면 이는 기금 모금

이용 약관을 위반하는 것이며, EdenChain 은 이들에게 보상을 요청할 수 있습니다. 이러한 위반

행위의 가능성이 있는 지역이라면 EdenChain 에서 제공하는 어떠한 형태의 정보, 예를 들어

홈페이지, 기술 백서 등을 다운로드 받거나 유통 또는 복사본을 만들어서는 안됩니다.

기술 백서에 나와 있는 정보는 규제 당국이 검토하거나 승인하지 않았습니다. 백서의 발행과

배포가 해당 법률의 규제 및 요구 사항을 준수했다는 것을 의미하지 않습니다.



2

해당 법률, 규정 및 규칙에서 허용하는 최대 범위 내에서 EdenChain 창업자, 팀 구성원 등은

EdenChain 프로젝트에 관련된 어떠한 종류의 간접적인, 우발적인 결과나 기타 손실에 대해

책임을 지지 않습니다.

이 문서에는 공개된 시장 조사 보고서, 산업 간행물의 정보와 EdenChain 내부에서의 조사,

연구 등으로 얻은 정보가 포함되어 있습니다. 이러한 정보는 일반적으로 신뢰성 있는 정보로

취급되지만, 정보의 정확성이나 신뢰성에 대한 완벽한 확신은 없습니다.

이 문서에 포함된 어떤 정보도 EdenChain 개발에 비지니스, 법률, 재정, 세금 관련된 조언으로

간주되어서는 안됩니다.

EdenChain 의 홈페이지, 백서 그리고 기타 문서들에 포함된 모든 정보는 모범 사례로

제시되며 기금 모금자의 이용약관에서 명시적으로 언급하지 않는 한 구속력이 없으며, 이를

수행하지 않습니다.

EdenChain 에서 제공하는 어떤 종류의 정보와 문서도 “면책사항”을 포함시키지 않고 복제,

배포할 수 없습니다.



3

요약

EdenChain 은 프로그래머블 이코노미 플랫폼(Programmable Economoy Platform) 기술로

모든 유무형의 가치를 자산화시키고, 거래할 수 있는 블록체인 플랫폼 기술이다. 블록체인

스마트 컨트랙트(Smart Contract)를 이용하면 자산 가치가 있는 유무형의 모든 것을 토큰으로

자산화(Tokenization) 시킬 수 있다. 자산화는 스마트 컨트랙트를 이용해 현실 경제와 가상

경제를 통합하여 새롭고 거대한 경제 시스템, 프로그래머블 이코노미를 탄생시킨다.

프로그래머블 이코노미는 1) 미들맨(Middle Man)이 없어 거래 비용을 낮추고, 2) 미들맨이

독점하던 이익을 공유할 수 있으며, 3) 유﹒무형물의 자산화를 통해 이전에 없었던 새로운 시장을

형성하고 많은 사람들에게 경제적 혜택이 돌아가 우리의 삶을 윤택하게 만들어 줄 것이다. 현재

블록체인 기술에서는 프로그래머블 이코노미를 실현하는 데 2 가지 주요 기술적 이슈가 있다. 1)

Performance, 2) No Secured Connectivity 이다. EdenChain 은 이러한 기술적 문제들을 해결해

프로그래머블 이코노미 구현에 필요한 구성요소들을 가지고 있다. Merkle Tree + Namespace 를

이용해 서로 다른 Namespace 의 트랜잭션을 병렬 실행하여 Performance 문제를 해결하고, E-

Oracle 기술을 이용해 외부 시스템 연동에 대한 신뢰와 안전성을 제공하고, MVT(Median Voter

Theorem)을 합의 알고리즘으로 채택해 외부 시스템과의 연동에서 발생할 수 있는 값의 선택

문제에 강인한 기능을 제공한다. ECC(Elliptic Curve Cryptography)-TC(Threshold

Cryptography)를 적용한 E-Protocol 은 모든 네트워크 데이터가 암호화되어 해커의 공격에

방어할 수 있는 강력한 매커니즘으로 작용한다. 원장 데이터의 합의 알고리즘은 PoET(Proof-of-

Elapsed-Time)을 사용해, 적은 컴퓨팅 리소스 사용으로 효율적인 Leader Election 이 가능하도록

설계되었다.



4

EdenChain 의 주요 프로그램들은 SGX Enclave 에서 실행되어 소프트웨어 공격과 하드웨어

공격을 무력화시켜 외부 시스템과의 연동 시 Secured Connectivity 를 한층 더 강화시킨다.

EdenChain 은 지진, 태풍 등의 자연재해나 해커의 대규모 공격에도 안전하게 서비스를

제공하기 위해 Global DNS, Multi-Datacenter 패턴 그리고 VPN(Virtual Private Network) Hub

기술을 사용한다. 전세계 주요 대륙별로 EdenChain Service Zone 을 운영해 어떠한 경우에도

서비스가 지속될 수 있다.

EdenChain 은 유무형의 가치가 있는 것들을 자산화시킬 수 있고, 트랜잭션을 빠르고 안전하고,

합리적 비용으로 실행할 수 있어 ICO(Initial Coin Offering), IoT, 공유경제, 게임, 금융 등 다양한

산업과 서비스에 적용할 수 있다.

키워드: blockchain, programmable economy, tokenization,smart contract, secured

connectivity



5

1. Introduction

1.1 A Programmable Economy

인터넷과 스마트폰, 빅데이터와 클라우드 그리고 인공지능 기술들은 우리 인류의 삶의 방식에

많은 영향을 주고 있다. 스마트폰과 같은 기술들은 우리 삶에 들어온 이후, 그 영향력과 적용

범위가 다양해져 이제는 필수불가결한 생활의 일부가 되어 버렸다. 블록체인 기술 역시 머지않아

우리의 삶 깊숙히 들어와 새로운 삶의 방식을 가져올 것이라고 믿어 의심치 않는다.

블록체인과 경제 시스템이 만나면 프로그래머블 이코노미(Programmable Economy)가

탄생한다. 프로그래머블 이코노미는 가치가 있는 유무형의 어떤 것을 블록체인 기술을 이용해

자산화시켜, 미들맨 없이 인터넷을 통해 자유롭게 거래하는 새로운 경제 시스템이다. 기존 경제

시스템에서는 미들맨이 구매자와 판매자가 거래를 안전하고 빠르게 이뤄질 수 있도록 서비스를

제공하고, 그에 대한 대가로 비용을 받는다. 이러한 경제 시스템에서는 일반 대중이 해당

네트워크에 참여할 수 없어 미들맨이 거래에서 발생하는 이익을 독점하고 있다. 프로그래머블

이코노미에서는 구매자와 판매자가 직접 연결하기 때문에 미들맨이 존재하지 않아 비용이

낮아지고, 기존 거래 프로세스보다 간단해진다. 더욱이 누구나 네트워크에 참여해 일정 부분

기여를 하면, 그에 상응하는 수익을 나누어 받을 수 있다.

프로그래머블 이코노미에서는 블록체인 기술로 자산의 성격을 가지고 있는 유무형의 모든

것들을 자산화(Tokenization)할 수 있고, 이를 블록체인에 등록해 소유권을 주장할 수 있고,

토큰으로 다른 사람과 거래할 수 있고, IoT 서비스를 이용해 거래를 자동화 시킬 수 있다.



6

Figure 1 Eden’s Programmable Economy

1.2 Tokenization (자산화)

Tokenization 은 어떤 유무형의 자산을 블록체인 토큰으로 변환하는 과정이다. (Cameron-Huff,

n.d.) 우리가 살고있는 세상에는 주식, 부동산, 쌀, 자동차, 금 등 수많은 종류의 자산들이

존재하고 있으며, 사람들은 자신의 목적에 의해, 사고 파는 거래 행위를 지속적으로 하고 있다.

기술이 발전함에 따라 저작권, 보험 증권, 그리고 각종 파생 금융 상품과 같이 이전과는 다른

형태의 자산들이 나타나기 시작했고, 어떤 자산들은 특정한 조건이 충족되면 가치를 지니는

특징을 가지고 있다.

블록체인 기술을 이용하면 기존의 자산을 블록체인 토큰으로 치환해 소유권을 등록할 수

있으며, 필요한 조건들을 스마트 컨트랙트로 명시해 자산의 특성에 맞춰 설계할 수 있다.



7

자산화는 기존의 가치있는 것을 토큰으로 만들어 낼 수도 있지만, 다른 자산들과의 조합으로

새로운 자산을 생성하는 것도 가능하다. 자산화는 게임 아이템, 신용카드 포인트, SNS 상의

자신의 영향력과 같은 무형의 것에 소유권을 부여하고, 가치를 매기며, 다른 사람과 거래할 수

있다.

Figure 2 Tokenization

1.3 Smart Contract

Nick Szabo 는 스마트 컨트랙트에 대해 다음과 같이 설명하였다.:

“A set of promises, specified in digital form, including protocols within which the parties

perform on these promises.” (Szabo, 1996)

간단히 설명하면, 계약을 프로그램으로 작성한 것으로 지정한 조건이 충족되면, 사람의

개입없이 자동으로 실행되는 “자동화된 거래규약”이라고 할 수 있다.

(Alliance, 2016)에서는 Szabo 의 스마트 컨트랙트 개념을 Model of Smart Contract,

Automation, Data Processing Protocol 그리고 Software Code 의 4 가지 요소로 구체화시켰고

스마트 컨트랙트를 총 6 단계로 이뤄지는 것으로 설명했다. :



8

1. Identify Agreement

2. Set Conditions

3. Code the Business Logic

4. Encrypt & Blockchain Technology

5. Execution & Processing

6. Network Updates

Bocconi University 의 Vincenzo Morabito 교수는 스마트 컨트랙트를 1) Deterministic, 2) Non-

deterministic 의 2 가지로 구분하였다. 1) Deterministic 스마트 컨트랙트은 실행할 때 외부로부터

어떠한 데이터도 없는 형태이고, 2) Non-deterministic 스마트 컨트랙트는 실행시 외부의

데이터가 필요한 형태이다 (Morabito, 2017).

Non-deterministic 스마트 컨트랙트는 블록체인 네트워크가 아닌 외부 시스템에서 데이터를

가져와야 하기 때문에 외부 데이터가 필요 없는 Deterministic 스마트 컨트랙트보다 안전성이

취약하다. 하지만 Non-deterministic 스마트 컨트랙트는 외부 시스템과 연동할 수 있어 다양한

형태의 스마트 컨트랙트를 작성할 수 있으며, 스마트 컨트랙트의 매우 중요한 요소인

자동화(Automation)를 실제 구현할 수 있다..



9

Figure 3 Smart Contract

1.3.1 Bitcoin Smart Contract

비트코인은 “Script”라는 이름의 프로그래밍 언어를 제공한다. Script 는 Forth 와 유사하게

bytecode stack-based 언어이고, 해킹 위험이 없는 Script 프로그램 실행을 담보하기 위해

의도적으로 loop, recursion 을 지원하지 않는 Turing-Incomplete 로 설계하였다. (Pablo Lamela

SeijasSimon, 2017)

Script 는 Stack manipulation, String Manipulation, Bitwise Manipulation, basic cryptographic

등 다양한 기능들을 지원한다. 하지만 Script 는 태생적으로 활용에 제약이 있을 수 밖에 없어

활용성이 좋지 않았다. 가장 대표적인 것은 비트코인 블록 사이즈 크기의 제약으로 인해 Script 의

최대 크기가 10,000 바이트 이하여야 하고 사용할 수 있는 Opcodes 의 수도 201 개로 제한되어

있다. (HardingDavid, 2015).



10

1.3.2 Ethereum Smart Contract

이더리움은 Turing-Complete 언어를 지원하기 때문에 Loop, Recursion 을 사용할 수 있어

비트코인의 Script 언어보다 한층 더 발전된 기술을 보여주었다.

Script 에서는 프로그램 실행을 의도적으로 지연시키거나, 오랜 시간이 소요되도록 하지

못하게 하기 위해 Loop, Recursion 을 금지하였는데 이더리움은 “Gas”라는 개념을 도입해 이

문제를 해결하였다. (WOODDR., 2017)

Gas 는 스마트 컨트랙트를 실행하기 위해 미리 이더리움의 암호화폐인 Ether 로 지불하는

것으로 일종의 사용료 개념으로 이해할 수 있다. 이더리움 스마트 컨트랙트에 작성된 연산을

실행할 때마다 미리 지불한 Gas 에서 일정 금액을 차감하는 방식으로 동작하기 때문에

고의적으로 실행을 지연시키거나 연산을 무한 반복시킬 수 없다.

이더리움 스마트 컨트랙트 언어의 재밌는 특징은 Reactive 특성을 가지고 있어, 스마트

컨트랙트 프로그램이 스스로 실행될 수 없고, 다른 트랜잭션에 의해서 실행될 수 있다는 점이다.

DoS Attack 을 피하기 위해 의도적으로 Reactive 특성을 가지도록 설계되었다.

이더리움에서 지원하는 언어로 작성한 스마트 컨트랙트는 EVM(Ethereum Virtual

Machine)에서 실행된다.

공개적 특성을 갖는 Permissionless 블록체인에서 누구나 스마트 컨트랙트를 작성하고, 등록할

수 있어 안전성을 담보할 수 없는 환경에서 스마트 컨트랙트를 실행하는 EVM 은 이더리움

네트워크 환경에서 격리되어 실행되며, 스마트 컨트랙트 실행시 문제가 발생하면, 실행하기

이전의 상태로 Rollback 시키며, 이미 사용한 Gas 는 반환하지 않는다.



11

1.3.3 NXT Smart Contract

NXT 는 1 세대 블록체인 기술로 Performance 와 Scalability 를 확보하기 위해 POS(Proof-of-

stake) 합의 알고리즘을 채택하였고, 클라이언트-서버 아키텍쳐로 설계되었으며 API 를 이용해

내외부 시스템과 연동한다.

NXT 는 비트코인, 이더리움과 다르게 스마트 컨트랙트를 NXT 에서 제공하는 API 를 이용해서

작성한다. NXT API 는 지불, 저장, 메시징, 거래 등 다양한 분야에 필요한 기본적인 기능들을

제공한다. 따라서 NXT 스마트 컨트랙트를 작성하기 위해서는, 일반적인 로직은 Javascript,

Python, Java 등과 같은 프로그래밍 언어를 사용해 작성하고, 블록체인에 데이터를 입력, 삭제,

업데이트 등의 작업은 NXT API 를 사용한다.

NXT 에서 작성할 수 있는 스마트 컨트랙트의 종류와 기능은 제공되는 API 의 종류와 내용에

달려있기 때문에 이더리움과 같이 언어 기반의 스마트 컨트랙트를 지원하는 다른 블록체인

기술보다 제한적이다.

2.Technical Motivation

스마트 컨트랙트는 프로그래머블 이코노미에 있어 핵심적인 요소이다. 왜냐하면 자산화가

스마트 컨트랙트를 통해 실현되기 때문이다. 스마트 컨트랙트는 거래를 처리하기 때문에

해커들의 공격이나 오용, 변조 등에 대항하여 방어할 수 있어야 하며, 처리 속도도 빨라야 한다.

(KONSTANTINOS CHRISTIDIS, 2016)는 스마트 컨트랙트를 완벽한 예측이

가능한 Autonomous Actor 라고 설명했으며, 이를 통해 신뢰할 수 있는 트랜잭션 처리가

가능하다고 이야기했다.



12

(Maher AlharbyAad, 2017)에서는 스마트 컨트랙트에 의해 발생할 수 있는 이슈들을 1)

Codifying Issue, 2) Security Issue, 3) Privacy Issue, 4) Performance Issue 의 4 가지로 구분하여

설명하였다.

Codifying Issue 는 완전무결한 스마트 컨트랙트를 작성하는 것이 어렵다는 것을 설명하는

것이고, Security Issue 는 스마트 컨트랙트 자체의 버그나 약점을 이용한 공격에 연관된 것이고,

Performance 는 스마트 컨트랙트를 실행하는 블록체인의 Scalability 에 따라 발생하는 문제를,

마지막으로 Privacy Issue 는 스마트 컨트랙트의 내용이 모두에게 공개됨에 따라 발생하는

문제를 설명한다.

스마트 컨트랙트가 Trusted Autonomous Actor 로 활용되기 위해서는 해결해야 할 몇 가지

기술적 이슈들이 있으며, 이러한 이슈들이 해결될 때 스마트 컨트랙트가 진정한 의미의 스마트

컨트랙트로 프로그래머블 이코노미의 다양한 분야에 활용될 수 있다.

2.1 Technical Issues

프로그래머블 이코노미 구현에 2 가지 주요 기술적 이슈가 있다. 처리 속도와 보안성이다.

처리 속도는 시급하게 해결되어야 할 문제로 현재의 블록체인 처리 기술은 실제 서비스에 연동해

사용하기에는 어려움이 많다. 또한 블록체인이 활성화될 수도록 외부 서비스와의 연동이 많은데,

인터넷을 이용하기 때문에 무방비로 노출되어 해커의 공격에 취약하다.

2.2 Performance & Scalability

비트코인, 이더리움의 블록체인 기술에서 가장 많이 논의되는 기술적 이슈 중의 하나는

Performance 와 Scalability 에 대한 것이다. (Ehrsam, 2017)에 의하면, 페이스북은 초당 157,000



13

Requets 를 처리할 수 있고, 이더리움은 초당 13 Transaction 을 처리할 수 있으며, 스마트

컨트랙트를 이용한 Token 의 경우에는 초당 7 Transaction 을 처리할 수 있다고 한다. 아울러

Performance 와 Scalability 가 블록체인 업계에 가장 주요한 문제가 될 것이라고 얘기한다.

블록체인 기술이 활성화되려면 Performance 와 Scalability 에 관련된 기술적 문제들은 반드시

해결되어야 하며, 일반적인 블록체인 트랜잭션보다 훨씬 더 많은 연산을 필요로 하는 스마트

컨트랙트에 있어서는 더욱 중요한 이슈이다.

예를 들어 스마트 컨트랙트가 외부 시스템과 연동된다면, 스마트 컨트랙트의 느린 처리로

블록체인 자체가 병목 지점이 되어 전체 시스템의 Performance 와 Scalability 를 저하시키고,

시스템 응답성을 심각하게 훼손시켜 사용자들의 외면을 받을 수 있다.

현재보다 블록체인이 활성화되어 블록체인에서 처리되는 트랜잭션의 수가 증가하고, 스마트

컨트랙트의 활용이 증가할수록 Performance & Scalability 문제는 더욱 심각해질 수 있다.

Figure 4 TPS Performance

2.3 Lack of Secured Connectivity

경제학자 Mark Flood 는 자신의 논문 서두에 금융 네트워크(Financial Network)는 각각의

꼭지점들이 서로 연결된 Edge 이고, 이들 Edge 를 연결하는 것이 스마트 컨트랙트라는 점을

이해하는 것이 중요하다고 이야기했다. (Mark FloodOliver, 2017) 서로 다른 시스템들은



14

연결되기 위한 방법 그리고 조건들을 하나의 잘 정제된 무엇으로 만들고, 실행시킬 수 있는

수단이 필요하다.

스마트 컨트랙트가 이러한 역할을 수행해 보다 풍성한 응용 서비스들을 만들고, 더 나아가

프로그래머블 이코노미를 실현하기 위해서는 외부 시스템과의 연동할 수 있는 특성, Secured

Connectivity 가 요구된다.

Figure 5 Lack of Secured Connectivity

예를 들어 화물 주인이 화물차 기사와 화물 A 를 위치 B 로 옮겨주면, 화물차에 부착된 GPS

정보를 확인해 비용을 지불하는 스마트 컨트랙트를 작성했다고 가정해보자.

스마트 컨트랙트가 실행되기 위해서는 일정 시간 간격으로 화물차에 부착된 GPS 정보가

스마트 컨트랙트가 저장되어 있는 블록체인으로 전달되어야만 스마트 컨트랙트가 실행되어

화물차 기사가 약속된 비용을 지급받을 수 있다. 즉 스마트 컨트랙트에 외부 시스템과 안전하게



15

연동할 수 있는 시스템 연동이 확보되어야만 원래의 스마트 컨트랙트가 약속하는 여러가지

이점들을 제공할 수 있다. 스마트 컨트랙트가 계약을 자동 처리하기 위해서는 다양한 외부

시스템과 연동할 수 있어야 한다. 중요한 포인트는 시스템 연동이 단순히 외부 시스템과의

연동을 의미하는 것만 아니라, 외부 시스템과의 연동에 대해 안정성을 보장해야 한다는 점이다.

이더리움은 Oracle 을 제공해 외부 시스템과의 연동을 허용할 수 있는 방법을 제공하고 있지만,

외부 시스템에서 가져온 데이터에 대한 안전성은 보장하지 않는다. (Maher Alharby, 2017)

Secured Connectivity 는 스마트 컨트랙트와 외부 시스템과의 연동에 있어 발생할 수 있는

여러가지 해커의 공격을 방어하고, 안정성을 담보해준다.

Secured Connectivity 는 스마트 컨트랙트의 확장성과 자동화를 위해 반드시 해결되어야 하는

중요한 기술적 이슈지만 비트코인, 이더리움 등의 블록체인 기술에서 제공하지 않는다.

3.Eden: The Programmable Economy Platform

3.1 Introduction to Eden

Edenchain 은 프로그래머블 이코노미 플랫폼으로 앞서 언급한 기술적 이슈들을 보완해 보다

고성능의 처리속도를 보여주고, 안정적으로 동작하며, 외부 시스템과의 신뢰할 수 있는 연동으로

스마트 컨트랙트 기반의 다양하고 자동화된 서비스를 개발할 수 있는 블록체인 기술이다.



16

프로그래머블 이코노미 구현 핵심 기술인 스마트 컨트랙트는 On-chain 에서만 동작하는

Deterministic 스마트 컨트랙트보다 Off-chain 과의 연동을 필요로 하는 Non-deterministic 스마트

컨트랙트가 더욱 큰 기술적, 경제적 가치를 가지고 있다.

비트코인, 이더리움과 같은 기존 블록체인 기술들은 Non-deterministic 스마트 컨트랙트에서

요구되는 외부 시스템과의 연동에 대한 신뢰를 보장하지 않아 해커 공격에 노출되어 있어

안전하지 못하다. EdenChain 은 E-Bridge Layer 를 통해, Non-deterministic 스마트 컨트랙트가

외부 시스템과 연동할 때, 여러 개의 데이터 소스로부터 데이터를 가져오고, 암호화된 통신

그리고 MVT(Median Voter Theorem)를 이용한 데이터 선택 알고리즘으로 데이터의 신뢰를

확보하고, 해커의 공격을 방어한다.

스마트 컨트랙트를 실행하는 데 있어 Performance 는 빼놓을 수 없는 매우 중요한 기술적

이슈이다. EdenChain 은 Merkle Tree 에 Namespace 를 결합해, 트랜잭션을 Namespace 별로

분리 처리해, 한번에 하나의 트랜잭션을 처리하지 않고, Namespace 별로 병렬 처리 가능한

Execution System 을 구축해 Performance 와 Scalability 를 확보한다.

EdenChain 은 이더리움의 EVM 을 포함해 현 시점에서 가장 인기있는 스마트 컨트랙트

언어인 Solidity 를 지원한다. 스마트 컨트랙트는 지불 및 결제 같은 민감한 서비스에 많이

활용되기 때문에 이를 쉽게 작성할 수 있는 새로운 형식의 프로그래밍 언어보다는 안정적이고,

신뢰할 수 있는 안정적인 스마트 컨트랙트 프로그래밍 언어가 더욱 중요하다. 새로운 형식의

언어가 출현해 테스트와 검증을 통해 안정성을 인정받기는 오랜 시간이 걸리며, 검증 기간동안

해커의 공격으로 심각한 보안 문제가 노출되고, 많은 사람들에게 피해를 줄 수 있다.

EdenChain 에서는 “Don’t reinvent the wheel”의 원칙에 따라 검증과 개선이 많이 이루어진

EVM 과 Solidity 를 EdenChain 에 포함해 블록체인을 구성한다.



17

EdenChain 은 Secured Connectivity 를 보장하기 때문에 인터넷을 이용해 다양한 블록체인

기반의 자산들을 거래하는 프로그래머블 이코노미를 실현할 수 있다. 어떠한 유무형의

자산이라도 스마트 컨트랙트로 Tokenization 을 실시하면, 해당 자산의 소유권을 공개적으로

증명할 수 있고, 이것을 거래소에서 혹은 P2P 거래 등으로 사고 팔 수 있다.

3.2 Architecture

Figure 6 Eden Architecture

Edenchain 은 크게 Distributed Ledger Layer, Validation Layer, 그리고 Bridge Layer 의 3 개

레이어로 구성된 Permissioned 블록체인이다. Distributed Ledger Layer 는 데이터를 저장하는

곳으로 블록체인에서 사용하는 데이터들이 분산되어 저장되어 있으며, Validation Layer 에서

합의된 정상적인 Transaction 들의 데이터들만 처리된다. Distributed Ledger 의 데이터는

트랜잭션을 통해 추가할 수 있다.

Validation Layer 는 트랜잭션을 실행하고, 검증하는 곳으로, 스마트 컨트랙트를 실행하는

EVM 을 포함하고 있다. Validation Layer 는 Transaction Scheduling 기능을 가지고 있어

EdenChain 의 Performance 와 Scalability 에 중요한 영향을 미친다.



18

Bridge Layer 는 블록체인 내부에서 실행되는(On-chain) 스마트 컨트랙트가 필요로 하는

데이터를 외부(Off-chain)와 연동해 안전하게 가져오는 역할을 한다. Bridge Layer 는 특성상

노드들이 On-chain 과 Off-chain 에 걸쳐 존재하며, 이들 노드들 간의 신뢰할 수 있는 통신을 위해

암호화 기법인 ECC-TC 를 활용한 E-Protocol 을 사용한다.

3.3 Permissioned Blockchain

Permissioned Blockchain 은 비트코인, 이더리움과 같은 누구나 네트워크에 참여할 수

있는 Permissionless 블록체인 기술의 대안으로 발전해왔다. Permissioned Blockchain 기술은

네트워크에 참여하기 위해서 인증 등의 과정을 통해 해당 네트워크 관리자로부터 참여 허가를

받아야 한다.

Kadena, Tendermint, Chain 등 새롭게 등장한 블록체인 기술들은 Permissioned 네트워크를

채택했으며, 리눅스파운데이션의 블록체인 오픈소스 프로젝트인 Hyperledger 도 Permissioned

Blockchain 기술을 채택하였다.

Edenchain 은 Permissioned Blockchain 으로 구성해 스마트 컨트랙트를 신뢰할 수 있는

환경(Trusted Environment)에서 빠르고 효율적으로 실행할 수 있다.

이더리움과 같은 Permissionless Blockchain Network 에서는 스마트 컨트랙트가 모든 Full

Node 에서 실행된다. 이런 방식은 2 가지 중요한 문제를 야기한다. 첫 번째는 Performance

문제이다. 모든 스마트 컨트랙트는 블록체인 네트워크 내의 EVM 에 저장되어 있고, 조건에 따라

실행되는데, 만약 이더리움 블록체인 내에 존재하는 스마트 컨트랙트의 수가 1,000,000 개 혹은

100,000,000 개가 된다고 하면 심각한 Performance 문제가 발생할 수 있고, Full Node 를

운영하는 채굴자 입장에서는 자신에게 많은 이익이 돌아오는 즉, Gas 가 높은 것들을 우선적으로

실행하게 되어, 모든 스마트 컨트랙트가 실행되지 않을 수도 있다.



19

두번째는 효율성에 대한 이슈이다. 모든 Full Node 에서 스마트 컨트랙트를 개별적으로

실행한다는 것은 Permissionless Blockchain 기술의 철학에 기반한 것이기는 하지만 스마트

컨트랙트를 항상 모든 노드에서 개별적으로 실행하고 검증하는 이와 같은 동작 방식은

효율적이라 생각되지 않는다.

Edenchain 은 Permissioned Blockchain 으로 스마트 컨트랙트 실행을 위한 신뢰할 수 있는

환경을 구성하고, 실행해 안전성을 확보하고, Namespace 에 따른 일정 수의 노드를 사용해

효율성을 증대시키며, 모든 트랜잭션의 처리를 100% 담보한다.

Figure 7 100% Transaction Guarantee

3.3.1 Block Withholding

Kyber Network 의 CEO 인 Loi Luu 가 Block Withholding 이라는 부정행위 기법과 위험성에

대해 설명한 바 있다(Loi Luu, 2015). Block Withholding 은 POW 합의 알고리즘에서 채굴자가

문제에 대한 해답을 찾았을 때, 그 해답을 채굴자 그룹(Mining Pool)에 공개하지 않고 계속 가지고

있어, 해당 채굴자 그룹이 인센티브를 받지 못하도록 하는 공격 기법이다. 이 기법은 어떤 채굴자

그룹에서 다른 채굴자 그룹을 공격할 때 효과적으로 사용할 수 있다. 예를 들어 A 채굴자

그룹에서 새롭게 형성된 B 채굴자 그룹을 공격하고 싶다면, 성능이 좋은 컴퓨터를 선별해 B

채굴자 그룹에 침투시키고, Block Withholding 공격을 한다. B 채굴자 그룹의 멤버들은 계속해서

인센티브를 받지 못하기 때문에 해당 채굴자 그룹에 참여하는 동기가 약해지고, 결국 B 채굴자

그룹은 와해된다.



20

Block Withholding 공격은 비트코인 포럼과 최근의 논문들에서 확인되고 있다. (ckolivas, 날짜

정보 없음) (Eyal, 2015)

EdenChain 은 Permissioned 블록체인으로 운영해, 공정하고 안정적으로 시스템을 운영한다.

EdenChain 의 목적은 채굴을 통한 인센티브의 확보가 아니라 프로그래머블 이코노미를

창발시키는 것이고, 그렇게 하기 위해서는 EdenChain 에 대한 대중들의 신뢰가 필수적이기

때문에 어떠한 부정행위 없이 시스템을 투명하게 운영한다.

3.4 High Availability

EdenChain 은 Permissioned Blockchain 이기 때문에 서비스 가용성(Service Availability)에

대한 고려가 필요하다. 왜냐하면 EdenChain 서버는 소수의 허가받은 기관이나 회사가

운영하는데, 이들 서버에 대규모 해커의 공격이 들어오거나 지진이나 화재 등의 재해가

발생한다면 서버 운영이 중지되고, 이는 곧 EdenChain 서비스의 중지를 의미하기 때문이다.

EdenChain 은 전세계의 사용자와 다수의 사업자들에게 서비스를 제공하기 때문에 어떠한

경우에도 서비스가 지속될 수 있도록 시스템을 설계 및 운영해야 한다. 고가용성(High

Availability)을 보장할 수 있어야 한다.

EdenChain 은 고가용성을 보장하기 위해 클라우드 서비스를 활용하고, Global DNS 와 Load

Balancer 를 이용한 Multi-Datacenter Pattern 으로 EdenChain 시스템을 운영한다. EdenChain

서비스를 제공하는 동일한 시스템을 아시아, 미국, 유럽 등 전세계 주요 대륙에 각각의 Service

Zone 으로 구성하고 운영해, 해커의 공격이나 자연재해에도 안정적인 서비스를 제공할 수 있다.



21

대륙별로 배치된 Service Zone 사이의 네트워크는 VPN(Virtual Private Network)으로

구성한다. 클라우드 서비스에서 제공하는 대륙별 데이터 센터 간에는 고속 전용선으로 연결되어

빠른 네트워킹이 가능하고 데이터 센터 간의 시스템 구축이 가능하다.

Multi-Datacenter Pattern 은 클라우드 서비스 사업자인 아마존에서 제공하는 패턴으로,

Apache 재단, Netflix, CloudFoundry, Attlasian 등 많은 인터넷 업체에서 사용하고 있으며, MS

Azure 에서도 추천하는 운영 설계 방법이다. (CloudDesignPattern, 2012) (Microsoft, 2017)

(Ruslan Meshenberg, 2013)

그림 8 은 Multi-Datacenter Pattern 과 VPN 을 적용한 EdenChain 운영 시스템 구성도이다.

Global DNS 외부의 데이터 요청을 받아 적절한 Service Zone 으로 연결해주는 역할을 하며,

복수 개의 Global DNS 서버들을 운영해 가용성을 확보한다. 모든 서비스의 Endpoint 는 Global

DNS 가 되도록 설계하고 운영한다.

Load Balancer 는 Global DNS 에서 전달된 요청을 실제 처리할 EdenChain 서버들에게

전달한다. Load Balancer 는 단순히 Request Routing 역할 뿐만 아니라 각 서버들의 상태 정보도

같이 수집해, Round-robin 보다 더 지능적인 서비스 운영을 할 수 있고, 특정 서버에 문제가

발생했는지 비교적 정확하게 파악할 수 있으며, 각 서버들의 Workload 를 모니터링해 Capacity

Planning 에도 활용할 수 있다.

EdenChain 에서 운영되는 서버들은 Operational Firewall 로 보호한다. Operational Firewall 은

EdenChain 서버들을 기능 그룹으로 정리하고, 각 정리된 기능 그룹별로 Firewall 정책을

적용하는 방식이다. Operational Firewall 은 기능별로 잘 추상화된 보안 정책을 적용할 수 있어

보안 정책을 유연하게 설계할 수 있으며, 그룹 단위로 적용하고 통합 관리 할 수 있고, 사용자의

설정 작업 실수를 최소화시킬 수 있다.



22

여러 Service Zone 간에 VPN 을 Full Mesh Topology 형으로 구축하면 Service Zone 이 늘어날

수록 각각의 VPN 설정이 복잡해져 성능과 관리 문제가 발생한다.

EdenChain 운영 시스템은 VPN 을 Star Topology 로 구성해 Service Zone 의 VPN Router 는

모든 Service Zone 에 연결하지 않고, VPN Gateway 에 접속해 다른 Service Zone 과 VPN

네트워킹을 할 수 있다.

3.4 High Availability

EdenChain 은 Permissioned Blockchain 이기 때문에 서비스 가용성(Service Availability)에

대한 고려가 필요하다. 왜냐하면 EdenChain 서버는 소수의 허가받은 기관이나 회사가

운영하는데, 이들 서버에 대규모 해커의 공격이 들어오거나 지진이나 화재 등의 재해가

발생한다면 서버 운영이 중지되고, 이는 곧 EdenChain 서비스의 중지를 의미하기 때문이다.

EdenChain 은 전세계의 사용자와 다수의 사업자들에게 서비스를 제공하기 때문에 어떠한

경우에도 서비스가 지속될 수 있도록 시스템을 설계 및 운영해야 한다. 고가용성(High

Availability)을 보장할 수 있어야 한다.

EdenChain 은 고가용성을 보장하기 위해 클라우드 서비스를 활용하고, Global DNS 와 Load

Balancer 를 이용한 Multi-Datacenter Pattern 으로 EdenChain 시스템을 운영한다. EdenChain

서비스를 제공하는 동일한 시스템을 아시아, 미국, 유럽 등 전세계 주요 대륙에 각각의 Service

Zone 으로 구성하고 운영해, 해커의 공격이나 자연재해에도 안정적인 서비스를 제공할 수 있다.

대륙별로 배치된 Service Zone 사이의 네트워크는 VPN(Virtual Private Network)으로

구성한다. 클라우드 서비스에서 제공하는 대륙별 데이터 센터 간에는 고속 전용선으로 연결되어

빠른 네트워킹이 가능하고 데이터 센터 간의 시스템 구축이 가능하다.



23

Multi-Datacenter Pattern 은 클라우드 서비스 사업자인 아마존에서 제공하는 패턴으로,

Apache 재단, Netflix, CloudFoundry, Attlasian 등 많은 인터넷 업체에서 사용하고 있으며, MS

Azure 에서도 추천하는 운영 설계 방법이다. (CloudDesignPattern, 2012) (Microsoft, 2017)

(Ruslan Meshenberg, 2013)

Figure 8 Eden System Operation for High Availability

그림 8 은 Multi-Datacenter Pattern 과 VPN 을 적용한 EdenChain 운영 시스템 구성도이다.

Global DNS 외부의 데이터 요청을 받아 적절한 Service Zone 으로 연결해주는 역할을 하며,

복수 개의 Global DNS 서버들을 운영해 가용성을 확보한다. 모든 서비스의 Endpoint 는 Global

DNS 가 되도록 설계하고 운영한다.



24

Load Balancer 는 Global DNS 에서 전달된 요청을 실제 처리할 EdenChain 서버들에게

전달한다. Load Balancer 는 단순히 Request Routing 역할 뿐만 아니라 각 서버들의 상태 정보도

같이 수집해, Round-robin 보다 더 지능적인 서비스 운영을 할 수 있고, 특정 서버에 문제가

발생했는지 비교적 정확하게 파악할 수 있으며, 각 서버들의 Workload 를 모니터링해 Capacity

Planning 에도 활용할 수 있다.

EdenChain 에서 운영되는 서버들은 Operational Firewall 로 보호한다. Operational Firewall 은

EdenChain 서버들을 기능 그룹으로 정리하고, 각 정리된 기능 그룹별로 Firewall 정책을

적용하는 방식이다. Operational Firewall 은 기능별로 잘 추상화된 보안 정책을 적용할 수 있어

보안 정책을 유연하게 설계할 수 있으며, 그룹 단위로 적용하고 통합 관리 할 수 있고, 사용자의

설정 작업 실수를 최소화시킬 수 있다.

여러 Service Zone 간에 VPN 을 Full Mesh Topology 형으로 구축하면 Service Zone 이 늘어날

수록 각각의 VPN 설정이 복잡해져 성능과 관리 문제가 발생한다.

EdenChain 운영 시스템은 VPN 을 Star Topology 로 구성해 Service Zone 의 VPN Router 는

모든 Service Zone 에 연결하지 않고, VPN Gateway 에 접속해 다른 Service Zone 과 VPN

네트워킹을 할 수 있다.

3.5 Proof-of-Elapsed-Time (PoET)

합의 알고리즘은 블록체인 기술에서 중요한 역할을 하는 것으로 크게 2 가지 접근 방법이

존재한다. 첫 번째는 “Nakamoto Consensus”로 일종의 Lottery 과정을 통해 Leader Selection 을

실시하는 방법이다. Leader 로 선정되면 이전의 블록을 인증하고, 새로운 블록을 생성할 수 있는

권리를 갖게 된다. 비트코인의 경우에는 Hash Puzzle 을 가정 먼저 해결하는 노드가 Leader 로



25

선정된다. 두번째는 “BFT(Byzantine Fault Tolerance)”를 이용한 방법이다. 이 방법은 Leader 를

선정하지 않고, 여러 단계의 투표 과정을 통해 최종 합의를 이뤄내는 방식이다.

EdenChain 은 합의 알고리즘으로 PoET 를 사용한다. PoET 는 “Nakamoto Consensus”

방식으로, CPU 명령을 이용해 비트코인과 같이 해쉬 문제를 풀기 위해 막대한 에너지를

사용하지 않고 무작위로 Leader 를 선출하는 합의 알고리즘이다.

PoET 는 다른 Leader Selection 알고리즘에서 사용하는 것과 유사한 확률로 블록체인

네트워크에 참여하는 모든 노드들에게 블록 생성 권한을 가지는 Leader 가 될 수 있는 기회를

제공한다. (Foundation, 2017) PoET 는 SGX Enclave 에서 실행해 해커의 공격을 방어해,

안전하게 Leader Selection 프로세스가 진행될 수 있도록 한다. PoET 는 각 노드에서 SGX

Enclave 에서 CPU 명령을 이용해 Exponential Distribution 을 따르는 Wait Time 을 난수로 얻고,

가장 작은 Wait Time 을 갖는 노드를 Leader 로 선출한다.

Figure 8 PoET

PoET 는 다음과 같은 지수 분포를 따르며, 사건이 독립적이라면 일정 시간동안 발생하는

횟수가 단위 시간 안에 어떤 사건이 몇 번 발생할 것인지를 표현하는 이산 확률 분포의 일종인

푸아송 분포를 따르도록 설계되었다.



26

( )

3.6 Distributed Ledger Layer (DLL)

Distributed Ledger Layer 는 EdenChain 에 탈중앙화된 데이터베이스 기능을 제공하며 리눅스

재단의 오픈소스 프로젝트인 Hyperledger 를 기반으로 사용한다.

DLL 은 EdenChain 에서 발생하는 모든 데이터를 블록으로 저장하며 데이터의 수정은

불가능하며, 추가만이 가능하다. DLL 은 디스크 장치에 데이터를 저장하며 저장된 데이터는 모두

적법한 트랜잭션으로부터 발생한 것으로 간주한다. DLL 은 외부에서 필요한 데이터를 블록 ID 나

트랜잭션 ID 를 이용해 찾을 수 있으며, 반대로 블록에 포함된 모든 트랜잭션에 대한 정보도

액세스할 수 있는 기능을 제공한다.

DLL 에는 BlockCache 모듈을 가지고 있어 디스크 액세스를 최소화시킨다.

BlockCache 는 현재 사용하고 있는 블록들을 위주로 메모리에 저장하고 있으며, 요청 받은

블록을 찾을 수 없을 때, 디스크에서 해당 블록을 읽어와 메모리에 로딩한다. 사용 빈도에 따라

메모리에 계속 가지고 있을 블록과 그렇지 않은 블록을 결정해 최적의 메모리 사용으로 캐쉬

효과를 볼 수 있다.

3.7 Software Connector

소프트웨어 시스템 연구원 Xiwei Xu 은 블록체인 기술을 일종의 소프트웨어 커넥터(Software

Connector)로 활용하는 방안을 제안하였다.(Xiwei Xu, 2016) 이러한 시각은 소프트웨어

아키텍쳐의 품질을 향상시킬 수 있고, Information transparency 와 traceability 를 강화시킬 수

있다. 또한 블록체인에 저장할 수 있는 데이터 크기가 한정적인 만큼 어떤 정보를 블록체인에



27

저장하고(On-chain), 어떤 것들을 블록체인이 아닌 곳에(Off-chain) 저장할지를 결정하는 것도

아키텍쳐 설계상의 중요한 문제이다.

Edenchain 은 발생하는 각종 트랜잭션에 대한 정보를 저장하는 Distributed Ledger Layer 를

소프트웨어 커넥터로 간주해 전체 아키텍쳐를 설계했다. 소프트웨어 커넥터에 정의된

인터페이스만 지켜진다면 어떤 모듈이라도 Distributed Ledger Layer 와 연동할 수 있다.

소프트웨어 커넥터는 소프트웨웨어 모듈 간의 상호 연동을 위한 일종의 미들웨어 컴포넌트로,

분산 환경에서는 필수적인 요소로 작용해 Performance, Reliability, Security 등에 영향을 미친다.

Hyperledger 는 Modular Design 을 채택해 설계자의 목적과 필요에 따라 제공되는 기능을

자신의 시스템에 쉽게 연동시킬 수 있어 전체 아키텍쳐 설계에서 Distributed Ledger 기능을

소프트웨어 커넥터로 활용하는 것이 용이하다.

.

Figure 10 Blockchain as a Software Connector

3.8 Execution Layer (EL)

EL 은 트랜잭션을 실행, 처리하고 검증하는 레이어로 EdenChain 의 강점인 스마트

컨트랙트에 중요한 기능을 제공한다.

EdenChain 의 Distributed Ledger 에 데이터를 업데이트하기 위해서는 트랜잭션을 사용해야

하는데 EL 은 TEE(Trusted Execution Environment)를 제공해 해당 트랜잭션이 해커 공격에 의한



28

데이터 탈취나, 데이터 위변조 등으로부터 안전하게 방어할 수 있는 환경을 제공한다. 스마트

컨트랙트를 포함한 모든 트랜잭션과 주요한 로직들은 TEE 에서 실행된다.

EL 은 TES(Transaction Execution Scheduling)을 가지고 있어 트랜잭션이 어느 노드에서 어떤

방식으로 실행될지를 지정한다. TES 는 Performance 에 영향을 미치는 중요한 기술 요소로,

처리해야 하는 트랜잭션들을 어떻게 관리하고 실행하느냐에 따라 동일한 컴퓨팅 자원으로 다른

처리 성능을 보여줄 수 있다.

TES 는 Solidity 로 작성된 스마트 컨트랙트를 실행하기 위해 이더리움의 EVM 을 포함하고

있다. 실행되는 트랜잭션이 Solidity 와 같은 이더리움에서 실행되는 스마트 컨트랙트이면, EL 은

EVM 을 실행시킨다.

3.9 Ethereum Virtual Machine (EVM)

현 시점에서 이더리움의 스마트 컨트랙트는 많은 사용자를 확보하고 있으며, 여러 블록체인

프로젝트에 사용되어 안정성과 기능을 검증 받고 있다.

Edenchain 은 스마트 컨트랙트를 위한 새로운 언어나 시스템을 개발하기 보다는 검증된

이더리움의 EVM 을 사용하고, EVM 을 Edenchain Permissioned Blockchain 에서 활용해

EdenChain 스마트 컨트랙트에 대한 접근성을 낮추고, 다양한 스마트 컨트랙트를 작성할 수

있도록 한다.

3.10 Bridge Layer (BL)

BL 은 Edenchain 을 다른 블록체인과 차별화시켜 주는 중요한 기술적 요소로, On-chain 과

Off-chain 간의 Zero-Knowledge Trusted Connectivity 를 담보해준다.



29

이더리움에서는 Oracle 을 이용해 스마트 컨트랙트가 외부 시스템과 연동을 할 수 있지만,

외부로부터 연동된 데이터에 대한 신뢰를 보장하지 않는다. 스마트 컨트랙트 기반의

프로그래머블 이코노미를 실현하기 위해서는 블록체인과 외부 시스템이 해커의 위협으로부터

안전하게 연동할 수 있는 Trusted Connectivity 를 확보해야한다. Trusted Connectivity 를

확보해야만 외부 시스템과의 연동으로 기능을 확장하고, 여러가지 서비스들을 자동화시킬 수

있다.

BL 은 스마트 컨트랙트와 연동을 위한 1) On-chain 모듈과, 2) 외부 시스템 연동을 위한 Off-

chain 모듈 그리고 3) On-chain 과 Off-chain 연동과 네트워킹을 위한 모듈로 구성되어 있다.

On-chain 모듈은 스마트 컨트랙트에서 필요한 외부 데이터 요청할 때 대응하기 위한 기능들로

일종의 게이트웨이 역할을 한다. Off-chain 모듈은 On-chain 모듈에서 요청한 데이터를 실제 외부

시스템에 접속해 가져오고, 데이터들을 검증해 특정 값을 선택해 On-chain 에 전달한다.

On-chain 과 Off-chain 은 서로 다른 네트워크에 위치하기 때문에 해커의 공격으로부터

안전하게 데이터를 주고 받기 위한 네트워크를 구성해 통신한다.

3.11 Transaction Execution Scheduling (TES)

EdenChain 의 클라이언트는 트랜잭션을 통해 DL 에 데이터를 업데이트할 수 있다. 스마트

컨트랙트의 실행 역시 트랜잭션을 통해 가능하다.

EdenChain 은 트랜잭션을 그룹화하는 단위로 Batch 와 Block 을 사용한다. 트랜잭션들이 모여

Batch 를 구성하고 Batch 가 모여 Block 을 구성한다.

EL 에서는 Block 단위로 트랜잭션을 처리한다.



30

Figure 11 Transaction, Batch, and Block

트랜잭션을 Batch 로 그룹화해서 처리하면 스마트 컨트랙트에서 발생할 수 있는 트랜잭션들

간의 Dependency 문제를 쉽게 처리할 수 있다. 같은 Batch 안에 존재하는 트랜잭션들은 서로

연관 관계가 있다고 가정하고, 특정 트랜잭션 실행시 문제가 발생하면, 다른 트랜잭션들을

무효화 처리 할 수 있다.

예를 들어 트랜잭션 A 에서 트랜잭션 B, 그리고 트랜잭션 C 를 발생시켰다면, 트랜잭션

A,B,C 는 서로 연관 관계를 가지고 있으며, A,B,C 가 모두 성공적으로 실행되어야만 정상적인

처리가 완료된 것으로 간주할 수 있다. 이때 트랜잭션 A,B,C 를 Batch 로 그룹화시키면 A,B,C 중

에러가 발생하면, A,B,C 의 실행 순서나 상관 관계등을 고려하지 않고 해당 Batch 내에 포함된

트랜잭션을 모두 무효화시킬 수 있어 Dependency 문제를 쉽게 해결 할 수 있다.

3.12 Transaction Data Structure

트랜잭션은 Transaction Body 와 Transaction Header 로 구성되며 다음과 같은 데이터 필드를

포함하고 있다. :



31

Field Description

Public Key Client’s Public key

Dependency Transaction Data with Dependency

Namespace A Namespace for Differentiating between Transactions

Nonce Random Data for Differentiating between Transactions

Figure 9 Transaction Header

Field Description

Header Transaction header Data

Header_Signature Signature Data

Payload Payload Data

Figure 10 Transaction Body



32

여타의 블록체인 기술과 마찬가지로 EdenChain 에서도 트랜잭션에는 Client 의 Public key 를

이용해 사인하도록 되어 있고, Transaction Body 와 Transaction Header 가 페어로 구성된다.

Transaction Header 의 Dependency 필드는 해당 Transaction 과 Dependency 를 갖는

트랜잭션들을 명시한다. Dependency 필드는 트랜잭션을 병렬로 실행할 때, 연관된

트랜잭션들이 무엇인지를 알려주기 때문에 해당 관계와 순서에 맞게 Transaction Scheduling 할

수 있다.

Namespace 는 해당 트랜잭션의 성격을 알려주는 것으로 일종의 구분자 역할을 한다.

EdenChain 에서는 스마트 컨트랙트를 이용해, 누구나 자신만의 코인이나 블록체인 시스템을

구축할 수 있다. 예를 들어 Alice 가 자신의 이름을 딴 Alice 코인을 만들고 싶다면 제공되는

스마트 컨트랙트 템플릿을 이용해 Alice Coin 을 발행할 수 있다. 이렇게 발행된 Alice Coin 을

거래하기 위해서는 트랜잭션을 발생시켜야 하는데, 이 때 트랜잭션에 Alice Coin 에 연관된

것이라는 것을 알려주기 위해 Namespace 에 “Alice”를 할당한다. EdenChain 은 Transaction

Header 를 참조해 해당 트랜잭션들을 Alice Coin 관련 트랜잭션들만을 모아서 처리할 수 있다.

이런 방식을 활용하면 트랜잭션들을 Namespace 에 따라 병렬 처리해 Performance 와

Scalability 를 향상 시킬 수 있다.

3.13 Merkle Tree

Merkle Tree 는 Ralph Merkle 이 1979 에 발표한 인증을 위한 Tree 데이터 구조로 모든 Leaf

노드는 자식 노드들의 Hash 값을 가지고 있고, Non-leaf 노드에는 데이터를 저장한다. Merkle

Tree 는 데이터를 효율적으로 저장할 수 있고, 적은 데이터로 Data Integrity 를 확인할 수 있어

IPFS, ZFS, 비트코인, 이더리움, Apache Cassandra 등 다양한 곳에서 사용되고 있다. (Wikipedia,

1979).



33

Merkle Tree 의 Root Node 는 새로운 노드가 추가될 때마다 갱신되고, Leaf Node 들의 Hash

값에 다시 Hash 함수를 재귀적으로 적용하기 때문에 특정 노드의 값이 하나만 바뀌어도 Root

Node 의 Hash 값은 달라진다.

이러한 성질은 전체 데이터없이 Root Node 값과 자신의 노드값 그리고 Counterparty Node

값을 알면 Data Integrity 를 스스로 검증할 수 있다.

3.14 Namespace

EdenChain 에서는 Radix Merkle Tree 를 이용해 블록체인의 현재 상태를 저장한다. 블록의

적합성을 검사하는 Validator Node 는 모두 Radix Merkle Tree 를 가지고 있다. Radix Merkle

Tree 는 최적의 공간을 사용하는 Trie 로 어떤 데이터를 표시하는데, Child 노드가 1 개뿐이라면

이 노드들을 합쳐 하나의 노드를 만들어 사용하기 때문에 메모리를 효율적으로 사용할 수 있다.

Radix Merkle Tree 의 Leaf Node 에는 Node Address 를 포함시켜 Node Address 값으로 해당

노드의 Sibling, Parent 등을 파악할 수 있도록 한다.

Validator Node 는 Block 과 Batch 내에 포함된 Transaction 을 검증하기 위해 트랜잭션에

포함되어 있는 Node Address 를 조사한다.

Node Address = Namespace + Node Path



34

Figure 11 Radix Merkle Tree with Node Address

Namespace 는 트랜잭션의 종류를 구분하기 위한 일종의 식별값으로, EdenChain 의 모든

트랜잭션은 Namespace 정보를 포함하고 있어야 한다. Validator Node 는 Namespace 정보를

이용해 블록 내의 트랜잭션들을 연관있는 트랜잭션들로 그룹화 할 수 있다.

예를 들어 단순한 거래 내역을 포함하는 트랜잭션에는 “EDN”이라는 Namespace 를 사용하고,

스마트 컨트랙트 XYZ 이라면 “XYZ”라는 Namespace 를 사용한다. Validator Node 는 단순히

트랜잭션에 포함되어 있는 Namespace 를 확인함으로써 EDN 에 연관된 트랜잭션들과 XYZ 관련

트랜잭션들을 구분할 수 있다. EDN 과 XYZ 는 서로 다른 종류의 Transaction 이기 때문에 Data

Consistency 문제가 없어 이들을 병렬로 실행할 수 있다. 기존의 비트코인이나 이더리움처럼

Data Consistency 문제 때문에 한번에 하나의 트랜잭션을 실행할 필요가 없어진다.



35

Figure 12 Transaction based on Namespace

3.15 Transaction Routing

Edenchain 은 Transaction Routing 을 이용해 Namespace 별로 준비된 TEE 에서 실행한다.

Router 는 Validator Node 에서 제출한 트랜잭션들에 대한 실행 요청을 받으면, Namespace 로

구분된 Batch 들을 실행시키기 위한 Execution Node 를 Resource Registry 에서 검색해, 해당

Execution Node 로 처리해야 하는 트랜잭션들을 전달한다.

Resource Registry 에는 각각의 Namespace 를 처리하기 위한 Computing Node 들이

기록되어 있으며, Router 가 Resource Registry 에서 해당 Namespace 를 찾지 못한 경우에는

Default Execution Node 에 트랜잭션을 전달해 실행한다.

Namespace 별로 할당된 TEE 는 Data Consistency 문제가 없기 때문에 현재 상태에 대한

Global Lock 없이 독립적으로 동시에 실행할 수 있다.

TEE 에 할당되는 워크로드를 실시간으로 모니터링 해 적절한 수의 Execution Node 를

구성한다면, 필요한 컴퓨팅 파워에 맞춰 최적의 컴퓨팅 리소스 상태로 블록체인을 운영할 수

있다.



36

Figure 13 Transaction Routing by Namespace

3.16 E-Bridge

E-bridge 는 EdenChain 과 외부 시스템을 연결해주는, 즉 On-chain and Off-chain Software

Bridge 로 BL 의 핵심 기술이다.

블록체인 내부에서 움직이는 데이터들은 합의 알고리즘, Encrypted Messaging 등의 기술을

이용해 Security 를 확보할 수 있지만, 외부 시스템의 경우에는 여러 곳에서 해커의 공격을 당할

수 있어 Security 를 확보할 수 없다. 따라서 On-chain 과 Off-Chain 을 연동할 때는 외부 시스템에

대한 신뢰 그리고 외부 시스템에서 전달받은 데이터를 On-chain 으로 연동시킬 때에 위협없이

안전하게 전달된다는 신뢰가 필요하다.



37

Off-chain 에 존재하는 데이터 소스에 대한 신뢰 문제는 해당 외부 시스템이 공개적인

서비스를 제공하고 있고 명성을 가지고 있다면 해소할 수 있다. 예를 들어 스마트 컨트랙트에서

애플 주가를 필요로 하는데, Nasdaq 이나 Yahoo Finance 서비스에서 데이터를 가져온다면

이들이 제공하는 데이터는 신뢰할 수 있다.

외부 시스템과의 연동 시 Off-chain 에서 발생할 수 있는 신뢰 문제는 크게 3 가지 문제로

압축할 수 있다.

1. 데이터 소스 신뢰도: 외부 시스템에서 제공하는 데이터가 올바른 데이터인지

아닌지에 대한 신뢰 문제를 해결할 수 있어야 한다.

2. 데이터 소스로부터의 신뢰할 수 있는 데이터 전달 : 데이터의 올바른 전달은

신뢰할 수 있는 데이터 소스로부터 데이터를 가져왔지만 데이터를 가져오는

프로그램이 해킹 당해 데이터가 변조되거나, 엉뚱한 데이터 소스로부터 가져오는

등의 공격을 받지 않고, 원래의 데이터가 100% 그대로 전달되어야 한다.

3. Off-chain 에서 On-chain 으로의 신뢰할 수 있는 데이터 전달 : 외부

시스템으로부터 전달된 신뢰할 수 있는 데이터가 공격받지 않고 On-chain 으로

전달될 수 있어야 한다.

E-Bridge 는 이러한 기술적 문제를 해결하는 기술로 On-Chain 과 Off-Chain 사이의 Secured

Connectivity 를 제공한다.

E-Bridge 는 블록체인 내에 속해 있지 않은 Off-chain 에 위치하는 Oracle Server, Enclave 등의

소프트웨어 모듈이 있고, On-chain 에 위치하는 Executor, Oracle Client 등이 서로 연동해

Secured Connectivity 를 확보하는 방식으로 설계되었다.



38

Figure 14 E-Bridge Layer

3.16.1 E-Bridge Architecture

E-Bridge 는 트랜잭션을 실행하는 Executor 와 스마트 컨트랙트의 외부 데이터 액세스 요청을

전달하는 E-Oracle Client, Client 의 요청을 처리하는 E-Oracle Server 그리고 E-Oracle Server

프로그램이 실행되는 TEE 인 SGX Enclave 로 구성되어 있다.

Executor, E-Oracle Client 는 On-chain 에 위치하며, E-Oracle Server 그리고 SGX Enclave 는

Off-chain 에 있어 E-Bridge 내에는 On-chain 과 Off-chain 의 모듈들을 안전하게 잘 연동할 수

있도록 E-Protocol 을 사용한다.

Figure 15 E-Bridge Architecture



39

3.17 Executor

Executor 는 EVM 을 탑재하고 있으며, 스마트 컨트랙트를 실행하는 역할을 한다. Executor 는

Secutiry 를 확보하기 위해 고립된 환경에서 실행되며, 스마트 컨트랙트의 업데이트 내용은 직접

DLT 에 기록되는 것이 아니라 Validator 를 거쳐, 검증된 데이터만 DLT 를 액세스 할 수 있다.

Edenchain 에서는 N 개의 Executor node 를 운영해 각각의 Executor Node 에서 스마트

컨트랙트를 실행하고 검증하도록 설계되었다.

3.18 E-Oracle

E-Oracle 은 스마트 컨트랙트가 외부 데이터를 액세스할 수 있도록 기능을 제공해 주는

소프트웨어 모듈로 E-Oracle Client 와 E-Oracle Server 로 구성되어 있다. E-Oracle Client 에서

외부 데이터를 요청하면, E-Oracle Server 에서 데이터 수집 후 전달해 주는 구조로 되어 있다. E-

Oracle Client 는 스마트 컨트랙트에서 호출할 수 있어야 하기 때문에 해당 스마트 컨트랙트에서

E-Oracle Client 를 로딩해 사용한다. E-Oracle Client 는 E-Protocol 을 이용해 E-Oracle Server 에

필요한 데이터를 요청한다. E-Oracle 은 여러 개의 노드로 구성되며 이들 노드들 간의 데이터

검증 방법과 최종 데이터 선택을 위한 합의 알고리즘을 제공한다.

3.18.1 E-Oracle Client

E-Oracle Client 는 스마트 컨트랙트가 외부 데이터 액세스 요청 기능을 제공하는 특별한

형태의 스마트 컨트랙트이다. E-Oracle Client 는 스마트 컨트랙트가 외부 데이터 액세스 요청을

하면, 실행에 필요한 파라메터를 E-Oracle Server 에 전달하며, E-Oracle Server 가 수집한 외부



40

데이터를 전달받아 스마트 컨트랙트에 전달해준다. E-Oracle Client 는 스마트 컨트랙트와 E-

Oracle Server 를 연결하는 일종의 게이트웨이 역할을 한다.

3.18.2 E-Oracle Server

E-Oracle Server 는 E-Oracle Client 로부터 요청한 데이터를 외부에서 액세스하기 위해

필요한 실질적인 기능들을 제공한다. E-Oracle Server 의 중요한 기능은 E-Oracle Client 로부터

외부 데이터 액세스 요청을 실행하고, 외부 데이터를 수집해 적절한 값을 선택하고, 이를 E-

Oracle Client 에 전달하는 것으로 설명할 수 있다. E-Oracle Server 는 보안을 강화하기 위해 E-

Oracle Server 자체 내에서 외부 데이터 액세스 관련 코드를 실행하지 않고, SGX Enclave 라는

별도의 공간에서 실행한다. E-Oracle Server 는 N 개의 노드들로 구성해, 어떠한 외부 데이터도

복수 개의 데이터를 가져오도록 설계한다. 하나의 E-Oracle Server 에서 데이터를 가져온다면,

이는 데이터의 신뢰성에 대한 문제나, 시스템적인 문제로 데이터를 제대로 가져오지 못할 수

있으므로, 복수 개의 E-Oracle Server 를 운영한다.

3.18.3 SGX Enclave

SGX Enclave 는 Intel 의 SGX(Software Guard Extension) Enclave 로 프로그램을 신뢰할 수

있는 환경에서 실행해 Security 를 보장해 주는 기술이다.

SGX Enclave 는 Enclave 에서 실행되는 프로그램을 분리된 공간에 위치시키고 데이터를

암호화하고, 외부 프로세스에서 접근할 수 없도록 만들어 해커의 공격으로부터 프로그램과

데이터를 보호한다. 암호화된 데이터와 코드는 Enclave 내에서만 복호화할 수 있어 안전하며,

만약 해커가 사이드 채널 공격으로 메모리를 직접 액세스해서 데이터와 코드를 알아냈다

하더라도, Enclave 내에 존재하는 Private Key 를 알 수 없어 복호화가 불가능하다.



41

Wipro 의 수석 소프트웨어 엔지니어인 Surenthar Selvaraj 에 의하면 SGX Enclave 는

Intel 에서 하드웨어와 소프트웨어 공격을 방어할 수 있도록 CPU Level 에서의 보안을 제공한다.

(Selvaraj, 2016) Enclave 에서 사용하는 메모리는 Privilege Level 과 CPU Mode 에 상관없이

읽거나 쓸 수 없으며, 전통적인 calls, jumps, register manipulation, stack manipulation 으로는

Enclave 환경으로 들어갈 수 없다. Enclave 에서 암호화를 위해 사용하는 키는 무작위로

변경되며, 해당 키 값은 메모리가 아닌 CPU 안에 저장되고, 외부에서 액세스 할 수 없다.

EdenChain 은 SGX Enclave 에서 E-Oracle Server 코드를 실행하기 때문에 해커의

소프트웨어 공격과 하드웨어 공격으로부터 안전하게 데이터와 시스템을 보호할 수 있다.

Figure 16 SGX Enclave



42

3.18.4 E-Oracle Consensus

EdenChain 은 Trusted Connectivity 확보를 위해 복수 개의 E-Oracle Server 를 운영한다.

하나의 E-Oracle Server 를 운영하면 외부 데이터를 가져왔는데, 그 데이터가 신뢰할 수 있는

데이터 소스로부터 가져왔다 하더라도, 해당 시스템의 실수로 혹은 시스템 상의 문제로 언제나

100% 옳다고 확신할 수 없다.

이런 문제를 회피하기 위해 E-Oracle 은 2n-1 개로 운영하며, 이들을 E-Oracle Pool 이라고

지칭한다.

여러 개의 E-Oracle Pool 을 사용하면, 한 가지 기술적 문제에 부딪히게 된다. 각각의 E-Oracle

Server 에서 제공하는 여러 개의 값 중에서 어떤 값을 사용할지를 결정하는 문제이다.

E-Oracle Server 에서 받아올 수 있는 값의 형태를 Discrete Type 와 Continuous Type 의

2 가지 형태로 구분할 수 있다. Discrete Type 는 불연속적인 값으로 True, False, “man”,

“woman”와 같은 형태의 값을 의미하고, Continuous Type 는 연속적인 값으로 15.34432, 1.0213

와 같은 연속적인 값을 지칭한다.

Discrete Type 는 여러 개의 E-Oracle Server 에서 동일한 값을 가질 수 있지만, Continuous

Type 은 신뢰할 수 있는 데이터 소스로부터 데이터를 가져왔다 하더라도 그 값이 데이터 소스와

외부 시스템의 특성에 따라 달라질 수 있다.

예를 들어 애플 주식 가격에 따라 결정되는 파생 상품이 있다면, E-Oracle Server 에서는 애플

주식 가격을 Nasdaq, Yahoo finance 와 같이 여러 서비스를 통해 가져온다.

Nasdaq 에서의 값은 175.01, Yahoo Finance 에서는 174.98 이라고 값을 가져왔다면, E-

Oracle Server 은 175.01 과 174.98 의 2 가지 값 중에 하나를 선택하던가, 아니면 이들 값을

조합해 최종값을 결정해 E-Oracle Client 에 전달해야 한다.



43

E-Oracle Consensus 는 이러한 상황에서 여러 개의 값 중에 어떤 값을 최종적으로 사용할지를

결정하는 기술이다.

3.18.5 Schelling Point

(Schelling, 1960)은 사람들이 어떤 행동을 할 때 무작위로 행동하기 보다는 스스로

생각하기에 자연스럽거나 상식에 따라 행동하는 성향이 있다는 Shelling Point 라는 개념을

발표하였다. Schelling 은 “내일 이방인을 뉴욕에서 만나야 한다면, 언제 어디서 그를 만날

것인가?” 라는 질문에 대한 답으로 “정오에 Grand Central Terminal 의 Information Booth 에서”

를 제시하였다. 사람들이 전통적으로 약속 장소로 가장 많이 사용하는 시간과 장소이기 때문에

사람들이 은연 중에 선택할 가능성이 높다고 이유를 설명했다.

E-Oracle 에서 외부 데이터에 대한 합의를 만들기 위해 Schelling Point 를 사용할 수 있다. E-

Oracle Server 는 각각의 독립적인 노드이고, 스마트 컨트랙트에서 전달된 파라메터를 이용해

외부 데이터를 액세스하고, 그 결과값을 받아온다.

E-Oracle Server 는 서로의 값을 교환하고, 최종적인 값을 중앙화된 시스템 없이 스스로

선택해야 하는데, 중요한 기본적인 가정은 각각의 E-Oracle Server 에서 제출한 값들에 대한

신뢰도가 없다는 점이다.

(Buterin V. , 2014)은 이에 대한 해결책으로 Schelling Coin 을 제시하였다. 어떤 값을 결정하기

위한 프로세스에 참여하는 사람들에 대한 인센티브로, 최종적으로 선택된 올바른 값을 제출하는

참여자들에게는 Shelling Coin 을 보상으로 준다면, 참여자들은 보상을 받기 위해 다음 번에

제출하는 값이 다른 사람들이 제출하는 값과 유사한 값을 제출하게 되고, 이러한 프로세스가

반복되면 참여자들의 값 선택이 자연스럽게 실제 값에 가깝게 된다는 매커니즘을 가지고 있다.



44

Schelling Point 는 공통적으로 알고 있는 어떤 사실을 Focal Point 로 활용해 선택을 하는

것으로 참여자 간의 공통 정보(Common Knowledge)를 만들어야 하고, 지속적인 인센티브를

제시해 옳은 값과 그렇지 않은 값을 구분하고, 다수가 선택할 만한 값을 제출하도록 유도해야

한다. 참여자가 계속 바뀌는 상황이나, 선택해야 하는 값에 대한 공통 정보를 만들수 없다면

적용하기 어렵다.

3.18.6 E-Oracle Consensus by Median Voter Theorem (MVT)

E-Oracle Server 들이 갖게 될 수 있는 데이터는 Discrete Type 과 Continuous Type 의

2 가지이고, 이들 데이터 형태는 서로 다른 합의 알고리즘을 필요로 한다.

E-Oracle 은 데이터 형태에 따라 Discrete Type 의 경우에는 다수결(Majority Voting)을,

Continuous Type 에는 MVT 를 적용한다.

3.18.7 Majority Voting

E-Oracle 이 가질 수 있는 값이 “Yes” Or “No” 혹은 “True” or “False”와 같이 한정되어 있다면

Majority Voting 을 실시해 E-Oracle Server 가 가장 많이 가지고 있는 값을 선택해 최종 값으로

확정한다. Majority Voting 은 일반적으로 많이 사용되는 합의 알고리즘으로 Discrete Type 에

어려움 없이 적절히 활용할 수 있다.

3.18.8 Median Voter Theorem (MVT)

MVT 는 Continuous Type 의 데이터들이 있을 때 적용하는 방법이다.

MVT 는 다수결 시스템에서는 Median Voter 가 선호하는 결과가 선택될 것이라는 이론이다.

(WIKIPEDIA, n.d.)



45

경제학자 Duncan Black 은 다수결 시스템에서 Median Voter 에 의해 선택된 결과가 “Nash

Equilibrium”이고, Median Voter 가 선택한 값과 멀어지면 아무런 이득을 얻을 수 없다고 설명했다

(Black, 1948). 즉 다수의 참가자가 어떤 값을 다수결 시스템으로 결정하려고 할 때 Median

Voter 의 선택과 다른 선택을 하면, 이득이 없다는 것을 의미한다.

여기서 Median Voter 는 참가자 절반이 생각하는 이상적인 선택이 이상적인 선택이라고

생각하는 사람을 의미한다.

Figure 17 MVT (Puglisi, 2011)

3.19 Voting Theorem

Common Resource 의 경우에는 Resource Utilization 과 Growth Rate 는 Median Voter 에

의해 VSSE(Voting steady-state Equilibrium)이 결정된다. (Kirill Borissov, 2010)

( )

Figure 21 Voting Steady-State Equilibrium (VSSE)

Voter 는 효용성을 극대화하기 위해 노력한다. 투표를 실시할 때 VSSE 상태값을 증가시키기

원하는 사람이 전체 인원의 50%를 넘어야 VSSE 의 값이 증가된다.

VSSE 의 값은 다음과 같은 수식으로 결정된다. ( = Median Voter)



46

3.19.1 The equilibrium growth rate is determined as follows :

( )

따라서 최종 평형 상태값인 VSSE 는 Median Voter 에 의해 결정되며, 50%를 넘는 과반수를

확보하지 못하면 VSSE 값을 변동시킬 수 없다. MVT 합의 알고리즘은 SGX Enclave 에서

실행되기 때문에, 해커가 성공적으로 공격하기 위해서 과반수 이상의 노드들을 해킹해야 하며,

이는 상당한 시간과 노력을 필요로 한다.

MVT 는 최종 선택값으로 Median 을 사용하기 때문에 Continuous Type 에 적용할 수 있다.

하지만 discrete type 에는 적합하지 않다. 또한 Schelling Point 와 다르게 공통 정보를 필요로

하지 않기 때문에 별다른 사전 정보 없이 E-Oracle Server 들이 제출한 값 중에서 최종 값을

선택할 수 있고, 별도의 인센티브 시스템을 도입하지 않아도 되기 때문에 구현이 간단하며

명쾌하다.

E-Oracle Server 는 Continuous Type 데이터들을 선택할 때 MVT 를 적용해 최종 값을

선택한다.

3.20 Threat Model

E-Oracle Consensus 에서 사용하는 Majority voting 과 MVT 는 51% 공격에 취약하다. 해커가

외부에 노출되는 모든 E-Oracle Server 를 51%이상 탈취하는 데 성공한다면 탈취된 서버에서

제출하는 값들이 Median 이 되고, E-Oracle Server 는 변조된 값을 최종값으로 E-Oracle Client 에

전달할 위험이 있다.



47

E-Oracle Consensus 모듈은 이러한 위험을 방지하기 위해 SGX Enclave 에서 프로그램을

실행해 하드웨어, 소프트웨어 공격을 방어하고, 외부 서비스는 HTTPS 를 이용해 액세스한다.

HTTPS 를 지원하지 않는 데이터 소스는 E-Oracle Server 에서 데이터 액세스를 허용하지 않는다.

4. E-Protocol

E-Protocol 은 E-Oracle Pool 에 있는 E-Oracle Server 들간의 통신을 위한 프로토콜이다. E-

Oracle Server 는 외부 데이터를 액세스하고, 수집한 데이터의 합의를 이루기 위해 E-Oracle

Server 들간의 상호 연동이 필요하다. E-Oracle Server 가 SGX Enclave 에서 실행되어 데이터를

조작하거나, 프로그램을 변조할 수는 없지만, 해커가 네트워크 패킷을 훔쳐볼 수 있는 가능성이

있기 때문에 이를 방지하기 위한 방법이 필요하다.

E-Protocol 은 Threshold Cryptography 를 이용한 통신으로 데이터를 암호화한다.

Threshold Cryptography 는 N 명의 사람들이 있는 그룹에서 K 명의 사람들이 특별한 값을

서로 공유해 데이터를 보호할 수 있는 암호화 프로토콜이다. (Shoup, 2000)

Threshold Cryptography 는 협력적 특성을 가진 프로토콜로 복호화를 위해 필요한 데이터를

참여자들끼리 나누어 갖기 때문에 자신 뿐만 아니라 다른 참여자들의 데이터를 가지고 있어야만

암호를 해제할 수 있다.

Threshold Cryptography 는 다음과 같은 특성을 가지고 있다.

1. 사용하는 알고리즘에 따라 Trusted Third Party 가 필요없을 수 있다. (Lee, Shen,

and Wheatman, 2016):

2. K 수보다 작은 참여자들은 메시지를 복호화할 수 없다.



48

3. 공격자는 획득한 정보를 이용해 추후 메시지의 Signature 를 파악할 수 없다.

4. Signature 생성 후에는 참여자들이 다시 Signature 를 생성하거나 섞을 필요가 없다.

E-Protocol 은 스마트 컨트랙트 세션, E-Oracle Client 가 요청한 데이터를 외부에서 가져오고,

최종적으로 값을 선택해 E-Oracle Client 에게 반환하는 과정에 적용된다..

4.1 Elliptic Curve Cryptography (ECC) –

Threshold Cryptography (TC)

(Nguyen, 2005)는 RSA Threshold 를 제안하였다. 이 방법은 Trusted Third Party 를 필요로

하지 않고 Secret Sharing 을 위한 초기 설정 과정에서 중요한 정보가 누출되지 않는다.

RSA Threshold 는 기존의 Threshold Cryptography 가 가지고 있던 문제를 해결해 안전성을

향상시켰다.

(Ibrahim, 2003)는 ECC - TC 를 제안하였다. 이 방법은 RSA Threshold 보다 더 작은 크기의

키로 유사한 수준의 보안을 제공하기 때문에 더 빨리 연산을 마칠 수 있고, 메모리 사용량이 더

적다. ECC - TC 는 Public Key 와 Private Key 가 모두 Elliptic Curve 상의 포인트로 존재하기

때문에 키가 공유되지 않는다. (G.PadmavathiB., 2012)

ECC - TC 는 1) Key Generation, 2) Encryption, 3) Decryption 의 3 단계로 구성되어 있다.

ECC - TC 의 Encryption 은 암호화시키려는 메시지를 N 개로 나누고 각각의 나뉘어진

메시지를 암호화 한다.

ECC-TC 를 적용하는 주요 절차를 기술하면 다음과 같다. :

1. Elliptic Curve 상에서 Base point (x,y)를 무작위로 선택한다.



49

2. Plaintext 를 (xm,ym)에 위치시킨다.

3. TC 를 적용하기 위해 “m”을 “w”개로 나눈다.

4. 각 노드들은 private key “n”을 선택하고 public key 를 계산한다.

p = n(x,y)

예를 들어 노드 A 가 메시지를 암호화시키기 위해서는 난수 k 를 생성해야 한다.

Cm = {k(x,y),(xm,ym) + kpA}

5. Cm 을 복호화시키기 위해서는 다음과 같은 과정을 거친다.

((xm,ym) + kPA – nA(k(x,y) ) = (xm,ym) + k(nA(x,y) – nA(k(x,y)) = (xm,ym)

나뉘어져 암호화된 메시지들은 Shamir’s 의 방법을 이용해 재구성하고, Private Key 를 이용해

복호화하여 원래의 메시지를 읽을 수 있으며 아래의 그림은 암호화하는 과정과 복호화하는

과정을 설명한 것이다.

E-Protocol 은 ECC - TC 를 이용해 E-Oracle 에서 사용하는 메시지들을 암호화 한다.



50

Figure 18 ECC-TC Encryption

Figure 19 ECC-TC Decryption

4.2 External Attacker

외부의 공격자가 E-Protocol 메시지를 액세스했다면 얻을 수 있는 정보는 Public Key Q 와

Random Number K 이다. 이 2 가지 정보는 일반적인 ECC 에서도 동일하게 얻을 수 있는 것으로

공격자는 그 외의 아무런 정보를 얻을 수 없다.

만약 외부의 공격자가 메시지를 액세스했고, E-Oracle Server 에서 ECC - TC 를 사용한다는 것을

알고 있다고 해도, 공격자가 얻을 수 있는 정보는 이전과 동일하게 Public Key Q 와 Random

Number K 뿐이기 때문에 메시지를 복호화하거나, Signature 을 알아내 변조하는 것은

불가능하다..



51

4.3 Attack from a Malicious Participant

E-Oracle Session 에 참여하는 하나의 노드에서 메시지를 변조하거나, 복호화 하려는 시도를

할 수 있다. 하지만 이러한 시도 역시, 별다른 효과가 없을 것이다. 왜냐하면 ECC - TC 에서는

메시지를 복호화하려면 ECC - TC 에 참여하는 자신을 제외한 노드들의 Secret Key 를 알아야

한다. 자신의 Secret key 만으로는 복호화할 수 없다.

5. Confidentiality on Eden

블록체인에서 Confidentiality 는 3 가지 측면으로 나누어 생각할 수 있다. 첫 번째는 스마트

컨트랙트에 대한 Confidentiality 로 특정한 사람만이 스마트 컨트랙트의 내용을 볼 수 있도록

보호하는 것이다. 두 번째는 Transaction 에 대한 Confidentiality 로 Transaction 을 모든 사람이 볼

수 있지 않고, 특정인만 볼 수 있도록 하는 것이다. 세 번째는 Oracle 에 대한 Confidentiality 로

외부 시스템에 요청할 때 데이터가 노출되지 않도록 하는 것이다.

블록체인의 철학과 기술 특성상 첫 번째와 두 번째 Confidentiality 는 확보하기 힘들다.

Edenchain 에서는 다양한 스마트 컨트랙트가 실행되는데, 암호화된 스마트 컨트랙트를

허용하면, 스마트 컨트랙트를 제출한 사람 혹은 단체에 대한 완벽한 신뢰를 갖고 해당 스마트

컨트랙트는 안전한 것이라고 믿고 실행해야 한다. 이 같은 사상은 Edenchain 전체의 보안에 큰

영향을 미칠 수 있는 중요한 가정인데, 이를 담보할 수 없다. 따라서 Edenchain 에서는 암호화된

스마트 컨트랙트를 허용하지 않는다.

트랜잭션에 대한 암호화는 몇몇 특성화된 Sealed Auction 과 같은 금융거래에서는 필수적인

요소이다. 하지만 Edenchain 의 스마트 컨트랙트는 다양한 외부 시스템과의 연동이 필요하고, 또



52

외부에서 소유권이나 과거 트랜잭션에 대한 기록을 요청할 때 제공할 수 없다면 EdenChain 의

효용성이 작아지기 때문에 수용하지 않는다.

Oracle Confidentiality 는 스마트 컨트랙트를 이용해 Trusted Connectivity 를 확보해 다양한

외부 시스템과의 연동에 있어 중요한 보안적 요소이다.

스마트 컨트랙트가 자동화되어 사용자에게 편리하고 안전하게 동작하기 위해서는 외부

시스템과의 지속적인 상호 연동이 필요하고, 이 과정에서 중요한 정보들이 네트워크를 통해

이동한다. 만약 해커가 이러한 정보를 액세스할 수 있게 된다면 오용의 여지를 만들어 보안을

크게 훼손 할 수 있다.

5.1 Confidentiality by SGX and Encrypted

Protocol

SGX Enclave 와 Encrypted Protocol 을 이용해 Confidentiality 를 확보하고, EdenChain 에서

실행되는 트랜잭션과 스마트 컨트랙트의 세부적인 내용은 누구도 알 수 없도록 Privacy 를

보장한다.

E-Oracle Server 에서 외부 시스템에 액세스해 데이터를 가져오고, 여러 데이터 중 하나를

선택하는 E-Oracle Consensus 등의 모든 과정은 SGX Enclave 에서 실행된다. SGX Enclave 는

제한된 액세스와 데이터 암호화로 실행되고 있는 동안 시스템 운영자와 같은 내부인이나 해커가

해당 내용을 알 수 없다.

SGX Enclave 에서 외부 데이터는 HTTPS 를 이용해 가져온다. HTTPS 는 SSL Certificate 와

암호화된 통신을 사용하기 때문에 해킹의 위험을 줄여주고 역시 내부자가 데이터의 내용을 알 수



53

없다. 스마트 컨트랙트는 HTTPS 를 지원하는 외부 시스템과의 연동을 지원하며, 암호화되지

않은 통신 프로토콜은 허용하지 않는다.

SGX Enclave 에서는 외부 시스템과의 연동을 위해 사용했던 데이터를 디스크와 같은

영구적인 저장 장치에 저장하지 않기 때문에 실행이 종료되는 즉시 삭제된다.

.

5.2 Encrypted Protocol

해커는 E-Oracle 이 동작하는 동안 네트워킹 측면에서 2 가지 공격 가능성을 가지고 있다.

SGX Enclave 와 외부 시스템과의 네트워킹과 E-Oracle Server 간의 네트워킹이다.

SGX Enclave 와 외부 시스템과의 통신은 HTTPS 를 이용하기 때문에 데이터들이 암호화되어

있고, E-Oracle Server 간의 통신은 ECC - TC 를 이용한 암호화 통신을 하기 때문에 공격자가

메시지를 액세스하더라도 메시지를 복호화하거나 조작하는 것은 가능하지 않다.

5.3 Lack of Censorship

EdenChain 에서 실행되는 모든 트랜잭션과 스마트 컨트랙트는 EVM 과 SGX Enclave 에서

실행되기 때문에 여기에서 사용되는 데이터를 통제하거나 액세스 할 수 없고, 따라서 검열할 수

없다. EdenChain 은 Permisioned 블록체인이지만 여타의 Permissionless 블록체인과

마찬가지로 검열하지 않고, 모든 트랜잭션과 스마트 컨트랙트가 균등하게 실행되고, 100%

실행할 수 있는 환경을 제공한다.



54

5.Conclusion

EdenChain 은 블록체인 기술을 프로그래머블 이코노미에 적용하기 위해 필요한 대표적인

기술적 요건인 속도와 보안을 향상시킨 블록체인 기술이다. 기존 블록체인 기술들은 데이터

정합성 문제(Data Consistency Problem) 때문에 한번에 하나씩 실행하는 직렬 실행(Serial

Execution) 방식을 채택하고 있다. 직렬 실행은 확장성이 없기 때문에 더 많은 트랜잭션들을

처리하기 위해 컴퓨팅 파워를 늘려도 처리 속도를 높일 수 없다. EdenChain 은 Namespace

기술을 도입해 트랜잭션을 동일한 Namespace 를 가지고 있는 것들끼리 묶어서 처리할 수 있다.

서로 다른 Namespace 에 속해있는 트랜잭션들은 데이터 정합성 문제가 없어 동시에 병렬로

실행할 수 있다. 병렬 실행(Parallel Execution)은 트랜잭션의 수가 늘어나면 컴퓨팅 파워를

추가해 처리 속도를 증가시킬 수 있어 확장성이 좋다. 더욱 빠른 처리가 필요하면 Namespace

별로 트랜잭션을 처리할 수 있는 각각의 Namespace Computing Zone 을 만들어 최적의 성능을

유지할 수 있다.

블록체인이 외부 서비스와 연동해 트랜잭션을 처리하는 경우가 많아지면, 그에 따른 해킹

사고의 위험이 증대된다. 기존 블록체인 기술들은 블록체인 자체의 보안에 초점이 맞춰져 있어

외부 서비스 연동 보안에 대해서는 특별한 방법을 제공하고 있지 않다. EdenChain 은 E-Oracle

기술을 이용해 외부 서비스와 연동시 해커의 공격을 효과적으로 방어할 수 있다. E-Oracle 기술은

Multiple Data Source, ECC-TC 그리고 MVT 기술을 이용한다. E-Oracle 은 SGX Enclave 에서

실행되기 때문에 해킹을 하기가 매우 어려운 구조로 되어 있고, 해킹을 성공시키기 위해서는

전체 51%의 E-Oracle 서버에 침입해야 한다.

EdenChain 을 이용하면 유﹒무형 가치들을 자산화시켜, 안전하게, 빠르게, 저렴하게 거래할 수

있다. 블록체인 기술과 코인이 필요한 사업자/단체/개인이 쉽고 간편하게 사용할 수 있다.



55

References

Alharby, M. and Moorsel, A. (2017). Blockchain-based Smart Contracts: A Systematic Mapping

Study. Computer Science & Information Technology.

Black, D. (1948). On the Rationale of Group Decision-making. Journal of Political Economy.

Bontje, J. (2016). Does every node execute the contract code for each transaction? Retrieved

from https://ethereum.stackexchange.com/questions/357/does-every-node-execute-the-

contract-code-for-each-transaction

Buterin, V. (2014). SchellingCoin: A Minimal-Trust Universal Data Feed. Retrieved from

https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/

Buterin, V. (n.d.). A next-generation smart contract and decentralized application platform.

Retrieved from https://github.com/ethereum/wiki/wiki/White-Paper/

Cameron-Huff, A. (2017). Nasdaq. Retrieved from http://www.nasdaq.com/article/how-

tokenization-is-putting-real-world-assets-on-blockchains-cm767952

Chamber of Digital Commerce (2016). Smart Contracts: 12 Use Cases for Business & Beyond.

Chianese, A. (2015). Smart environments and Cultural Heritage: A Novel approach to create

intelligent culural spaces. Journal of Location Based Services.

Ehrsam, F. (2017, 6). Scaling Ethereum to Billions of Users. Retrieved from Medium:

https://medium.com/@FEhrsam/scaling-ethereum-to-billions-of-users-f37d9f487db1

Eyal, I. (2015). The miner’s dilemma. IEEE Symposium on Security and Privacy.

Tschorsch, F. (n.d.). Bitcoin and Beyond- A Technical Survey on Decentralized Digital.

Foundation, L. (2017). Sawtooth. Retrieved from

https://sawtooth.hyperledger.org/docs/core/releases/latest/introduction.html#proof-of-

elapsed-time-poet

Harding, D. A. (2015). Is there a maximum size of a scriptSig/scriptPubKey? Retrieved from

Bitcoin Stack- Exchange: http://bitcoin.stackexchange.com/questions/35878/is- there-a-

maximum-size-of-a-scriptsig-scriptpubkey.

Holcombe, R.G. (2006). Public Sector Economics, Upper Saddle River: Pearson Prentice Hall, p.

155.

Ibrahim, M.H. and Ali, I.A. (2003). A robust threshold elliptic curve digital signature providing a

new verifiable secret sharing scheme. Circuits and Systems.

Jameson, H. (2017, 6). Accounts, Transactions, Gas, and Block Gas Limits in Ethereum.

Retrieved from https://hudsonjameson.com: https://hudsonjameson.com/2017-06-27-

accounts-transactions-gas-ethereum/



56

Borissov, K. (2010). Common and private ownership of exhaustible resources: theoretical

implications for economic growth. Istanbul.

Konstantinos, C.. (2016). Blockchains and Smart Contracts for the Internet of Things. IEEE.

Lamela-Seijas, P. (2017). Scripting smart contracts for distributed ledger technology.

Lee, H., Shen, H., and Wheatman, B. (2016). Implementation and Discussion of Threshold RSA.

Lewis, A. (n.d.). Agentleintroductiontosmartcontracts. Retrieved from

https://bitsonblocks.net/2016/02/01/a-gentle-introduction-to-smart-contracts

Li, S., Xu, L.D., and Zhao, S. (2015). The internet of things: A Survey. Information Systems

Frontier.

Luu, L. (2015). On Power Splitting Games in Distributed Computation: The Case of Bitcoin

Pooled Mining. IEEE.

Flood, M.D. (2017). Contract as Automaton: The Computa- tional Representation of Financial

Agreements.

Merkle, R. (1998). “A digital signature based on a conventional encryption function”. Retrieved

from Merkle Paper: https://people.eecs.berkeley.edu/~raluca/cs261-

f15/readings/merkle.pdf

Meshenberg, R., Gopalani, N., and Kosewski, L. (2013). “Active-Active for Multi-Regional

Resiliency”. Retrieved from Medium: https://medium.com/netflix-techblog/active-active-

for-multi-regional-resiliency-c47719f6685b

Microsoft. (2017). Multiple Datacenter Deployment Guidance. Retrieved from Developer

Network: https://msdn.microsoft.com/en-us/library/dn589779.aspx

Morabito, V. (2017). Smart contracts and licensing, in Business Innovation Through Blockchain.

Nakanishi, S. (2016, 6). Are gas limit in transaction and block gas limit different? Retrieved from

StackExchange: https://ethereum.stackexchange.com/questions/7359/are-gas-limit-in-

transaction-and-block-gas-limit-different

Nguyen, H. (2005). RSA Threshold Cryptography.

Padmavathi, G., and Lavanya, B. (2012). Comparison of RSA-Threshold Cryptography and

ECC-Threshold Cryptography for Small Mobile Adhoc Networks. Advanced Networking

and Applications.

Puglisi, R. (2011). The Political Economics Approach.

Schelling, T. (1960). The Strategy of Conflict. Harvard University Press.

Selvaraj, S. (2016). Overview of Intel Software Guard Extension Enclaves. Retrieved from Intel :

https://software.intel.com/en-us/blogs/2016/06/06/overview-of-intel-software-guard-

extension-enclave



57

Shoup, V. (2000). Pratical Threshold Signature. IBM Research Lab.

Solidity. (n.d.). Solidity. Retrieved from http://solidity.readthedocs.io/en/develop/index.html

Huckle, S. (2016). Internet of Things, Blockchain and shared Economy applictions.

Szabo, N. (1996). Smart Contracts: Building Blocks for Digital Markets.

Szabo, N. (1997). Formalizing and Securing Relationships on Public Networks.

Pureswaran, V. (2015). Device Democracy - Saving the future of the Internet of things. IBM.

Gramoli, V. (n.d.). The Blockchain as a Software Connector.

Wood, D. G. (2017). Ethereum: A secure decentralised generalized transaction ledger.

Xu, X., Pautasso, C., and Zhu, L. (2016). The Blockchain as a Software Connector. IEEE.

edenchain: the programmable economy platform james ......edenchain: the programmable economy...

Documents