IPFS란 무엇입니까: 완전한 행성 간 파일 시스템 가이드(2026)

매일 사용하는 인터넷은 간단한 약속에 따라 실행됩니다. 브라우저에 주소를 입력하면 전 세계 어딘가에 있는 특정 서버가 파일을 다시 보냅니다. 이 모델은 30년 동안 웹을 강화해 왔지만 결정적인 약점이 있습니다. 파일은 한 곳에 있습니다. 해당 서버가 다운되거나, 검열을 받거나, 단순히 도메인 갱신을 잊어버린 경우 콘텐츠는 영원히 사라집니다. 는 행성 간 파일 시스템 IPFS로 더 잘 알려진 은 인터넷에서 파일이 주소 지정되고 공유되는 방식을 재구성하여 이 문제를 정확하게 해결하기 위해 구축되었습니다.

IPFS는 단일 회사가 아닙니다. 블록체인또는 전통적인 의미의 클라우드 스토리지 서비스입니다. 위치 기반 주소 지정 대신 콘텐츠 기반 주소 지정을 사용하여 누구나 파일을 저장하고 제공할 수 있는 P2P 프로토콜입니다. IPFS를 사용하면 "이 서버에 있는 파일을 주세요"라고 묻는 대신 "이 지문이 포함된 파일을 주세요"라고 물으면 해당 파일이 있는 네트워크의 모든 노드가 응답할 수 있습니다. 이러한 미묘한 변화는 영구 링크, 검열 저항, 프로토콜 수준의 중복 제거, 오프라인 운영, 웹3 중앙 집중식 호스팅에 의존하지 않는 애플리케이션.

이 전체 가이드에서는 IPFS가 실제로 무엇인지, IPFS가 무엇인지, 컨텐츠 주소 지정이 내부적으로 어떻게 작동하는지 배우게 됩니다. CID 식별자, 이유 NFT 메타데이터, 고정 서비스 환경, IPFS 게이트웨이가 네트워크를 조용히 중앙집중화하는 방법, 새로운 Helia js-ipfs를 대체한 구현 및 IPFS가 함께 적합한 구현 파일코인. 결국에는 첫 번째 파일을 업로드하고, 고정 제공자를 평가하고, 대부분의 기사에서 언급되지 않은 문제를 발견할 수 있을 만큼 IPFS를 깊이 이해하게 될 것입니다.

IPFS란 과연 무엇일까요?

IPFS(InterPlanetary File System)는 웹을 더 빠르고 탄력적이며 개방적으로 만들기 위해 설계된 오픈 소스 P2P 프로토콜입니다. 이는 나중에 Filecoin을 출시한 조직인 Protocol Labs를 통해 2014년 Juan Benet에 의해 만들어졌습니다. 기본적으로 IPFS는 HTTP의 위치 기반 주소 지정을 콘텐츠 기반 주소 지정으로 대체하고 중앙 기관에 의존하지 않고 콘텐츠를 저장하고 검색할 수 있는 분산형 노드 네트워크를 구축합니다.

여기에 중요한 정신적 변화가 있습니다. HTTP를 통해 웹사이트를 방문하면 브라우저는 특정 서버에 특정 경로를 요청합니다. URL https://example.com/photo.jpg 은 브라우저에 무엇을 얻을 것이 아니라 어디로 가야할지 알려줍니다. IPFS를 사용하면 파일을 요청합니다. CID, 파일 내용의 암호화 해시입니다. 네트워크는 파일이 있는 피어를 찾아서 사용자에게 제공합니다. 주소는 내용 그 자체입니다.

한 가지 중요한 점: 프로토콜은 실제로 자체적으로 아무것도 저장하지 않습니다. IPFS는 주소 지정 및 라우팅 시스템입니다. 파일은 파일을 호스팅하도록 선택한 노드에 있습니다. 특정 CID를 호스팅하는 노드가 없으면 주소가 영원히 유효하더라도 해당 콘텐츠는 더 이상 네트워크에 존재하지 않습니다. 이것이 고정 서비스가 존재하는 이유이며, 고정하지 않고 NFT 이미지를 IPFS에 업로드하는 것이 가장 흔한 실수 중 하나인 이유입니다. NFT 프로젝트.

콘텐츠 주소 지정: 핵심 아이디어

콘텐츠 주소 지정은 IPFS에서 가장 중요한 개념입니다. 파일이 있는 위치로 파일을 식별하는 대신 파일이 무엇인지로 식별합니다. IPFS에 추가된 모든 파일은 암호화를 통해 실행됩니다. 해싱 알고리즘, 일반적으로 SHA-256은 해당 파일에 고유한 고정 길이 다이제스트를 생성합니다. 파일의 한 비트를 변경하면 해시가 완전히 변경됩니다. 이 해시는 네트워크의 영구 주소인 파일 CID의 기초가 됩니다.

이것의 의미는 엄청납니다. 전 세계 어디에서나 두 개의 동일한 파일은 동일한 CID를 갖게 됩니다. 이는 IPFS가 자동으로 콘텐츠를 중복 제거한다는 것을 의미합니다. 백만 명의 사람들이 동일한 고양이 사진을 업로드하는 경우 네트워크에는 사본 하나만 필요합니다. CID는 HTTPS URL과 달리 변조 방지 기능도 갖추고 있습니다. 가져올 때 /ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi, 귀하가 수신하는 콘텐츠는 정확한 CID로 해시되어야 합니다. 그렇지 않으면 IPFS 클라이언트가 이를 거부합니다. 악의적인 노드가 동일한 주소로 수정된 콘텐츠를 제공할 수 있는 방법은 없습니다.

대용량 파일은 단일 blob으로 해시되지 않습니다. IPFS는 이를 더 작은 청크(일반적으로 각각 256KB)로 분할하고 각 청크를 해시한 다음 각 노드가 해시를 통해 하위 노드를 참조하는 Merkle 방향성 비순환 그래프(DAG)를 구축합니다. 반환되는 CID는 파일의 모든 청크에 전이적으로 커밋되는 루트 노드의 해시입니다. 이 구조를 dag-pb IPFS 세계에서는 레거시 기본값입니다. 최신 콘텐츠 사용 ipld (InterPlanetary Linked Data)는 JSON, CBOR 및 기타 인코딩을 지원하는 보다 유연한 데이터 모델입니다.

CID v0과 CID v1: 차이점은 무엇입니까?

IPFS에 무언가를 업로드한 적이 있다면 아마도 매우 다르게 보이는 두 개의 CID를 본 적이 있을 것입니다. 오래된 스타일은 다음과 같이 시작됩니다. Qm 그리고 다음과 같습니다 QmYwAPJzv5CZsnA625s3Xf2nemtYgPpHdWEz79ojWnPbdG. 새로운 스타일은 다음과 같이 시작됩니다. b 그리고 다음과 같습니다 bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi. 이는 각각 CID v0 및 CID v1을 나타내며 프로덕션에서는 그 차이가 중요합니다.

CID v0이 원본 형식입니다. 항상 Qm으로 시작하는 dag-pb 인코딩 콘텐츠의 SHA-256 해시, base58 인코딩입니다. 짧고 알아볼 수 있지만 단단하기도 합니다. 다양한 해시 함수, 다양한 인코딩 또는 다양한 기반을 위한 여지가 없습니다. CID v1은 현대적이고 유연한 형식입니다. 버전, 코덱, 코덱을 명시적으로 인코딩하는 자체 설명적 식별자입니다. multihash 함수 사용 및 기본 인코딩. 이는 CID v1이 SHA-256 dag-pb를 나타낼 수 있지만 BLAKE3 IPLD, 원시 바이트 또는 프로토콜이 지원하는 모든 것을 나타낼 수도 있음을 의미합니다.

현재 CID v1을 선호하는 가장 큰 실질적인 이유는 하위 도메인 게이트웨이 지원입니다. 최신 IPFS 게이트웨이는 다음과 같은 URL의 콘텐츠를 제공합니다. https://bafybei...ipfs.dweb.link, 각 CID에 고유한 브라우저 출처를 제공합니다. 이러한 원본 격리는 보안(쿠키, 로컬 저장소, 서비스 작업자)에 필수적이며 CID v1인 대소문자를 구분하지 않는 base32 인코딩에서만 작동합니다. 2026년에 게시하는 경우 특별한 이유가 없는 한 기본적으로 CID v1을 사용하세요.

libp2p: 네트워킹 계층 아래

IPFS는 다음과 같은 모듈식 네트워킹 스택 위에 구축되었습니다. libp2p. 이는 Protocol Labs에서 나오는 가장 중요한 인프라 중 하나이며 Ethereum 2.0, Polkadot 및 다양한 Web3 프로토콜을 포함하여 IPFS 이외의 다른 많은 프로젝트에서 사용됩니다. libp2p는 피어 검색, 연결 관리, NAT 통과, 전송 암호화, 멀티플렉싱 및 스트림 프로토콜 등 전통적으로 네트워크 스택이 필요한 모든 것을 처리합니다. IPFS와 같은 상위 수준 프로토콜이 자체 논리에 집중할 수 있도록 P2P 네트워킹의 지저분한 현실을 추상화합니다.

libp2p의 피어는 고유한 식별자로 식별됩니다. PeerID, 이는 그 자체가 피어 공개 키의 해시입니다. 이는 피어 ID가 암호화되고 자체 주권적이며 주소가 작동하는 방식과 매우 유사하다는 것을 의미합니다. 암호화폐 지갑. 피어는 Kademlia를 기반으로 하는 분산 해시 테이블(DHT)을 통해 서로를 찾습니다. 이를 통해 네트워크는 중앙 디렉터리 없이 콘텐츠 요청을 효율적으로 라우팅할 수 있습니다. CID를 요청하면 노드는 DHT에 쿼리하여 자신이 CID를 가지고 있다고 광고하는 피어를 찾은 다음 해당 피어에 직접 연결하여 콘텐츠를 다운로드합니다.

libp2p는 TCP, QUIC, WebSockets 및 WebRTC를 포함한 여러 전송을 지원합니다. 브라우저는 원시 TCP 연결을 열 수 없기 때문에 WebRTC는 IPFS가 브라우저에서 작동하도록 만드는 것입니다. 이러한 유연성을 통해 IPFS는 임베디드 장치부터 브라우저 탭, 프로덕션 서버에 이르기까지 모두 동일한 프로토콜을 사용하는 모든 장치에서 실행될 수 있습니다.

콘텐츠 검색 작동 방식: Bitswap

IPFS 피어 간에 바이트를 이동하는 실제 메커니즘은 다음과 같습니다. bitswap. 이는 강력한 아이디어를 지닌 상대적으로 간단한 프로토콜입니다. 각 피어는 찾고 있는 CID의 "원하는 목록"과 제공할 수 있는 CID의 "갖고 있는 목록"을 유지 관리합니다. 두 피어가 연결되면 이 목록을 교환하고, 한 피어가 다른 피어가 원하는 블록을 받을 때마다 이를 전송합니다.

CID를 요청하면 IPFS 노드는 먼저 로컬 캐시를 확인합니다. 콘텐츠가 있으면 즉시 얻을 수 있습니다. 그렇지 않은 경우 노드는 DHT에 쿼리하여 CID를 광고한 피어를 찾고 libp2p를 통해 피어에 연결한 다음 비트스왑을 사용하여 블록을 다운로드합니다. 여러 블록에 걸쳐 분할된 대용량 파일의 경우 노드는 여러 피어에서 여러 블록을 병렬로 가져올 수 있으므로 성능이 향상되고 개별 피어 오류에 대한 네트워크의 복원력이 향상됩니다.

비트스왑에는 기본적으로 금전적 인센티브가 내장되어 있지 않습니다. 피어는 원하기 때문에 또는 IPFS 위에서 실행되는 서비스에서 비용을 지불했기 때문에 콘텐츠를 제공합니다. 이는 IPFS와 Filecoin의 주요 차이점 중 하나이며 나중에 자세히 설명하겠습니다. Bitswap에는 지불 개념이 없습니다. 이는 순수한 최선의 P2P 교환입니다.

고정: 이것이 중요한 이유와 이를 수행하는 사람

IPFS에 대해 가장 오해되는 부분이 있습니다. IPFS에 파일을 업로드했는데 아무도 고정하지 않으면 해당 파일은 결국 사라집니다. IPFS 노드는 캐시 공간이 제한되어 있으며 아무도 적극적으로 보관하지 않는 오래된 콘텐츠를 정기적으로 가비지 수집합니다. CID는 유효한 상태로 유지되며 프로토콜은 누군가 제공하는 경우 해당 콘텐츠를 찾는 방법을 여전히 알고 있지만 실제 바이트는 사라졌습니다. 고정은 IPFS 노드에 "무슨 일이 있어도 이 콘텐츠를 삭제하지 마십시오"라고 알리는 행위입니다.

콘텐츠를 자신의 노드에 고정할 수 있는데, 이는 개인 프로젝트에는 적합하지만 프로덕션 환경에서는 거의 항상 고정 서비스에 의존합니다. 이들은 강력한 IPFS 인프라를 운영하고 귀하가 비용을 지불하는 한 CID를 계속 사용할 수 있도록 보장하는 회사입니다. 2026년의 고정 서비스 환경은 성숙하고 경쟁적이며 다양한 사용 사례를 제공하는 몇 가지 견고한 옵션이 있습니다.

고정 서비스 선택은 우선순위에 따라 다릅니다. 견고한 가동 시간과 우수한 개발자 인체공학이 필요한 경우 Pinata가 안전한 기본값입니다. Filecoin 거래가 포함된 장기적인 내구성을 원한다면 Storacha는 이를 위해 특별히 제작되었습니다. dApp 프런트엔드를 배포하는 경우 Fleek의 Git 통합을 통해 CI 설정 시간이 절약됩니다. 소규모 프로젝트를 실행 중이고 반복 지출을 0으로 원한다면 모니터링이 뛰어난 자체 호스팅 Kubo 노드가 완벽하게 실행 가능합니다.

IPFS 게이트웨이와 중앙화 문제

IPFS가 P2P 프로토콜인 경우 브라우저는 어떻게 로드됩니까? /ipfs/CID URL? 적어도 기본적으로는 그렇지 않습니다. 주류 브라우저는 IPFS 프로토콜을 사용하지 않습니다. 일반 웹을 통해 IPFS 콘텐츠에 액세스할 수 있도록 하기 위해 커뮤니티는 게이트웨이, 즉 IPFS 네트워크와 일반 브라우저 사이의 브리지 역할을 하는 HTTP 서버를 구축했습니다. 당신이 요청 https://ipfs.io/ipfs/bafybei..., 게이트웨이는 IPFS 네트워크에서 콘텐츠를 가져와 HTTPS를 통해 다시 제공합니다.

게이트웨이는 매우 유용하지만 IPFS 마케팅 자료에서 종종 간과되는 조용한 중앙 집중화 문제를 야기합니다. 두 개의 주요 게이트웨이인 ipfs.io(Protocol Labs에서 운영)와 cloudflare-ipfs.com(Cloudflare에서 운영)은 전체 IPFS 트래픽의 상당 부분을 처리합니다. 대부분의 NFT 마켓플레이스, dApp 및 교육 사이트가 이러한 게이트웨이를 사용하여 IPFS 콘텐츠를 제공하면 프로토콜의 분산 스토리가 약해집니다. Cloudflare가 CID를 차단하거나 ipfs.io가 중단되면 실제 IPFS 클라이언트를 설치한 적이 없는 사용자는 "분산형" 콘텐츠의 상당 부분을 일시적으로 접근할 수 없게 됩니다.

완화 방법은 잘 알려져 있지만 제대로 사용되지 않습니다. 먼저, 여러 게이트웨이를 통해 콘텐츠에 연결하거나 대체 게이트웨이 목록을 사용하면 단일 운영자가 다운되어 사이트가 중단되지 않습니다. 둘째, 다음과 같은 하위 도메인 게이트웨이를 선호합니다. https://CID.ipfs.dweb.link 경로 게이트웨이를 통해, 각 콘텐츠 조각을 자체 브라우저 원본에서 격리하기 때문입니다. 셋째, 실제 검열 저항이 필요한 사용자가 자체 노드를 실행하거나 IPFS가 내장된 Brave를 사용하도록 권장합니다. 넷째, 장기적인 복원력을 고려하는 프로젝트는 공개 게이트웨이를 사용하는 것 외에도 자체 게이트웨이를 실행해야 합니다.

Helia 대 Kubo: 최신 IPFS 스택

대부분의 IPFS 역사에서 두 가지 주요 구현이 있었습니다. Kubo (원래 go-ipfs라고 함), Go로 작성된 참조 구현 및 JavaScript 구현인 js-ipfs. Kubo는 데몬으로 실행되며 고정 서비스 및 게이트웨이를 포함하여 대부분의 프로덕션 IPFS 인프라를 지원합니다. 성숙하고 성능이 뛰어나며 전투 테스트를 거쳤습니다.

js-ipfs를 사용하면 브라우저와 Node.js 앱에서 IPFS를 실행할 수 있지만 레거시 코드가 많이 포함되어 유지 관리가 어려웠습니다. 2023년, 프로토콜 랩스는 전환을 시작했습니다. Helia, 더 간결하고 모듈화된 아키텍처를 사용한 새로운 구현입니다. 2025년까지 js-ipfs는 더 이상 사용되지 않으며 Helia는 JavaScript 프로젝트에 권장되는 선택이 되었습니다. 2026년에는 Helia와 함께 새로운 것을 시작해 보세요.

Helia는 즉시 교체가 아닙니다. API는 다르고 종속성 그래프는 더 작으며 철학은 "자신만의 부분을 가져오세요"입니다. 자신만의 블록스토어, 데이터스토어 및 라우팅을 선택하고 이를 Helia에 연결하면 작업 노드가 있습니다. 이로 인해 Helia를 최신 스택에 훨씬 쉽게 포함할 수 있습니다. js-ipfs 프로젝트에 대한 마이그레이션 가이드가 있습니다.

IPFS와 HTTP: 나란히 비교

IPFS를 이해하는 가장 유용한 방법은 IPFS를 기반으로 구축되고 부분적으로 대체되는 프로토콜인 HTTP와 직접 비교하는 것입니다. 그들은 적이 아니며 대부분의 프로덕션 IPFS 사용 사례에는 스택 어딘가에 HTTP가 포함되어 있지만 디자인 철학은 매우 다릅니다.

2026년의 현실적인 결론은 IPFS와 HTTP가 경쟁하기보다는 공존한다는 것입니다. HTTP는 동적 콘텐츠, 세션 및 처리량이 높은 애플리케이션에 탁월합니다. IPFS는 무결성과 복원력이 밀리초 지연 시간보다 중요한 정적, 주소 지정 가능, 수명이 긴 콘텐츠에 탁월합니다. 대부분의 프로덕션 스택은 동적 계층(API, 사용자 인증)에 HTTP를 사용하고 불변 계층(이미지, NFT 메타데이터, dApp 프런트엔드)에 IPFS를 사용합니다.

IPFS 대 Filecoin: 관계 명확화

IPFS와 Filecoin 사이에는 지속적인 혼란이 있습니다. 부분적으로 둘 다 Protocol Labs에서 만들었기 때문이고 부분적으로는 마케팅 자료가 때때로 경계를 모호하게 만들기 때문입니다. 깨끗한 버전은 다음과 같습니다. IPFS는 콘텐츠 주소 지정 및 이동을 위한 프로토콜입니다. Filecoin은 보장된 기간 동안 콘텐츠를 호스팅하기 위해 노드에 비용을 지불하는 블록체인 기반 스토리지 시장입니다. 그것들은 상호 보완적이며 상호 교환 가능하지 않습니다.

IPFS에는 경제적 계층이 없습니다. 노드는 선의로 콘텐츠를 제공하거나 프로토콜 위에서 실행되는 일부 서비스에서 비용을 지불했기 때문에 콘텐츠를 제공합니다. CID가 계속 사용 가능하다는 기본 보장은 없습니다. Filecoin은 스토리지 제공업체가 특정 콘텐츠를 특정 기간 동안 사용할 수 있도록 유지하기 위해 암호경제적 지분을 약속하는 시장을 만들어 이 문제를 해결합니다. Filecoin 제공업체가 정기적인 암호화 증명을 통해 귀하의 데이터를 아직 보유하고 있음을 증명하지 못하면 담보의 일부를 잃게 됩니다. 이는 순수한 IPFS에는 부족한 경제적 인센티브를 창출합니다.

깔끔한 생각 방법: 검색 및 주소 지정에는 IPFS를 사용하고, 내구성 있는 유료 스토리지 약정에는 Filecoin을 사용합니다. Storacha 및 NFT.Storage와 같은 최신 고정 서비스는 두 가지 모두를 수행합니다. 빠른 검색을 위해 귀하의 콘텐츠를 IPFS에 고정하고 Filecoin 스토리지 계약을 체결하여 콘텐츠가 장기적인 암호화 경제를 보장하도록 합니다. IPFS의 속도와 Filecoin의 내구성을 하나의 스택으로 얻을 수 있습니다.

NFT 메타데이터: IPFS가 표준이 된 이유

NFT를 발행할 때 실제 이미지나 미디어 파일은 블록체인 자체에 거의 저장되지 않습니다. 이더리움에 멀티 메가바이트 JPEG를 저장하려면 엄청난 비용이 듭니다. 가스비. 대신 NFT 계약은 이미지 URL, 특성 및 기타 속성이 포함된 JSON 파일을 가리키는 메타데이터 URI를 저장합니다. NFT의 무결성은 해당 메타데이터 URI가 올바른 콘텐츠로 계속 확인되는지 여부에 전적으로 달려 있습니다.

IPFS가 사실상의 표준이 된 곳입니다. NFT 메타데이터에 일반 HTTPS URL을 사용하는 경우 손상된 NFT로 인해 서버가 한 번 중단됩니다. 더 나쁜 것은 민트 이후 이미지를 교체할 수 있으며 서버 로그를 확인하지 않고는 아무도 알 수 없다는 것입니다. IPFS의 경우 URI는 다음과 같습니다. ipfs://CID, 특정 암호화 해시를 가리킵니다. 내용은 변경할 수 없습니다. 해당 CID에 대해 다른 파일을 제공하는 모든 노드는 해시가 일치하지 않으므로 즉시 감지할 수 있습니다.

가장 흔한 NFT 실수인 문제는 IPFS에 업로드해도 파일이 유지되지 않는다는 것입니다. 로컬 노드에 업로드하고 다른 곳에 고정하지 않고 종료하면 NFT가 종료됩니다. 평판이 좋은 프로젝트는 최소한 하나의 전문 서비스에 고정되고, 진지한 프로젝트는 여러 서비스에 고정되어 Filecoin 거래를 성사시킵니다. NFT 프로젝트가 발행된 지 몇 년 후에 중단되는 경우는 거의 항상 팀이 고정 청구서 지불을 중단했기 때문입니다.

IPFS의 dApp 프런트엔드 호스팅

NFT를 넘어 두 번째 주요 프로덕션 사용 사례는 분산형 애플리케이션 프런트엔드를 호스팅하는 것입니다. 최신 dApp에는 Ethereum의 스마트 계약 백엔드와 JavaScript 프런트엔드가 있습니다. 프런트엔드가 일반 클라우드 제공업체에 있는 경우 dApp의 분산화 주장은 대부분 허구입니다. 스마트 계약은 온체인이지만 팀의 도메인이나 호스팅이 다운되면 사용자는 이에 접근할 수 없습니다.

프런트엔드 번들을 IPFS에 배포하면 dApp에 액세스할 수 있습니다. /ipfs/CID 영구적이며 모든 IPFS 게이트웨이가 이를 제공할 수 있습니다. 와 결합 분산형 ID 및 ENS를 통해 사람이 읽을 수 있는 이름 또는 dnslink, 완전히 주소 지정이 가능하고 검열에 저항하는 프런트엔드를 얻게 됩니다. Uniswap, Aave 및 기타 주요 DeFi 프로토콜은 이러한 이유로 IPFS 빌드를 게시합니다.

IPNS 및 DNSLink: 변경할 수 없는 콘텐츠의 변경 가능한 이름

콘텐츠 주소 지정은 훌륭하지만 분명한 한계가 있습니다. 콘텐츠가 변경될 때마다 CID도 변경됩니다. dApp이 새 버전을 배포하면 기존 링크가 모두 끊어집니다. 이 문제를 해결하기 위해 IPFS는 두 가지 간접 계층을 제공합니다. /ipns/ (행성간 이름 시스템) 및 dnslink.

IPNS를 사용하면 시간이 지남에 따라 업데이트할 수 있는 CID에 대한 안정적인 피어 키 기반 포인터를 게시할 수 있습니다. 포인터 자체는 공개 키의 해시이며 해당 개인 키로 업데이트에 서명합니다. 다른 노드는 해당 업데이트를 확인하고 IPNS 이름에 대한 요청을 현재 CID로 라우팅할 수 있습니다. 주소는 다음과 같습니다 /ipns/k51qzi5...은 영원히 안정적이지만 가리키는 내용은 변경될 수 있습니다.

DNSLink는 TXT DNS 레코드를 통해 일반 도메인 이름을 IPFS CID에 매핑할 수 있도록 하여 이를 한 단계 더 발전시킵니다. 다음과 같은 TXT 레코드를 생성합니다. _dnslink.example.com 값 포함 dnslink=/ipfs/CID및 IPFS 인식 도구는 도메인을 현재 CID로 확인합니다. 이것이 dApp 프런트엔드가 IPFS의 콘텐츠를 계속 제공하면서 사람이 읽을 수 있는 URL을 얻는 방법입니다. 배포할 때마다 DNS 레코드를 업데이트하고 사용자는 여전히 친숙한 도메인에 접속합니다.

실습: Storacha 및 Pinata에 업로드

이론은 괜찮지만 IPFS를 내면화하는 가장 빠른 방법은 실제로 무언가를 고정하는 것입니다. Storacha와 Pinata는 모두 넉넉한 무료 등급과 뛰어난 개발자 경험을 제공합니다. 각각의 실제 흐름은 다음과 같습니다.

와 함께 스토라차, 이메일로 storacha.network에 가입하세요. 이 서비스는 귀하에게 확인 이메일을 보내며, 일단 클릭하면 업로드를 위한 네임스페이스인 "공간"을 생성합니다. 당신은 w3 CLI npm install -g @web3-storage/w3cli, 로그인 w3 login [email protected], Space를 선택하고 다음으로 업로드하세요. w3 up ./my-file.jpg. 즉시 CID를 돌려받습니다. 파일은 Storacha의 IPFS 노드에 고정되어 있으며 Filecoin 스토리지 거래를 위해 대기하고 있습니다.

와 함께 피냐타, pinata.cloud에 가입하고 고정 및 목록 범위가 포함된 API 키를 생성하고 웹 업로드 인터페이스 또는 API를 사용하세요. 대시보드에서 문자 그대로 파일을 끌어다 놓고 이름을 지정하면 몇 초 안에 CID와 다음과 같은 Pinata 게이트웨이 URL이 생성됩니다. https://gateway.pinata.cloud/ipfs/CID. 프로그래밍 방식 업로드의 경우 Pinata는 여러 언어로 SDK와 깔끔한 REST API를 제공합니다. 대부분의 프로덕션 NFT 프로젝트에서 수행하는 것과 같이 자신의 도메인 아래에 사용자 지정 전용 게이트웨이를 구성할 수도 있습니다.

두 서비스 중 하나에서 CID가 있으면 여러 게이트웨이에서 작동하는지 확인하세요. 시도해 보세요 https://ipfs.io/ipfs/CID, https://CID.ipfs.dweb.link및 https://cloudflare-ipfs.com/ipfs/CID. 세 가지 모두 동일한 콘텐츠를 제공해야 합니다. 서로 다른 게이트웨이에서 동일한 CID의 서로 다른 콘텐츠가 표시되면 뭔가 매우 잘못된 것이므로 신고해야 합니다. 콘텐츠 주소 지정의 핵심은 CID가 콘텐츠라는 것입니다.

실제 프로덕션 사용 사례

IPFS는 더 이상 연구 프로젝트가 아닙니다. 이는 상당한 생산 트래픽을 지원하며 아래 예는 IPFS가 실제로 좋은 점과 과대평가된 점을 보여주기 때문에 알 가치가 있습니다.

터키의 Wikipedia 미러: 터키가 2017년에 Wikipedia를 차단했을 때 Wikimedia Foundation은 IPFS 커뮤니티와 협력하여 IPFS에 터키어 Wikipedia의 전체 미러를 게시했습니다. 사용자는 정부가 차단하지 않은 모든 IPFS 게이트웨이를 통해 액세스할 수 있습니다. 이는 IPFS 검열 저항에 대해 가장 많이 인용되는 증거로 남아 있습니다.

브레이브 브라우저: Brave는 기본 IPFS 지원을 제공하는 최초의 주요 브라우저로 사용자가 문제를 해결할 수 있도록 했습니다. ipfs:// 공용 게이트웨이를 통한 URL 또는 브라우저에서 직접 로컬 Kubo 노드를 실행합니다. 이로 인해 설정 없이 수천만 명의 사용자에게 IPFS가 제공되었습니다.

오디우스: 분산형 음악 스트리밍 플랫폼은 자체 콘텐츠 노드를 통해 IPFS에 모든 음악을 저장합니다. 아티스트 업로드, 플랫폼 핀, 청취자 스트리밍. 수백만 명의 사용자와 토큰화된 제작자 경제를 갖춘 실제 소비자 애플리케이션입니다.

OpenSea 및 NFT 마켓플레이스: Ethereum, Polygon 및 Solana의 NFT 메타데이터 및 미디어의 대부분은 고정 서비스를 통해 IPFS에 저장됩니다. 저장된 고유 콘텐츠의 양으로 볼 때 이는 IPFS의 단일 사용 사례 중 가장 큰 규모입니다.

dApp 프런트엔드: Uniswap, Aave, 1inch 및 기타 여러 주요 DeFi 프로토콜은 프런트엔드 빌드를 IPFS에 게시하고 여러 서비스에 고정합니다. 검열 저항에 관심이 있는 사용자는 팀의 도메인이 압류되거나 DNS에 감염되더라도 IPFS를 통해 직접 이러한 프런트엔드에 액세스할 수 있습니다.

위험 및 정직한 제한

IPFS는 강력한 프로토콜이지만 마법은 아니며 마케팅에서는 때때로 IPFS가 실제로 제공하는 것을 과도하게 판매합니다. IPFS에 프로젝트를 베팅하기 전에 이해해야 할 위험과 제한 사항은 다음과 같습니다.

첫 번째이자 가장 큰 위험은 핀 신뢰성. 귀하의 콘텐츠는 누군가가 고정하는 동안에만 살아있습니다. 무료 계층에는 대개 저장소 및 속도 제한이 있습니다. 이를 초과하고 업그레이드하지 않으면 핀이 제거될 수 있습니다. 프로젝트가 중요한 경우 유료 고정 또는 자체 호스팅을 계획하고 보관을 위한 Filecoin 거래를 고려하세요.

두 번째 위험은 게이트웨이 중앙화. 오늘날 대부분의 "IPFS 사용자"는 소수의 게이트웨이를 사용하는 HTTP 사용자입니다. 게이트웨이가 추가로 통합되거나 규제 압력에 직면하면 실질적인 분산화 스토리가 약화됩니다. 여러 게이트웨이를 사용하고 고급 사용자가 실제 노드를 실행하도록 장려하여 완화합니다.

세 번째 문제는 개인정보 보호. IPFS는 익명이 아닙니다. CID를 요청하면 피어 ID와 IP가 피어에게 표시되며 DHT 노드를 실행하는 사람은 누구나 어떤 CID가 요청되는지 확인할 수 있습니다. 민감한 콘텐츠의 경우 IPFS만으로는 충분하지 않습니다. 암호화 또는 양파 라우팅 전송이 필요합니다.

네 번째 문제는 대기 시간. 특히 제대로 복제되지 않은 CID의 경우 콜드 스토리지에서 검색 속도가 느려질 수 있습니다. DHT는 왕복을 추가하고 비트스왑은 세련된 CDN만큼 최적화되지 않습니다. 트래픽이 많은 동적 콘텐츠의 경우 IPFS는 적합한 도구가 아닙니다.

다섯 번째 문제는 데이터 영속성에 대한 오해. CID는 동일한 콘텐츠가 항상 동일한 주소를 갖는다는 점에서 영구적입니다. 그러나 콘텐츠를 호스팅하는 노드가 없으면 주소는 아무 것도 확인되지 않습니다. 영속성은 IPFS 자체가 아닌 고정 및 Filecoin 거래의 기능입니다.

IPFS, Stablecoins 및 Web3 배관

Web3에서 IPFS가 수행하는 덜 명확하지만 중요한 역할 중 하나는 감사 가능하고 변경할 수 없어야 하는 거버넌스 문서, 서비스 약관 및 위험 매개 변수 세트를 위한 스토리지 계층입니다. 전공 스테이블코인 발행자와 DeFi 프로토콜은 스마트 계약에서 참조되는 IPFS CID로 증명 문서, 예비 보고서 및 거버넌스 제안을 게시합니다. 이는 토큰 보유자에게 발행자의 웹 서버에 의존하지 않는 변조 방지 기록 기록을 제공합니다.

DAO 거버넌스에도 동일한 패턴이 나타납니다. 제안 텍스트와 지원 문서가 IPFS에 고정되므로 온체인 투표는 항상 사람들이 투표한 정확한 콘텐츠를 참조합니다. Snapshot 및 Tally와 같은 도구는 기본적으로 IPFS 고정 제안을 지원합니다. 역사적 제안을 확인할 때 블록체인 탐색기 을 클릭하고 설명을 클릭하면 일반적으로 IPFS에서 CID를 로드하게 됩니다.

자주 묻는 질문

결론

IPFS는 지난 10년간의 광범위한 분산 컴퓨팅 운동에서 등장한 가장 중요한 인프라 중 하나입니다. 위치 기반 주소 지정을 콘텐츠 기반 주소 지정으로 대체함으로써 웹이 초창기부터 안고 있던 문제(링크가 끊어지고, 콘텐츠가 사라지고, 중앙 집중식 서버가 단일 장애 지점을 생성함)를 해결했습니다. IPFS는 웹에 관한 모든 것을 고치지는 않지만 불변성과 탄력성의 이점을 가장 많이 누리는 인터넷 부분에 강력하고 효과적인 대안을 제공합니다.

솔직하게 요약하면 IPFS는 NFT 메타데이터, dApp 프런트엔드, 보관 문서, 거버넌스 기록 및 분산형 출판과 같이 무결성이 중요한 정적이고 주소 지정이 가능하며 수명이 긴 콘텐츠에 매우 잘 작동한다는 것입니다. 처리량이 많은 동적 콘텐츠, 추가 암호화가 없는 개인 데이터, 밀리초 지연 시간이 필요한 사용 사례에는 적합하지 않습니다. 프로토콜은 성숙하고 도구는 Helia 및 Kubo를 통해 견고하며 고정 서비스 환경은 누구나 몇 분 안에 콘텐츠 업로드를 시작할 수 있을 만큼 충분히 경쟁력이 있습니다.

정직한 주의사항도 마찬가지로 중요합니다. 게이트웨이 중앙화는 소수의 운영자에게 많은 트래픽을 조용히 집중시킵니다. 핀의 신뢰성은 전적으로 누가 비용을 지불하는지에 달려 있습니다. Filecoin이나 강력한 고정이 없으면 "영구 저장소"에 대한 마케팅은 오해의 소지가 있습니다. 이러한 제한 사항을 이해한다면 IPFS는 환상적인 도구입니다. 그렇지 않으면 조용히 썩어가는 NFT 컬렉션, 프런트엔드를 잃어버린 dApp, 아무도 보지 않을 때 사라지는 아카이브를 출시할 수 있습니다. IPFS를 신중하게 사용하고 내구성이 중요한 Filecoin 또는 전문 고정과 결합하면 최신 Web3 스택의 가장 강력한 스토리지 기본 요소 중 하나를 갖게 됩니다.