Iroh의 전 세계 콘텐츠 검색

AI 요약

Iroh 개발팀은 콘텐츠를 게시한 뒤 관심 있는 사람이 남아 있는 한 전 세계에서 계속 찾을 수 있게 하려는 목표로, 실험적인 콘텐츠 검색 시스템을 만들었습니다. IPFS의 전 세계 콘텐츠 검색 구상에서 출발하되, 제공자 검색에는 오랜 기간 안정적으로 운영된 BitTorrent Mainline DHT를 선택했습니다. 전송에는 SHA-1 조각 해시 대신 BLAKE3 검증 스트리밍을 쓰고, Mainline이 제공하는 UDP 주소를 Iroh의 암호화된 EndpointId로 연결하는 작은 주소 인덱스 서비스를 추가합니다.

BitTorrent 검색망을 활용하는 이유

BitTorrent는 파일 전송과 콘텐츠 검색을 별도 시스템으로 구성합니다. 2001년에는 중앙 트래커를 사용했고, 2005년에 Mainline DHT를 추가했습니다. 토렌트 파일의 info 영역에는 파일 이름과 조각 크기, 파일 길이, 각 조각의 SHA-1 해시가 담깁니다. Mainline은 이 info 영역의 해시를 키로 삼아 제공자를 등록하고 검색합니다.

글에서는 Mainline의 단순한 설계를 빠른 검색의 이유로 꼽습니다. 노드별 연결 상태를 크게 늘리지 않도록 질의와 응답을 단일 UDP 패킷에 담고, 제공자 정보도 DHT 노드가 관측한 공개 IP 주소와 포트로 제한합니다. BEP 44 확장 데이터 역시 작은 크기로 제한하며, 쓰기 전에 주소 도달 가능성을 확인하는 토큰을 요구합니다. 작성자는 실제 BEP 44 조회에서 첫 결과를 37밀리초 만에 얻은 사례를 보여줍니다. Mainline 조회가 전역 규모에서도 밀리초 단위로 끝날 수 있다는 설명입니다.

BLAKE3 전송과 주소 인덱스

BitTorrent 전송은 조각 전체를 받아야 해시를 검증합니다. 반면 Iroh의 iroh-blobs는 BLAKE3 검증 스트리밍을 사용해 큰 콘텐츠의 일부 범위도 중간 해시 없이 검증합니다. 콘텐츠마다 BLAKE3 루트 해시 하나만 쓰며, 여러 제공자에게서 한 콘텐츠를 효율적으로 내려받는 작업은 아직 남아 있습니다.

Mainline의 제공자 기록은 IP 주소와 포트뿐입니다. Iroh는 연결에 Ed25519 공개키인 EndpointId를 쓰고, 제공자의 주소는 NAT 뒤에 있어 직접 연결 주소로도 쓸 수 없습니다. 이에 저자는 공개 UDP 주소와 EndpointId를 이어 주는 별도 서비스 udp-addr-index를 구현했습니다. 서비스는 도달 가능성이 확인된 UDP 주소마다 최대 1KiB의 임의 메타데이터를 보관하는 메모리 기반 last-writer-wins 맵입니다. 기록은 만료되므로 제공자가 주기적으로 갱신해야 하며, 영속 저장을 생략해 운영을 단순하게 했습니다. 서비스는 EndpointId의 개인키로 서명한 기록을 보관하지만 서명이나 엔드포인트 자체를 검증하지는 않습니다. 발견된 엔드포인트는 후보일 뿐이며, 실제 콘텐츠 제공 여부는 별도로 확인합니다.

게시부터 다운로드까지

게시자는 주소 인덱스에 서명된 EndpointId 기록을 등록하고, 콘텐츠의 BLAKE3 해시를 SHA-1로 변환해 Mainline의 announce_peer에 알립니다. SHA-1의 충돌 저항성은 깨졌지만, 여기서 DHT는 제공자 후보를 찾는 최선 노력 방식으로만 쓰입니다. 내려받은 데이터는 원래 BLAKE3 해시로 검증하므로 잘못된 검색 결과가 시간을 낭비하게 할 수는 있어도 다른 콘텐츠를 정상 데이터로 받아들이게 하지는 않습니다.

검색자는 같은 방식으로 해시를 변환해 get_peers를 호출합니다. 반환된 IP 주소와 포트를 주소 인덱스에서 EndpointId로 바꾸고, 각 후보에 콘텐츠 크기를 묻는 BLAKE3 질의를 보내 살아 있는 제공자인지 확인합니다. 이후 iroh-blobs 다운로더가 콘텐츠를 받습니다. 실제 QUIC 연결은 Mainline에 등록한 UDP 주소로 맺지 않습니다. Iroh의 주소 검색과 NAT 홀 펀칭을 거쳐 EndpointId로 연결합니다.

실험 저장소 iroh-content-discovery에는 주소 인덱스 서비스와 클라이언트, 관련 예제가 포함됩니다. 예제에서는 Mainline에서 제공자 주소를 찾은 뒤 EndpointId로 바꾸고, 44바이트 콘텐츠를 내려받아 검증합니다.

브라우저에서 콘텐츠를 열고 이름 붙이기

정적 콘텐츠 주소는 BLAKE3 해시를 z-base-32로 인코딩한 https://<해시>.blake3.net 형식입니다. 실제 웹 게이트웨이를 도메인에 두는 대신 브라우저 플러그인이 주소를 로컬 게이트웨이 주소로 다시 씁니다. 플러그인은 Brave, Chrome, Firefox를 지원하며, 로컬 게이트웨이가 Mainline 검색과 다운로드를 맡고 콘텐츠를 검증해 제공합니다. 게이트웨이는 iroh-blobs 컬렉션의 디렉터리 목록과 파일 형식 판별도 지원합니다.

변경 가능한 이름에는 공개키 기반의 분산 DNS인 Pkarr를 씁니다. Ed25519 공개키를 인코딩한 이름은 <이름>.pkarr.net 형식이며, Pkarr 레코드는 Mainline DHT에 게시합니다. 레코드가 BLAKE3 콘텐츠를 가리키면 게이트웨이가 해당 콘텐츠를 제공합니다. 공개키를 가진 누구나 이름을 만들 수 있지만, 52자 공개키 인코딩은 사람이 기억하기 어렵습니다. 사람이 읽기 쉬운 이름과 Pkarr를 결합하는 방법은 아직 구상 단계입니다.

남은 한계

현재 시스템은 전 세계 콘텐츠 검색의 출발점이며 완성형은 아닙니다. Mainline은 모든 인터넷 콘텐츠를 주소화하는 규모까지 확장되지 않을 수 있고, 트래픽이 암호화되지 않아 중간 장비가 차단하기 쉽습니다. Pkarr의 Ed25519 이름은 양자 내성을 갖추지 않았으며, 콘텐츠를 공유하면 누구나 제공자의 IP 주소를 조회할 수 있어 프라이버시도 보장하지 않습니다. 작성자는 Mainline 확장이나 Iroh 연결을 사용하는 자체 DHT로 기반을 개선할 가능성을 언급합니다. 관련 프로토콜은 개발 중이며, 엔드포인트 검색 기능은 실험 단계입니다.

Lobsters 반응

• @sanqui — IPFS는 쇠퇴 중입니다. 자금 지원이 줄고 있고, 성능 문제도 극복하지 못한 듯합니다. Iroh가 이 아이디어를 차세대 방식으로 구현한 결과가 마침내 나왔네요. 적어도 퍼즐 조각 대부분은 갖춰진 것 같습니다. 아직 크게 알리지는 않는 듯하지만 기대됩니다!
• @synchronousq — Mainline DHT를 UDP 홀 펀칭에 쓰는 이야기가 나와서 말인데, DHT나 DNS를 이용하면 Tailscale의 조정 서버를 완전히 대체할 수 있지 않을까 의심해 왔습니다. 한동안 프로토타입을 만들었는데 꽤 잘 작동하는 듯합니다.
  • @quad — BEP-55인가요?
• @chriswarbo — 아주 흥미롭습니다! 새로운 걸 발명하지 않고 작동하게 만들 방법이 있는지 같은 문제를 붙들고 있었습니다. 새 기술을 만들면 다른 사람들에게 채택을 설득해야 하니까요. 저는 DNS를 통해 Pkarr 레코드를 조회하는 pkdns를 써 왔습니다. 브라우저 플러그인보다 범용적입니다. 주소와 포트 조합을 데이터베이스 키로 쓰는 건 다소 억지스럽지만, 해당 주소와 포트로 통신할 수 있다는 증명을 쓰기 권한으로 삼은 점은 영리합니다.

원문: Iroh / 번역·요약: Trawling