▣ HTTP
기존 인터넷에서 우리가 정보를 찾는 과정을 생각해보자.
우리가 인터넷에서 정보를 얻기 위해서는 먼저 크롬(Chrome), 인터넷 익스플로러(Internet Explorer)와 같이 인터넷에 접속할 수 있는 웹 브라우저(Web Browser)를 먼저 실행해야 한다. 그리고 웹 주소창에 원하는 사이트의 주소를 입력하거나, 구글, 네이버와 같은 검색 사이트에서 검색하여 원하는 정보에 접근한다. 그러면 서버는 우리의 웹 브라우저에게 해당 웹 페이지가 저장하고 있는 정보를 전송하여, 우리가 서버에 저장된 정보를 볼 수 있게 만들어 준다.
이 때 우리가 입력하는 영문명의 사이트 주소는 실제 사이트 주소가 아니다. 인터넷 상의 실제 주소는 IP주소이며, 이를 사람이 보기 편하게 만들어 준 것이 우리가 입력하는 사이트의 주소이다. 따라서 우리가 어느 사이트에서 정보를 얻기 위해 해당 사이트를 들어갔다면, 원하는 정보가 있는 주소에 접속해서 해당 주소에 있는 데이터를 모두 받아오는 과정이라고 생각하면 된다.
이것이 오늘날 우리가 인터넷에서 정보를 교환하는 방식인 HTTP(Hypertext Transfer Protocol)이다.
HTTP의 특징은 서버에 저장된 정보를 불러오는 과정에서 볼 수 있듯이 동일한 데이터이든 아니든 관계없이 모든 데이터에게 고유의 주소(IP)가 붙는다는 점이다. 예를 들어 A와 B가 동일한 내용의 파일을 각각의 서버에 저장해두고 있다면, 두 파일은 다른 점이 없지만 파일에 접근하기 위해서는 각각 파일에 해당하는 주소가 필요하다.
이와 같은 HTTP 방식은 수많은 데이터를 한 서버에 저장하는데 매우 유용한 방식이었다. 인터넷 초기 당시, 서버 구축 등 IT 인프라 비용이 높았던 시절, 한 곳에 데이터를 저장하고 관리해야 더욱 경제적으로 운영할 수 있었기 때문에 HTTP를 버려지지 않고 계속적으로 프로토콜으로 자리잡고 있었다.
그 결과로, HTTP는 중앙화 된 서버와 해당 서버에 의존하는 수십만, 수백만의 클라이언트를 만들어 냈다. 예를 들어 FANG(Facebook, Amazon, Netflex, Google)을 비롯해 네이버 등 IT 공룡기업들은 인터넷 상의 데이터를 자신의 서버에 저장하고 있으며 우리는 항상 해당 서버에 접속해 데이터를 얻고 있다.
▣ HTTP의 문제점
그러나 IT 인프라 비용이 낮아지고, 인터넷을 사용하는 사람들의 수가 늘어나면서 HTTP의 장점은 점차 희석되고 단점들이 나타나기 시작했다.
위에 설명 했듯이, HTTP 방식에서는 하나의 서버에 데이터가 저장되기 때문에 데이터를 다운 받게 되면 하나의 서버에서 데이터를 다운 받게 된다. 만약 이 때 해당 서버가 작동하지 않는다면 어떨까? 혹은 해당 서버가 없어진다면 어떻게 될까? 우리는 데이터를 다운 받을 수 없게 된다. 해당 데이터가 다른 곳에 남아 있다 하더라도 다시 데이터가 저장된 주소를 찾는 번거로움을 경험해야 하며, 그렇다 하더라도 찾을 수 있다는 보장조차 없다.
또한 FANG의 예시에서도 알 수 있듯이, 수 많은 공룡기업들이 데이터를 과점한 상태로 계속 가게 되며 데이터가 돈이 되는 세상에서는 결과적으로 공룡기업들에게 더 많은 권력이 집중되게 되어 버린다. 공룡기업들이 어떻게 우리의 데이터를 사용하는지 우리는 알 수 없다는 점도 문제이다.
▣ IPFS : Contents 기반
이와 같이 인터넷 상에서의 데이터 정보 교환에 대한 프로토콜 HTTP의 문제점을 해결하기 위해 등장한 새로운 프로토콜이 IPFS(Inter Planetary File System)이며, 오픈소스이다.
IPFS가 HTTP와 구별되는 가장 큰 특징은 데이터에 접근하는 방식이다. 기존 HTTP가 데이터가 저장된 위치(Location)로 접근했다면, IPFS는 특정 데이터가 가지고 있는 내용(Contents)으로 접근한다.
예를 들어 A, B가 내용이 동일한 파일을 각각 가지고 있다고 했을 때, HTTP 방식에서 다운로드를 위해서는 A, B 각각 주소에 접근해야 한다. 반면 IPFS는 A, B의 파일을 동일한 것으로 간주하며, 다른 사람이 다운을 요청했을 때, A, B 파일에 동시에 접근해 각각의 파일을 동시에 다운로드 받는다. 이 때 다운로드 받는 파일을 작은 블록(Block)들로 쪼개 블록 조각들을 A, B로부터 나눠서 받게 된다.
쉽게 생각하면 토렌트(Torrent)와 비슷한 방식이라고 생각하면 된다. 토렌트도 새로운 데이터를 다운로드 받고자 하면, 해당 파일을 가지고 있는 여러 사람들에게 접근하여 해당 데이터를 사람들로부터 다운 받는다. 그리고 데이터를 쪼개서, 각각의 사용자들로부터 쪼개진 데이터를 다운 받는다.
IPFS가 이와 같이 같은 내용(Contents)을 담은 데이터에 사람들이 동시에 접근할 수 있도록 만들 수 있었던 것은 데이터 내용을 기반으로 데이터별로 해쉬(Hash)값을 부여하기 때문이다. 즉, 동일한 내용의 데이터는 동일한 해쉬값을 갖게 되며, 우리가 원하는 데이터의 해쉬값을 입력하게 되면 해쉬값에 해당하는 데이터가 우리에게 보여지게 된다.
물론 해쉬값은 굉장히 이더리움 주소명과 같이 참 사람이 보기에 어렵게 생겼다. IPFS는 이 문제점을 해결하기 위해 각 해쉬값에 손쉽게 이름을 붙일 수 있는 IPNS(Inter Planetary Naming System)을 만들었다. 즉, 우리가 IP주소가 아니라 blog.naver.com/zeigal과 같은 주소를 입력하는 것처럼, IPNS도 해시값 대신 사람에게 친숙한 값을 입력하면 웹 페이지가 열리는 방식이다.
▣ IPFS와 블록체인
IPFS는 사실 딱히 블록체인과 연관성이 많아 보이지 않을 수 있다. 사실 IPFS는 블록체인을 위해 만들어진 프로토콜이 아니며 웹의 분산화를 위해 만들어진 프로토콜이라고 볼 수 있다.
이런 IPFS가 많은 블록체인 백서에 등장하는 것은 현재 블록체인이 가지고 있는 데이터 저장에 대한 한계 때문이다. 블록을 생성 후에 노드들에게 공유하는 작업은 노드가 많아질수록, 데이터가 커질 수록 많은 시간이 필요하다. 따라서 데이터 저장을 위해 블록 크기를 무한정 늘릴 수 없으며, 1GB 등의 상대적으로 용량이 큰 데이터를 블록에 담을 수는 없다. (현재 비트코인 블록 크기는 1MB이다.)
그러나 데이터를 저장하지 않는다면 블록체인은 그저 암호화폐 전송에 대한 장부(Ledger)를 기록하는 수준에 머물 수 밖에 없으며 Dapp 등도 실제 데이터는 모두 중앙화된 서버에 기록될 뿐, 자신들이 발행한 토큰만 투명하게 공개되는 수준에서 멈출 것이다. 따라서 진정한 분산화를 이루고자 한다면 데이터 저장도 모두 분산화 되어야 한다. 이런 의미에서 Dapp들의 데이터를 저장하는데 IPFS가 사용될 수 있는 것이다.
또한, 블록체인 전송(Transaction)에 데이터 해시값을 저장함에 따라 어떤 데이터를 누가, 얼마를 지불/수령하고 사용/판매 했는지까지 추적이 가능하다. 앞서 설명했듯이 IPFS의 특징은 데이터 크기에 관계없이 모든 데이터를 해시값으로 표현이 가능하며, 해당 해시값은 용량이 매우 작기 때문에 블록에 포함해도 전혀 무방하다.
따라서 암호화폐 전송에 맞물려 데이터 해시값을 함께 작성한다면 데이터 전송/수령에 대한 경제적 인센티브의 주고 받는 것까지 투명하게 공개될 수 있다.
