kubo v0.14.0은 사용자가 구성 파일에 HTTP 끝점을 추가하여 컨텐츠, 피어 및 IPNS 레코드를 검색하는 방법을 구성할 수 있는 리프레임(Reframe) 프로토콜에 대한 지원을 추가했다. 즉, IPFS 공용 DHT 옆에서 또는 대신 새로운 컨텐츠 라우팅 시스템을 사용하는 것은 이제는 간단하다. 마찬가지로, 리프레임은 퍼블릭 IPFS HTTP 게이트웨이와 같은 애플리케이션이 DHT 노드를 컨텐츠 서비스 노드에서 분리하여 독립적으로 확장 및 로드 밸런싱을 수행할 수 있도록 지원한다.
IPFS Thing 2022의 프레젠테이션에서 리프레임을 활용한 더 많은 정보와 데모를 볼 수 있다.
리프레임을 사용해야 하는 이유
IPFS 공용 DHT는 피어 라우팅(예: 이 피어의 현재 IP 주소), 컨텐츠 라우팅(예: 특정 컨텐츠가 있는 피어 찾기), IPNS 레코드 게시 및 검색 등을 위한 기능을 제공한다.
그러나 IPFS 공용 DHT와 유사한 역할을 수행하지만 다른 속성을 가진 유형의 시스템이 있을 수 있다. 일반적인 IPFS 라이브러리는 새로운 라우팅 시스템에 대한 사용자 지정 코드를 플러그인하는 것을 오랫동안 지원해 왔지만, 프로세스 외 API를 호출하지 않고 지원을 추가하는 것은 더 번거로울 수 있다. 이는 로컬이든 원격이든 새 DNSLink 확인기를 연결하기만 하면 사용자 지정 TLD를 위한 새 DNSLink 리졸버를 추가할 방법과 유사하다.
또한 사용자와 가까운 일부 노드가 요청 받고 다른 노드 또는 시스템에서 데이터를 요청하기 전에 응답할 기회를 갖는 재귀 또는 캐싱 라우팅 시스템에 대한 제안도 있었다. 이러한 라우팅 시스템을 컴포넌트화하는 것은 그들이 말할 수 있는 공유 API를 가지고 있을 때 훨씬 더 쉽다.
이 두 가지 문제를 모두 해결하기 위한 방법으로 리프레임이 설립되었다.
리프레임이란?
리프레임은 두 가지 구성 요소를 가진 요청-응답 프로토콜이다.
- 방법 -> 리프레임 엔드포인트에 대해 수행할 수 있는 다양한 요청(예: 주어진 컨텐츠가 있는 피어를 묻는 FindProviders)
- 전송 -> 요청 및 응답이 이루어지는 방식(예: DAG-JSON을 사용하여 인코딩된 데이터로 HTTP)
예를 들어 HTTP를 통해 FindProviders 요청을 보내려는 경우 전송에 필요한 요청과 응답을 인코딩할 수 있다.
리프레임 조정 프로토콜은 ipfs/specs로 지정되어 있다.
리프레임 유연성
방법과 전송에 대해 추상적으로 정의되는 리프레임의 유연성은 사용자가 전송에 특정한 기능(예: HTTP 헤더)을 사용하는 것을 방해하지 않으면서 전송 내에서 새로운 방법, 새로운 전송 또는 심지어 새로운 데이터 인코딩 방법을 추가하는 것이 상당히 쉽다는 것이다.
운송
예를 들어 HTTP를 사용하는 것이 많은 환경에서 바람직하지만 다른 환경에서는 gRPC를 선호하여 QUIC 또는 보다 일반적인 libp2p 스트림보다 일부 사용자 지정 프로토콜을 만든다. HTTP만 지정되었지만 다른 것이 필요하면 해킹을 시작하고 사양을 올리면 된다.
비슷하게, HTTP + JSON은 사람들에게 친숙하고 기존 툴링과 쉽게 작동하기 때문에 요청을 인코딩하기 위해 DAG-JSON 형식을 사용했지만, 초기 리프레임 사용자 중 일부는 캐시와의 상호 운용성을 개선하기 위해 HTTP GET 요청의 이진 형식을 원했다. 메소드 매개변수가 추상적으로 설명되기 때문에 HTTP 캐시 가능성이 JSON의 사용 용이성보다 더 중요한 경우 GET와 함께 DAG-CBOR 형식을 사용하는 것이 간단했다.
방법
방법 측면에서는 IPNS Get 및 Put을 포함하여 초기 FindProviders 방법 외에 방법를 이미 추가했다. 또한 FindProviders 자체를 확장하여 더 다양한 프로토콜을 지원한다. 더 많은 제안이 진행 중이지만 Reframe이 유용할 것으로 생각되는 새로운 방법이 있는 경우 구현하고 사양 PR을 만들어 사람들에게 작업 중인 내용을 알릴 수 있다.
모든 리프레임 클라이언트 또는 엔드포인트가 모든 방법을 지원하는 것은 아니지만, 공통 사양 및 도구를 사용하면 필요한 부분을 보다 쉽게 지원할 수 있다.
리프레임 구현
서버 구현
현재 두 가지 리프레임 서버 구현은 네트워크 인덱서를 지원하는 StoreTheIndex(스토어더인데스)와 IPFS 공용 DHT 및 네트워크 인덱스(Network Index)와 같은 다른 서비스로 요청을 전달하고 결과를 다시 스트리밍하는 위임된 라우팅 끝점인 썸가이(Someguy)이 있다. go-delegated-routing 라이브러리는 새로운 서버 구현을 쉽게 만들 수 있는 도구를 제공한다.
프로토콜 랩스는 현재 routing.delegate.ipfs.io에서 썸가이 인스턴스를 실행 중이다.
클라이언트 구현
쿠보(Kubo), 하이드라-부스터(Hydra-booster), 썸가이 등 자신의 요청을 처리하기 위해 위임 라우팅 라이브러리를 활용하는 다양한 고객이 있다.
예시
CID의 제공자를 위해 routing.delegate.ipfs.io에서 리프레임 엔드포인트를 쿼리하면 해당 제공자와 해당 제공자에 대한 일부 메타데이터(예: 주소 및 지원 프로토콜)가 반환된다.
이렇게 하면 다음과 같은 결과가 반환된다.
이것들은 두 개의 libp2p 노드가 그들이 콘텐츠를 제공하고 비트스와프 프로토콜의 일부 버전을 지원한다고 광고했음을 나타낸다.
쿠보에 리프레임 지원
쿠보(이전에 go-ipfs)v0.14.0+ 리프레임 엔드포인트에 라우팅 요청 위임을 지원한다. 즉, kubo 인스턴스가 IPFS 공개 DHT가 사용되는 요청 유형에 대해 쿼리되는 추가 시스템을 지원하려면 구성 파일을 통해 수정할 수 있다. 쿠보가 IPFS 공용 DHT의 대체 메커니즘을 사용하는 경우 어떻게 보일지 생각해 본 적이 있다면 이제 알 수 있다.
예를 들어, cid.contact에 엔드포인트에 쿼리 지원은 다음을 통해 지정할 수 있다.
자세한 내용은 https://github.com/ipfs/kubo/blob/master/docs/config.md#routing을 참조하면 된다.
참고: IPFS 공용 DHT 및 다양한 리프레임 엔드포인트를 포함하여 쿠보에서 사용되는 여러 라우팅 시스템에 걸쳐 라우팅 구성을 균일화하기 위한 추가 작업이 여기서 진행되고 있다.
더욱 다양한 정보 및 방송 관련 소식은
공식 SNS 채널을 통해 확인 가능합니다.
