IPLD - Specification: DAG-JSON
원문은 IPLD Github specs 에서 확인 가능하다. IPLD DAG-JSON
Specification: DAG-JSON
DAG-JSON은 전체 IPLD 데이터 모델을 지원한다.
1. Format
1.1 Simple Types
바이너리를 제외한 모든 간단한 유형은 기본적으로 JSON에서 지원된다.
JSON은 Big Integers를 지원한다. 즉, dag-json의 JS 구현은 기본 JSON 파서 및 직렬기를 사용할 수 없다는 것을 의미한다.
1.1.1 Binary Type
{"/": { "base64": String }}
1.2 Link Type
{"/": String /* base encoded CID */}
IPLD - Specification: DAG-CBOR
원문은 IPLD Github specs 에서 확인 가능하다. IPLD DAG-CBOR
Specification: DAG-CBOR
DAG-CBOR은 전체 IPLD Data Model을 지원한다.
CBOR은 이미 모든 IPLD Data Model Kinds를 기본적으로 지원한다.
1. Format
CBOR IPLD 형식은 일반 CBOR과의 모호성을 제거하기 위해 DagCBOR라고한다. 대부분의 CBOR 객체는 유효한 DagCBOR이다. 유일한 제한은 tag 42 가 있는 필드는 유효한 CID 여야 한다는 것이다.
2. Map Key Restriction
모든 IPLD 형식과 마찬가지로 DagCBOR는 Merkle-Link를 인코딩 할 수 있어야한다. DagCBOR에서 링크는 tag 42와 함께 byte-string type (주요 유형 2)이있는 필드에서 raw-binary (identity, NUL) 멀티베이스를 사용하여 인코딩된다.
DagCBOR에서 맵 키는 문자열이어야 한다. 맵 키는 /를 사용하면 안된다.
3. Canonical DagCBOR
Canonical DagCBOR must:
- CID tag (42) 이외의 태그는 사용하지 말것. 다른 태그는 전환시 손실될 수 있다.
- [canonical CBOR] https://tools.ietf.org/html/rfc7049#section-3.9) 인코딩을 사용하여야 한다.
- string map keys 만 사용하여야 한다.
IPLD - Specification: CIDs
원문은 IPLD Github specs 에서 확인 가능하다. IPLD CIDs
Specification: CIDs
Status: Descriptive - Final
문서에서 “Content IDs” 또는 “CIDs”는 서로 바꿔서 사용할 수 있다.
Protobuf 데이터에 대한 Prior Base58 Multihash 링크를 CID 버전 0 이라고 한다.
1. Summary
CID는 해시 기반 콘텐츠 식별자이다. ‘codec’ 과 ‘multihash’를 포함한다.
+-------+------------------------------+
| Codec | Multihash |
+-------+------------------------------+
long version:
+------------------------------+
|Codec |
+------------------------------+
|Multihash |
| +----------+---------------+ |
| |Hash Type | Hash Value | |
| +----------+---------------+ |
| |
+------------------------------+
2. CIDs Version 1
IPLD 링크 업데이트 구문을 함께 사용하면 multibase prefix, version, 압축된 multicodec 및 multihash를 사용하며 IPLD 데이터 CID 버전 1에 대한 새로운 핸들을 사용할 수 있다.
<mbase><version><mcodec><mhash>
<mbase>는 CID를 encode하는 베이스를 기술하는 멀티베이스 접두어이다. 바이너리의 경우는 생략된다.<version>은 cid의 버전 번호이다.<mcodec>는 CID 다중 코드 테이블의 다중 코드로 묶인 식별자이다.<mhash>는 다음을 포함하는 암호화 다중 해시이다:<mhash-code> <mhash-len> <mhash-value>
모든 CID v1은 언제나 <mbase><version>로 시작되어야 하며 매우 잘 진화되고 있다.
2.1 Multicodec Packed Representation
소규모 식별자에 사용하기 위해 소형 버전의 멀티 코드를 사용하는 것이 유용하다. 이 콤팩트 식별자는 테이블에서 찾은 단일 varint 이다. 다른 응용 프로그램은 다른 테이블을 사용할 수 있다. 잘 알려진 포맷에 대해 하나의 공통 테이블을 가져야한다.
IPFS v0 Merkledag, CBOR IPLD, Git, Bitcoin 등과 같은 공통된 인증 데이터 구조 형식에 대한 테이블을 구축한다. 이 테이블은 간단한 varint 조회이다.
2.2 Distinguishing v0 and v1 CIDs (old and new)
모든 IPFS 링크가 계속해서 작동하는 것은 어려운 조건이다. 이는 v0 CID를 계속 지원해야 함을 의미한다. 즉, IPFS API가 v0 및 v1 CID를 모두 수용해야 함을 의미한다. 이 섹션에서는 v0을 v1 CID와 구별하는 방법을 정의한다.
오래된 v0 CID는 base58에 엄격하게 sha2-256 다중 해시로 인코딩된다. 이는 IPFS 툴링이 sha2-256에 대한 지원과 함께 제공되기 때문이다. 이것은 바이너리 버전이 34 바이트 길이(sha2-256 256 bit multihash)이고 문자열 버전이 46자(46 characters) 길이 (base58 encoded)임을 의미한다. 이것은 v0 CID를 길이 256 비트의 sha256 비트 다중 해시 및 문자열인 경우 base58로 보장함으로써 인식 할 수 있음을 의미한다.
<mbase>는 암묵적으로 base58 이다.<version>은 암묵적으로 0 이다.<mcodec>은 암묵적으로 protobuf 이다. (v0와의 하위 호환성)<mhash>는 명시적으로 암호화 된 다중 해시이다.
element(요소)를 명시적으로 만들어 v1 CID에 오래된 v0 CID를 다시 쓸 수 있다. 이것은 앞으로 v0 CID를 더 많이 생성하지 않도록하기 위해 수행되어야한다. 그러나 많은 참고 문헌이 존재하므로 v0 링크를 계속 지원해야한다. 먼 미래에 sha2가 중단된 후 지원을 중단할 수 있다.
값을 깔끔하게 구분할 수 있으므로 두 가지를 모두 지원하기 쉽다. 이 코드는 다음과 같다. https://gist.github.com/jbenet/bf402718a7955bf636fb47d214bcef8a
2.3 IPLD supports non-CID hash links as implicit CIDv1s
Protobuf, Git, Bitcoin, Ethereum 등의 다양한 데이터 구조에 저장된 원시 해시 링크가 이미 존재한다 (예: Protobuf, Git, Bitcoin, Ethereum 등). 이 링크들은 데이터 구조 중 하나로 직접로드 될 때 “linking within a network(네트워크 내에서 링크)”로 간주 될 수 있지만 적절한 CIDv1 IPLD 링크는 “across networks(네트워크 간)” 링크로 볼 수 있다. 이러한 기존 (또는 새로운) 원시 해시 링크를 CIDv1로 지원하려면 원시 이진 링크만 사용하여 데이터 구조 링크에서 나머지 CIDv1 필드가 암묵적이라는 사실을 알면된다.
<mbase>는 암묵적으로 바이너리이거나 형식이 인코딩하는 모든 것이다.<version>은 암묵적으로 1이다.<mcodec>는 암묵적으로 데이터 구조와 동일하다.<mhash>는 원시 해시로부터 결정될 수 있다.
기본적으로 우리는 모든 다른 정보가 데이터 구조의 _컨텍스트_에 있기 때문에 원시 해시 링크에서 해당 CIDv1을 생성한다. 이것은 다음을 허용하기 때문에 매우 유용하다.
- 하나의 데이터 구조체에서 다른 구조체로 연결될 때 CIDv1 보다 간단한 인코딩
- 지금까지 명시된대로 CBOR IPLD에서 다른 CBOR IPLD 객체로 연결되므로 모든 IPLD 채택자가 계속 작업한다
- (가장 중요한) 다른 데이터 구조의 기본 지원을 위한 문을 연다.
2.4 IPLD addresses raw data
위의 변경 사항을 고려할 때 이제 원시 데이터를 IPLD 노드로 직접 처리 할 수 있다. 이 노드는 물론 단지 바이트 버퍼로 간주되고 링크(예: 리프 노드)가 없다.
이 유틸리티는 IPLD 데이터 구조 외부의 해싱을 통해 모든 객체를 직접 주소 지정하는 기능이다.
2.5 Support for multiple binary packed formats
이전의 Merkle 객체(예: IPFS protobuf legacy, git, bitcoin, dat 및 그외)와는 달리 새로운 IPLD 객체는 인증되고 자체적으로 데이터 블롭을 기술하고, 각 IPLD 객체는 그 포맷을 식별하는 멀티 코드에 의해 직렬화되고 접두어(prefix)된다.
IPLD - Concept: Serialization and Formats
원문은 IPLD Github specs 에서 확인 가능하다. IPLD Serialization and Formats
Concept: Serialization and Formats
format 과 serializer/deserializer 사이의 모든 IPLD 코덱에는 논리적 구분이 있다.
+--------------------+ +--------------------+
| | | |
| Serializer | | Deserializer |
| | | |
+--------------------+ +----------^---------+
| |
| Sent to another peer |
| |
+---------v----------+ +--------------------+
| | | |
| Format |-------------> Format |
| | | │
+--------------------+ +--------------------+
format(형식)은 원하는대로 객체 유형과 트리 구조를 나타낼 수 있다. 여기에는 기존 표현 (JSON, BSON, CBOR, Protobuf, msgpack 등) 또는 새로운 사용자 정의 직렬화가 포함된다.
따라서 format(형식)은 IPLD 링크 및 경로의 표준화 된 표현이다. 구조화 된 데이터와 바이너리간 변환 방법을 설명한다.
serializers 및 deserializers는 프로그래밍 언어에 따라 다르지만 format은 모든 코덱 구현에서 일관성을 유지해야 한다.
IPLD - Concept: Multihash
원문은 IPLD Github specs 에서 확인 가능하다. IPLD Multihash
Concept: Multihash
Multihash는 단일 해싱 알고리즘(single hashing algorithm)과 관련이 없는 해시 형식이다.
멀티해시(Multihash)는 해시 값과 해시 값에 사용되는 알고리즘을 설명한다.
