[케블리] #8. IPFS(InterPlanetary File System)이해하기 1부 : HTTP Web을 넘어서, IPFS Web으로

kblock (58)in #kr • 6 years ago (edited)

Kblock 공식 리서치팀, 케블리

안녕하세요 케블리 입니다. 케블리는 '전세계의 블록체인 비즈니스를 함께 찾고 공부해 나눈다’는 KBlock의 목표에서 ‘나눈다’를 본격적으로 실천합니다.

#8. IPFS(InterPlanetary File System)이해하기 1부 / HTTP Web을 넘어서, IPFS Web으로

1 | 인터넷(Internet)과 웹(Web)

인터넷은 연결이며, HTTP 프로토콜은 서로 데이터를 주고받는 방식에 대한 약속, Web은 인터넷 상에서 HTTP 프로토콜에 따라 주고받는 공간

일상적으로 우리는 인터넷과 웹을 동의어처럼 사용합니다. 그러나 엄밀하게 말하면 둘은 다음과 같이 구별할 수 있습니다.

인터넷은 방대한 네트워크, 혹은 네트워크 인프라를 의미합니다. 인터넷에 연결되어 있다면, 컴퓨터는 다른 컴퓨터와 통신이 가능합니다. 이 때, 데이터는 다양한 프로토콜에 따라서 주고받을 수 있습니다. 프로토콜은 통신할 때에 지켜야하는 규칙을 의미하며, 누구나 새로 창조할 수 있습니다. 다만 많은 사람들이 사용해야 그 의미가 있겠죠.

World Wide Web, 혹은 줄여서 웹(Web)은 인터넷을 통해 데이터를 얻는 방법 중 하나에 지나지 않습니다. 이는 인터넷 계층 위에 설계된 데이터공유 모델입니다. 웹은 HTTP 프로토콜을 사용합니다. HTTP 프로토콜은 인터넷 상에서 데이터를 송수신하는 하나의 규약입니다.

HTTP 프로토콜은 현존 가장 성공한 파일 분배 시스템입니다. 브라우저(Internet Explorer, Firefox, Chrome 등)를 통해 누구나 쉽게 하이퍼링크로 연결된 웹 페이지들에 접근할 수 있게 되었고, HTTP요청으로 얻은 결과를 그래픽, 사운드, 문자, 비디오 등의 형태로 볼 수 있게 되었습니다. HTTP는 엄청난 기술적 사회적 충격을 주었습니다. HTTP는 인터넷 상에서 말그대로 파일을 주고받는 핵심 규약이 되었습니다.

2 | 기존 HTTP Web의 문제점

HTTP Web은 불안정적이고, 중앙화 되어있으며, 비효율적이고, 느리며, 고도의 연결성을 필요로 합니다.

(1)HTTP Web은 불안정(brittle, low resiliency)합니다

HTTP 프로토콜은, 클라이언트(우리)가 서버(위키피디아)에 데이터요청(request)을 보내면, 서버에서 응답(response)하며 데이터를 보내주는 구조로 되어있습니다. 따라서
만약 서버의 전원이 차단되면 링크가 끊겨버리고, 해당 컨텐츠에 대한 접근할 수 있는 방법이 없습니다. 만약 위키피디아 서버가 해킹되어 모든 데이터가 삭제된다면, 현대판 분서(焚書, book burning)가 일어나는 것과 다름 없겠네요.

또한 웹서핑을 하다보면 404 Error를 목격하는 경우가 종종 있는데, 404 상태 코드는 요청한 페이지를 찾을 수 없다는 의미로, 컨텐츠가 삭제되거나 알 수 없는 곳으로 옮겨졌음을 의미합니다. 불에 타 재가 된 책을 목격하신 셈입니다.

보통 이러한 일이 발생하는 이유는 간단합니다. 데이터가 집중된 중앙화된 서버가 백업 없이 고장나거나 닫히는 경우, 도메인 주인이 바뀐 경우, 서버를 운영하던 기업이 해산한 경우 등 많은 원인이 있을 것입니다.

(2)HTTP Web은 이미 고도로 중앙화(Hyper Centralization)되었습니다.

웹의 태생적 목표는 탈중앙화(decentralization)였습니다. 그러나 오늘날의 웹은 수억명의 사람들이 소수의 서비스에 의존하게 되면서 굉장히 빨리 중앙화되었습니다.

그래도 좋은 서비스를 이용할 수 있으니 괜찮다고 생각하실 수 있겠지만, 이는 HTTP가 전혀 의도하던 방향이 아닙니다. 미국의 NSA 혹은 우리나라의 국정원은 이제 몇 개의 서버만으로 우리를 철저하게 감시할 수 있습니다. 이제는 정부 마음대로 특정 컨텐츠를 차단해버릴 수도 있습니다. 해당 컨텐츠를 갖고있는 서버만 닫아버리면 되니까요. 중앙화된 서버는 또한 DDoS공격이 성공할 경우 치명적인 결과를 더욱 큰 피해를 야기할 수 있습니다

Web 분산화를 통하여 소수의 강력한 기관들이 Web을 제멋대로 주무를 수 없게 할 수 있습니다. 이는 곧 우리의 자유와 독립성 증진으로 이어질 것입니다. 또한 Web이 분산화된다면, 큰 기관 하나 무너지더라도 수많은 데이터가 유실되는 경우를 방지할 수 있을 것입니다.

(3)HTTP Web은 비효율적(inefficient)입니다.

강남스타일 뮤직비디오의 용량은 117MB입니다. 강남스타일은 현재 누적 31억 뷰를 자랑하고 있습니다. 그러나 이것은 자세히 생각해보면, 유튜브 서버에서 31억 번의 request를 받고, 총 362,700,000,000MB(117MB X 31억)를 유저들에게 전송했다는 것입니다. 이는 360.7PB의 데이터가 전송되었다는 것이며, 1GB 전송에 100원이 소요되었다고 계산해도 3,627,000,000원(36억 2700만 원)이 파일 분배에 소모되었음을 의미합니다.

종전까지는 작은 용량의 파일을 전송하는 데에 별다른 비용이 들지 않았기 때문에 우리가 파일 전송 효율성에 크게 관심을 갖지 않았으나, 우리가 인터넷 상에서 향유하는 파일(정보, 데이터)은 점점 그 용량이 증가하고 있습니다. 일례로, 스트리밍 서비스로 시청하는 영상의 질이 상승하면서 그 용량 또한 폭증하였습니다. 한가지 더 지적할 사항은, Bandwidth 발전 속도가 다른 Storage 발전속도를 따라가지 못한다는 것입니다. 이는 결국 상대적으로 통신속도가 느려진다는 것을 시사합니다.

(4)HTTP Web은 느립니다(Latency Problems).

개인적으로 라즈베리 파이3에 OS인 라즈비안을 설치하기 위해 공식 사이트에서 다운로드 받는데 속도가 매우 느렸습니다. 공식 사이트도 이 문제를 잘 알고 있는지 토렌트를 이용하여 다운로드 하는 것을 추천하더군요. 속도 차이가 어마어마했습니다.

빛으로 통신하고 있기 때문에 빛의 속도를 넘어설 수 없습니다. 따라서 지리적으로 가까운 곳에 서버(혹은 데이터센터)가 존재하면 아무런 문제가 되지 않지만, 서버가 굉장히 먼 지역에 위치하면 파일(혹은 정보, 데이터) 전송이 그만큼 느려집니다. 대한민국에서 미국 사이트에 접속할 때, 국내 사이트를 이용하는 것보다 꽤나 느린 것을 모두 체험해 보셨죠. 서비스 업체들은 세계 곳곳에 데이터 센터를 설립하는 방법으로 대응해왔습니다.

구글 데이터 센터 분포도

(5)Overdependence on the Internet Backbone

특정 서버의 데이터를 얻기 위해서는 반드시 그 서버와 연결되어 있어야 합니다. 인터넷 연결이 끊어지는 상황이 발생하면(예를 들어, 개발도상국의 통신선 미비, 자연재해로 인한 유실 등) 해당 서버에 접근할 수 없기 때문에 원하는 데이터를 얻을 수 없습니다. 이렇게 인터넷 연결에 과도하게 영향을 받는다는 문제가 있습니다.

3 | 오늘날의 Data Distribution 트렌드

Lots of Data, Accessible Everywhere

HTTP가 이 오랜 기간동안 꾸준히 잘 이용되어 온 이유는 작은 파일들을 이동하는 것은 트래픽 많은 작은 기관들에게도 상대적으로 저렴했기 때문입니다. 그러나 오늘날의 데이터 분배는 새로운 문제에 직면하고 있습니다.

이 부분은 백서의 내용을 그대로 옮겼습니다. 백서에 따르면 :

(A) Hosting and distributing petabyte datasets (B) Computing on large data across organizations (C) High-volume high-definition on-demand or real-time media streams (D) Versioning and linking of massive datasets (E) Preventing accidental disappearance of important files

요약하면, 엄청난 양의 데이터를 어디서든 접근할 수 있도록(Lots of Data, Accessible Everywhere) Web이 진화해야한다는 것입니다.

4 | IPFS(InterPlanetary File System)

위에 제시한 문제들에 대한 해결책으로 제시된 것이 바로 IPFS입니다.
InterPlanetary File System(IPFS)는 모든 컴퓨터를 연결하고자 하는 분산된 P2P 파일 시스템입니다. InterPlanetary라는 표현이 사용된 이유는 지구 상의 컴퓨터 뿐만 아니라 다른 행성의 컴퓨터들까지 모두 연결하겠다는 IPFS팀의 비전이 담겨 있습니다.

IPFS Web는 기존의 HTTP Web의 문제점을 해결하고 보완한 새로운 Web입니다. IPFS가 어떻게 기술적으로 구현되었는지 알아보기 전에, IPFS가 어떤 특징을 갖고 있는지 알아보겠습니다.

‘파일’을 데이터, 정보, 컨텐츠와 동의어라고 생각하고 읽어주세요!

IPFS의 특징

중앙화된 서버 없이 노드들의 P2P 통신으로 실현한 더 빠르고 안전하고 열린 네트워크 입니다. 대형 서버의 연결이 차단되면 치명적인 결과를 낳는 과거 HTTP Web과는 달리, IPFS에서는 몇몇 노드들이 연결이 끊어지더라도 생태계가 안정적으로 유지됩니다.
고용량의 파일을 빠르고 효율적이게 전달할 수 있으며(BitSwap), 파일들의 중복을 알 수 있기 때문에 저장소도 효율적으로 사용할 수 있습니다(Merkle DAG, contents-addressed)
IPFS 상에 업로드된 파일의 이름은 영원히 기록되며, 만약 IPFS 상에서 지키고 싶은 파일은 원하는 만큼 지켜낼 수 있습니다(pinning). 또한 파일의 버전 관리(Git)가 가능합니다.
주류 인터넷에 원활하게 접속할 수 없는 상황이더라도 IPFS의 생태계는 유지됩니다.

How IPFS works?

각각의 파일은 여러 개의 블록으로 이루어져 있으며, 각각의 블록은 해시로 표현된 고유의 이름이 있습니다.

IPFS는 모든 파일의 이름을 데이터베이스 속에 저장하며, 동일 파일의 중복을 배제하며, 각 파일의 버전 정보를 트래킹합니다.

각 노드는 본인이 관심있는 파일만 저장소에 보관하며, 인덱싱 정보를 통해 누가 어떤 파일을 저장하고 있는지 알 수 있습니다.

네트워크에서 파일을 찾기 위해서는, 파일명을 조회하고 해당 파일을 갖고 있는 노드를 물어보면 됩니다.

IPNS를 통해 모든 파일명은 인간이 읽기 쉬운 형태(DNS와 유사한 개념)로 변환할 수 있습니다.

5 | IPFS은 어떤 기술들을 기반으로 하고 있는가?

Distributed Hash Table, BitTorrent, Git, SFS

IPFS Web은 사실 오늘날의 다양한 기술들의 조합입니다. 실제로는 모두 조화롭게 상호작용하며 사용되지만, 이를 계층별로 분석하면 다음과 같이 그려볼 수 있습니다.

1. Distributed Hash Tables(DHT) - Routing

DHT란 무엇인가?

네트워크에 참여한 노드들이 해시 테이블을 각자 관리하므로써 중앙화된 서버 없이 고도의 P2P 네트워크를 실현할 수 있으며, 이를 분산 해시 테이블(Distributed hash table, DHT) 기술이라고 말합니다.

우리가 어떤 파일을 찾아갈 때 해시 테이블을 이용하는데, 중앙 시스템이 아닌 각 노드들이 이름을 값으로 맵핑하는 기능을 하는 방식입니다. 파이썬으로 치면, 해시테이블은 dictionary에 해당하는 개념입니다.

어떤 방식으로 DHT를 운영하느냐에 따라서 얼마나 빠르고 효율적으로 네트워크 요청을 소화해낼 수 있는지 그 역량이 결정되며, 노드의 네트워크 진입/이탈, 신규 컨텐츠 등록 등이 어떻게 관리되는 지 달라집니다.

Kademlia DHT에 대한 설명은 이 영상을 참고하세요.

DHT는 순수 P2P라도 네트워크의 부하를 억제할 수 있으며 네트워크 상의 콘텐츠를 빠르고 정확히 검색할 수 있는 것이 가능합니다. 종래의 순수 P2P에서 채용되었던 방식에서는 수십만 노드 정도가 한계였으나, DHT의 사용으로 수십억개의 노드를 검색범위로 할 수 있게 되었습니다.

DHT를 기반으로 IPFS는 어떻게 디자인 되었는가?

우리가 인터넷을 이용하는 이유는 파일(정보, 즉 컨텐츠)을 검색하기 위함이지, 노드를 검색하기 위함이 아닙니다.

또한 기존의 HTTP에서는 컨텐츠의 위치(IP)를 주소를 알고 찾아갔으나, 앞서 지적한 것처럼 그 위치에 컨텐츠가 더 이상 존재하지 않으면 영영 잃게 되는 문제가 발생했습니다. 따라서 IPFS에서는 컨텐츠 자체를 찾습니다. 컨텐츠 자체가 주소 역할을 하는 것이며, 이를 ‘content-addressed’ 라고 말합니다.

따라서 해시테이블 상에서 컨텐츠 이름을 찾으면, 해당 컨텐츠를 보유하고 있는 노드를 알 수 있습니다.

2. Bittorrent - File exchange

BitTorrent는 P2P 파일 교환 프로토콜입니다. 종전의 방식은 서버가 파일을 가지고 있고 클라이언트가 서버로부터 파일을 받아가는 것이었습니다. 반면 BitTorrent에서는 하나의 파일을 여러 조각으로 나누어, 각 노드끼리 자신이 갖고 있는 조각의 정보를 알려주고 다른 노드들에게 자신이 필요한 조각을 요청합니다. 하나의 노드 다른 노드들과 무수히 많은 세션을 생성하게 되며, 세션이 늘어남에 따라 사용자의 다운로드 속도는 전적으로 늘어나 노드가 사용하는 인터넷 환경의 최대 대역폭까지 다운로드 속도가 증가합니다.

BitTorrent에 대한 자세한 설명은 링크를 확인하세요.
BitTorrent를 눈으로 확인하고 싶으면 BitTorrent Visualization를 확인하세요.

IPFS BitSwap Protocol

BitSwap은 BitTorrent에서 영감을 얻은 프로토콜입니다. BitTorrent에서처럼, Peer들은 본인이 얻고 싶은 파일블록(want_list)와 본인이 갖고 있는 파일블록(have_list)가 있습니다. 그러나, BitTorrent는 하나의 파일을 받고자할 때 그 파일의 블록들만 한정적으로 받아올 수 있는 반면, BitSwap에서는 일치하는 파일블록이라면 어떤 파일에 속해 있든지 받아올 수 있다는 장점이 있습니다.

만약 노드들이 받기만 하려고하고 줄 생각이 없다면 문제가 되겠죠. 이를 해결하기 위해 BitSwap는 기본적으로 물물교환 시스템(barter system)을 표방합니다. 무언가 받기 위해서는 무언가 주어야합니다. 상대방에게 내가 원하는게 있지만, 내가 대가로 줄게 없으면 어떡할까요**? 그러면 그 노드는 열심히 일해서 굉장히 희귀한 파일블록이라도 얻어서 보유해놓아야 합니다- 이는 희귀한 파일블록들이 더욱 배포, 확산되는 효과를 낳습니다.

**filecoin 구상이 시작된 배경이기도 합니다.

또한 BitSwap Credit 시스템을 통하여, 노드들이 peer에게 파일블록을 보내주면, 보낸 노드는 자산이 증가하며, 받은 노드는 부채가 증가하게 됩니다. 결국 평판이 쌓이는 구조이므로 받기만 하려는 어뷰징을 막을 수 있고, 파일블록을 보유하고 보내주는 것에 인센티브가 생기게 됩니다.

BitTorrent에서는 Tit-for-tat(눈에는 눈, 이에는 이) 전략이 표준으로 되어있지만, BitSwap의 노드들은 각자 자신의 전략을 설정할 수 있습니다. 이러한 전략들의 총체는 곧 BitSwap 생태계의 성능을 좌우하게 될 것 입니다. BitSwap과 관련된 세부적인 내용(BitSwap Strategy 예시, BitSwap 자산/부채 장부, 코드(GO) 예시, peer connection cycle 설명은 2부 혹은 백서를 참고하시기 바랍니다.)

3. Git(merkle DAG) - version control systems

IPFS는 네트워크 상에 존재하는 모든 파일을 Merkle DAG 형식으로 정리(organize)합니다. Merkle DAG이란 무엇일까요? Merkle DAG를 이해하기 위해서 Merkle Tree에 대해서 우선 알아봅시다. Merkle Tree는 데이터 구조 중 하나로, 하나의 아버지에 두 아들이 존재하는 'binary tree' 입니다. 연쇄적으로 해시함수가 사용되기 때문에(아버지 해시 = hash(아들1 해시+아들2 해시) ) 데이터가 조금이라도 위변조 될 경우, 가장 꼭대기에 존재하는 root hash가 달라지기 때문에, 간단하게 데이터 무결성을 확인할 수 있습니다.

Merkle Tree

Merkle DAG는 Merkle Tree와 약간 다릅니다. 차이점은 Merkle DAG에 설명되어 있습니다.
요약 : Merkle DAG가 더 일반적인 개념인 것이, Binary Tree는 아니지만 그래프이며, 아무 노드나 데이터를 보유할 수 있다는 점입니다. - Merkle Tree에서는 leaf node(가장 아래 세대의 노드만 데이터 보유 가능)

Merkle DAG

Merkle DAG 구조를 통해, IPFS는 다음과 같은 세가지 중요한 특성을 갖습니다.

Content Addressing : 모든 컨텐츠는 그 자체가 링크이며, multihash checksum으로 그 무결성을 확인할 수 있습니다.
Tamper resistance : 모든 컨텐츠는 자체적으로 checksum으로 무결성을 확인할 수 있고, 위변조시 merkle root의 hash값이 변경되기 때문에 IPFS 자체적으로 감지할 수 있습니다.
Deduplication : 같은 컨텐츠는 같은 해시값을 갖기 때문에, Merkle DAG 상에서 컨텐츠가 중복되지 않습니다.

4. SFS(Self-certified FileSystems)

IPFS의 name system인 IPNS를 시행하기 위한 기반 기술입니다.
주소는 /sfs/(Location):(HostID)의 형식으로 표현되며, 여기서 Location은 서버의 주소입니다. HostID는 hash(서버가 제공한 공개키 + Location)입니다.
따라서 이용자는 서버가 제공한 공개키를 통해, 그 서버가 ‘주소와 일치하는 서버’임을 확인할 수 있는 것입니다.

IPNS

파일이름(엄밀히 말하서 파일들의 해시값입니다)을 기준으로 Merkle DAG을 형성하였습니다. 모든 파일은 각각 영구적인, 변경할 수 없는 이름이 생긴 것입니다. 하지만 때로는 변경 가능한 이름이 필요하기도 합니다. 이를 위해 DNS(Domain Name System)처럼, IPFS 상에서는 IPNS를 통해 변경가능한 이름을 만들 수 있습니다. IPNS 주소 또한 self-certification이 가능하도록 설계되었습니다.

6 | 1부를 마치며

1부에서는 IPFS가 탄생한 배경, IPFS는 어떤 특징을 가지는지, 그리고 어떻게 작동하는지에 대해서 살펴보았습니다. 또한 IPFS가 기반으로 하는 기술들과 그것들이 어떻게 IPFS에 적용되었는지 간략하게 살펴보았습니다. 앞으로 구체적으로 IPFS가 어떻게 디자인 되었는지, IPFS가 블록체인과 어떤 관련성을 갖는지, IPFS와 filecoin은 어떤 관계인지, IPFS와 관련된 다양한 주제들을 소개하도록 하겠습니다. 마지막으로 IPFS와 filecoin을 창조한 Protocol Labs의 Juan Benet의 사진을 첨부합니다. 감사합니다.