[논문 조사] 스토리지(STORJ) 블록체인

# 출처 https://coinforu.io/coin/board/read/8371/

1. Storj

 

홈페이지 : https://storj.io/

 

About Storj

현재 클라우드형 스토리지는 데이터를 전송하고 저장하기 위해 신뢰할 수있는 제 3 자 역할을하는 대용량 스토리지 공급자에게 거의 독점적으로 의존하게되었습니다.(아마존, 구글, MS) 이러한 시스템은 신뢰 기반 모델의 고유 한 약점으로 인해 어려움을 겪습니다. 클라이언트 측 암호화는 비표준이므로 전통적인 클라우드는 사기업 및 기업 데이터를 노출하는 중간자(man-in-the-middle) 공격, 악성 프로그램 및 응용 프로그램 결함을 비롯한 다양한 보안 위협에 취약합니다. 또한 많은 저장 장치가 동일한 인프라를 사용하기 때문에 파일과 시스템에서 장애가 서로 관련됩니다.

분산 형 클라우드 스토리지 네트워크는 데이터 센터 기반 클라우드 스토리지에 비해 많은 이점을 제공합니다. 클라이언트 측 암호화를 사용하여 데이터 보안을 유지 관리 할 수 있으며 데이터 무결성은 검색 가능성 증명을 통해 유지 관리됩니다. 인프라 장애 및 보안 침해의 영향은 크게 줄어 듭니다. 데이터 스토리지의 공개 시장은 더 많은 당사자가 기존 장치를 사용하여 경쟁 할 수있게함으로써 다양한 스토리지 서비스 비용을 절감 할 수 있습니다.

네트워크의 데이터는 검열, 변조, 무단 액세스 및 데이터 오류에 강합니다. 이 백서에서는 이러한 네트워크의 구체적인 구현과 해당 네트워크와 상호 작용할 수있는 도구 집합에 대해 설명합니다.

 

1.1 Encrypt Files 

Storj는 피어 간의 저장소 계약을 구성하고 실행하기 위한 분산 네트워크를 만드는 프로토콜입니다. Storj 프로토콜을 사용하면 네트워크의 피어가 계약을 협상하고 데이터를 전송하며 원격 데이터의 무결성과 가용성을 확인하고 데이터를 검색하고 다른 노드에 비용을 지불 할 수 있습니다. 각 피어는 자율적 인 에이전트로서 사람과의 중요한 상호 작용없이 이러한 작업을 수행 할 수 있습니다. 이러한 상호 작용을위한 많은 기본 도구가 백서에 설명되어 있습니다.

 

1.1.1 Files as Encrypted Shard

샤드(Shard)는 네트워크에 저장 될 암호화 된 파일의 일부입니다. Sharding은 보안, 개인 정보 보호, 성능 및 가용성에 여러 가지 이점이 있습니다.

파일은 암호화되기 전에 클라이언트 쪽에서 암호화되어야 합니다. 레퍼런스 구현은 AES256-CTR을 사용하지만, 수렴형 암호화(convergent encryption) 또는 다른 바람직한 시스템을 구현할 수 있습니다. 이렇게 하면 데이터를 저장하는 저장소 공급자 또는 마이너(Miner)에게서 데이터의 내용을 보호 할 수 있습니다. 데이터 소유자는 암호화 키에 대한 완전한 제어를 유지하므로 데이터에 대한 액세스가 계속됩니다.

* CTR Mode

 

 

 

* Convergent Encryption

 

 

데이터 소유자는 파일이 파괴되는 방식 및 네트워크에서 파일 파편이 위치한 위치에 대한 보안 지식을 별도로 확보 할 수 있습니다. 네트워크의 조각이 커질수록, 주어진 샤드 세트의 위치를 사전에 알지 못하면 기하 급수적으로 샤드 세트를 찾기가 더욱 어려워집니다. 이것은 파일의 보안이 네트워크 크기의 제곱에 비례 함을 의미합니다. 샤드 크기(Size)는 협상 가능한 계약 매개 변수입니다. 프라이버시를 유지하려면 샤드 크기를 8MB 또는 32MB 와 같이 바이트 배수로 표준화하는 것이 좋습니다. 더 작은 파일은 0 또는 임의의 데이터로 채워질 수 있습니다. 표준화 된 크기는 주어진 샤드의 내용을 결정하기 위한 사이드 채널 시도를 단념 시키며, 네트워크를 통한 샤드의 흐름을 가릴 수 있습니다. 

비디오 컨텐츠와 같은 대용량 파일을 조각내고, 노드를 통해 샤드를 배포하면 특정 노드에서 컨텐츠 전달의 영향(트래픽)을 줄일 수 있습니다. 대역폭 요구는 네트워크 전체에 보다 균등하게 분산됩니다. 또한 최종 사용자는 BitTorrent 또는 다른 피어 투 피어 네트워크와 유사한 병렬 전송을 이용할 수 있습니다. 피어는 일반적으로 별도의 하드웨어 및 인프라에 의존하기 때문에 데이터 오류는 상관 관계가 없습니다. 이는 파편의 중복 미러를 만들거나 파편 집합 전체에 패리티 구성표를 적용하는 것이 가용성을 확보하는 데 매우 효과적인 방법이라는 것을 의미합니다. 가용성은 데이터를 저장하는 노드의 수에 비례합니다.

 

샤딩 프로세스(Sharding Process)

1. 파일이 암호화됩니다. 2. 암호화된 파일을 샤드(파편)로 조각내거나, 여러개의 파일이 결합된 조각을 만듭니다. 3. 사전 검증 처리는 각 조각에 대해 시행됩니다. 4. 샤드는 네트워크로 전송됩니다.

 

 

1.2 Kademlia and Modifications

IPFS 백서 분석글 에서도 나온 내용입니다. DHT 섹션을 읽어보시면 도움이 되실 겁니다.

Storj는 분산 해시 테이블(DHT) 인 Kademlia 를 기반으로 합니다. 샤드들은 해시 테이블에 저장되지 않습니다. 오히려, Kademlia 는 효율적인 메시지 라우팅 및 기타 바람직한 자질을 갖춘 분산 네트워크를 만듭니다. Storj는 몇 가지 메시지 유형과 코어 Kademlia 기능 향상을 추가했습니다. 장래에, 해시 테이블은 데이터 위치 정보 또는 다른 목적을 위한 저장소로 사용될 수 있습니다.

 

1.2.1 Signature Verification

S/Kademlia 와 마찬가지로 Storj 네트워크는 노드가 메시지에 서명 할 것을 요구합니다. 네트워크에 가입하려면 노드는 ECDSA 키 쌍 (kpriv, kpub) 을 만들어야 합니다. Kademlia 노드 ID는 ripemd160(sha256 (kpub)) 에 해당합니다. 이와 같이 Storj 네트워크의 각 노드 ID는 노드가 사용할 수있는 유효한 Bitcoin 주소이기도 합니다. 노드는 모든 메시지에 서명하고 메시지를 처리하기 전에 메시지 서명의 유효성을 검사합니다. 이러한 과정은 네트워크에서 장기간의 신원을 확인하고 Kademlia 라우팅에 대한 Eclipse 공격에 대한 작업 증명을 제공합니다. 미래에는 이라한 주소에 대해 다양한 용도로 사용됩니다.

 

1.3 Proofs of Retrievability

복구 가능성의 증거로 원격 호스트에 특정 데이터의 존재를 보장합니다. 이상적인 증거로 메시지 크기를 최소화하고, 신속하게 계산할 수 있으며, 사전 처리를 최소화하고, 파일을 그대로 사용할 수 있다는 높은 수준의 신뢰를 제공합니다. Storj는 데이터 무결성 및 데이터 소유자에 대한 가용성에 대한 정보를 제공하기 위해 "감사(검증) 또는 하트비트(heartbeat)" 라고 하는 "챌린지-응답(challenge-response) " 상호 작용을 통해 복구 가능성 증명을 발행하고 검증하기위한 표준 형식을 제공합니다.

Strorj Audit Tree with |l| = 4

Red outlines indicate the elements of a Merkle proof for S0

 

1.3.1 Partial Audits

Merkle 트리 감사 체계는 데이터 소유자에 대해 상당한 계산에 대한 오버 헤드가 필요합니다. 전체 조각은 사전 잎(pre-leaves)을 생성하기 위해 여러 번 해시(hash)되어야 하기 때문입니다. 이 계획의 확장은 데이터의 부분 집합을 사용하여 부분 감사를 수행하여 계산 오버 헤드를 줄입니다. 또한 이는 마이너(스토리지 제공자) 자원에 대한 I/O 부담을 크게 줄이는 이점이 있습니다. 

이러한 확장은 두 개의 추가 선택 가능한 매개 변수, 즉 샤드 내의 바이트 인덱스 x 세트 및 바이트 단위 섹션 길이 b 세트에 의존합니다. 데이터 소유자는 3 튜플 (s, x, b)의 집합을 저장합니다. 사전 잎(pre-leaf) i 를 생성하기 위해, 데이터 소유자는 xi 에서 발견 된 bi 바이트에 si 를 앞에 붙입니다. 심사 과정에서, 검증자는 (s, x, b)i 를 전송하며, 마이너는 이를 사용하여 사전 잎을 생성합니다. Merkle 증명은 정상적으로 생성되고 검증됩니다.

 

Storj Audit Tree with |l| = 4 and Partial Audits

Red outlines indicate the elements of a Merkle proof for S0

부분 감사는 마이너가 전체 파일을 보유 할 것이라는 확률론 적 확신만 제공합니다. 그들은 검증자가 실제로, 수정되거나 부분적으로 삭제되었을 때 마이너가 손상되지 않은 파편을 보유하고 있다고 믿는 거짓 긍정 결과를 허용합니다. 개별 부분 감사에서 거짓 긍정의 확률은 쉽게 계산할 수 있습니다. 따라서 데이터 소유자는 샤드가 손상되지 않고 사용 가능한 것으로 알려진 신뢰 수준을 가질 수 있습니다. 실제로 마이너들은 부분 감사를 무효화하기 위해 지능적인 전략을 구현할 수 있기 때문에 더욱 복잡합니다. 다행스럽게도 이것은 반복 감사의 경우 제한적인 문제입니다. 파일의 작은 부분이 삭제 된 경우에도 몇 차례 연속 false-positive가 발생할 확률은 매우 낮습니다. 또한 부분 감사는 Merkle 트리를 재구성하거나 증명 확인 프로세스를 수정하지 않고도, 전체 감사와 쉽게 섞일 수 있습니다. 전체 및 부분 검증을 혼합 한 많은 감사 전략이 구상 될 수 있으며, 각 검증 전략은 시간에 따라 다른 수준의 신뢰를 제공합니다.

 

이러한 스키마의 추가 확장은 바이트 인덱스 집합 대신 결정성(deterministic) 시드를 사용할 수 있습니다. 이 시드는 파일에서 여러 비-연속 바이트의 색인을 생성하는 데 사용됩니다. 많은 연속되지 않는 임의의 바이트를 요구하면, 처리 또는 I/O 로 인한 상당한 추가 오버 헤드없이 감사 회피 전략을 구현하려는 악의적 인 마이너에 대한 추가적인 저항을 제공합니다.

 

1.3.2 Other Proof-of-Restrievability Schemes

다른 감사 계획이 검토되었지만 일반적으로 실현 불가능한 것으로 간주됩니다. 예를 들어, Shacham-Waters 는 Merkle-tree 방식보다 몇 가지 장점이 있는 압축 증거를 제안했습니다. 이 구성은 최소의 저장된 정보로 데이터 소유자에 의해 생성 된 도전-과제의 끝없는 흐름을 허용합니다. 또한 챌린지 응답의 공개 검증을 허용합니다. 그러나 초기 구현에서는 Shacham-Waters 체계에 필요한 클라이언트 측 사전 처리가 해시 기반 방법보다 적어도 1 배 더 많은 계산 시간을 필요로 하므로 대부분의 응용 프로그램에서 너무 느리게 처리됩니다.

복구 가능성의 증거는 현재 진행중인 연구 분야이며, 다른 실용적인 계획이 앞으로 발견 될 수 있습니다. 검색 가능성 계획의 증거가 발견되고 구현됨에 따라 스키마 선택이 협상 가능한 계약 매개 변수가 될 수 있습니다. 이를 통해 각 데이터 소유자와 노드는 다양한 스키마를 구현하고 주어진 목적에 가장 유리한 계획을 선택할 수 있습니다.

 

1.3.3 Issuing Audits

감사를 수행하기 위해 Storj 는 Kademlia 메시지 세트를 AUDIT 유형으로 확장합니다. 이 메시지는 데이터 소유자로부터 마이너에게 보내지고 데이터의 해시와 챌린지를 포함합니다. 마이너는 위에서 설명한 Merkle 증명으로 응답해야합니다. Merkle 증명을 수령하고 확인한 후, 데이터 소유자는 합의 된 조건에 따라 마이너에게 비용을 지불해야합니다.

Issuing and Varifying Storj Audits

1.4 Contract and Negotiation

데이터 저장은 표준 계약 포맷을 통해 협상됩니다. 계약은 데이터 소유자와 마이너 사이의 관계를 설명하는 버전화된 데이터 구조입니다. 계약에는 각 노드가 관계를 형성하고 데이터를 전송하며 시간 경과에 따른 감사를 만들고 응답하고 지불을 중재하는 데 필요한 모든 정보가 포함되어야합니다. 여기에는 조각 해시, 조각 크기, 감사 전략 및 지불 정보가 포함됩니다. Storj는 계약서 작성에 관심있는 당사자를 연결하는 게시 / 구독 시스템을 구현합니다. 각 당사자는 서명 된 계약서 사본을 보관해야합니다. 계약은 다른 노드가 관계의 조건이나 상태를 확인할 수 없으므로 데이터 소유자와 마이너의 이익을 위해서만 존재합니다. 미래에는 계약 정보가 DHT 또는 블록 체인과 같은 외부 원장에 저장 될 수 있습니다. 이는 외부 조건에 대한 일부 외부 검증을 허용 할 수 있습니다. (계약 시스템은 Kademlia의 4 가지 새로운 메시지 유형, OFFER, CONSIGN, MIRROR, RETRIEVE 를 확장합니다.)

 

OFFER

계약을 협상하기 위해 노드는 제안 메시지를 작성하여 미래의 파트너에게 보냅니다. 유망한 파트너는 게시 / 가입 시스템을 통해 발견됩니다. 제안 메시지에는 원하는 관계를 설명하는 완전 구축 계약서가 들어 있습니다. 두 노드는 서명 된 OFFER 메시지를 반복적으로 교환합니다. OFFER 루프의 각 새 메시지에 대해 노드는 협상을 종료하거나 새 서명 된 카운터 제공을 통해 응답하거나 카운터에 서명하여 계약을 수락합니다. 오퍼는 양 당사자가 서명하면 데이터의 해시를 입력하여 로컬로 저장합니다.

 

CONSIGN

합의가 이루어지면 데이터 소유자는 CONSIGN 메시지를 마이너에게 보냅니다. 메시지에는 감사 트리의 잎이 들어 있습니다. 마이너는 데이터 소유자가 HTTP 전송을 통해 데이터를 업로드하도록 허용하는 PUSH 토큰으로 응답해야합니다. 이 토큰은 임의의 숫자이며 제 3 자에게 위임 할 수 있습니다.

RETRIEVE

RETRIEVE 메시지는 마이너로부터 파편을 회수 할 의도를 나타냅니다. 이러한 메시지는 CONSIGN 메시지와 거의 동일하지만 감사 트리를 포함하지 않습니다. 마이너는 별도의 HTTP 전송을 통해 데이터 다운로드 권한을 부여하는 PULL 토큰과 함께 유효한 RETRIEVE 메시지에 응답합니다.

MIRROR

MIRROR 메시지는 마이너에게서 다른 마이너로부터 데이터를 검색하도록 지시합니다. 이를 통해 데이터 소유자는 상당한 추가 대역폭이나 시간을 소비하지 않고도 샤드의 중복 사본을 만들 수 있습니다. 성공적인 OFFER / CONSIGN 프로세스 후, 데이터 소유자는 다른 마이너  동일한 데이터에 대해 별도의 OFFER 루프를 시작할 수 있습니다. 대신 데이터 소유자는 미러링 마이너에게 CONSIGN 메시지를 보내는 대신 원래 마이너에게 RETRIEVE 메시지를 보낸 다음 미러링 마이너의 MIRROR 메시지에 검색 토큰을 포함시킵니다. 이렇게 하면 미러링 마이너가 원래 마이너의 데이터를 검색 할 수있는 권한이 부여됩니다. MIRROR 프로세스의 성공 여부는 AUDIT 메시지를 통해 즉시 검증되어야합니다.

 

1.5 Payment

Storj는 지불 불가지론1 이라고 합니다. 프로토콜이나 계약에는 특정 지불 시스템이 필요하지 않습니다. 현재의 구현은 Storjcoin을 가정하지만 BTC, Ether, ACH 이전 또는 생후 염소의 물리적 이동을 포함하여 많은 다른 지불 유형을 구현할 수 있습니다. 레퍼런스 구현은 현재 개발중인 Storj coin 소액 결제 채널을 사용합니다. Micropayment 채널은 감사와 직접 지불을 결합하여 마이너와 데이터 소유자간에 필요한 신뢰의 양을 최소화합니다. 그러나 데이터 저장소가 저렴하기 때문에 감사 금액은 대단히 작으며 감사 당 0.000001 달러 미만인 경우가 많습니다. 

Storj coin은 다른 후보 통화보다 훨씬 세분화 된 지불을 허용함으로써 당사자 간의 신뢰를 최소화합니다. 또한, 소액 결제 채널의 메커니즘은 채널의 수명 기간 동안 채널의 총 가치를 에스크로 해야합니다.(마이크로페이먼트 참조: 라이덴네트워크) 이는 환율을 감소시키고, 가치 변동이 소액 결제 채널의 경제적 인센티브에 심각한 영향을 미친다는 것을 의미합니다. 별도의 토큰을 사용하면 외부 변동성과 일정한 단열이 형성되고 Storj coin의 대규모 공급은 토큰의 에스크로가 시장에 미치는 영향을 최소화합니다. 

 

1.지불 불가지론 : 지불에 대한 진실 여부, 즉 사용자가 어떤것으로 지불 하였는 지에 대해 파악할 수 없다. 로 해석될 수 있습니다.

 

1.6 Quasar

Storj는 Quasar 라고하는 피어 투 피어 게시/구독 시스템을 구현합니다. Quasar는 Bloom 필터를 사용하여 주제 기반 pub/sub를 제공합니다. 주제는 계약 노드의 계약 크기와 대역폭 약속을 포함하여 방송 노드가 원하는 계약 매개 변수의 범위를 설명합니다. 주제 목록은 프로토콜 수준에서 표준화되어 있으며 쉽게 확장 할 수 있습니다. 이는 메시지가 관심있는 노드에 도달하도록 함으로써 계약 제안 및 협상 프로세스를 용이하게합니다. Quasar를 사용하기 위해 Storj는 SUBSCRIBE, UPDATE 및 PUBLISH의 세 가지 새로운 메시지 유형으로 Kademlia를 확장합니다. 이 메시지는 필터 작성 및 전파를 용이하게합니다. 각 노드는 그것이 구독하는 토픽에 대한 정보와 깊이 K = 3 인 감쇠 된 Bloom 필터의 형태로 이웃들이 구독하는 토픽에 대한 정보를 유지한다. 레벨 1의 필터는 1 홉 멀리 떨어진 노드의 구독을 나타냅니다.

 

SUBSCRIBE

SUBSCRIBE는 이웃에 필터 목록을 요청합니다. 초기 필터 목록을 작성하기 위해 노드는 SUBSCRIBE 메시지를 세 개의 가장 가까운 이웃에 발행합니다. 노드는 SUBSCRIBE에 현재 필터 목록으로 응답합니다. 요청 노드는 수신 된 필터 목록을 자체 감쇠 Bloom 필터에 추가합니다.

UPDATE

UPDATE는 로컬 필터 변경을 세 개의 가장 가까운 이웃으로 푸시합니다. 노드가 새로운 토픽에 가입하면 SUBSCRIBE 요청을 발행하여 이웃 국가에 대해 학습 한 다음 이웃에게 새로운 구독을 알리는 UPDATE 요청을 발행해야한다. SUBSCRIBE / UPDATE 루프 노드를 통해 필터 목록을 교환하면 이웃 노드와 인접 라우터가 도달 할 수있는 노드에 바람직한 정보를 점진적으로 파악할 수 있습니다.

PUBLISH

PUBLISH는 네트워크에 메시지를 브로드 캐스트합니다. Storj에서는 일반적으로 부분적으로 생성 된 계약의 공개 발표입니다. PUBLISH 메시지는 세 개의 가장 가까운 이웃 노드로 보내지고, 필터 목록의 각 필터와 다이제스트가 비교되는 주제 매개 변수가 포함됩니다. 주제 다이제스트가 K = 0 에있는 필터에서 발견되면, 노드는 메시지를 처리합니다. 주제가 필터 목록의 다른 필터에서 발견되면 노드는 메시지를 인접 항목으로 전달합니다. 일치하는 필터가 발견되지 않으면 메시지는 해당 노드 라우팅 테이블의 임의로 선택된 피어로 전달됩니다.

메시지의 재순환을 방지하기 위해 노드는 노드 ID가 전달 될 때 PUBLISH 메시지에 노드 ID를 추가하여 해당 노드가 이미 메시지를 수신했음을 나타냅니다. 메시지를 전달할 때 노드는 해당 목록에 ID가있는 다른 노드를 무시합니다. 이렇게하면 통신 오버 헤드를 최소화하면서 중복되는 메시지 재전송을 방지 할 수 있습니다. PUBLISH 메시지에는 홉 단위로 측정 된 TTL(time-to-live) 매개 변수도 포함됩니다. 노드는 홉이 TTL을 초과 한 메시지를 릴레이하지 않습니다. 스팸 공격을 방지하기 위해 노드는 TTL이 새 메시지를 제공하는 TTL을 초과하는 메시지 릴레이를 거부합니다.

 

 

구독 필터를 기반으로하는이 라우팅 프로세스로 인해 PUBLISH 메시지는 필터 목록에 가입 또는 거짓 긍정이 포함 된 노드를 찾을 때까지 네트워크를 무작위로 전파합니다. 구독이 필터로 표시되면 메시지가 구독자쪽으로 빠르게 이동합니다. 거짓 긍정(False-Positive)이 발생하면 메시지는 무작위 라우팅을 재개합니다.

 

1.7 Redundancy Schemes

클라우드 객체 저장소는 대개 고객 파일을 저장하기 위해 서버를 소유하거나 임대합니다. 이들은 물리적 또는 네트워크 장애로부터 파일을 보호하기 위해 RAID 체계 또는 다중 데이터 센터 접근법을 사용합니다. 신뢰할 수 없는 피어의 분산 네트워크에 Storj 개체가 존재하므로 마이너는 기존의 클라우드 스토리지 회사와 마찬가지로 데이터 손실에 대해 동일한 안전 조치를 취하지 않아야합니다. 실제로 마이너들은 언제든지 노드의 연결을 끊을 수 있습니다. 따라서 데이터 소유자가 파일의 안전을 보장하기 위해 중복성 체계를 구현하는 것이 좋습니다. 프로토콜은 개별 샤드에 대한 계약 만 처리하므로 많은 중복 계획이 사용될 수 있습니다. 세 가지가 아래에 설명되어 있습니다.

 

1.7.1 Simple Mirroring

가장 간단한 해결책은 여러 노드에서 샤드를 미러링하는 것입니다. 미러링은 각 샤드의 여러 복사본이 존재하도록하여 하드웨어 오류를 방지합니다. 이 방식을 사용하는 샤드의 가용성은 P = 1 - ∏n0 an이며, 여기서 an은 샤드 n을 저장하는 노드의 가동 시간입니다. 모든 파편은 파일을 어셈블링해야 하므로 파일의 가용성은 사용 가능한 파편의 가용성과 같습니다. 누락 된 계약의 경우에는 해당 샤드의 중복 사본을 검색 할 수 있으며 네트워크상의 새로운 위치를 찾을 수 있습니다. 이것은 참조 구현의 현재 동작입니다.

 

1.7.2 K-of-M Erasure Coding

삭제 코딩 알고리즘(Erasure coding)은 파일을 k 개의 샤드로 나누고 프로그래밍 방식으로 m 개의 패리티 샤드(parity shards)를 만듭니다. 파일의 손실을 방지하려면 데이터 소유자는 조각 손실 허용 수준을 설정해야합니다. 20(K)-of-40(M) 소거 코딩 방식이 고려될 수 있습니다.. 데이터 소유자는 가까운 장래에 액세스 할 수 없게 될 가능성이 낮으므로 40 개에서 5 개의 샤드가 손실되는 것을 용인 할 수 있습니다. 그러나 어느 시점에서 확률 적 가용성은 안전 임계 값 이하로 떨어질 것입니다. 이 시점에서 데이터 소유자는 검색 및 재구성 프로세스를 시작해야합니다. 감사 프로세스를 통해 노드 가동 시간을 알 수 있기 때문에 관여 수준은 관련 노드의 특성에 따라 최적화 될 수 있습니다. 이 과정을 처리하기 위해 많은 전략이 구현 될 수 있습니다.

소거 코딩은 파일에 대한 액세스가 손실 될 확률을 대폭 감소시키기 때문에 바람직합니다. 또한 파일에 대해 일정 수준의 가용성을 확보하는 데 필요한 디스크상의 오버 헤드를 줄입니다. 가장 가용 한 샤드에 의해 제한되기보다는, 소거 코딩 방식은 사용 가능한 최소 n + 1 노드에 의해 제한됩니다

 

1.8 KFS

Storj는 마이너를 위한 디스크상의 저장을 용이하게 하기 위해 'KFS' 라는 로컬 파일 저장소를 구현합니다. 마이너 고객은 처음에 파일 시스템을 직접 사용하여 샤드를 저장했습니다. 나중에 마이너 고객은 단일 LevelDB 인스턴스를 사용했습니다. 이 두 가지 접근 방식 모두 확장에 실패했습니다. 예를 들어, LevelDB 압축 처리 시간은 저장소 크기에 따라 선형 적으로 조정되며 진행 중에 읽기 및 쓰기를 잠급니다. 이는 100GB가 넘는 노드를 저장하는 노드의 성능과 가용성에 큰 영향을 미쳤습니다. KFS는 스케일링 문제를 해결하려는 LevelDB 인스턴스 집합에 대한 추상화 계층입니다.

 

1.9 NAT Traversal and Reverse HTTP Tunneling

NAT 및 기타 불리한 네트워크 조건으로 인해 모든 장치가 공개적으로 액세스 할 수있는 것은 아닙니다. 비공개 노드가 네트워크에 참여할 수 있도록 Storj 는 역 터널 시스템(reverse tunnel system)을 구현합니다. 이 시스템을 용이하게 하기 위해 Storj 는 세 가지 추가 메시지 유형 인 Kademlia를 확장합니다. PROBE, FIND TUNNEL 및 OPEN TUNNEL 터널링 시스템은 2.6 절에 설명 된 게시 / 가입 시스템을 사용합니다.

 

PROBE

PROBE 메시지는 노드가 공개적으로 주소 지정 가능한지 여부를 판별 할 수있게합니다. 메시지는 공개적으로 주소 지정이 가능한 노드 (일반적으로 알려진 네트워크 시드)로 전송됩니다. 수신 노드는 별도의 PING 메시지를 발행합니다. 수신 노드는 PING의 결과로 PROBE 메시지에 응답합니다. 네트워크에 참여하는 노드는 즉시 알려진 노드에 PROBE를 보내야합니다.

초기 PROBE에 대해 부정적 응답을 수신 한 노드는 알려진 노드에 FIND TUNNEL 요청을 보내야합니다. 이 노드는 게시 / 가입 시스템을 통해 이전에 터널 공지 사항을 게시 한 3 개의 연락처로 응답해야합니다. 터널 제공 업체는 공개적으로 주소를 지정할 수 있어야합니다. 비공개 노드가 터널 제공자 목록을 수신하면 터널 제공자에게 OPEN TUNNEL 요청을 보냅니다. 제공자는 가능한 경우 해당 노드에 대해 터널을 제공해야합니다. 연결을 열려면 공급자가 터널 정보를 사용하여 긍정 응답을 다시 보냅니다. 그런 다음 터널링 된 노드는 공급자와의 장기 연결을 열고 자체 연락처 정보를 업데이트하여 터널 주소를 반영합니다.

 

1.10 Data Transfer

데이터는 HTTP 통신을 통해 전송됩니다. 마이너들은 클라이언트 애플리케이션이 샤드를 업로드하거나 다운로드 할 수 있는 엔드-포인트(End-Point)를 공개합니다. 클라이언트의 요청들은 이전 CONSIGN 및 RETRIEVE 메시지로 제공되는 토큰을 통해 인증됩니다. 이 전송 메커니즘은 프로토콜에 필수적인 것은 아니며 앞으로 많은 대안이 구현 될 수 있습니다.

 

 

 

2. Network Access

Storj 네트워크에서 데이터의 가용성과 무결성을 유지하려면 데이터 소유자가 상당한 부담을 감수해야합니다. 노드를 신뢰할 수 없으며 챌린지 세트와 같은 숨겨진 정보는 신뢰할 수 없는 피어에게 안전하게 아웃소싱 할 수 없으므로 데이터 소유자는 계약 협상을 담당하며, 지불을 제공하고, 파편 수집을 통해 파일 상태를 관리하고, 파일 암호화 키를 관리하는 등의 작업을 수행 할 수 있습니다. 이러한 많은 기능에는 특히 활성 파일 세트에 대해 높은 가동 시간과 중요한 인프라가 필요합니다. 파일 동기화 응용 프로그램과 같이 사용자가 실행하는 응용 프로그램은 네트워크의 파일을 효율적으로 관리 할 수 없습니다.

가능한 가장 광범위한 클라이언트 응용 프로그램 배열에서 네트워크에 간단하게 액세스 할 수 있도록 Storj는 데이터 소유권을 관리하는 전용 서버에 트러스트(trust)를 위임하는 씬-클라이언트(thin-client) 모델을 구현합니다. 이것은 Bitcoin 및 기타 cryptocurrency 생태계에서 발견되는 SPV 지갑 개념과 유사합니다.

데이터 소유자의 부담은 다양한 방법으로 클라이언트와 서버에서 분리 될 수 있습니다. 위임 된 금액을 다양 화함으로써 서버는 다양한 다른 가치있는 서비스를 제공 할 수 있습니다. Bridge라는 전용 서버는 자유 소프트웨어로 개발되어 출시되었습니다. 모든 개인 또는 조직은 자체 브리지 서버를 실행하여 네트워크 액세스를 용이하게 할 수 있습니다.

 

 

2.1 Bridge 

이 모델의 참조 구현은 브리지 서버와 클라이언트 라이브러리로 구성됩니다. Bridge는 객체 저장소를 제공합니다. 즉 Bridge의 기본 기능은 API를 응용 프로그램 개발자에게 공개하는 것입니다. 개발자는 네트워크, 감사 절차 또는 cryptocurrencies에 대한 지식 없이도 간단한 클라이언트를 통해 Bridge를 사용할 수 있어야합니다. Bridge API는 개발 프로세스를 간소화하는 추상화 계층입니다. 이를 통해 개발자는 Storj 네트워크를 사용하는 많은 응용 프로그램을 만들 수 있으므로 네트워크가 많은 사용자에게 다가 갈 수 있습니다.

현재 구현에서 Bridge는  계약 협상, 감사 발급 및 확인, 지불 및 파일 상태에 대한 책임을 지고 클라이언트는 암호화, 사전 처리 및 파일 키 관리를 담당합니다. Bridge는 RESTful API를 통해 이러한 서비스에 대한 액세스를 제공합니다. 이런 방식으로, 클라이언트는 Storj 프로토콜과 네트워크를 완전히 순수한상태로 유지하면서, 네트워크를 계속 이용할 수 있습니다. 또한 전용 서버가 높은 가동 시간을 갖기 때문에 신뢰할 수없는 사용자 공간 응용 프로그램에 클라이언트를 통합 할 수 있습니다.

 

Bridge는 메타 데이터 만 저장하도록 설계되었습니다. 암호화 된 샤드는 캐시하지 않으며 공개 버킷을 제외하고는 암호화 키를 보유하지 않습니다. Bridge가 타사와 공유 할 수 있는 파일에 대한 유일한 지식은 액세스 패턴과 같은 메타 데이터입니다. 이 시스템은 클라이언트의 개인 정보를 보호하고 데이터에 대한 액세스를 클라이언트가 완벽하게 제어 할 수 있도록하며 네트워크에서 사용할 수있는 파일을 Bridge에 보관할 책임을 위임합니다.

 

2.2 Bridge API and Client

Bridge API의 전체 설명서는이 백서의 범위를 벗어나지 만 다른 곳에서도 사용 가능합니다. 첫 번째 완전한 클라이언트 구현은 JavaScript입니다. C, Python 및 Java의 구현이 진행 중입니다. API 엔드 포인트에 파일을 단순히 게시 할 수 없기 때문에 Bridge API와 클라이언트의 구조는 기존 객체 저장소와 다릅니다. 클라이언트는 단순하고 친숙한 인터페이스를 통해 스토리 네트워크의 파일 관리 복잡성을 숨기기 위해 구현됩니다. 가능한 한 많은 복잡한 네트워크 작업이 간단한 함수 호출로 추상화됩니다.

 

2.3 Bridge as an Authorization Mechanism

Bridge는 네트워크에 저장된 개인 파일에 대한 권한 부여를 관리하는 데 사용할 수 있습니다. Bridge는 각 계약의 상태를 관리하기 때문에 이러한 서비스를 논리적으로 제공합니다. 다양한 공유 관련 서비스를 관리하여 공유 및 협업을 가능하게합니다.

 

2.3.1 Identity and Permissioning

Bridge API는 공개 키 암호화를 사용하여 클라이언트를 확인합니다. 각 사용자에게 API 키를 발급하는 브리지 서버가 아니라 사용자는 공개 키를 브리지에 등록합니다. API 요청이 서명되고 브리지가 서명이 등록 된 공개 키와 일치하는지 확인합니다. Bridge는 파일 메타 데이터를 버킷으로 구성하여 관리를 용이하게합니다. 버킷에 공개 키 집합을 등록하여 버킷에 개별적으로 권한을 부여 할 수 있습니다.

응용 프로그램 개발자는 이를 사용하여 응용 프로그램, 서버 또는 다른 개발자에게 사용 권한을 쉽게 위임 할 수 있습니다. 예를 들어, 파일 동기화 서비스 개발자는 해당 서비스의 각 사용자에 대해 키 쌍을 만들고 각 사용자를 해당 사용자 키 쌍만이 액세스 할 수있는 별도의 버킷으로 나눌 수 있습니다. 각 버킷의 사용량은 별도로 추적되므로 할당량을 초과 한 사용자는 프로그래밍 방식으로 쓰기 사용 권한을 취소 할 수 있습니다. 이는 다양한 조직 도구뿐만 아니라 사용자 권한을 논리적으로 구분합니다.

 

2.3.2 Key Migration

샤드 암호화 키는 생성 된 장치에 저장되므로 데이터 이식성이 중요한 문제입니다. Bridge와 클라이언트의 참조 구현은 안전한 방법으로 클라이언트간에 파일 암호화 키의 전송을 용이하게합니다. 클라이언트는 기본적으로 무작위로 생성 된 12 개의 단어 구문을 사용하여 암호 학적으로 강력한 시드를 생성합니다. 주어진 파일을 암호화하기 위해 클라이언트는 seed, Bucket ID 및 File ID를 기반으로 결정 론적으로 키를 생성합니다. 사용자는 새 장치 각각에 시드를 한 번 가져올 수 있습니다. 그러면 장치가 영구적으로 동기화됩니다. 또한 사용자는 새로 생성 된 모든 파일 키가 아닌 시드를 저장하기 만하면되므로 백업을 용이하게합니다.

 

2.3.3 Public Files

Bridge는 다른 객체 저장소와 마찬가지로 공개 버킷을 통해 공개 파일을 만들고 보급 할 수 있습니다. 브리지 서버는 개발자가 암호화 키를 업로드하도록 허용 한 다음 익명 사용자가 파일 키와 파일 포인터 집합을 검색 할 수 있게 합니다. 공용 버킷은 웹 페이지 또는 공개 응용 프로그램에 대한 컨텐트 전달에 유용합니다.

Bridge가 없어도 공개 파일을 공유하고 검색 할 수있는 시스템을 만들 수도 있습니다. 포인터와 키는 모든 플랫폼에 공개적으로 게시 할 수 있으며 클라이언트는 다운로드를 위해 마이너에게 직접 지불해야 할 수 있습니다. 실제로 이는 인센티브 급류(incentivized torrent)와 매우 유사합니다. 포인터를 제공하는 플랫폼은 급류를 촉진하는 추적기와 유사하게 기능합니다. 이 시스템이 기존의 급류 네트워크에 비해 중요한 이점을 가지고 있는지 여부는 분명하지 않습니다.

 

2.3.4 File Sharing

앞으로 Bridge는 응용 프로그램이나 사용자간에 특정 파일을 공유 할 수 있습니다. 모든 파일이 공유 네트워크에 공존하므로 표준화 및 ID 관리의 문제입니다. Bridge는 안전한 개인간 파일 공유를 가능하게하기 위해 PGP 키 서버 또는 Keybase와 같은 타사 소스를 사용할 수도 있습니다. 계층 적 키잉 전략 (LastPass에서 사용 된) 은 개별 파일을 공유 할 수도 있습니다. 프록시 재 암호화와 같은 다른 암호화 기법이 유망한 것으로 보인다.

- 예시 : 파일 키가 강력하게 암호화되어 브리지로 에스크로 된 경우 파일은 키베이스를 통해 인증 할 수있는 모든 소셜 미디어 핸들과 공유 할 수 있습니다. Bridge는 해당 클라이언트에 전달 키와 함께 하나의 암호화 된 파일 키를 보낼 수 있으므로 파일을 Bridge에 노출시키지 않고 파일에 액세스 할 수 있으며 어떤 방식 으로든 파일을 수정할 수 있습니다.

 

2.4 Bridge as a Network Information Repository

앞서 언급했듯이 데이터 소유자는 계약을 협상하고 파일 상태를 관리해야합니다. 네트워크상의 피어에 대한 충분한 정보가 있으면 계약 선택은 파일 상태를 유지 관리하는 강력한 도구가됩니다. Bridge는 많은 마이너들과 많은 적극적인 계약을 맺을 것이므로 그 마이너에 관한 정보에 접근 할 수 있습니다. Bridge는이 정보를 사용하여 특정 성능 목표를 달성하기 위해 마이너 집합에 지능적으로 조각을 배포 할 수 있습니다.

Bridge는 네트워크상의 동료에 대한 지식을 활용하여 서비스를 고객 요구 사항에 맞게 조정할 수 있습니다. 제한된 서비스 계층 세트 대신 Bridge는 모든 서비스 요구 사항을 충족하기 위해 즉석에서 계약 패키지를 조합 할 수 있습니다. 이를 통해 클라이언트는 파일의 최적의 대기 시간, 대역폭 또는 위치를 결정하고 목표를 달성 할 것이라는 확신을 가질 수 있습니다. 예를 들어, 스트리밍 비디오 애플리케이션은 고 대역폭에 대한 요구를 규정 할 수 있으며, 아카이브 스토리지는 높은 가용성만을 요구할 수 있습니다. 충분히 큰 네트워크에서 어떤 필요성이라도 충족 될 수 있습니다.

 

보안 분산 컴퓨팅은 해결되지 않은 문제이므로 각 브리지 서버는 축적 된 네트워크 지식을 사용합니다. Bridge는 분산 네트워크만으로는 제공 할 수없는 농부의 성능과 신뢰성에 대한 지식을 기반으로 확률적인 서비스 품질을 제공 할 수 있습니다.

 

2.5 Bridge as a Service

신뢰 위임 비용이 지나치게 높지 않은 경우 고객은 제 3 자 Bridge를 사용할 수 있습니다. Bridge는 데이터를 저장하지 않고 키에 액세스 할 수 없기 때문에 기존 데이터 센터 모델에서 여전히 큰 개선 사항입니다. Bridge 서버가 권한 부여 및 지능형 계약과 같이 제공하는 많은 기능은 상당한 네트워크 효과를 활용합니다. 데이터 세트는 크기가 커짐에 따라 기하 급수적으로 유용 해지며, 이는 Bridge에서 인프라와 정보를 공유하기위한 강력한 경제적 인센티브가 있음을 나타냅니다.

객체 저장소를 사용하는 응용 프로그램은 저장소 공급자에게 상당한 양의 신뢰를 위임합니다. 제공자는 공공 Bridge를 서비스로 운영하도록 선택할 수 있습니다. 그런 다음 애플리케이션 개발자는 전통적인 객체 저장소와 마찬가지로 Bridge에  신뢰를 위임하지만 정도는 떨어집니다. 향후 업데이트는 클라이언트와 Bridge 간의 다양한 책임 분배 (그리고 신뢰 수준)를 허용 할 것입니다. 이로 인해 응용 프로그램 개발자가 서비스 공급자에게 상당한 운영 부담을 전가시킵니다. 또한 개발자는 암호 화 지갑을 관리하는 대신 신용 카드와 같은 표준 지불 메커니즘을 사용하여 스토리지 비용을 지불 할 수 있습니다. Storj Labs Inc.는 현재이 서비스를 제공합니다.

 

3. Future Areas of Research

3.1 Federated Bridge

Bridge 노드는 상호 이익이되는 연합에서 네트워크에 대한 데이터를 공유하기 위해 협력 할 수 있습니다. 이를 통해 각 Bridge는 사용 가능한 정보의 품질을 향상시킴으로써 제공되는 서비스 품질을 향상시킬 수 있습니다. Bridge는 또한 사용자의 동의하에 협력하여 파일 메타 데이터와 포인터를 공유 할 수 있습니다. 이렇게하면 사용자는 단일 Bridge에 종속되지 않고 모든 Bridge에서 파일에 액세스 할 수 있습니다. 동일한 액세스 정보를 저장하는 계층화 된 폴백 (fallback) Bridge 세트가 바람직한 기능입니다. 솔로 Bridge에서 중단 시간을 헤지하기 때문입니다. 해결할 수있는 몇 가지 권한 문제가 있을 수 있지만 Bridge에서 상태를 동기화하기 위한 표준 형식 및 알고리즘이 개발되지 않을 수도 있습니다.

 

3.2 Data Portability

Storj는 데이터 형식 및 액세스 표준 사용을 권장함으로써 응용 프로그램간에 데이터를 이식 할 수 있도록하고 있습니다. Storj가 공통 기본 계층을 형성하기 때문에 데이터 액세스가 데이터에 액세스하는 데 사용되는 서비스에 묶여있는 기존 모델과 달리 데이터 액세스는 개별 사용자와 연결될 수 있습니다. 사용자 데이터를 영구적 인 암호화 ID에 연결하고 데이터를 제 3 자에게 노출시키지 않고 인증 할 수 있습니다. 응용 프로그램에서 Siloing 데이터는 기존 모델의 유해한 유물입니다. 데이터 스토리지의 미래에 상호 호환성을 구축하면 사용자의 개인 정보와 사용자 경험이 크게 향상됩니다.

이러한 표준을 구현하는 응용 프로그램은 광범위하게 호환됩니다. 액세스가 서비스가 아닌 사용자에게 연결될 때 개인 정보 보호 및 제어가 보존됩니다. 사용자는 하드 드라이브를 백업하는 서비스에 액세스 권한을 부여 할 수 있습니다. 하드 드라이브는 Storj에 파일을 저장합니다. 사용자는 사진 공유 서비스에 대한 액세스 권한을 별도로 부여 할 수 있으며 그러면 백업의 모든 사진에 액세스 할 수 있습니다. 사용자는 많은 응용 프로그램에서 데이터의 이식성을 확보하고 응용 프로그램 개발자는 기존 사용자의 대규모 풀에 액세스 할 수 있습니다.

 

3.3 Eclipse

Eclipse 공격은 모든 아웃 바운드 연결이 악성 노드에 도달하도록하여 네트워크 그래프에서 노드 또는 노드 집합을 격리하려고 시도합니다. 악의적 인 노드는 대부분의 경우 정상적으로 기능 할 수 있기 때문에 특정 중요한 메시지 나 정보를 무시하기 때문에 Eclipse 공격을 식별하기가 어려울 수 있습니다. Storj는 공개 키 해시를 노드 ID로 사용하여 일식 공격을 처리합니다. 네트워크의 노드를 Eclipse 하기 위해 공격자는 가장 가까운 비 악의적 인 이웃보다 해시가 대상 노드에 더 가까운 세 개의 키를 발견 할 때까지 키 쌍을 반복해서 생성해야하며 더 가까운 ID를 가진 새로운 노드에 대해 해당 위치를 방어해야합니다 . 이것은 본질적으로 네트워크의 노드 수에 비례하는 작업 증명 문제입니다.

 

3.4 Hostage Bytes

Hostage Byte 공격은 악의적 인 마이너들이 데이터 소유자로부터 추가 지불을 강요하기 위해 샤드, 또는 샤드의 일부 를 전송하는 것을 거부하는 스토리지 관련 공격입니다. 데이터 소유자는 여러 노드에 분할 코드를 중복 저장하여 Hostage Byte 공격으로부터 보호해야합니다. 클라이언트가 지우기 인코딩(Erase-coding)의 경계를 비밀로 유지하는 한 악의적 인 마이너는 마지막 바이트가 무엇인지 알 수 없습니다. 중복 스토리지는 이 공격에 대한 완벽한 솔루션은 아니지만이 공격의 실제적인 응용 프로그램의 대부분을 처리합니다. 중복성을 없애기 위해서는 여러 악의적 인 노드에 대한 담합이 필요하며 이는 실제로 실행하기가 어렵습니다.

 

3.5 Cheating Owner

데이터 소유자는 올바른 감사를 거부함으로써 데이터 저장을 위해 마이너에게 지불하는 것을 피할 수 있습니다. 이에 대응하여 마이너는 데이터 소유자의 파편을 삭제할 수 있습니다. 이 공격은 외부의 관찰자가 어느 당사자의 주장을 검증하기 어렵기 때문에 미래의 분산 평판 시스템에 대해 주로 문제를 야기합니다. 실용적으로 공개적으로 입증 가능한 저장 증거는 없으며 개인적으로 검증 가능한 감사가 발급되었거나 주장대로 응답되었다는 것을 독립적으로 입증 할 수있는 알려진 계획이 없습니다. 이는 치팅 클라이언트 공격이 평판 시스템에서 커다란 해결되지 않은 문제임을 나타냅니다.

 

3.6 Faithless Farmer

파밍(Farming) 소프트웨어는 다운로드 요청을 처리하기 전에 서명과 토큰을 통해 인증을 요구하기 위해 제작되었지만, 지불 요청자에게 파편을 제공 할 수있는 파밍 소프트웨어를 수정하는 것이 합리적입니다. 믿을 만한 마이너들이 지배하는 네트워크에서 타사는 네트워크에 있는 임의의 조각을 집계하고 검사 할 수 있습니다.

그러나 믿을 만한 마이너들이 네트워크를 지배하더라도 데이터 프라이버시가 크게 손상되지 않습니다. 주어진 파일을 구성하는 조각의 위치는 데이터 소유자가 단독으로 유지하기 때문에 소유자를 손상시키지 않으면서 대상 파일을 찾는 것이 매우 어렵습니다. Storj는 손상된 데이터 소유자를 보호하도록 설계되지 않았습니다. 또한 타사가 모든 파편을 모을 경우 강력한 클라이언트 측 암호화가 파일 내용을 검사하지 못하도록 보호합니다. 포인터 및 암호화 키는 개별적으로 보안 될 수있다. Bridge의 현재 구현에서 포인터와 키는 각각 Bridge와 클라이언트에 의해 유지됩니다.

 

3.7 Defeated Audit Attacks

전형적인 Merkle 증명 검증은 검증자가 나무의 깊이를 알 필요가 없다. 대신 검증자는 데이터의 유효성을 검사해야합니다. Storj 감사 트리에서 깊이가 검증자에게 알려지지 않은 경우 마이너는 트리에서 해시에 대한 Merkle 증명을 전송하여 확인 프로세스를 공격 할 수 있습니다. 이 증명은 여전히 ​​Merkle 루트를 생성하므로 일부 노드의 유효한 증명입니다. 그러나 검증자가 트리를 생성하는 데 사용 된 데이터를 보유하지 않기 때문에 증명이 해당 챌린지에 해당하는 특정 리프에 대한 것인지 검증 할 수있는 방법이 없습니다. 검증자는 트리 깊이, 잎 노드 세트 또는 사전 잎 세트와 같은 트리 바닥에 대한 정보를 저장해야합니다. 이 중 깊이가 가장 작기 때문에 바람직합니다.

프리-리프를 중개자로 사용하면 다른 공격이 무효화됩니다. 여기서 마이너는 어느 리프가 현재의 도전에 해당하는지 간단히 추측합니다. 이 공격이 성공하지는 못했지만, 마이너가 사전 잎을 제공하도록 강요함으로써 그 공격을 자멸했습니다. 마이너는 챌린지가 발행되기 전에 프리-리프를 알 수 없습니다. 사전 리프의 전송을 요구하면 데이터 소유자는 무작위로 선택하도록 강요 당하지 않고 선형 적으로 챌린지 세트를 진행할 수 있습니다. 이는 데이터 소유자가 트리 당 더 적은 상태 정보를 유지할 수 있기 때문에 바람직합니다.

 

---

 

4. Storj Message Type

4.1 Kademlia

- PING : 노드가 온라인 상태인지 확인합니다.

- STORE : DHT 에 value를 저장합니다.

- FIND_NODE : DHT 에 노드를 찾습니다.

- FIND_VALUE : DHT 에 value를 찾습니다.

 

4.2 Tunneling

- PROBE : 송신자가 공개적으로 주소가 지정되었는지 확인합니다.

- FIND_TUNNEL : 공개적으로 주소가 지정된 노드 제공 터널을 찾습니다.

- OPEN_TUNNEL : 노드 제공 터널을 가진 터널을 엽니다.

 

4.3 Quasar

- SUBSCRIBE : 인근 필터 리스트를 요청합니다.

- UPDATE : 업데이트된 파일들을 인근에 알립니다.

- PUBLISH : 관심있는 노드에게 메세지를 전송합니다.

 

4.4 Contracting

- OFFER : 계약을 제안하거나 마무리 합니다.

- CONSIGN : 마이너로부터 PUSH 토큰을 요청합니다.

- MIRROR : 다른 마이너의 데이터를 검색하고 미러링 하도록 마이너에게 지시합니다.

- AUDIT : 마이너에게 감사 문제를 제기합니다.

- RETRIEVE : 마이너로부터 PULL 토큰을 요청합니다.