Tezos 한글 백서

translated by megasolar.

audited by Tezos Korea foundation.

Table of Contents

소개

이 문서에서는 첫째, 추상적인 블록체인과 자가개정 암호원장(self-amending crypto-ledger) 에 대해서 얘기 할 것입니다. 두번째, 시드 프로토콜 (seed protocol)에 대해서 설명합니다.

자가 개정 암호화 원정 (Self-amending cryptoledger)


블록체인 프로토콜은 아래와 같이 뚜렷한 세가지 프로토콜들로 나눌 수 있습니다.

  • 블록을 발견하고 트랜잭션들을 전파하는 네트워크 프로토콜
  • 구체적으로 트랜잭션을 유효하게 만드는 트랜잭션 프로토콜
  • 유일한 체인에서 합의를 이끌어 내는 합의 프로토콜 (consensus protocol)

Tezos는 일반 네트워크 쉘를 구현합니다. 이 쉘는 트랜잭션 프로토콜과 합의 프로토콜에 대해 상관이 없습니다. 우리는 트랜잭션 프로토콜과 합의 프로토콜을 함께 "블록체인 프로토콜"이라고 부릅니다. 먼저 블록체인 프로토콜을 수학적으로 표현한 다음 Tezos의 구현 중 일부를 설명할것입니다.

(Tezos에 대한)수학적 설명


블록 체인 프로토콜은 근본적으로 (네트워크의)전체 상태에 대해 동시 변화 모나드 구현체입니다.(monadic implementation of concurrent mutations of a global state) 이 모나드 구현체는 "블록"을 이 전체 상태에서 작동하는 연산자로 정의함으로써 만들어집니다. 제네시스 상태(genesis state)인 블록의 자유 모노이드(free monoid)는 트리 구조(tree structure)를 이룹니다. 전체 또는 표준 상태는 구체화된 순서의 최소 리프로 정의됩니다.

앞서 말한 것은 다음과 같은 추상적인 표현으로 나타 낼 수 있습니다.

  • (S,)(\mathbf{S},\leq) 는 전부 정렬되어 있고 셀 수 있는 상태들의 집합( set of possible state)라고 합시다.
  • S\oslash \notin \mathbf{S} 은 특수한 상태, 유효하지 않은 상태를 나타낸다고 가정합니다.
  • BSS{}\mathbf{B} \subset \mathbf{S}^{\mathbf{S} \cup \{\oslash\}} 는 (유효한)블록들의 집합이라고 하고 유효하지 않은 블록들의 집합은 BSS\mathbf{B} \cap \mathbf{S}^{\mathbf{S}} 로 나타냅니다.

S\mathbf{S} 의 모든 순서가 확장되면 sS,<s\forall s \in \mathbf{S}, \oslash < s 가 됩니다 . 이 순서는 블록 트리에서 어떤 리프가 표준 리프로 될건지를 결정합니다. B\mathbf{B} 에 있는 블록은 상태(state)에서 작동하는(acting) 연산자(operator)로 간주됩니다.

결론적으로 모든 블록 체인 프로토콜 (Bitcoin, Litecoin, Peercoin, Ethereum, Cryptonote 등)은 튜플로 완전히 결정될 수 있습니다.

\left(\mathbf{S},\leq,\oslash, \mathbf{B} \subset \mathbf{S}^{\mathbf{S} \cup \{\oslash\}}\right)

네트워킹 프로토콜은 기본적으로 이러한 블록체인과 동일합니다. "채굴"알고리즘은 네트워크의 새로운 속성이며 블록생성에 대한 인센티브를 줍니다.

Tezos에서는 블록들이 프로토콜 자체에 따라 움직이도록 함으로써 ( 블록체인 프로토콜 ) 스스로를 감시하는 블록체인 프로토콜을 만듭니다. 이에 대해 다음과 같이 재귀적으로 프로토콜 집합을 표현할 수 있습니다.

\mathcal{P} = \left\{\left(\mathbf{S},\leq,\oslash,\mathbf{B} \subset \mathbf{S}^{(\mathbf{S} \times \mathcal{P})\cup \{\oslash\}} \right)\right\}

(Tezos) 네트워크 쉘(shell)


이 공식적인 수학 설명은 어떻게 블록 트리를 만드는가에 대해서는 설명하지 않습니다. 네트워크 쉘(Shell)은 가십 네트워크(gossip network)와 프로토콜 간의 인터페이스 역할을 합니다.

네트워크 쉘은 클라이언트에게 알려진 최상의 체인을 유지하고 관리합니다. 네트워크 쉘은 세 가지 타입의 객체를 알고 있습니다. 첫 번째 두 개는 트랜잭션과 블록으로, 유효한 경우에만 네트워크를 통해 전파됩니다. 세 번째는 프로토콜 입니다 ,OCaml 모듈은 기존 프로토콜을 수정하는 데 사용됩니다. 프로토콜의 자세한 내용에 대해서는 나중에 설명합니다. 지금은 트랜잭션과 블록에 초점을 맞춰 설명 할 것입니다.

네트워크 쉘에서 가장 힘든 부분은 DDos(Denial-of-service, 서비스 거부 공격) 공격 으로부터 노드를 보호하는 것입니다.

클럭(Clock)

모든 블록은 네트워크 쉘에서 볼 수있는 타임 스탬프를 전달합니다. 미래에 만들어질 블록은 타임 스탬프가 시스템 시간의 몇 분 내에 있으면 버퍼링(임시 저장된다는 뜻 - 역자 주)되고 그렇지 않은 경우 거부됩니다. 프로토콜 설계는 클라이언트에서 합리적인 클럭 드리프트를 허용해야하며 타임 스탬프가 위조 될 수 있다고 가정해야합니다.

체인 선택 알고리즘 (Chain selection algorithm)

(네트워크)셸은 블록의 전체 트리가 아닌 단일 체인을 유지합니다.(고아 블록이나 Pruning 된 블록체인을 가지고 있지 않다는 뜻 - 역자 주) 클라이언트가 더 나은 체인을 정확히 인식하게 될 경우에만 이 체인을 덮어쓰게 됩니다.

네트워크 통신 측면에서 트리를 유지하고 관리한다는 것은 간단합니다. 하지만 이런 경우엔 공격자가 많은 공격을 시도하더라도 성공하기 어렵지만 유효한 (체인)포크를 만드는 DDoS 공격에 취약 할 수 있습니다.

또 노드가 주어진 체인의 점수에 대해서 어쩌면 많은 수의 블록을 클라이언트가 처리한 후에만 발견될 거짓말을 하는 것은 가능합니다. 그러나 그러한 노드는 나중에 무시 될 수 있습니다.

다행스럽게도 프로토콜은 낮은 점수를 가진 체인이 낮은 블록 생성 속도를 나타내는 속성을 가질 수 있습니다. 따라서 클라이언트는 발표 된 점수가 거짓말이라고 결론 짓기 전에 몇 블록의 "약한" 포크만을 고려할 것입니다.

네트워크 수준의 방어 (Network level defense)

또한 쉘은 "방어적" 입니다. 다양한 IP 범위에서 많은 피어에 연결을 시도합니다. 연결이 끊긴 피어를 탐지하고 악의적인 노드를 차단합니다.

특정 DDOS(서비스 거부 공격, denial-of-service) 공격으로부터 보호하기 위해 프로토콜은 블록 및 트랜잭션 크기에 대한 컨텍스트 의존 범위를 쉘에 제공합니다

기능적인 표현 (Functional representation)

체인의 유효성 (Validating the chain)

다음 OCaml 타입을 사용하여 추상 블록체인 구조의 거의 모든 일반적인 성질을 효율적으로 캡처 할 수 있습니다. 우선, 블록헤더는 다음과 같이 정의됩니다.

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

의도적으로 헤더 필드를 더 강조해서 입력하지 않으므로 임의의 내용을 나타낼 수 있습니다. 그러나 우리는 쉘 연산에 필요한 필드인 이전 블록의 해시, 작업 해시의 목록과 타임 스탬프를 입력합니다. 실제로 블록에 포함된 작업은 네트워크 수준에서 블록과 함께 전송됩니다. 작업 자체는 다음과 같이 임의의 blob들로 표현됩니다.

    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

디스크 작업에서 블로킹을 피하기 위해 함수는 비동기 모나드 Lwt[@LWT]를 사용합니다. 컨텍스트에 대한 연산(operation)은 순수한 함수입니다. (설명하자면)getsetdel 둘 다 새로운 Context를 반환하는 동안 예외(exception)를 던지기보다는 option 모나드를 사용합니다. Context 모듈은 메모리 캐싱(memory caching)과 디스크 스토리지를 결합하여 불변하는 저장소의 모양을 효율적으로 제공합니다.

이제 우리는 임의의 블록체인 프로토콜의 모듈 타입을 정의 할 수 있습니다.

    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

우리는 수학적모델 처럼 상태를 직접 비교하는 대신 Contextscore 함수를 사용하여 바이트 목록에 보여줍니다. 바이트의 리스트는 첫번째로 길이에 의해 순서가 정해지고, 그 다음에 알파벳 순서에 의해 정렬됩니다. 이는 소프트웨어 버전 관리에 사용되는 것과 유사한 일반적인 구조로 다양한 순서를 나타낼 때 매우 유용합니다.

왜 프로토콜 모듈 내에서 비교 함수를 정의하지 않을까요? 우선, 그러한 함수가 total order를 표현한다는 요구 사항을 강제하는 것은 어려울 것입니다. 점수를 표시하는 것(score projection)은 마지막 블록의 해시를 기반으로 연결이 끊길 수 있기 때문에 항상 total order를 확인합니다 . 둘째, 원칙적으로 우리는 별개의 프로토콜을 통해 상태를 비교할 수 있는 능력이 필요합니다. 특정 프로토콜 수정 규칙에 따라서 이러한 일이 거의 일어나지 않을 것으로 보이지만 네트워크 쉘은 이를 알지 못합니다.

parse_block_headerparse_operation 작업은 쉘에 노출됩니다. 그래서 완전히 형식화 된 연산과 블록을 프로토콜로 전달 할 수 있을 뿐 만 아니라 연산을 릴레이(relay)하거나 로컬 블록트리 데이터베이스에 블록을 추가하기로 결정하기 전에 이런 연산과 블록이 올바른 형식인지에 대해서 확인할 수 있습니다.

다음과 같은 응용 합수는 프로토콜의 핵심입니다.

  • 블록 헤더와 관련 연산 목록이 전달되면 컨텍스트에 변경 사항을 계산하고 수정 된 복사본을 반환(return)합니다. 버전관리 시스템(versioning system)에서와 같이 내부적인 차이점은 블록의 해시를 버전 핸들로 사용하여 저장됩니다.

  • (체인에서는) 연산(operation)목록만 전달되면 가능한 한 많은 작업에 적용하려고합니다. 이 기능은 프로토콜 자체에는 필요하지 않지만 유효한 블록을 만들려는 채굴자에게는 유용합니다.

프로토콜 수정하기 (Amending the protocol)

Tezos의 가장 강력한 특징은 자체 개정(self-amendment)이 가능한 프로토콜을 구현할 수 있다는 것입니다. 이는 프로토콜에 아래와 같은 두 개의 프로시저 함수로 인해 가능하게 됩니다.

  • set_test_protocol 이는 testnet에서 사용 된 프로토콜을 일반적으로 이해관계자의(tez 소유자) 투표를 통해 채택 된 새로운 프로토콜으로 바꿉니다.

  • 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 파일의 타르볼(tarball)의sha256 해시입니다. 이 파일들은 즉시 컴파일되고 작은 표준 라이브러리에 액세스 할 수 있지만 샌드박싱(sandboxing)되어 어떤 시스템 호출도 하지 않습니다.

이 함수는 새로운 Context를 반환하는 프로토콜의 apply 함수를 통해 호출됩니다.

많은 조건이 프로토콜 변경을 만들어 낼 수 있습니다. 가장 단순한 버전에서는 이해관계자(tez 소유자) 투표로 인해 프로토콜이 변경됩니다. 점진적으로 좀 더 복잡한 규칙을 채택 할 수 있습니다. 예를 들어, 이해 관계자가 원하는 경우, 특정 속성을 존중히는 컴퓨터가 확인 가능한 증명를 제공한다는 새로운 추가 수정이 필요한 개정안을 통과시킬 수 있습니다. 이러한 것이 (프로그래밍 된) "헌법"(constitutionality)의 효과적이며 알고리즘적인 검사입니다.

원격 프로시저 호출(Remote Procedure Call ,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
    }

name은 프로시저에서 네임스페이스(namespace)를 허용하는 스트링(string, 문자열) 목록입니다. 입력 및 출력은 선택적으로 json 스키마로 설명됩니다.

이 호출은 일반적으로 가장 높은 점수를 가진 리프 노드의 최신 부모 노드 컨텍스트에서 수행됩니다. 예를 들어, 여섯 블록위의 컨텍스트를 쿼리하면 가장 높은 점수를 가진 리프노드에서 여섯번의 확인(confirmation)을 한 원장의 상태가 표시됩니다

UI 자체는 특정 버전의 프로토콜에 맞게 조정되거나 일반적으로 JSON 스펙에서 얻을 수 있습니다.

시드 프로토콜 (Seed protocol)


블록 체인이 제네시스 해시(Genesis hash)에서 시작하는 것처럼 Tezos는 시드 프로토콜로 시작합니다. 가상으로 어떤 블록체인 기반 알고리즘이든 반영하도록 프로토콜이 수정 될 수 있습니다.

이코노미 (Economy)


코인에 대해서

하나의 코인을 "테지(tez)"라고 하고 가장 작은 단위를 센트(cent)라고 합니다. 또한 tez를 나타내는 데 ꜩ(\ ua729, "라틴어의 작은 알파벳인 tz") 기호를 사용하는 것을 제안합니다. 모금 행사기간 동안 총 763,306,929.69ꜩ가 생성되어서 참여한 기부자에게 배포되었습니다.

마이닝과 사이닝 보상

원칙

추측하길, 분산화 된 통화의 안전성을 위해서 참가자들에게 금전적인 보상으로 인센티브를 주어야 합니다. Position paper에서 설명한 바와 같이, 거래 비용에 의존하는 것만으로 공유자의 비극을 겪고 있습니다. Tezos에서는 채권과 보상의 조합을 사용합니다.

채권은 채굴자와 보증인들이 구매 한 5사이클 (5-cycle) 담보 보증금입니다. 이중서명(double signing)의 경우, (페널티로)이 채권은 몰수됩니다.

사이클 후에 채굴자와 보증인들은 그들의 채권과 함께 기회비용에 대해 보상을 받습니다. 주로 채권의 가치에 의해 담보가 제공되며 보상은 채권 가치의 일부 작은비율만 있으면됩니다.

채권의 목적은 필요한 보상액을 줄이고 아마 네트워크에 손실회피(loss aversion)효과라는 장점을 주는 것입니다.

세부사항

시드 프로토콜에서 블록을 캐는 것은 16ꜩ 보상을 줍니다. 이를 위해서 하나의 블록을 만들때 512개의 ꜩ본드가 필요합니다. 블록에 서명하는 것은 어떤 블록이 먼저 만들어 졌느냐에 따라 최대 2ꜩ 보상을 제공합니다. 블록 당 최대 32개의 서명이 있으며 서명에는 64개의 ꜩ본드가 필요합니다.

보상은 명목상 인플레이션율인 최대 5.5%를 입니다. 명목인플레이션은 중립적이며, 누구(의 재산)를 좀 더 부자로 만들거나 가난하게 만들지 않습니다 2.

1년의 기간은 블록수가 아닌 블록의 타임스탬프에서 결정됩니다. 이것은 채굴자가 실행한 (블록체인)길이에 관한 불확실성을 제거하는 것입니다.

잃어버린 코인에 대해서 (Lost coins)

주소가 작동하지 않을 경우 컨센서스 알고리즘이 느려지므로 블록을 만드는 것을 선택하지 못하고 참여율에 대한 불확실성을 피하기 위해 다시 활성화 될 때까지 투표가 허용되지 않습니다.

개정 규칙 (Amendment rules)

개정안은 각 N=217=131072N=2^{17}=131072 블록동안 진행하는 선거 사이클이 끝나고 채택됩니다. 블록 인터벌이 1분임을 감안헤서 달력 시간으로 보자면 약 3개월입니다. 선거 사이클 자체가 215=327682^{15}=32768 블록의 4분의1로 나뉩니다. 이 사이클은 이른 개선을 권장하는 데는 상대적으로 짧은 기간이지만 추가 개정이 사이클의 기간을 늘릴 것입니다. 빠른 소프트웨어 개발 주기 반복이 가능하도록 첫 해에 프로토콜 업그레이드 투표가 훨씬 더 자주 실시됩니다. 보안 조치로서 Tezos 재단은 투표 절차에서 결함이 없을때까지 거부권을 행사할 것입니다. 이 거부권은 12개월 후에 만료됩니다. 후보 지명을 하려면 일정한 정족수가 충족되어야합니다. 이 정족수는 Q=80%Q=80\%에서 시작하지만 평균적인 참여율을 반영하도록 동적으로 조정됩니다. 이는 분실한 코인에 대해서 사용합니다.

첫번째 쿼터 (First quarter)

프로토콜 개정안은 새로운 프로토콜을 나타내는.ml.mli 파일의 tarball의 해시를 제출함으로써 제안됩니다. 이해 관계자는 이런 프로토콜들이 몇 개가 되든 승인 할 수 있습니다. 이는 특히 강력한 투표 절차인 "승인투표(approval voting)"로 알려져 있습니다.

두번째 쿼터 (Second quarter)

첫 쿼터에 가장 많은 승인을 얻은 개정안은 이제 투표 대상이 됩니다. 이해 관계자는 명시적으로 기권하거나, 반대 할 수 있습니다. 기권은 정족수에 포함됩니다.

세번째 쿼터 (Third quarter)

명백한 기권을 포함해서 정족수가 충족되고, 개정안에 80%80\%의 찬성이 접수되면 개정안이 승인되어 테스트 프로토콜을 대체합니다. 그렇지 않으면 거부됩니다. 정족수에 도달했다고 가정하면 qq, 최소 정족수 QQ는 다음과 같이 갱신됩니다. Q0.8Q+0.2q.Q\leftarrow 0.8 Q + 0.2 q.

이 업데이트의 목표는 시간이 지남에 따라 분실한 코인이 투표절차가 중단하도록 만드는 것을 막는 것입니다. 최소 정족수는 이전 선거 때마다 도달 한 정족수의 지수이동평균(EMA)입니다.

네번째 쿼터 (Fourth quarter)

개정안이 승인되었다고 가정하면 세번째 쿼터 초부터 테스트넷에서 실행됩니다. 이해관계자들은 (다시금) 두 번째로 투표하여 (제안된)테스트 프로토콜을 주요 프로토콜로 승격을 원한다는 것을 확인합니다. 이 또한 정족수가 충족되어야하고 80%80\% 압도적 다수가 필요합니다.

우리는 고의적으로 개정안에 대해서 보수적인 방식을 선택했습니다. 그러나 이해관계자들은 이 정책이 약하다고 생각하는 경우에 개정안을 느슨하게든 또는 타이트하게든 자유롭게 받아들일 수 있습니다.

지분 증명 매커니즘 (Proof-of-stake mechanism)


개요

우리의 증명 메커니즘은 슬래셔@Slasher, Chain of Activity[@CoA] 및 소각 증명(Proof-of-burn) 등 여러 아이디어가 혼합되어 있습니다. 다음은 알고리즘에 대한 간략한 개요입니다.이 알고리즘의 구성 요소는 아래에서 자세히 설명합니다.

각 블록은 임의의 광부가 채굴하고 임의의 서명자가 제공한 이전 블록의 여러 서명을 포함합니다. 채굴과 서명 둘다 모두 작은보상을 제공하지만 이중채굴(double mining) 또는 이중서명(double signing)의 경우 5사이클의 보장 보증금을 몰수해야합니다.

4,096 블록의 사이클안에서 프로토콜이 작동합니다. 각 사이클이 시작될 때, 무작위 시드는 블록 채굴자들의 숫자에서 얻고 마지막에서 두 번째 주기에서 정해지며 마지막에 나타납니다. 이 무작위 시드를 사용하여 코인 계획에 따라 다음주기의 특정 주소에 채굴권리를 서명권리를 할당하는 데 사용됩니다.

지분증명 매커니즘(proof-of-stake mechanism)의 4사이클: *Four cycles of the proof-of-stake mechanism*

클록(Clock)

프로토콜은 블록간에 최소로 지연되도록 합니다. 원칙적으로 각 블록은 어떤 이해 관계자든 채굴 할 수 있습니다. 그러나 주어진 블록에 대해 각 이해 관계자는 무작위 최소 지연에 따라야 합니다. 우선순위가 가장 높은 이해 관계자는 이전 블록에서 1분 후에 해당 블록을 채굴 할 수 있습니다. 두 번째로 높은 우선 순위를 받는 이해 관계자는 이전 블록의 2분 후에 채굴을 할 수 있습니다, 세 번째, 세 번째 등등도 마찬가지 입니다.

이는 소수의 일부 이해 관계자가 기여하는 (체인의)포크는 낮은 블록 생성 비율을 나타내는 것을 보장합니다. 그렇지 않은 경우, 노드를 속여 매우 높은 점수를 갖는 매우 긴 체인을 검증함으로써 CPU DDOS 공격이 가능할 수 있습니다.

무작위 시드 생성하기 (Generating the random seed)

마이닝 된 모든 블록은 광부가 선택한 임의의 숫자로 해쉬 커밋(hash commitment)을 가지고 있습니다. 이 숫자들은 보장 채권(safety bond)을 몰수한다는 벌칙에 따라 다음 사이클에 공개되어야 합니다. 이 가혹한 규칙은 선택되서 선점된(witholding) 숫자의 시드 엔트로피 공격을 방지하기위한 것입니다.(This harsh penalty is meant to prevent selective whitholding of the numbers which could be sued to attack the entropy of the seed. 번역의 적확성을 표시하기 위해 원문 삽임함 - 역자 주)

다음 사이클에 있는 악의적인 채굴자들은 이런 임의의 숫자들을 검열하려고 시도 할 수 있지만, 여러 개의 숫자가 하나의 블록에 나타날 수 있기 때문에 성공하기가 쉽지 않습니다.

공개 된 모든 숫자는 해시 리스트에 (수학적으로) 합쳐지며 시드는 루트에서 scrypt키 유도 함수를 사용하여 얻습니다. 시드는 일반적인 데스크톱 PC에서 블록의 평균 유효성 검사 시간 (average validation time)의 몇 퍼센트에 따라 유도한 키값(key derivation)을 조작해야만 합니다.

코인 추적 프로시져 (Follow-the-coin procedure)

무작위로 이해관계자를 선택하기 위해서 다음과 같은 코인 프로시져를 따릅니다.

규칙(Principle)

이 아이디어는 비트코인에서 사토시 따라가기(follow-the-satoshi)로 알려져 있습니다. "만약" 발행된 모든 사토시에는 고유한 일련 번호가 적혀 있다면 이 절차가 작동한다는 것입니다. 사토시는 무조건(implicitly)생성 시간에 따라 정렬되고 임의의 사토시가 블록체인을 통해 이동하고 추적됩니다. 물론 각각의 센트(사토시를 의미함- 역자 주)는 직접 추적되지 않습니다. 대신 입력이 합쳐져서 여러 출력에 걸쳐 사용될 때 어떤 일이 발생하는지 설명하기 위한 규칙이 적용됩니다.

결국, 알고리즘은 각 키와 연관된 구간셋을 추적합니다. 각 구간은 사토시 "범위"를 나타냅니다. 불행히도,시간이 지남에 따라 데이터베이스는 점점 더 쪼개져서 클라이언트 쪽에서 부풀려집니다.

코인 롤 (Coin Rolls)

우리는 tez로 구성된 큰 "코인 롤"을 구성하여 위에 언급한 알고리즘을 최적화합니다. 따라서 약 1백만개의 롤(roll)이 있습니다. 데이터베이스는 모든 롤(roll)을 현재 소유자에게 매핑합니다.

각 주소에는 특정 롤(roll)의 정해진 셋과 몇몇 코인(loose change , 롤(roll)에 들어가 있지 않는 tez를 뜻함- 역자주)이 있습니다. 전체 롤(roll)의 일부를 소비하고자 할 때, 롤이 없어지고(broken) 일련 번호가 일종의 "어중간한 상태(limbo 라고 표현 - 역자주)" 인 롤(roll)의 LIFO(후입 선출, Later In, Fisrt Out, 데이터베이스 구조인 Queue의 성질을 설명함 - 역자주) queue로 보내집니다. 모든 트랜잭션은 손상된 롤(roll) 수를 최소화하는 방식으로 처리됩니다. 주소에 동전을 충분히 쌓아 롤을 만들 때마다 일련 번호가 대기열에서 나오고 롤(roll)이 다시 형성됩니다.

LIFO의 우선권(LIFO priority)은 공격자가 그가 가지고 있는 계정들을 속인 코인을 비밀포크(Secret fork)에서 변경할 수 없도록 합니다.

이 방법의 작은 단점(sightly drawback)은 지분(의 개수를) 가장 롤(roll)의 정수 개수에 가장 가까운 숫자로 버림한다는(round down)것입니다. 그러나 이런 방식은 사토시 추적 방식(follow-the-satoshi)에 비해 효율성을 엄청나게 향상시킵니다.

롤(roll)이 (일련)번호가 매겨지는 동안, 이 방법은 Zerocash와 같은 대체 보존(Fungibility preserving) 프로토콜을 사용도록 합니다 이 프로토콜은 동일한 "limbo" queue 기술을 사용할 수 있습니다.

코인추적 프로시져 사용 동기 (Motivation)

이 절차는 그냥 잔고(balance)에 의해 가중치가 부여 된 임의의 주소를 만드는 것과 다릅니다.

사실 채굴자는 비밀포크에서 임의의 시드생성을 조정하고 적절한 주소를 미리 만들어서 스스로에게 서명 과 코인 발행 권리를 할당하려고 시도 할 수 있습니다. 숨겨진 포크는 특정 롤의 소유권을 위조 할 수 없고 서명 및 코인 발행 권한을 할당하기 위해 시드에 프리이미지된 해시 함수를 적용해야 합니다. 그러므로 만약 롤을 무작위로 선택하면 공격을 달성하기가 훨씬 더 어렵습니다.

실제로, 길이 N=2048N=2048의 사이클에서 롤의 일부분인 ff을 보유한 사람은 평균 fNf N 마이닝 권리와 유효한 부분을 가질 수 있으며 f0f_0의 표준 편차가 이래와 같이 1N1ff.\sqrt{\frac{1}{N}}\sqrt{\frac {1-f}{f}}. 가 됩니다.

만약 공격자가 WW가 다른시드로 무차별 대입 탐색을 한다면 공격자가 기대할 수 있는 이익은 아래처럼 최대한[3^] (2log(W)N1ff)fN\left(\sqrt{\frac{2\log(W)}{N}}\sqrt{\frac{1-f}{f}}\right)fN 블록이 됩니다.

예를 들어, 롤의 f=10%f=10\%를 제어하는 ​​공격자는 사이클 당 약 205205 블록을 채굴해야만 합니다. 공격자가 시드를 제어하고 있는 비밀 포크에서 1조개 이상의 해시를 계산했다고 가정하고 블록에 대해 302302블록 또는 약 14.7%14.7\%의 블록을 스스로에게 할당 할 수 있습니다. 참고 할 사항은 아래와 같습니다.

  • 비싼 키 유도 함수에서 나온 시드의 해시는 무차별 대항 검색에 대해서 비실용적입니다.

  • 마이닝된 블록에서 선형적인 이익을 얻기 위해 2차 지수 방정식을 푸는 정도의 노력이 필요합니다.

블록 채굴하기 (Mining blocks)

무작위 시드는 롤을 선택하는 데 반복적으로 사용됩니다. 선택된 첫 번째 롤은 이해 관계자가 1분 후에 블록을 채굴 할 수 있게하고 두 번째 롤은 2분 후 채굴 할 수 있습니다.

이해관계자가 시드를 보고하고 다음주기에 우선 순위가 높은 블록을 작성할 수 있다는걸 알게되면 임대 보증금을 낼 수 있습니다.

잠재적으로 문제가 되는 상황을 피하기 위해 특정 블록을 채굴하는 데 임대 보증금을 낸 이해 관계자가 없으므로 16 분 후에 블록을 보증금 없이 채굴 할 수 있습니다.

어떠한 체인에서도 블록을 채굴하지 않았기 때문에 채권은 구매자에게 즉시 암묵적으로 반환됩니다.

블록에 서명하기 (Signing blocks)

현재 우리는 지분 시스템에 대한 실질적인 증거를 거의 다 가지고 있습니다. 체인의 가중치를 블록의 수로 정의 할 수 있습니다. 그러나, 이것은 이기적 채굴(Selfish mining)의 형태가 될 지도 모릅니다.

따라서 우리는 서명에 대한 체계를 소개합니다. 이 체계는 블록이 발행되는 동안 무작위 시드가 32롤에 32개의 서명권한을 무작위로 할당하는 데 사용됩니다.

서명 권한을 받은 이해관계자는 발행 된 블록을 보고 다음 해당 블록의 서명을 제출합니다. 이런 서명들은 블록체인에 (자기가 생성한)부모 블록을 안전하게 포함시키려는 채굴자에 의해 다음 블록에 포함됩니다.

서명인이 받은 서명에 대한 보상은 블록을 채굴한 채굴자의 우선순위에 달려 있습니다. 우선 순위가 높을수록 서명에 대한 보상이 높습니다. 따라서 서명자는 정말로 그 순간 만들어진 최선의 블록이라고 믿는 곳에 서명 할 강한 동기가 있습니다. 또한 결국엔 블록이 블록체인에 포함 된 경우에만 서명 보상이 지급되기 때문에 (서명인이 )서명 할 블록에 동의하는 강한 동기를 가집니다.

채굴자가 온라인 상태가 아니기 때문일 수도 있어서 가장 우선 순위가 높은 블록이 채굴되지 않은 경우 채굴자가 늦는 경우를 대비하여 서명인이 잠시 기다릴 동기가 있을 수 있습니다. 그러나 다른 서명인이 최우선 순위 블록에 서명하기로 결정할 수 있으며 새로운 블록에 서명이 포함되어 계약보류 상황을 벗어날 수 있습니다. 따라서 채굴자들은 이 전략을 따르기 어렵습니다.

반대로 다른 서명자가 첫번째로 본 블록에 서명해서 새로운 블록이 바로 만들어 지는 것 때문에 서명인이 공황 상태에 빠지고 처음 서명 한 블록에 서명을 하는 그런 균형을 상상해 볼 수 있습니다. 그러나 이것은 아무에게도 이익이 되지 않는 매우 부자연스러운 상황입니다. 이런 방식으로 작동하도록 프로그램의 코드를 수정하기는 커녕, 이런 균형이 있다고 서명인이 생각할 동기가 없습니다. 운영을 방해하는 악의적인 이해관계자는 이런 전략을 따르기 때문에 다른 사람들이 뒤따를 가능성이 없고 스스로에게 손해를 끼칩니다.

체인의 무게 (Weight of the chain)

(체인의)무게는 사인의 개수입니다.

블록 발행 규칙을 어긴것에 대한 폐기통보 (Denunciations)

블록의 이중 발행이나 블록의 이중 서명을 피하기 위해 채굴자는 채굴한 블록에 폐기 통보를 포함 할 수 있습니다.

이 폐기 통보는 두 가지 서명의 형태를 취합니다. 블록의 높이에 발행 된 각 서명 또는 블록서명을 서명하여 부정 행위의 증거를 간결하게 만듭니다.

네트워크 참여자 중 누구나 부정 행위에 대해 폐기통보를 할 수 있지만 블록 채굴자외 다른 사람이 폐기 통보를 한다는 것은 의미가 없습니다. 사실, 채굴자는 부정행위에 대한 증거를 복사해서 자신이 발견 한 것 처럼 할 수 있습니다.4

당사자가 이중 발행이나 이중서명이라는 판결을 받으면 보장 채권은 몰수됩니다.

스마트 컨트랙트 (Smart contracts)

컨트랙트 타입

미사용 출력(unspent output) 대신 Tezos는 상태(stateful)계정을 사용합니다. 일반적으로 이런 계정들이 실행코드를 지정하면 컨트랙트로 알려집니다. 계정도 실행 코드가 없는 컨트랙트타입 이므로 계정과 컨트랙트 두가지 모두 일반적으로 \"컨트랙트\" 로 간주합니다.

각 컨트랙트에는 "관리자\"(manager)가 있으며, 계정의 경우에는 소유자를 나타냅니다. 컨트랙트에 지출이 있다고 표시되면 관리자는 컨트랙트와 관련된 자금을 사용할 수 있습니다. 또한 각 컨트랙트는 지분 증명 프로토콜에서 채굴된 블록이나 서명에 사용한 공개 키의 해시를 지정할 수 있습니다. 비밀키는 관리자가 제어하거나 제어하지 않을 수 있습니다.

컨트랙트는 형식상 다음과 같이 표현됩니다.


    type contract = {
      counter: int; (* counter to prevent repeat attacks *)
      manager: id; (* hash of the contract's manager public key *)
      balance: Int64.t; (* balance held *)
      signer: id option; (* id of the signer *)
      code: opcode list; (* contract code as a list of opcodes *)
      storage: data list; (* storage of the contract *)
      spendable: bool; (* may the money be spent by the manager? *)
      delegatable: bool; (* may the manager change the signing key? *)
    }

컨트랙트의 타이틀(handle)은 컨트랙트의 초기 내용의 해시입니다. 해시가 기존 계약과 충돌하는 계약을 만들려고하면 유효하지 않은 작업이며 올바른 블록에 포함될 수 없습니다.

데이터는 유니온 타입(union type)으로 표현합니다.

    type data =
      | STRING of string
      | INT of int

여기서 INT는 부호가 있는 64비트 정수이고 string은 바이트 크기 만큼의 배열(array)입니다. 저장용량은 바이트로 제한되며, 정수계산은 8바이트로, 문자열은 길이로 계산합니다.

스마트 컨트랙트의 작성 (Origination)

작성 오퍼레이션은 새로운 컨트랙트를 생성하는 데 사용될 수 있으며, 컨트랙트의 코드와 컨트랙트의 스토리지의 초기 내용을 정합니다. 실수나 악의로 인한 경우가 아니면 타이틀이 이미 기존 계약에 있다면 컨트랙트의 작성이 거부됩니다.

트랜잭션

트랜잭션은 한 계약에서 다른 계약으로 보낸 메시지입니다. 이 메시지는 다음과 같이 표시됩니다.

    type transaction = {
      amount: amount; (* amount being sent *)
      parameters: data list; (* parameters passed to the script *)
      (* counter (invoice id) to avoid repeat attacks *)
      counter: int;
      destination: contract hash;
    }

관리자의 키를 사용하여 서명한 경우나 컨트랙트에서 실행되는 코드를 통해 이런 트랜잭션들이 컨트랙트에서 전송할 수 있습니다. 트랜잭션을 받으면 해당 금액이 받는 컨트랙트의 잔액에 더해지고 해당 컨트랙트 코드가 실행됩니다. 이 코드는 (보낸이로부터) 전달된 파라메터를 사용할 수 있으며 컨트랙트 스토리지를 읽고 쓸 수 있으며 서명 키를 변경하거나 트랜잭션을 다른 컨트랙트로 보낼 수 있습니다.

카운터의 역할은 리플레이 공격(replay attack)을 막는 것입니다. 컨트랙트 카운터가 트랜잭션 카운터와 동일한 경우에만 트랜잭션이 유효합니다. 트랜잭션이 적용되면 카운터가 1씩 증가하여 트랜잭션이 재사용되지 않습니다.

또한 클라이언트가 유효한 것으로 간주하는 최근 블록의 블록 해시도 트랜잭션에 포함됩니다. 포크(fork)로 긴 리오그(re-organization, 블록체인의 재구성을 뜻함 - 역자 주 )를 강제하는것을 공격자가 성공시켜도 명백하게 포크를 가짜로 만드는 트랜잭션을 포함 시킬 수 없습니다. TAPOS는 최후의 방어선이며 장기적인 리오그를 방지하는 훌륭한 시스템이지만 단기간 이중 지불을 방지하는 시스템은 아닙니다.

(account_handle, counter) 은 비트코인의 미사용 출력값(unspent output)과 대체로 같습니다.

저장 수수료

스토리지(storage)가 네트워크에 비용을 부과하기 때문에 스토리지의 각 바이트가 늘어나는 것에 최소 1ꜩ 의 수수료가 부과됩니다. 예를 들어, 트랜잭션 실행 후 정수가 스토리지에 추가되고 스토리지의 기존 문자열에 10자가 추가되면 18ꜩ이 컨트랙트의 잔액에서 지출되고 없어집니다.

Code

언어는 스택(stack) 기반으로 높은 수준의 데이터 타입과 프리미티브(primitives) 및 엄격한 정적 타입 검사를 사용합니다. 이 설계는 Forth, Scheme, MLCat의 영향을 받았습니다. 명령어 셋의 전체 스펙은 [@language]에서 볼 수 있습니다. 이 스펙은 정확한 참조 설명서로 완전한 명령어 셋과 타입 시스템 및 프로그래밍 언어의 의미를 제공한다.

수수료

지금까지 이 시스템은 Ethereum이 트랜잭션을 처리하는 방식과 유사합니다. 그러나 우리는 수수료를 처리하는 방식이 다릅니다. Ethereum에서 긴 프로그램을 (사용자) 마음대로 실행하려면 프로그램 실행 시간에 비례해서 선형적으로 증가하는 수수료가 필요합니다 유감스럽게도 이것은 채굴자가 거래를 검증 할 동기를 제공하지만, 다른 채굴자에게는 이런 동기를 제공하지 않으며, 또한 이 트랜잭션을 검증해야만 합니다. 실제로 스마트 컨트랙트에서 사용될 수있는 흥미로운 프로그램의 대부분은 매우 짧습니다. 따라서 프로그램을 실행할 수있는 단계의 수를 엄격하게 제한함으로써 구조를 단순화합니다.

만약 제한(hard cap)이 일부 프로그램에 대해 너무 엄격한 것이면 여러 단계로 실행하는 중단하고 완전히 프로그램을 실행하기 위해 트랜잭션을 여러번 사용합니다. Tezos는 개정이 가능하기(amendable) 때문에 향후 이 캡을 변경하거나 새로운 opcode로 고급 프리미티브를 도입 할 수 있습니다.

계정이 허용한다면 변경을 요청 서명 메시지를 보내서하여 서명 키를 변경할 수 있습니다.

마무리

우리는 흥미로운 시드 프로토콜을 구축했다고 생각합니다. 그러나 자신에게 가장 잘 도움이 되는 프로토콜을 결정할 책임이 이해관계자에게 있다는 것이 Tezos의 진정한 잠재력 입니다.


  1. 반대로 Bitcoin의 채굴 인플레이션은 Bitcoin 보유자 전체를 가난하게 하고 중앙은행은 저축하는 사람들 희생시키면서 금융 부문을 풍요롭게합니다
  2. 영지식 증명(zero-knowledge proof)은 불법행위을 고발하는 것이 누구에게든 이익을 얻을 수 있게 해줄 것이지만, 이것은 더 이익을 가져다 준다는 것에서는 명확하지 않습니다.