테조스 백서(한글)

Tezos — a self-amending crypto-ledger White paper
자가 수정형 암호화 원장 백서

L.M. Goodman
2014년 9월2일
번역 @areyoucrazy
기획 @krexchange

2.3. 기능적인 표현

2.3.1. 체인의 유효성 검사

다음과 같은 Ocaml의 유형을 사용해서 추상적인 블록체인 구조의 거의 모든 일반적인 부분들을 효율적으로 캡쳐 할 수 있었습니다. 우선, 블록의 헤더는 다음과 같이 정의합니다.

type raw_block_header = { 
   pred: Block_hash.t; 
   header: Bytes.t; 
   operations: Operation_hash.t list;
   timestamp: float; 
}

우리는 의도적으로 헤더필드를 강력하게 입력하지 않으므로 임의의 내용을 나타냅니다. 그러나 우리는 쉘 조작에 필요한 필드를 입력합니다. 여기에는 이전 블록의 해시, 작업 해시 목록 및 타임 스탬프가 포함됩니다. 실제로 블록에 포함된 작업은 네트워크 수준에서 블록과 함께 전송됩니다. 연산 자체는 여기서 임의의 얼룩으로(arbitrary blobs) 표현이 되게 됩니다.

type raw_operation = Bytes.t

이 상태는 디스크 기반의 불변의 key-value 값 저장소를 캡슐화하는 Context 모듈의 도움으로 표현이 됩니다. Key-value 저장소의 구조는 다목적이며 다양한 상태를 효율적으로 나타낼 수 있습니다.

module Context = sig 
   type t 
   type key = string list 

   val get: t -> key -> Bytes.t option Lwt.t 
   val set: t -> key -> Bytes.t -> t Lwt.t 
   val del: t -> key -> t Lwt.t 
   (*...*) 
End

디스크 작업에서 블로킹을 막기 위해서 함수의 경우 비동기 모나드를 사용하게 됩니다. Context에서 연산은 순전히 기능적입니다:

get은 옵션 모나드를 사용하고 set과 del은 새로운 Contect를 반환합니다. Context 모듈은 메모리 캐싱 및 디스크 스토리지를 사용하여서 불변 저장소(immutable store)의 모양을 효율적으로 제공합니다.

이제 임의의 블록 체인 프로토콜의 모듈 유형을 정의할 수 있습니다:

type score = Bytes.t list
module type PROTOCOL = sig
   type operation
   val parse_block_header : raw_block_header -> block_header option
   val parse_operation : Bytes.t -> operation option

   val apply :
      Context.t ->
      block_header option ->
      (Operation_hash.t * operation) list ->
      Context.t option Lwt.t

   val score : Context.t -> score Lwt.t
   (*...*)
end

우리는 더 이상 수학적 모델 에서처럼 상태를 직접 비교하지 않습니다. 우리는 스코어 함수를 사용하여 Context를 바이트 목록에 투영합니다. 바이트 리스트는 길이에 의해 순서가 정해지며, 그 다음에 어순 순서에 의해 정렬이 되게 됩니다. 이는 소프트웨어 버전 관리에 사용되는 것과 비슷한 상당히 일반적인 구조로 다양한 순서를 나타낼 때에는 매우 유용합니다.

왜 프로토콜 모듈 내에서 비교 기능을 정의하지 않을까요?

첫번째로는 그러한 기능이 총 주문을 나타내는 요구 사항을 시행하는 것은 어렵기 때문입니다. 점수 투영은 이를 항상 확인하게 됩니다(마지막 블록의 해시를 기반으로 연결 고리가 끊어질 수도 있습니다).

둘째로는, 원칙적으로 우리는 별개의 프로토콜을 통해서 상태를 비교할 수 있는 능력이 필요합니다. 특정 프로토콜 수정 규칙은 이 일이 거의 일어나지 않을 것으로 보지만, 네트워크 쉘은 이것을 알지 못합니다.

Parse_block_header및 parse_operation 작업은 쉘에 노출되어 완전히 형식화된 작업 및 블록을 프로토콜로 전달할 수 있게 하지만, 작업을 릴레이하거나 로컬 블록트리 데이터베이스에 블록을 추가하기 전에 이러한 작업 및 블록의 형식이 올바른지 확인해야 합니다.
Apply 함수는 프로토컬의 핵심으로 작용합니다:

블록 헤더와 관련 연산 목록이 전달되면, 컨텍스트에 대한 변경 사항을 계산하고 수정된 복사본을 반환합니다. 내부적으로 차이점은 버전 관리 시스템에서 저장되어서, 블록의 해시를 버전핸들로 사용한다는 것입니다.
작업 목록이 전달되게 된다면, 이것은 가능한 많은 작업을 적용시키려고 합니다. 이 기능은 프로토콜 자체에게는 효율적이지 않지만, 유효 블록을 생성하려 하는 채굴자들에겐 유용합니다.

2.3.2. 프로토콜 개정

테조스의 가장 강력한 특징은 자체 수정이 가능한 프로토콜을 구현할 수 있다는 것입니다. 이것은 두개의 절차 기능을 프로토콜에 노출시킴으로써 이루어집니다.

set_test_protocol은 테스트넷에서 사용된 프로토콜을 새로운 프로토콜(일반적으로 스테이크 홀더 투표자들에 의해서 채택된 프로토콜)로 대체합니다.
promote _test_protocol은 현재 프토토콜을 시험중인 프로토콜로 교체해줍니다.
이러한 함수는 관련 프로토콜을 변경하여 컨텍스트를 변환합니다. 새로운 프로토콜은 다음 블록이 체인에 적용될 때 적용됩니다.

module Context = sig 
   type t 
   (*...*)
   val set_test_protocol: t -> Protocol_hash.t 
   Lwt.t val promote_test_protocol: t -> Protocol_hash.t -> t Lwt.t 
End

Protocol_hash는 .ml와 .mli의 타르볼을 sha256으로 해싱한 값입니다. 이 파일들은 즉시 컴파일링 됩니다. 그들은 작은 표준 라이브러리에 액세스할 수 있지만 샌드 박싱되어 있으며, 시스템 호출을 할 수 도 없습니다.

이 함수들은 프로토콜의 적용 함수를 통해서 호출되며, 새 Context를 반환하게 됩니다.
많은 조건이 프로토콜 변경을 유발할 수 있습니다. 가장 간단한 방식으로는 스테이크 홀더들의 투표로 인해서 프로토콜이 변경이 되게 됩니다. 보다 복잡한 규칙들을 점진적으로 투표하는 것도 가능합니다. 예를 들어서 스테이크 홀더들이 원한다면 앞으로 하는 개정안들에 대해서 특정 자산을 존중한다는 컴퓨터로 확인 가능한 증거를 제공하라고 하는 개정안을 만들 수도 있습니다. 이것은 “합헌성”(constitutionality)의 효과적이고 알고리즘 적인 검사입니다.

2.3.3. RPC

GUI의 구축작업을 쉽게 만들기 위해서, 이 프로토콜은 JSON-RPC API를 드러냅니다. API 자체는 다양한 프로 시저 유형을 나타내는 json 스키마로 설명 됩니다. 일반적으로 get-balance와 같은 함수들은 RPC에서 구현이 될 수 있습니다.

type service = {
   name : string list ;
   input : json_schema option ;
   output : json_schema option ;
   implementation : Context.t -> json -> json option Lwt.t
}

The name은 프로 시저에서 네임 스페이스를 허용하는 문자열 목록입니다. 입력과 출력은 선택적으로 json 스키마에 의해서 설명이 되게 됩니다.
이 호출은 일반적으로 가장 높은 득점을 한 leaf의 조상인 주어진 context에서 수행이 되게 됩니다. 예를 들어, 가장 높은 득점을 한 리프보다 6 블록 앞에서 문맥을 쿼리하게 된다면, 여섯 가지 확인 사항이 있는 원장의 상태가 표시됩니다.
UI자체는 특정 버전의 프로토콜에 맞게 조정되거나 일반적으로 JSON 사양에서 파생됩니다.

3. 씨드 프로토콜

대부분의 블록체인은 제네시스 해시로부터 시작이 되게 됩니다. 테조스는 씨드 프로토콜에서 시작합니다. 이 프로토콜은 사실상 모든 블록 체인 알고리즘을 반영하도록 수정될 수 있습니다.

3.1. 경제 부분

3.1.1. 코인

처음에는 100억개의 코인이 존재합니다. (하지만, 토큰 공급은 군중 중에 발급되는 토큰의 수이며, 100억은 단순히 자리 표시일 뿐입니다. ) 그리고, 소수점 두번째 자리까지 사용할 수 있습니다. (이 역시 우리가 실제로 사용할 수 있는 부분은 소수점 8째자리까지 가능합니다.) 하나의 코인은 tez라고 불리며, 가장 작은 단위는 센트입니다. 0.01tez= 1 센트.

3.1.2. 채굴와과 서명 보상

원리 우리는 탈중앙화된 통화의 안전성을 유지하기 위해서는 참여자들이 필요하다는 것을 인식하고 있고, 그들에게 금전적인 보상인 인센티브를 지급합니다. (현재는 보상에 대한 계획을 마무리하는 과정입니다.) 포지션 페이퍼에서 나왔듯이, 트랜잭션피에만 의존하는 것은 위험하며, 테조스는 보상과 채권(bond)에 의존해서 돌아가게 됩니다.

이러한 bond는 채굴자들이 구매한 1년 예금과 같은 개념입니다. (현재 bond는 한주기만 지속됩니다. 기회 비용 및 1주기를 초과할 경우 유대 기간 연장의 보안에 대한 적은 이점이 주된 이유입니다. 보증인(endorser) 또한 이러한 bond를 구매해야 합니다) 이중 서명의 경우 이러한 BOND는 무효화 처리 됩니다.

한 주기 이후, 채굴자들과 보증인들은 그들의 기회 비용을 보상받기 위해서 bond에 대한 인센티브를 받습니다. 보안에 대한 부분은 채권(bond)의 가치로 제공되기 때문에, 보상에 대한 부분은 그 가치의 작은 비율이기만해도 괜찮습니다.

채권 (Bond)의 주요 목적은 필요한 보상액을 줄이는 것이며 네트워크 이점에 loss-adversion effect를 적용하는 것입니다.
자세한 부분들 씨드 프로토콜에서 블록을 채굴함으로써 512개의 테조스를 제공받으며, 1536개의 테조스 채권(bond)를 필요로 합니다. 블록 서명을 통해서 32∆T −1 테조스를 지급 받게 되며, ∆T는 블록이 서명된 시간과 이전 블록과 해당 블록 사이의 시간 간격(분) 입니다. 블록당 최대 16개까지의 서명에 대해서는 bond를 필요로 하지 않습니다. (위 수치는 이전 10억개로 가정했을 때의 수치이므로, 이후 변경이 될 가능성이 큽니다. 추후 업데이트 예정입니다)

이러한 보상 계획은 연간 5.4%의 인플레이션을 기준으로 예정되어 있습니다.
유의하실 점은 1년의 기준은 블록들의 타임스탬프를 기준으로 하며, 블록 개수로 환산하지 않습니다. 이것은 채굴자들이 약속한 길이에 관한 불확실성을 확실히 제거하기 위함이 주요 목적입니다.

이러한 채권(bond)의 보상은 33프로 정도로 예상이 되어 있습니다. (이 부분 역시 검토 중입니다.) 이 수익은 채굴자들과 서명자들이 잠재적으로 불안정한 자산을 1년동안 홀딩 해야 하기 때문에 수익이 초기엔 높을 필요성이 존재합니다. (현재는 1년에서 한 주기로 변경되었습니다)

하지만, 테조스가 성장할수록 이러한 bond의 보상은 현행 이자율 수준까지 줄 것이며, 그럴 이유가 분명 하진 않지만, 1프로 이하의 명목상 인플레이션율이 유지될 예정입니다.

3.1.3. 잃어버린 코인들

통화량에 대한 불확실성을 줄이기위해서 1년간(타임스탬프 기준으로) 활동이 없는 주소들에 한해서 코인과 주소가 모두 삭제될 예정입니다. (이부분은 수정이 되었습니다. 코인에 대한 소각은 이루어지지 않고, 스테이킹 권리만 잃게 됩니다. 이후 주소가 활성화되면 이 권리를 되찾는 것이 가능해집니다.

3.1.4. 수정 규칙

개정안은N=217= 131062 블록 지속되는 선거 주기 동안 채택됩니다. 1분 블록 간격을 감안했을 때 이것은 약 3개월로 추정이 됩니다. 선거주기는 이를 4등분한 215= 32768 블록마다 이루어지게 됩니다. 이 주기는 초기 개선을 장려하는데는 상대적으로 짧지만, 추가 수정을 통해서 주기의 길이가 길어질 것으로 예정됩니다. (프로토콜 개정안은 첫 해에는 훨씬 더 자주 이루어질 예정입니다. 보안 조치의 수단으로써 테조스 재단은 많은 것이 안정화된 12개월 후에 거부권을 행사하게 될 것입니다.)

1분기 프로토콜 수정안은 .ml와 .mli의 타르볼을 해슁해서 제출하는 것으로 제안됩니다. 스테이크 홀더들은 이러한 프로토콜들을 승인할 수 있습니다. 이를 “승인 투표”라고 하며, 특히나 강력한 투표 절차로 여겨집니다.

2분기 1분기에서 가장 많은 승인을 얻은 개정안은 이제 투표 대상이 됩니다. 스테이크 홀더들은 이를 위해서 투표안을 제시하거나 기권을 할 수도 있습니다. 이때 기권은 정족수에 포함이 됩니다.

3분기 정족수가 충족이 되고, 개정안 찬성표가 80% 이상을 받게 된다면, 개정안은 승인되어서 테스트 프로토콜을 대신하게 됩니다. 그렇지 않다면(80프로 미만이라면), 이는 거부 됩니다. 이전의 도달된 정족수가 q하고 가정하면 그 다음 투표의 최소 정족수 Q는 다음과 같이 업데이트 됩니다:

Q ← 0.8Q + 0.2q.

여기서 이 업데이트의 목표는 분실되거나 사용되지 않는 코인들로 인해서 투표가 늦춰지는 것을 막기 위함 입니다. 이렇게 함으로써 최소 정족수는 이전 선거때마다 도달한 정족수 지수 이동의 평균으로 설정이 됩니다.

4분기 개정안이 승인되었다고 가정하게 된다면, 이는 3분기 초에서부터 테스트넷에서 실행됩니다. 스테이크 홀더들은 이때 이 테스트 프로토콜을 메인 프로토콜로 승격시키기를 원하는지에 대해서 두번째 투표를 실행하게 됩니다. 이 역시 정족수를 충족 시켜야 하며, 80%이상의 대다수가 동의해야 합니다.

백서 원문
번역 후기 - 테조스 한글 백서 번역을 무사히 끝마쳤습니다.

Steemit Token LAB 백서 번역 #1. 테조스

Steemit KR에서 암호화폐 백서를 번역합니다. 첫번째 프로젝트로 테조스 백서를 한글로 번역하였습니다.
테조스에 관심이 많으신 @areyoucrazy 님께 번역을 의뢰하였으며, 빠르게 번역을 해주셨습니다. 앞으로 3번에 걸쳐 업로드할 계획입니다.
앞으로도 지속적으로 관심있는 암호화폐 백서의 번역 작업을 이어갈 계획입니다.
선 지급한 번역료 외에 본 글 저자보상 SBD의 30%는 번역가에게 전달되며, 50%는 다음 백서 번역을 위하여 적립합니다.

번역 저작권

이용시 출처 표시
비상업적 이용만 가능
변형 등 2차적 저작물 작성 가능

[Steemit Token LAB] 테조스 백서(한글) #2