[Smart Contract 개발] #8 이더리움 핵심 개요 정리 2

이전글에 이어서 이더리움 개발에 필요한 핵심 개요 정리를 이어가 보겠습니다.

이전글 - [Smart Contract 개발] #7 이더리움 핵심 개요 정리 1

역시 이번에도 다음 책의 내용을 바탕으로 내용을 요약합니다.

이더리움을 활용한 블록체인 프로젝트 구축, 나라얀 프루스티 저

블락 생성 시간

이더리움 블락 생성 주기는 10초-20초 사이입니다. 블락 사이즈는 찾아보니 현재는 약 30KB (킬로 바이트) 정도입니다.

출처: https://etherscan.io/chart/blocksize

이더리움의 경우는 비트코인과 달리 블락 사이즈가 점점 증가하고 있습니다. 즉 초당 처리할 수 있는 거래가 증가하고 있는 것입니다. 블락 생성 시간을 15초라고 보고 블락 사이즈를 30KB로 하면, 초당 처리할 수 있는 데이터 사이즈는 2KB입니다.

30KB/15= 2KB

비트코인의 경우는 블락 사이즈가 약 1MB로 고정되어 있고 (BIP 102 :블락 크기를 2MB로 확장하자는 제안 미반영), 블락 생성시간을 약 10분이기 때문에 초당 처리할 수 있는 데이터 사이즈는 1.67KB 입니다.

1000KB/(10*60)= 1.67KB

계산해 보니, 이더리움이 비트코인보다 훨씬 더 많은 량의 거래를 처리하는 것처럼 느껴지나, 실제로 계산해 보면 처리할 수 있는 데이터량을 비슷한 수준입니다.

블락 생성 시간은 매우 중요합니다. 블락 생성이 매우 빠르면, 즉 블락 생성 난이도가 낮으면 네트워크의 보안 수준으 나빠집니다. 반대로, 블락 생성이 매우 느리면, 즉 블락 생성 난이도가 높으면 네트워크 보안 수준은 올라가지만, 언제 블락이 생성되는지 알기 어렵기 때문에, 트랜잭션 처리가 언제 될지 예측하기 어려운 문제가 발생하게 됩니다. 따라서 적절한 블락 생성 시간이 설정되어야 하는 것입니다.

만약 두 채굴자가 거의 비슷한 시간에 블락을 채굴한다면 어떻게 처리해야 할까요? 앞서 이더리움 네트워크는 총 블락의 난이도가 더 높은 체인을 선택한다고 했습니다. 그러면 난이도가 낮은 체인은 그냥 버리는게 좋을까요? 이처럼 선택되지 못한 블락을 스테일 블락(stale block)이라고 하는데, 이더리움에서는 스테일 블락을 엉클 블락(uncle block)이라고 부릅니다.

이 엉클 블락은 블락 생성 평균 시간이 짧아지면 자주 발생하게 됩니다. 왜냐하면, 채굴자가 블락을 찾아서 다른 노드에 전파시키는데 시간이 소요되는데, 블락 생성 시간이 짧다는 것은 채굴자들이 쉽게 퍼즐의 해답을 찾을 수 있다는 말이 되는데, 이렇게 되면 블락을 찾았다는 신호가 전달되기 전에 다른 채굴자가 새로운 블락을 찾을 수 있기 때문입니다.

그런데 이 엉클 블락의 문제점은 트랜잭션 confirmation을 늦춘다는 것입니다. 어떤 트랜잭션이 엉클 블락에 속한다면, 그 트랜잭션은 confirmation되지 못합니다. 즉 해당 트랜잭션이 포함된 블락이 다시 채굴되어야 합니다. 또 엉클 블락이 자주 발생한다는 것은 엉클 블락을 채굴하는데 그만큼 해쉬 파워가 소모되었다는 것입니다. 즉 해쉬 파워가 불필요한 곳에 사용된 것이지요. 이것은 평균 블락 생성 시간을 늦추게 되고, 평균 블락 생성 시간이 늦어졌기 때문에, 결국 난이도를 낮추게 되어 네트워크 보안 수준을 떨어트리는 문제까지 번집니다.

이더리움은 고스트 프로토콜(Ghost Protocol)이란 방식으로 이러한 엉클 블락 문제를 해결합니다. 즉 정상적인 블락들이 N개의 엉클 블락을 가질 수 있게 함으로써, 엉클 블락이 메인 체인에 붙도록 한 것입니다. 그렇게 되면 엉클 블락도 메인 체인에 속하므로, 난이도가 낮아지지 않는 효과를 가져옵니다.

출처: 이더리움 작동원리의 이해 https://www.ddengle.com/bitcoindeveloper_voted/3392079

엉클 블락도 메인 블락체인에 포함시키는 것을 장려하기 위해 엉클 블락을 찾은 채굴자도 보상을 받게 됩니다. 그러나 트랜잭션 수수료는 받지 않습니다.

Forking

출처

Forking이란 단어는 기존에도 쓰이던 개념입니다. 어떤 소스 코드가 있을 때, 그것을 콕 찍어서 원래 것과 다르게 자신의 고유의 소스 코드로 발전시킬 때 쓰는 용어입니다. Forking한 시점 이전까지는 같은 코드지만, 이후는 달라질 수 있는 것이죠. Github에 보면 forking이 몇 번되었는지, 즉 사람들이 어떤 코드를 몇 번 꼭 찍어 갔는지 카운트를 해주는 기능이 있습니다.

포크는 일반 포크, 소프트 포크, 하드 포크가 있습니다.

일반 포크: 앞서 봤던 둘 이상의 채굴자가 거의 동시에 불락을 채굴했을 때 발생합니다. 이런 경우는 난이도 높은 체인을 선택함으로써, 금방 해결됩니다.
소프트 포크: 체인의 충돌이 심각하여 채굴자의 절반 이상(엄밀히는 해쉬 파워의 50%)이 코드 업데이트를 해야 하는 경우 발생합니다. 예를 들어, 특정 블락 데이터를 변경시키고자 한다면 해쉬 파워의 50% 이상을 차지하는 채굴자들의 코드를 변경하면 됩니다.
하드 포크: 모든 채굴자가 코드 업데이트를 해야 할 때 발생합니다. 예를 들어, 채굴자의 보상 수식을 변경하려면 모든 채굴자가 코드 업데이트를 해야만 충돌을 해결할 수 있습니다.

Gas (개스)

모든 트랜잭션을 처리하는데 일종의 연산과 저장 공간이 필요합니다. 즉 비용이 발생하게 됩니다. 만약 트랜잭션 처리 비용이 없다면, 채굴자들은 트랜잭션을 블락에 포함시키지 않고, 빈 블락을 채굴해서 채굴 보상만 가져가려고 할 것입니다. 물론 빈 블락은 다른 노드들에 의해서 블락 유효성 검사 때 거부되겠지요.

트랜잭션 수수료는 (실제 사용된 개스량) x (발신자가 설정한 개스 비용) 으로 결정됩니다. 이 때, 채굴자가 설정한 개스 비용보다 낮은 비용으로 설정된 트랜잭션은 채굴자에 의해 거부될 수 있습니다.

부트스크랩 노드 (Bootstrap Node)

이더리움 네트워크는 중앙 서버가 없이 노드와 노드간의 연결로 된 분산 구조입니다. 그러나 한 노드가 네트워크 상의 모든 노드와 연결될 수는 없습니다. 그래서 하나의 노드는 주변의 노드들과 연결되고, 그 노드들이 다시 다른 노드들과 연결되는 구조를 갖게 됩니다. 이런 구조 때문에 네트워크 상에서 특정 노드를 찾는 문제가 대두됩니다. 이더리움 네트워크에서는 특정 노드를 빨리 찾기 위해서 부트스트랩 노드라는 것이 존재합니다. 부트스트랩 노드는 일정 기간 동안 연결됐던 노드들의 목록을 저장합니다. 노드가 이더리움 네트워크에 다시 접속할 때는, 부트스크랩 노드에 먼저 연결되게 되어 있습니다. 부트스크랩 노드를 구현 한 것 중 인기있는 것인 부트노드(bootnode)입니다.

블락체인 데이터의 빠른 동기화

이더리움 블락체인 데이터는 현재 500GB가 넘는 것으로 보입니다. 이더리움은 빠른 동기화 알고리듬을 구현해서 이 데이터를 빠르게 다운로드 하는 방법을 제공합니다. 아래 그림이 빠른 동기화(Fast Sync)의 블락체인 데이터 크기를 보여주고 있습니다. 지금은 약 44GB입니다.

출처

빠른 동기화는 한 블락의 전체 데이터를 다운로드 하는 것이 아니라, 다음과 같은 정보만 다운로드 합니다.

블락 헤더
트랜잭션 영수증 (transactions receipts)
데이터베이스 최신 상태

빠른 동기화로 받은 데이터의 무결성을 검사하기 위해서 지정된 블락마다 블락 전체 데이터를 다운로드 합니다.

이더리움 지갑

이더리움 지갑은 다음과 같은 작업이 가능한 것을 지칭합니다.

계정 생성
이더 송금
스마트 컨트랙트 배포
스마트 컨트랙트 함수 호출
옵션으로 UI 제공
geth를 포함. 지갑 프로그램 실행시 로컬에서 geth를 찾는데 실행되고 있는 geth가 없다면 자체 geth를 실행시킴.

Mist(미스트)는 단순히 이더리움 지갑뿐만 아니라 이더리움, 위스퍼(Whisper), 스웜(Swarm)의 클라이언트 기능이 있는 것입니다. 위스퍼는 탈중앙화 커뮤니케이션 프로토콜이고, 스웜은 탈중앙화된 분산 스토리지 플랫폼입니다. 참고로 geth는 이더리움, 위스퍼, 스웜 노드를 go 언어로 구현한 것입니다. 미스트는 브라우저 기능이 함께 제공되는데, web3.js 라이브러리를 이용해 geth 노드에 접근할 수 있습니다. 즉 브라우저에서 geth 기능을 사용할 수 있는 것이죠. 미스트는 앞으로 서버 없이 이더리움, 위스퍼, 스웜을 구현하는 3세대 웹을 구축하려고 합니다.

이더리움 약점

이더리움 네트워크의 약점은 DoS(서비스 거부)와 같이 일반적 약점 이외에 이더리움만의 독특한 약점이 크게 두 가지 입니다.

시빌 공격(Sybil Attack): 네트워크 공격자가 제어하는 일반 노드들로 네트워크를 구축하려고 하는 시도. 이렇게 되면 우리는 공격자의 노드들에 연결될 가능성이 높고, 일단 연결되면 공격자는 트랜잭션 처리를 거부할 수 있게 되고, 우리를 네트워크로 부터 고립시킬 수 있습니다.
51% 공격 (51% Attack): 공격자가 해쉬 파워의 51%를 점유하게 되면 다른 채굴자보다 빠르게 블락을 생성할 수 있게 됩니다. 공격자는 자신의 생성한 체인이 다른 노드들에게 인정될 수 있는 길이가 될 때까지 기다렸다가 전파 시켜서 체인의 내용을 변경시킬 수 있습니다. 50% 이상의 해쉬 파워가 있다면 그 채굴자는 트랜잭션을 변경할 수 있고, 특정 트랜잭션이 채굴되는 것을 금지시킬 수 있습니다.

지금까지 두 개의 포스팅에 걸처 이더리움 개발에 앞서 핵심 개념을 살펴봤습니다. 내용이 좀 방대한 느낌이지만, 이제 이런 개념을 잡고서 다음 부터 스마트 컨트랙트 개발을 위한 솔리디티 코딩에 들어가 보겠습니다.

오늘의 실습: 이더리움은 트랜잭션 실행시에 Gas가 필요합니다. Gas가 없다면 채굴자는 빈 블락을 생성하려고 할 것이기 때문에 gas는 필요해 보입니다. 그런데 어떻게 하면 트랜잭션 처리나 스마트 컨트랙트를 실행할 때 처리 비용을 없앨 수 있을까요? EOS는 어떤 방식으로 gas를 없앤 것일까요?