안녕하세요, 이댕댕입니다! 마지막으로 EOS 백서 정리 시작하겠습니다.

운영(Governance)

운영은 다음과 같은 세가지를 말합니다.

1.소프트웨어 알고리즘만으로 완전히 해결할 수 없는 집단 행동의 주관적 문제에 대한 합의를 도출하는 것
2.도출된 합의를 수행하는 것
3.헌법 수정안을 통해 운영 규칙 자체를 변경하는 것

말 그대로, 블록체인 생태계를 어떻게 운영하여 나아갈 것인가에 관한 내용입니다. 타 블록체인에서는 운영절차가 비공식적이고, 임시적으로 바뀌는 경우가 있습니다. EOS에서는 토큰 보유자에서 권한을 얻은 BP가 결함 있는 애플리케이션 업데이트, 계정 동결, 하드포크 변경 제안 등의 권한을 행사하면서 운영을 이끌어나갑니다.

계정 동결

어떤 계정이 자원을 비정상적으로 소모하는 등 문제가 발생했을 경우, BP가 해당 계정을 동결하여 문제가 퍼지는 것을 막을 수 있습니다. BP는 어떤 트랜잭션이 블록에 포함되는 지 결정할 수 있으므로 15/21 표결을 통해해당 계정과 관련된 트랜잭션들을 배제하여 계정을 동결할 수 있습니다.

계정 코드 변경

다른 대응책들이 모두 실패했을 경우, BP는 15/21 표결을 통해 블록체인을 하드포크하지 않고 해당 계정의 코드만 변경합니다.

헌법

P2P 서비스 계약이나, 서명한 사용자 간 구속력을 가지는 헌법이 있습니다. 단순 코드로 강제할 수 없는 사용자 간 의무, 규칙을 정해 분쟁을 쉽게 해결합니다. 모든 트랜잭션 안에 헌법의 해시를 서명의 일부로 포함시켜 사용자가 헌법을 따른다는 것을 서명에 포함시킵니다. 이 헌법은 BP가 헌법 변경을 제안하고 표결을 통해 헌법을 변경할 수 있습니다.

스크립트 & 가상 머신

결정론적이고 정확한 샌드박스 처리를 제공하는 모든 언어, 가상 머신은 EOS.IO API와 통합될 수 있다고 합니다. 즉, 여러 언어와 머신들을 지원한다는 얘기입니다.

EOS에는 액션과 DB를 스키마로 정의하여 저장합니다. 스키마는 어떤 약속 같은 거여서, DB 상의 스키마는 DB에 저장되는 데이터 구조를 어떤 식으로 하겠다와 같은 약속을 의미합니다. 액션 상의 스키마도 어떤 식으로 액션을 정의하겠다 이런 내용이겠죠?

애플리케이션에서 인증을 분리

병렬화를 극대화하고, 애플리케이션 상태 재생성 연산을 최소화하기 위해서 검증 로직을 다음과 같이 분할 하였습니다.

1.액션의 내부 일관성 검증
: 읽기 전용이고 블록체인 상태에 액세스 필요 없음.-> 병렬 가능

2.모든 선행조건의 타당성 검증: 필요 잔고 등을 검사하는 과정, 읽기 전용 -> 병렬 가능

3.애플리케이션의 상태 수정: 쓰기가 필요함. 순차적 처리 필요.

블록체인 간 통신

EOS는 블록체인 간의 통신을 지원합니다. 다른 외부체인과 통신했을 때, 트랜잭션이 그 외부 체인에서 번복할 수 없고 확정되었다는 것을 쉽게 증명하고 확인할 수 있게 설계되었습니다.
비트코인에서 라이트노드와 풀 노드, 머클트리를 통해 검증의 효율성을 높인 것처럼 EOS도 유사한 방법을 씁니다.

LCV(Light Client Validation)이라는 방법을 쓰는데, 경량의 데이터를 추적해서 여기까지는 검증되었다는 경량의 존재증명을 만듭니다. 그러면 다음 노드에서 이 증명을 포함하여 또다른 경량의 데이터들에 대해서 검증을 하고 또다른 경량의 존재증명들을 만듭니다. 이런 식으로, 검증되었다는 검증 내역들을 계속 포함하면서 노드들이 경량의 데이터만 검증해도 이미 전의 내용들은 검증된 내역이기 때문에 검증을 완료할 수 있게 됩니다.

https://camo.githubusercontent.com/d1247e97697c62a84ed549bb9b00f601beb013a0/687474703a2f2f656f732e696f2f7770696d672f4469616772616d312e6a7067

위 그림이 LCV 방식에 대한 것인데요, 자세한 내용이 없어서 저도 이해는 조금 힘들었습니다. 위의 내용에 비추어 생각하면,

우선, 이미 모든 검증이 완료되어 블록이 연결되어 있고, 이 블록의 머클루트 값이 있습니다. 라이트 노드는 최신의 트랜잭션들만 검증하고, 가장 최근까지 블록의 머클루트 값을 마지막 트랜잭션에 포함시킵니다. 이렇게 포함시킴으로써 가장 마지막 블록까지의 검증은 할 필요가 없게 됩니다. 즉, 최신의 트랜잭션들만 검증하면 됩니다.

이렇게 검증된 것들을 꼬리 무는 식으로 연결하여 검증의 효율성을 높인 방법 같습니다.(혹시 자세하게 아시는 분이 있으면 알려주세요!)

이런 검증 방식으로 외부 체인과 통신하는데, 트렌잭션이 외부 블록체인에서 확정되었을 때 이 트랜젝션이 정당하다고 판단할 수 있습니다. 확정될때까지의 시간을 체인 간 통신의 지연 시간이라고 하는데, 블록 생산 간격 0.5초의 DPOS를 사용하면 0.5초 정도가 소요됩니다.

완전성 증명

외부 블록체인에서 머클 증명을 사용할 때, 어떠한 트렌젝션도 건너뛰지 않고 타당하다는 것을 인지하는 것이 중요합니다. 최근의 모든 트랜잭션들이 알려졌다는 것을 증명하기는 불가능하지만, 트랜잭션 이력에 빈틈이 있는지는 확인 가능합니다. EOS에서는 모든 액션에 일련번호를 할당하여 건너뛴 트랜잭션이 없는지, 순차적으로 잘 처리되었는지 확인할 수 있습니다.

증인 격리(분리)

증인 격리(Segregated Witness, SegWit)은 서명된 트랜잭션이 블록체인이 포함되면, 이미 비가역적이기에 서명 데이터를 잘라내도 현재 상태를 파악할 수 있다는 내용입니다. 서명이 트랜잭션의 많은 부분을 차지하기 때문에, 세그윗을 적용하면 디스크 사용량, 동기화 시간을 절약할 수 있습니다.

이 개념을 블록체인 간 통신에도 적용할 수 있는데, 일반 서명을 절약하는 것보다 32배 더 절약할 수 있다고 합니다.

스팀잇에도 세그윗이 적용됩니다. 블록체인 위에는 블로그 내용 해시만 포함되고, 블로그 내용은 격리된 증인 데이터에 포함됩니다. 즉, 핵심적인 내용만 블록에 담아 시간과 공간을 절약한다는 내용입니다.

정리

6일정도로 천천히 EOS 백서를 읽어보았습니다. 백서를 읽으면서, 블록체인간의 통신, 계정에 관한 내용, LCV 방식 등이 인상 깊었네요. 그만큼 많은 것을 설계하고 고려한 블록체인이라는 생각이 들었습니다.

EOS에 조금 의문이 드는 것은,

21명의 BP가 과연 답합하지 않고 블록체인을 이끌어갈수 있을까. BP에게 주어진 권한이 생각보다 크기 때문에 BP가 자신의 이익만 생각하여 블록체인을 이끄는게 아닐까 생각이 들었습니다.
투표율의 문제. EOS가 지속적으로 성장하기 위해선 많은 토론, 논의, 투표가 필요하다고 생각합니다. 다만, EOS를 갖고 있는 사람들 반 이상은 EOS에 대해서 잘 모르고 투자한 사람일 것 같고, EOS의 기술적, 정책적 모델엔 대해서 잘 모르는 사람도 많을 것 같아 투표율이 매우 저조할 것 같습니다. 그러면 거래소에서 대신 투표를 하는 식으로 할텐데 과연 올바르게 흘러갈 수 있을까 의문이 듭니다.

다만, 스팀잇의 성공을 보면 이런 걱정은 줄어들긴 하네요. 그러나 스팀보다 규모가 더 커서 어떻게 흘러갈지는 잘 모르겠습니다ㅎㅎ

EOS에 대해서 찾다가 재밌는 글을 찾았습니다.

http://www.hashedpost.com/2017/08/hashed-report-vs-eos.html

이 링크를 보시면, 이더리움과 EOS와 관련한 재밌는 논쟁 해설이 있습니다. 이더리움과 EOS 모두 훌륭한 블록체인 플랫폼이라고 생각하는데요, 개인적으로 블록체인 플랫폼 상에서 높은 점유율을 위해서는 중앙화 요소보다는 확정성이 아닐까 생각합니다.

나중에, 대중들이 쓸 때는 탈중앙화는 크게 관심을 가지진 않을 것 같아요. 사실 블록체인 기술 자체에도 관심이 별로 없을 것 같습니다. 기술이 중요한게 아니라 내가 쓰는 것이 중요하거든요.

그저, 기존 방식처럼 빠르게 주어진 서비스를 이용할 수 있는 지가 대중이 플랫폼을 받아들이는 기준이 되지 않을까요? 그 외에도, 블록체인을 받아드리면서 기존에는 없었던 신뢰성, 인센티브 시스템 정도가 대중들을 이끌 수 있을 것 같네요.

이상, 이댕댕이었습니다!