백서 읽어주는 남자(eos 백서-8-마지막 편) @leesunmoo

leesunmoo (72)in #kr • 7 years ago

이오스 백서 읽어주는 남자 8번째 마지막 포스팅입니다.

이태민님이 번역하시고 조재우님이 감수하신 이오스 기술백서를 제가 가지고 있는 백서를 읽는 능력(?)을 바탕으로 이오스 백서를 읽어볼까 합니다. 혹 제가 잘못 이해하는 부분이 있다면 독자분들이 바로 잡아주시길 바랍니다. 그리고 제가 이오스 백서를 읽어드리는 목적은 이오스에 대한 이해를 돕기 위함이지 투자를 권유하기 위함이 아님을 분명히 밝혀둡니다.

한글 번역된 기술백서 링크-이태민님이 번역하시고 조재우님이 감수하심

https://steemit.com/kr/@leesunmoo/eos-leesunmoo
https://steemit.com/kr/@leesunmoo/eos-2-leesunmoo
https://steemit.com/kr/@leesunmoo/eos-3-leesunmoo
https://steemit.com/kr/@leesunmoo/eos-4-leesunmoo
https://steemit.com/kr/@leesunmoo/eos-5-leesunmoo
https://steemit.com/kr/@leesunmoo/eos-6-leesunmoo
https://steemit.com/kr/@leesunmoo/eos-7-leesunmoo

에 이어서 계속합니다.

블록체인 간 통신 (Inter Blockchain Communication)

EOS.IO 소프트웨어는 블록체인 간 통신이 쉽도록 설계되었습니다. 이는 메시지 존재 증명과 메시지 순서 증명의 생성을 손쉽게 함으로 이루어집니다. 이러한 증명들은 메시지 전달을 감싸는 애플리케이션 아키텍처와 결합하여 블록체인간 통신과 증명 검증 과정이 애플리케이션 개발자로부터 은닉되도록 합니다.

블록체인간 통신 부분은 이해가 난해한 부분입니다. 2017년 ico 열풍에 스모킹 건 역할을 한 것이 코스모스 블록체인이었을 겁니다. 코스모스 블록체인이 추구하는 것이 블록체인간 소통(?)으로 이해하고 있는 입장에서 이오스 블록체인이 블록체인간 소통을 쉽게 하도록 설계되었다는 기술백서 부분을 보는 순간 여차하면 이더리움뿐 아니라 코스모스 블록체인도 이오스 체인과 경쟁하겠구나 하는 생각을 하게 되었습니다.

경량화된 클라이언트 검증(LCV)을 위한 머클 증명 (Merkle Proofs for Light Client Validation)

클라이언트가 모든 트랜잭션을 처리할 필요가 없을 때 블록체인들을 결합하는 것이 쉬워집니다. 사실, 모든 거래소는 전체 블록체인 중 거래소의 입/출금에 대해서만 관리하면 됩니다. 교환 체인(exchange chain)의 입금 이력에 대한 경량화된 머클 증명을 이용하는 것은 블록 생산자 전체에 대한 신뢰성을 유지하는 것 보다 이상적입니다. 적어도 해당 체인의 블록 생산자들은 다른 블록체인과 동기화를 위해 최소한의 연산 부담을 받길 원합니다.
LCV(경량화된 클라이언트 검증)의 목표는 상대적 경량 데이터 집합을 보고 있는 누구든지 검증할 수 있는 상대적 경량 증명을 만들 수 있게 하는 것입니다. 특정 트랜잭션이 어떤 블록에 포함되어 있고, 그 블록이 블록체인의 인증 이력(verified history)에 포함되어 있는지를 증명하는 것을 목표로 합니다.
비트코인은 모든 노드가 블록 헤더에 기록된 4MB 가량의 모든 기록을 접근하는 것을 가정하고 트랜잭션의 검증을 수행합니다. 초당 10개의 트랜잭션이 발생할 경우, 유효한 증명(valid proof)은 512 바이트를 필요로 합니다. 10분의 블록 간격을 가지는 블록체인에서 이 방법은 사용할 수 있지만, 3초의 블록 간격을 가지는 블록체인에는 "경량"이 아닙니다.
EOS.IO 소프트웨어는 트랜잭션이 바뀌지 않는(irreversible) 블록 헤더에 포함된 이후, 해당 블록 헤더를 가진 누구나 경량 증명을 가능하게 합니다. 아래에 보이는 해쉬 연결 구조(hash-linked structure)를 이용하여 1,024바이트 이하의 증명(proof)을 가지는 모든 트랜잭션에 대한 존재 증명(existance prove)이 가능합니다. 유효성 검사 노드가 지난 하루 간(2MB의 데이터)의 모든 블록 헤더를 유지한다 가정하면, 트랜잭션의 검증을 위해서 200바이트의 증명이면 충분합니다.
경량 검증 방식을 도입하기 위해 적절한 해쉬-연결(hash-linking)이 포함된 블록을 생성하는 것의 추가 비용은 매우 적으므로, 이 방식으로 블록을 생성하지 않을 이유는 없습니다.
다른 체인에 속한 증명들을 검증할 경우 다양한 연산 시간/공간/대역폭 최적화가 가능합니다. 모든 블록 헤더(연간 420MB)의 추적(tracking)은 증명의 크기를 작게 유지하게 할 것입니다. 최근 발생한 헤더만 추적하는 것은 장기적 관점의 저장소 관리와 증명 크기 간의 절충이 발생합니다. 대안으로, 블록체인은 과거 증명의 중간 해쉬를 기억하는 지연 평가(lazy evaluation) 방식을 사용할 수 있습니다. 새로운 증명은 이미 알려진 희소 트리(sparse tree)에 대한 링크를 포함하면 됩니다. 어떤 방식을 사용할지는 머클 증명을 참조하는 트랜잭션을 포함하는 외부 블록의 비율에 따라 결정됩니다.
상호 연결이 일정 비율 이상 이루어진다면, 단순하게 다른 체인의 모든 블록 기록을 해당 체인이 가지게 하여 검증을 위해 두 체인을 볼 필요가 없게 하는 것이 효율적입니다. 성능 관점에서 체인 간 증명의 비율을 낮추는 것이 좋습니다.

이 부분은 무슨 소린지 저로서는 이해할수가 없습니다.

체인 간 통신의 지연 시간 (Latency of Interchain Communication)

외부의 다른 블록체인과 통신할 때, 블록 생산자는 적합한 입력값으로 받아들이기 이전에 다른 블록체인에서 바뀌지 않는 확인 상태에 돌입하였음을 100% 확신할 때까지 기다려야 합니다. EOS.IO 소프트웨어와 21명의 생산자와 3초 블록 생성 시간을 가지는 DPOS(지분 위임 증명; Delegated Proof-Of-Stake)를 이용할 때 약 45초가 걸립니다. 만약에 특정 체인의 블록 생산자가 바뀌지 않는 상태가 되는 것을 기다리지 않는다면 거래소에 취소한 입금이 승인되는 것과 같은 일이 일어나며 체인의 합의 검증에 문제가 발생할 것입니다.

블록체인간 소통함에 있어 서로 다른 블록체인의 블록타임(10분,2분30초,15초,3초 등등)으로 인해 상대 블록체인의 컨펌이 일정 수준 완료 되는 시점(바뀌지 않는 상태의 돌입)까지 기다려야 한다는 의미입니다.

완전성 증명 (Proof of Completeness)

블록체인 외부의 머클 증명을 사용할 때, 모든 트랜잭션이 수행 된 것을 확인하는 것과 무시하거나 빠진 트랜잭션이 없음을 확인하는 것은 상당한 차이가 있습니다. 최근의 모든 트랜잭션을 모두 알고 있음을 증명하기는 불가능하지만, 트랜잭션 이력의 빈틈(gap)이 없음을 증명하는 것은 가능합니다. EOS.IO는 모든 계정간 메시지 전달에 순서 번호를 부여하여 이를 가능하게 합니다. 사용자는 특정 계정에 대한 모든 메시지가 정상적으로 처리되었으며, 순서에 맞추어 처리되었음을 증명할 때 이러한 순서 번호를 사용할 수 있습니다.

결론 (Conclusion)

EOS.IO 소프트웨어는 검증된 개념과 실질적인 경험을 통해 설계되었으며, 블록체인 기술의 근본적인 발전을 대표하는 제품입니다. 이 소프트웨어는 전 세계적 규모의 블록체인의 탈중앙화 애플리케이션을 쉽게 구현하고 운영(governing)하는 전체적인 청사진의 일부입니다.

이오스 블록체인는 검증된 개념과 경험을 통해 설계되었다고 합니다. 즉 완성에 어려움이나 불확실성이 존재하지 않는다는 의미로 이해 됩니다.