이오스 백서 읽어주는 남자 4번째 포스팅입니다.
이태민님이 번역하시고 조재우님이 감수하신 이오스 기술백서를 제가 가지고 있는 백서를 읽는 능력(?)을 바탕으로 이오스 백서를 읽어볼까 합니다. 혹 제가 잘못 이해하는 부분이 있다면 독자분들이 바로 잡아주시길 바랍니다. 그리고 제가 이오스 백서를 읽어드리는 목적은 이오스에 대한 이해를 돕기 위함이지 투자를 권유하기 위함이 아님을 분명히 밝혀둡니다.
한글 번역된 기술백서 링크-이태민님이 번역하시고 조재우님이 감수하심
@leesunmoo/eos-leesunmoo
@leesunmoo/eos-2-leesunmoo
@leesunmoo/eos-3-leesunmoo
에 이어서 계속합니다.
메시지의 필수 지연 시간 (Messages with Mandatory Delay)
시간은 보안의 핵심 요소입니다. 대부분의 경우, 개인 키(private key)가 도난당한 경우 사용되기 전까지 알기 어렵습니다. 인터넷에 연결된 컴퓨터에 보관되는 키를 사용하는 애플리케이션을 일상적으로 사용하는 사람들에게 시간 기반의 보안은 더욱더 중요합니다. EOS.IO 소프트웨어는 애플리케이션 개발자가 특정 메시지가 블록에 포함되기 시작하고 적용되기 이전에 지정한 시간 만큼을 기다리도록 표시할 수 있게 합니다. 지정한 시간 내에서 메시지는 취소 가능합니다.
스팀 블록체인을 사용해 보신 분들은 스팀파워의 파워다운 13주나 쉐이빙 계정의 인출 소요 시간 3.5일 등을 기억하실 겁니다. 이처럼 자산 이동에 시간이 소요되도록 하는 것은 키를 도난당했을 때 매우 유용합니다. 이오스 블록체인은 스팀 블록체인보다 한 발짝 더 나아가 사용자가 해당 지연 시간을 임의로 직접 지정할 수 있는 것으로 보입니다.
사용자는 이메일이나 단문으로 메시지가 전송되었음을 안내받을 수 있습니다. 만약 본인이 한 것이 아니라면, 계정 복구 절차를 통해 계정 복구와 메시지 철회를 할 수 있습니다.
이오스 블록체인은 자금이 이체될 경우 이체 내역이 이메일이나 문자메세지로 안내됩니다. 만일 본인이 자금을 이체한
것이 아니라면 계정을 복구할 수 있고 이체 지연 시간을 설정했다면 전송을 철회할 수도 있다는 이야기 입니다.
요구되는 지연 시간은 작업의 중요도에 따라 다릅니다. 커피 한잔을 구매하는 것은 지연시간을 갖지 않아 몇 초 내로 취소 불가 상태가 되며, 집을 사는 문제라면 72시간의 거래 완료 조정 기간을 둘 수 있습니다. 전체 계정을 새로운 환경으로 전환하는 것은 30일의 유예기간을 둘 수도 있습니다. 실제 지연 시간은 애플리케이션 개발자와 사용자가 정하게 될 것입니다.
이체되는 자금의 규모나 사안의 중요도에 따라 지연 시간을 서로 다르게 설정할 수 있다는 의미입니다. 이렇게 멋진 보안기능이 있는 블록체인이 존재하거나 개발되고 있다는 소식을 이오스 이외에 들어본적이 저는 없습니다.
키 도난 상태에서의 복구 (Recovery from Stolen Keys)
EOS.IO 소프트웨어는 사용자의 키가 도난당하였을 때 계정에 대한 복구 작업을 제공합니다. 계정 소유자는 최근 30일 이내에 사용한 키를 가지고 지정된 계정 복구 협력자와 협력하여 계정을 재설정할 수 있습니다. 계정 복구 협력자는 소유자의 허가 없이 계정에 작업할 수 없습니다.
키를 가진 해커는 이미 계정을 제어할 수 있으므로 복구 프로세스를 시도하여 얻을 수 있는 것은 없습니다. 복구 프로세스에 진입하여도 복구 협력자는 추가적인 신분 증명이나 2채널 인증(핸드폰이나 이메일)을 요구할 것입니다. 이 과정에서 해커의 정체가 노출되거나 아무것도 얻지 않을 수 있습니다.
이 과정은 단순한 다중서명 합의(multi-signature arrangement)와 매우 다릅니다. 다중서명 트랜잭션의 경우 모든 트랜잭션에 관여하는 별도의 회사가 존재하는 것입니다. 복구 처리 과정을 이용하면 복구 협력자는 복구과정에만 관여하며 트랜잭션에 관해서는 어떠한 영향력도 행사하지 않습니다. 이로 인해 참여자들에 대한 비용과 법적 책임을 큰폭으로 감소시킬 수 있습니다.
이오스 블록체인은 스팀 블록체인처럼 자신의 계정이 도난당했을 경우 최근 30일 내에 사용했었던 키를 사용하여 도난당한 계정을 복구할 수 있다는 의미입니다.
애플리케이션의 결정론적 병렬 실행 (Deterministic Parallel Execution of Applications)
블록체인 합의(consensus)는 재현 가능한 결정론적 행위(deterministic behavior)에 달려있습니다. 이는 모든 병렬 실행은 뮤텍스(mutex)나 다른 기초 라킹 연산(locking primitive) 없이 수행되어야 함을 뜻합니다. 락(lock)이 없다면 다른 방식으로 모든 계정이 보유한 프라이빗 데이터베이스에만 읽기/쓰기 연산할 수 있도록 보장하여야 합니다. 또한 각각의 계정안의 메시지들을 순차적으로 처리하며, 연산의 병렬성은 계정 단위에서 수행됨을 뜻합니다.
EOS.IO 소프트웨어를 사용할 때, 메시지를 개별적인 쓰레드로 구성하여 병렬 평가되도록 하는 것은 블록 생산자가 수행하는 일입니다. 각각의 계정의 상태(state)는 전달받은 메시지에 달려있습니다. 블록 생산자의 결과물로 실행 스케쥴이 나오게 되며, 이는 결정론적으로 실행됩니다. 다만, 스케쥴을 만드는 과정까지 결정론적일 필요는 없습니다. 이는 블록 생산자가 트랜잭션을 스케쥴링 할 때 병렬 알고리즘을 활용할 수 있음을 뜻합니다.
스크립트가 새로운 메시지를 만들 때, 바로 전달되지 않고 다음 사이클(cycle)에 전달되도록 스케쥴을 구성하는 것을 부분적 병렬 실행이라 합니다. 메시지를 바로 전달할 수 없는 이유는 수신자(receiver)가 다른 쓰레드로 인해 상태가 변경되고 있을 수 있기 때문입니다.
뭔소리인지... 기술적인 부분이라 저는 패스합니다. 이해가 되시는 기술적 지식을 가지신 분이 댓글로 설명해 주시면 감사하겠습니다.
통신 지연 최소화 (Minimizing Communication Latency)
지연 시간은 한 계정에서 다른 계정으로 메시지를 보내고 응답을 받기까지의 시간입니다. 기술적 목표는 두 계정 사이의 메시지 교환이 단일 블록에서 이루어지며 메시지 간 간격이 3초 이내에 들어가게 하는 것입니다. 목표를 달성하기 위해 EOS.IO 소프트웨어는 블록을 사이클 단위로 나눕니다. 각각의 트랜잭션은 전달하는 메시지의 집합으로 구성됩니다. 이러한 구조는 트리(tree) 형태로 시각화 가능하며, 레이어 단위로 순차(sequentially) 처리되거나 병렬(parallel) 처리됩니다.
하나의 사이클에서 생성된 트랜잭션들은 이후 사이클 혹은 블록에서 전달됩니다. 블록 생산자는 블록에 지정된 시간(3초)이 지나거나 더 전달할 트랜잭션이 없을 때까지 사이클을 계속 추가합니다.
정적 분석(static analysis)으로 한 블록에서 동일 사이클에 같은 계정을 수정하는 2개 이상의 쓰레드를 가진 트랜잭션이 없는지 알 수 있습니다. 없으면, 하나의 블록은 여러 개의 쓰레드로 병렬 처리할 수 있습니다.
어려운 말들이 많지만 저는 이오스 블록체인의 자료를 전송하고 응답받고 하는데 소요되는 시간을 3초 이내로 하며 이오스 블록체인의 블록타임은 3초다 정도로 이해하고 있습니다. 또한 아래 부분들도 저로서는 설명이 좀 어려운 부분들입니다. 3초보다 짧은 블록타임도 가능한것 아닌가 하고 생각하시는 분들이 계실 수 있습니다. 3초보다 짧은 블록타임으로 블록체인을 만든다면 포크나는(잃어버리는)블록이 급격히 증가하게 된다고 합니다. 결국 3초보다 짧은 블록타임은 좀 어려운 것 아닌가 싶습니다.
읽기 전용 메시지 처리기 (Read-Only Message Handlers)
특정 계정의 메시지는 내부 상태의 수정이 아닌 통과/실패(pass/fail) 기반으로 처리할 때도 있습니다. 이러면 특정 사이클에 하나 이상의 쓰레드가 포함될 경우 해당 작업을 수행하는 메시지 처리기는 병렬 처리가 가능합니다.
다중 계정의 원자적 트랜잭션 (Atomic Transactions with Multiple Accounts)
종종 다수의 계정에 메시지의 전달 및 적용에 대한 원자성(atomicity)을 보장해야 합니다. 이 경우, 두 메시지는 하나의 트랜잭션에 위치하고, 두 계정은 같은 쓰레드에 할당되며, 메시지는 순차적으로 적용됩니다. 이 방식은 성능 면에서 이상적이지 않습니다. 사용량에 대한 "청구(billing)"를 수행할 때 트랜잭션에 참고된 계정의 수 만큼 비용이 청구됩니다.
성능과 비용 측면에서 2개 이상의 계정이 참여하는 원자적 트랜잭션을 줄이는 것이 좋습니다.
블록체인 상태의 부분 검사 (Partial Evaluation of Blockchain State)
블록체인 기술의 확장성을 보장하려면 구성 요소는 모듈화되어야 합니다. 애플리케이션의 일부만 사용할 때 전체를 다 구동할 필요는 없습니다.
거래소 애플리케이션의 개발자는 거래 상태를 사용자들에게 보여주기 위해 풀 노드(full node)를 구동하여야 합니다. 이러한 거래소 애플리케이션은 소셜 미디어 애플리케이션과 연동하여 동작할 필요가 없습니다. EOS.IO 소프트웨어는 풀 노드가 애플리케이션 중 일부를 한정 지어 구동할 수 있도록 합니다. 전달받은 메시지를 통해 애플리케이션의 상태가 전이되기 때문에, 다른 애플리케이션에서 이루어지는 메시지 전송은 안전하게 무시됩니다.
이것은 다른 계정과의 통신에 중요한 의미를 가집니다. 특히 다른 계정의 상태를 동일 기계(machine)로 접근할 수 있다고 가정하면 안 됩니다. 또한, 다른 계정과의 동기화 콜(call)을 호출하도록 로크(lock)를 사용할 때, 다른 계정이 메모리에 상주하지 않으면 이 디자인 패턴은 손상됩니다.
계정 간 상태 통신(state communication)은 블록체인의 메시지로 전달되어야 합니다.
이오스 블록체인 위에서 작동하는 각각의 애플리케이션(dapp)들이 어떻게 독립적으로 다른 애플리케이션에 영향을 주지않고 동작하고 서로 소통하는지에 대한 설명입니다. 이해하실 수 있으신분만 이해하시면 되는 부분입니다. 휴대폰이 어떻게 작동하는지를 알고나서 휴대폰을 사용할 필요가 없는 것처럼 이오스 블록체인에서 구동시킬 에플리케이션 개발자가 아니라면 기술적인 부분은 "그렇구나" 하는 정도로 이해하시고 넘어가셔도 됩니다.
주관적 최선 스케쥴링 (Subjective Best Effort Scheduling)
EOS.IO 소프트웨어는 블록 생산자가 어떤 계정으로 어떻게 메시지를 보낼지에 대하여 강제할 수 없습니다. 각각의 블록 생산자는 계산 복잡도와 트랜잭션을 처리하기 위한 요구 시간에 대한 주관적인 측정을 수행합니다. 이것은 트랜잭션이 사용자에 의해 생성되거나 스크립트에 의해 자동으로 생성될 때 모두 적용됩니다.
EOS.IO 소프트웨어는 네트워크 관점에서 모든 트랜잭션에 대해 0.01ms가 걸리건 10ms가 걸리건 상관없이 같은 연산 대역폭(compudational bandwidth) 비용을 청구합니다. 하지만 블록 생산자들은 개별적인 측정 알고리즘을 이용하여 리소스 사용 비용을 계산할 수 있습니다. 블록 생산자가 한 트랜잭션 혹은 계정이 과도한 양의 연산 자원을 사용한다고 판단이 되면 해당 트랜잭션을 본인이 생산하는 블록에 추가하는 것을 거부할 수 있습니다. 물론 이 경우에도 다른 블록 생산자는 그 트랜잭션이 적합하다고 판단하여 처리할 수 있습니다.
블록 생산자인 증인은 어떤 계정이 메세지를 보내는 것을 증인이 임의로 강제할수 없으나 특정 사용자나 계정이 자신의 연산대역폭을 넘어서 사용한다고 판단되는 경우에는 예외로 한다는 의미입니다. 이런 경우에도 다른 증인이 적합한 연산
대역폭 이내라고 판단하면 블록에 포함시킬수 있다는 의미입니다.
일반적으로 한명 의 블록 생산자라도 트랜잭션이 리소스 사용 제한을 넘지 않아 적합하다고 간주하면 다른 블록 생산자도 승인하게 됩니다. 그러나, 이 경우 트랜잭션이 받아주는 블록 생산자를 찾기까지 1분 가까운 시간이 소요될 수 있습니다.
간혹 블록 생산자가 허용 가능한 범위를 몇 배나 넘어가는 트랜잭션을 블록에 포함 시킬 수도 있습니다. 이 경우 다음 블록 생산자는 그 블록을 아예 거절해버릴 수 있으며, 승인과 거절이 동률인 상태는 다음 블록 생산자에 의해 판결됩니다. 이는 거대 블록으로 인해 네트워크 전파 지연이 발생하는 경우와 차이가 없습니다. 커뮤니티는 이상 패턴을 파악하고 이러한 불량 생산자에게 표를 주지 말아야 할 것입니다.
불량 증인으로 인해 계정소유자의 연산대역폭을 넘는 트랜젝션도 블록에 포함될 수 있는 문제가 있다고 합니다. 그러나 이런 경우 다음번 블록생산자가 해당블록을 거절할수도 있습니다. 불행히 승인과 거절이 동수라면 그 다음 블록생산자에 의해 판결이 됩니다.(홀수의 블록생산자를 두는 이유로 짐작됩니다) 그러함에도 이런 불량 블록생산자는 존재할 수 있지만 이오스 코인을 보유한 커뮤니티가 이런 불량 생산자에게는 증인투표를 하지 않음으로서 스스로 블록 생산자를 제어할 수 있다는 의미입니다.
이러한 블록 생산자의 주관적 평가가 있기에 블록체인은 정확하고 명확한 실행 시간 계산의 측정을 하지 않아도 됩니다. 이러한 디자인은 정확한 계수 명령(count instruction)을 요구하지 않으며, 이로 인해 합의를 해치지 않는 최적화 기회가 열리게 됩니다.
이후 부분은 다음 포스팅(eos 백서-5)에서 읽어드리겠습니다
감사합니다.
@leesunmoo 올림