콘텐츠 식별자 (CID)

모든 IPFS 파일이 받는 고유한 핑거프린트입니다.

CID란 무엇인가요?

콘텐츠 식별자(CID)는 IPFS에서 데이터를 고유하게 식별하는 자기 기술형 라벨입니다. 파일 내용의 암호학적 해시와 사용된 해싱 알고리즘 및 인코딩 형식에 대한 메타데이터를 결합하여 파생됩니다.

bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

bafy(또는 작은 단일 블록 콘텐츠의 경우 bafk)로 시작하는 CID는 최신 자기 기술형 형식인 CIDv1을 사용합니다. Qm으로 시작하는 레거시 CID는 CIDv0(base58 인코딩 SHA-256)을 사용합니다 — 여전히 유효하고 여전히 해석 가능하지만, 더 이상 새 콘텐츠의 기본 출력 형식은 아닙니다.

핵심 속성

• 결정론적 — 동일한 파일은 항상 동일한 CID를 생성합니다. 같은 이미지를 두 번 업로드해도 동일한 식별자를 받습니다.
• 고유성 — 1바이트의 변경만으로도 완전히 다른 CID가 생성됩니다. 이는 CID를 변조 방지 가능하게 합니다.
• 자체 검증 — 파일을 받은 누구나 해시를 다시 계산하여 요청한 CID와 일치하는지 확인할 수 있습니다.
• 불변성 — CID는 항상 동일한 콘텐츠를 가리킵니다. CID가 해석하는 대상을 변경할 수 없습니다.

IPFS.NINJA에서의 CID

업로드한 모든 파일은 API 응답에서 CID를 반환합니다. 이를 사용하여:

• 게이트웨이를 통해 파일에 접근: ipfs.ninja/ipfs/<CID>
• 파일 메타데이터 조회: GET /file/<CID>
• 온체인에서 콘텐츠 참조 (NFT, 스마트 컨트랙트)
• 누구와든 공유 — 콘텐츠가 일치하는지 검증 가능

CID가 업로드 워크플로우에 어떻게 활용되는지는 IPFS.NINJA 개요에서 확인하세요. 콘텐츠를 영구적으로 접근 가능하게 유지하려면 CID로 콘텐츠 고정하기 방법을 알아보세요.

CIDv0 vs CIDv1

속성	CIDv0	CIDv1
접두사	Qm...	bafy... (dag-pb, 디렉터리 및 다중 청크 파일), bafk... (raw, 작은 단일 블록 콘텐츠), 코덱별로 그 밖의 형식도 존재
해시 함수	SHA-256만	다중 (SHA-256, Blake2b 등)
인코딩	Base58 (대소문자 혼용)	Multibase — 기본값은 base32 (소문자, DNS 안전)
자기 기술형	아니요	예 (코덱 + 해시 정보 포함)
청커	256 KiB 레거시 기본값	IPIP-0499에 따른 1 MiB
Leaf 인코딩	dag-pb로 래핑됨	Raw 바이트 (raw-leaves=true)

IPFS.NINJA가 생성하는 형식

2026-07-13 이후에 이루어진 업로드와 피닝은 기본적으로 CIDv1을 반환합니다: CIDv1 base32 인코딩, 1 MiB 청크, raw leaves — IPIP-0499 unixfs-v1-2025 프로필입니다. 실질적인 영향:

• 작은 파일(1 MiB 이하)은 bafk...(raw 단일 블록 CIDv1)로 반환됩니다
• 더 큰 파일과 디렉터리는 bafy...(dag-pb CIDv1)로 반환됩니다
• 저희를 통해 업로드된 파일은 최신 도구(Helia, 최신 Kubo, ipfs-car)가 동일한 바이트로부터 계산하는 것과 동일한 CID를 얻습니다

하위 호환성

이전 업로드의 레거시 Qm... CID는 계속 완전히 해석 가능합니다 — 게이트웨이, POST /pin, GET /file/:cid, IPNS 리졸버, 그리고 다른 모든 엔드포인트가 두 형식을 무기한 허용합니다. 이전 업로드에서 받은 Qm... CID가 있다면, 이미 구축한 것은 아무것도 작동을 멈추지 않습니다.