IPFS 는 어떻게 파일을 다운로드 합니까?

IPFS 는 파일을 로컬 노드로 다운로드 합니다. 이때 사용하는 명령은 ipfs get 이며 로컬에 캐시됩니다. ipfs pin add 는 다운로드 한 캐시 데이터를 잠그는데 사용됩니다. IPFS 에서 pin 은 파일이 오랫동안 로컬에 저장되고 가비지 수집되지 않으며 pin 에 의해 처리되지 않은 데이터가 정기적으로 정리된다는 것을 의미합니다.

위의 그림은 ipfs get 명령의 흐름을 보여줍니다. 현재 노드의 경우 연결된 모든 피어 노드가 swarm 네트워크를 형성합니다. 로컬 노드가 get 요청을하면 로컬 블록 저장소에서 요청 된 데이터를 먼저 찾은 다음 찾지 못하면 swarm 네트워크에 DHT 라우팅을 통해 데이터를 소유 한 노드를 찾는 요청을 보냅니다. 요청 된 데이터가 있는 노드가 발견되면 노드는 데이터를 피드백 합니다. 그런 다음 로컬 노드는 수신 된 블록 데이터를 로컬 블록 저장소에 캐시하여 전체 네트워크가 원본 데이터의 복사본과 동일하게 만듭니다. 더 많은 노드가 데이터를 요청하면 노드의 데이터가 점점 더 많아지기 때문에 데이터가 손실되기가 거의 불가능 해집니다. 이것이 IPFS 네트워크가 영구적으로 데이터를 저장할 수 있는 방법입니다.

get 명령을 사용하여 해시가 가르키는 데이터를 얻을 수 있습니다. cat 옵션을 통하여 해시의 데이터를 볼 수 있습니다.

$ ipfs get QmbrevseVQKf1vsYMsxCscRf6D7S2dftYpHwxkYf94pc7T
Saving file(s) to QmbrevseVQKf1vsYMsxCscRf6D7S2dftYpHwxkYf94pc7T
 17 B / 17 B [====================================] 100.00% 0s

$ ipfs cat QmbrevseVQKf1vsYMsxCscRf6D7S2dftYpHwxkYf94pc7T
IZ*ONE violeta

ipfs pin 명령어는 다음과 같이 사용된다.

$ ipfs pin add QmbrevseVQKf1vsYMsxCscRf6D7S2dftYpHwxkYf94pc7T
pinned QmbrevseVQKf1vsYMsxCscRf6D7S2dftYpHwxkYf94pc7T recursively

IPFS 는 어떻게 파일을 저장합니까?

IPFS 파일의 저장 및 읽기는 BitTorrent 업로드 및 다운로드의 원칙과 유사합니다. IPFS에서 채택한 인덱스 구조는 DHT (Distributed Hash Table) 이며 데이터 구조는 MerkleDAG (Merkle Directed Acyclic Graph) 입니다.

1. IPFS 단일 파일 저장소

파일 시스템을 연구 한 사람들은 인덱스와 섹터라는 두 가지 개념을 알고 있습니다. 예를 들어 NTFS 섹터는 보통 4K 이고 실제 파일 데이터는 섹터에 저장됩니다. 이러한 섹터를 찾는 방법은 인덱스를 만드는 것입니다. IPFS 는 파일 시스템이기도하지만 IPFS 에는 저장 용량 제한이 없으며 공간 복구 기능도 없다는 점이 다릅니다. IPFS 가 파일을 저장하면 다음 단계를 수행합니다:

1. 단일 파일을 256KB 크기의 여러 블록으로 분할합니다. (블록, 섹터로 이해할 수 있음)
2. 블록 (block) 당 blockhash 를 계산합니다. hashN = hash(blockN)
3. 모든 blockhash 를 배열에 넣은 다음 해시를 계산하면 파일의 최종 해시인 hash(file) = hash(hash1…N) 이 생성되고 hash(file) 와 blockhash 배열을 묶어 객체를 구성하고 객체를 인덱스 구조로 처리합니다.
4. IPFS 노드에 블록 및 인덱스 구조를 업로드 합니다. 파일은 IPFS 네트워크와 동기화 됩니다.

여기에는 또한 작은 파일의 처리 논리가 누락되어 있으며 NTFS 와 같은 파일 시스템과 유사하게 작은 파일 (1KB보다 작음) 은 IPFS 가 데이터 콘텐츠를 직접 해시 (인덱스) 와 함께 배치하여 하나의 IPFS 노드 블록에 업로드하는 일이 더 이상 없습니다. 이것으로 파일의 원래 데이터와 파일 인덱스 (예: 해시)가 IPFS 네트워크에 업로드 되었습니다. IPFS 는 교정을 지원하지 않습니다. 일단 파일이 IPFS 와 동기화되면 영구히 존재하게 됩니다.

대규모 파일을 자주 편집하는 경우 편집 할 때마다 다시 동기화해야 합니다. 그렇다면 너무 많은 공간을 낭비하지 않을까요? 다음을 보면 알 수 있습니다.

예를 들어 IPF 에 동기화 된 1G 의 File1 이라는 큰 파일이 있습니다. 이 파일 File1 뒤에 1K 내용을 추가 한 후 이 파일을 다시 동기화해야 합니다. 계산해야 할 공간은 1G + 1G + 1K 입니다. IPFS 가 데이터를 저장하면 동일한 데이터가 한 번만 저장되며 파일은 블록으로 저장됩니다. 동일한 해시 블록은 한 번만 저장됩니다. 즉 이전 1G 의 내용은 변경되지 않았습니다. IPFS 는 데이터의 마지막 1K 에 대하여만 블록이 할당되고 해시는 다시 업로드 됩니다. 실제 점유 공간은 1G + 1K 입니다.

자막이 있는 영화는 오디오 및 비디오 부분이 같고 자막이 다른 경우를 생각해보면 각기 다른 국가의 두 사람이 같은 영화를 업로드 할 때 이러한 파일이 블록에 있습니다. (block) 대부분의 블록 해시가 일관성이 있을 가능성이 높습니다. 이 블록은 하나의 복사본만 IPFS 에 저장하므로 동일한 블록을 가리키는 많은 파일 인덱스가 있을 수 있습니다. 이는 MerkleDAG 데이터 구조를 의미 합니다.

해시는 모든 인덱스에 저장되기 때문에 MerkleDAG 에는 다음과 같은 기능이 있습니다 (whitepaper 내용): 1) Content based Addressing: 모든 내용은 링크를 포함하여 여러 해시 체크섬으로 고유하게 식별됩니다. 2) 위조 할 수 없음: 모든 내용이 체크섬으로 확인됩니다. 데이터가 훼손되거나 손상되면 IPFS 가 탐지합니다. 3) 중복 제거: 콘텐츠를 복제하고 한 번만 저장합니다.

2. IPFS 디렉토리 파일 저장

IPFS 는 디렉토리 구조를 지원하며 저장은 다음과 같습니다:

1. 먼저 디렉토리의 모든 파일을 IPFS 네트워크와 동기화하고 모든 파일 해시에 대한 별칭을 만듭니다. 이 별칭은 실제로 로컬 파일 이름입니다. 해시와 별칭은 IPFSLink 라는 객체를 형성하기 위해 함께 ‘번들링 (결합; 묶음)’ 됩니다.
2. 디렉토리의 모든 IPFSLink 객체를 배열로 만들고 배열에 대한 디렉토리 해시를 계산하고 배열과 디렉토리 해시를 구조로 결합하고 IPFS 네트워크에 동기화 합니다.
3. 상위 계층에 디렉토리 구조가 있으면 디렉터리 해시에 별칭 (즉, 디렉토리 이름) 이 만들어지고 IPFSLink 객체를 만들기 위해 디렉토리 해시와 별칭이 함께 ‘번들’로 포함되며 실행은 2 단계를 반복합니다.
4. 디렉토리 해시를 출력하고 읽을 때 사용됩니다.

IPFS 는 어떻게 데이터를 업로드하고 다운로드 할까?

IPFS 에서 데이터를 업로드하는 과정을 알아봅시다. 먼저 단일 데이터 업로드를 예로 들어 보겠습니다. (전제: 모든 사람이 IPFS 실행 파일을 설치했다고 가정)

1. 데이터 업로드 IPFS 프로세스

[1] 현재 디렉토리에서 foo.txt 파일 작성

$ ipfs add foo.txt
added QmTzeEKzcweAsSw2mQbcKLgm6TWqbuVCqZAHk5J9543CVZ foo.txt
 10 B / 10 B [=====================================] 100.00%

위 과정을 통하여 hash 를 받을 수 있습니다.

ipfs add 명령은 foo.txt 파일을 로컬에 저장하고 해시값을 지정합니다. 이 해시값은 이 파일의 ID 입니다.

[2] 노드를 시작하고 IPFS 네트워크에 연결

IPFS 노드 시작 명령은 다음과 같습니다.

$ ipfs daemon

IPFS 데몬 명령을 시작한 후 내 노드가 IPFS 네트워크에 연결되면 내 로컬 데이터를 전체 네트워크에 공유 할 수 있습니다. 하지만 내 파일 해시값은 나만 알고 있으며 다른 사람들은 액세스 할 수 없으므로 foo.txt 데이터는 내 노드에만 로컬로 저장되며 다른 네트워크 노드는 데이터를 저장하지 않습니다. 노드를 끄면 IPFS 네트워크의 foo.txt 데이터가 존재하지 않게 됩니다.

IPFS 데몬이 시작되면 (쉽게 말하자면) 전체 네트워크에 foo.txt 데이터가 있음을 알리게 됩니다.

[3] 웹 페이지 또는 CLI 을 통해 foo.txt 데이터에 액세스하고 로컬로 저장하는 대신 IPFS 네트워크에 저장할 수 있습니다. (ipfs daemon 은 멈출 수 없음)

예) 웹 페이지 입력: https://ipfs.io/ipfs/QmTzeEKzcweAsSw2mQbcKLgm6TWqbuVCqZAHk5J9543CVZ

완료되면 데이터가 IPFS 네트워크에 저장됩니다. 이렇게 되면 로컬 노드를 중지하더라도 (ipfs daemon 종료) 웹 페이지 또는 CLI 을 통해서 데이터에 계속 액세스 할 수 있습니다.

요약하면 위의 세 단계를 거치면 내 데이터가 IPFS 네트워크에 저장됩니다.

2. IPFS 업로드 속도

위의 저장 프로시저에서 첫 번째 단계와 두 번째 단계는 데이터를 저장하기 위한 준비 작업이며 세 번째 단계는 실제 저장 프로시저 입니다. 저장 속도는 큰 파일에 대응한 것으로 작은 파일은 전통적인 HTTP 와 차이가 없고 큰 파일은 IPFS 가 업로드하는 속도가 확실히 빠르다.

IPFS 의 대용량 파일 (예: 1G 파일) 은 저장 될 때 대용량 파일을 나누어 여러 파일 조각을 형성합니다. 각 조각은 256kb 이며 이 조각도 해시 값으로 생성됩니다. 업로드 프로세스는 동시에 진행되며 모든 조각이 동시에 네트워크에 제공됩니다. 스토리지 노드는 wantlist 테이블에 따라 해당 조각을 저장합니다. 일반적인 HTTP 저장소의 경우 저장소 노드는 중앙 서버이며 저장소는 모든 파일을 스트림 형식으로 저장합니다.

이렇게 비교하며 IPFS 는 많은 스토리지 볼륨이 대용량 데이터 파일의 조각에 대해 동기화되고 저장되기 시작하며 모든 조각 파일이 로드되면 저장 작업이 완료됩니다. 이 속도는 http 스토리지보다 훨씬 빠릅니다. 마치 여러 사람이 함께 분담해서 일을 하면 한 명보다 더 빠르고 효율적으로 처리할 수 있다.

3. IPFS 다운로드 속도

IPFS 는 대용량 파일을 몇 개로 나눠서 하나의 서버에서 파일을 다운로드 할 수 있을뿐만 아니라 수백 대의 서버에서 동시에 다운로드 할 수 있습니다. 이렇게 하면 액세스가 크게 빨라집니다.

IPFS 마이닝

IPFS 는 우리에게 무엇을 할 수 있습니까?

미래를 예측하는 인공 지능, 사물의 인터넷, 그리고 지금 가장 인기있는 블록 체인; 이 세 가지가 미래 기계 시대의 세 가지 기본 요소가 될 것입니다. 개발을 제한하는 중요한 문제는 데이터 저장 문제입니다. 인터넷 기술의 발달과 함께 데이터의 양은 폭발적으로 증가 할 것입니다. 기존의 중앙 집중화 된 서버는 스토리지 용량과 보안 및 유지 관리 비용 측면에서 병목 현상이 발생합니다.

IPFS 는 위의 문제를 해결하는 열쇠입니다. IPFS 안전한, 상한이 없는, 신뢰할 필요 없는, 값싼, 빠른 조회 저장이 가능한 분산 네트워크 스토리지 모델을 제공합니다.

IPFS 는 현재 HTTP 프로토콜을 데이터 전송 저장을 위한 기본 프로토콜로 대체합니다. 입력한 URL 은 http://xxx 가 아니라 ipfs/xxx 가 됩니다.