명명된 데이터 네트워킹 프로젝트(이하 NDN)는 네트워크 분야의 정보 중심 플래그십 프로젝트입니다. 이 프로젝트는 네트워크 계층, 메시지 중심(즉, 콘텐츠 주소 지정 가능) 프로토콜 스택을 구축하고 있습니다. 약 10년 전에 시작하여 NSF의 자금 지원을 받아 미국의 10개 대학과 협력했습니다.
IPFS와 NDN은 콘텐츠 주소 지정이 가능한 네트워크라는 동일한 비전을 공유하지만 매우 다른 방식으로 작동합니다. NDN은 기본 네트워크 계층 모델이고 IPFS는 애플리케이션 계층 모델입니다.
프로젝트의 공통된 비전을 고려할 때 쇼케이스 세션, 특히 토론과 피드백에 대해 매우 기대하고 있습니다. 총 20명이 넘는 사람들이 연설에 참여했습니다.
다음은 프레젠테이션 중에 받은 질문을 요약한 것입니다.
Q: 블록 크기는 어떻게 됩니까? 사용자가 다른 크기의 블록을 사용할 수 있습니까?
A: 사용되는 기본 블록 크기는 256KB입니다. 예, 사용자/응용 프로그램은 ipfs add 명령의 -s(--chunker) 옵션을 사용하여 청크 크기와 청크 알고리즘을 정의할 수 있습니다.
Q: Merkle-Tree는 어떻게 만들어지나요?
A: 사용자가 로컬 IPFS 노드에 파일을 추가하면 Merkle-DAG 구조(Interplanetary Linked Data 또는 IPLD라고 함)가 로컬로 생성됩니다. 파일이 IPFS 네트워크에 게시되면 파일이 다른 노드에 복제되지 않습니다. 이는 클라이언트의 동의 없이 클라이언트의 로컬 저장소에 콘텐츠를 추가하지 않도록 하기 위한 것입니다. 대신 파일은 초기에 요청 시 네트워크에 게시하는 사용자 에이전트에 의해 배포됩니다. 동시에 원본 파일에서 검색하는 모든 노드는 자료 제공자 역할을 하여 콘텐츠에 대한 캐시 네트워크를 생성할 수 있습니다. 파일이 네트워크에 게시되면 검색을 위해 로컬 노드를 가리키도록 "공급자 레코드"가 DHT에 배치됩니다. 네트워크의 다른 클라이언트가 파일의 영구 공급자가 되기를 원하는 경우 파일을 "잠글" 수도 있습니다. 파일을 잠그지 않으면 파일은 결국 "가비지 수집"이 됩니다.
Q: 구조적 관점에서 파일은 어떻게 시스템에 추가됩니까? 특히 무엇을 어디에 추가했는지 세상에 알리는 방법은 무엇입니까? 마찬가지로 다른 사람이 시스템에 추가되었는지 어떻게 알 수 있습니까?
답변: IPFS 아키텍처에는 네트워크에 게시된 파일을 추적하는 메커니즘이 없습니다. 새로 추가된 콘텐츠/CID를 전 세계에 알리려면 "오프밴드"에서 발생해야 합니다. 이 주제는 IPFS 커뮤니티에서 "분산형 검색 엔진"에 대한 지속적인 토론과 많은 관련이 있지만 지금까지 실질적인 결과는 없었습니다. 즉, 이 주제는 Protocol Labs와 커뮤니티 전체에서 많은 관심을 받았습니다. IPNS 및 지원되는 PubSub 프로토콜은 새로 게시된 콘텐츠에 대한 정보를 전파하는 또 다른 방법입니다. 애플리케이션은 이 옵션을 사용하여 애플리케이션 자체의 도메인 내에서 새 콘텐츠에 대한 정보를 전파(즉, 푸시)할 수 있습니다. IPNS가 DHT 위에서 실행되면 풀 기반 작업도 수행할 수 있습니다.
Q: 일부를 검색하려면 Merkle-Tree의 전체 구조가 있어야 합니까? 파일의 일부만 검색하려는 경우 CID 루트는 거의 의미가 없어 보입니다.
A: 사용자는 일부를 검색하기 위해 Merkle-DAG의 전체 구조를 가질 필요가 없습니다. Merkle-DAG(하나 이상의 CID 블록으로 구성됨)의 일부만 검색하려면 사용자가 해당 특정 CID를 보유해야 합니다. 또한 루트 CID 및 경로 표기법을 사용하여 Merkle-DAG의 파일(예: Qmcri6S86LuivUY4FDcM1phu5REXcFYootxn1GsRoqnFN5/path/to/some/file.png)에 액세스할 수 있습니다.
Q: 블록에 CID가 할당되면 블록을 변경할 수 없습니까?
답변: 예, 블록의 CID가 계산되면 영원히 동일하게 유지됩니다. 우리 모두 알다시피 SVN과 git과 같은 버전 제어 시스템에서 이것은 "영구 웹"의 기본 개념입니다. 우리는 이것이 보관 및 배송 시스템의 중요한 속성이라고 생각합니다. 물론 블록 자체는 정적이 아니며 변경할 수 있습니다. 그러나 새 파일의 CID는 이전 파일과 일치하지 않으므로 새 버전을 별도로 추가해야 합니다(콘텐츠가 IPNS를 통해 공개 키로 게시된 경우 제외).
Q: IPFS 네트워크에서 CID를 취소하는 방법은 무엇입니까?
A: 이러한 CID는 영구적이며 특정 항목의 해시이므로 "취소"할 수 없습니다(위의 "영구 웹" 설명 참조). 더 이상 특정 콘텐츠에 대한 액세스를 제공하지 않으려는 사용자는 해당 콘텐츠의 "제공"을 중지하면 됩니다. 즉, 해당 제공자의 레코드 게시를 중지하면 됩니다. 그러나 콘텐츠를 검색한 다른 클라이언트가 여전히 콘텐츠를 캐시에 보관하고 제공할 수 있으므로 콘텐츠가 네트워크에서 사라진다는 의미는 아닙니다. 또한 Protocol Labs에서 제공하는 IPFS 게이트웨이에는 CID 거부 목록이 있습니다. , 이 목록의 CID는 콘텐츠를 보호하기 위해 이중 해시되며 IPFS 게이트웨이는 콘텐츠를 제공하기 전에 콘텐츠가 거부/차단되었는지 확인합니다.
Q: 특정 CID의 제거 상태(예: 거부 목록에 추가됨)를 확인할 수 있습니까?
A: CID가 지정된 게이트웨이의 거부 목록에 있는지 확인하려면 게이트웨이에서 해당 CID를 확인하고 거부되었는지 알려주는 HTTP 응답 코드를 얻을 수 있습니다. 각 거부 목록은 운영 조직에서 개별적으로 유지 관리합니다. 전체 IPFS 네트워크에 대한 전역 거부 목록은 없습니다.
Q: 거부자 목록이 분산 인프라에 속하지 않는 것 같습니다.
A: 모든 개인 또는 조직은 공용 IPFS 게이트웨이를 실행하고 자체 거부 목록을 운영할 수 있습니다. 이러한 의미에서 거부 목록의 (콘텐츠)는 중앙 집중식 엔터티에 의해 결정되지 않습니다.
Q: IPNS 기록은 어디에 보관됩니까?
A: IPNS는 콘텐츠 라우팅, 즉 DHT와 동일한 인프라를 사용합니다. 변경 가능한 콘텐츠를 가리키기 위해 클라이언트 공개 키의 여러 해시가 DHT에 등록됩니다. 한편, IPNS 레코드를 배포하는 다른 방법이 있습니다. gossipsub라는 pubsub 프로토콜(사양이라고도 함)이 IPNS 레코드를 빠르게 배포하는 방법으로 이 목적에 사용됩니다. 앞에서 언급했듯이 IPNS over PubSub와 DHT의 차이점은 푸시(PubSub) 모드와 풀(DHT) 모드의 차이입니다.
Q: 다른 노드는 이름에 대한 올바른 키를 가지고 있는지 어떻게 알 수 있습니까?
A: 노드가 DHT에서 IPNS 이름을 조회할 때 데이터를 저장하기 위해 DHT에서 지정한 모든 클라이언트에서 레코드를 검색합니다. 레코드에는 일련 번호가 있으므로 클라이언트는 IPNS 키에 해당하는 가장 최근 값을 쉽게 확인할 수 있습니다. 조회가 완료될 때까지 기다리는 대신 사용자가 레코드 수신의 쿼럼 Q(현재 Q=16으로 설정됨)를 기다리기로 결정할 수 있는 DHT 조회 바로 가기도 있습니다. 기록.
Q: IPNS 레코드를 저장한 노드가 오프라인 상태가 되면 IPNS 레코드가 손실되고 누군가 24시간 이내에 업데이트하지 않으면 서비스할 수 없습니까?
A: 이것은 정확하며 IPFS 레코드(즉, 불변 CID)의 게시자도 마찬가지입니다. 두 가지 중 하나가 발생할 수 있습니다. 콘텐츠가 요청되었고 이미 다른 노드에서 검색 및 캐시된 경우 캐싱 노드에서 콘텐츠를 제공할 수 있습니다.
콘텐츠를 검색(및 캐싱)한 클라이언트 중 하나(또는 일부)가 콘텐츠를 계속 저장/제공하기로 결정하면 콘텐츠를 "잠글" 수 있습니다. 즉, 콘텐츠의 영구 공급자가 되었음을 의미합니다.
Q: 콘텐츠를 캐싱할 때 시스템은 캐싱된 항목과 이를 사용/파싱하는 방법을 어떻게 알 수 있습니까?
답변: 콘텐츠를 캐시하는 클라이언트는 또한 제공자의 레코드를 DHT에 게시하여 캐시에 있는 모든 콘텐츠 항목의 제공자이기도 함을 선언합니다.
Q: 캐시된 콘텐츠는 콘텐츠의 원본과 동일합니까?
A: 다음 "가비지 수집" 날짜까지 캐시된 콘텐츠를 구문 분석하고 제공할 수 있으며 캐시된 콘텐츠가 "잠기지" 않는 한 만료됩니다(그렇지 않으면 사용자가 변경할 때까지 영구적으로 복사됨). 작성 당시에는 가비지 수집이 기본적으로 해제되어 있습니다.
Q: 무엇을 찾아야 하는지 정확히 알아야 합니다. DHT는 좋지만 그 안에 무엇이 들어 있는지 알기가 어렵습니다. CID와 실제 신원 정보 간의 결합은 어디에서 발생합니까?
A: IPFS는 최종 사용자 대면 콘텐츠 검색에 사용하기 위한 분산 파일 시스템입니다(예: HTTP가 현재 Google 검색 서비스의 사이트를 주소 지정/호스트하는 데 사용되는 방법). IPFS는 특정 CID에 대한 콘텐츠 제공, 저장 및 가져오기를 관리합니다. 나머지(사용자를 해당 앱과 연결된 CID에 연결하거나 처음에 앱을 찾는 것)는 IPFS 자체보다 상위 계층에서 발생해야 합니다.
Q: 대화 초반에 네트워크(즉, 외부 엔터티)에서 신뢰를 제거하는 것이 목적이라고 언급하셨습니다. 자세히 설명해 주시겠습니까? 특정 콘텐츠가 특정 키로 게시된다는 것을 어떻게 신뢰할 수 있습니까?
A: 자체 해시로 콘텐츠 이름을 지정하고 분산 P2P 네트워크에 게시하면 기본적으로 콘텐츠 호스팅 및 콘텐츠 해결 엔터티와 같은 외부 엔터티를 신뢰하는 것과 관련된 일부 문제를 극복할 수 있습니다. 콘텐츠는 자체 유효성 검사이므로 로컬에서 확인할 수 있습니다. 콘텐츠가 게시자의 개인 키로 서명되는 한 콘텐츠 소비자는 외부 엔터티에 의존하지 않고 콘텐츠의 진위를 확인할 수 있습니다.
이 강연에 참석해주신 모든 분들과 이 행사를 준비하고 초대해주신 NDN에 감사드립니다!
