IPFS 심층 분석: 차세대 인터넷 기본 프로토콜

저자: Xiang, W3.Hitchhiker

IPFS란 무엇인가

탈중앙화된 인터넷(web3.0)을 위한 동력 제공.

인간의 지식을 저장하고 발전시키는 보다 확장 가능하고 탄력적이며 개방적인 방식으로 네트워크를 유지하는 점대점 초미디어 프로토콜.

IPFS는 파일, 웹사이트, 애플리케이션 및 데이터를 저장하고 접근하기 위한 분산 시스템입니다.

HTTP

"IPFS"는 여러분이 익숙할 수 있는 "HTTP"라는 것과 대응됩니다. 인터넷에서 바이두 검색 페이지를 열 때 보이는 것이 바로 그것입니다.

웹의 응용 계층 프로토콜은 하이퍼텍스트 전송 프로토콜(HTTP)로, 전통적인 웹의 핵심입니다. HTTP는 두 개의 프로그램으로 구현됩니다: 하나는 클라이언트 프로그램이고 다른 하나는 서버 프로그램입니다. 클라이언트 프로그램과 서버 프로그램은 서로 다른 단말 시스템에서 실행되며, HTTP를 통해 세션을 교환합니다. HTTP는 이러한 데이터의 구조와 클라이언트와 서버 간의 상호작용 방식을 정의합니다.

웹 페이지는 객체로 구성되어 있으며, 객체는 HTML 파일, JPEG 이미지 또는 짧은 비디오 클립과 같은 파일입니다. 이들은 URL 주소를 통해 주소 지정할 수 있습니다. 대부분의 웹 페이지는 기본 HTML 파일과 여러 참조 객체를 포함합니다.

HTTP는 웹 클라이언트가 웹 서버에 웹 페이지를 요청하는 방식과 서버가 클라이언트에게 웹 페이지를 전달하는 방식을 정의합니다.

브라우저는 HTTP 프로토콜과 프론트엔드 코드를 실행하고 해석하여 내용을 표시하는 작업을 수행합니다. 쿼리를 제출할 때 일반적으로 웹 측에서 데이터베이스를 쿼리하고 결과를 요청자에게 반환하며, 요청자는 브라우저입니다. 그런 다음 브라우저가 이를 표시합니다.

HTTP 프로토콜의 단점

현재 우리가 사용하는 인터넷은 모두 HTTP 또는 HTTPS 프로토콜 하에서 운영되고 있으며, HTTP 프로토콜은 월드 와이드 웹 서버에서 로컬 브라우저로 하이퍼텍스트를 전송하는 전송 프로토콜입니다. 1990년에 제안된 이후로 32년이 지났으며, 현재 인터넷의 폭발적인 성장에 기여하여 인터넷의 번영을 이루었습니다.

그러나 HTTP 프로토콜은 C/S 아키텍처 기반의 인터넷 통신 프로토콜로, 주 네트워크의 중앙 집중식 운영 메커니즘에 기반하고 있어 여러 단점이 존재합니다.

1. 인터넷의 데이터는 파일이 삭제되거나 서버가 종료됨에 따라 종종 영구적으로 사라집니다. 통계에 따르면 현재 인터넷의 웹 페이지 평균 저장 수명은 약 100일에 불과하며, 우리는 종종 "404 오류"가 발생하는 웹사이트를 봅니다.
2. 주 네트워크의 운영 효율성이 낮고 사용 비용이 높습니다. HTTP 프로토콜을 사용할 때마다 중앙 집중식 서버에서 전체 파일을 다운로드해야 하므로 속도가 느리고 효율성이 낮습니다.
3. 주 네트워크의 동시 처리 메커니즘이 인터넷 접근 속도를 제한합니다. 이러한 중앙 집중식 주 네트워크 모델은 높은 동시 처리 상황에서 네트워크 접근 시 혼잡을 초래합니다.
4. 현재의 HTTP 프로토콜 하에서는 모든 데이터가 이러한 중앙 집중식 서버에 저장되며, 인터넷 거대 기업들은 우리의 데이터에 대해 절대적인 통제권과 해석권을 가지고 있습니다. 다양한 규제, 차단, 감시는 어느 정도 혁신과 발전을 크게 제한합니다.
5. 비용이 높고 공격에 취약합니다. HTTP 프로토콜을 지원하기 위해, 바이두, 텐센트, 알리바바와 같은 대량 트래픽 기업들은 서버와 보안 위험을 유지하기 위해 막대한 자원을 투입하여 DDoS 공격 등을 방지합니다. 주 네트워크는 전쟁, 자연 재해, 중앙 서버 다운 등으로 인해 전체 인터넷 서비스 중단을 초래할 수 있습니다.

IPFS의 해결책

1. IPFS는 파일의 역사적 버전 추적 기능을 제공하여 파일의 역사적 버전을 쉽게 확인할 수 있으며, 데이터는 삭제할 수 없고 영구적으로 저장됩니다.
2. IPFS는 콘텐츠 주소 지정 기반의 저장 모델로, 동일한 파일은 중복 저장되지 않으며, 과잉 자원을 압축하여 저장 공간을 해방시킵니다. 데이터 저장 비용이 감소합니다. P2P 방식으로 다운로드를 변경하면 대역폭 사용 비용을 약 60% 절감할 수 있습니다.
3. IPFS는 P2P 네트워크 기반으로 여러 소스에서 데이터를 저장할 수 있으며, 여러 노드에서 데이터를 동시에 다운로드할 수 있습니다.
4. 탈중앙화된 분산 네트워크에 구축된 IPFS는 중앙 집중식 관리와 제한을 받기 어려워 인터넷이 더욱 개방적이 됩니다.
5. IPFS의 분산 저장은 중앙 주 네트워크에 대한 의존도를 크게 줄일 수 있습니다.

간단히 말해:

HTTP는 중앙 집중식 서버에 의존하며 공격에 취약하고, 트래픽이 급증할 경우 서버가 다운되기 쉽고, 다운로드 속도가 느리며, 저장 비용이 높습니다;

반면 IPFS는 분산 노드로 구성되어 있어 DDoS 공격에 안전하고, 주 네트워크에 의존하지 않으며, 저장 비용을 줄이고 저장 공간이 크며, 다운로드 속도가 빠르고 파일의 역사적 버전 기록을 조회할 수 있으며, 이론적으로 영구 저장이 가능합니다.

새로운 기술이 오래된 기술을 대체하는 것은 두 가지에 불과합니다:

첫째, 시스템 효율성을 높일 수 있어야 합니다;

둘째, 시스템 비용을 낮출 수 있어야 합니다.

IPFS는 이 두 가지를 모두 달성했습니다.

IPFS 팀은 개발 시 고도로 모듈화된 통합 방식을 채택하여 블록 쌓듯이 전체 프로젝트를 개발했습니다. 프로토콜 실험실 팀은 2015년에 설립되어 2017년까지 IPLD, LibP2P, Multiformats라는 세 가지 모듈 개발에 집중했습니다. 이들은 IPFS의 기본을 지원합니다.

Mutiformats는 해시 암호화 알고리즘과 자기 설명 방식(값을 통해 값이 어떻게 생성되었는지 알 수 있는)의 집합으로, SHA1, SHA256, SHA512, Blake3B 등 6가지 주요 암호화 방식을 포함하여 nodeID 및 지문 데이터 생성을 암호화하고 설명하는 데 사용됩니다.

LibP2P는 IPFS의 핵심 중 핵심으로, 다양한 전송 계층 프로토콜과 복잡한 네트워크 장치에 직면하여 개발자가 신속하게 사용 가능한 P2P 네트워크 계층을 구축할 수 있도록 도와줍니다. 이는 IPFS 기술이 많은 블록체인 프로젝트에서 선호되는 이유입니다.

IPLD는 사실 변환 미들웨어로, 기존의 이종 데이터 구조를 통일된 형식으로 변환하여 서로 다른 시스템 간의 데이터 교환과 상호 운용을 용이하게 합니다. 현재 IPLD가 지원하는 데이터 구조는 비트코인, 이더리움의 블록 데이터 등이며, IPFS와 IPLD도 지원합니다. 이것이 IPFS가 블록체인 시스템에서 인기를 끌고 있는 두 번째 이유입니다. IPLD 미들웨어는 서로 다른 블록 구조를 표준으로 통일하여 전달할 수 있도록 하여 개발자에게 높은 성공률의 표준을 제공합니다. 성능, 안정성 및 버그에 대한 걱정 없이 사용할 수 있습니다.

IPFS의 장점

• Kademlia, BitTorrent, Git 등의 개념을 통합한 초미디어 배포 프로토콜
• 중앙 노드의 실패를 방지하고, 검열과 통제가 없는 완전한 탈중앙화 점대점 전송 네트워크
• 인터넷의 내일로 나아가기 ------ 새로운 브라우저는 이미 IPFS 프로토콜을 기본적으로 지원합니다(브레이브, 오페라). 전통적인 브라우저는 https://ipfs.io와 같은 공용 IPFS 게이트웨이를 통해 IPFS 네트워크에 저장된 파일에 접근하거나 IPFS 동반자 확장을 설치하여 접근할 수 있습니다.
• 차세대 콘텐츠 배포 네트워크 CDN ------ 로컬 노드에 파일을 추가하기만 하면 전 세계가 캐시 친화적인 콘텐츠 해시 주소와 유사 BitTorrent 네트워크 대역폭 배포를 통해 파일을 얻을 수 있습니다.
• 강력한 오픈 소스 커뮤니티를 기반으로 하여 완전한 분산 애플리케이션 및 서비스를 구축하기 위한 개발자 도구 모음

IPFS는 시스템 내에서 파일이 어떻게 저장, 인덱싱 및 전송되는지를 정의하며, 업로드된 파일을 전용 데이터 형식으로 변환하여 저장합니다. 동시에 IPFS는 동일한 파일에 대해 해시 계산을 수행하여 고유한 주소를 결정합니다. 따라서 어떤 장치에서든지, 어떤 장소에서든지 동일한 파일은 동일한 주소를 가리킵니다(이는 URL와 다르며, 이 주소는 암호화 알고리즘에 의해 보장된 원시 주소로, 변경할 수 없고 변경할 필요도 없습니다). 그런 다음 파일 시스템을 통해 네트워크의 모든 장치를 연결하여 IPFS 시스템에 저장된 파일을 전 세계 어디에서나 빠르게 접근할 수 있게 하며, 방화벽의 영향을 받지 않습니다(네트워크 프록시가 필요 없습니다). 따라서 근본적으로 IPFS는 웹 콘텐츠의 배포 메커니즘을 변경하여 탈중앙화를 완성할 수 있습니다.

IPFS 작동 원리

IPFS는 점대점(p2p) 저장 네트워크입니다. 세계 어디에 위치한 노드를 통해 콘텐츠에 접근할 수 있으며, 이러한 노드는 정보를 전달하거나 저장하거나 두 가지 모두를 수행할 수 있습니다. IPFS는 위치가 아닌 콘텐츠 주소를 사용하여 요청한 콘텐츠를 찾는 방법을 알고 있습니다.

IPFS의 세 가지 기본 원칙을 이해합니다:

1. 콘텐츠 주소 지정에 의한 고유 식별
2. 유향 비순환 그래프(DAG)를 통한 콘텐츠 링크
3. 분산 해시 테이블(DHT)을 통한 콘텐츠 발견

이 세 가지 원칙은 서로 의존하며 IPFS 생태계를 구축합니다. 콘텐츠 주소 지정과 콘텐츠의 고유 식별부터 시작해 보겠습니다.

콘텐츠 주소 지정과 콘텐츠의 고유 식별

IPFS는 콘텐츠 주소 지정을 사용하여 콘텐츠를 위치가 아닌 콘텐츠에 따라 식별합니다. 콘텐츠를 기반으로 항목을 찾는 것은 모든 사람이 항상 해왔던 일입니다.

예를 들어, 도서관에서 책을 찾을 때 종종 책 제목으로 찾습니다. 이는 콘텐츠 주소 지정입니다. 왜냐하면 당신이 그것이 무엇인지 묻고 있기 때문입니다.

위치 주소 지정을 사용하여 그 책을 찾으려면, "2층의 책, 세 번째 책장, 네 번째 층에서 왼쪽에서 네 번째 책을 찾고 싶습니다."라고 말해야 합니다.

누군가 그 책을 옮기면, 당신은 불행해질 것입니다!

인터넷과 당신의 컴퓨터에도 이 문제가 존재합니다! 현재 콘텐츠는 위치를 기준으로 검색됩니다. 예를 들어:

• https://en.wikipedia.org/wiki/Aardvark
• /Users/Alice/Documents/term_paper.doc
• C:\Users\Joe\My Documents\project_sprint_presentation.ppt

반면, IPFS 프로토콜을 사용하는 모든 콘텐츠는 콘텐츠 식별자인 CID를 가집니다. 해시는 해당 콘텐츠에 대해 고유하며, 원본 콘텐츠와 비교할 때 짧아 보일 수 있습니다.

많은 분산 시스템이 해시를 통해 콘텐츠 주소 지정을 사용하여 콘텐츠를 식별할 뿐만 아니라 서로 연결합니다. 코드 제출을 지원하는 것부터 암호화폐를 실행하는 블록체인까지 모든 것이 이 전략을 활용합니다. 그러나 이러한 시스템의 기본 데이터 구조는 반드시 상호 운용 가능하지는 않습니다.

CID (콘텐츠 식별자)

CID 규격은 IPFS에서 시작되어 현재 여러 형식으로 존재하며, IPFS, IPLD, libp2p 및 Filecoin을 포함한 광범위한 프로젝트를 지원합니다. 우리는 이 과정에서 IPFS의 몇 가지 예를 공유할 것이지만, 이 튜토리얼은 CID 자체에 대한 분석입니다. 모든 분산 정보 시스템은 이를 콘텐츠를 참조하는 핵심 식별자로 사용합니다.

콘텐츠 식별자 또는 CID는 자기 설명적인 콘텐츠 주소 지정 식별자입니다. 이는 콘텐츠가 어디에 저장되는지를 나타내지 않고, 콘텐츠 자체에 따라 주소를 형성합니다. CID의 문자 수는 기본 콘텐츠의 암호화 해시에 따라 달라지며, 콘텐츠 자체의 크기와는 관계가 없습니다. IPFS의 대부분의 콘텐츠는 해시 sha2-256을 사용하므로, 여러분이 접하는 대부분의 CID는 동일한 크기(256비트, 즉 32바이트)를 가집니다. 이는 특히 여러 콘텐츠를 처리할 때 관리하기 쉽게 만듭니다.

예를 들어, IPFS 네트워크에 아르다바크의 이미지를 저장했다면, 그 CID는 다음과 같습니다: QmcRD4wkPPi6dig81r5sLj9Zm1gDCL4zgpEj9CfuRrGbzF

이전에 시연된 유니스왑의 IPFS 링크:

CID를 생성하는 첫 번째 단계는 입력 데이터를 변환하여 암호화 알고리즘을 사용하여 임의 크기의 입력(데이터 또는 파일)을 고정 크기의 출력으로 매핑하는 것입니다. 이 변환을 해시 디지털 지문 또는 간단히 해시라고 합니다(기본적으로 sha2-256 사용).

사용되는 암호화 알고리즘은 다음과 같은 특성을 가진 해시 값을 생성해야 합니다:

• 결정성: 동일한 입력은 항상 동일한 해시를 생성해야 합니다.
• 비관련성: 입력 데이터의 작은 변화는 완전히 다른 해시를 생성해야 합니다.
• 단방향성: 해시 값에서 입력 데이터를 역추적하는 것은 불가능합니다.
• 고유성: 특정 해시를 생성할 수 있는 파일은 하나뿐입니다.

토끼 이미지의 단일 픽셀을 변경하면 암호화 알고리즘은 이미지에 대해 완전히 다른 해시를 생성합니다.

콘텐츠 주소를 사용하여 데이터를 가져올 때, 우리는 해당 데이터의 예상 버전을 볼 수 있다는 것을 보장할 수 있습니다. 이는 전통적인 웹에서 위치 주소 지정과는 완전히 다릅니다. 전통적인 웹에서는 주어진 주소(URL)의 콘텐츠가 시간이 지남에 따라 변경될 수 있습니다.

CID의 구조

Multiformats

Multiformats는 IPFS 시스템에서 주로 신원의 암호화와 데이터의 자기 설명을 담당합니다.

Multiformats는 미래의 안전한 시스템을 위한 프로토콜 집합으로, 자기 설명 형식은 시스템 간의 협력과 업그레이드를 가능하게 합니다.

Multiformats 프로토콜에는 다음과 같은 프로토콜이 포함됩니다:

multihash - 자기 설명 해시

multiaddr - 자기 설명 네트워크 주소

multibase - 자기 설명 기본 인코딩

multicodec - 자기 설명 직렬화

multistream - 자기 설명 스트림 네트워크 프로토콜

multigram (WIP) - 자기 설명 패킷 네트워크 프로토콜

콘텐츠 링크 유향 비순환 그래프(DAG)

Merkle DAG는 CID의 배포 가능성을 상속합니다. DAG에 콘텐츠 주소 지정을 사용하면 배포에 몇 가지 흥미로운 영향을 미칩니다. 첫째, 물론 DAG를 소유한 사람은 누구나 해당 DAG의 제공자가 될 수 있습니다. 둘째, DAG로 인코딩된 데이터를 검색할 때, 예를 들어 파일 디렉토리와 같은 경우, 우리는 이 사실을 활용하여 노드의 모든 하위 노드를 병렬로 검색할 수 있으며, 이는 여러 다른 제공자로부터 올 수 있습니다!

셋째, 파일 서버는 중앙 집중식 데이터 센터에 국한되지 않으므로 우리의 데이터 범위가 더 넓어집니다. 마지막으로, DAG의 각 노드는 고유한 CID를 가지므로, 그것이 나타내는 DAG는 그것 자체가 포함된 어떤 DAG와도 독립적으로 공유되고 검색될 수 있습니다.

검증 가능성

파일을 백업한 후 몇 달 후에 이 두 파일이나 디렉토리를 찾아 그 내용이 동일한지 궁금해 본 적이 있습니까? 각 백업에 대해 Merkle DAG를 계산할 수 있으며, 파일을 비교하는 데 수고를 들이지 않아도 됩니다: 루트 디렉토리의 CID가 일치하면 어떤 것을 안전하게 삭제할 수 있는지 알 수 있으며, 하드 드라이브의 일부 공간을 확보할 수 있습니다!

배포 가능성

예를 들어, 대규모 데이터의 배포. 전통적인 웹 네트워크에서는:

• 공유 파일의 개발자가 서버 및 관련 비용을 유지해야 합니다.
• 동일한 서버가 전 세계의 요청에 응답하는 데 사용될 가능성이 높습니다.
• 데이터 자체는 단일 파일 아카이브로 단편적으로 배포될 수 있습니다.
• 동일한 데이터의 대체 공급자를 찾기가 어렵습니다.
• 데이터는 대량으로 존재할 수 있으며, 단일 공급자로부터 직렬로 다운로드해야 합니다.
• 다른 사람들이 데이터를 공유하기가 어렵습니다.

Merkle DAG는 이러한 모든 문제를 완화하는 데 도움을 줍니다. 데이터를 콘텐츠 주소 지정 DAG로 변환함으로써:

• 원하는 사람은 누구나 파일을 송수신하는 데 도움을 줄 수 있습니다.
• 전 세계의 노드가 데이터 서비스를 제공하는 데 참여할 수 있습니다.
• DAG의 각 부분은 고유한 CID를 가지며 독립적으로 배포할 수 있습니다.
• 동일한 데이터의 대체 공급자를 찾기가 쉽습니다.
• DAG를 구성하는 노드는 작아 여러 다른 공급자로부터 병렬로 다운로드할 수 있습니다.

이 모든 것은 중요한 데이터의 확장성에 기여합니다.

중복 데이터 제거

예를 들어, 웹 페이지를 탐색하는 경우! 사용자가 브라우저를 사용하여 웹 페이지에 접근할 때, 브라우저는 먼저 해당 페이지와 관련된 리소스(이미지, 텍스트 및 스타일)를 다운로드해야 합니다. 사실 많은 웹 페이지는 매우 유사하게 보이며, 단지 동일한 테마를 사용하고 약간의 변화만 있을 뿐입니다. 여기서 많은 중복이 발생합니다.

브라우저가 충분히 최적화되면, 해당 구성 요소를 여러 번 다운로드하는 것을 피할 수 있습니다. 사용자가 새 웹사이트에 접근할 때마다, 브라우저는 DAG에서 서로 다른 부분에 해당하는 노드만 다운로드하면 되며, 이전에 다운로드한 다른 부분은 다시 다운로드할 필요가 없습니다!(WordPress 테마, Bootstrap CSS 라이브러리 또는 일반적인 JavaScript 라이브러리를 생각해 보세요.)

분산 해시 테이블(DHT)

분산 해시 테이블(DHT)은 키를 값에 매핑하는 분산 시스템입니다. IPFS에서 DHT는 콘텐츠 라우팅 시스템의 기본 구성 요소로 사용되며, 디렉토리와 탐색 시스템 간의 교차점 역할을 합니다. 사용자가 찾고 있는 콘텐츠를 저장하는 피어 노드에 매핑합니다. 이를 거대한 표로 생각할 수 있으며, 누가 어떤 데이터를 소유하고 있는지를 저장합니다.

Libp2p

libp2p는 모듈화된 네트워크 스택으로, IPFS에서 독립적인 프로젝트로 발전했습니다. 폴카도 사용하고 있으며, eth2.0도 일부 사용하고 있습니다.

libp2p가 탈중앙화 네트워크에서 이렇게 중요한 부분인 이유를 설명하기 위해, 우리는 한 걸음 물러서서 그 출처를 이해할 필요가 있습니다. libp2p의 초기 구현은 IPFS에서 시작되었으며, 이는 점대점 파일 공유 시스템입니다. IPFS가 해결하고자 하는 네트워크 문제를 탐구하는 것부터 시작해 보겠습니다.

네트워크

네트워크는 매우 복잡한 시스템으로, 자체 규칙과 제한이 있으므로 이러한 시스템을 설계할 때 많은 상황과 사용 사례를 고려해야 합니다:

• 방화벽: 여러분의 노트북에는 특정 연결을 차단하거나 제한하는 방화벽이 설치되어 있을 수 있습니다.
• NAT: 여러분의 가정 WiFi 라우터는 NAT(네트워크 주소 변환)를 통해 노트북의 로컬 IP 주소를 외부 네트워크가 연결할 수 있는 단일 IP 주소로 변환합니다.
• 고지연 네트워크: 이러한 네트워크는 연결 속도가 매우 느려 사용자가 콘텐츠를 보기 위해 오랜 시간을 기다려야 합니다.
• 신뢰성: 전 세계에 분산된 많은 네트워크가 있으며, 많은 사용자가 느린 네트워크를 자주 경험합니다. 이러한 네트워크는 사용자에게 양질의 연결을 제공하기 위한 강력한 시스템이 없습니다. 연결이 자주 끊기고, 사용자의 네트워크 시스템 품질이 좋지 않아 사용자에게 필요한 서비스를 제공하지 못합니다.
• 로밍: 이동 주소 지정은 또 다른 상황으로, 사용자의 장치가 전 세계의 다양한 네트워크를 탐색할 때 고유한 발견 가능성을 유지해야 합니다. 현재 이들은 많은 조정 지점과 연결이 필요한 분산 시스템에서 작동하지만, 최선의 해결책은 탈중앙화입니다.
• 검열: 현재의 네트워크 상태에서 정부 기관이라면 특정 웹사이트 도메인에서 웹사이트를 차단하는 것이 상대적으로 쉽습니다. 이는 불법 활동을 차단하는 데 유용하지만, 독재 정권이 인구의 자원 접근을 차단하고자 할 때 문제가 됩니다.
• 다양한 속성을 가진 런타임: IoT(사물인터넷) 장치(예: Raspberry Pi, Arduino 등)와 같은 여러 유형의 런타임이 있으며, 이들은 많은 채택을 받고 있습니다. 이들은 제한된 자원으로 구축되기 때문에, 이들의 런타임은 종종 서로 다른 프로토콜을 사용하며, 이들 프로토콜은 이들의 런타임에 대해 많은 가정을 합니다.
• 혁신이 매우 느림: 많은 자원을 가진 가장 성공적인 기업조차도 새로운 프로토콜을 개발하고 배포하는 데 수십 년이 걸릴 수 있습니다.
• 데이터 프라이버시: 소비자들은 최근 사용자 프라이버시를 존중하지 않는 기업에 대해 점점 더 우려하고 있습니다.

P2P 프로토콜의 현재 문제

점대점(P2P) 네트워크는 인터넷 개념에서 탄생하여, 피어 노드가 중대한 자연재해나 인위적 재난으로 인해 네트워크와 연결이 끊겨도 정상적으로 작동하는 탄력적인 네트워크를 만드는 방법으로 구상되었습니다. 이를 통해 사람들은 계속해서 통신할 수 있습니다.

P2P 네트워크는 비디오 통화(예: Skype)에서 파일 공유(예: IPFS, Gnutella, KaZaA, eMule 및 BitTorrent)까지 다양한 사용 사례에 활용될 수 있습니다.

기본 개념

Peer - 탈중앙화 네트워크의 참여자. 피어 노드는 애플리케이션에서 동등한 권한과 능력을 가진 참여자입니다. IPFS에서 노트북에서 IPFS 데스크탑 애플리케이션을 로드하면, 여러분의 장치는 탈중앙화 네트워크 IPFS의 피어 노드가 됩니다.

Peer-to-Peer (P2P) - 분산 네트워크로, 작업 부하가 피어 노드 간에 공유됩니다. 따라서 IPFS에서 각 피어 노드는 다른 피어 노드와 공유할 전체 또는 일부 파일을 호스팅할 수 있습니다. 한 노드가 파일을 요청하면, 해당 파일 블록을 가진 모든 노드가 요청된 파일을 전송하는 데 참여할 수 있습니다. 그런 다음 요청 데이터를 요청한 노드는 나중에 다른 노드와 데이터를 공유할 수 있습니다.

IPFS는 현재와 과거의 네트워크 애플리케이션 및 연구에서 영감을 얻어 P2P 시스템을 개선하려고 합니다. 학계에는 이러한 문제를 해결하는 방법에 대한 많은 과학 논문이 있으며, 연구는 초기 결과를 생성했지만, 사용하고 조정할 수 있는 코드 구현이 부족합니다.

기존 P2P 시스템의 코드 구현은 정말 찾기 어렵고, 실제로 존재하는 경우에도 다음과 같은 이유로 재사용하거나 조정하기 어려운 경우가 많습니다:

• 파일이 불완전하거나 존재하지 않음
• 제한적인 라이센스 또는 라이센스를 찾을 수 없음
• 10년 이상 업데이트되지 않은 매우 오래된 코드
• 연락 지점이 없음(연락할 수 있는 유지 관리자가 없음)
• 클로즈드 소스(비공개) 코드
• 단종된 제품
• 사양이 제공되지 않음
• 사용자 친화적인 API가 노출되지 않음
• 특정 사용 사례와의 결합이 너무 밀접함
• 향후 프로토콜 업그레이드를 사용할 수 없음

더 나은 방법이 있어야 합니다. 주요 문제는 상호 운용성이라는 것을 알고 있는 IPFS 팀은 모든 현재 솔루션을 통합하고 혁신을 촉진하는 플랫폼을 제공하는 더 나은 방법을 구상했습니다. 미래의 솔루션이 네트워크 스택에 원활하게 통합될 수 있는 새로운 모듈화 시스템입니다.

libp2p는 IPFS의 네트워크 스택이지만, IPFS에서 분리되어 독립적인 일류 프로젝트와 IPFS의 의존 프로젝트가 되었습니다.

이런 방식으로 libp2p는 IPFS에 의존하지 않고도 발전할 수 있으며, 자체 생태계와 커뮤니티를 얻을 수 있습니다. IPFS는 libp2p의 많은 사용자 중 하나일 뿐입니다.

이렇게 하면 각 프로젝트는 자신의 목표에만 집중할 수 있습니다:

IPFS는 콘텐츠 주소 지정, 즉 네트워크에서 어떤 콘텐츠를 찾고, 가져오고, 검증하는 데 더 집중합니다.
libp2p는 프로세스 주소 지정, 즉 네트워크에서 어떤 데이터 전송 프로세스를 찾고, 연결하고, 검증하는 데 더 중점을 둡니다. 그렇다면 libp2p는 어떻게 이를 수행할까요?

답은: 모듈화입니다.

libp2p는 네트워크 스택을 구성할 수 있는 특정 부분을 식별했습니다:

다양한 언어 구현을 지원하며, 7가지 개발 언어를 지원하는 libp2p의 JavaScript 구현은 브라우저와 모바일 브라우저에서도 사용할 수 있습니다! 이는 애플리케이션이 데스크탑과 모바일 장치에서 libp2p를 실행할 수 있게 해주기 때문에 매우 중요합니다.

애플리케이션에는 파일 저장, 비디오 스트리밍, 암호화 지갑, 개발 도구 및 블록체인이 포함됩니다. 블록체인 최상위 프로젝트는 이미 IPFS의 libp2p 모듈을 채택하고 있습니다.

IPLD

IPLD는 데이터를 이해하고 처리하는 데 사용됩니다.

IPLD는 기존의 이종 데이터 구조를 통일된 형식으로 변환하는 미들웨어로, 서로 다른 시스템 간의 데이터 교환과 상호 운용을 용이하게 하며, 데이터 모델과 디코딩을 CID를 링크로 사용합니다.

먼저, 우리는 "데이터 모델"을 정의하며, 이는 데이터의 도메인과 범위를 설명합니다. 이는 우리가 구축할 모든 것의 기초가 되기 때문에 중요합니다. (광의적으로 말하자면, 데이터 모델은 "JSON과 비슷하다"고 할 수 있으며, map, string, list 등을 포함합니다.) 이후, 우리는 "코덱"을 정의하며, 이는 메시지에서 이를 파싱하고 우리가 원하는 메시지 형식으로 발신하는 방법을 설명합니다. IPLD에는 많은 코덱이 있습니다. 여러분은 다른 애플리케이션과 상호 작용하고자 하는 경우에 따라 서로 다른 코덱을 선택하거나, 단순히 자신의 애플리케이션에서 성능과 인간 가독성의 적합성을 고려하여 서로 다른 코덱을 선택할 수 있습니다.

IPLD는 가장 상위의 세 가지 프로토콜을 구현합니다: 객체, 파일, 명명.

• 객체 계층 - IPFS의 데이터는 Merkle Directed Acyclic Graph(Merkle DAG) 구조로 조직되며, 노드는 객체라고 하며, 데이터 또는 다른 객체에 대한 링크를 포함할 수 있습니다. 링크는 소스에 내장된 대상 데이터의 암호화 해시입니다. 이러한 데이터 구조는 콘텐츠 주소 지정, 데이터 변조 방지, 중복 데이터 제거 등과 같은 많은 유용한 속성을 제공합니다.
• 파일 계층 - Merkle DAG 위에 Git과 유사한 버전 관리 시스템을 모델링하기 위해, IPFS는 다음과 같은 객체를 정의합니다:
• blob 데이터 블록: blob은 가변 크기의 데이터 블록(링크 없음)으로, 데이터 블록을 나타냅니다.
• list: blob 또는 다른 lists를 순서대로 조직하는 데 사용되며, 일반적으로 파일을 나타냅니다.
• tree: 디렉토리를 나타내며 blobs, lists 및 다른 trees를 포함합니다.
• commit: Git의 커밋과 유사하며, 객체의 버전 기록에서 스냅샷을 나타냅니다.
• 명명 계층 - 객체의 각 변경은 해시 값을 변경하므로 해시 값을 매핑할 필요가 있습니다. IPNS(Inter Planetary Naming System)는 각 사용자에게 가변 명명 공간을 할당하며, 사용자의 개인 키로 서명된 경로에 객체를 게시하여 객체의 진위를 검증할 수 있습니다. 이는 URL과 유사합니다.

IPLD의 표현:

IPFS는 위의 모듈 기능을 적용하여 독립 노드에서 실행되는 컨테이너화된 애플리케이션으로 통합되어, 웹 서비스 형태로 제공됩니다. IPFS는 네트워크의 참여자들이 서로 검증 가능한 데이터를 저장하고 요청하며 전송할 수 있게 합니다. 그러나 IPFS는 오픈 소스이므로 무료로 다운로드하고 사용할 수 있으며, 이미 많은 팀에서 사용하고 있습니다.

Filecoin

IPFS 및 기술의 각 노드는 그들이 중요하다고 생각하는 데이터를 저장할 수 있습니다; 하지만 간단한 방법이 없고, 다른 사람들이 네트워크에 참여하거나 데이터를 저장하도록 유도할 수 없다면, IPFS의 확산은 어려워집니다. 이때 Filecoin이 필요하게 되었고, IPFS의 인센티브 레이어로서 증권화되었습니다.

Filecoin은 IPFS에 인센티브 저장을 추가합니다. IPFS 사용자는 Filecoin에 데이터를 직접 신뢰할 수 있게 저장할 수 있으며, 이를 통해 네트워크에 많은 애플리케이션과 실제 사용 사례의 문을 열 수 있습니다.