Filecoin: A Decentralized Storage Network(백서, 한글번역)

Filecoin: A Decentralized Storage Network
Protocol Labs
July 19, 2017

요약

인터넷은 혁명의 한가운데에 있습니다. 중앙화된 독점 서비스는 분산된 공개 서비스로 대체되고 있습니다. 신뢰할 수 있는 당사자는 검증 가능한 계산으로 대체되었습니다.
취약한 위치 주소는 복원 가능한 컨텐츠 주소로 대체되었습니다. 비효율적인 모놀리식 서비스가 P2P 알고리즘 시장으로 대체되었습니다. 비트코인, 이더리움 및 기타 블록 체인 네트워크는 분산 트랜잭션 원장의 유용성을 입증했습니다.
이 공개 원장은 정교한 스마트 계약 애플리케이션을 처리하고 수 천억 달러에 이르는 암호화 자산을 거래합니다. 이 시스템은 참가자가 중앙 관리 또는 신뢰할 수 있는 당사자없이 유료 서비스를 제공하는 분산 네트워크를 형성하는 인터넷 전체 공개 서비스의 첫번째 인스턴스입니다. IPFS는 다음과 같은 방법으로 컨텐츠 주소 지정 유틸리티를 입증했습니다.
웹 자체를 분산시켜 전 세계 피어 투 피어 네트워크에서 사용되는 수십억 개의 파일을 제공합니다.
사일로에서 데이터를 방출하고, 네트워크 파티션에서 살아남고, 오프라인으로 작동하며, 검열 주변으로 라우팅하고, 디지털 정보에 대한 영구성을 제공합니다.

파일코인은 클라우드 스토리지를 알고리즘 시장으로 전환하는 분산형 스토리지 네트워크다.
광부들이 고객에게 스토리지를 제공해 벌어들이는 네이티브 프로토콜 토큰(일명 '파일코인'이라고도 함)을 가진 블록체인으로 시장이 운영된다. 반대로 고객들은 파일코인을 데이터를 저장하거나 배포하기 위해 광부를 고용하는 데 쓴다.
비트코인과 마찬가지로 파일코인 채굴업자들이 상당한 보상을 받으며 블록 채굴 경쟁을 벌이지만 파일코인 채굴력은 (블록체인 컨센서스 유지에 그 유용성이 한정된 비트코인 채굴업과 달리) 고객에게 유용한 서비스를 직접 제공하는 액티브 스토리지에 비례한다.

이것은 광부들이 가능한 한 많은 저장소를 축적하여 고객들에게 대여할 수 있는 강력한 동기를 만들어준다. 프로토콜은 이러한 축적된 리소스를 전 세계 누구나 신뢰할 수 있는 자가 치유 스토리지 네트워크로 통합한다. 네트워크는 콘텐츠를 복제하고 분산시키는 동시에 복제 오류를 자동으로 감지하고 복구함으로써 건전성을 달성한다.

클라이언트는 다양한 위협 모델로부터 보호할 복제 매개 변수를 선택할 수 있다. 프로토콜의 클라우드 스토리지 네트워크는 콘텐츠가 클라이언트에서 엔드투엔드로 암호화된 반면, 스토리지 제공자들은 암호 해독 키에 접근할 수 없기 때문에 보안도 제공한다. 파일코인은 어떤 데이터에도 스토리지 인프라를 제공할 수 있는 IPFS[1] 위에 인센티브 계층으로 작용한다. 특히 데이터 분산, 분산형애플리케이션 구축 및 실행, 스마트 컨트랙트 구현 등에 유용하다.

This work:
(a) 파일코인 네트워크 도입, 프로토콜 개요 제공과 몇 가지 요소를 상세하게 살펴본다.
(b) DSN(분권형 스토리지 네트워크) 체계와 그 속성을 공식화한 다음 DSN으로 파일코인을 구축한다.
(c) 데이터 복제본이 물리적으로 독립적인 저장소에 저장된다는 것을 증명할 수 있는, 복제 증명(proof-of-eplication) 방법의 새로운 클래스를 도입한다.
(d) 권력의 척도로서 순차적인 복제증거 및 저장에 근거한 새로운 유용한 작업 컨센서스를 소개한다.
(e) 검증 가능한 시장을 공식화하고, 각각 파일코인에 데이터를 쓰는 방법과 파일코인에 데이터를 읽는 방법을 지배하는 스토리지마켓과 회수(검색, 리트리벌) 마켓이라는 두 개의 시장을 구축한다.
(f) 이용사례, 다른 시스템과의 접속, 프로토콜 이용방법 등에 대해 논의한다.

Note: Filecoin is a work in progress. Active research is under way, and new versions of this paper will
appear at https://filecoin.io. For comments and suggestions, contact us at [email protected].

1 Introduction

파일코인은 블록체인이 데이터를 저장하는 광부들에 의해 블록이 생성되는 'Proof-of-Spacetime'이라는 새로운 증명으로 실행되는 프로토콜 토큰이다.
파일코인 프로토콜은 단일 코디네이터에 의존하지 않는 독립 스토리지 제공자 네트워크를 통해 데이터 저장 및 검색 서비스를 제공한다. (1) 고객은 데이터를 저장하고 검색하기 위해 지불하고 (2) 스토리지 광부들은 저장 기능을 제공하여 토큰을 얻는다.

1.1 Elementary Components

파일코인 프로토콜은 네 가지 새로운 요소를 기반으로 구축된다.
1. 분산형 스토리지 네트워크(DSN): 독립 스토리지 제공자의 네트워크가 스토리지 및 검색 서비스를 제공하는 추상화를 제공한다(2절). 나중에 파일코인 프로토콜을 인센티브가 부여되고 감사 가능하고 검증 가능한 DSN 구성으로 제시한다(섹션 4).
2. 새로운 스토리지 증명서: 두 가지 새로운 스토리지 Proof-Storage를 소개한다(섹션 3).
(1) Proof-Replication을 통해 스토리지 제공자는 고유한 전용 물리적 스토리지에 데이터가 복제되었음을 증명할 수 있다.
검증자는 고유한 물리적 복사본을 적용하여 검증자가 동일한 스토리지 공간에서 여러 데이터 복사본을 중복 제거하지 않는지 확인할 수 있다.
(2) PROF-of-Spacetime은 스토리지 제공자가 특정 시간 동안 일부 데이터를 저장했음을 증명할 수 있도록 허용한다.
3. 검증 가능한 시장: 파일코인 네트워크(섹션 5)가 운영하는 2개의 분산형 검증 가능한 시장에서 보관 요청 및 검색 요청을 주문으로 모델링한다. 검증 가능한 시장은 서비스가 올바르게 제공되었을 때 지급이 수행되도록 보장한다. 광부와 고객이 각각 저장 및 검색 주문을 제출할 수 있는 저장 시장과 검색 시장을 제시한다.
4. 유용한 작업증명서: 합의 프로토콜에서 사용할 수 있는 작업증명서(Proof-of-Spacetime)에 근거한 유용한 작업증명서를 구성하는 방법을 보여준다. 광부들은 블록을 채굴하기 위해 낭비적인 계산을 할 필요가 없고 대신 네트워크에 데이터를 저장해야 한다.

1.2 Protocol Overview

파일코인 프로토콜은 블록체인에 기본 토큰으로 구축된 분산형 스토리지 네트워크 구축이다. 고객들은 데이터를 저장하고 검색하기 위해 토큰을 소비하고 광부들은 데이터를 저장하고 제공함으로써 토큰을 얻는다.
파일코인 DSN은 스토리지 시장과 검색 시장의 두 가지 검증 가능한 시장을 통해 각각 저장 및 검색 요청을 처리한다. 고객들과광부들은 요청된 서비스의 가격을 정하고 그들의 주문을 시장에 제출한다.
시장은 파일코인 네트워크에 의해 운영되며, 파일코인 네트워크는 광부들이 저장하기로 약속된 데이터를 올바르게 저장하도록 보장하기 위해 Proof-of-Spacetime과 Proof-Replication을 채택한다.
마지막으로, 광부들은 밑줄 친 블록체인을 위한 새로운 블록 생성에 참여할 수 있다. 다음 블록에 대한 광부의 영향은 네트워크에서 현재 사용 중인 광부의 저장 용량에 비례한다. 문서 후반부에 정의된 명명법을 사용한 Filecoin 프로토콜의 스케치는 그림 2의삽화와 함께 그림 1에 표시된다.

1.3 Paper organization

이 논문의 나머지 부분은 다음과 같이 정리되어 있다. 이론적인 DSNscheme에 대한 정의 및 요구 사항을 섹션 2에 제시한다. 섹션3에서는 데이터가 거래에 따라 지속적으로 저장되는지 암호화된 검증에 파일코인 내에서 사용되는 복제 증명(Proof-of-Replication) 및 스페이스(Proof-of-Spacetime) 프로토콜의 동기를 부여, 정의 및 제시한다. 제4절에서는 파일코인 DSN의 구체적인 인스턴스화를 설명하고, 데이터 구조, 프로토콜 및 참가자 간의 상호작용을 설명한다. 섹션 5는 검증 가능한 시장의 개념과 그 구현인 스토리지 시장과 검색 시장의 개념을 정의하고 설명한다. 6절에서는 블록체인을 확장하고 블록 보상을 할당하는 데 필요한 채굴자의 네트워크에 대한 기여도를 실증하고 평가하기 위한 Special-of-Spacetime 프로토콜의 사용을 동기 부여하고 설명한다. 7절은 8절의 미래 작업에 대한 토론으로 결론을 내리는 파일코인 내의 스마트 계약에 대한 간략한 설명을 제공한다.

2 Definition of a Decentralized Storage Network

DSN(Distributed Storage Network) 체계의 개념을 소개한다. DSN은 여러 독립 스토리지 제공자가 제공하는 스토리지를 집계하고 고객에게 데이터 스토리지 및 데이터 검색을 제공하기 위해 자체 조정한다. 조정은 분산되고 신뢰할 수 있는 당사자가 필요하지 않다: 논문 시스템의 안전한 운영은 개별 당사자가 수행하는 운영을 조정하고 검증하는 프로토콜을 통해 이루어진다.
DSN은 시스템의 요건에 따라 비잔틴 협정, 가십 프로토콜 또는 CRDT를 포함한 서로 다른 조정 전략을 채택할 수 있다. 나중에 섹션 4에서 파일코인 DSN에 대한 구성을 제공한다.
Definition 2.1. A DSN scheme II is a tuple of protocols run by storage providers and clients:
(Put, Get, Manage)
● Put(data) → key: 클라이언트는 고유한 식별자 키 아래에 데이터를 저장하기 위해 Put 프로토콜을 실행한다.
● Get(key) → data: 클라이언트는 키를 사용하여 현재 저장된 데이터를 검색하기 위해 Get 프로토콜을 실행한다.
● Manage(): 참가자 네트워크는 Manage 프로토콜을 통해 다음과 같이 조정된다.
사용 가능한 스토리지를 제어하고, 제공자가 제공하는 서비스를 감사하며, 가능한 결함을 수리한다. 관리 프로토콜은 종종 클라이언트 또는 *감사인의 네트워크와 함께 스토리지 제공자에 의해 실행됨.
DSN scheme II는 데이터 무결성 및 검색 가능성을 보장하고 다음 절에 정의된 관리 및 스토리지 장애를 허용해야 한다.
*매니지먼트 프로토콜이 블록체인에 의존하는 경우, 광부들이 스토리지 제공자를 검증하고 조정하기 때문에 감사인으로 간주한다.

2.1 Fault tolerance

2.1.1 Management faults
우리는 관리 프로토콜의 참여자에 의해 야기되는 관리 결함을 비잔틴적인 결함으로 정의한다. DSN 체계는 밑줄 친 관리 프로토콜의 내결함성에 의존한다. 관리 결함에 대한 내결함성 가정에 대한 위반은 시스템의 내구성과 안전을 손상시킬 수 있다.
예를 들어 관리 프로토콜에서 스토리지 제공자를 감사하기 위해 Beanzine 계약(BA)을 필요로 하는 DSN 체계 II를 고려해 보십시오. 그러한 프로토콜에서, 네트워크는 스토리지 제공자들로부터 스토리지 증명서를 받고, BA를 실행하여 이러한 증명들의 타당성에 대해 합의한다. BA가 총 노드 수 n개 중에서 최대 f개의 장애를 허용한다면, 우리의 DSN은 f < n/2 결함 노드를 허용할 수 있다.
이러한 가정을 위반할 경우 감사가 손상될 수 있다.

2.1.2 Storage faults
우리는 저장고 결함을 고객들이 자료를 회수하지 못하도록 하는 비잔틴적인 결함으로 정의한다. 즉 저장 광부들은 그들의 작품을 잃어버리고, 회수 광부들은 서빙을 중단한다. 성공적인 Put 실행은 입력 데이터가 m 독립 스토리지 제공자(총 n개)에 저장되고 최대 f 비잔틴 제공자까지 허용할 수 있는 경우 (f, m) 내구성이 있다. 매개변수 f와 m은 프로토콜 구현에 따라 달라진다. 프로토콜 설계자는 f와 m을 수정하거나 사용자에게 선택권을 맡길 수 있으며, Put(데이터)을 Put(데이터, f, m)으로 확장할 수 있다. 결함이 있는 스토리지 제공자가 f명 미만일 경우 저장된 데이터에 대한 Get 실행이 성공적이다.
예를 들어, Put 프로토콜이 각 스토리지 제공자가 모든 데이터를 저장하도록 설계된 간단한 체계를 생각해 보십시오. 이 체계에서 m = n 및 f = m - 1. 항상 f = m - 1인가? 그렇지않다. 일부 체계는 삭제 코딩을 사용하여 설계할 수 있다. 각 스토리지 제공자가 데이터의 특별한 부분을 저장하므로, 이 경우 f = m - x의 데이터를 검색해야 한다.

2.2 Properties

DSN 구성에 필요한 두 가지 속성을 설명한 다음 파일코인 DSN에 필요한 추가 속성을 제시하십시오.

2.2.1 Data Integrity
This property requires that no bounded adversary A can convince clients to accept altered or falsified data
at the end of a Get execution.
이 속성은 어떤 경계 대상 A도 Get 실행이 끝날 때 고객이 변경되거나 변조된 데이터를 받아들이도록 설득할 수 없도록 요구한다.

2.2.2 Retrievability
이 속성은 II에 대한 당사의 오류 허용도 가정을 고려할 때, 일부 데이터가 성공적으로 II에 저장되고 스토리지 제공자가 프로토콜을 계속 따를 경우, 고객이 결국 데이터를 검색할 수 있다는 요구사항을 포착한다.
Definition 2.3. DSN 구성표 II는 다음과 같은 경우 검색 가능성을 제공함: 데이터 under key에 대한 성공적인 Put 실행키, 클라이언트가 *데이터를 검색하는 키에 대한 성공적인 Get 실행이 있다.
* 이 정의는 모든 Get이 성공하도록 보장하지는 않는다: 만일 모든 Get이 결국 데이터를 반환한다면, 그 계획은 공정하다.

2.2.3 Other Properties
DSN은 해당 애플리케이션과 관련된 다른 속성을 제공할 수 있다. 우리는 파일코인 DSN에서 요구하는 세 가지 핵심 속성, 즉 공개 검증 가능성, 감사 가능성 및 인센티브 호환성을 정의한다.
Definition 2.4. DSN 체계 II는 성공적인 각 Put에 대해 스토리지 제공자의 네트워크가 데이터가 현재 저장 중이라는 증거를 생성할 수 있는 경우 공개적으로 검증할 수 있다. 저장소 증명서는 키만 알고 데이터에 대한 액세스 권한이 없는 효율적인 검증자를 설득해야 한다.
Definition 2.5. DSN 구성표 II는 스토리지가 적절한 기간 동안 실제로 저장되었는지 확인하기 위해 나중에 확인할 수 있는 검증 가능한 작업 추적을 생성하는 경우 감사할 수 있다.
Definition 2.6. DSN 구성표 II는 인센티브와 호환되며, 다음과 같은 경우 스토리지 제공자가 성공적으로 보상받을 수 있다.
저장 및 검색 서비스를 제공하거나, 스토리지 제공자의 주요 전략이 데이터를 저장하는 것과 같은 잘못된 행동에 대해 벌칙을 부과
한다.

3 Proof-of-Replication and Proof-of-Spacetime

파일코인 프로토콜에서 스토리지 제공자들은 그들이 저장하기 위해 지불한 데이터를 저장했다고 그들의 고객에게 확신시켜야 한다.
실제로 스토리지 제공자들은 블록체인 네트워크(또는 고객들 스스로)가 검증하는 스토리지 증명서(PoS)를 생성한다.
이 섹션에서는 파일코인에 사용되는 PoRep(Proof-of-Replication) 및 PoSt(Proof-Spacetime) 계획에 대한 구현에 대한 동기 부여, 제시 및 개요를 설명한다.

3.1 Motivation

PDP(Provable Data Substance) [2] 및 PoR(Proof-of-Retrievability)[3, 4] 체계와 같은 PoS 체계에서는 데이터 D를 서버에 아웃소싱하는 사용자(예: 검증자 V)가 서버가 여전히 D를 저장 중인지 반복적으로 확인할 수 있다. 사용자는 데이터를 다운로드하는 것보다 더 효율적으로 서버에 아웃소싱된 데이터의 무결성을 확인할 수 있다. 서버는 무작위 블록 집합을 샘플링하여 확률론적 보유 증거를 생성하고 사용자와 챌린지/응답 프로토콜로 소량의 데이터를 전송한다.
PDP 및 PoR 체계는 챌린지 / 응답시 입증자가 일부 데이터를 소유했음을 보증합니다. Filecoin에서는 악의적 광부가 악용 할 수있는 세 가지 유형의 공격 (Sybil 공격, 아웃소싱 공격, 생성 공격)이 제공하지 않는 스토리지에 대한 보상을받을 수있는 강력한 보증이 필요합니다.

Sybil Attacks : 악의적 인 광부들이 사본보다 더 많은 사본을 저장하고 비용을 지불하는 것처럼 가장 할 수 있습니다
여러 Sybil ID를 생성하여 데이터를 저장하지만 데이터는 한 번만 저장합니다.
아웃소싱 공격 : 악의적 인 광부가 물리적으로 저장할 수있는 양보다 더 많은 데이터를 저장하겠다고 약속 할 수 있으며 다른스토리지 제공 업체로부터 데이터를 빠르게 가져 오는 데 의존합니다.
Generation Attacks: 악의적인 광부들은 대량의 데이터를 저장한다고 주장할 수 있으며, 대신 소규모 프로그램을 사용하여 효율적으로 온디맨드 방식으로 생성한다. 프로그램이 저장된 데이터보다 작을 경우 악성 채굴자가 현재 사용 중인 채굴자의 저장장치에 비례하는 파일코인으로 블록 보상을 받을 가능성을 부풀린다.

3.2 Proof-of-Replication

복제 증명 (PoRep)은 서버 (즉, 검증 자 P)가 일부 데이터 D가 고유 한 전용 물리적 스토리지에 복제되었음을 사용자 (즉, 검증 자V)에게 설득 할 수있는 새로운 스토리지 증명입니다. . 우리의 체계는 대화 형 프로토콜이며, 여기서 P : (a) 일부 데이터 D의 n 개의 개별 복제본 (물리적으로 독립적 인 복제본)을 저장하기로 약속 한 다음 (b) 검증 자 V가 P가 실제로 각 복제본을 저장하고 있음을 확인합니다. 챌린지 / 응답 프로토콜을 통해. 우리가 아는 한, PoRep은 PoR 및 PDP 체계를 개선하여 Sybil 공격, 아웃소싱 공격 및 생성 공격을 방지합니다.
Note. 공식적 정의, 그 속성에 대한 설명, 그리고 PROF-of-Replication에 대한 심층적인 연구를 위해, [5]를 참조.

Definition 3.1. (Proof-of-Replication) PoRep 체계는 P가 일부 데이터 D의 물리적 독립 복사본인 복제본 R을 P에만 저장한다는 것을 검증자 V에게 확신시킬 수 있게 한다. PoRep 프로토콜은 다항식 시간 알고리즘의 튜플이 특징이다:
(Setup, Prove, Verify)
PoRep.Setup(1λ, D) → R, SP , SV , where SP and SV are scheme-specific setup variables for P and V, λ
is a security parameter. PoRep.Setup is used to generate a replica R, and give P and V the necessary
information to run PoRep.Prove and PoRep.Verify. Some schemes may require the prover or interaction
with a third party to compute PoRep.Setup.

PoRep.Prove(SP , R, c) → πC , where c is a random challenge issued by a verifier V, and πC is a proof that a prover has access to R a specific replica of D. PoRep.Prove is run by P to produce a πC for V.
PoRep.Verify(SV , c, πc ) → {0, 1}, which checks whether a proof is correct. PoRep. Verify is run by V and convinces V whether P has been storing R.

3.3 Proof-of-Spacetime

스토리지 증명 체계를 통해 사용자는 스토리지 제공자가 도전 당시 아웃소싱된 데이터를 저장 중인지 확인할 수 있다. 일정 기간 동안 일부 데이터가 저장되고 있음을 입증하기 위해 PoS 체계를 어떻게 사용할 수 있는가? 이 질문에 대한 당연한 대답은 사용자가 스토리지 제공자에게 반복적으로(예: 매 분마다) 과제를 보내도록 요구하는 것이다. 다만 각 상호작용에 필요한 통신 복잡성은 스토리지 제공자가 증명서를 블록체인 네트워크에 제출해야 하는 파일코인과 같은 시스템의 병목현상이 될 수 있다.
이 질문을 해결하기 위해 검증자가 공간을 확보 한 아웃소싱 된 데이터를 일정 시간 동안 저장하고 있는지 확인할 수있는 새로운 시공간 증명 증명을 소개합니다. (1) 순차적 저장 저장 증명 (이 경우 복제 증명)을 생성해야합니다. (2) 짧은 증거를 생성하기 위해 실행을 재귀적으로 구성합니다.
Definition 3.2. (Proof-of-Spacetime) PoSt 방식은 효율적인 검증 자 P가 검증 자 V에게 P가 일정 시간 t 동안 일부 데이터 D를 저장하고 있음을 설득 할 수 있게 한다. PoSt는 다항식 시간 알고리즘의 튜플이 특징입니다:
(Setup, Prove, Verify)
PoSt.Setup(1λ , D) → SP , SV , where SP and SV are scheme-specific setup variables for P and V, λ is a security parameter.
PoSt.Setup is used to give P and V the necessary information to run PoSt.Prove and PoSt.Verify. Some schemes may require the prover or interaction with a third party to compute PoSt.Setup.
PoSt.Prove(SP , D, c, t) → πc, where c is a random challenge issued by a verifier V, and πc is a proof that a prover has access to D for some time t. PoSt.Prove is run by P to produce a πc for V.
PoSt.Verify(SV , c, t, πc) → {0, 1}, which checks whether a proof is correct. PoSt.Verify is run by V and convinces V whether P has been storing D for some time t.

3.4 Practical PoRep and PoSt

우리는 기존 시스템에 배치될 수 있고 신뢰할 수 있는 당사자 또는 하드웨어에 의존하지 않는 실용적인 PoRep 및 PoSt 구축에 관심이 있다. 복제본을 생성하기 위해 설치 중에 매우 느린 순차 계산 Seal을 수행해야 하는 PoRep([5]의 Seal-based Proof-ofReply in [5] 참조)을 위한 시공을 제공한다. PoRep 및 PoSt에 대한 프로토콜 스케치는 그림 4에 제시되어 있으며 PoSt에서 입증 단계의 기본 메커니즘은 그림 3에 제시되어 있다.

3.4.1 Cryptographic building blocks
충돌 방지 해싱. 충돌 저항 해시함수 CRH : {0, 1}∗ → {0, 1}O(()를 사용한다. 우리는 또한 충돌저항 해시함수 MerkleCRH를 사용하며, 이너리 트리를 만들어 CRH를 재귀적으로 적용하고 루트를 출력한다.
zk-SNARKs. PoRep과 PoSt의 실제 구현은 지식이없는 간결한 비 대화식 지식 인수 (zk-SNARK)에 의존합니다 [6, 7, 8]. zkSNARK는 간결하므로 증명은 매우 짧고 확인하기 쉽습니다. 보다 공식적으로 L은 NP 언어이고 C는 L의 결정 회로가 되어야합니다.
신뢰할 수 있는 당사자는 일회성 설정 단계를 수행하여 두 개의 공개 키 (프로빙 키 pk 및 확인 키 vk)를 생성합니다. 검증 키 pk를 사용하면 (신뢰할 수없는) 검증자가 선택한 인스턴스 x에 대해 x ∈ L을 증명하는 증명 π를 생성 할 수 있습니다. 비 대화식 증명 π는 제로 지식 및 증명 증명입니다. 누구나 검증 키 vk를 사용하여 증명 π를 검증 할 수 있습니다. 특히 zk-SNARK 증명은 공개적으로 확인할 수 있습니다. π를 생성 한 프로버와 상호 작용하지 않고도 누구나 π를 확인할 수 있습니다. 증거 π는 일정한 크기를 가지며 | x |에서 선형 인 시간으로 확인할 수 있습니다.

A zk-SNARK for circuit satisfiability is a triple of polynomial-time algorithms
(KeyGen, Prove, Verify)
KeyGen(1λ, C) → (pk, vk). On input security parameter λ and a circuit C, KeyGen probabilistically samples pk and vk.
Both keys are published as public parameters and can be used to prove/verify membership in LC.
Prove(pk, x, w) → π. On input pk and input x and witness for the NP-statement w, the prover Prove outputs a noninteractive proof π for the statement x ∈ LC .
Verify(vk, x, π) → {0, 1}. On input vk, an input x, and a proof π, the verifier Verify outputs 1 if
x ∈ LC .

zk-SNARK 시스템의 공식 발표 및 구현에 대해서는 [6, 7, 8]에 참조한다.
일반적으로 이러한 시스템은 신뢰할 수 있는 당사자가 KeyGen 작업을 실행하도록 요구한다. SCIP(Calable Computer Integrity and Privacy) 시스템에 대한 새로운 연구[9]는 이러한 초기 단계를 피할 수 있는 전도유망한 방향을 보여주며, 따라서 위의 신뢰 가정은 다음과 같다.

3.4.2 Seal operation
봉인 작업의 역할은 (1) 프로버에게 n개의 복제본을 저장하기로 확약함으로써(복제본의 저장소 크기의 n배) n개의 독립 복제본을 위한 전용 디스크 공간(disk space for n개의 복제본을 저장하도록 하고 (2) 복제본을 물리적으로 독립적으로 복사하도록 강제하는 것이다. PoRep 중 복제본 생성.도전에 응답하는 데 예상된 시간보다 상당히 오래 걸리는 설정. 씰 작업에 대한 보다 공식적인 정의는 [5]를 참조하십시오.
The above operation can be realized with Sealτ AES−256, and τ such that Sealτ AES−256 takes 10-100x longer than the honest challenge-prove-verify sequence. Note that it is important to choose τ such that running Sealτ
BC is distinguishably more expensive than running Prove with random access to R.

3.4.3 Practical PoRep construction
이 절에서는 PoRep 프로토콜의 구성을 설명하고 그림 4의 간단한 프로토콜 스케치를 포함하며, 구현 및 최적화 세부사항은 생략한다.
Creating a Replica. Setup 알고리즘은 Seal 작업과 그것이 올바르게 생성되었다는 증거를 통해 복제본을 생성한다. 프루버(검증자)는 복제본을 생성하고 출력물(R 제외)을 검증기로 보낸다.

Verifying the Proofs. Verify 알고리즘은 Merkle이 주어지면 저장 증명의 유효성을 검사합니다.
복제본의 루트와 원본 데이터의 해시. 증명은 공개적으로 검증 가능합니다.
원장을 유지 관리하는 시스템과 특정 데이터에 관심이 있는 고객은 이러한 증명을 확인할 수 있습니다.

3.4.4 Practical PoSt construction
이 절에서는 PoSt 프로토콜의 구성을 설명하고 그림 4의 간략화된 프로토콜 스케치를 포함하며, 구현 및 최적화 세부사항은 생략한다. Setup and Verify 알고리즘은 PoRep 구조와 동일하므로 여기서는 Proof만 설명한다.

Proving space and time. 증명 알고리즘은 복제본에 대한 Proof-of-Spacime을 생성한다. 프루버는 검증자로부터 무작위 도전을 받
고 정해진 반복 t의 양에 대해 다른 증명의 출력으로 다른 증명의 입력을 사용하여 순차적으로 증명의 출력을 생성한다(그림 3 참조).

3.5 Usage in Filecoin

Filecoin 프로토콜은 Proof-Spacetime을 사용하여 광부들이 제공하는 스토리지를 감사한다. 파일코인에 PoSt를 이용하기 위해 지정된 검증자가 없기 때문에 우리의 계획을 비인터랙티브로 수정하고, 우리는 네트워크의 어떤 구성원도 검증할 수 있기를 원한다.
우리의 검증기는 퍼블릭 코인 모델로 운영되기 때문에 블록체인의 임의성을 추출해 도전장을 낼 수 있다.

4 Filecoin: a DSN Construction

파일코인 DSN은 감사 가능하고 공개적으로 검증 가능하며 인센티브에 따라 설계된 분산형 스토리지 네트워크다. 고객들은 데이터 저장과 검색을 위해 광부 네트워크에 돈을 지불한다; 광부들은 지불의 대가로 디스크 공간과 대역폭을 제공한다. 광부들은 네트워크가 그들의 서비스가 올바르게 제공되었는지 감사할 수 있는 경우에만 지불금을 받는다.
이 섹션에서는 DSN 정의 및 Proof-Spacetime에 기반하여 Filecoin DSN 구성을 설명한다.

4.1 Setting

4.1.1 Participants
모든 사용자는 클라이언트, 저장 광부 및/또는 검색 광부로 참여할 수 있다.
 ● 클라이언트는 데이터 저장 및 DSN의 데이터 검색 시 Put 및 Get 요청을 통해 비용을 지불함
 ● 저장 광부들은 네트워크에 데이터 스토리지를 제공한다. 저장 광부들은 그들의 디스크 공간을 제공하고 Put 요청을 제공함으로써 파일코인에 참여한다. 저장 광부가 되려면 사용자는 저장소에 비례하는 담보를 예치하여 저장 서약을 해야한다. 저장 광부들은 고객의 데이터를 지정된 시간 동안 저장하기로 약속함으로써 Put 요청에 응답한다. 저장 광부들은 시간을 통해 데이터를 저장하고 있다는 것을 증명하기 위해 블록체인에 이를 제출한다. 유효하지 않거나 누락된 증거의경우, 저장 광부들은 벌칙을 받고 담보물의 일부를 느슨하게 한다. 저장 광부들은 또한 새로운 블록을 채굴할 자격이 있으며, 그렇게 함으로써 블록에 포함된 거래에 대한 블록과 거래 수수료를 창출한 것에 대한 채굴 보상을 받게 된다.
 ● 검색 광부들은 네트워크에 데이터 검색을 제공한다. 검색 광부들은 Get을 통해 사용자가 요청하는 데이터를 제공함으로써 파일코인에 참여한다. 저장 광부와 달리, 그들은 서약하거나, 데이터를 저장하기로 약속하거나, 저장 증거를 제공할 필요가 없다. 저장 광부들도 검색 광부로 참여하는 것은 당연하다. 검색 광부들은 고객들로부터 직접 또는 검색 시장에서 조각을 얻을 수 있다.

4.1.2 The Network, N
파일코인 전체 노드를 실행하는 모든 사용자를 단일 추상 엔터티로 지정한다. 네트워크. 네트워크는 관리 프로토콜을 실행하는 중개자 역할을 한다. 비공식적으로 파일코인 블록체인의 새로운 블록마다 전체 노드가 사용 가능한 스토리지를 관리하고, 서약을 검증하며, 스토리지 증명서를 감사하고, 가능한 결함을 수리한다.

4.1.3 The Ledger
우리의 프로토콜은 원장 기반 통화 위에 적용된다. 우리는 일반적으로 이것을 원장, L.라고 부른다. 우리는 이것을 어떤 주어진 시간 t (epoch라고 부름)에 모든 사용자들이 거래의 순서인 epoch t의 원장 Lt에 접근할 수 있다. 원장은 부록3이다. 파일코인 DSN 프로토콜은 파일코인의 증명서를 검증할 수 있는 모든 원장에 구현될 수 있다; 우리는 6절의 유용한 작업에 근거하여 어떻게 원장을 구성할 수 있는지를 보여준다.

4.1.4 The Markets
두 개의 파일코인 마켓에서 스토리지 수요 및 공급 충족: 스토리지 시장 및 회수 시장.
시장은 두 개의 분산형 거래소로서 제5절에 자세히 설명되어 있다. 간단히 말해서, 고객들과 광부들은 각 시장에 주문을 제출함으로써 그들이 요청하거나 제공하는 서비스의 가격을 책정한다.
거래소는 고객들과 광부들이 매칭 오퍼를 보고 거래를 시작할 수 있는 방법을 제공한다. 관리 프로토콜을 실행함으로써, 네트워크는 광부들이 보상을 받고, 요청된 서비스가 성공적으로 제공되었을 경우 고객들에게 요금을 부과하도록 보장한다.

4.2 Data Structures

Pieces. 조각은 클라이언트가 DSN에 저장하는 데이터의 일부분이다. 예를 들어, 데이터는 의도적으로 여러 조각으로 나눌 수 있고 각 조각은 다른 저장 광부 세트에 의해 저장될 수 있다.
Sectors. 섹터는 스토리지 Miner가 네트워크에 제공하는 일부 디스크 공간이다. 광부들은 고객들로부터 받은 조각들을 그들의 분야에 저장하고 그들의 서비스에 대한 토큰을 벌어들인다. 조각을 저장하기 위해서는 저장 광부들이 그들의 섹터를 네트워크에 서약해야 한다.
AllocationTable. AllocTable은 조각과 할당된 섹터를 추적하는 데이터 구조다.
AllocTable은 원장의 모든 블록에서 업데이트되며, 그것의 Merkle 루트는 최신 블록에 저장된다. 실제로 테이블은 DSN의 상태를유지하는 데 사용되므로 증명 확인 중에 신속하게 검색할 수 있다.
자세한 내용은 그림 5를 참조하십시오.
Orders. 주문은 서비스를 요청하거나 제공하려는 의향서를 말한다. 고객은 시장에 입찰 주문을 제출하여 서비스를 요청한다(resp).
데이터 저장을 위한 저장 시장과 데이터 검색을 위한 검색 시장) 및 광부들은 서비스 제공을 위한 주문서를 제출한다. 순서 데이터 구조는 그림 10과 같다. 시장 프로토콜은 섹션 5에 자세히 설명되어 있다.
Orderbook. 주문서는 주문의 집합이다. 자세한 내용은 섹션 5.2.2의 스토리지 시장 주문서 및 섹션 5.3.2의 검색 시장 주문서를 참조하십시오.
Pledge. 서약은 네트워크에 스토리지(특히 섹터)를 제공하겠다는 약속이다. 저장 광부들은 저장 시장에서의 주문 수령을 시작하려면 그들의 서약서를 장부에 제출해야 한다. 서약은 서약된 부문 규모와 스토리지 Miner가 예치한 담보물로 구성된다(자세한 내용은 그림 5 참조).

4.3 Protocol

이 섹션에서는 클라이언트, 네트워크 및 광부들에 의해 수행된 작업을 설명함으로써 파일코인 DSN에 대한 개요를 제공한다. 우리는 그림 7에서 Get과 Put 프로토콜의 방법과 그림 8에서 Manage 프로토콜의 방법을 제시한다. 프로토콜 실행의 예는 그림 6에 나와 있다. 전체적인 파일코인 프로토콜은 그림 1에 제시되어 있다.

4.3.1 Client Cycle
우리는 클라이언트 사이클에 대한 간략한 개요를 제공한다; 다음 프로토콜에 대한 상세한 설명은 섹션 5에 제시되어 있다.
1. Put: Client stores data in Filecoin.
고객은 스토리지 광부들에게 파일코인 토큰으로 돈을 지불하여 데이터를 저장할 수 있다. Put 프로토콜은 섹션 5.2에 자세히 설명되어 있다.
고객이 (블록체인에 주문을 제출하여) 스토리지 시장 주문서에 입찰 주문을 제출함으로써 Put 프로토콜을 개시한다. 광부들의 주문과 일치하는 것이 발견되면 의뢰인은 그 조각을 광부에게 보낸다.
양 당사자는 거래 주문서에 서명하여 스토리지 시장 주문서에 제출한다.
고객은 여러 주문을 제출(또는 복제 팩터를 순서에 지정)하여 작업물의 물리적 복제본 양을 결정할 수 있어야 한다. 중복성이 높으면 스토리지 장애에 대한 내성이 높아진다.
2. Get: Client retrieves data from Filecoin.
클라이언트는 파일코인 토큰으로 검색 광부에게 지불하여 DSN에 저장된 모든 데이터를 검색할 수 있다. Get 프로토콜은 섹션 5.3에 자세히 설명되어 있다.
클라이언트는 (네트워크에 주문을 가십하여) 회수 시장 주문서에 입찰 주문을 제출함으로써 Get 프로토콜을 개시한다. 광부들의 주문과 일치하는 것이 발견되면 의뢰인은 광부로부터 그 조각을 받는다.
수신되면 쌍방이 거래 주문서에 서명해 블록체인에 제출해 거래가 성공했는지 확인한다.

4.3.2 Mining Cycle (for Storage Miners)
We give an informal overview of the mining cycle.
1. Pledge: 저장 광부들은 네트워크에 저장소를 제공하겠다고 서약했다.
스토리지 채굴자는 'Manage.PledgeSector'를 통해 블록체인에 서약거래를 통해 담보를 입금하는 방식으로 네트워크에 스토리지를 서약한다. 담보는 서비스를 제공하고자 하는 기간 동안 입금되며, 광부가 저장하기로 한 데이터에 대한 저장 증거를 생성하면 반환된다. 일부 스토리지 증빙이 실패하면 비례적 담보가 손실된다. 일단 블록체인에 서약 거래가 등장하면 광부들은 스토리지 마켓에서 그들의 스토리지를 제공할 수 있다: 그들은 가격을 정하고 시장의 주문서에 주문서를 추가한다.

2. Receive Orders: 스토리지 광부들은 스토리지 시장으로부터 스토리지 요청을 받는다.
일단 블록체인에 서약거래가 등장하면('AllocTable'에서), 광부들은 스토리지 마켓에서 그들의 스토리지를 제공할 수 있다: 그들은 가격을 정하고 Put.AddOrders 을 통해 시장의 주문서에 주문서를 추가한다.

고객의 주문과 고객의 해당 입찰 주문이 일치하는지 확인, via Put.MatchOrders.

주문이 일치하면 고객은 저장 광부에게 데이터를 보낸다. 이 작품을 받을 때 광부들은 Put.ReceivePiece를 실행. 데이터가 접수되면 광부와 고객 모두 거래 주문서에 서명해 블록체인에 제출한다.

3. Seal: 저장 광부들은 미래의 증거를 위해 그 조각들을 준비한다.
저장 광부들의 스토리지는 섹터별로 나누어져 있으며, 각 섹터에는 광부에게 할당된 조각들이 포함되어 있다. 네트워크는 할당표를통해 각 스토리지 광부 영역을 추적한다. 저장 광부 섹터가 채워지면 섹터는 봉인된다. Sealing은 섹터의 데이터를 복제품으로 변환하는 느리고 순차적인 작업으로, 스토리지 Miner의 공용 키와 관련된 데이터의 고유한 물리적 복사본이다. 봉인작업은 3.4절에 기술된 복제증명서 작성 동안에 필요한 작업이다.

4. Prove: 저장 광부들은 그들이 약속한 조각들을 저장하고 있다는 것을 증명한다.
저장 광부에게 데이터가 할당될 때 반복적으로 복제 증빙을 생성하여 데이터를 저장하는지 확인해야 한다(자세한 내용은 섹션 3 참조). 블록체인에 증명서가 게시되고 네트워크가 이를 검증한다.

4.3.3 Mining Cycle (for Retrieval Miners)
우리는 검색 광부들의 채굴 주기에 대한 비공식적인 개요를 제공한다.
 ● 주문 접수: 검색 광부들은 검색 시장에서 자료 요청을 받는다.
검색 광부들은 네트워크에 요청 명령을 받음으로써 자신의 조각을 알린다.
가격을 설정하고 시장 주문서에 주문 요청을 추가합니다.

그런 다음 검색 광부는 주문이 고객의 해당 입찰 주문과 일치하는지 확인합니다.

2. Send: Retrieval Miners send pieces to the client.

주문이 일치하면 검색 채굴자는 해당 조각을 고객에게 보냅니다 (자세한 내용은 섹션 5.3 참조).
조각이 접수되면 광부와 고객 모두 거래 주문에 서명하고이를 블록 체인에 제출합니다.

4.3.4 Network Cycle
우리는 네트워크에 의해 운영되는 운영에 대한 비공식적인 개요를 제공한다.
1. Assign: 네트워크는 고객의 작품을 스토리지 광부 부문에 할당한다.
고객은 스토리지 마켓4에서 입찰 주문을 제출하여 Put 프로토콜을 시작한다.
질의와 입찰 주문이 일치하면 관련 당사자들이 공동으로 거래소에 위임하고 시장에서 거래 주문을 제출한다. 이 시점에서, 네트워크는 데이터를 광부에게 할당하고 할당표에 기록한다.

2. Repair: 네트워크는 결함을 찾아 복구를 시도한다.
모든 스토리지 할당은 네트워크의 모든 참가자에게 공개된다. 모든 블록에서, 네트워크는 각 할당에 필요한 증명서가 있는지 확인하고, 증명서가 유효한지 확인하고, 그에 따라 행동한다.
 ● 증거 누락 또는 무효인 경우, 네트워크는 저장 광부에게 담보물의 일부를 제공함으로써 불이익을 준다.
 ● 다량의 증명이 누락되거나 무효(시스템 매개변수 결함으로 정의), 네트워크는 스토리지 Miner의 결함을 고려하고, 실패한 것으로 주문을 정리한 후, 동일한 부품에 대한 새로운 주문을 시장에 재도입한다.
 ● 이 작품을 보관하는 모든 스토리지 Miner에 결함이 있는 경우, 해당 작품은 분실되고 고객은 환불을 받는다.

4.4 Guarantees and Requirements

다음은 파일코인 DSN이 무결성, 검색 가능성, 공개 검증 가능성 및 인센티브 호환성을 달성하는 방법에 대한 직관이다.

Achieving Integrity: 조각들은 암호 해시의 이름을 따서 명명된다. Put 요청 후 클라이언트는 Get을 통해 데이터를 검색하고 수신한 콘텐츠의 무결성을 확인하기 위해 이 해시를 저장하기만 하면 된다.
Achieving Retrievability: Put 요청에서 클라이언트는 복제 팩터와 원하는 삭제 코딩 유형을 지정하여 스토리지를 (f, m) 내구성(tollerant)으로 지정한다. 이러한 가정은 데이터를 저장하는 M 스토리지 광부에게 주어진 최대 f 결함은 허용된다는 것이다. 고객은 둘 이상의 스토리지 Miner에 데이터를 저장함으로써 스토리지 Miner가 오프라인으로 전환되거나 사라질 경우 복구 가능성을 높일 수 있다.
Achieving Public Verifiability and Auditability: 스토리지 채굴자는 자신의 스토리지 증명서(πSEAL, πPOST)를 블록체인에 제출해야 한다. 네트워크의 모든 사용자는 아웃소싱된 데이터에 접근하지 않고도 이러한 증명들의 타당성을 확인할 수 있다. 증빙 자료는 블록체인에 저장돼 있기 때문에 언제든 감사가 가능한 운용의 흔적이다.
Achieving Incentive Compatibility: 비공식적으로, 광부들은 그들이 제공하는 저장고에 대해 보상을 받는다.
광부들이 어떤 자료를 저장하기로 약속할 때, 그들은 증거를 만들어야 한다. 증빙자료를 건너뛰는 광부들은 (담보의 일부를 잃음으로써) 불이익을 받고 저장한 것에 대해 보상을 받지 못한다.
Achieving Confidentiality: 자신의 데이터가 비공개로 저장되기를 원하는 클라이언트는 데이터를 네트워크에 제출하기 전에 암호화해야 한다.

5 Filecoin Storage and Retrieval Markets

파일코인은 저장 시장과 회수(검색) 시장 두 개의 시장을 가지고 있다.
두 시장은 구조는 같지만 디자인은 다르다. 스토리지 시장은 고객이 데이터를 저장하기 위해 스토리지 광부에게 지불할 수 있도록한다. 회수 시장은 고객이 회수 광부들에게 돈을 지불하여 데이터를 회수할 수 있도록 한다. 두 경우 모두 고객들과 광부들은 그들의 오퍼와 수요 가격을 정하거나 현재의 오퍼를 받아들일 수 있다. 교환은 네트워크에 의해 실행된다 - 파일코인의 전체 노드 네트워크를 의인화한다. 네트워크는 광부들이 서비스를 제공할 때 고객들로부터 보상을 받는 것을 보장한다.

5.1 Verifiable Markets

거래소 시장은 특정 재화나 서비스의 교환을 촉진하는 프로토콜이다. 그들은 구매자와 판매자가 거래를 할 수 있게 함으로써 이것을 한다. 우리의 목적을 위해, 우리는 교환이 검증 가능할 것을 요구한다.
참가자들의 분산된 네트워크는 구매자와 판매자 사이의 교환을 확인할 수 있어야 한다.
우리는 단일 주체가 거래소를 지배하지 않고, 거래는 투명하며, 누구나 가명적으로 참여할 수 있는 검증 가능한 시장의 개념을 제시한다. 검증 가능한 시장 프로토콜은 상품/서비스의 교환을 분산형 방식으로 운영한다. 즉, 주문서의 일관성, 주문 정산 및 정확한 서비스 실행은 참여자-파일코인의 경우 광부 및 전체 노드를 통해 독립적으로 검증된다. 우리는 다음과 같은 구조가 되도록 검증 가능한 시장을 단순화한다.

Definition 5.1. 검증 가능한 시장은 주문 매칭과 결제라는 두 가지 단계를 가진 프로토콜이다. 주문은 보안, 재화 또는 서비스를 구입하거나 판매하려는 의향서이며 주문서는 사용 가능한 모든 주문의 목록이다.

5.2 Storage Market

스토리지 시장은 고객(즉, 구매자)이 데이터를 저장할 스토리지를 요청하고 스토리지 광부(판매자)가 스토리지를 제공할 수 있는 검증 가능한 시장이다.

5.2.1 Requirements
We design the Storage Market protocol accordingly to the following requirements:
In-chain orderbook: 중요한 것은 (1) 스토리지 광부 주문이 공개되어 항상 최저 가격이 네트워크에 알려지고 고객이 주문에 대해 정보에 입각한 결정을 내릴 수 있도록 하는 것이다.
(2) 고객 주문은 항상 주문서에 제출되어야 하며, 비록 그들이 최저 가격을 받아들이더라도, 시장이 새로운 오퍼에 반응할 수 있는방식으로 제출되어야 한다. 따라서 우리는 주문서에 추가하기 위해 파일코인 블록체인에 주문을 명확히 추가해야 한다.
Participants committing their resources: 우리는 스토리지 광부들이 서비스를 제공하지 않는 것과 이용 가능한 자금이 없는 고객들을 피하기 위한 방법으로서 양 당사자들이 그들의 자원에 전념할 것을 요구한다.
스토리지 시장에 참여하려면 스토리지 채굴자가 DSN에 스토리지 양에 비례하는 담보물을 입금하는 것을 약속해야 한다(자세한 내용은 섹션 4.3.3 참조). 이러한 방식으로, 네트워크는 저장하기로 약속한 조각에 대한 저장 증거를 제공하지 않는 저장 광부들에게 불이익을 줄 수 있다. 이와 유사하게, 고객들은 이러한 방식으로 결제 중 자금의 약속과 가용성을 보장하면서 순서에 명시된 자금을 입금해야 한다.
Self-organization to handle faults: 저장 광부들이 합의된 기간 동안 그 조각들을 보관했다는 것을 반복적으로 증명했을 경우에만 주문이 해결된다. 네트워크는 규칙 Subsection 4.3.4의 보수. 부분에 기술에 따라 존재와 이러한 증거와 정확한 행위를 확인할 수 있어야 한다.

5.2.2 Datastructures
Put Orders. 주문은 입찰 주문, 주문 문의, 거래 주문의 세 종류가 있다. 저장 광부들은 저장소를 추가하기 위해 주문서를 작성하고, 고객은 저장소를 요청하기 위해 입찰 주문을 작성하며, 쌍방이 가격에 합의하면 그들은 공동으로 거래 주문을 만든다. 주문의 데이터 구조는 그림 10에 자세히 나타나 있으며, 주문의 매개변수를 명시적으로 정의하고 있다.
Put Orderbook. 스토리지 시장의 주문서는 현재 유효하고 공개적인 요청, 입찰 및 거래 주문의 집합이다. 사용자는 Put 프로토콜(그림 7에 설명된 대로 AddOrders, MatchOrders.)에 정의된 방법을 통해 주문서와 상호작용할 수 있다.
주문서는 공개적이며 모든 정직한 사용자들은 주문서를 같은 시각으로 본다. 모든 시대마다 새로운 블록체인 블록에 새로운 주문거래(txorder)가 나타나면 새로운 주문이 추가되고, 주문이 취소, 만료 또는 결제되면 제거된다. 주문은 블록체인에 추가되며, 따라서 주문서가 유효할 경우 주문서에 다음과 같이 추가된다.

Remark. 악의적인 클라이언트가 스토리지 Miner로부터 서명된 계약을 받았으나 주문서에 추가하지 않으면 스토리지 Miner는 해당 거래에서 커밋된 스토리지를 다시 사용할 수 없다. 필드 ts는 ts 이후 주문이 무효화되어 주문서에 제출할 수 없기 때문에 이 공격을 방지한다.

5.2.3 The Storage Market Protocol
In brief, the Storage Market protocol is divided in two phases: order matching and settlement:
Order Matching: 고객과 스토리지 채굴자는 블록체인에 거래처(1단계)를 제출해 주문서에 주문서를 제출한다. 주문이 일치하면 고객은 해당 부품을 스토리지 Miner에 보내고 양 당사자는 거래 주문서에 서명하여 주문서(2단계)에 제출한다.
Settlement: 스토리지 채굴자는 해당 섹터를 봉인하고(3a단계) 해당 섹터가 담긴 보관 증빙을 생성해 블록체인에 정기적으로 제출(3b단계)하는 한편, 나머지 네트워크는 채굴자가 생성한 증빙을 검증하고 가능한 결함(3c단계)을 수리해야 한다. 스토리지 시장 프로토콜은 그림 11에 자세히 설명되어 있다.

5.3 Retrieval Market

회수 시장은 의뢰인들이 특정 조각에 대한 회수 및 광부 회수를 요청할 수 있도록 한다.
저장 광부와 달리 회수 광부는 시간 경과에 따라 조각을 보관하거나 저장 증거를 생성할 필요가 없다. 네트워크에 있는 사용자라면 누구나 파일코인 토큰과 교환해 조각을 제공함으로써 검색광부가 될 수 있다. 회수 광부들은 고객들로부터 직접 그것들을 수령하거나 회수 시장에서 그것들을 인수하거나 저장 광부로부터 그것들을 저장함으로써 그것들을 얻을 수 있다.

5.3.1 Requirements
We design the Retrieval Market protocol accordingly to the following requirements:
Off-chain orderbook: 고객들은 가격을 정리한 후에 필요한 물건을 제공하는 회수 광부들을 찾아 직접 교환할 수 있어야 한다.
이는 블록체인을 통해 주문서를 실행할 수 없다는 것을 의미하며, 이는 빠른 검색 요청에 대한 병목 현상이 될 것이기 때문이다.
참가자는 OrderBook에 대한 부분 뷰만 가질 수 있다. 따라서 우리는 쌍방이 그들의 명령을 퍼뜨리도록 요구한다.

Retrieval without trusted parties: 공정 거래에 대한 불가능 결과[10]는 신뢰할 수 있는 당사자 없이 두 당사자가 교환을 수행하는 것은 불가능하다는 것을 상기시킨다. 스토리지 시장에서 블록체인 네트워크는 스토리지 채굴자가 제공하는 스토리지를 검증하는 (탈중앙화) 신뢰 당사자 역할을 한다. 회수 시장에서 회수 광부들과 고객들은 네트워크가 파일 교환을 목격하지 않고 데이터를 교환한다. 우리는 회수 광부에게 그들의 데이터를 여러 부분으로 나누도록 요구함으로써 이 결과를 돌아보고 그들은 고객에게 보내는 각 부분에 대해 지불을 받는다.
이런 식으로 의뢰인이 지불을 중단하거나 광부가 데이터 전송을 중단하면 어느 한쪽 당사자가 교환을 중단할 수 있다.
이것을 작동시키기 위해서는, 우리는 항상 한 명의 정직한 회수 광부가 있다고 가정해야 한다.
Payments channels: 고객들은 지불금을 제출하는 즉시 그 조각들을 회수하는 데 관심이 있고, 회수 광부들은 그들이 확실히 그 조각들을 받을 수 있는 경우에만 서빙하는 것에 관심이 있다.
지불 공과대장을 통한 지급 확인은 회수 요청의 병목현상이 될 수 있으므로 효율적인 오프체인 지급에 의존해야 한다. 파일코인 블록체인은 신속하고 낙관적인 거래가 가능한 결제 채널을 지원하고 분쟁 발생 시에만 블록체인을 이용해야 한다. 이런 식으로, 회수 광부들과 고객들은 우리의 의정서가 요구하는 소액의 지불금을 신속하게 보낼 수 있다. 미래 업무는 이전에 [11, 12]에서 본 바와 같이 지급 채널의 네트워크 구축을 포함한다.

5.3.2 Data Structures
Get Orders. 회수시장에는 거래처들이 입찰주문 오비드를 만들고, 회수광부들이 주문오스크를 만들고, 거래주문 오딜은 저장광부와 거래자가 거래에 합의할 때 공동으로 만들어진다. 주문의 데이터 구조는 그림 10에 자세히 나와 있다.
Get Orderbook. 회수 시장의 주문서는 유효하고 공개적인 요청, 입찰 및 거래 주문의 집합이다. 스토리지 시장과 달리 주문은 네트워크에서 퍼뜨리고 각 광부와 클라이언트는 관심 있는 주문만 추적하기 때문에 모든 사용자는 주문서를 다르게 본다.

5.3.3 The Retrieval Market Protocol
In brief, the Retrieval Market protocol is divided in two phases: order matching and settlement:
• Order Matching: 고객들과 회수 광부들은 그들의 주문을 퍼뜨려(gossiping) 주문서에 제출한다(1단계). 주문이 일치하면 고객과 회수 광부들은 마이크로페이먼트(아주 소규모 지불) 채널(2단계)을 구축한다.
Settlement: 검색 채굴자는 조각의 작은 부분을 클라이언트에게 보내고 각 조각에 대해 클라이언트가 채굴자에게 영수증을 보냅니다 (3 단계). 검색 채굴자는 배달 영수증을 블록 체인에 제시하여 보상을 받습니다 (4 단계).
The protocol is explained in details in Figure 12

6 Useful Work Consensus

파일코인 DSN 프로토콜은 파일코인의 증명서를 검증할 수 있는 모든 합의 프로토콜 위에 구현될 수 있다. 이 섹션에서는 유용한 작업에 기반한 컨센서스 프로토콜을 어떻게 부팅할 수 있는지 설명한다. 작업증명서 계산 대신 파일코인 채굴자들이 하는 작업으로 Proof-Spacetime을 만들어 내는 것이 컨센서스에 참여할 수 있게 하는 것이다.
Useful Work. 우리는 합의된 프로토콜에서 광부들이 한 작업이 블록체인을 확보하는 것을 넘어 네트워크로 귀중하다면 유용하다고 생각한다.

6.1 Motivation

블록체인을 확보하는 것이 기본이지만, 작업증명제도는 종종 재사용할 수 없거나 찾기 위해 상당한 양의 계산이 필요한 퍼즐을 풀어야 한다.
Non-reusable Work: 대부분의 무허가 블록 체인은 해시 함수 반전과 같은 어려운 계산 퍼즐을 풀기 위해 광부가 필요하다. 이러한 퍼즐에 대한 솔루션은 종종 쓸모가 없으며 네트워크 보안 이상의 고유 한 가치가 없다. 이 작업을 유용한 것으로 재사용 할 수있을까?
Attempts to re-use work: 유용한 계산을 위해 채굴력을 재이용하려는 시도가 여러 번 있었다. 어떤 노력들은 광부들이 표준 작업증명서와 함께 특별한 연산을 수행하도록 요구한다. 다른 노력들은 작업증명서를 여전히 풀기 어려운 유용한 문제들로 대체한다. 예를 들어 프라임코인은 광부들의 연산력을 재이용해 새로운 프라임 넘버를 찾고, 이더리움은 작업증명서와 함께 작은 프로그램을 실행하도록 하고, 퍼마코인은 일부 데이터가 보관되고 있다는 것을 증명하면서 광부들에게 해시함수를 뒤집도록 요구함으로써 아카이브서비스를 제공한다.
이러한 시도의 대부분은 유용한 작업을 수행하지만, 낭비되는 작업의 양은 여전히 이러한 계산에서 일반적인 요인이다.
Wasteful Work: 어려운 퍼즐을 푸는 것은 기계와 에너지 소비의 측면에서 정말 비용이 많이 들 수 있는데, 특히 이러한 퍼즐들이 계산력에만 의존한다면 더욱 그렇다. 채굴 알고리즘이 당황스러울 정도로 평행할 때 퍼즐을 푸는 일반적인 요인은 계산력이다. 낭비하는 일의 양을 줄일 수 있을까?
Attempts to reduce waste: 이상적으로는 네트워크 자원의 대다수가 유용한 작업에 사용되어야 한다.
어떤 노력들은 광부들이 더 에너지 효율적인 해결책을 사용하도록 요구한다. 예를 들어, 스페이스민트는 광부들에게 계산보다는 디스크 공간을 전용하도록 요구한다. 에너지 효율이 더 높지만, 디스크는 무작위 데이터로 채워져 있기 때문에 여전히 "소진" 상태에 있다. 퍼즐을 풀기 위한 다른 노력들은 이해당사자들이 제도에서 그들의 화폐의 몫에 비례하여 다음 블록을 투표하는 "Proof-of-Stake"에 기초한 전통적인 비잔틴 합의로 대체된다.
우리는 사용자 데이터 저장에 기반한 유용한 작업으로 컨센서스 프로토콜 설계에 착수했다.

6.2 Filecoin Consensus

우리는 네트워크가 광부를 선택하여 창조할 확률을 나타내는 유용한 작업 컨센서스 프로토콜을 제안한다.
새로운 블록(우리는 이것을 광부의 의결권이라고 부른다)은 네트워크의 나머지 부분과 관련하여 현재 사용 중인 저장장치에 비례한다. 우리는 광부들이 광산 컴퓨팅을 병렬화하기 위해 컴퓨팅 파워보다는 스토리지에 투자하도록 파일코인 프로토콜을 설계한다. 광부들은 합의사항에 참여하기 위해 데이터가 저장되고 있다는 증거를 위해 저장 및 계산을 다시 사용한다.

6.2.1 Modeling Mining Power
Power Fault Tolerance. 기술 보고서 [13]에서는 프로토콜 결과에 대한 참가자의 영향 측면에서 비잔틴적인 결함을 재프레임하는 추상화인 Power Fault Tolerance를 제시한다. 모든 참여자는 n이 네트워크의 총 파워인 어느 정도의 파워를 제어하며, f는 결함이 있거나 적대적인 참여자들에 의해 제어되는 파워의 일부분이다.

In Filecoin, power has the following properties:
Public: 현재 네트워크에서 사용되고 있는 총 스토리지 양은 공개적이다. 블록체인을 읽음으로써, 누구나 각 광부의 스토리지 할당량을 계산할 수 있기 때문에 누구나 언제든지 광부의 파워와 총 전력량을 계산할 수 있다.
Publicly Verifiable: 각 스토리지 할당에 대해 광부들은 Spacetime 증명서를 생성하여 서비스가 제공되고 있음을 증명해야 한다. 블록체인을 읽음으로써 누구나 광부가 주장하는 파워가 맞는지 확인할 수 있다.
Variable: 언제든지 광부들은 새로운 섹터를 약속하고 섹터를 채움으로써 네트워크에 새로운 스토리지를 추가할 수 있다. 이런식으로 광부들은 시간을 통해 그들이 가진 힘의 양을 바꿀 수 있다.

6.2.2 Accounting for Power with Proof-of-Spacetime
Δproof Block6마다, 광부들은 네트워크에 Proof-of Spacetime을 제출하도록 요구되는데, 이는 단지 Δproof blocks6에 불과하다.
네트워크에서 대다수의 파워가 블록체인을 유효하다고 간주할 경우 블록체인에 성공적으로 추가된다. 모든 블록에서 모든 전체 노드는 할당 테이블을 업데이트하여 새 스토리지 할당을 추가하고 만료된 스토리지 할당을 제거하고 누락된 증빙을 표시한다.

Miner Mi의 힘은 두 가지 방법으로 할 수 있는 AssignmentTable의 항목들을 합하여 계산하고 검증할 수 있다:

 ● Full Node Verification: 노드에 전체 블록체인 로그가 있는 경우 제네시스 블록에서 현재 블록까지 NetworkProtocol을 실행하고 Mi를 위한 AllocTable를 읽으시오. 이 프로세스는 Mi에 현재 할당된 스토리지에 대해 모든 PROF-Of Spacetime을 확인한다.
 ● Simple Storage Verification: 라이트 클라이언트가 최신 블록을 브로드캐스트하는 신뢰할 수 있는 소스에 액세스할 수 있다고 가정하십시오. 라이트 클라이언트는 네트워크의 노드에서 요청할 수 있다: (1) 광부 Mi에 대한 현재 할당 테이블항목, (2) 해당 항목이 마지막 블록의 상태 트리에 포함되었음을 증명하는 Merkle 경로, (3) 생성 블록에서 현재 블록까지의 헤더. 이러한 방법으로 라이트 클라이언트는 네트워크에 PROF-of-Spacetime의 검증을 위임할 수 있다.

전력 계산의 보안은 Proof-Spacetime의 보안에서 비롯된다. 이 설정에서 PoSt는 광부가 자신이 가지고 있는 할당된 스토리지 양에 대해 거짓말을 할 수 없음을 보장한다. 실제로, 그들은 그들이 저장하고 있는 데이터 이상을 저장한다고 주장할 수 없다. 왜냐하면 이것은 느린 PoSt를 가져오고 실행하는 데 시간을 들여야 하기 때문이다. PoSt 이후, 그들은 계산을 병렬화하여 증거를 더 빨리 생성할 수 없다. 증명은 순차적 계산이다.

6.2.3 Using Power to Achieve Consensus
우리는 스테이크가 할당 된 스토리지로 대체되는 기존 (및 미래의) Proof-of-Stake 컨센서스 프로토콜을 확장하여 Filecoin 컨센서스를 구현하기위한 여러 전략을 예상한다.
우리는 Proof-of-Stake 프로토콜의 개선을 예견하는 한편, Expected Consensus [14]라는 이전 작업을 기반으로 한 구성을 제안한다. 우리의 전략은 매 라운드마다 (또는 그 이상) 광부를 선출하여 선거에서 이길 확률이 각 광부에게 할당 된 저장 공간에 비례하도록하는 것이다.

Expected Consensus. 예상 컨센서스 EC의 기본 직관은 결정적으로, 예측 불가능하게, 그리고 각 시대마다 비밀리에 작은 리더들을 선출하는 것이다. 예상대로라면 시대당 선출된 지도자의 수는 1명이지만, 일부 시대에는 지도자가 0명 또는 다수일 수도 있다.
리더는 블록을 만들어 네트워크에 전파함으로써 체인을 확장한다. 각 시대마다 사슬은 하나 또는 여러 개의 블록으로 확장된다. 리더가 없는 시대의 경우 체인에 빈 블록이 추가된다. 체인의 블럭은 선형적으로 정렬할 수 있지만, 그것의 데이터 구조는 다이렉트 acyclick 그래프다. EC는 확률론적 합의로서, 각 시대는 이전 블록에 비해 더 많은 확실성을 도입하고, 결국 다른 역사의 가능성이충분히 작다는 충분한 확실성에 도달한다. 블록은 참가자 대다수가 체인을 확장하거나 블록에 서명하여 블록이 속한 체인에 가중치를 추가하면 커밋된다.

Electing Miners. 모든 시대마다, 각 광부들은 그들이 리더로 선출되었는지 여부를 점검한다. 이것은 이전의 프로토콜과 유사하게 수행된다. CoA[15], Snow White [16], 알고랜드[17]

7 Smart Contracts

파일코인은 최종 사용자에게 Get과 Put이라는 두 가지 기본적인 원리를 제공한다. 이러한 원시적 요소를 통해 고객은 데이터를 저장하고 선호하는 가격으로 시장에서 데이터를 검색할 수 있다. 원시 요소는 파일코인의 기본 사용 사례를 다루지만 스마트 계약 구축을 지원하여 Get and Put 위에 보다 복잡한 작업을 설계할 수 있도록 한다. 사용자는 일반적인 스마트 계약뿐만 아니라 파일 계약으로 분류되는 세분화된 새로운 스토리지/재개 요청을 프로그래밍할 수 있다. Contracts 시스템([18] 기반)과 Bridge 시스템을 통합하여 다른 블록체인의 파일코인 스토리지를 다른 블록체인에, 그 반대로 파일코인에 다른 블록체인의 기능을 도입한다.

우리는 파일코인 생태계에 수많은 스마트 컨트랙트가 존재할 것으로 예상하며 스마트 컨트랙트 개발자들의 커뮤니티를 기대한다.

7.1 Contracts in Filecoin

스마트 계약은 파일코인 사용자가 토큰을 사용할 수 있는 상태 저장 프로그램을 작성하고, 시장에서 데이터 저장/회수를 요청하며, 저장 증거를 검증할 수 있도록 해준다. 사용자는 계약서의 함수 호출을 촉발하는 대장에 트랜잭션을 전송함으로써 스마트 계약과 상호작용할 수 있다. 스마트 계약 시스템을 확장하여 파일코인 특정 운영(예: 시장 운영, 증명 확인)을 지원한다.

파일코인은 보다 일반적인 스마트 계약뿐만 아니라 데이터 스토리지 관련 계약을 지원한다:

File Contracts: 사용자가 스토리지 서비스를 제공하거나 제공하는 조건을 프로그래밍할 수 있도록 허용한다. 언급할 만한 몇 가지 예가 있다: (1) 광부 계약: 고객은 시장에 참여하지 않고 서비스를 제공하는 광부들을 미리 지정할 수 있다.
(2) 지불 전략: 고객은 광부를 위한 다양한 보상 전략을 설계할 수 있다. 예를 들어, 계약은 광부에게 시간을 통해 간접적으로 더 높은 금액을 지불할 수 있고, 다른 계약은 신뢰할 수 있는 "보증인"이 통보한 저장소의 가격을 설정할 수 있다. (3) 티켓팅 서비스: 계약은 광부가 토큰을 예치하고 사용자를 대신하여 저장/보관 비용을 지불할 수 있게 할 수 있다. (4) 더 복잡한 운영: 고객은 데이터 업데이트를 허용하는 계약을 만들 수 있다.

Smart Contracts: 사용자는 저장소의 사용에 직접 의존하지 않는 다른 시스템(Ethereum [18]과 같이)과 같은 자신의 거래에 프로그램을 연결할 수 있다. 우리는 분산형 명명 시스템, 자산 추적 및 크라우드세일 플랫폼과 같은 응용 프로그램을 예상한다.

7.2 Integration with other systems

교량은 서로 다른 블록체인을 연결하는 것을 목적으로 하는 도구다.
아직 작업이 진행 중인 동안 다른 블록체인 기반 플랫폼에 파일코인 스토리지를 도입하는 것은 물론 다른 플랫폼의 기능성을 파일코인으로 끌어들이기 위해 교차 체인 상호작용을 지원할 계획이다.
 ● Filecoin in other platforms: 비트코인[19], Zcash[20], 특히 이더리움[18], 테조스와 같은 다른 블록체인 시스템에서는 개발자들이 스마트 계약서를 작성할 수 있지만, 이러한 플랫폼은 스토리지 기능을 거의 제공하지 않고 매우 높은 비용으로 제공한다. 우리는 이들 플랫폼에 저장과 검색 지원을 가져올 수 있는 다리를 제공할 계획이다. IPFS는 이미 여러 스마트 계약(및 프로토콜 토큰)에서 콘텐츠를 참조하고 배포하는 방법으로 사용되고 있다는 점에 주목한다. 파일코인에 대한 지원을 추가하면 이들 시스템이 파일코인 토큰의 교환으로 IPFS 콘텐츠의 저장을 보장할 수 있게 된다.
 ● Other platforms in Filecoin: 다른 블록 체인 서비스를 Filecoin과 연결하기위한 브리지를 제공 할 계획이다. 예를 들어 Zcash와 통합하면 개인 정보에 데이터 저장 요청을 보낼 수 있다.

8 Future Work

이 작업은 파일코인 네트워크 구축을 향한 명확하고 응집력 있는 경로를 제시하지만, 향후 분산형 스토리지 시스템에 대한 연구의 시발점이 되기도 한다고 생각한다. 이 절에서는 미래 작업의 세 가지 범주를 식별하고 채운다. 여기에는 완료되어 설명과 출판만을 기다리고 있는 작업, 현재 프로토콜 개선을 위한 공개 질문, 프로토콜 공식화 등이 포함된다.

8.1 On-going Work

다음 주제는 진행 중인 작업을 나타낸다.
 ● 모든 블록의 파일코인 상태 트리 사양
 ● 파일코인과 그 구성요소에 대한 상세한 성능 추정치 및 벤치마크
 ● 완전한 구현이 가능한 파일코인 프로토콜 사양
 ● 클라이언트 C1이 피스당 베어러-스팬더블 토큰을 발행하여 다른 클라이언트 C2의 다운로드를 후원할 수 있는 후원 회수 티켓팅 모델.
 ● 파일코인 서브넷이 임시 또는 영구 파티션 중에 트랜잭션을 분할하고 계속 처리할 수 있는 계층적 컨센서스 프로토콜
 ● SNARK/STARK를 사용한 증분형 블록체인 스냅샷 생성
 ● 파일코인-이더리움 인터페이스 계약 및 프로토콜
 ● 브레이드(Braid)를 사용한 블록체인 아카이브 및 인터블록체인 스탬프
 ● 분쟁 해결을 위해 블록체인에 Proof-Spacetime만 게시
 ● 파일코인 DSN과 새로운 스토리지 증명서의 실현을 공식적으로 입증한다.

8.2 Open Questions

출시 전에 해결해야 할 문제가 하나도 없는데도 불구하고 답안이 네트워크 전체를 실질적으로 개선할 수 있는 잠재력을 가지고 있는 개방형 질문들이 많이 있다.
 ● PROF-of-Replication Seal 함수를 위한 더 나은 원시적 기능. 이상적으로는 디코딩(O(nm)에 O(n)가 아니며
SNARK/STAK가 필요하지 않고 공개적으로 검증할 수 있다.
 ● SNARK/STARK 없이 공개적으로 검증 가능하며 투명한 Proof-of-Replication Proof 기능을 위한 보다 원시적인 기능.
 ● 투명하고 공개적으로 검증 가능한 보증서 또는 기타 스토리지 증명.
 ● 회수 시장의 새로운 검색 전략(예: 확률적 지급, 지식 조건부 지급 제로)
 ● 한 시대 당 정확히 한 명의 선출된 지도자를 주는 기대 컨센서스를 위한 더 나은 비밀 지도자 선거.
 ● 공용 매개변수의 증분 확장을 가능하게 하는 SNARK에 대한 보다 신뢰할 수 있는 설정 계획(각 추가 MPC가 결함의 확률을 엄격히 낮추고 각 MPC의 출력을 시스템에 사용할 수 있는 일련의 MPC를 실행할 수 있는 일정).

8.3 Proofs and Formal Verification

증명과 정식 검증의 명확한 가치 때문에 향후 수개월, 수년에 걸쳐 파일코인 네트워크의 많은 속성을 증명하고 정식으로 검증된 프로토콜 사양을 개발할 계획이다. 몇 가지 증거가 진행 중이고 더 많은 것을 염두에 두고 있다. 그러나 파일코인의 많은 속성(스케일링, 오프라인 등)을 증명하는 것은 힘들고 장기적인 작업이 될 것이다.
 ● 예상 합의 및 변형에 대한 정확성 증명.
 ● Power Fault Tolerance 비동기 1/2 불가능 결과에 대한 정확성 증명.
 ● 범용 기능 프레임 워크에서 Filecoin DSN을 공식화하여 Get, Put 및 Manage를 이상적인 기능으로 설명하고 실현을 입증합니다.
 ● 자동 자가 치유 보장을 위한 공식 모델 및 증명.
 ● 프로토콜 설명 (예 : TLA + 또는 Verdi)을 공식적으로 확인
 ● implementation을 공식적으로 검증합니다 (예 : Verdi).
 ● Filecoin의 인센티브에 대한 게임 이론적 분석.

Acknowledgements

이 작업은 Protocol Labs 팀 내의 여러 개인의 누적된 노력이며, Protocol Labs의 협력자 및 조언자의 도움, 의견 및 검토가 없었다면 불가능했을 것이다. 후안 베넷은 2014년 파일코인 원본 백서를 작성해 이 작품의 토대를 마련했다. 그와 니콜라 그레코는 새로운 프로토콜을 개발했고, 유용한 기여, 논평, 검토, 대화를 제공한 나머지 팀원들과 협력하여 이 백서를 썼다. 특히 데이빗 "다비도드" 달리름플은 주문서 패러다임과 다른 아이디어를 제안했고, 매트 줌왈트는 논문의 구조를 개선했으며, 에반 미야조노가 삽화를 만들어 논문을 마무리했고, 제롬 존슨은 의전을 설계하면서 통찰력을 제공했고, 스티븐 앨런은 통찰력 있는 질문과 해설을 기고했다.
우리는 또한 우리의 모든 협력자들과 조언자들, 특히 앤드류 밀러와 일라이 벤-사손에게 감사한다.

Previous version: QmYcf7X6ygKisoVS7EApqY3gxcKW1MigF57zc1cdXjZWrQ

References
[1] Juan Benet. IPFS - Content Addressed, Versioned, P2P File System. 2014.
[2] Giuseppe Ateniese, Randal Burns, Reza Curtmola, Joseph Herring, Lea Kissner, Zachary Peterson, and
Dawn Song. Provable data possession at untrusted stores. In Proceedings of the 14th ACM conference
on Computer and communications security, pages 598–609. Acm, 2007.
[3] Ari Juels and Burton S Kaliski Jr. Pors: Proofs of retrievability for large files. In Proceedings of the
14th ACM conference on Computer and communications security, pages 584–597. Acm, 2007.
[4] Hovav Shacham and Brent Waters. Compact proofs of retrievability. In International Conference on
the Theory and Application of Cryptology and Information Security, pages 90–107. Springer, 2008.
[5] Protocol Labs. Technical Report: Proof-of-Replication. 2017.
[6] Rosario Gennaro, Craig Gentry, Bryan Parno, and Mariana Raykova. Quadratic span programs and
succinct nizks without pcps. In Annual International Conference on the Theory and Applications of
Cryptographic Techniques, pages 626–645. Springer, 2013.
[7] Nir Bitansky, Alessandro Chiesa, and Yuval Ishai. Succinct non-interactive arguments via linear interactive proofs.
Springer, 2013.
[8] Eli Ben-Sasson, Alessandro Chiesa, Daniel Genkin, Eran Tromer, and Madars Virza. Snarks for c:
Verifying program executions succinctly and in zero knowledge. In Advances in Cryptology–CRYPTO
2013, pages 90–108. Springer, 2013.
[9] Eli Ben-Sasson, Iddo Bentov, Alessandro Chiesa, Ariel Gabizon, Daniel Genkin, Matan Hamilis,
Evgenya Pergament, Michael Riabzev, Mark Silberstein, Eran Tromer, et al. Computational integrity
with a public random string from quasi-linear pcps. In Annual International Conference on the Theory
and Applications of Cryptographic Techniques, pages 551–579. Springer, 2017.
[10] Henning Pagnia and Felix C G¨artner. On the impossibility of fair exchange without a trusted third party.
Technical report, Technical Report TUD-BS-1999-02, Darmstadt University of Technology, Department
of Computer Science, Darmstadt, Germany, 1999.
[11] Joseph Poon and Thaddeus Dryja. The bitcoin lightning network: Scalable off-chain instant payments.
2015.
[12] Andrew Miller, Iddo Bentov, Ranjit Kumaresan, and Patrick McCorry. Sprites: Payment channels that
go faster than lightning. arXiv preprint arXiv:1702.05812, 2017.
[13] Protocol Labs. Technical Report: Power Fault Tolerance. 2017.
[14] Protocol Labs. Technical Report: Expected Consensus. 2017.
[15] Iddo Bentov, Charles Lee, Alex Mizrahi, and Meni Rosenfeld. Proof of activity: Extending bitcoin’s
proof of work via proof of stake [extended abstract] y. ACM SIGMETRICS Performance Evaluation
Review, 42(3):34–37, 2014.
[16] Iddo Bentov, Rafael Pass, and Elaine Shi. Snow white: Provably secure proofs of stake. 2016.
[17] Silvio Micali. Algorand: The efficient and democratic ledger. arXiv preprint arXiv:1607.01341, 2016.
[18] Vitalik Buterin. Ethereum <https://ethereum.org/>, April 2014. URL https://ethereum.org/.
[19] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2008.
[20] Eli Ben Sasson, Alessandro Chiesa, Christina Garman, Matthew Green, Ian Miers, Eran Tromer, and
Madars Virza. Zerocash: Decentralized anonymous payments from bitcoin. In Security and Privacy
(SP), 2014 IEEE Symposium on, pages 459–474. IEEE, 2014.

더욱 다양한 정보 및 방송 관련 소식은

공식 SNS 채널을 통해 확인 가능합니다.