• Distributed Hash Tables in IPFS

    DHT (Distributed Hash Tables)

    분산 해시 테이블을 의미하는 것으로 말 그대로 해시 테이블을 분산하여 관리하는 기술 입니다.

    어떤 항목을 찾아갈 때 해시 테이블을 이용하는데, 중앙 시스템이 아닌 각 노드들이 이름을 값으로 맵핑하는 기능을 하는 방식으로 부하가 집중되지 않고 분산된다는 큰 장점이 있어, 극단적으로 큰 규모의 노드들도 관리할 수 있습니다.

    살짝 감이 오지 않습니까? IPFS 의 주요 기능말입니다.

    분산 해시 테이블에 대한 기본 이해

    해시 테이블은 Key/Value 데이터 구조로 구성되어 있습니다. DHT는 해싱으로 생성된 데이터 Key 값과 서버 ID 의 짝을 시스템을 구성하고 있는 모든 노드에 균일하게 분산하기 위하여 고안된 lookup 방법입니다. 데이터 Key 값과 서버 ID 를 통하여 모든 노드와 데이터들을 동일 주소 공간에 할당함으로써 데이터와 노드 정보들을 한꺼번에 관리하기가 용이하기 때문에 P2P 시스템에서 많이 사용합니다. (데이터의 Key 값과 분산 서버 ID는 동일한 해시 함수로 동일한 주소 공간에 데이터와 노드를 배치)

    한마디로 중앙 서버 없이 데이터를 관리하는 분산된 서버를 찾을 수 있으며 클러스터에 참여하는 서버의 추가/제거가 자동으로 이루어질 수 있도록 구성할 수 있기 때문입니다.

    부하가 집중되지 않고 분산된다는 큰 장점이 있어, 극단적으로 큰 규모의 노드들도 관리할 수 있습니다. 종래의 순수 P2P에서 채용되었던 방식에서는 수십만 노드 정도가 한계였으나, DHT의 사용으로 수십억개의 노드를 검색범위로 할 수 있게 되었습니다.

    IPFS 에서는 Kademlia DHTBitTorrent 그리고 Git, Self-certifying File System 에 대한 이해를 필요로 합니다.

    각각은 차차 알아보기로 하고 조금 더 DHT 에 대한 이야기를 해보겠습니다.

    IPFS 에서 DHT

    네트워크에 참여한 노드가 해시 테이블을 사용하여 서버없이 P2P 네트워크를 실현하는 기술로 파일(데이터, 컨텐츠)을 검색하는데 사용됩니다.

    HTTP는 IP를 기반으로 검색이 되었으나 IPFS는 Content-Addressed를 사용합니다. 즉, 컨텐츠 자체가 주소역할을 대신 합니다.

    Content Name Node Location
    Content01 Node01
    Content02 Node03, Node05
    Content03 Node02, Node08

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

    Kademlia DHT

    Kademlia는 현재 가장 대중적으로 사용되는 P2P DHT 입니다. Kademlia는 다음과 같은 용어에 대한 이해가 필요합니다.

    • Node: node는 Kademlia DHT 네트워크에 참여하는 컴퓨터
    • pair (Key/Value): KV(Key/Value) 형태로 데이터를 저장, Kademlia 네트워크에서 값을 찾기 위한 고유 키이며 값은 DHT에 저장되는 데이터
    • LookUP: Kademlia 네트워크에서 주어진 키에 대한 실제 값을 찾는 과정
    • Data/Content: Kademlia DHT에 pair(KV) 형태로 저장되어 있는 실제 데이터

    Kademlia를 사용하는 이유

    • Node간 주고받는 데이터를 최소화
    • 네트워크에 속한 node, 인접 node 등에 대한 설정 정보가 자동적으로 Kademlia 네트워크에 확산
    • Kademlia 네트워크의 node들은 다른 node를 통해 파악 (적은 비용으로 node간 경로 탐색)
    • Kademlia는 작동하지 않는 node의 timeout을 피할 수 있는 병렬적이고, 비동기적 쿼리 제공
    • DOS 공격 방지

    Key

    Kademila는 Node와 데이터를 식별하기 위해 160 비트 key를 이용합니다. 네트워크에 참여하는 컴퓨터는 각각 160 비트 NodeId 키를 가집니다. Kademila는 pair(KV)로 데이터를 저장하기 때문에 160 비트 key를 사용해서 데이터를 식별합니다.

    Distance

    두 Node 간의 ‘거리’를 계산하는 것으로 두 NodeId의 XOR로 계산되고 정수형 값을 가집니다. Key와 NodeId는 같은 형태, 길이의 정수형 값을 가지고 있기 때문에 XOR연산이 가능합니다. NodeId는 Node를 식별할 수 있는 무작위의 정수형 값(UUID)을 가집니다. 즉, 물리적 거리가 먼 Node라도 NodeId 값이 비슷하다면 논리적으로 이웃에 위치할 수 있습니다.

    • 임의의 Node와 그 Node 자신에 대한 거리는 0
    • XOR 연산은 대칭성을 가짐: A에서 B 거리의 계산 결과는 B에서 A 거리와 동일
    • 삼각 부등식 성립: A, B, C Node가 주어질 경우, A와 B 사이 거리는 A와 C 또는 C와 B의 거리합과 같거나 작음

    위와 같은 특징은 간단하면서 빠른 XOR 연산의 특징을 보여줍니다.

    Kademlia 탐색 작업이 반복될 때마다 한 비트씩 탐색 대상에 가까워집니다. 2^n 개의 Node를 가지고 있는 Kademlia 네트워크에서는 최대 n번 탐색을 반복하면 임의의 Node를 찾을 수 있습니다.

    라우팅 테이블

    각 NodeId들의 각 비트를 저장한 리스트를 포함하고 있습니다. 리스트의 모든 항목은 다른 Node들의 위치에 대한 주요 정보를 저장합니다. 리스트의 각 항목은 일반적으로 다른 Node의 IP 주소, 포트, NodeId를 저장합니다. 후보 id의 n-1번째 비트는 NodeId와 일치하여야 합니다. (모든 리스트는 특정 node의 거리와 대응됩니다. n번째 리스트에 갈 수 있는 Node는 반드시 NodeId의 n번째 비트가 달라야 합니다.)

    128 비트의 id가 있는 네트워크에서는, 128개의 다른 거리로 다른 Node들을 식별하게 됩니다. Node가 네트워크에 참가하게 되면, 리스트에 추가됩니다. 이러한 과정은 통해 다른 Node들이 Key를 찾는 것을 돕습니다.

    프로토콜 메시지

    • PING: Node 작동상태 확인
    • Sotre: 한 Node에 pair(KV) 데이터를 저장
    • FIND_NODE: 요청한 Key에 제일 가깝게 위치한 k Node들을 반환
    • FIND_VALUE: FIND_NODE와 같은 역할을 하며 요청한 Key에 대한 해당 데이터가 있으면 데이터 반환

    요청에 의해 반환되는 RPC 메시지는 발신자가 지정한 랜덤한 값을 포함합니다. 랜덤으로 정해진 값은 요청 메시지와 응답 결과를 대응시키기 위해 사용됩니다.

    Location Nodes

    Node 탐색은 동기적으로 동작합니다. 동시에 일어나는 탐색 요청은 α로 나타내며, 일반적인 α 값은 3입니다. Node은 원하는 Key 값에 가장 가까운 α개의 Node에 FIND_NODE 요청을 전송합니다. FIND_NODE 요청을 받은 Node들은 자신의 k-buckets을 탐색하여 Key 값에 가장 가까운 k개의 Node들을 반환합니다. 탐색 요청자는 요청 결과를 저장하며, k개의 가장 가까운 NodeId를 저장합니다.

    탐색 요청자는 저장하고 있는 NodeId들을 선택하여 각 Node들이 위와 같은 요청을 하도록 하는 작업이 반복됩니다. 각 Node들은 자신 주위에 있는 Node들에 가장 잘 알고 있기 때문에 이러한 작업이 반복될 수록 Key 값에 더 가까운 Node를 찾게 됩니다.

    탐색 작업은 전 탐색 결과보다 Key에 더 가까운 Node들이 없을때까지 반복됩니다. 탐색이 중지되었을때 저장되어 있는 k Node들이 원하는 Key에 가장 가까운 Node가 됩니다.

    Reference

  • IPFS (InterPlanetary File System) 첫번째

    IPFS

    IPFS (InterPlanetary File System) 의 영문만 해석을 하면 ‘행성간 파일 시스템’ 입니다. 제목만 보았을때 ‘무슨 이런 황당한’ 이라는 생각이 들었습니다.

    일단 주요 링크는 다음과 같습니다.

    앞으로 수많은 어려움이 있을 듯 싶지만 하나씩 알아보고자 합니다.

    IPFS 는 무엇일까?

    IPFS 를 최초로 소개한 논문의 Abstract를 살펴보면 다음과 같습니다.

    IPFS는 ‘InterPlanetary File System’ 의 약자로 모든 컴퓨팅 장치를 동일한 파일 시스템과 연결하려는 P2P 분산 파일 시스템입니다. 어떤면에서 IPFS는 웹과 비슷하지만 IPFS는 하나의 Git 저장소 내에서 오브젝트를 교환하는 단일 BitTorrent swarm 으로 볼 수 있습니다. 즉, IPFS는 content addressed 하이퍼 링크를 사용하여 높은 처리량의 content addressed 블록 스토리지 모델을 제공합니다. 이는 버전화 된 파일 시스템, 블록 체인 및 심지어 영구 웹을 구축 할 수 있는 데이터 구조인 일반화 된 Merkle DAG 를 형성합니다. IPFS 는 분산 해시 테이블, 인센티브화 된 블록 교환 및 자체 인증 네임 스페이스를 결합합니다. IPFS는 단일 장애 지점 (SOF) 이 없으며 노드는 서로를 신뢰 할 필요가 없습니다.

    IPFS 를 최초로 설계한 Juan Benet 은 다음과 같이 이야기 했습니다.

    When you have IPFS, you can start looking at everything else in one specific way and you realize that you can replace it all – Juan Benet

    나에게는 ‘모든 것을 다르게 보고 모든 것을 바꾸어보자!’ 는 하나의 슬로건 처럼 보였습니다.

    IPFS는 파일을 가져 와서 관리하고 버전을 저장하고 버전을 추적 할 수 있는 버전으로 관리하는 파일 시스템입니다. 또한 이러한 파일이 네트워크를 통해 이동하는 방식을 설명하므로 분산 파일 시스템이기도 합니다.

    IPFS는 본질적으로 BitTorrent 와 유사한 네트워크에서 데이터와 컨텐트가 어떻게 이동하는지에 대한 규칙을 가지고 있습니다. 이 파일 시스템 계층은 다음과 같은 매우 흥미로운 속성을 제공합니다:

    • 완전히 배포 된 웹 사이트
    • 원본 서버가없는 웹 사이트
    • 클라이언트 측 브라우저에서 완전히 실행할 수있는 웹 사이트
    • 대화 할 서버가 없는 웹 사이트

    Content Addressing

    IPFS는 서버에 저장되는 객체(사진, 기사, 비디오)를 참조하는 대신 파일의 해시를 기준으로 모든 것을 참조합니다. 브라우저에서 특정 페이지에 액세스하려는 경우 IPFS는 전체 네트워크에 “이 해시에 해당하는 파일을 가지고 있습니까?” 라는 질문을 하고 IPFS에 있는 노드는 해당 파일을 반환할 수 있습니다.

    IPFS는 HTTP 계층에서 content addressing 을 사용합니다. 위치별로 문제를 해결하는 식별자를 만드는 대신 콘텐츠 자체를 표현하여 문제를 해결하려고 합니다. 즉, 콘텐츠가 주소를 결정합니다. 이 메커니즘은 파일을 가져와서 암호화된 방식으로 해시하여 매우 작고 안전한 파일 표현으로 끝나도록 하는 것입니다. 따라서 다른 사람이 단순히 같은 해시를 가지고 있는 다른 파일을 만들어서 주소로 사용할 수 없습니다. IPFS에있는 파일의 주소는 보통 루트 객체를 식별하는 해시로 시작한 다음 경로를 따라 내려갑니다. 서버 대신에 특정 객체와 통신하고 그 객체 내의 경로를 확인합니다.

    HTTP vs. IPFS to find and retrieve a file

    HTTP에는 식별자가 위치하기 때문에 파일을 호스팅하고있는 컴퓨터를 쉽게 찾을 수있는 멋진 속성이 있습니다. 이것은 유용하며 일반적으로 잘 작동하지만 오프라인 사례 또는 네트워크에서 로드를 최소화하려는 대규모 분산 시나리오에서는 작동하지 않습니다.

    IPFS에서는 단계를 두 부분으로 나눕니다:

    • content addressing 을 사용하여 파일 식별
    • Go and find it: hash가 생겼을 때 네트워크에 누가 ‘이 콘텐츠를 가지고 있는가? (hash)’ 를 물어 보고 해당 노드에 연결하여 다운로드

    그 결과 매우 빠른 라우팅이 가능한 peer-to-peer 오버레이가 생성됩니다.

    더 많은 정보는 Alpha Video 를 참조하기 바랍니다.

    IPFS by Example

    IPFS (InterPlanetary File System)는 DHT, Git 버전 시스템Bittorrent 와 같이 잘 테스트 된 인터넷 기술을 종합 한 것입니다. 그것은 IPFS Object 의 교환을 허용하는 P2P swarm 을 만듭니다. 전체 IPFS ObjectMerkle DAG 로 알려진 인증 된 데이터 구조를 형성하며 이 데이터 구조는 다른 많은 데이터 구조를 모델링하는 데 사용될 수 있습니다. 이 글에서는 IPFS 개체와 Merkle DAG를 소개하고 IPFS를 사용하여 모델링 할 수있는 구조의 예를 제시합니다.

    IPFS Objects

    IPFS는 기본적으로 IPFS Object 를 검색하고 공유하기 위한 P2P 시스템입니다. IPFS Object 는 두 개의 필드가있는 데이터 구조입니다.

    • Data: 크기가 256 kB 미만인 비정형 바이너리 데이터
    • Links: Link 구조체의 배열. 다른 IPFS Object 에 대한 링크

    링크 구조에는 세 개의 데이터 필드가 있습니다:

    • Name: 링크의 이름
    • Hash: 링크된 IPFS Object 의 해시
    • Size: 링크 다음의 링크를 포함한 연결된 IPFS Object 의 누적 크기

    Size 필드는 P2P 네트워킹을 최적화하는 데 주로 사용되며 개념적으로 논리적 구조에는 필요하지 않기 때문에 대부분 여기에서 무시합니다.

    IPFS Object 는 일반적으로 Base58 로 인코딩 된 해시로 참조됩니다. 예를 들어 IPFS CLI Tool 을 사용하여 해시 QmarHSr9aaSNaPSR6KFPbuLV9aqJfTk1y9Bpdwline 에서 IPFS Object 를 살펴보면 다음과 같습니다.

    > ipfs object get QmarHSr9aSNaPSR6G9KFPbuLV9aEqJfTk1y9B8pdwqK4Rq
    {"Links": [{
    "Name": "AnotherName",
    "Hash": "QmVtYjNij3KeyGmcgg7yVXWskLaBtov3UYL9pgcGK3MCWu",
    "Size": 18},
    {"Name": "SomeName",
    "Hash": "QmbUSy8HCn8J4TMDRRdxCbK2uCCtkQyZtY6XYv3y7kLgDC",
    "Size": 58}],
    "Data": "Hello World!"}
    

    모든 해시가 “Qm”으로 시작한다는 것을 알 수 있습니다. 그 이유는 해시가 실제로 multihash (다중 해시) 이기 때문입니다. 해시 자체가 다중 해시의 처음 2 바이트에서 해시 함수와 길이를 지정하기 때문입니다. 위의 예에서 16 진수의 처음 2 바이트는 1220이며, 여기서 12는 SHA256 해시 함수이고 20은 바이트 단위의 해시 길이를 나타냅니다 (32 바이트).

    데이터와 명명 된 링크는 IPFS Object 의 컬렉션에 Merkle DAG 의 구조를 제공합니다. DAG 는 Directed Acyclic Graph 를 의미하고 Merkle 은 암호화 해시를 사용하여 콘텐츠를 처리하는 암호로 인증 된 데이터 구조임을 나타냅니다.

    그래프 구조를 시각화하기 위해 노드의 데이터와 링크가 그래프 에지를 다른 IPFS Object 로 향하게하는 그래프로 IPFS Object 를 시각화합니다. 여기서 링크 이름은 그래프 에지의 레이블입니다. 위의 예는 다음과 같이 시각화됩니다.

    IPFS Object 로 나타낼 수 있는 다양한 데이터 구조의 예는 다음과 같습니다.

    File Systems

    IPFS는 파일과 디렉토리로 구성된 파일 시스템을 쉽게 나타낼 수 있습니다.

    Small Files

    작은 파일 (<256 kB)은 데이터가 파일 내용 (작은 머리글과 바닥 글 포함)이고 링크가없는 IPFS Object 로 표시됩니다. 즉, 링크 배열이 비어 있습니다. 파일 이름은 IPFS 개체의 일부가 아니므로 이름이 다른 파일과 내용이 동일한 두 파일의 IPFS 개체 표시는 동일하므로 해시가 동일합니다.

    ipfs add 명령을 사용하여 IPFS에 작은 파일을 추가 할 수 있습니다:

    user@user-VBox:~/tmp$ ipfs add test_dir/hello.txt
    added QmfM2r8seH2GiRaC4esTjeraXEachRt8ZsSeGaWTPLyMoG test_dir/hello.txt
    

    ipfs cat 명령을 사용하여 위의 IPFS Object 의 파일 내용을 볼 수 있습니다.

    user@user-VBox:~/tmp$ ipfs cat QmfM2r8seH2GiRaC4esTjeraXEachRt8ZsSeGaWTPLyMoG
    Hello World!
    

    ipfs object get 명령을 사용하여 기본 구조를 볼 수 있습니다.

    user@user-VBox:~/tmp$ ipfs object get QmfM2r8seH2GiRaC4esTjeraXEachRt8ZsSeGaWTPLyMoG
    {"Links": [],
    "Data": "\u0008\u0002\u0012\rHello World!\n\u0018\r"}
    

    이 파일을 다음과 같이 시각화합니다:

    Large Files

    큰 파일 (> 256 kB)은 <256 kB 인 파일 청크에 대한 링크 목록으로 표시되며이 Object 는 큰 파일을 나타내는 최소 데이터만 표시됩니다. 파일 청크에 대한 링크는 빈 문자열을 이름으로 갖습니다.

    user@user-VBox:~/tmp$ ipfs add test_dir/bigfile.js
    added QmR45FmbVVrixReBwJkhEKde2qwHYaQzGxu4ZoDeswuF9w test_dir/bigfile.js
    user@user-VBox:~/tmp$ ipfs object get QmR45FmbVVrixReBwJkhEKde2qwHYaQzGxu4ZoDeswuF9w
    {"Links": [{
    "Name": "",
    "Hash": "QmYSK2JyM3RyDyB52caZCTKFR3HKniEcMnNJYdk8DQ6KKB",
    "Size": 262158},
    {"Name": "",
    "Hash": "QmQeUqdjFmaxuJewStqCLUoKrR9khqb4Edw9TfRQQdfWz3",
    "Size": 262158},
    {"Name": "",
    "Hash": "Qma98bk1hjiRZDTmYmfiUXDj8hXXt7uGA5roU5mfUb3sVG",
    "Size": 178947}],
    "Data": "\u0008\u0002\u0018* \u0010 \u0010 \n"}
    

    Directory Structures

    디렉토리는 파일 또는 다른 디렉토리를 나타내는 IPFS Object 에 대한 링크 목록으로 나타냅니다. 링크의 이름은 파일과 디렉토리의 이름입니다. 예를 들어, test_dir 디렉토리의 다음 디렉토리 구조를 참고하기 바랍니다.

    user@user-VBox:~/tmp$ ls -R test_dir
    test_dir:
    bigfile.js hello.txt my_dir
    test_dir/my_dir:
    my_file.txt testing.txt
    

    hello.txt 및 my_file.txt 파일에는 모두 Hello World!\n 라는 문자열이 있습니다. testing.txt 파일에는 Testing 123\n 문자열이 있습니다.

    이 디렉토리 구조를 IPFS Object 로 나타낼 때 다음과 같이 보입니다:

    Hello World!\n 파일을 포함하는 파일의 자동 중복 제거에 유의하십시오. 이 파일의 데이터는 IPFS의 한 논리적 위치(해시에 의해 추가됨)에만 저장됩니다.

    IPFS command-line tool 은 디렉토리 링크 이름을 따라 파일 시스템을 탐색 할 수 있습니다.

    user@user-VBox:~/tmp$ ipfs cat Qma3qbWDGJc6he3syLUTaRkJD3vAq1k5569tNMbUtjAZjf/my_dir/my_file.txt
    Hello World!
    

    Versioned File Systems

    IPFS는 버전화된 파일 시스템을 허용하기 위해 Git 에서 사용하는 데이터 구조를 나타낼 수 있습니다. Git 커밋 Object 는 Git Book에 설명되어있으니 참조하기 바랍니다. IPFS 커밋 Object 의 구조는 완전히 지정되지 않았으며 지금까지도 토론이 진행 중입니다.

    Commit Object 의 주요 속성은 이전 커밋을 가리키는 parent0, parent1 등의 이름을 가진 하나 이상의 링크와 해당 커밋에서 참조하는 파일 시스템 구조를 가리키는 name Object (Git 에서 tree) 가 있는 하나 이상의 링크를 포함한다는 것입니다.

    다음과 같은 두 가지 커밋과 함께 이전 파일 시스템 디렉토리 구조를 예제로 제공합니다. 첫 번째 커밋은 원래 구조이고 두 번째 커밋에서는 my_file.txt 파일을 본래 Hello World! 대신 Another World! 로 업데이트합니다.

    자동 중복 제거가 있으므로 두 번째 커밋의 새 Object 는 기본 디렉토리이고 새 디렉토리는 my_dir 이며 업데이트 된 파일은 my_file.txt 입니다.

    Blockchains

    이것은 IPFS의 가장 흥미로운 사용 사례 중 하나입니다. 블록체인은 자연스러운 DAG 구조를 가지고 있습니다. 과거 블록은 항상 이후의 블록과 해시로 연결됩니다. Ethereum 블록체인과 같은 고급 블록체인에는 IPFS Object 를 사용하여 에뮬레이트 할 수 있는 Merkle-Patricia 트리 구조가 있는 연결된 state 데이터베이스도 있습니다.

    각 블록에 다음 데이터가 포함된 블록체인의 단순화된 모델을 가정해 봅시다.

    • 트랜잭션 Object 리스트
    • 이전 블록에 대한 링크
    • state (상태) tree 및 데이터베이스의 해시

    블록체인은 다음과 같이 IPFS 에서 모델링 될 수 있습니다.

    상태 데이터베이스를 IPFS 에 넣을 때 중복 제거가 발생합니다. 두 블록 사이에 변경된 상태 항목만 명시적으로 저장해야 합니다.

    여기서 흥미로운 점은 블록체인에 데이터를 저장하는 것과 블록체인에 데이터의 해시를 저장하는 것 사이의 차이입니다. Ethereum 플랫폼에서는 주 데이터베이스의 중복을 최소화하기 위해 관련 상태 데이터베이스 (“blockchain bloat”) 에 데이터를 저장하는 데 상당한 비용을 지불해야 합니다. 따라서 데이터 자체가 아니라 상태 데이터베이스에서 데이터의 IPFS 해시를 저장하는 것이 일반적인 설계 패턴입니다.

    연관된 상태 데이터베이스와 블록체인이 이미 IPFS에 표시되어 있는 경우, 모든 것이 IPFS에만 저장되므로 블록체인에 해시를 저장하고 블록체인에 데이터를 저장하는 것 사이의 구분이 다소 모호해집니다. 이 경우 IPFS 링크를 블록체인에 저장한 경우, 마치 데이터가 블록체인에 저장된 것처럼 이 링크를 따라 데이터에 액세스할 수 있습니다.

    그러나 온체인과 오프체인 데이터 스토리지를 구분할 수 있습니다. 새로운 블록을 만들 때 마이너가 처리해야하는 것을 살펴봄으로써 이를 수행합니다. 현재 Ethereum 네트워크에서 마이너는 상태 데이터베이스를 업데이트 할 트랜잭션을 처리해야 합니다. 이렇게 하려면 전체 상태 데이터베이스에 액세스 하여야 변경된 곳마다 데이터베이스를 업데이트 할 수 있습니다.

    따라서 IPFS로 표현 된 블록 체인 상태 데이터베이스에서 “온체인”또는 “오프체인”으로 데이터에 태그를 지정해야 합니다. 마이너가 마이닝을 위해 국부적으로 유지하기 위해서는 “온체인” 데이터가 필요하며 이 데이터는 거래의 직접적인 영향을받습니다. “오프체인” 데이터는 사용자가 업데이트 해야하며 마이너가 접촉 할 필요가 없습니다.

    IPFS 를 지탱하는 기반 기술

    IPFS 에서는 Kademlia DHTBitTorrent 그리고 Git, Self-certifying File System 에 대한 이해를 필요로 합니다.

    앞으로 차근차근 이에대한 이야기를 하도록 하겠습니다.

  • IPFS 그리고 Web

    Internet 그리고 Web

    위키피디아를 통해 찾아본 인터넷과 웹의 정의는 아래와 같습니다.

    인터넷 은 컴퓨터로 연결하여 TCI/IP (Transmission Control Protocol/Inrternet Protocol) 통신 프로토콜을 이용해 정보를 주고받는 컴퓨터 네트워크 입니다.

    World Wide Web 은 인터넷에 연결된 컴퓨터들을 통해 사람들이 정보를 공유할 수 있는 전 세계적인 정보 공간을 말합니다. 이를 간단히 웹 (Web) 이라고 부르는 경우가 많습니다. 이 용어는 인터넷과 동의어로 쓰이는 경우가 많으나 엄격히 말해 서로 다른 개념입니다. 웹은 전자메일과 같이 인터넷 상에서 동작하는 하나의 서비스 입니다.

    그런데 우리가 가장 많이 사용하는 웹 프로토콜은 무엇일까요? 아마도 HTTP (HyperText Transfer Protocol) 가 아닐까 합니다.

    HTTP 는 WWW 상에서 정보를 주고받을 수 있는 프로토콜 입니다. TCP 와 UDP 를 사용하고 80번 포트를 사용합니다. 결국 클라이언트와 서버 사이에 이루어지는 요청/응답(request/response) 프로토콜 입니다.

    인터넷, 웹, HTTP, TCP/UDP 등등의 수많은 의미와 기술들은 요청한 파일을 전송하는 목적을 가지고 있습니다.

    HTTP Web 의 한계

    불안정

    HTTP는 클라이언트가 서버에 데이터를 요청하면 서버에서 응답하며 데이터를 보내주는 구조입니다. 그렇기 때문에 서버의 전원이 차단되면 아무것도 할 수 없고 항상 서버 해킹에 대한 걱정을 안고 있어야 합니다. 특히나 해킹으로 인하여 서버의 데이터가 삭제된다면 무척이나 큰 일이 발생합니다.

    자주 웹서핑을 하다가 분노를 일으키는 ‘404 Error’ 는 컨텐츠가 삭제되거나 이동하였음을 의미합니다.

    가장 심각한 문제는 어떤 이유로든 데이터가 삭제되는 것 입니다. 이러한 문제를 줄이기 위해 이중화, 삼중화로 서버를 구성하고 네트워크보안을 추가하는 등 어마어마한 시간과 노력을 들이고 있지만 해결이 되지 않습니다.

    중앙 집중화

    인터넷을 기반으로 하는 시스템의 구성은 분산 시스템이지만 역설적이게도 매우 중앙 집중화되어 있습니다. 이는 결국 현재의 문제점을 낳고 말았습니다. 해커는 중앙 집중화된 몇개의 서버를 공격하여 개인정보를 탈취하고, 몇개의 서버를 장악하면 하나의 나라를 감시할 수 있습니다. 즉 중앙 집중화된 구조는 보안에 취약해질 수 밖에 없는 구조입니다.

    Latency

    지리적으로 가까운 서버에서 데이터를 제공하지 않는다면 속도 문제가 발생합니다. 특히나 지리적으로 너무 멀리 떨어진 서버라면 상상을 초월하는 속도 문제를 경험하게 됩니다. 대부분의 서비스 업체들은 리전이라고 하는 데이터센터를 세계 권역마다 마련하고 있습니다.

    최근 매우 인기가 있는 Youtube 를 생각하면 인기 콘텐츠에 대한 요청이 어마어마하게 발생하고 있으며 이에 대한 응답 역시 어마어마하게 발생하고 있습니다. 작은 용량의 데이터가 전송되던 과거의 형태에서 매우 급격하게 증가한 데이터가 전송되고 있습니다. 스트리밍 서비스 영상이 고화질로 증가하면서 용량도 폭증하였습니다. 이는 결국 통신 속도의 저하를 초래하게 됩니다.

    해결책은 데이터 분산

    비교적 작은 데이터들이 돌아다녔던 과거의 HTTP 환경에서 이제는 매우 큰 데이터들이 어마어마한 트래픽을 발생시키는 환경으로 변화하였습니다. 하지만 아직도 HTTP를 가장 많이 활용하고 있습니다. 새로운 도전거리가 발생한 것 입니다. 즉, 네트워크도 진화하고 변화하여야 합니다.

    대략의 진화 방향을 살펴보면 다음과 같습니다.

    • 페타 바이트 데이터셋이 호스팅되고 분산됩니다.
    • 조직 전체에 걸쳐 대규모 데이터를 기반으로 컴퓨팅 합니다.
    • 대규모 데이터셋은 버전처리되어 관리 되고 연결됩니다.
    • 중요한 파일이 실수로 사라지는 것을 방지합니다.

    앞으로 이러한 변화의 선두에 서있는 IPFS (InterPlanetary File System) 에 대하여 알아보고자 합니다.