인덱스 제공자가 되는 방법
네트워크 인덱서에 관련한 세 번째 글이다. 첫 번째 글은 네트워크 인덱서에 개념적인 측면에서 다가갔다면 두 번째 글은 주소 지정이 가능한 몇십억 개의 콘텐츠에 대한 콘텐츠 제공자 검색을 활성화하기 위한 내부 작동 방식에 대해 더 깊게 알아보았다.
이전 글에 더하여 이번에는 인덱스 제공자가 되는 방법에 대해 더 자세히 알아본다.
인덱스 제공자란 무엇인가?
인덱스 제공자는 근본적으로 두 개의 추가적인 일을 하는 콘텐츠 제공자다.
- 다중 해시(multihashes)를 알림으로써 네트워크에 어떤 콘텐츠인지 알리며
- 콘텐츠가 검색되는 방식에 대한 부가 정보 제공
과정 개요
다음은 일반적인 인덱스 제공자가 취하는 단계에 대한 개요를 설명한다.
콘텐츠: 제공업체에 주소 지정이 가능한 새로운 콘텐츠가 저장된다. 콘텐츠 CID에서 제공자는 다중 해시를 추출하며 이는 엔트리(Entries)로 또한 불린다.
- 광고 생성: 제공자는 광고라는 데이터 구조에서 콘텐츠를 검색하는 방법에 대한 메타데이터와 함께 엔트리를 수집한다.
- 광고 검색: 제공자는 다른 콘텐츠를 저장하듯 이 광고를 저장하고 검색할 수 있게 만든다. 광고는 그 자체로 주소 지정할 수 있는 콘텐츠다.
- 공지(선택): 공급자는 네트워크에 새로운 콘텐츠를 알린다. 이 공지는 두 가지 방법으로 게시될 수 있다.
- 가십섭(Gossipsub) 공지: libp2p에 대해 /indexer/ingest/mainnet를 기본 설정함으로써 잘 알려진 가십섭 주제에 게시된다.
- HTTP 공지: HTTP 전송 프로토콜을 통해 알려진 네트워크 인덱서 인스턴스에 명시적 PUT 요청이 수행된다.
인덱서 노드는 알림 메시지를 수신하고 이 메시지에 응답하여 네트워크 인덱서가 콘텐츠를 인덱싱하는 광고 수집 메커니즘을 촉발한다.
각 단계에 대해 더 자세히 알아보자.
광고 생성
광고는 제공자가 호스팅하는 콘텐츠에 대한 정보를 네트워크 인덱서에 전달하는 코드 데이터 구조다. 밑의 정보는 이 데이터 구조를 IPLD 형식으로 설명한다.
type Advertisement struct {
PreviousID optional Link
Provider String
Addresses [String]
Signature Bytes
Entries Link
ContextID Bytes
Metadata Bytes
IsRm Bool
ExtendedProviders
}
광고 IPLD 형식
각 필드가 나타내는 것에 대한 설명이다.
- PreviousID: 이전 광고에 대한 IPLD 링크, 링크의 부재는 체인에서 가장 초기의 광고라는 것을 나타냄
- Provider: 콘텐츠 제공자의 libp2p 피어(Peer) ID
- Addresses: 콘텐츠를 검색할 수 있는 주소 목록
- Signature: 광고 서명, 콘텐츠 제공자의 신원에 따라 서명
- Entries: 콘텐츠 공급자가 호스팅하는 콘텐츠 해시를 캡처하는 항목에 대한 IPLD 링크
- ContextID: 콘텐츠 제공자가 게시한 광고 메타데이터를 고유하게 식별하는 키
- Metadata: 데이터를 검색할 수 있는 프로토콜의 암호화된 설명
- IsRm: 광고가 이전에 광고된 콘텐츠를 제거하는지에 대한 여부
- ExtendedProviders: 데이터에 대한 대체 가능한 제공자의 목록
광고 체인
광고들은 서로 연결되어 있는데, 각 광고는 효과적으로 제공자들이 호스팅하는 콘텐츠의 차이다. 모든 광고의 집합은 호스트에 전체 다중 해시 목록을 나타낸다. 다음 그림은 광고가 어떻게 함께 연결되어 있는지 설명한다.
엔트리
엔트리는 콘텐츠 제공자가 호스팅하는 다중 해시 목록을 확보한다. 구조는 다음과 같다.
- EntryChunk, 또는
- HAMT
엔트리 청크(Chunk) 체인
엔트리 청크 체인은 다음과 같은 IPLD 형식을 사용한다.
type EntryChunk struct {
Entries [Bytes]
Next optional link
}
엔트리 청크 IPLD 형식
광고와 마찬가지로 엔트리청크는 IPLD 링크를 사용하여 다중 해시 목록의 페이지 분류를 용이하게 하는 방법으로 함께 체인으로 연결된다. 기본 항목 목록은 광고의 다중 해시 배열이다. 만약 광고가 데이터 전송을 목적으로 단일 블록에 들어가는 것보다 더 많은 CID를 가지고 있다면, 그것들은 다음 청크에 대한 참조로서 Next를 사용함으로써 여러 청크, 개념적으로 연결된 목록으로 분할될 수 있다.
구체적인 제약 면에서 각 엔트리 청크는 4MB이하여야 하며 모든 엔트리 청크의 연결된 리스트는 400개를 넘으면 안 된다. 실질적으로, 이는 각각의 개별 광고가 약 4천만 개의 멀티 해시를 보유할 수 있다는 것을 의미한다.
HAMT
HAMT는 HMAT ADL의 IPFS 사양을 반드시 따라야 한다. HAMT 데이터 구조는 광고 중인 다중 해시 목록을 확보하는 집합으로 사용된다. 여기서 HAMT의 키는 광고되는 다중 해시를 나타내며 값은 단순히 true로 설정된다.
https://github.com/ipld/go-ipld-adl-hamt
https://ipld.io/specs/advanced-data-layouts/hamt/spec/
엔트리 청크 체인 vs HAMT
두 데이터 구조 중 하나를 사용하여 광고의 항목을 나타낼 수 있다. 그러나 어떤 것을 선택할지는 사용 사례에 따라 다르다.
엔트리 청크 체인은 IPLD 노드의 체인으로, 각각 다중 해시 배열을 가지고 있다. 다중 해시는 정렬되지 않는다. 즉, 특정 접두사를 사용하여 모든 다중 해시 목록을 가져오려면 전체 체인을 수집해야 한다. 다음 청크에 대한 링크가 하나만 있기 때문에 청크는 엄격한 순서를 따르지만 동시에 병렬로 통과할 수 없다. 우리는 다음 링크를 통과해야만 그 다음 링크를 알 수 있다.
HAMT는 반면 다중 해시를 정리하기 위해 전문화된 맵 데이터 구조를 사용한다. 이 특화된 구조 덕분에 특정 접두사를 사용하여 맵에서 다중 해시를 찾는 데에 효율적인 검색을 제공한다. 이는 여러 노드 간에 책임을 분포할 때 굉장히 유용하다. 이에 대한 더 자세한 내용은 향후 게시물을 확인하십시오. 부정적인 측면에서, 더 복잡한 데이터 구조를 가지며, 비트 폭과 버킷 크기에 적합한 HAMT 값을 선택하기 위해 다중 해시의 총 개수에 대한 이해와 일부 연구를 요구한다.
메타데이터
메타데이터는 데이터를 검색할 수 있는 프로토콜에 대한 정보를 가져온다. 일반적으로 나머지 바이트를 디코딩하는 방법에 대한 힌트를 제공하는 프로토콜 ID인 varint로 시작한다. 메타데이터는 확장 가능하도록 명시적으로 설계되었다. 데이터 검색자가 프로토콜 ID를 이해하는 한 원하는 프로토콜을 지원할 수 있다. 인덱서 노드는 이를 최대 1KiB 크기 제한을 가진 바이트 배열로 처리한다.
이 필드는 여러 프로토콜 ID에 대한 인코딩을 지원한다. 여기서 프로토콜 섹션은 프로토콜 ID 값의 오름차순으로 나타나야 한다. 현재 잘 알려진 프로토콜 ID는 두 개다:
- 빗스왑(Bitswap): 간단히 고정된 varint 값인 0x0900이며 그 이상의 바이트는 없음
- 그래프싱크코인V1(GraphsyncFileCoinV1): 프로토콜 ID 0x0910을 사용하며 CBOR로 인코딩 된 다음과 같은 정보를 캡슐화하여 파일코인 스토리지 제공자로부터 콘텐츠가 다운받아지는 방식을 명시한다.
type GraphsyncFilecoinV1 struct {
PieceCID Link
VerifiedDeal Bool
FastRetrieval Bool
}
그래프싱크코인V1 메타데이터 IPLD 형식
일반적으로 프로토콜 ID는 멀티코드 CSV 테이블에 추가된다. 그러나 이는 절대적으로 요구사항이 아니며 검색 클라이언트가 메타데이터를 이해하기 때문에 사용자 자신의 맞춤형 비충돌 프로토콜 ID로 자신의 프로토콜을 자유롭게 인코딩할 수 있다.
광고 공지
광고가 형성이 되면 광고의 존재를 전파하기 위해 인덱스 제공자가 공지하며 결과적으로 네트워크의 인덱서에 의해 광고의 실제 콘텐츠에 관한 여론조사를 촉발한다. 공지는 두 가지 방법으로 이뤄진다.
- 가십섭, 혹은
- 직접적인 HTTP 공지
인덱서가 공지하는 제공자를 이미 알고 있으면 광고마다 공지를 하지 않아도 된다.
가십섭 공지
가십섭 공지는 잘 알려진 주제에 대해 /indexer/ingest/mainnet이라고 불리는 libp2p 가십섭 프로토콜을 사용한다. 인덱서는 다음을 파악하기 위해 해당 주제에 게시된 메시지를 확인한다.
- 가장 최근의 광고 CID는 무엇인지, 그리고
- 어디서 가져올 수 있는지
광고 체인을 가져오기 위해 피어에 접촉한다.
HTTP 공지
직접적인 HTTP 공지는 콘텐츠 제공자 측면에서의 잘 알려진 인덱서 엔드포인트 구성을 요구한다. 광고가 형성된 후에 콘텐츠 제공자는 PUT 요청을 가십섭 메시지와 동일한 정보를 포함하는 요청 본문과 함께 잘 알려진 엔드포인트인 /ingest/announce로 보낸다.
인덱서 노드가 직접적인 공지를 받는 것에 대한 반응은 동일하다. 반응은 '204 Accepted'이며 광고 체인을 가져오기 위해 수동적으로 피어에게 접촉한다.
광고 가져오기
앞서 언급한 바와 같이, 광고 체인은 인덱서에 의해 움직인다. 이는 인덱서 노드가 확장하고 다수 제공자로부터 콘텐츠를 가져올 수 있도록 돕는 주요 설계 결정이다. 인덱서 노드는 광고 가져오기를 수동으로 설정하여 제공자 공지가 많은 경우 가져오기 요청을 일괄 처리할 수 있다.
또한, 인덱서가 어떤 것을 가져올 지 제어할 수 있게 한다. 인덱서 노드는 내부적으로 마지막에 처리된 광고 CID를 추적함으로써 전에 보지 못했던 광고의 부분만을 가져온다.
가져오기를 활성화하기 위해 제공자는 인덱서 노드가 접근할 수 있는 엔드포인트를 노출해야 한다. 두 가지의 전송 프로토콜을 현재 지원하고 있다.
- HTTP 및
- 그래프싱크(GraphSync)에 대한 데이터트랜스퍼(DataTransfer)
공지 메시지는 콘텐츠 제공자가 어떤 전송 프로토콜을 제공하는지에 대한 정보를 가져온다.
광고된 콘텐츠 수정
제공자는 항목을 다시 광고할 필요성을 완화하는 특수하게 조작된 광고를 통해 광고한 콘텐츠의 상태를 변경할 수 있다. 매번 항목을 다시 알릴 필요 없이 효율적으로 수정할 수 있도록 하기 위해서다.
여기에 향후 광고를 통해 광고한 콘텐츠를 수정하는 방법에 대한 가장 흔한 사용 사례가 있다.
- 콘텐츠 제거: IsRm을 true로 설정하고 콘텐츠를 추가했던 광고와 동일한 Provider 및 ContextID를 사용하여 특수 CID인 no-content를 Entries 링크로써 사용하는 새로운 광고 게시
- 검색 프로토콜 변경: IsRm을 false로 설정하고 콘텐츠를 추가했던 광고와 동일한 Provider 및 ContextID를 사용하여 새 Metadata만 변경하고 Entries 링크를 지정하지 않는 새로운 광고 게시
- 검색 주소 변경: 새 주소로 새 광고를 게시하면 공급자 ID에 매핑된 주소가 이전에 광고된 모든 콘텐츠에 대해 업데이트
광고한 콘텐츠를 수정하는 방법에 대한 자세한 내용은 수집 도식 설명서를 참조하십시오.
모든 콘텐츠를 삭제하는 것은 현재 지원이 안 된다는 점을 참고하십시오.
IPNI는 또한 확장 제공자 패밀리(Extended Provider Famillies)를 지원한다. 이 기능을 통해 제공자는 검색 프로토콜과 함께 데이터를 검색할 수 있는 다른 제공자 목록을 확장할 수 있다. 확장 제공자 패밀리 전용 블로그 게시물을 계속 시청하십시오.
광고 입증
인덱스-제공자 라이브러리는 콘텐츠 제공자 및 인덱서 양측에서 광고된 콘텐츠의 정확성을 입증하는 데에 사용할 수 있는 CLI 도구를 제공한다. 콘텐츠 제공자가 체인을 정확하게 노출시켜 네트워크 인덱서가 접근할 수 있는지 확인할 수 있다. 인덱서 측면에서 광고된 콘텐츠가 인덱서에게 취득되고 올바른 제공자와 관련된 쿼리 API를 통해 발견 가능한지 확인한다.
여기에서 설치 안내를 확인하고 더 많은 정보를 위해 provider verify-ingest --help를 실행하십시오.
리소스
인덱서 혹은 인덱서 네트워크 참여에 관심이 있다면 아래의 리소스를 참조하십시오.
- cid.contact (콘텐츠 라우팅 홈페이지)
- docs.cid.contact (인덱서 깃북)
- ipni (파일코인 슬랙 채널)
- 인덱서 구현(Indexer Implementation)
- 인덱서 취득(Index Ingestion)
- 인덱서 제공자 생성(Creating an Index Provider)
- 인덱서 제공 덱(Index Providing Deck)
더욱 다양한 정보 및 방송 관련 소식은
공식 SNS 채널을 통해 확인 가능합니다.
