안녕하세요, 이댕댕입니다!
이어서 EOS 백서 읽기 진행하겠습니다.

애플리케이션의 결정론적 병렬 실행

블록체인에서 병렬로 실행될 수 있는 트랜재션이 비 결정론적이지 않게 보장하는 방법이 필요합니다. 여기서 '결정론적' 이라는 말은 알고리즘을 통한 결과가 예측 가능하다는 것을 의미합니다. 일반적인 프로그래밍 언어, 함수 모두 일반적으로 결정론적이라고 보시면 됩니다. 특히나 블록체인 상에서 트렌젝션이 결정론적으로 확정이 되야 제대로 구동하다고 볼 수 있겠죠?

2018년 6월 릴리즈에는 단일 스레드에서 실행되지만 향후 병렬 실행이 가능하도록 데이터베이스가 제공된다고 합니다.
병렬 실행이 가능해지만, BP는 서로 독립적인 샤드로 액션을 병렬로 실행시킬 수 있습니다. BP는 트렌젝션을 어떻게 블록에 담을것인지 스케줄링을 하고, 병렬로 결정론적으로 스케줄링을 실행시킬 수 있습니다.

요약하면, 안전하게 병렬로 트랜젝션들을 실행시킬 수 있다! 고 보시면 될 것 같습니다.

통신 대기시간 최소화

한 계정에서 다른 계정으로 액션을 전송한 후, 다시 응답을 받는데 걸리는 시간을 대기시간으로 합니다. EOS에서는 두 계정의 대기시간이 0.5초 이내로, 단일 블록 내에서 서로 액션을 하는 것을 목표로 합니다. 이를 위해 다음과 같은 계층구조를 설계하였습니다.

블록

리전

사이클(순차 처리)

  샤드(병렬 처리)

    트랜잭션(순차 처리)

      액션(순차 처리)
      
        수신자와 알림받는 계정(병렬 처리)

우선, 밑에서부터 액션은 트랜잭션에 담기고 트렌젝션은 샤드에 담기고 여러 샤드를 사이클이 담고 있습니다. 블록은 사이클들의 모임입니다. 이런 구조로 사이클 내부의 트렌젝션들을 바로바로 실행시킬 수 있고, 사이클 외부나 블록 외부로도 트랜잭션을 전송할 수 있습니다.
정리하면, 샤드의 병렬처리, 그리고 계층구조 안에 있는 순차처리로 통신 대기시간을 최소화한다는 내용입니다.

읽기 전용 액션 핸들러

일부 계정은 상태를 수정하지 않고 액션의 성공/실패를 처리할 수 있습니다. 특정 사이클 내, 하나의 샤드 안에 어떤 계정의 읽기 전용 핸들러들만 포함되어 있으면 병렬로 실행할 수 있습니다.

여러 계정에 대한 원자적 트랜잭션

'원자적'이라는 말은 어떤 작업이 다른 작업에 의해 방해 받아 중단되지 않고, 언제나 완전하게 수행되는 것을 의미합니다. 다중 계정으로의 원자적 트랜잭션이 보장되어야하는 경우가 있습니다. 이럴 경우, 두 액션을 모두 하나의 트랜잭션이 넣고, 두 계정을 같은 샤드에 넣어 작업을 순차적으로 진행합니다. (이부분은 아직 잘 와닿지가 않네요)

문맥 무관 액션

문맹 무관 액션은 블록체인 상태에 의존하지 않고 트랜잭션 데이터에만 의존하는 연산을 의미합니다. 블록체인 상태에는 지갑 정보, 얼마 들었는 지 등이 포함되어있는데 이런 상태가 필요없는 연산의 예로, 트랜잭션에 서명한 공개키를 확인하는 연산이 있습니다.
이 연산을 확인하기 위해서는 트랜잭션 데이터와 서명만 필요합니다. 상태를 참고할 필요가 없어서 다른 액션들과 병렬로 처리가능합니다.
이러한 문맥 무관 액션을 병렬로 잘 처리하면 속도를 비약적으로 올릴 수 있겠네요.

토큰 모델 및 자원 사용

EOS.IO의 블록체인 상 위의 자원에는 크게 세가지가 있습니다.

1.대역폭 및 로그 저장소(디스크)
2.연산 및 연산 백로그(CPU)
3.상태 저장소(RAM)

대역폭, 연산에는 순간 사용과 장기 사용을 할 수 있습니다. 블록체인 위의 모든 액션은 로그로 저장되고 전체 노드에 의해 로그가 저장됩니다. 이 로그를 통해서 애플리케이션의 상태를 재구성할 수 있습니다.

근데, 이 로그가 너무 커져 상태 재생성을 할 때 연산이 커지면 블록체인의 스냅샷을 뜨고, 블록체인의 히스토리를 버릴 수 있다고 합니다.

상태저장소, 램은 애플리케이션 로직이 접근할 수 있는 정보입니다. 여기에는 주문서, 계정 잔고 같은 정보를 말합니다. 구체적으로 나와있지는 않지만, 계정, 거래 같이 중요한 정보들을 언급하는 것 같습니다. 그래서 블로그 글이나 댓글 같은 정보들은 상태 저장소에 저장되지 않습니다. 핵심적인 정보만 상태저장소에 저장하는 것 같습니다.

BP는 위 세가지 요소에 대해 사용 가능한 용량을 제시합니다. EOS.IO 위에서 토큰 비례량에 따라 전체 용량의 일정 비율을 사용할 수 있습니다. 전체 토큰의 1%를 가지고 있으면, 상태 저장 용량의 1%를 사용할 수 있다는 말입니다.

많은 사람들이 블록체인을 사용하는 만큼, 서로 용량들을 겹치지 않게 BP가 연산 능력들을 정확히 계측할 수 있어야합니다. 이러한 계측에는 일반적으로 BP가 주관적인 기준과 알고리즘을 통해 계측하게 됩니다.

수신자 부담

EOS 위의 상태 저장 용량 사용 비용을 최종 사용자가 내지 않도록 합니다. 애플리케이션 최종 사용자가 그런 비용을 낼 수는 있습니다. 그러나 우리가 구글 등 서비스를 무료로 사용하는 것처럼 애플리케이션 개발사가 블록체인 쓰는 비용을 상품이나 제품에 넣어서 직접적으로 블록체인 비용을 쓰는 사람이 내지 않도록 합니다.

용량 위임

토큰 보유자는 대역폭을 즉시 사용할 필요가 없을때, 다른 사람에게 위임하거나 대여할 수 있습니다.

트랜잭션 비용을 토큰 가치와 구분

애플리케이션이 사용 가능한 대역폭 양은 보유하고 있는 토큰 수, 즉 전체 토큰에 대해 내 토큰이 차지하는 비율에 따라 결정됩니다. 따라서 토큰이 가격이 어떻게 되던간 토큰 수가 변하지 않으면 고정된 대역폭 사용량을 가져 애플리케이션을 계속 실행시킬 수 있습니다. 따라서 외부 가격 변동의 영향을 받지 않기 때문에 트랜잭션 비용이 외부에 따라 달라지지 않습니다. 즉, 토큰 가격이 어떻게 되던간에 애플리케이션을 안정적으로 운용할 수 있다는 뜻입니다.

상태 저장 비용

애플리케이션 개발사는 상태 저장을 위해 토큰을 보유해야 합니다. 해당 토큰은 묶여있는 셈이어서 실제 유통에서 제외되는 셈입니다.

블록 보상

블록이 생성될 때마다 BP에게 보상이 지급됩니다. 이 값은 BP가 원하는 보상의 중간값을 따릅니다. 전체 보상으로 발행되는 토큰이 전체의 5%를 넘기지 않도록 상환을 설정할 수 있습니다. 블록 보상에 관해서는 BP끼리 담합을 할 수도 있지 않을까? 라는 생각이 드네요ㅎㅎ

워커 제안 시스템

토큰 보유자는 BP 선출 투표외에도 커뮤니티에 도움되는 워커 제안에 투표할 수 있습니다. 투표에서 승리한 제안은 일정 퍼센트의 토큰을 보상으로 받습니다. 워커 제안 시스템은 아직 출시되지 않은 것 같습니다.

---

2부는 여기서 마치겠습니다!
다음에는 운영부터 마지막까지 다루겠습니다.

그럼 이댕댕으로 놀러왕~!