안녕하세요. 이글아이(@eaglekeeneye) 입니다.

이번 글은 지난 글에 이어진 이야기입니다. 아래의 링크부터 차례로 먼저 읽고 오시길 권장 드립니다.

• 시리즈 서두:
  [블록체인 스터디 노트 #1] 또 블록체인이야?
  [블록체인 스터디 노트 #2] 중앙집권적 금융체제의 폐해

• 1세대 암호자산 비트코인:
  [블록체인 스터디 노트 #3] Bitcoin의 탄생: 분산화 된 가치 저장수단
  [블록체인 스터디 노트 #4] Bitcoin은 어떻게 신뢰를 얻게 되었나 1
  [블록체인 스터디 노트 #5] Bitcoin은 어떻게 신뢰를 얻게 되었나 2
  [블록체인 스터디 노트 #6] Bitcoin, 그리고 그 이후

• 2세대 암호자산 이더리움:
  [블록체인 스터디 노트 #7] Ethereum의 탄생: 분산화 된 애플리케이션 플랫폼
  [블록체인 스터디 노트 #8] Ethereum의 역사: 발자취와 로드맵
  

0) 이야기 순서

---

이번 포스팅에서는 이더리움의 대표적인 4가지의 한계점에 대한 포스팅을 하고 이더리움 파트를 마무리하겠습니다.

우선 "1) 한계점 1: 가스" 에서 이더리움의 가스가 dApp의 실사용에 왜 장애물인지 설명하겠습니다.

"2) 한계점 2: 매우 느린 속도" 에서는 이더리움의 블록생성 시간과 속도에 대해 설명을 하며, 왜 실제 사용하기에 적합하지 않은지 설명하겠습니다.

"3) 한계점 3: Code is Law" 에서는 이더리움의 code is law에 대한 개념과 실사용에 불편한 점들을 설명하겠습니다.

"4) 한계점 4: Oracle Problem, 현실 세계를 반영하지 못하는 체인" 에서는 이더리움뿐만 아니라 이오스를 포함한 모든 체인이 풀어야만 하는 과제인 oracle problem과 이에 대한 문제를 설명하겠습니다.

1) 한계점 1: 가스

---

( a ) 가스의 개념

---

( i ) 이더리움 컴퓨팅 자원 수수료

---

가스의 어원은 이더리움 재단에서 빛의 매질이라 생각되던 에테르(ether)에서 착안하여 만들었습니다. 가스의 개념은 [블록체인 스터디 노트 #7] Ethereum의 탄생: 분산화 된 애플리케이션 플랫폼 포스팅에서 설명해 드린 적이 있습니다. 다시 설명해 드리자면 이더리움은 비트코인과 달리 반복 구문을 사용할 수 있기 때문에 악의적인 노드가 불필요한 거래를 일으켜 시스템 전체를 마비시킬 수 있습니다. 그래서 불필요한 거래를 일으키면 이에 대한 경제적 타격을 주기 위해 '가스(gas)' 라는 개념을 도입한 것입니다.

비트코인은 거래수수료로 바로 비트코인을 지불하고 채굴자들이 비트코인으로 받습니다. 하지만 이더리움은 거래수수료로 이더(ether) 대신 '가스(gas)'로 지급합니다. 수수료로 나가는 가스는 미미한 양인데, 가스비를 따로 받으면 이더의 가격 변동에 따라 거래 수수료 가격을 안정화할 수 있습니다.

( ii ) 이더리움 송금

---

이더리움 이용자들을 많이 괴롭히던 이더리움 송금법에 대해 간략하게 알아보겠습니다.

① 이더리움 주소에서 이더와 이더리움 기반 토큰으로 거래할 때, 널리 쓰는 것이 MyEtherWallet 과 Metamask 입니다. 일명 '여우 지갑'이라 불리는 메타마스크는 사실 이더리움 거래를 위한 (EOS에서 scatter 같은) 리모콘 역할을 합니다. 이더리움 비밀키를 입력합니다.

② 계정의 이더와 이더기반 토큰 잔고를 조회 할 수 있으며, 거래내역 조회도 됩니다. 이더를 송금하기 위해 'SEND'를 클릭합니다.

③ 송금하고자 하는 이더리움 계정 주소와 이더 수량을 입력합니다.

④ 여기서 Gas Limit 와 Gas Price 가 있습니다. 우선 Gas Limit은 가스 한도인데, 이더리움 계약상의 버그로 인해 반복 구문에서 빠져나가지 못할 때 가스 소비의 한도를 정하기 위해 만들었습니다. 그리고 Gas Price의 단위는 wei 인데 1,000,000,000,000,000,000 (10^18) wei = 1,000,000,000 (10^9) Gwei = 1 ETH 에 해당합니다.

따라서 위의 예시에서 0.02 ETH를 송금할 때, 가스비는 최대 21,000 (Gas Limit) X 5 gwei = 105,000 gwei = 0.000105 ETH 이 필요합니다. 값들은 언제든지 마음대로 조절할 수 있는데 위의 값대로 하면 최대 0.020105 ETH 이 필요합니다.

이더리움 채굴자들은 가스비를 높게 잡은 이용자들의 거래를 먼저 처리해줍니다. 다시 말해 거래를 빨리하고 싶으면 가스비를 늘려야 하고, 느려도 상관없다면 가스비를 낮추면 됩니다.

( b ) 가스의 문제점들

---

출처: Mainframe, How Dapps Work in 2018 ~ "Dawn of the Dapps"

( i ) dApp 실사용의 장애물

---

위의 예시에서 이더리움 기반 토큰을 보낼 때도 토큰만 있어서는 안 되고, 가스비를 지불할 이더리움도 같이 있어야 합니다. 하지만 거래속도에 따라 사용자들이 가스를 얼마나 써야 하는지 예측하기 어렵고, 그나마 가스비 지불 후에도 거래 처리속도가 낮아 답답해서 취소해도 가스비를 그대로 소비하는 경우도 있습니다.

dApp의 실사용을 위해 일반 이용자들은 가스라는 개념을 모르고도 사용할 수 있어야합니다. 가스의 존재 자체가 일반 이용자들이 dApp 사용에 큰 장애물인데, 한술 더 떠서 정해진 값도 아니라 이용자들이 알아서 기재해야 하는 것도 큰 장애 요인입니다.

( ii ) 비싼 가스 비용

---

이더가격에 비해 수수료 단위가 작다고 하나, 거래량이 많으면 가스비용이 그렇게 저렴한 편도 아닙니다. 앞서 언급했듯이 이더리움 기반의 토큰 거래량이 한꺼번에 몰리면 이용자들은 앞 다투어 가스 수수료를 높이는데 마침 이더 수요가 급증함에 따라 수수료도 덩달아 오르게 되었습니다.

아래에서 더 자세하게 설명하겠지만, 2017년 12월에 출시된 이더 기반 가상 고양이 기르기 게임 크립토키티(CryptoKitty)라는 dApp 하나 때문에 이더리움 네트워크 전체가 먹통이 된 적이 있습니다. 이미지는
Ethereum Average Gas Price Chart에서도 조회 가능한데, 당시 이더리움 네트워크에 거래량이 몰려서 가스 수수료가 높아진 모습입니다.

( c ) POW(Proof of Work) 에서 POS(Proof of Stake)으로 전환

---

이전 글인 [블록체인 스터디 노트 #8] Ethereum의 역사: 발자취와 로드맵
에서 언급했듯이, 이더리움은 콘스탄티노플 하드포크를 통해 POW 기반 합의 알고리즘에서 완전한 POS 기반 알고리즘으로 전환하는 과정을 거치고 있습니다.

채굴이라는 합의 알고리즘이 필요 없어지고, 모든 거래를 POS 기반으로 검증하여 합의하여 확장성을 늘린다면 '가스'라는 개념도 자연히 없어질 것입니다.

2) 한계점 2: 매우 느린 속도

---

( a ) 이더리움 속도

---

( i ) 이더리움 블록 생성

---

비트코인도 POW 기반의 토큰이기 때문에 거래속도가 매우 느리지만, 이더리움 역시 dApp 실사용을 위해 요구되는 속도에 한참 동안 미치지 못합니다.

비트코인의 블록 생성 시간은 블록당 10분이지만, 이더리움은 그것보다 더 빠른 15초입니다. 비트코인의 TPS(Transaction per Second, 초당 거래량)는 7TPS 정도인 것에 비해 이더리움은 30TPS 정도입니다. 비트코인의 속도보다는 빠르지만 실생활에 적용 가능할 정도로 빠르지 못합니다.

( ii ) 크립토키티(cryptokitties)

---

이미지 출처: cryptokitties

cryptokitties는 2017년 12월에 출시된 이더리움 기반 가상 고양이 기르기 게임입니다. 같은 종류의 대체 가능한 토큰인 ERC20 기반의 이더리움 토큰과 달리 크립토키티는 대체 불가능한 토큰(NFT, Non-Fungible Token)인 ERC-721 토큰을 사용합니다.

특별한 특성을 가진 가상의 고양이를 하나 받고, 각기 다른 고양이와 짝짓기를 하여 새로운 특성을 갖는 고양이를 낳습니다. 그리고 이 고양이들을 서로 이더를 이용하여 사고팔 수 있으며, 일정량의 거래수수료를 개발사인 DapperLabs 에서 가져갑니다.

위에서도 설명했다시피 크립토키티를 이용하고자 한 이용자들도 많아지고, ICO에 의한 이 더 수요와 거래량 폭주로 이더리움 네트워크가 마비되기 일쑤였습니다. ICO에 참여하기 위해 비싼 가스 수수료를 지불하거나, 그나마 지불해도 기본 30분 이상 기다려야 하는 경우가 다반사였습니다. 이더리움의 네트워크가 일상에서 사용할 만큼의 거래량을 감당하지 못한 것이 드러난 것입니다.

( b ) 이더리움의 확장성(Scalability)을 늘리기 위한 시도

---

이더리움은 POS 방식 전환 이외에도 확장성을 늘릴 다양한 방법을 제시하고 있습니다. 그중 아래 방법을 소개하는데, 자세한 설명은 이 포스팅의 범위와 저자의 역량을 벗어나므로 매우 간략하게만 정리하겠습니다. 아래에 설명한 방법 이외에도 블록체인의 확장성을 늘리고자 하는 시도는 많습니다.

( i ) 사이드 체인(sidechain)

---

이미지 출처: Bitcoin Wiki - Blockchain Sidechain

이더리움의 확장성 문제를 사이드체인을 이용하여 해결하고자 하는 시도들이 있습니다. 물론 사이드체인이라는 개념은 이더리움의 확장성을 해결하기 위해 탄생한 개념이 아니고 이전부터 존재했었던 개념이었습니다. 사이드체인은 단일체인에서 모든 거래를 처리해야 하는 부담을 줄여줍니다.

사이드체인을 이용하면 메인체인에 있는 자산을 동결시키는 동시에 사이드체인에서 그에 상응하는 자산 '상응물'을 생성하고 이에 대한 거래를 검증하게 됩니다. 사이드체인 내에 있는 '상응물'에 대한 거래와 검증이 모두 완료되면 이 '상응물'을 제거하면서 동시에 메인체인에 있는 자산의 동결을 풀고 사이드체인에서 했던 동일한 거래내용을 반영합니다.

이더리움의 한계점과 논외로, 사이드체인을 이용하면 블록체인의 확장성(Scalability)뿐만 아니라 상호운용성(Interoperability)도 해결할 수 있을 것으로 평가되고 있습니다. 쉽게 이해하자면 비트코인과 이더리움은 다른 블록체인을 기반으로 하는 토큰인데, 사이드체인을 이용하면 이더리움 체인 상에서 비트코인을 거래할 수 있고 반대로 비트코인 체인상에 이더기반의 자산을 거래할 수 있게 되어 암호자산 간의 이동이 자유로울 수 있게 됩니다.

( ii ) 샤딩(sharding)

---

샤딩의 shard는 '조각'이라는 의미이며, 한개의 큰 덩어리가 여러 개의 조각으로 나뉘는 것을 생각하면 됩니다. 원래 샤딩이라는 개념은 블록체인이 아니라 데이터베이스의 정보처리 방법에서 나왔습니다. 대용량의 데이터를 처리하기 위해 데이터를 여러 조각으로 쪼개서 저장함으로써 효율적으로 처리할 수 있습니다.

블록체인에서 샤딩은 전체 네트워크를 나누어 거래내역을 서로 다른 영역별로 조각을 내어 저장하여 이를 On-Chain에서 병렬적으로 검증하는 방법입니다. 예를 들어, 메인체인에서 처리해야 할 100개의 거래내역을 10개의 다른 샤드(shard)로 나누어 처리하면 각각의 샤드가 10개씩 거래내역을 처리하는 방식입니다. 이러한 방법을 통해 한 개의 블록에 모든 거래내역을 처리하여 과부하를 일으키지 않고, 나누어서 처리하기 때문에 확장성을 늘릴 수 있게 됩니다.

( iii ) 플라즈마(plasma)

---

이더리움의 확장성을 늘리기 위한 하나의 방안으로 플라즈마 솔루션을 제시하고 있습니다. 플라즈마에 대한 자세한 설명은 Plasma 총정리 : 이더리움 확장성 솔루션에서 읽어 보실 수 있습니다. 플라즈마 기술에 대해 깊이 있게 공부해보고 싶으면 읽으시면 되고, 본 글은 일반 투자자를 위한 글이므로 간단한 개념만 짚고 넘어가겠습니다.

On-chain에서 모든 거래를 해결하는 샤딩과 달리 플라즈마는 child-chain(하부 체인)을 이용합니다. 이러한 하부 체인을 둠으로써 블록체인에 담아야 할 정보량을 최소화할 수 있습니다. 이더리움 체인인 root-chain(이더리움 메인넷)에서 중요한 거래를 처리한 후, 거래의 결과값만 root-chain에 올려주기 때문에 이더리움의 부담을 덜어줄 수 있기 때문입니다.

암호자산을 플라즈마 체인에서 가치를 이동(deposit) 할 수 있으며, 필요할 때 root-chain으로 이더로 가치를 반환(exit)할 수 있게 됩니다. 되돌리는 과정에는 악의적인 거래인 경우 반환을 거절할 수 있습니다.

3) 한계점 3: Code-is-Law

---

( a ) 비가역적 계약

---

Code-is-Law 개념은 [블록체인 스터디 노트 #7] Ethereum의 탄생: 분산화 된 애플리케이션 플랫폼에서 간단하게 언급한 적이 있습니다. 이더리움의 기반의 탈중앙화 애플리케이션은 체인 상에 올리면 개발자조차도 수정하지 못하고, 커뮤니티의 합의에 따라 하드포크를 함으로써 오류가 없는 새로운 프로그램으로 재 업로드해야 합니다.

하지만 이러한 계약의 내용을 바꾸고 dApp의 사용을 지속하고자 하면, 개발자는 이용자들에서 새로운 버전의 하드포크를 진행하니 합의를 얻어야 합니다. 그리고 이러한 합의를 얻기 위해 수많은 시간이 걸리거나 아예 달성하지 못할 수도 있습니다.

( b ) 비가역적 계약의 문제점

---

개발자들도 사람이라서 코드의 오류나 버그가 항상 존재하며, 버그로 인해 오류 수정이 원활하지 못하다면 이용자들은 dApp 사용을 중지할 수밖에 없습니다. 코드 수정을 커뮤니티의 합의 없이 개발자들 마음대로 함부로 하지 못한다는 점에서 탈중앙화를 달성했을지는 몰라도 상업적 측면에서는 최악의 결점이 됩니다.

계약 코드를 수정할 수는 있으나 개발사에서 버그를 없앤 계약을 이더리움 체인 상에 다시 deploy 하여 swap 작업을 진행해야 합니다. 코드 수정이 유연하지 못하니 심각한 결함을 발견하면 커뮤니티 대부분의 구성원들은 자기 시간과 자원을 투자해서 하드포크 투표에 동참하느니 토큰 가격이 내려가기 전에 거래소에 재빨리 팔아버리는 것이 경제적으로 더 이득입니다.

최악의 경우는 dApp 시스템에 피해를 준 당사자 혹은 이해 관계자들이 부당하게 얻는 토큰으로, 원활한 시스템 업로드 혹은 하드포크를 방해하는 것입니다. 이전 글인 [블록체인 스터디 노트 #8] Ethereum의 역사: 발자취와 로드맵에서의 DAO 해킹 사건이 대표적인 예시입니다. 해킹을 통해 부당하게 얻는 이더를 롤백하는 하드포크를 진행한 이더리움 체인과 탈중앙화의 가치를 지켜야 한다는 이유로 하드포크에 동참하지 않아 찢어진 이더리움 클래식이 생기게 되었습니다.

( c ) 문제점 예시 - SMT(SmartMesh) 토큰 해킹 사건

---

DAO 해킹 사건 이외에도 2018년 4월 25일에 생긴 ERC20 기반의 토큰 SMT(SmartMesh)의 해킹 사건이 일어났습니다. 바로 해커는 오버플로우(overflow) 의 약점을 이용하여 토큰을 무한히 생성한 사건입니다.

오버플로우(overflow): 이더리움 프로그래밍 상에 선언한 변수가 제한한 표현형을 넘어갈 경우 0으로 시작되는 현상

사건에 대한 더욱 자세한 정보는 SMT(SmartMesh) 토큰 무한생성 해킹 설명과 대비책이란 글에서 확인하실 수 있습니다. 우선 SMT 개발사에서 자체적으로 만든 함수인 transferProxy() 에서 문제가 일어났습니다. 이 함수는 이더가 없는 사용자가 다른 제 3자를 이용해 SMT 토큰을 수수료로 내고 토큰을 송금할 수 있는 기능으로, 크게 아래의 3가지 단계가 있습니다.

• 보내는 계정의 잔액이 충분한지 확인 (보내는 계정의 잔고가 보내는 토큰의 수량보다 많아야 함)
• 거래의 서명 값이 보내는 계정과 일치하는지 확인
• 토큰을 송금

여기서 해커는 코드의 취약점을 파악하고, 송금하는 토큰의 수량을 큰 값을 입력하여 오버플로우를 일으킵니다. 실제 해커는 매우 큰 값을 일으켰음에도 코드상에서는 '0'으로 인식하여 보유하고 있던 토큰보다 적은 수량을 보냈다고 인식합니다.

해커는 무려 65,133,050,195,990,400,000,000,000,000,000,000,000,000,000,000,000,000,000,000개와 50,659,039,041,325,800,000,000,000,000,000,000,000,000,000,000,000,000,000,000개의 토큰 을 생성하고 10,000,000,000,000,000개의 토큰을 후오비 거래소로 송금하였습니다. 그리고 부당하게 생성한 토큰을 판매한 것으로 추정되고 있습니다.

물론 이 사건은 ERC20의 취약점은 아닙니다. 이더리움 재단에서는 이전부터 이와 같은 문제를 여러 번 보고받았고, dApp 개발사들이 공식함수인 SafeMath() 함수를 사용하도록 권장하였습니다.

이 사건의 본질은:

• 함량 미달의 dApp 개발사들이 공식함수를 쓰지 않고 커스텀 함수를 사용한 것
• 소스코드에 대한 기본 단계인 감사(audit)를 진행하지 않은 것
• 그런 취약점이 있는 토큰을 무분별하게 상장시킨 거래소들

하지만 여기서 지적하고자 하는 것은 이더리움의 비가역적 계약은 이러한 문제가 발생했을 시에 빠르게 대처하지 못한다는 문제점이 존재한다는 것입니다.

4) 한계점 4: Oracle Problem, 현실세계를 반영하지 못하는 체인

---

( a ) Oracle Problem 이란

---

오라클 문제(Oracle problem): 외부 데이터를 블록체인 내부로 가져올 때 발생하는 다양한 문제

앞서 언급했듯이, 이 오라클 문제(Oracle problem) 는 이더리움 블록체인만의 문제는 아니며 이오스를 포함한 모든 블록체인이 갖고 있는 한계점입니다. 이것은 현실 세계의 데이터와 블록체인상의 데이터 연결에 관한 문제이기 때문입니다.

블록체인상의 노드가 어떤 거래나 데이터를 생산할 때, 선의의 노드는 그 데이터를 검증하고 분산원장에 기록하여 데이터의 조작을 불가능하게 함으로써 무결성을 유지합니다. 하지만 이 데이터는 블록체인상에서 생산한 것에만 국한되고, 외부세계에서 들여오는 데이터는 다릅니다. 외부 데이터 자체가 조작되었는지 자체를 블록체인상에서 판단할 수 없기 때문입니다.

( b ) Oracle 의 종류

---

( i ) 하드웨어 오라클 (Hardware Oracle)

---

물리적인 데이터에 대한 오라클을 의미합니다. 예를 들어 GPS를 기반으로 한 위치정보, 카메라에 찍힌 이미지나 영상, 날씨 그리고 온도 같은 데이터가 대상입니다. 이러한 정보를 데이터화하여 블록체인 네트워크에 제공할 수 있는데, 데이터의 신뢰성에 문제가 있을 수 있습니다.

만약 아이스크림 회사가 소비자의 아이스크림 소비패턴에 따라 아이스크림을 얼마나 생산해야 하는지 가정해봅시다. 아이스크림은 냉장으로 보관해야 하므로 소비자의 수요를 정확하게 예측할수록 재고를 줄일 수 있습니다. 데이터 제공회사와 계약을 맺어 날씨와 온도 데이터, GPS 정보를 이용하여 소비자가 어느 지역에 얼마나 더울 때 아이스크림을 사 먹는지 데이터를 받을 수 있을 것입니다. 여기서 회사에서 빅데이터 기술을 적용한 smart contract 로 적시 적소에 아이스크림 생산량을 자동으로 정할 수 있게됩니다.

그런데 여기서 문제가 발생합니다. 만약 날씨, 온도 센서가 고장 난다면 누가 그 데이터의 진위를 알 수 있을까요? 데이터 제공자가 더운 날 아이스크림 가게까지는 들어왔는데 아이스크림을 구매했다는 것을 어떻게 판단할 것이며 어떻게 신뢰할 수 있을까요? 여기서 하드웨어 오라클 문제가 발생합니다.

( ii ) 소프트웨어 오라클 (Software Oracle)

---

온라인상의 데이터에 대한 오라클을 의미합니다. 예를 들어 실시간 환율정보, 인터넷상의 문서기록, 각종 데이터 그리고 날짜/시간과 같은 데이터가 대상입니다. 대부분 데이터는 온라인상에 신뢰할 수 있는 제 3자가 생산한 것입니다.

블록체인 암호자산 dApp 이 사용자가 원하는 조건에 따라 smart contract 에 의해 자동으로 자신의 계정에서 일정 부분의 암호자산을 자동으로 거래소로 보내고 팔아서 법정화폐로 바꿀 수 있도록 연동해 놓았다고 가정합시다. 보통 암호자산 지갑 dApp 에서 유용하게 쓸 수 있는 기능이 될 것입니다.

( iii ) 다른 종류의 오라클

---

• 인바운드 오라클 (Inbound Oracle): 외부세계에서 블록체인상에 데이터를 전송하는 것입니다.

• 아웃바운드 오라클 (Outbound Oracle): 블록체인상에서 외부세계로 데이터를 전송하는 것입니다.

• 합의 기반 오라클 (Consensus Based Oracle): 합의 메커니즘에 의해 생산된 블록체인상에 데이터를 전송하는 것입니다. 예를 들어 미래 예측 시장 플랫폼인 Augur와 Gnosis 가 있습니다.

( c ) Oracle Problem 을 해결방안

---

오라클 문제를 해결하고자 하는 여러 방안 중 크게 두 가지 방안을 소개하겠습니다.

( i ) 미들웨어(Middleware)

---

이미지 출처: New blockchain integrations and beyond

블록체인 dApp 개발사가 자체적으로 오라클 모델을 만들 필요 없이, 오라클 전문 미들웨어에서 검증된 외부 데이터를 제공받을 수 있습니다. Smart contract에 필요한 API를 미들웨어에서 제공해주는 방식입니다. 하지만, 미들웨어에서 제공한 데이터의 무결성 역시 100% 보장할 수 없습니다.

( ii ) 지분증명(POS, Proof of Stake)

---

POS (지분증명) 합의 알고리즘을 이용하여 블록체인상에서 오라클 모델을 구성할 수 있습니다. Augur와 같은 예측 시장 플랫폼이 대표적인 예시인데, 토큰의 지분을 보유한 노드가 데이터의 진위 여부를 투표를 통해 결정하여 오라클 모델을 구축하는 식입니다.

POS 방식이기 때문에 데이터의 통과 여부는 과반수(51%)의 득표를 얻은 쪽으로 블록체인 네트워크에 저장이 되며, 진실된 데이터를 검증한 노드는 보상을 받고 그렇지 못한 노드는 토큰을 잃습니다. 물론 이 모델의 취약점은 토큰의 과반수를 확보할 수 있는 소수의 노드가 체인을 독점하면 거짓된 데이터도 투표에 통과되므로 완벽히 오라클 문제를 해결했다고 볼 수 없습니다.

5) 결론

---

이번 포스팅에서 이더리움의 대표적인 4가지 한계점들에 대해 설명하면서 이더리움 파트를 마무리하였습니다.

dApp의 실사용을 위해 가스는 불편하며, 거래 속도가 느리다는 단점이 있었습니다. 그리고 소프트웨어에 버그가 존재할시 코드의 수정이 불가하다는 것과 모든 블록체인이 안고 있는 오라클 문제가 존재합니다.

다음 포스팅부터는 프라이빗 블록체인 기반의 암호자산에 대한 포스팅을 올리겠습니다.

4)참고자료 및 각주

---

참고문헌:

• [1] 쉬밍성, 티엔잉, 리지위에, 알기쉬운 블록체인(광문각, 2017)
• [2] 다니엘 드레셔, 블록체인 무엇인가(이지스 퍼블리싱, 2018)
• [3] 안드레아스 M. 안토노풀로스, 비트코인, 블록체인과 금융의 혁신 (Mastering Bitcoin)(고려대학교 출판문화원, 2015)
• [4] 크리스 다넨, 이더리움과 솔리디티 입문: 이더리움을 이용한 블록체인과 암호화폐 개발 이론과 실무 (Introducing Ethereum and Solidity)(위키북스, 2018)
• [5] 이더리움의 기술적 한계 (1) [EOS 개발 입문 4] devEOS openclass
• [6] 이더리움의 기술적 한계 (2) [EOS 개발 입문 5] devEOS openclass
• [7] How Dapps Work in 2018 ~ "Dawn of the Dapps"
• [8] 사이드체인 (Sidechain)
• [9] 블록체인 확장성 솔루션 시리즈 4–1 :: Sharding 샤딩
• [10] Plasma 총정리 : 이더리움 확장성 솔루션
• [11] SMT(SmartMesh) 토큰 무한생성 해킹 설명과 대비책
• [12] 블록체인(On-Chain)과 외부 세계(Off-Chain)를 이어주는 가교 ‘오라클(Oracle)’

---

긴 글 읽어주셔서 감사합니다.
여러분의 팔로우+업보팅+리스팀은 저에게 힘이 됩니다.

---

_{Sponsored ( Powered by dclick )}

종로 양꼬치

^{종로 젊은의 거리 안쪽에 들어오시면 종로 양꼬치 전문점이 약간 구석에 위치해 있습니다. 최근에...}