안녕하세요! 이댕댕입니다.

각 코인마다 비전이 다르고, 실현 가능성이 다르고, 적용할 기술이 조금씩 다를텐데 이를 비교하면서 공부해보면 좋은 도움이 될 것 같아, 블록체인 백서를 차근차근 읽으려고 합니다. 각 백서를 읽으면서, 추가적인 설명이 필요한 부분은 천천히 정리해보면서 나아가보겠습니다.

지금 생각하는 것은, 따끈따끈한 EOS와 스팀에 대한 백서를 읽고, 천천히 어떻게 다르고, 어디가 좋은지 고민해보는 시간을 가지려 합니다. 몇 백서를 읽은 후에는, dapp 만들어 보는 것을 공부해보려고 합니다!

첫 스타트는 이오스입니다.
EOS 백서 읽기 시작하겠습니다!

EOS 한글 백서 읽기:
https://github.com/eoseoul/docs/blob/master/ko/translations/TechnicalWhitePaperV2.md

초록: EOS.IO 소프트웨어는 탈중앙화 애플리케이션의 수직 및 수평 확장이 가능하게 디자인된 새로운 블록체인 구조를 소개합니다. 이것은 애플리케이션들(applications)을 만들 수 있는 운영체제와 유사한 구조를 생성함으로 가능합니다. 본 소프트웨어는 수백 개의 CPU 코어 또는 클러스터를 통해 계정(accounts), 인증(authentication), 데이터베이스(databases), 비동기 통신(asynchronous communication), 애플리케이션의 스케쥴링(application scheduling)을 제공합니다. 그 결과 초당 수백만 건의 트랜잭션 처리 능력을 갖추면서도, 수수료가 없고, 빠르고 쉽게 애플리케이션을 개발할 수 있는 블록체인 아키텍처 기술이 탄생했습니다.

이더리움 경쟁자라고 불리는 EOS입니다. 이더리움 이후로 생성된만큼, 초당 수백만 TPS를 지원하여 기업이 사용할 수 있는 Dapp을 지원합니다. 또한, 이더리움은 사용자가 수수료를 내면서 Dapp을 쓰는 구조인 반면, 이오스는 사용자에게 부과되는 수수료가 없는 모델을 제안합니다.

블록체인 애플리케이션의 요구사항 (Requirements for Blockchain> Application)
대중적으로 사용되기 위해서, 블록체인 위에서 돌아가는 애플리케이션은 다음의 요구사항을 만족하는 유연한 플랫폼을 갖춰야 합니다.

1.수백만의 사용자 허용 (Support Millions of Users)
2.무료 사용 (Free Usage)
3.간편한 업그레이드 및 버그 해소 (Easy upgrades and Bug Recovery)
4. 짧은 지연 시간 (Low Latency)
5. 순차(sequential) 처리 성능 (Sequential Performance)
6. 병렬 처리 성능 (Parallel Performance)

블록체인이 널리 사용될 수 있기 요구되는 사항들입니다. 수백만의 사용자를 수용가능해야 하며, 그 사용자들은 무료로 서비스를 사용할 수 있어야합니다. 순차 처리 성능, 병령 처리 성능이 높고, 지연 시간이 적어서 사용자가 지속적으로 블록체인 서비스를 사용할 수 있도록 합니다.

합의 알고리즘(BFT-DPOS)

EOS.IO는 DPOS 합의 알고리즘을 사용합니다. 현재 국회의원이 있는 대의 민주주의처럼, 나 대신 검증 및 블록 생성을 할 21명의 BP(Block Producer)를 뽑아 블록체인을 운영하는 형식입니다. DPOS 알고리즘은 다음 포스팅에 자세히 다루도록 하겠습니다.

EOS에는 라운드가 있습니다. 각 라운드에는 투표로 인해 선출된 21명의 BP들이 블록을 생성합니다. 블록은 0.5초마다 한 블록씩 생성되며 한 BP만이 하나의 블록을 생성합니다. 각 BP는 연속으로 6개의 블록을 생성합니다. BP들이 블록들을 생성하는 순서(ex BP1-BP2-BP3 ... -BP21)는 15명 이상의 BP가 합의한 순서에 따라 생산을 하게됩니다. 각 BP 당 6개씩, 21명의 BP가 있으니깐 126개의 블록이 한 라운드동안 만들어집니다.

한 BP가 자기 차례에 블록을 생성하지 못하고, 지난 24시간동안 블록 생산 기록이 없으면, 블록을 생성하겠다는 의사 표시 전까진 생산 순서에 제외됩니다. 트롤링하는 BP을 최소화하겠다는 것입니다.라운드가 끝나면 21명의 BP가 다시 투표로 인해 달라질 수 있습니다.

정상적인 경우 BP들이 협력하여 블록을 생산하므로 포크가 발생하지 않습니다. 다만, 포크 발생 경우 합의하에 가장 긴 체인으로 전환됩니다. BP가 많이 참여한 체인일 수록 길기 때문에 가장 긴 체인이 메인 체인으로 인정됩니다.

BP는 두 개의 포크에 블록을 생산할 수 없습니다. 또한, 모든 BP는 모든 블록에 서명하는데 동일한 타임스탬프, 높이를 가지는 두 블록에 서명할 수 없습니다. BFT 기능으로, 15명의 BP가 블록에 서명하면 해당 블록은 확정됩니다. BP가 이중 생산을 하거나, 이중 서명을 했을 경우 암호학적 증거가 남아 적당한 처벌을 받을 수 있습니다.

지분 증명 기반 트랜잭션(Transation as Proof of Stake, TaPoS)

모든 트렌젝션에 최근 블록 헤더의 해시 일부가 포함되어야 합니다. 이렇게 한 이유는
(1) 포함된 블록을 갖고 있지 않는 포크에서 트렌젝션이 재생되는 것을 막고
(2)특정 사용자와 그 지분이 어떤 포크 상에 존재한다는 네트워크에 알립니다.

트렌젝션에 최근 블록 내용을 포함하기 때문에 위조 체인 생성이 어렵습니다. 즉, 합법적인 체인이 있고 포크로 인한 체인이 있을 때 포크로 인한 체인이 합법적인 체인으로 위조하려고 시도할 수 있습니다. (1)과 (2)을 통해서 합법 체인에서 발생한 트렌젝션을 복사,재생 하는 것을 막아 위조 체인 생성을 막습니다.

계정

계정 내용이 참 재밌습니다. 우선, EOS.IO는 최대 12문자 길이의 이름으로 계정을 생성합니다. 스팀에서 우리가 설정한 이름이 지갑 주소가 되는 것처럼 말이죠. 계정을 만드는 사람은 새로운 계정을 만들때, 이 계정이 RAM을 예약할 토큰을 보유할때까지 RAM을 예약한다고 합니다. (이 부분은 아직 잘 모르겠습니다. RAM이 스팀잇에서 스팀파워와 비슷한 개념인 것 같습니다. 스팀잇에서 계정 생성을 위해서 스팀파워가 필요한 것처럼요)

애플리케이션 개발자는 새 사용자를 등록하기 위햇 계정 생성 비용을 지불합니다. 이 비용은 일반 기업이 고객을 모으는 비용보다 많이 저렴할 것이라고 합니다.

EOS 위의 스마트컨트랙트는 액션과 액션 핸들러의 조합으로 구성됩니다. 계정은 다른 계정으로 어떤 액션을 보냅니다. 액션을 받은 계정은 액션 핸들러를 가지고 있어서 받은 액션에 따라 다른 행동들을 할 수 있습니다. 액션 핸들러가 다른 계정에 액션을 보내게 설정할 수도 있습니다. EOS에는 각 계정에 자체 액션 핸들러가 접근할 수 있는 자체 데이터베이스를 제공합니다.

병렬 실행을 위해서 각 계정은 데이터베이스 안에서 얼마만큼의 범위를 쓸 것이더라고 정의할 수 있고, BP는 범위값에 따른 메모리 충돌이 일어나지 않도록 트랜잭션을 스케줄링합니다. (같은 데이터베이스 범위를 쓰는 트렌젝션들은 다른 블록에 넣는 식을 말하는 것 같습니다)

역할 기반 권한 관리

스팀잇을 보면 권한 코너에 포스팅키, 액티브키, 소유자키가 있습니다. 즉, 이 키를 다른 DAPP이나 다른 사람들에게 보여줌으로써 다른 사람들도 해당 계정의 어떤 일들을 할 수 있습니다. 예를 들어, 포스팅키를 넘겨주고 다른 사람이 자신의 계정에 포스팅할 수 있는것이지요. 하지만 그 사람은 포스팅키만 있으므로 지갑에서 돈을 전송하거나, 다른 키들을 바꾸거나 할 수 없습니다.

EOS에도 마찬가지로 한 계정을 한 사람만이 쓰는 게 아니라 여러 사람이 쓸 수 있도록 해놓았습니다. 사용자 지정으로 액션을 정의하고 이 액션은 어떤 권한을 가진 사람만이 할 수 있게 지정해놓았습니다. 모든 계정은 다른 계정과 개인키들의 가중치 조합으로 제어할 수 있습니다. 권한들은 그룹화를 할 수 있습니다. 예를 들어, '친구' 권한 그룹에 만들어 이 그룹에 있는 계정들은 나의 계정을 가지고 글을 쓰거나 할 수 있는 역할을 할 수 있습니다. 그리고 모든 것들은 기록이 되기 때문에 누가 어떤 권한으로 언제 무엇을 했는지 알 수 있습니다.

이 권한들은 부모-자식 관계를 가지고 있습니다. 계정으로 아주 사소한 역할만 할 수 있는 권한에서부터 모든 것을 관리할 수 있는 권한까지 있습니다. 어떤 액션이 발생하면 가장 밑의 권한부터 시작하여 해당 권한이 이 액션을 수행할 수 있는가?를 검사한 후 수행할 수 없으면 상위 권한으로 올라가 다시 검사하는 식으로 권한을 평가하고 유효성을 검증하게 됩니다. 이런 식으로, 실제 트렌젝션 검증의 상당 부분은 권한을 검증하는 것입니다. 하지만, 권한 검증은 병렬 평가가 가능하고, 중복된 권한 검사는 할 필요가 없기 때문에 빠르게 검증 처리할 수 있다고 합니다.

강제 지연과 관련된 액션

시간은 보안의 핵심 요소입니다. 어떤 개인키의 도용 여부는 해당 개인키가 사용될 때 알 수 있게 됩니다. 덕분에 개인키가 도용당했을때, 해당 개인키로 인해 액션이 발생해야 도용당했다는 것을 확인할 수 있습니다. 이런 문제점에 대한 해결책으로, 애플리케이션은 어떤 액션을 취할 떄 지연시간을 만듭니다. 이 시간동안 애플리케이션은 사용자에게 어떤 알림을 취할 수 있고, 도용당한 것이 확인되면 해당 액션을 철회할 수 있습니다.