장미, 제비꽃, 수선화를 본 적이 있다면 꽃이 무엇인지에 대한 간단화된 직관을 가진다. 하지만 히노라 아프리카나(Hydnora Africana) 공상과학 몬스터, 거대한 시체꽃, 스와들 베이비(Swaddled Babies) 또는 웃는 벌 난초(Bee Orchids)와 같은 특이한 품종을 포함한 세상의 더 많은 꽃식물을 발견하면서 꽃에 대한 이해도가 높아지고 특정 시점에 어떤 것이 꽃인지에 대해 궁금해하기 시작한다.

2022년 7월, IPFS 커뮤니티의 건축가, 구현자 및 헌신적인 빌더의 핵심 그룹이 아이슬란드 레이크자빅(Reykjavik, Iceland)에서 IPFS 프로토콜 구현 확장 및 다각화에 초점을 맞춘 사상 최초의 모임인 IPFS þing을 위해 만났다.

이벤트의 시작은 IPFS를 오늘날의 다면적인 소프트웨어 환경에서 가능한 한 사용 가능하고 액세스할 수 있도록 하고 Python과 같은 언어 또는 Lite 노드 및 위성 연결과 같은 아키텍처 제약 조건에서 운영할 수 있도록 하기 위한 게이밍에 대한 다양한 구현의 요구로 시작되었다. 그리고 그로부터 9개월이 지난 지금, 바로 그런 일이 일어났다. 지금은 분산형 반구의 봄이고 우리는 IPFS 꽃밭을 뛰어놀고 있다. 이렇게 번성하는 광범위한 에코시스템에서 한발 물러서서 IPFS를 만드는 원리를 살펴볼 가치가 있다.

콘텐츠 목록

• IPFS란?
• 오늘날의 IPFS 구현
• 더 넓은 견해
• IPFS 원칙
  • 콘텐츠 주소 지정
  • 전송에 구애받지 않음
• 더 명확한 기초
• 재회
• 부록: 구현

IPFS란?

퀴즈 시간! 다음 중 IPFS에 해당하는 것은?

• ❓사용자가 IPFS 게이트웨이 URL을 통해 NFT 자산에 연결
• ❓폰에서 웹3.스토리지로 이미지 공유
• ❓깃헙(GitHub)에서 플릭(Fleek)으로 정적 웹사이트의 웹 게시 흐름
• ❓IPFS CID(콘텐츠 식별자) 주소 데이터를 사용한 블루투스 연결을 통한 두 사람의 채팅
• ❓IPFS CID 이미지를 방출하는 위성 신호는 (상대적으로) 높은 대역폭의 6분 창에서 IPFS 연결 지상국에 도움이 된다. 하루에 몇 번씩 수신된다.
• ❓IPFS CID에 의한 정적 컨텐츠 로드 장면, OEM에 의해 하드웨어에 제공된 컨텐츠
• ❓연결 불량 또는 인터넷 제한으로 인해 오프라인 또는 검열저항 소스에서 위키백과를 읽는 사용자

정답: 모두 해당!

이러한 IPFS 사용 방법은 서로 매우 다르지만, 이는 모두 두 가지 주요 특성을 공유한다:

1. 데이터는 콘텐츠에서 생성된 고유 지문으로 처리된다.
2. 따라서 데이터를 전송에 구애받지 않고 사용할 수 있다.

이는 매우 철저한 정의처럼 느껴지지 않을 수도 있지만, 이미 IPFS 구현이 무엇인지 또는 무엇이 아닌지에 대해 많은 것을 알려준다. 오늘날 지형을 살펴보고 구현이 실제로 무엇을 의미하는지 알아보려 한다.

오늘날의 IFPS 구현

IPFS 구현은 데이터 센터에서 오래 살고 수명을 다하는 OS 수준의 데몬(daemon)에서부터 브라우저 탭의 일시적인 반짝임 속에서 실행되는 JavaScript에 이르기까지 매우 다양하다. 현재 사용자가 IPFS에 액세스하고 개발자가 해당 액세스 권한을 제공하는 프로그램을 배포해야 하는 다양한 환경에 존재해야 한다. 이러한 환경 대부분은 가차없으며 모바일 운영 체제 또는 IoT 장치와 같은 호스트의 요구 사항이나 비즈니스 모델에 맞게 사용 가능한 기능을 명시적으로 제한할 수 있다.

개발자가 환경의 최대 제어를 가질 때 원본 백서에 기술된 이상적인 비전에 일치하는 IPFS를 구현할 수 있다. 배포 환경이 이상에서 거리가 멀거나 사용 사례가 매우 다를 때 IPFS 구현은 종종 필요한 모든 수단을 통해 안정적으로 콘텐츠 주소 지정 데이터를 시스템 내부 또는 외부로 가져오는 것을 의미한다.

이러한 요구사항의 다양성은 구현 에코시스템에서 확인할 수 있다. 예를 들어 Go, 자바 및 자바스크립트에서 구현할 뿐만 아니라 러스트(Rust)에서도 구현하여 효율성을 극대화한다. 몇몇은 클러스터 또는 파일코인을 타겟팅하며 모바일 또는 기타 임베디드 환경과 클라우드에서 작동할 수 있다. 그 수는 계속 증가하고 있다.

더 넓은 견해

오늘날의 IPFS 에코시스템은 대부분의 사람이 알고 있는것 보다 규모가 크며 보통 이 중 일부만 사용한다. 이는 IPFS에 대한 제한적인 직관을 가지기 쉽다.

예를 들어, IPFS 지원이 쿠보(Kubo)와의 상호 운용성 또는 쿠보의 모든 기능을 지원하는 것이라는 결론에 도달하기 쉽다. 쿠보는 물론, 뛰어난 구현이지만 다양한 컨텍스트를 타겟팅하거나 다양한 목표를 향하려면 다른 결정을 내려야 하는 이유가 있다. 이는 특히 파일코인에 대한 사실이다. 파일코인 스토리지 제공자가 저장한 데이터를 다른 IPFS 노드가 접근할 수 있게 하는 것은 단순히 로터스(Lotus)를 쿠보로 연결하는 것과는 다르다.

많은 성공적인 프로토콜은 프로토콜의 전체 기능을 활용하거나 어쩌면 완전히 호환될 필요 없이 하나에만 특화된 구현을 지원한다. 예를 들어, 포트 80에서 수신하고, 전송하는 모든 메서드, 경로 또는 헤더 정보를 버리고, 항상 코드 418, 이미지/jpeg로 설정된 컨텐츠 유형 및 본문의 고전적인 예술 작품으로 응답하는 HTTP 서버를 작성할 수 있다. 완전히 호환되는 HTTP 구현이 아닐 수도 있고, HTTP 구현이 매우 유용하지는 않지만, 여전히 HTTP 구현이다. 수백만 개의 HTTP 서버가 HTTP 표준의 모든 것을 지원하지는 않지만, 그럼에도 불구하고 우리의 작은 사고 실험보다 훨씬 더 가치 있는 서비스를 제공한다. 권한으로 http URL을 해결하는 데 사용할 수 있다는 점이 중요하다.

이는 IPFS가 지원하는 유용한 패턴이다. 빠르고 매우 더러운 예시를 주자면(이 부분이 요점이므로), 이 크루드(crude) 24 라인 스크립트는 SHA1 해시에 f017c1114를 접두사로 사용하는 CID를 통해 모든 개체에 액세스할 수 있게 함으로써 깃(Git) 저장소를 IPFS 게이트웨이로 노출한다. 이러한 스크립트는 예를 들어 IPFS 기반 아카이브 시스템으로 깃 저장소를 통합하는 데에 사용할 수 있다. 이는 우아한 구현과는 거리가 멀고 깃을 IPFS로 연결하는 것은 더 깨끗한 접근 방식을 보장하지만, 중요한 점은 최소화된 접근 방식으로 시스템을 IPFS에 결합하는 것이 스위스 아미 나이프(Swiss Army Knife) IPFS 라이브러리 못지않게 합법적인 IPFS 배포라는 점이다.

또한 IPFS 네트워크의 많은 시스템이 공용 DHT(분산형 해시 테이블) 외부에서 피어(peer) 검색 및 콘텐츠 라우팅을 수행한다는 점도 염두에 두어야 한다. 여기에는 게이트웨이뿐만 아니라 mDNS 검색, 가십섭(Gossipsub) 피어 교환, 고정 서비스 클러스터 또는 완전히 별도의 DHT도 포함된다. IPFS에 포함된 내용에 대한 포괄적이지만 원칙적인 관점은 에코시스템을 더욱 풍부하고 가치 있게 만든다.

▲ ipfs 네트워크

IPFS 원칙

IPFS를 구현하고 사용하는 데에 많은 방법이 있으며 위의 관점은 간신히 표면을 긁는 정도다. 하지만 너무 폭넓게 가지 말아야 한다. 모든 것이 IPFS에 일환이라면 우리가 가진 것은 에코시스템이 아니라 관계없는 것들이다. 소프트웨어가 의미 있게 IPFS에 참여하는 방법을 정의하는 구체적인 원칙이 필요하다.

이러한 원칙은 앞서 언급했던 주요 특징에 세부 내용을 제공한다.

1. 1. 데이터는 콘텐츠에 따라 주소 지정된다.
2. 2. 전송에 구애받지 않는 데이터 사용을 허용한다.

콘텐츠 주소 지정

주소 지정은 주소 지정의 속성이 프로토콜의 속성을 정의하는 방법을 쉽게 간과하는 모든 소통 프로토콜의 기초 부분이다. IP 주소는 IANA 및 RIR이 위임하는 계층 권한을 기반으로 로컬 할당을 위해 네트워크 관리자에게 할당된다. HTTP는 서버에 권한을 위임하는 도메인 이름 시스템을 기반으로 하는 http URL 위에 빌드되며, 서버의 운영자는 해당 공간에 있는 이름과 서버가 매핑하는 리소스에 대한 완전한 소유권을 가진다. 계층 및 소유권에 대한 이러한 개념은 웹의 기본 아키텍처 문서에 깊이 뿌리박혀 있으며 웹이 작동하는 방식에 영향을 미친다. 모든 사용자가 DNS에 종속되어 있을 뿐만 아니라 URL을 방문할 때 다른 사용자의 속성으로 명시적으로 정의된 이름과 리소스와 상호 작용한다. 결과적으로, 이는 사용자와의 관계에서 해당 주체에 힘을 부여한다.

IPFS의 첫 번째 정의 특성은 콘텐츠 주소 지정이며, 이는 CID에 제공되는 기본 역할에 반영된다. IPFS는 CID를 사용하여 상호 작용할 수 있는 리소스 공간이다.

이는 이미 여러 가지 결과를 가지고 있다. 우선, CID는 다중 형식을 사용하여 정의되므로 미래에 대비하고 자체 설명 및 확장이 가능하다. 예를 들어, 강력한 새로운 해시 알고리즘이 등장한다면 과거에 갇혀 있거나 모든 것을 업그레이드할 방법을 찾아야 하는 상황이 찾아오지 않는다. IPFS 네트워크에서 점진적으로 롤아웃(roll out)할 수 있다. 이를 생성하거나 사용해야 하는 엔드포인트는 업그레이드해야 하지만 네트워크의 나머지 부분은 상관하지 않는다.

이 접근 방식은 IPFS가 기존의 컨텐츠 주소 시스템과 상호 운용될 수 있다는 것을 의미한다. 일반적으로 IPFS가 사용하는 해시를 CID로 전달하는 데 필요한 작업을 거의 수행하지 않는다.

CID는 강력하고 부하를 견딜 수 있는 기반을 형성하지만, 그럼에도 불구하고 매우 단순하다. 후안(Juan)의 원래 CID사양은 구현하기에 충분히 상세하지만, 단순성에 대한 열정적인 작별 코멘트인 "그게 다야!"를 포함하여 마크다운(Markdown)의 절반 페이지에 불과하다.

▲ 후안(Juan)의 CID 사양

CID에 IPFS를 구축함으로써 사람에게 힘을 부여하는 자가 증명 웹의 길을 닦는다. 로케이션을 통해 권한을 위임하거나 소유권을 주는 것이 아닌, CID는 엔드포인트 간, 사람과 CID가 가리키는 콘텐츠 간의 직접적인 관계다. (그리고 링크로써의 CID에 체계적으로 의존하는 것으로 뛰어난 IPLD도 이와 유사한 이점을 가져온다.)

그리고 콘텐츠 주소 지정은 다음에서 다룰 다른 기초 특징을 활성화하는 주요 요소다.

전송에 구애받지 않음

콘텐츠 주소 지정은 멋지지만, 검색, 이동, 컴퓨팅 혹은 데이터 조작에 더 유용하게 사용할 수 있다. IPFS는 CID를 기반으로 구축되었기 때문에(자체 증명), 콘텐츠의 무결성을 걱정할 필요 없이 모든 전송 계층을 사용할 수 있다.

이러한 전송 불응성은 전체 네트워크를 로컬 또는 특정 요구에 더 잘 적응할 수 있게 하며, 바이트가 어떻게 위치하고 이동하는지에 대한 광범위한 속성을 실험할 수 있게 한다. 미래의 시스템을 보호하고 새로운 제약 조건 하에서 새로운 장소에서 지원되어야 할 때 신속하게 시스템을 지원한다. 개발자는 로컬 또는 오프라인 우선 구축에 대해 걱정할 필요가 없다.

IPFS는 이 접근 방식을 취하면서 프로토콜 설계의 두 가지 오래된 원칙을 재검토하고 업데이트하고 있다. 첫 번째는 견고성 원칙인데, 수년간 서로 다른 방식으로 표현해 왔지만 '보낼 때는 엄격하고 받을 때는 관대하라'고 요약할 수 있다. 견고성 원칙의 공식화는 일반적으로 의심의 여지가 없는 지혜로 받아들여졌지만, 최근 프로토콜 설계 커뮤니티에서 비판을 받고 있다. 프로토콜이 수년에 걸쳐 대규모로 배포되고 해당 구현이 관용적인 측면에서 오류를 범하는 경우 실제로 발생하는 경향은 새로운 구현을 생성하기가 너무 어려워지고 프로토콜이 부패하기 시작할 때까지 상호운용성 결함이 시간이 지남에 따라 누적된다.

프로토콜 붕괴를 피하고 싶지만, 시스템을 새로운 상황에 적응시키는 데 기여하기 때문에 어느 정도의 내성은 바람직하다. 이 문제를 해결하기 위해 IPFS는 한 방향에서는 엄격하고 다른 방향에서는 관용적인 대신 CID가 생성되거나 검증되는 엔드포인트에서는 엄격하며, 그 사이에서는 바이트를 전달하는 모든 방법으로 관용적이다.

"결과에 대해 엄격하고, 방법에 대해 관용적이어야 한다"고 공식화할 수 있는 견고성에 대한 이 새로운 접근은 엔드 투 엔드(end-to-end) 원칙의 구현이다. 엔드 투 엔드 원칙은 프로토콜의 신뢰성 속성이 중간 노드가 아닌 엔드포인트에서 지원되어야 한다고 명시한다. 그리고 이는 CID가 활성화한다.

더 명확한 기초

CID를 이용한 콘텐츠 주소 지정 및 탄탄한 전송 비구애성이 지금의 IPFS를 만든다. libp2p 기반으로 구축하지 않고, 쿠보가 하는 일을 하지 않으며 http 게이트웨이를 통해 검증 가능한 콘텐츠만을 검색하는 IPFS 구현은 여전히 IPFS 구현이다.

이 기초와 그 위에 있는 모든 것을 명확히 하기 위해 IPIP 프로세스의 새로운 발전 및 새로운 사양 사이트를 포함한 더 나은 사양을 개발하고 있다(IPFS Thing 2023 트랙 포함).

IPFS를 정의하는 원칙의 표준화된 설명에 대한 제안서가 사양 작업의 일환이다. 더 자세한 내용을 보려면 읽어보는 것을 추천한다.

재회

기반을 다지는 것은 더 높고 더 나은 건설을 할 수 있게 해줍니다. 다음 IPFS Thing은 브뤼셀에서 4월 15일부터 19일까지 몇 주 앞으로 다가왔다. 커뮤니티로서 이 기회를 활용하여 많은 새로운 IPFS 기능과 구현을 공유, 논의 및 발전시킬 예정이다. 우리는 이 CID로부터 많은 꽃들이 자라리라는 것을 의심하지 않는다.

부록: 구현

docs.ipfs.tech에 있는 구현 테이블은 현재 활발하게 유지 보수되고 있으며 에코시스템이 빠르게 변하면서 최종적인 소스를 찾고 있다면 참고해야 한다. 그러나 예시적인 목적으로, 이 블로그 게시물이 인쇄되는 동안 구현 목록(툴링 및 기타 시스템의 모든 방식은 포함하지 않음)이 있다.

• 일라스틱 프로바이더(Elastic provider) - 자바스크립트, 타입스크립트 - 확장 가능한 클라우드 기본 구현
• 에스츄어리(Estuary) - go - 파일코인에 IPFS 데이터를 온보딩하는 데몬(Daemon) 지향 서비스
• 쿠보 - go - 확장 HTTP RPC API 및 HTTP 게이트웨이 API를 통한 일반 데몬 지향 IPFS 구현
• IPFS 클러스터 - go - CRDT/Raft 컨센서스를 통한 다중 쿠보 노드에 대한 통합
• 아이로(Iroh) - 러스트(rust) - 극효율 지향 IPFS 구현
• 로터스(Lotus) - go - 컨센서스, 스토리지 제공, 스토리지 계약 체결, 데이터 수집 등을 처리하는 파일코인 노드
• 나부(Nabu) - 자바 - IPFS의 최소 자바 구현
• 오스피너(auspinner) - go - 피닝 서비스(pinning service)를 처리하고 빗스왑(bitswap)을 통해 파일을 업로드하기 위한 CLI 툴
• 바지(barge) - go - 워크플로우와 같은 깃(Git)을 통한 CLI 툴을 사용하여 에스츄어리에 델타 업로드
• 부스트(Boost) - go - 데몬을 통해 파일코인 스토리지 제공자 내부 및 외부로 IPFS 데이터 얻기
• 고모바일-ipfs(gomobile-ipfs) - go - 라이브러리 지향 ipfs 데몬을 사용하여 모바일 앱에 쿠보 내장
• 헬리아(helia) - 자바스크립트 - JS 및 브라우저 환경을 위한 간소하고 모듈식의 최신 IPFS 구현으로, 현재는 사전 알파이지만 후에 js-ipfs를 대체
• ipfs-임베드(embed) - 러스트 - 소규모 임베딩 가능한 ipfs 구현
• ipfs-라이트(lite) - go - 쿠보와 동일한 블록에 구축하고 최소 접착 층이 있는 최소 라이브러리 지향 ipfs 데몬
• ipfs-뉴클리우스(nucleus) - go - P2P IPLD 앱에 대한 최소한의 IPFS 대체
• js-ipfs - 자바스크립트, 타입스크립트 - 노드js 및 브라우저에 타겟팅하는 자바스크립트 구현, js-ipfs 개발 현재 중단
• 바이프로스트-게이트웨이 - go - 원격 데이터 스토어 지원의 가벼운 HTTP+웹 게이트웨이 데몬. CID를 검증하고 신뢰할 수 없는(원격) 게이트웨이의 신뢰할 수 있는(로컬) 사용 활성화.

더욱 다양한 정보 및 방송 관련 소식은

공식 SNS 채널을 통해 확인 가능합니다.