Iroh의 글로벌 콘텐츠 탐색 시스템 구현

Iroh가 BitTorrent Mainline DHT와 별도 주소 인덱스를 결합하여, BLAKE3 해시로 콘텐츠 제공자를 찾고 데이터를 내려받는 실험적 시스템을 구현했습니다.

콘텐츠 탐색과 전송을 분리하고, iroh-blobs의 BLAKE3 검증 스트리밍으로 데이터를 검증합니다. 이 방식은 DHT가 잘못된 제공자를 반환하더라도 시간을 낭비할 수는 있지만, 잘못된 콘텐츠를 받아들이지는 않습니다.

Iroh는 Mainline이 저장하는 host:port와 Iroh의 암호학적 식별자인 EndpointId를 연결하기 위해 경량 UDP 주소 인덱스 서비스를 추가했습니다. 이를 통해 브라우저 확장과 로컬 게이트웨이를 사용하여 콘텐츠 주소 기반 웹을 탐색하고, pkarr로 중앙 명명 기관의 허가 없이 갱신 가능한 이름을 게시할 수 있습니다.

아직 실험 단계이며, 공유자의 IP 주소 노출, 암호화되지 않은 DHT 트래픽, 인터넷 전체 규모로의 확장성, 양자 내성이 없는 명명 체계 등의 한계가 존재합니다.

허가 없는 글로벌 콘텐츠 탐색

개인 웹사이트, 블로그, 정치적 유인물을 게시하고 관심 있는 사람이 충분한 동안 전 세계에서 계속 접근할 수 있게 하는 것이 허가 없는 콘텐츠 탐색의 목표입니다. 정부의 방화벽 기법이 정교해지면서 검열 우회 도구와 글로벌 콘텐츠 탐색의 필요성은 여전히 큽니다.

IPFS Shipyard의 활동 종료는 시급성을 더합니다. IPFS가 작동을 멈춘다는 의미는 아니지만, 프로젝트의 미래에 좋은 징후는 아닙니다.

홀 펀칭 구현 때 기존 오픈소스 시스템을 출발점으로 삼았듯이, 이번에는 20년 넘게 작동해 온 BitTorrent를 검토했습니다. 다만, BitTorrent의 데이터 전송 프로토콜과 글로벌 탐색용 Mainline DHT는 별개의 시스템입니다.

전송 프로토콜과 BLAKE3 검증 스트리밍

BitTorrent의 .torrent 파일은 JSON과 개념적으로 유사한 bencode로 다운로드할 데이터의 정보를 저장합니다. pieces에는 piece length 크기로 나눈 조각들의 SHA-1 해시가 이어 붙여져 있습니다.

여러 피어에서 조각의 블록을 내려받으며, 종료 단계인 endgame 모드에서는 남은 블록을 여러 피어에 중복 요청하고 먼저 도착한 응답을 사용할 수 있습니다. 조각 내부의 범위 요청은 가능하지만, 조각 전체를 받은 뒤 SHA-1을 계산해야 검증할 수 있습니다.

iroh-blobs는 BLAKE3 검증 스트리밍을 사용하여 Iroh 연결로 블롭을 공유합니다. 이 방식은 루트 해시 하나만 필요하며, piece length 매개변수나 개별 조각의 해시 목록이 필요 없습니다. 중간 해시를 미리 갖고 있지 않아도 큰 블롭의 임의 부분을 검증할 수 있습니다.

세밀한 검증이 가능한 스트리밍 프로토콜은 BitTorrent 전송 방식보다 낫지만, 단일 블롭을 여러 제공자에게서 효율적으로 내려받는 기능은 추가 작업이 필요합니다. BLAKE3와 Bao 심층 설명 영상에서는 검증 스트리밍, 별도 검증 데이터 인코딩(outboard encoding), 범위 요청을 다룹니다.

Mainline이 빠르게 작동하는 이유

Mainline DHT는 트래커에 의존하지 않고 콘텐츠 제공자를 찾게 합니다. 모든 조각의 해시가 들어 있는 .torrent의 info 영역을 SHA-1으로 해싱합니다. 그리고 announce_peer로 해당 해시의 제공자임을 알리고, get_peers로 제공자를 조회합니다.

각 DHT 노드는 많은 제공자 정보를 저장하며, 여러 현대적 프로토콜도 DHT를 사용하지만, Mainline은 매우 크고 안정적인 공개 DHT이며 많은 대안보다 잘 작동합니다. 극단적인 최소주의로 노드당 연결 상태를 줄이고, 요청과 응답을 각각 단편화되지 않는 UDP 패킷 하나에 담습니다.

제공자 레코드에는 DHT 노드에서 관찰한 공개 host:port만 저장하며, 사용자 정의 정보는 없습니다. announce_peer에서 포트를 선택할 수는 있지만 16비트에 불과해 32바이트 EndpointId를 모두 사용할 수 없습니다.

넣기에는 부족함
BEP 44 확장도 자체적으로 검증 가능한 작은 데이터나 서명 레코드를 사용하고, 일반적인 MTU에 들어가도록 제한함
데이터를 쓰려면 먼저 노드를 조회하고 응답의 단기 토큰을 반환해야 함. 게시 시점에 자신이 알린 IP 주소로 패킷을 받을 수 있음을 입증하는 방식으로, QUIC의 주소 검증 토큰과 비슷함
Mainline 조회가 보통 1초 미만 에 완료됨
n0-mainline 의 get_mutable

예제로 pkarr 레코드를 조회한 실제 실행에서는 첫 결과가 37밀리초 만에 도착함
글로벌 규모에서도 밀리초 단위 DHT 조회가 가능함
UDP 주소를 Iroh 식별자로 연결하는 인덱스
Mainline 제공자 레코드는 IPv4 host:port

이지만, Iroh는 현재 Ed25519 공개 키인 EndpointId
로 연결함
따라서 해당 주소에 어떤 EndpointId
가 연결돼 있는지 알아야 함
이 주소는 대부분 NAT 뒤에 있어 직접 접근할 수 없음
BEP 44 등 기존 Mainline 기능으로 매핑을 저장하는 여러 방법을 시도했지만 현재는 불가능해, 별도 udp-addr-index
서비스를 추가함
주소 인덱스는 검증된 UDP 주소마다 최대 1KiB의 임의 메타데이터를 저장하는 단순한 서비스임
단일 패킷 UDP 프로토콜만 사용하며, Mainline 자체가 UDP를 요구하므로 UDP를 보낼 수 없는 경우는 처리하지 않음
쓰기는 Mainline이나 QUIC 토큰과 유사한 방식으로 해당 주소의 수신 가능 여부를 검증함
읽기에는 이 검증이 필요 없지만, 증폭을 막기 위해 패딩을 넣은 요청 패킷을 요구함
매핑은 마지막 쓰기 우선(last writer wins) 방식이며 일정 시간이 지나면 만료됨
제공자는 주기적으로, 그리고 공개 UDP 주소가 바뀔 때마다 갱신해야 함
현재 구현은 메모리에만 저장함. 어차피 주기적 갱신이 필요하므로 영속성을 없애 운영을 단순하고 저렴하게 유지함
공개 UDP 소켓이 있는 작은 서버 한 대로 수백만 Iroh 엔드포인트의 주소 인덱스를 운영할 수 있음
이 서비스는 Iroh에 의존하지 않으며, Mainline을 쓰는 다른 애플리케이션에도 활용할 수 있음
장기적으로는 일반적인 BitTorrent Mainline 확장이 이 기능을 맡기를 기대함

서명 레코드가 보장하는 범위
엔드포인트 탐색용 레코드에는 엔드포인트 ID, 현재 UDP 소켓 주소, 타임스탬프를 넣고 엔드포인트 개인 키로 서명함
키 소유자만 유효한 서명 레코드를 만들 수 있어 다른 엔드포인트를 사칭할 수 없음
주소 인덱스 서비스 자체는 엔드포인트 정보를 검증하지 않음
get_peers
와 주소 인덱스가 반환하는 것은 콘텐츠를 제공할 수도 있는 후보 엔드포인트 목록일 뿐임
엔드포인트 탐색은 콘텐츠에만 한정되지 않으며, 가십 주제의 피어를 찾는 예제 도 있음

콘텐츠 공지와 탐색 절차
공지와 탐색 모두 Mainline DHT 노드가 필요하며, 기존 iroh-mainline-address-lookup
과 마찬가지로 n0_mainline
크레이트를 사용함
제공자는 DHT와 같은 UDP 소켓으로 주소 인덱스에 서명 레코드를 게시해 소켓과 EndpointId
를 연결함
n0_mainline은 자체 소켓으로 임의 UDP 패킷을 보내고 들어오는 패킷을 가로챌 수 있음
레코드는 주기적으로 갱신하고, 공개 host:port가 바뀌면 즉시 갱신함
Mainline의 키 공간은 20바이트이므로, BLAKE3 해시를 다시 SHA-1으로 해싱한 뒤 announce_peer

공지함
제공자 공지도 주기적으로 반복해야 함
SHA-1의 충돌 저항성은 깨졌지만 실용적인 역상 공격은 알려져 있지 않음
DHT는 후보 제공자를 찾는 최선형 수단일 뿐임. 다운로드 데이터는 원래 BLAKE3 해시로 검증하므로 잘못된 DHT 결과는 시간을 낭비하게 할 수 있어도 잘못된 콘텐츠를 수락하게 하지는 못함
탐색자는 먼저 작동하는 주소 인덱스 서비스(address index service)를 하나 이상 찾음
서비스가 스스로 공지하는 랑데부 해시(rendezvous hash)와, 선별한 서비스 목록을 담은 BEP 44 레코드라는 두 방식을 지원함
공지 측과 탐색 측이 같은 랑데부 해시 또는 BEP 44 레코드 이름을 사용해야 함
원하는 BLAKE3 해시의 SHA-1 값을 계산해 get_peers를 호출하고, 반환된 주소들을 주소 인덱스를 통해 EndpointId로 변환함
아직 검증되지 않은 후보에 빠른 BLAKE3 크기 조회를 보내 살아 있고 원하는 콘텐츠를 제공하는지 확인함
이후 iroh-blobs 다운로더에 넘겨 실제 데이터를 내려받음
실제 QUIC 연결은 공지된 UDP 주소를 통하지 않음
EndpointId와 Iroh 내장 주소 조회 및 홀 펀칭(hole punching)으로 연결함
공지된 host:port는 주소 인덱스의 조회 키일 뿐임
실험 구현과 데모
iroh-content-discovery 저장소에 주소 인덱스 서비스, 프로토콜, 클라이언트와 이를 활용하는 크레이트(crate)를 구현함
blobs 예제는 게시부터 탐색과 다운로드까지 실행함
게시와 조회를 한 프로세스에서 실행하지만 실제 탐색은 Mainline과 주소 인덱스를 거침
예제 실행에서는 제공자 주소를 EndpointId로 변환하고 44바이트를 다운로드해 검증함
블롭 탐색은 sendme 같은 도구와 대용량 데이터 전달에 유용하지만, 허가 없이 웹사이트를 게시하려면 추가 구성 요소가 필요함
콘텐츠 주소 링크와 브라우저 확장
콘텐츠 주소 링크는 항상 BLAKE3를 사용하며, 전역 이름 공간으로 blake3.net 도메인을 확보함
blake3.net에 공개 게이트웨이를 운영하는 대신, 브라우저 확장이 링크를 http://<hash>.blake3.localhost:<port>로 바꿈
확장은 링크 변환만 수행하며 포트는 설정 가능함
Brave, Chrome, Firefox에서 작동함
Chrome과 Brave용 iroh link는 Chrome Web Store에서 설치할 수 있음
Firefox 확장은 심사 대기 중이며, 현재는 서명되지 않은 XPI를 내려받아 Firefox 140 이상에서 임시 확장으로 로드해야 함
about:debugging#/runtime/this-firefox의 `

링크를 제공할 수는 있지만 도메인 등록 업체와 호스팅 업체가 필요하므로, 목표로 하는 무허가 게시와는 다름
pkarr는 키 쌍에 대한 DNS 레코드를 게시하는 표준으로, 비밀 키 소유자만 새 버전을 게시할 수 있음
브라우저와 게이트웨이에 맞춰 pkarr.net

도메인을 확보하고 링크 변환 및 조회 기능을 추가함
<name>.pkarr.net

여기서 name은 Ed25519 공개 키를 zbase32로 인코딩한 값임
확장은 이를 <name>.pkarr.localhost:<port>
게이트웨이는 pkarr 레코드를 조회해 리디렉션하거나, 레코드가 hash.blake3.net을 가리키면 콘텐츠를 직접 제공함
이 구조는 IPNS와 매우 비슷하며, 앞서 Iroh Pkarr Naming System이라는 소규모 실험도 진행함
pkarr-publish-resolve 예제는 이름 게시부터 독립 클라이언트의 검증 다운로드까지 실행함
키 쌍 생성, 블롭과 이름 게시, 별도 DHT 클라이언트의 이름 조회, 제공자 탐색, 다운로드 순서로 진행함
실행 예에서는 서명 레코드를 검증하고 35바이트 콘텐츠를 8.24초에 내려받아 BLAKE3로 검증함
pkarr 이름은 허가 없이 생성할 수 있지만 사람이 읽기 편하지는 않음
Zooko의 삼각형이 보여주는 절충처럼, 분산성과 암호학적 검증 가능성을 갖추는 대신 52자 공개 키는 기억하기 어려움
사람이 읽기 쉬운 명명 시스템과 결합하면 기억하기 쉽면서 대상을 허가 없이 바꿀 수 있는 이름을 만들 수 있으며, 이를 위한 아이디어를 검토 중임
iroh-share로 지속 게시
기존 웹사이트는 서버 디렉터리에 파일을 복사하면 되지만, 콘텐츠 주소 데이터와 pkarr 레코드에서는 사용자 자신이 게시자 가 됨
iroh-share는 게시를 단순화하는 도구로, 별도 사용자 인터페이스를 갖춘 데몬 형태의 sendme와 비슷함
콘텐츠 주소 데이터와 pkarr 레코드 모두 지속적인 공지가 필요해, 항상 켜 둔 소형 장비나 클라우드 VM에서 실행할 수 있음
실제로 NAT 뒤의 오래된 Synology NAS에서 운영하며 직접 연결도 이루어짐
GitHub 릴리스에서 받을 수 있음

한계와 다음 단계
사용자는 원하는 콘텐츠만 지정하면 게이트웨이가 가져오는 단순한 인터페이스를 얻지만, 그 아래 시스템에는 개선할 부분이 많음
Mainline은 확장성이 높지만 인터넷의 모든 콘텐츠를 주소화하는 규모까지 감당하기는 어려울 수 있음
DHT 트래픽이 암호화되지 않아 중간 네트워크 장비가 쉽게 차단할 수 있음
pkarr의 Ed25519 명명 체계는 양자 내성을 갖추지 못함
Mainline은 프라이버시를 제공하지 않으며, 콘텐츠를 공유하면 누구나 공유자의 IP 주소를 조회할 수 있음
현재는 글로벌 콘텐츠 탐색의 기초를 마련하는 단계 임
Mainline 확장이나 Iroh 연결을 사용하는 자체 DHT 구현 등을 통해 내부 시스템을 개선할 수 있음
이런 개선 과정에서도 사용자 인터페이스는 안정적으로 유지할 수 있음
자주 사용하는 프로토콜 irpc,
iroh-gossip,
iroh-blobs의 1.0을 준비 중임
엔드포인트 탐색은 여전히 실험적이지만 관련 크레이트는 모두 crates.io에 공개돼 있음
댓글과 토론