[IPFS vs Swarm] 블록체인 스토리지 분석 (2) - Sia 코인

[IPFS vs Swarm]  블록체인 스토리지 분석 (2) - Sia 코인

[IPFS vs Swarm]  블록체인 스토리지 분석 (2) - Sia 코인

* 지난편 모음

1.  [IPFS vs Swarm] 블록체인 스토리지 분석 (1) - IPFS vs Swarm 



1. Sia Coin

Siacoin (SC)
16.95 KRW (7.34%)
0.00000208 BTC
RANK

35
MARKET CAP

$591.52 B
VOLUME (24H)

$14.49 B

홈페이지 : https://sia.tech/

About Sia

Sia(시아) 는 클라우드 스토리지를 재창조해냈습니다. 시아의 기술은 파일 스토리지가 필요한 사용자에게 기존에 충분히 활용하지 못하는 하드 드라이브(HDD) 용량을 제공합니다. 블록체인 기술을 통해 데이터를 보호하고 사용자와 호스트를 위해 경제성을 향상 시킵니다.


Files Are Divided Prior To Upload (업로드 전 파일을 분할)


Sia 소프트웨어는 파일을 업로드하기 전에 30개의 세그먼트로 나눕니다. 각 세그먼트는 전 세계의 스토리지 제공자에게 배포됩니다. 이 배포를 통해 어느 제공자도 단일 장애지점을 나타내지 않고, 전체적인 네트워크 가동 시간과 중복성을 강화할 수 있습니다. 파일 세그먼트는 CD 및 DVD에서 일반적으로 사용되는 리드-솔로몬 삭제 코딩(Reed-Solomon erasure coding)이라는 기술을 사용합니다. 삭제 코딩을 통해 Sia는 중복된 방식으로 파일을 나눌 수 있습니다. 30개의 세그먼트 중 10개는 클라이언트의 파일을 완전히 복구할 수 있습니다. 즉, 30명의 스토리지 제공자 중에서 20명이 오프라인 상태가 되어도 Sia는 안전하게 파일을 다운로드 및 제공할 수 있게 합니다.

* Reed-Solomon erasure coding overview - Youtube


리드-솔로몬 삭제 코딩에 대한 설명은 영상으로 보시면 조금 더 쉽게 이해하실 수 있습니다. 


Each File Segment Is Encrypted(각 파일의 세그먼트들은 암호화됨)


클라이언트의 컴퓨터 및 저장소에서 제공하는 각 파일의 세그먼트들은 스토리지 제공자에게 제공되기전에 암호화 됩니다. 이렇게 하면 스토리지 제공자들은 암호화된 클라이언트의 데이터 세그먼트들 만 제공하게 됩니다. 기본적으로 사용자의 데이터를 암호화하지 않는 Amazon과 같은 기존의 클라우드 스토리지 공급자와 다릅니다. Sia는 스토리지 제공자가 암호화된 파일 세그먼트 만 저장하기 때문에 기존 파일보다 안전하게 저장합니다. Sia 는 AES(Advanced Encryption Standard) 경연대회에서 최종 후보였던 오픈 소스 및 보안 암호화 표준인 Twofish 알고리즘을 사용합니다.


File Are Sent To Hosts Using Smart Contract (스마트 컨트렉트로 스토리지 제공자에게 파일이 보내진다.)


Sia 블록체인을 이용해 클라이언트는 스토리지 제공자(호스트)와 파일 계약을 체결합니다. 이 계약은 가격 결정, 가동 시간 약속 및 클라이언트와 제공자 간의 관계의 다른 측면을 설정합니다. 파일 계약은 스마트 계약의 한 유형입니다. 이를 통해 Sia 블록체인에 저장된 SLA(암호화 서비스 수준의 계약)를 만들 수 있습니다. 파일 계약은 네트워크에 의해 자동으로 시행되기 때문에 Sia는 중개인이나 신뢰할 수 있는 제3자가 필요없습니다.


Renters And Hosts Pay With Sia coin (지불 시스템은 시아코인)


클라이언트와 스토리지 제공자 모두 Sia 코인을 사용합니다. Sia 코인은 Sia Blockchain 에 구축된 독창적인 암호화폐입니다. 클라이언트는 스토리지 제공자로부터 용량을 임대하기 위해 Sia 코인을 사용하고 제공자는 각 파일 계약에 Sia 코인을 담보로 입금합니다. 비트코인의 라이트닝 네트워크와 유사한 지불 채널이라는 기술을 사용하여 클라이어늩와 제공자 사이에 소액 결제가 이루어집니다. 즉, 오프체인(Off-chain)으로 지불이 이루어 지므로 네트워크 효율성과 확장성을 향상시킵니다.

* 라이트닝 네트워크 & 오프체인 

1. 오프체인에서 트랜젝션 이해 : https://medium.com/@liquidity.network/understanding-off-chain-transactions-in-blockchain-for-fun-and-profit-591e7e27ccc0

2. 비트코인 라이트닝 네트워크 Summery : https://lightning.network/lightning-network-summary.pdf


Contract Renew Over Time (계약 갱신)

클라이언트는 파일 계약 내 저장을 위해 선불로 지불하고, 고정 된 금액의 Sia 코인을 데이터 저장 및 전송에 사용합니다. 파일 계약은 일반적으로 90일 동안 지속됩니다. Sia는 특정 만료 기간에 있을 때 자동으로 계약을 갱신합니다. 계약 갱신이 되지 않으면 Sia 는 계약 기간이 끝났을 때 사용하지 않은 코인을 클라이언트에게 반환합니다. 개별 제공자가 오프라인 상태인 경우, Sia는 파일 복구 프로세스를 통해 자동으로 클라이언트의 데이터를 새로운 스토리지 제공자에게 이동시킵니다.


Hosts Submit Storage Proofs (스토리지 제공자는 저장소 증명을 제출해야함.)


파일 계약이 끝나면 스토리지 제공자는 클라이언트의 데이터를 저장하고 있었음 을 증명해야합니다. 이를 저장 증명이라 부릅니다. 저장 증명에 필요한 증거가 특정 기간 내에 블록체인에 표시되면 제공자에게 비용이 지급됩니다. 그렇지 않을 경우 제공자에게 벌칙(페널티)이 부과됩니다. 저장 증거는 머클 트리라는 기술로 가능합니다. 머클 트리는 작은 데이터 세그먼트가 큰 파일의 일부임을 증명할 수 있습니다. 이러한 증거의 장점은 파일 크기에 관계없이 해당 증거의 파일 크기가 매우 작다는 것 입니다. 증명은 블록체인에 영구적으로 저장됩니다.


1.1 Introduce

Sia(시아)는 기존의 스토리지 솔루션과 P2P 및 엔터프라이즈 수준에서 경쟁하려는 분산 형 클라우드 스토리지 플랫폼 입니다. 중앙화된 기존 공급 업체로부터 스토리지를 임대하는 대신, Sia는 P2P 네트워크를 통해 스토리지를 임대해줍니다. Sia는 당사자간에 형성된 스토리지 계약을 저장하여 계약조건을 이행합니다. 스마트 계약을 통해 스토리지 제공자는 클라이언트의 데이터를 저장하는데 동의하게 되고 계약 만료기간까지 계속 저장할 것을 동의하게 됩니다. 저장에 대한 보상을 받을 수 있으며 불이행에 대한 처벌을 받을 수 있습니다. 이러한 계약 증명은 네트워크 합의를 통해서 공개적으로 확인할 수 있고 스토리지 계약을 자동으로 연장할 수 있습니다. 중요한 부분은 클라이언트가 일일히 스토리지 제공자가 저장을 했는지에 대한 확인을 할 필요가 없다는 것 입니다. 단순히 파일을 업로드하고, 네트워크가 나머지를 하도록 할 수 있게 합니다. 

신뢰할 수 없는 단일 제공자에게 데이터를 저장 할 경우, 가용성, 대역폭 또는 일반적인 서비스 품질이 거의 보장되지 않을 수 있습니다. 따라서 여러 제공자에게 데이터를 중복 저장하는 것이 좋습니다. 특히나 과도한 중복없이 고 가용성을 구현하기 위해 중복제거 코드를 사용하면 됩니다. 

1.2 General Structure

Sia는 모든 트랜젝션에 대해  M-N 다중 서명 체계를 사용하는 대신에, 스크립팅 시스템 전체를 피합니다. 이로 인해 복잡성과 공격 표면이 줄어듭니다. 또한 Sia는 스토리지 계약을 수립하고 이행할 수 있도록 트랜젝션을 확장합니다. 이를 달성하기 위해 계약, 증명 및 계약 갱신과 같은 세가지가 필요하게 됩니다. 계약은 특정 크기와 해시를 가진 파일을 저장할 제공자의 의도를 선언합니다. 제공자가 저장 증명을 제출해야하는 규칙을 정의합니다. 계약 갱신 시 새롭게 계약을 수정할 수 있습니다. 자세한 구조는 다음과 같습니다.

1.2.1 Transactions

트랜젝션에는 다음과 같은 정보가 포함됩니다.

FieldDescription
VersionProtocol version number
Arbitrary DataUsed for metadata or otherwise
Miner FeeReward given to miner
InputsIncoming funds
OutputsOutgoing funds (optional)
File ContractFile Contract (optional)
Storage ProofProof of Storage (optional)
SignaturesSignatures from each input

Inputs and Outputs

Output 은 coin의 볼륨(volume)을 포함합니다. 각 output 에는 output이 나타난 트랜젝션에서 파생된 식별자가 있습니다. 모든 Input 은 이전 Output에서 가져와야하므로 입력은 단순히 Output ID가 됩니다. Input & Output 은 지출 조건 세트와 쌍을 이룹니다. Input 에는 지출 조건이 포함되며 출력에는 머클 루트 해시가 포합됩니다.

Spend Condition

앞서 언급된 지출 조건(Spend Condition)은 Coin이 "잠금 해제"되기 전에 충족되어야하는 지출액입니다. 지출 조건에는 시간 잠금 및 공개 키 세트 및 필요한 서명 수가 포함됩니다. 시간 잠금이 만료되고 지정된 키 중 충분한 수가 서명을 추가할 때까지 Output을 보낼 수 없습니다. 지출 조건은 시간 잠금, 필요한 서명 수 공개키를 사용하여 머클 트리로 해시됩니다. 이 트리의 루트 해시는 코인이 보내지는 주소로 사용됩니다. 코인을 소비하려면 주소 해시에 해당하는 지출 조건을 제공해야합니다. 머클 트리를 사용하면 당사자가 지출 조건에서 정보를 선택적으로 공개할 수 있습니다. 예를 들어 공개 키의 수나 필요한 서명 수를 밝히지 않고 시간 잠금을 나타낼 수 있습니다. 

시간 잠금과 서명 수는 엔트로피가 낮으므로 해시가 무차별 대입에 취약해집니다. 이것은 이러한 필드에 임의의 넌스(nonce)를 추가하여 엔트로피를 증가시킴으로써 해결할 수 있습니다.

Signatures

트랜젝션의 각 Input은 서명되어야합니다. 암호화 서명 자체는 Input ID, 시간 잠금 및 트랜젝션의 어느 부분이 서명되었는지를 나타내는 플래그 세트와 쌍을 이룹니다. Input ID는 서명이 적용되는 Input을 나타냅니다. 시간 잠금은 서명이 유효한 시기를 지정합니다. 서명 자체는 예외로 트랜젝션의 모든 하위 집합에 서명할수 있습니다.(백서상에서는 불가능 할 수 있다고 함.) 또한 서명을 제외하고 전체 거래가 서명되어야함을 나타내는 플래그가 있습니다. 이를 통해보다 미묘한(nuance) 거래방식을 사용할 수 있습니다.


1.3 File Contract

파일 계약은 스토리지 공금자와 해당 클라이언트 간의 계약입니다. 파일 계약의 핵심은 파일의 머클 루트 해시 입니다. 이 해시를 생성하기 위해 파일은 일정한 크기의 세그먼트로 분할되고 머클 트리로 해시화 됩니다. 루트 해시는 파일의 전체 크기와 함께 저장소 증명을 검증하는데 사용될 수 있습니다. 

파일 계약은 유효한 증거에 대한 보상, 유효하지 않은 증거 또는 누락 된 증거에 대한 보상, 누락 된 증거의 최대 수를 포함하여 기간, 요청 빈도 및 지불 매개 변수를 지정합니다. 챌린지 빈도는 저장 증거를 제출해야하는 빈도를 지정하고 스토리지 제공자가 저장 증명(one proof per window == 윈도우 당 증명)을 제출해야하는 개별 챌린지 윈도우를 만듭니다. 챌린지 윈도우에서 유효한 증명을 제출하면 "유효한 증명" 주소(스토리지 제공자)로 자동 지불됩니다. 챌린지 윈도우가 끝날 때 유효한 증거가 제출되지 않은 경우, 코인은 대신 "놓친 증명" 주소로 보내집니다 (DDos 공격을 방지하기 위해 보류 할 수 없는 주소 일 가능성이 있음). 계약서에는 누락 될 수있는 교정본의 최대 수를 정의합니다. 이 수가 초과되면 계약이 무효화됩니다.

계약 기간이 만료된 후에도 계약이 유효하면 성공적으로 해지되고 나머지 코인은 유효한 증명 주소로 보내지게 됩니다. 반대로 계약 기간이 끝나기 전에 계약금이 모두 소진되거나 누락된 증서의 최대 수가 초과되면 계약이 성공적으로 종료되고 나머지 동전은 누락된 증명 주소로 보내지게 됩니다.

계약 결과로는 계약의 종료 상태에 해당하는 잠재적 가치인 "성공 종료"와 "실패한 종료"가 있습니다. 피일 계약은 트랜젝션의 지출 조건과 유사한 "편집 조건" 목록 으로도 생성합니다. 편집 조건이 충족되면 계약이 수정 될 수 있습니다. 계약 금액, 파일 해시 및 출력 주소를 포함하여 모든 값을 수정할 수 있습니다. 이러한 수정은 후속 저장 증명의 유효성에 영향을 미칠 수 있으므로 효과적으로 계약 편집은 미래 윈도우를 지정해야합니다. (새로운 윈도우에서 계약 편집이 이뤄진다는 뜻 같습니다.) 이론적으로 스토리 제공자들은 "마이크로 편집 채널"을 생성하여 잦은 계약 편집을 할 수 있습니다.


1.4 Proof of Storage

스토리지 증명 트랜젝션은 파일 계약을 이행하기 위해 주기적으로 제출됩니다. 각 저장 영역 증명은 특정 파일 계약을 대상으로합니다. 저장 증명에는 Input 또는 Output이 필요하지 않습니다. 오직 계약 ID 및 증명 자료 만 필요합니다.

1.4.1 Algorithm

제공자는 원본 파일의 세그먼트와 파일의 Merkle 트리에서 해시 목록을 제공하여 저장소를 증명합니다. 이 정보는 세그먼트가 원래 파일에서 왔음을 증명하기에 충분합니다. 교정본이 블록 체인에 제출되므로 누구나 유효성 또는 무효성을 확인할 수 있습니다. 각 저장 증명은 무작위로 선택된 세그먼트를 사용합니다. 제공자가 무작위 세그먼트를 지속적으로 소유 할 수 있다면 전체 파일을 저장할 가능성이 높습니다. 파일의 50% 만 저장하는 스토리지 제공자는 약 50%의 증명을 완료할 수 없습니다. 

1.4.2 Block Withholding Attacks

난수 생성기(random number generator)는 블록 체인의 원천 보류 공격(block withholding attack)을 통해 조작되며, 공격자는 유리한 난수를 생성 할 블록을 찾을 때까지 블록을 보류합니다. 그러나 공격자는 특정 칠랜지에 대해 임의의 숫자를 조작 할 기회가 하나 뿐입니다. 또한 난수를 조작하기 위해 블록을 보류하면 공격자는 블록 보상에 대한 비용을 내야합니다. 공격자가 블록의 50%를 채굴할 수 있다면 전체 블록을 조작할 수 있습니다. 그럼에도 나머지 50% 는 여전히 무작위이므로 공격자는 일부 저장 증거를 만들어 낼 수 없게 됩니다.

특히 공격자는 원천 보류 공격 없이는 전체 공격의 50% 이상 실패 할 것 입니다. 이러한 공격으로부터 보호하기 위해 고객은 높은 시험 빈도와 누락된 교정본에 대한 큰 처벌을 지정할 수 있습니다. 이러한 주의사항은 재정적으로 동기 부여된 공격자가 네트워크의 해시파워를 50% 미만을 제어하는 것을 제어하는 것을 막기에 충분해야합니다. 그럼에도 고객은 경제적인 동기가 아닐 수 있는 잠재적 비잔틴 공격을 방어해야할 것 입니다.

- 백서 상 내용이 어렵게 적혀있습니다. 조금 쉽게 풀어서 설명하면, 스토리지 제공자 이면서 공격자 A가 난수 조작을 통한 증거를 제출하려할 때 전체 해시 50%를 넘는 가져야합니다. 그리고 공격하기 위한 난수를 생성할 블록을 찾을 때 까지 블록을 보류해야하는데, 이때 비용이 계속 청구된다는 뜻 입니다. 또한 저장 증거를 조작하려할 때 전체 100%에 대한 블록을 조작해야하는데 그것이 사실상 불가능 하다로 해석할 수 있습니다.  따라서 원천 보류 공격이 없이는 무조건 반 이상 공격이 실패한다는 뜻 입니다. 따라서 조작을 통해 얻는 비용대비 소비되는 비용이 더 크기 때문에 조작이 힘들다는 뜻 으로 해석이 가능합니다.

1.4.3 Closed Window Attacks

스토리지 제공자는 증명 트랜젝션이 블록체인에 저장하는 경우에만 저장 증거를 제출할 수 있습니다. 이때 마이너(miner)들은 제출된 저장 증거를 악의적으로 블록에서 제외할 수 있으며 거래 수수료는 없지만 제공자에게 벌금을 부과할 수 있습니다. 대안으로 마이너들은 스토리지 증명을 포함하기 위해 많은 비용을 요구함으로써 제공자를 강탈 할 수 있으며 평균 트랜젝션보다 중요하다고 알릴 수 있습니다. 악의적인 마이너가 인위적으로 윈도우(Window)를 닫았기 때문에 폐쇄적 윈도우 공격(Closed Window Attack)이라고 부릅니다. 이에 대한 방어는 큰 윈도우 사이즈(Window Size)를 사용하는 것 입니다. 제공자는 마이너의 일부가 트랜젝션 수수료 대신 자신의 증거를 포함할 것이라고 합리적으로 추측할 수 있습니다. 즉, 제공자가 모든 파일 계약에 동의하기 때문에 폐쇄적 윈도우 공격에 취약한 계약을 거부할 수 있습니다. 


1.5 Arbitrary Transaction Data

각 거래에는 임의의 유형의 정보에 사용할 수 있는 임의의 데이터 필드가 있습니다. 노드는 임의의 데이터가 트랜젝션의 서명으로부터 서명된 경우 이를 저장해야합니다. 노드는 처음에 블록 당 최대 64KB의 임의의 데이터를 받아옵니다.  이 임의의 데이터는 스토리지 제공자와 클라이언트에게 자체를 구성하는 분산된 방법을 제공합니다. 사용 가능한 공간이나 제공자를 찾는 파일을 광고하거나 분산 파일 추적기를 만드는데 사용할 수 있습니다. 다른 유형의 소프트 포크를 구현하기 위해 임의의 데이터를 사용할 수 도 있습니다. 이것은 임의의 데이터에 지정된 제한 사항을 사용하여 "누구나 사용가능한" 출력을 작성함으로써 수행됩니다. 제한 사항에 대한 이해가 있는 마이너는 필요한 규정을 충족시키지 않고 산출물을 소비하는 모든 거래를 찬단할 수 있습니다. 순수한 노드는 임의의 데이터를 분석 할 필요없이 동기화 상태를 유지합니다. (의역하자면, 앞서 언급한 광고나 분산 파일 추적기를 하지 않는 노드는 동기화 상태를 유지)


1.6 Storage Ecosystem

Sia 는 분산 스토리지를 지원하는 생태계를 구성합니다. 스토리지 제공자는 임의의 데이터 필드를 사용하여 네트워크에 자신을 알리 수 있습니다. (1.5 임의의 데이터를 이용한 광고) 이는 클라이언트가 읽을 수 있는 표준화된 템플릿을 사용하여 수행할 수 있습니다. 클라이언트는 이러한 템플릿(알림)을 통해 내부적으로 스토리지 제공자의 데이터베이스(리스트업)를 작성하고 신뢰할 수 있는 제공자와 계약을 맺을 수 있습니다. 

1.6.1 Host Protection

계약을 맺기 위해서는 스토리지 제공자(Host)와 클라이언트 모두 동의가 있어야하며, 이로 인한 제공자는 불리한 조건이나 원하지 않는(불법적인)파일을 거부할 수 있습니다. 제공자는 전체 파일이 업로드될 때 까지 계약서 서명을 거부할 수 있고, 계약 조건은 스토리지 제공자에게 유연성을 제공합니다. 스토리지 제공자들은 최소한의 신뢰성으로 광고 할 수있으며 저렴한 가격을 제공하고 파일 손실에 대한 최소한의 처벌(패널티)에 동의합니다. 또한 그들은 높은 신뢰성을 제공하고 높은 가격을 제시하며 파일을 잃어 버리는 것에 대한 더 엄격한 처벌에 동의할 수 있습니다. (높은 가격 제시, 파일 손실 시 높은 패널티 부과) 이러한 시장은 스토리지 시장의 가격 형성에 최적화될 것 입니다. 제공자는 서비스 거부 공격에 취약하여 저장소 증명을 제출하거나 파일을 전송하지 못하게 할 수 있습니다. 이렇나 공격으로부터 자신을 보호하는 것은 제공자 스스로의 책임입니다.

1.6.2 Client Protection

클라이언트는 코드를 다시 생성하는 등의 삭제 코드(리드-솔로몬 삭제 코드)를 사용하여 오프라인 상태 인 스토리지 제공자로부터 보호될 수 있습니다. 이러한 코드는 일반적으로 파일을 n 개의 조각으로 분할하여 작동하므로 파일을 m 개의 고유 조각으로 이루어진 하위 집합에서 복구 할 수 있습니다.(n과 m의 값은 특정 삭제 코드와 중복 인자에 따라 다릅니다.) 각 조각은 암호화되어 많은 제공자에 저장됩니다. 따라서 평균 네트워크 안정성이 낮더라도 클라이언트가 높은 파일 가용성을 얻을 수 있습니다. 극단적인 예로, 파일을 복구하는 데 100 조각 중 10 조각 만 필요한 경우 클라이언트는 실제 평균 신뢰성이 아닌 가장 신뢰할 수있는 10명의 제공자에게 의존합니다. 스토리지 제공자가 오프라인이 된 파일 조각을 다시 불러들여 가용성을 향상시킬 수 있습니다. 다른 메트릭스도 이 전략의 이점을 얻습니다. 클라이언트는 10 개의 가장 가까운 제공자에게서 다운로드하거나 10 개의 가장 빠른 제공자에게서 다운로드하여 다운로드 속도를 높여 대기 시간을 줄일 수 있습니다. 이러한 다운로드를 병렬로 실행하여 사용 가능한 대역폭을 최대화 할 수 있습니다.

1.6.3 Uptime incentives

저장소 증명에는 지속적인 가동 시간을 적용 할 수있는 메커니즘은 없습니다. 스토리지 제공자가 요청 시 클라이언트에 파일을 전송하도록 요구하는 조항도 없습니다. 클라이언트의 파일을 인질로 잡은 제공자들은 해당 파일을 다운로드에 필요한 엄청난 수수료를 요구할 것으로 예상됩니다. 그러나 이러한 공격은 리드-솔로몬 삭제 코드를 사용하여 완화됩니다. 이 전략을 통해 고객은 비협조적인 스토리지 제공자를 무시하고 협력적인 조직에서만 작업 할 수 있습니다. 결과적으로 제공자가 힘을 가지는 것이 아닌, 클라이언트가 힘을 가지게 됩니다. 그리고 다운로드 수수료는 "인센티브 업로드"가 될 것 입니다.

이러한 시나리오에서 클라이언트는 파일 전송에 대한 보상을 제공하며 제공자는 최상의 서비스 품질을 제공하기 위해 경쟁해야합니다. 클라이언트는 언제든지 파일을 요청할 수 있으므로 가능한 한 많은 보상을 얻기 위해 제공자가 가동 시간을 최대화하도록 유도합니다. 또한 클라이언트는 상대적으로 큰 보상을 통해 처리량을 늘리고 지연 시간을 줄일 수 있습니다. 클라이언트는 심지어 무언가를 다운로드하고 싶지 않더라도 호스트가 온라인 상태임을 확인하는 무작위 "점검"을 수행 할 수도 있습니다. 그러나 우리는 가동 시간에 대한 인센티브가 Sia protocol의 일부가 아니라는 것을 알립니다. 그들은 전적으로 고객의 행동에 의존합니다.

다운로드에 대한 지불은 기존의 소액 결제 채널을 통해 제공 될 것으로 예상됩니다. Micropayment 채널을 사용하면 고객은 최소한의 대기 시간과 블록 체인 (blockchain bloat)으로 연속적으로 지불될 수 많은 소액 지불을 할 수 있습니다. 제공자는 파일의 작은 부분을 전송하고, 진행하기 전에 소액 결제를 기다릴 수 있습니다. 연속으로 지급을 많이 사용하면 각 당사자는 속임수를 당할 위험을 최소화 할 수 있습니다. 소액 지불은 처리량에 큰 영향을주지 않고 몇 초마다 지불 할 수있을 정도로 충분히 작고 빠릅니다.

1.6.4 Basic Reputation System

클라이언트는 양질의 제공자를 선택하기 위한 신뢰할 수있는 방법이 필요합니다. 지나간 과거는 조작될 수 있기 때문에 제공자의 히스토리를 분석하는 것은 불충분합니다. 제공자는 자신과 계약을 반복적으로 형성하여 0 만 포함하는 파일과 같은 큰 "가짜"파일을 저장하는 것에 동의 할 수 있습니다. 실제로 아무 것도 저장하지 않고 그러한 데이터에 대한 저장 증명을 수행하는 것은 사소한 일입니다. (임의의 더미 데이터 파일을 업로드함으로써 과거내역을 조작할 수 있습니다.)

이러한 Sybil 공격을 완화하기 위해 클라이언트는 임의의 데이터 섹션에서 제공자에게 큰 시간 볼륨에 대한 잠금 된 코인을 포함하도록 요구할 수 있습니다. 10 개의 코인이 14 일 동안 잠겨 있다면, 스토리지 제공자는 140 코인이 생성될 동안에 "가치가 있는 자물쇠를 만들었다" 고 말할 수 있습니다. 가치가 높은 잠금 장치를 만든 호스트를 선호함으로써 귀중한 잠금 장치가 작성하기가 쉽지 않으므로 클라이언트는 Sybil 공격의 위험을 줄일 수 있습니다.(즉, 스토리지 제공자는 신뢰를 얻기위해 보증금 형식으로 잠금장치에 대한 비용을 지불함으로써 신뢰를 보여줄 수 있습니다. 비슷한 사례인 스팀잇의 스팀파워와 유사한 것으로 생각하시면 됩니다.)

각 클라이언트는 스토리지 제공자를 선택하기 위해 자체적으로 방정식을 선택할 수 있으며, 가격, 잠금 값(자물쇠 제작비), 제공되는 스토리지의 양 및 호스트가 파일을 잃어 버렸을 겨우 지불할 패널티 등을 포함하여 많은 요소를 사용할 수 있습니다. 사람의 리뷰(후기) 또는 기타 메트릭을 사용하는 시스템과 같은, 보다 복잡한 시스템은 보다 중앙 집중식 환경에서 구현 될 수 있습니다.


Leave a Comment

    0 Comments