영구성과 불변성은 NFT의 핵심적인 가치 제안의 일부이다. 불행히도 많은 NFT는 오늘의 소비자를 대상으로 기본적인 디자인 결함으로 이런 요소들을 제공하지 않는다. NFT는 “블록체인에 영원히 산다” 라는 주장을 자주 듣지만 종종 블록체인에 데이터를 저장하는 비용과 공간 제한 때문에 실제로 소유 기록만 저장되고, NFT의 실제 콘텐츠에 메타데이터가 연결된다.
이런 링크들은 너무 자주 연약하고 HTTP 프로토콜을 사용하여 사용자들을 특정 자산보다는 특정 위치 (location)로 유도한다. 이는 링크에 의해 지적된 내용이 향후 어느 시점에서든 변경되거나 오프라인으로 변환되어 원래의 자산이 영원히 손실될 수 있다는 것을 의미한다 (소유권의 기록은 가치가 없다).
IPFS는 이런 문제를 해결하는 것에 도움이 되고 IPFS의 활용하는 NFT는 이점을 얻을 수 있다. 그러나 네트워크에 저장된 데이터의 영구성과 접근성을 보장하기 위해서는 확립된 규약을 준수하는 것이 중요하다. NFT의 인기가 증가하면서, IPFS에 NFT 데이터를 연결하고 저장하는 모범 사례들을 다시 살피는 것을 추전한다. 이번 포스트에서는 우리는 최근 우려가 되는 두가지 영역을 다룰 것이다: 콘텐츠 주소 지정과 콘텐츠의 통합성.
Content Addressing
IPFS 콘텐츠 식별자 (CIDs)는 콘텐츠 저장 위치 또는 저장 방법에 관계없이 모든 콘텐츠를 고유하게 확인하기 위해 굉장히 강력하고 유용한 방법이다. 이러한 장점을 최대한 활용하려면 개발자는 IPFS 데이터에 연결하기 위한 다음과 같은 권장 사항과 규칙을 준수해야 한다.
Linking Overview
이 포스트는 CID에 대한 포괄적인 설명을 위한 것이 아니다. 그러나 독자들은 다음과 같은 차이점을 유의해야 한다.
CID (Content Identifier)
CID는 콘텐츠에 대한 자체 설명, 고유 식별자이다.
예)bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi
CID는 IPFS를 사용하든 다른 시스템을 사용하든 명확하지 않은 다른 상황 내에서 사용되어야 한다. 우리는 디스크에 저장할 때 CID를 IPFS URl로 전환하는 것을 추천하고 생성 후 변경할 수 없는 메타데이터 및 블록체인 레코드에서 그렇다. Ipfs://URl 체계를 포함하면 사용자 및 자동화된 툴링 방법을 명확하게 보여주는 중요한 컨텍스트가 CID에 추가된다.
IPFS URl
통일된 리소스 식별자 또는 URl는 주어진 콘텐츠에 특정 부분의 콘텐츠를 지정하기 위해 사용한다. 컨텍스트는 URl 체계에 의해 결정된다. IPFS URl 체계는 ipfs이다. URl은 선택적으로 끝에 추가된 경로를 포함할 수 있다.
- ipfs://bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi
- ipfs://bafybeigvafaks2bvivtv46n2z7uxszpvl25jhvzc6dbhnjjgjkbeia5jta/nft.mp4
IPFS URl은 파일이나 디렉토리를 가리키는 IPFS링크의 표준 표현이다. 스마트 계약에서 IPFS 데이터로 연결할 때 IPFS URl를 사용하여 IPFS를 사용하여 데이터를 검색해야 명확히 나타낸다.
IPFS URls 또한 IPFS에 저장된 이미지 및 기타 미디어 자산에 연결할 때 NFT의 구조화된 메타데이터 내부에서 사용되어야 한다.
HTTP Gateway URL
HTTP 게이트웨이는 IPFS URl를 기본적으로 확인할 수 없는 기존 브라우저에 상호 운용성을 제공한다. 이러한 링크는 애플리케이션의 프레젠테이션 계층에서만 사용되어야하며, 블록체인이나 NFT 메타데이터 내부에 저장해서는 안된다.
예)https://dweb.link/ipfs/bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi
HTTP 게이트웨이는 최근 콘텐츠 배포를 중앙 집중화하여 중간 벡터와 단일 장애 지점을 모두 제공한다. 게이트웨이 운영자가 오프라인으로 전환되거나 연결할 수 없는 경우 링크가 끊어진다. 그러나 IPFS를 기본 지원하는 브라우저는 이러한 문제에 영향을 받지 않으며, 이러한 링크에서 CID를 자동으로 추출하고 사용자의 기본 설정에 따라 IPFS에서 데이터를 로드 할 수 있기 때문이다.
Addressing in Various Contexts
개발자들은 상황에 따라 링크 형식을 다르게 지정해야 한다.
On chain
NFT 스마트 계약은 IPFS URl를 각 토큰과 연결된 자산 및 메타데이터로 반환해야 한다.
예)ipfs://bafybeibnsoufr2renqzsh347nrx54wcubt5lgkeivez63xvivplfwhtpym/metadata.json
각 토큰을 민트하고 온체인 URl를 저장하기 전에 우리는 IPFS URl를 생성하기를 추천한다. 이것은 URl를 기대하는 스마트 계약 인터페이스를 준수하는 가장 간단한 방법이며, ipfs://URl 체계는 모든 분산 앱 IPFS를 사용하여 데이터를 사용할 수 있음을 쉽게 확인할 수 있도록 한다.
Metadata
토큰 메타데이터에서 IPFS URls는 일반 텍스트에서 IPFS 리소스에 연결하는 가장 모호하지 않고 미래 대비적인 방법으로 사용되어야 한다.
다음은 NFT 미디어 자산을 첨조하는 IPFS URI의 예이다: ipfs://bafybeigvafaks2bvivtv46n2z7uxszpvl25jhvzc6dbhnjjgjkbeia5jta/nft.mp4
개발자는 선택적으로 레거시 상호 운용성을 위해 공개 HTTP 게이트웨이 링크를 포함하기 원할 수 있다.
콘텐츠를 연결하는 대안(예: 비게이트웨이 HTTP URL)은 이상적으로 피해야 한다. 특정 위치에서 HTTP를 통해 제공되는 콘텐츠는 변경될 수 있으므로 이러한 링크는 임시 콘텐츠 미러 이외의 다른 것으로 신뢰할 수 없다. 데이터가 영구적이고 불변으로 저장되는 블록체인의 경우 HTTP를 통해 콘텐츠를 참조하는 것은 그만큼 취약하고 위험하다.
대조적으로, IPFS URl는 영원히 유효하며, 따라서 데이터에 대한 표준 링크로 안전하게 간주될 수 있다. IPFS URl를 링크의 '진실의 소스’로 사용함으로써, 애플리케이션은 단순히 새로운 게이트웨이 링크를 생성함해 여러 스토리지 솔루션을 쉽게 지원 또는 시간이 지남에 따라 다른 게이트웨이로 변환할 수 있다. 이는 특정 게이트웨이를 영구 블록체인 레코드로 “하드 코딩”하는 것보다 더 유연하다.
Application
사용자 대면 애플리케이션의 경우 개발자는 다음 두가지를 모두 통해 IPFS콘텐츠에 연결해야 한다
- An IPFS URI
- An HTTP gateway URL
더 많은 브라우저가 IPFS URl 체계의 네이티브 해상도를 지원할 때까지, 두 종류의 링크는 필요에 따라 원시 CID 또는 IPFS URI에서 쉽게 생성될 수 있다.
다음은 dweb.link 의 공용 게이트웨이를 대상으로 하는 HTTP 게이트웨이 URL의 예이다:
https://dweb.link/ipfs/bafybeigvafaks2bvivtv46n2z7uxszpvl25jhvzc6dbhnjjgjkbeia5jta/nft.mp4
같은 링크는 CID로 URL 경로 대신 하위 도메인으로 작성할 수 있다:
https://bafybeigvafaks2bvivtv46n2z7uxszpvl25jhvzc6dbhnjjgjkbeia5jta.ipfs.dweb.link/nft.mp4
두 가지 예 모두 이 표준 IPFS URl에 해당한다:
ipfs://bafybeigvafaks2bvivtv46n2z7uxszpvl25jhvzc6dbhnjjgjkbeia5jta/nft.mp4
Integrity
NFT의 주요 관심사는 자산의 무결성이다. 여기에는 자산자체와 관련된 모든 데이터가 포함된다. IPFS는 CID를 사용하여 링크가 생성된 후 아무것도 변경되지 않았음을 확인함으로써 NFT 데이터의 무결성을 보호한다
개발자는 IPFS의 내장 데이터 검증의 이점을 최대한 활용하려면 다음 권장 사항을 준수해야 한다.
Linking metadata to its asset
토큰의 메타데이터는 NFT 값에 필수적인 것으로 간주해야 합니다. 따라서 자산의 가치를 보존하기 위해 메타데이터는 자산과 함께 IPFS에 저장되어야 하며, 둘 다 접근 가능한 상태를 유지해야 한다.
이를 위한 바람직한 방법은 다음과 같다:
- 두 개의 새로운 디렉터리 (자산용 하나와 메타데이터 하나) 생성한다.
- 자산을 디렉터리에 추가한다.
- 자산의 CID에 주목하여 자산의 디렉토리를 IPFS에 추가한다.
- (3)의 CID를 사용하여 자산을 참조하여 IPFS URl를 생성하는 자체 디렉터리에 메타데이터를 생성한다. URl에는 디렉토리의 CID와 자산의 파일 이름이 포함되어야 한다.
- 메다데이터의 디렉토리를 IPFS에 추가한다(CID 참고).
- (5)의 CID를 사용하여 메타데이터에 대한 IPFS URl를 생성하고 URl를 체인에 저장하여 소유한 레코드를 구성한다.
이 프로세스는 개발자가 파일 이름을 링크 (사용자 상호 작용에 귀중한)에 포함시키는 동시에 메타데이터와 자산이 서로 독립적으로 참조될 수 있도록 하는 기능을 보존하다.
- 메타데이터는 ipfs://{metadata-directory-CID}/metadata-filename 엑세스 할 수 있다.
- 자산은 ipfs://{asset-directory-CID}/asset-filename 엑세스 할 수 있다.
아래 이미지 파일에 연결되는 IPFS URl를 포함하는 일부 JSON 메타데이터의 예이다.
ipfs://bafybeidfjqmasnpu6z7gvn7l6wthdcyzxh5uystkky3xvutddbapchbopi/no-time-to-explain.jpeg 이미지를 불러올 수 있다. 프레센테이션 경우 HTTP 프로토콜을 사용하여 사용자들을 특정 자산보다는 특정 위치 (location)로 유도한다.
메타데이터가 생성되면 IPFS에 JSON 파일을 저장되며 CID는 스마트 게약에 저장할 수 있는 URl를 생성하는데 사용한다.
ipfs://bafybeibnsoufr2renqzsh347nrx54wcubt5lgkeivez63xvivplfwhtpym/metadata.json
High Availabilty
IPFS 와 같은 분산형 네트워크를 사용하여 콘텐츠를 제공하는 주된 이유 중 하나는 링크 로트(link rot)를 사전에 차단하기 위함이다. 이는 네트워크의 다른 노드가 공동 호스팅을 통해 데이터를 미러링하도록 허용함으로 달성된다. 그러나 콘텐츠의 가용성을 보장하고자 하는 개발자는 다른 노드의 이타주의에 의존해서는 안된다. 링크된 콘텐츠를 계속 사용할 수 있도록 하려며 개발자가 관리하는 IPFS노드에 콘텐츠의 CID를 고정하고, 콘텐츠를 보존 및 배포하여 직접 호스팅해야 한다. 원하는 경우 개발자는 핀닝 서비스를 통해 이러한 책임을 위임할 수도 있다.
보다 다양한 정보 및 방송관련 소식은
공식 SNS채널을 통해 확인 가능합니다.
