ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • IPFS란? (InterPlanetary File System)
    SE General 2021. 2. 25. 21:21
    반응형

    IPFS (InterPlanetary File System)이란 프로토콜이며, 분산 파일 시스템에서 데이터를 공유하고 저장하기 위한 peer-to-peer 네트워크입니다. IPFS는 모든 컴퓨팅 기기를 연결하는 글로벌 네임스페이스에서 각 파일을 식별하기 위해서 content-addressing을 사용합니다 [5].

     

    이와 같은 IPFS는 일면으로 웹과 유사하나, IPFS는 하나의 Git repository 안의 객체를 교환하는 하나의 BitTorrent Swarm에 좀 더 가깝습니다. 다른 표현으로는, IPFS는 높은 처리량의 content-addressed 블록 스토리지 모델을 content-addressed 하이퍼링크를 통해 제공합니다. 그리고 이것은 일반화된 Merkle Dag를 형성하여 버져닝된 파일 시스템이나, 블록체인, 심지어 Permanent Web을 만들 수 있는 기반을 이룹니다.

     

    IPFS는 분산 해쉬테이블, incentivized block exchange, self-certifying namespace를 결합하였으며, SPOF가 없고, 노드 간 신뢰를 필요로 하지 않습니다. 

     

    이 글에서는 IPFS에 대하여 다음과 같은 사항들을 살펴보겠습니다:

     

    • 예시로 알아보는 IPFS
    • IPFS의 주요특징들
    • IPFS는 어떻게 동작하는가?

     


    예시로 알아보는 IPFS [3]

    예시로 만약 aardvarks에 대해 조사하기 위해 아래와 같은 위키피디아 주소를 브라우저에 입력한다고 가정한다면,

    https://en.wikipedia.org/wiki/Aardvark

    URL을 입력 후 엔터를 치면 컴퓨터는 해당 국가(또는 지구 어딘가에 있는) 위키피디아의 컴퓨터에 요청하여 해당 페이지를 가져오게 됩니다.

     

    그러나, aardvarks 페이지를 다른 방식으로도 가져올 수 있습니다. IPFS에 저장된 위키피디아 미러(mirror)가 존재하기에, 그것을 사용할 수 있는데요. 만약 IPFS를 사용한다면 컴퓨터는 aardvarks 페이지를 아래와 같이 요청합니다:

    /ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/Aardvark.html

     

    그리고 IPFS는 해당 페이지의 위치가 아닌 컨텐츠를 기반으로 정보를 찾을 수 있습니다(content-addressing). aardvark 페이지의 IPFS 버젼은 URL 중간에 포함된 숫자 및 문자(QmXo...)로 나타내어 집니다. 그리고 그 요청은 위키피디아의 컴퓨터에 요청하는 것이 아니라, 전세계에 퍼져 있는 수많은 컴퓨터들에 aardvark 페이지를 공유해줄 것을 요청합니다. 그렇게 단지 위키피디아에서 뿐만 아니라, 해당 페이지를 가지고 있는 누구나로부터 얻을 수 있습니다.

     

    그리고 IPFS를 사용할 때, 해당 컴퓨터는 다른 누구로부터 파일들을 다운받는 것과 동시에 파일들을 나누어 주는 역할을 합니다. 해당 컴퓨터에서 몇 블록 떨어진 곳의 누군가가 똑같은 위키피디아 페이지가 필요하다면, 그 페이지를 나누어 줄 수 있습니다.

     

    An overview of the main IPFS operations - Image from [8]

    IPFS의 주요특징들

    IPFS의 중심에는 분산화(Decentralization), 컨텐츠 어드레싱(Content addressing), 참여(Participation)이라는 3가지 주요 특징이 존재합니다. 

     

    분산화

    IPFS는 하나의 기관이 중심이 되어 관리하는 것이 아니라 분산된 환경의 여러 장소로부터 파일을 다운로드 받을 수 있도록 합니다.

     

    그렇기에 하나의 중심 기관이 다운되면 파일 다운로드가 불가능한 중앙집중형 구조 대비 더욱 안정적인 인터넷 환경을 제공합니다. 

     

    또한, IPFS의 파일은 다양한 장소로부터 전달되기에 기관, states 등이 특정 정보를 막기 위해 검열하는 것을 매우 어렵게 만듭니다. 이러한 IPFS의 특성은 정보에 대한 자유로운 접근을 북돋습니다.

     

    마지막으로 요청하는 컴퓨터가 외지에 있거나 연결되지 않은 상황에서 웹을 빠르게 만들 수 있습니다. 수백, 수천 킬로미터의 어떤 장소로부터 해당 파일을 받는 대신 주변의 가까운 다른 노드로부터 빠르게 파일을 받을 수 있습니다. 포함되어 있는 커뮤니티가 커뮤니티 로컬에서는 서로 잘 연결되어 있지만 외부와는 연결이 잘 되지 않을 때 이러한 특성은 더욱 빛을 발합니다. 

     

    이런 마지막 포인트에서 IPFS는 InterPlanetary File System (범지구적 파일 시스템?)라는 이름을 따왔습니다. 

     

    컨텐츠 어드레싱

    /ipfs/QmXoypizjW3WknFiJnKLwHCnL72vedxjQkDDP1mXWo6uco/wiki/Aardvark.html

    살펴본 aardvark 페이지 URL의 ipfs 이후의 문자열은 content identifier로 IPFS가 여러 장소로부터 컨텐츠를 가져오는 키가 됩니다.

     

    • http://en.wikipedia.org/wiki/Aardvark
    • /Users/Alice/Documents/term_paper.doc

     

    위와 같은 전통적인 URLs과 파일 path는 하나의 파일이 '어디에 위치해 있는지' 나타냅니다. 그러한 표기는 하나의 파일이 여러 장소에 저장되어 있는 IPFS 환경에는 적합하지 않습니다.

     

    위치 기반의 표기 대신에, IPFS는 하나의 파일을 '해당 파일에 무엇이 들어 있는지'를 통해 나타냅니다. 위에서 살펴본 content identifier는 해당 주소를 가진 컨텐츠의 cryptographic hash 값입니다. 원본 컨텐츠에 비해 짧아보이지만 해당 hash 값은 기원한 컨텐츠에 따라 unique한 값을 가집니다. 또한, 이러한 hash는 컨텐츠와 hash가 매칭되지 않으며 다른 컨텐츠를 전달하는 것을 막습니다. 

     

    IPFS에서 하나의 파일에 대한 주소는 컨텐츠 자체로부터 생성되기 때문에 IPFS의 links는 변경될 수 없습니다. 예로,

     

    • 웹페이지의 텍스트가 바뀌면 새로운 버젼은 새로운 해쉬값을 가지며, 그렇기에 새로운 주소를 갖습니다.
    • 컨텐츠는 다른 주소로 이동될 수 없습니다. 

     

     

    주로, 사람들은 컨텐츠를 지속적으로 업데이트하여 컨텐츠를 변경하지만 매번 변경물에 대해서 새로운 링크를 보내고 싶진 않습니다. 그러한 부분은 IPNS, Mutable File System (MFS), 그리고 DNSLink 등을 통해서 좀 더 상세히 알아보실 수 있을 것 같습니다. 

     

    무엇보다도 어떠한 상황에서든지 IPFS는 참여적이고 협업적이라는 부분을 인지하는 것이 중요합니다. 아무도 특정 주소를 통한 content identity를 사용하지 않으면 누구도 해당 주소의 컨텐츠를 얻을 수 없습니다. 반대로 누구 하나라도 특정 주소의 컨텐츠를 가지고 있다면 그 컨텐츠를 지울 수 없습니다 (이러한 제한을 개선하여 GDPR 같은 개인정보 가이드라인을 만족하고자 하는 연구도 보입니다 [8]). 

     

     

    참여

    IPFS에는 복잡한 많은 기술들이 적용되었지만, 기본적인 아이디어는 사람들과 컴퓨터가 어떻게 커뮤니케이션하는지를 변경한 부분에 존재합니다.

     

    현재의 WWW는 소유권과 접근을 기반으로 구축되었기에 당신은 파일들을 그것을 소유한 누군가가 접근을 허용할 경우 그들로부터 얻습니다. IPFS 소지와 참여에 기반하여, 많은 사람들이 각각 다른 파일들은 가지고(소지)있고, 그것들을 사용할 수 있도록 참여하여 공유하게 됩니다.

     

    이것의 의미는 IPFS는 오직 사람들이 적극적으로 참여할 때에 잘 작동한다는 것입니다. 

     

     

    IPFS는 어떻게 동작하는가?

    interface Peer {
          open (nodeid :NodeId, ledger :Ledger);
          send_want_list (want_list :WantList);
          send_block (block :Block) -> (complete :Bool);
          close (final :Bool);
    }

    | BitTorrent에서 inspired하여 만들어진 IPFS에 사용되는 블록 교환 프로토콜 BitSwap의 Peer 인터페이스

     

    IPFS는 peer-to-peer (p2p) 스토리지 네트워크입니다. 컨텐츠는 세계 어디든지 존재하는 peers를 통해 접근가능합니다. 

     

    IPFS가 어떻게 동작하는지 이해하기 위해서는 아래 3가지 주요 원리를 알고 있어야 합니다:

     

    1. Content Addressing을 통해 unique identification
    2. Directed Acyclic Graphs (DAGs)를 통한 Content linking
    3. Distributed Hash Tables (DHTs)를 통한 Content discovery

     

    다시 살펴보는, 컨텐츠 어드레싱

    위에서 언급한대로, IPFS는 hash인 content identifier (CID)를 생성하여 접근 시에 사용합니다.

     

    이러한 컨텐츠 어드레싱은 컨텐츠 식별만을 위해서가 아니라 컨텐츠와 해시를 연결하기 위해서 많은 분산 시스템에서도 사용하고 있습니다 (코드에 대한 커밋부터 crypocurrencies를 실행하는 블록체인까지 다양하게). 그러나, 그런 다양한 시스템의 기반을 이루는 데이터 구조는 서로 연동되어 동작하지 않아도 됩니다. 

     

    이 부분에서 InterPlanetary Linked Data (IPLD) 프로젝트가 역할을 합니다. IPLD는 다양한 분산 시스템의 데이터를 통합할 수 있도록 hash로 연결된 데이터 구조를 변환해줍니다. IPLD는 기반한 프로토콜에 관계없이 데이터를 사용할 수 있도록 연결된 다양한 노드의 path, selector, query 등을 '번역'하는 라이브러리를 제공합니다. 예로, Git-style 입력에 대해 번역 후 특정 컨텐츠를 전달하고 Ethereum-style 입력에 대해 역시 번역 후 특정 컨텐츠를 전달할 수 있습니다.

     

     

    DAGs

    IPFS와 다른 많은 분산 시스템은 DAGs로 불리는 데이터 구조를 사용합니다. 특히 Merkle DAGs를 사용하는데, 이 DAGs에서 각 노드는 각 노드 컨텐츠의 hash인 unique한 식별자를 가집니다. 

     

    이 부분에서 Merkle DAGs은 Content-Addressing과 매우 유사한 특성을 가집니다. 

     

    IPFS는 디렉토리와 파일을 나타내는 것에 최적화된 Merkle DAG을 사용하는데, 이러한 Merkle DAG의 구조는 다양한 방식으로 커스텀하게 구조화할 수 있습니다. 예로, Git은 그 안에 여러가지 버젼을 가진 Merkle DAG을 사용합니다.

     

    컨텐츠를 나타내는 하나의 Merkle DAG을 만들기 위해서, IPFS 주로 먼저 컨텐츠를 블록들로 나눕니다. 컨텐츠를 블록들로 나누어서 파일의 다른 부분들을 다른 원천으로부터 받을 수 있고 빠르게 인증될 수 있습니다 (BitTorrent를 사용해보셨다면, 다양한 Peers로부터 파일의 부분부분을 다운받는 모습을 보셨을 것입니다).

     

    Merkle DAGs에서 모든 것은 CID를 가집니다. 만약 하나의 파일이 있다면 그것은 CID를 가집니다. 만약 그 파일이 하나의 폴더 안에 다른 파일들과 존재한다면, 모든 파일은 CID를 각각 가지고, 폴더 역시도 CID를 가집니다(폴더가 가진 컨텐츠들의 hash). 반대로, 그러한 파일들은 block들로 구성되어 있고, 각 블록은 CID를 가집니다:

     

    Directory, Files CID on IPFS - Image from IPFS Explorer

     

     

    Merkle DAGs과 컨텐츠를 여러 블록으로 쪼개는 것의 유용한 기능 중 하나는 만약 2가지 비슷한 파일을 가지고 있을 경우 두 파일은 Merkle DAG의 일부를 공유할 수 있다는 사실입니다: 두 가지 다른 Merkle DAGs이 같은 subset을 reference할 수 있습니다. 

     

    예로, 만약에 하나의 웹사이트를 업데이트 했다고하면, 오직 업데이트된 파일만 새로운 컨텐츠 주소를 받습니다. 그렇게 기존 버젼과 새로운 버젼은 그 변경분 이외에는 모두 같은 블록을 refer할 수 있습니다. 이후 해당 파일 전송 시에, 변경분에 대한 데이터만을 전송하여 전송량을 낮추고 저장사이즈도 작아질 수 있습니다.

     

    복습해보자면, IPFS는 CIDs를 컨텐츠에 붙이고 Merkle DAG을 통해 컨텐츠를 연결합니다. 마지막으로는 어떻게 컨텐츠를 찾고 이동시키는지 알아보겠습니다.

     

    DHTs

    어떤 peers가 당신이 원하는 컨텐츠를 hosting하고 있는지 알기 위해서 IPFS는 DHT (distributed hash table, 분산 해시 테이블)를 사용합니다. 하나의 해시테이블은 키와 값을 연결한 데이터베이스입니다. DHT는 분산 네트워크에 존재하는 모든 peers에 나누어져 존재하는 하나의 테이블입니다. 그래서 컨텐츠를 찾기 위해서는 이러한 peers들에게 질의를 하게 됩니다.

     

    libp2p 프로젝트는 IPFS 에코시스템의 일부로 DHT 기능을 제공하며 서로 연결되어 커뮤니케이션하는 peers 처리를 담당합니다. 

     

    일단 컨텐츠가 어디에 있는지 알고나면(좀 더 정확히는 어떤 peers가 해당 컨텐츠를 구성하는 블록들을 저장하고 있는지 알고나면), DHT를 사용하여 해당 peers들의 현재 위치를 알아낼 수 있습니다. 그러므로 컨텐츠를 얻기 위해서는 libp2p를 사용해 2번 질의를 해야 합니다.

     

    컨텐츠를 찾고 해당 컨텐츠의 현재 위치를 알아냈다면, 이제 컨텐츠를 가지고 있는 곳에 연결되어 요청을 해야 합니다. Peers에게 요청을 하거나 받아서 블록을 받거나 보내기 위해서, IPFS는 현재 Bitswap이라는 모듈을 사용합니다. Bitswap은 peers와 연결하는 것을 돕고 wantlist를 보내어 요청한 블록들을 받을 수 있도록 합니다. 요청된 블록들이 수신되면 컨텐츠를 해싱하여 CIDs를 얻고 그 CIDs와 요청한 CIDs 간에 비교를 통해 정확한 데이터를 받았는지 검증할 수 있습니다. 

     

    현재 논의되고 있는 다른 컨텐츠 복제 프로토콜들이 존재하며, 가장 개발도가 높은 것은 Graphsync입니다. 요청과 응답과 관련되어 기능을 추가하기 위해 Bitswap 프로토콜을 확장하는 것에 대한 논의도 진행 중입니다.

     

    Libp2p

    p2p에 libp2p가 유용한 이유는 connection multiplexing과 관련 깊습니다. 전통적으로 모든 서비스는 유사한 형태의 다른 서비스와 원격으로 커뮤니케이션 하기 위해 다른 코넥션을 생성합니다. IPFS를 사용하면서는 하나의 코넥션을 생성하고 다른 서비스를 multiplex할 수 있습니다. 

     

     

     

    Brave 브라우저

    작년 말, 크롬이 느리다(루머로 추정)라는 말을 듣고, 브라우저 대안을 찾던 중 Brave를 발견하였습니다. 클릭 몇 번으로 크롬의 모든 북마크, 플러그인 등이 Brave 브라우저로 들어와 큰 불편함 없

    kadensungbincho.tistory.com

     

     

     

    Reference

    [1] github.com/ipfs/ipfs

    [2] IPFS - Content Addressed, Versioned, P2P File System (DRAFT 3)

    [3] docs.ipfs.io/

    [4] Youtube. Why IPFS? - Juan Benet

    [5] Youtube. Stanford Seminar - IPFS and the Permanent Web

    [6] Wikipedia. IPFS

    [7] Escaping the Evils of Centralized Control with self-certifying pathnames

    [8] Delegated content erasure in IPFS

    반응형
Kaden Sungbin Cho