IPFS數據模型-IPLD

Salamander 發布于2019-06-27 18:30 / 888人閱讀

摘要：的內容尋址允許加密完整性檢查解析鏈接的值可以通過哈希來測試。例子使用以下數據集路徑的一個例子將遍歷第一個對象并獲取字符串。數據模型也非常簡單易用。由于基于數據模型，因此它完全可以通過與和關聯數據標準兼容。

ipld.io

Github：ipld

原文：IPLD specs

有許多系統使用merkle-tree和hash-chain受啟發的數據結構（例如git，bittorrent，ipfs，tahoe-lafs，sfsro）。IPLD（星際鏈接數據）定義：

merkle-links：merkle-graph的核心單元

merkle-dag：任何邊為merkle-links的圖。dag代表“有向無環圖”

merkle-paths：使用命名的merkl-links來遍歷merkl-dags的unix風格的路徑。

IPLD格式：可以表示IPLD對象的一組格式，例如JSON，CBOR，CSON，YAML，Protobuf，XML，RDF等。

IPLD規范格式：一種序列化格式的確定性描述，確保相同的邏輯對象始終被序列化到相同的位序列。這對于鏈接和所有加密應用程序都是至關重要的。

介紹 什么是merkle-link？

merkl-link是兩個對象之間的鏈接，它們是由目標對象的加密散列處理的，并嵌入到源對象中。merkl-links的內容尋址允許:

加密完整性檢查：解析鏈接的值可以通過哈希來測試。反過來，這可以實現廣泛，安全和可靠的數據交換（例如git或bittorrent），因為其他人不能給你任何不會散列到鏈接值的數據。

不可變的數據結構：帶有merkle鏈接的數據結構不能改變，這對于分布式系統來說是一個不錯的屬性。這對于版本控制，表示分布式可變狀態（例如CRDT）和長期存檔很有用。

一個merkle-link在IPLD對象模型中由包含一個key/mapped到“鏈接值”的映射表示。例如：

一個以json表示的“鏈接對象”的鏈接

{ "/" : "/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k" }
// "/" is the link key
// "/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k" is the link value

對象為foo/baz的鏈接

{
  "foo": {
    "bar": "/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k", // not a link
    "baz": {"/": "/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k"} // link
  }
}

對象在files/cat.jpg/link的實際鏈接以及files/cat.jpg中的偽“鏈接對象”。

{
   “ files ”： {
      “ cat.jpg ”： { //將鏈接屬性封裝在另一個對象中
      “ link ”： { “ / ”： “ / ipfs / QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k ” }，//鏈接
      “ mode ”： 0755，
      “owner”： “ jbenet ”
    }
  }
}

當取消鏈接時，映射本身將被它指向的對象替換，除非鏈接路徑無效。

該鏈接可以是multihash，在這種情況下，假設它是/ipfs層次結構中的鏈接，或者直接指向對象的絕對路徑。目前，只允許使用/ipfs層次結構。

如果應用程序想要將具有單個/key的對象用于其他目的，則應用程序本身應負責轉義/IPLD對象中的/key，這樣應用程序的key就不會與IPLD的特殊/key發生沖突。

什么是merkle-graph或merkle-dag？

帶有merkl-links的對象形成一個Graph（merkle-graph），如果加密散列函數的屬性保持不變，則這些對象必然都是定向的，并且可以認為它是非循環的，即merkle-dag。因此，所有使用merkle-linking（merkle-graph）的圖必定也是有向無環圖（DAG，因此為merkle-dag）。

什么是merkle路徑？

merkl-path是一種unix風格的路徑（例如，/a/b/c/d），它最初通過merkl-link進行引用，并允許訪問被引用節點和其他節點的元素。

我們鼓勵通用文件系統在IPLD上設計一個對象模型，該模型將專門用于文件操作，并有特定的路徑算法來查詢該模型。

merkle-paths如何工作？

merkl-path是一種unix風格的路徑，最初通過merkl-link進行引用，然后在中間對象中命名merkl-links。名稱后面的意思是查找對象，查找名稱并解析相關的merkl-link。

例如，假設我們有這個merkle-path：

/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k/a/b/c/d

路徑表述：

ipfs 是一個協議命名空間（允許計算機識別要做什么）

QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k 是一個加密哈希。

a/b/c/d是一個路徑遍歷，就像在unix中一樣。

路徑遍歷，用符號表示/，發生在兩種鏈接上：

對象內遍歷遍歷同一對象內的數據。

跨對象遍歷從一個對象遍歷到另一個對象，通過merkle-link解析。

例子

使用以下數據集：

> ipfs object cat --fmt=yaml QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k
---
a:
  b:
    link:
      /: QmV76pUdAAukxEHt9Wp2xwyTpiCmzJCvjnMxyQBreaUeKT
    c: "d"
    foo:
      /: QmQmkZPNPoRkPd7wj2xUJe5v5DsY6MX33MFaGhZKB2pRSE

> ipfs object cat --fmt=yaml QmV76pUdAAukxEHt9Wp2xwyTpiCmzJCvjnMxyQBreaUeKT
---
c: "e"
d:
  e: "f"
foo:
  name: "second foo"

> ipfs object cat --fmt=yaml QmQmkZPNPoRkPd7wj2xUJe5v5DsY6MX33MFaGhZKB2pRSE
---
name: "third foo"

路徑的一個例子：

/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k/a/b/c將遍歷第一個對象并獲取字符串d。

/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k/a/b/link/c將遍歷兩個對象并獲取字符串e

/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k/a/b/link/d/e遍歷兩個對象并獲取字符串f

/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k/a/b/link/foo/name遍歷第一個和第二個對象并獲取字符串second foo

/ipfs/QmUmg7BZC1YP1ca66rRtWKxpXp77WgVHrnv263JtDuvs2k/a/b/foo/name遍歷第一個和最后一個對象并獲取字符串third foo

什么是IPLD數據模型？

IPLD數據模型為所有merkle-dag定義了一個簡單的基于JSON的結構，并標識了一組格式來將結構編碼進去。

限制和期望

一些限制：

IPLD路徑必須是明確的。給定的路徑字符串必須總是確定性地遍歷到同一個對象。（例如避免重復鏈接名稱）

IPLD路徑必須是通用的，避免對非英語國家不友好（例如使用UTF-8，而不是ASCII）。

IPLD路徑必須在UNIX和Web上干凈地分層(使用/，對ASCII系統具有確定性的變換)。

考慮到JSON的廣泛成功，大量的系統提供了JSON接口。IPLD必須能夠對JSON進行簡單的導入和導出。

JSON數據模型也非常簡單易用。IPLD必須一樣易于使用。

定義新數據結構必須非常簡單。要在IPLD上嘗試新的定義，不應該很麻煩，也不需要太多的知識。

由于IPLD基于JSON數據模型，因此它完全可以通過JSON-LD與RDF和關聯數據標準兼容。

IPLD序列化格式（在磁盤上和在線上）必須快速且節省空間。（不應該使用JSON作為存儲格式，而應使用CBOR或類似的格式）

IPLD密碼哈希必須是可升級的（使用multihash）

一些不錯的點：

IPLD不應該犯下錯誤，例如JSON中缺少整數。

IPLD應該是可升級的，例如，如果出現更好的磁盤格式，系統應該能夠遷移到它之上并且最小化這樣做的成本。

IPLD對象應該能夠解析路徑的屬性，而不僅僅是merkle links。

IPLD Canonical Format應該易于編寫解析器。

IPLD Canonical Format應該能在不解析完整對象的情況下進行查找。（CBOR和Protobuf允許）。

格式定義

(注意:這里我們將使用JSON和YML來顯示格式是什么樣的。我們顯式地使用這兩種方法來顯示不同格式的對象的等價性。）

IPLD數據模型“是JSON”，它(a)也是基于樹的文檔，具有一些基本類型，(b)1:1映射到JSON， (c)用戶可以通過JSON本身使用它。它“不是JSON”(a)在某些錯誤上有所改進，(b)具有高效的序列化表示，(c)實際上并沒有指定單一的on-wire格式，因為眾所周知，這個世界正在改進。

基本的節點

以下是JSON中的示例IPLD對象：

{
   “ name ”：“ Vannevar Bush ” 
}

假設它散列的multihash值QmAAA...AAA。注意，它根本沒有鏈接，只是一個字符串名稱值。但是我們仍然能夠“解析”它下面的key name:

> ipld cat --json QmAAA...AAA
{
  "name": "Vannevar Bush"
}

> ipld cat --json QmAAA...AAA/name
"Vannevar Bush"

當然，我們可以用其他格式來查看它

> ipld cat --yml QmAAA...AAA
---
name: Vannevar Bush

> ipld cat --xml QmAAA...AAA
 

  Vannevar Bush

鏈接節點之間

節點之間的Merkle-Linking是IPLD存在的原因。IPLD中的鏈接只是一種特殊格式的嵌入式節點：

{
  "title": "As We May Think",
  "author": {
    "/": "QmAAA...AAA" // links to the node above.
  }
}

假設這個散列值為multihash值QmBBB...BBB。該節點通過子路徑author鏈接到QmAAA...AAA，上面這一節的節點。所以我們現在可以做到：

> ipld cat --json QmBBB...BBB
{
  "title": "As We May Think",
  "author": {
    "/": "QmAAA...AAA" // links to the node above.
  }
}

> ipld cat --json QmBBB...BBB/author
{
  "name": "Vannevar Bush"
}

> ipld cat --yml QmBBB...BBB/author
---
name: "Vannevar Bush"

> ipld cat --json QmBBB...BBB/author/name
"Vannevar Bush"

鏈接屬性約定

IPLD允許用戶構建復雜的數據結構，以及與鏈接相關的其他屬性。這對編碼其他信息以及鏈接（例如關系類型或鏈接中所需的輔助數據）很有用。這與下面討論的“鏈接對象約定”不同，它們本身非常有用。但有時候，你只是想在鏈接上添加一些數據而不必創建另一個對象。IPLD不會妨礙你。您可以簡單地通過將實際的IPLD鏈接嵌套在另一個對象中，并使用其他屬性來完成。

重要提示：鏈接屬??性不允許直接在鏈接對象中使用，因為存在明顯的歧義。閱讀規格歷史，了解有關難點的討論。

例如，假設您有一個文件系統，并希望在對象之間的鏈接中分配類似于權限或所有者的元數據。假設你有一個哈希值為QmCCC...CCC的目錄對象像這樣：

{
  "foo": { // link wrapper with more properties
    "link": {"/": "QmCCC...111"} // the link
    "mode": "0755",
    "owner": "jbenet"
  },
  "cat.jpg": {
    "link": {"/": "QmCCC...222"},
    "mode": "0644",
    "owner": "jbenet"
  },
  "doge.jpg": {
    "link": {"/": "QmCCC...333"},
    "mode": "0644",
    "owner": "jbenet"
  }
}

或YML

---
foo:
  link:
    /: QmCCC...111
  mode: 0755
  owner: jbenet
cat.jpg:
  link:
    /: QmCCC...222
  mode: 0644
  owner: jbenet
doge.jpg:
  link:
    /: QmCCC...333
  mode: 0644
  owner: jbenet

雖然我們在特定于此數據結構的鏈接中擁有新屬性，但我們仍然可以很好地解析鏈接:

> ipld cat --json QmCCC...CCC/cat.jpg
{
  "data": "u0008u0002u0012??u0008????u0000u0010JFIFu0000u0001u0001u0001u0000Hu0000H..."
}

> ipld cat --json QmCCC...CCC/doge.jpg
{
  "subfiles": [
    {
      "/": "QmPHPs1P3JaWi53q5qqiNauPhiTqa3S1mbszcVPHKGNWRh"
    },
    {
      "/": "QmPCuqUTNb21VDqtp5b8VsNzKEMtUsZCCVsEUBrjhERRSR"
    },
    {
      "/": "QmS7zrNSHEt5GpcaKrwdbnv1nckBreUxWnLaV4qivjaNr3"
    }
  ]
}

> ipld cat --yml QmCCC...CCC/doge.jpg
---
subfiles:
  - /: QmPHPs1P3JaWi53q5qqiNauPhiTqa3S1mbszcVPHKGNWRh
  - /: QmPCuqUTNb21VDqtp5b8VsNzKEMtUsZCCVsEUBrjhERRSR
  - /: QmS7zrNSHEt5GpcaKrwdbnv1nckBreUxWnLaV4qivjaNr3

> ipld cat --json QmCCC...CCC/doge.jpg/subfiles/1/
{
  "data": "u0008u0002u0012??u0008????u0000u0010JFIFu0000u0001u0001u0001u0000Hu0000H..."
}

但是我們無法像其他屬性那樣很好地提取鏈接，因為鏈接是要通過解析的。

重復屬性keys

注意，有兩個同名的屬性是不允許的，但實際上不可能阻止（有人會這樣做并將它提供給解析器），所以為了安全起見，我們定義了路徑遍歷的值作為序列化表示中的第一個條目。例如，假設我們有對象：

{
  "name": "J.C.R. Licklider",
  "name": "Hans Moravec"
}

假設這是規范格式(不是json，而是cbor)的準確順序，并且它的散列為QmDDD…DDD。我們總是得到:

> ipld cat --json QmDDD...DDD
{
  "name": "J.C.R. Licklider",
  "name": "Hans Moravec"
}
> ipld cat --json QmDDD...DDD/name
"J.C.R. Licklider"

路徑限制

Unix和Web中的路徑描述有一些重要的問題。有關討論，請參閱此討論。為了與unix和web的模型和期望兼容，IPLD明確禁止具有特定路徑組件的路徑。請注意，數據本身可能仍然包含這些屬性（有人會這樣做，并且有合法用途）。所以只有路徑解析器不能通過這些路徑來解析。這些限制與典型的unix和UTF-8路徑系統相同：

todo：

[ ] 列表路徑解析限制

[ ] show示例

JSON中的整型

IPLD可以直接與JSON兼容，以利用JSON的成功，但它不需要因為JSON的錯誤而受到限制。這是我們可以遵循格式慣用選擇的地方，但必須注意確保始終存在定義明確的1：1映射。

關于整數，在JSON中存在多種表示整數為字符串的格式，例如EJSON。這些可以被使用和轉換到其他格式，這是自然發生的- 也就是說，將JSON轉換為CBOR時，應該將EJSON整數自然地轉換為合適的CBOR整數，而不是將其表示為字符串值的映射。

序列化數據格式

IPLD通過multicodec支持各種序列化數據格式。這些可以使用，但是對于格式是慣用的，例如CBOR，我們可以使用CBOR類型tags來表示merkl-link，并避免寫出完整的字符串鍵@link。鼓勵用戶充分使用這些格式，并以最有意義的任何格式存儲和傳輸IPLD數據。唯一的要求是必須有一個明確定義的IPLD規范格式的一對一映射。這樣就可以將數據從一種格式轉換為另一種格式，而不必改變其含義或密碼哈希值。

帶標簽的序列化CBOR

在CBOR中，可以使用定義在RFC 7049 section 2.4.中的標記來表示IPLD鏈接。

標簽被定義。這個標簽可以是一個文本字符串(主類型3)或者是對應于鏈接目標的字節字符串(主類型2)。

將IPLD“鏈接對象”編碼到CBOR時，請使用以下算法：

提取鏈接值。

如果鏈接值是一個有效的multiaddress，并且將該鏈接文本轉換為多地址二進制字符串，并返回到文本將保證產生完全相同的文本，則該鏈接將轉換為存儲在CBOR中的二進制多地址字節字符串（主類型2）。

否則，鏈接值被存儲為文本（主類型3）

由此產生的編碼是鏈接值的CBOR表示

當解碼CBOR并將其轉換為IPLD時，的每一個事件都由以下算法轉換:

以下值必須是提取的鏈接值。

如果鏈接是二進制字符串，則將其解釋為多地址并轉換為文本格式。否則，直接使用文本字符串。

用一個鍵值對創建一個映射。關鍵是標準的IPLD鏈接key/，該值是包含鏈接值的文本字符串。

當一個IPLD對象以這里所述的方式包含這些標記時，用于表示對象編解碼器的multicodec頭必須是/cbor/ IPLD -tagsv1，而不僅僅是/cbor。讀者應該能夠使用優化的閱讀過程來檢測使用這些標簽的鏈接。

規范格式

為了保持merkle-linking的能力，我們必須確保IPLD文檔有一個單一的規范序列化表示。這可確保應用程序獲得相同的加密哈希。應該指出的是，這是一個系統范圍的參數。未來的系統可能會改變它來演進表示。不過，我們估計這需要十年不超過一次。

IPLD規范格式是帶tags的規范化CBOR。

除了此處定義的規則外，規范CBOR格式必須遵循RFC 7049 section 3.9中定義的規則。

這種格式的用戶不應該期望keys的任何特定排序，因為keys可能以不同的非標準格式排序。

傳統的規范格式是protocol buffers。

這種規范格式用于決定首次創建對象并計算其哈希時使用的格式。一旦為IPLD對象決定了格式，它必須在所有通信中使用，以便發送者和接收者可以根據散列來檢查數據。

例如，當發送一個在protocol buffers中編碼的傳統對象時，發送方不得發送CBOR版本，因為接收方將無法檢查文件的有效性。

同樣，當接收者存儲對象時，它必須確保該對象的規范格式與對象一起存儲，以便能夠與其他節點共享該對象。

用它們的格式存儲這些對象的一種簡單方法是用它們的multicodec頭存儲它們。

數據結構示例

重要的是，IPLD是一種簡單，靈活和可擴展的格式，不會妨礙用戶定義新的或導入舊數據文件的方式。為此，下面我將展示一些示例數據結構。

Unix文件系統

一個小文件

{
   “ data ”： “ hello world ”，
   “ size ”： “ 11 ” 
}

一個分塊文件
分割成多個獨立的子文件。

{
  "size": "1424119",
  "subfiles": [
    {
      "link": {"/": "QmAAA..."},
      "size": "100324"
    },
    {
      "link": {"/": "QmAA1..."},
      "size": "120345",
      "repeat": "10"
    },
    {
      "link": {"/": "QmAA1..."},
      "size": "120345"
    },
  ]
}

{
   “ foo ”： {
     “ link ”： { “ / ”： “ QmCCC ... 111 ” }，
     “ mode ”： “ 0755 ”，
     “ owner ”： “ jbenet ”
  }，
  “ cat.jpg ”： {
     “ link ”： { “ / ”： “ QmCCC ... 222 ” }，
     “ mode ”： “ 0644 ”，
     “ owner ”： “ jbenet ”
  }，
  “ doge.jpg ”： {
     “ link ”： { “ / ”： “ QmCCC ... 333 ” }，
     “ mode ”： “ 0644 ”，
     “ owner ”： “ jbenet ”
  }
}

git

git blob

{
   “ data ”： “ hello world ” 
}

git tree

{
   “ foo ”： {
     “ link ”： { “ / ”： “ QmCCC ... 111 ” }，
     “ mode ”： “ 0755 ”
  }，
  “ cat.jpg ”： {
     “ link ”： { “ / ”： “ QmCCC ... 222 ” }，
     “ mode ”： “ 0644 ”
  }，
  “ doge.jpg ”： {
     “ link ”： { “ / ”： “ QmCCC ... 333 ” }，
     “ mode ”： “ 0644 ”
  }
}

git commit

{
  "tree": {"/": "e4647147e940e2fab134e7f3d8a40c2022cb36f3"},
  "parents": [
    {"/": "b7d3ead1d80086940409206f5bd1a7a858ab6c95"},
    {"/": "ba8fbf7bc07818fa2892bd1a302081214b452afb"}
  ],
  "author": {
    "name": "Juan Batiz-Benet",
    "email": "juan@benet.ai",
    "time": "1435398707 -0700"
  },
  "committer": {
    "name": "Juan Batiz-Benet",
    "email": "juan@benet.ai",
    "time": "1435398707 -0700"
  },
  "message": "Merge pull request #7 from ipfs/iprs

(WIP) records + merkledag specs"
}

比特幣

比特幣block

{
   “ parent ”： { “ / ”： “ Qm000000002CPGAzmfdYPghgrFtYFB6pf1BqMvqfiPDam8 ” }，
   “ transactions ”： { “ / ”： “ QmTgzctfxxE8ZwBNGn744rL5R826EtZWzKvv2TF2dAcd9n ” }，
   “ nonce ”： “ UJPTFZnR2CPGAzmfdYPghgrFtYFB6pf1BqMvqfiPDam8 ” 
}

比特幣交易

這一次，在YML中。TODO：讓它是一個真正的txn

---
inputs:
  - input: {/: Qmes5e1x9YEku2Y4kDgT6pjf91TPGsE2nJAaAKgwnUqR82}
    amount: 100
outputs:
  - output: {/: Qmes5e1x9YEku2Y4kDgT6pjf91TPGsE2nJAaAKgwnUqR82}
    amount: 50
  - output: {/: QmbcfRVZqMNVRcarRN3JjEJCHhQBcUeqzZfa3zoWMaSrTW}
    amount: 30
  - output: {/: QmV9PkR2gXcmUgNH7s7zMg9dsk7Hy7bLS18S9SHK96m7zV}
    amount: 15
  - output: {/: QmP8r8fLUnEywGnRRUrHB28nnBKwmshMLiYeg8udzYg7TK}
    amount: 5
script: OP_VERIFY

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/24134.html

【戴嘉樂】詳解IPFS的本質、技術架構以及應用

摘要：戴嘉樂去年月參與了的眾籌，從而了解到技術，獨立開發了兩款基于的開源應用，一個是與有關的系統，另一個是相關的地理位置檢索系統。現在支持的數據結構，支持比特幣以太坊的區塊數據。戴嘉樂是前百度高級研發工程師，ipfser.org&巴比特專欄作者。戴嘉樂去年8月參與了FileCoin的眾籌，從而了解到IPFS技術，獨立開發了兩款基于IPFS的開源應用，一個是與IPFS有關的wiki系統，另一...

whlong 2019-06-27 18:54 評論0 收藏0
LibP2P規范文檔 - 中文翻譯

摘要：要完成這些，實現必須支持中繼，雖然它應該是可選的，并且能夠被終端用戶關閉連接中繼應該作為傳輸來實現，以便對上層透明中繼的實現，可參考啟用多種網絡拓撲不同的系統有不同的需求，進而導致不同的拓撲結構。目前進度為80%, 持續更新... 1 介紹在開發IPFS（星際文件系統）的過程中，我們遇到了很多在異構設備之上運行分布式文件系統所帶來的若干挑戰，這些設備具有不同的網絡設置和能力。在這個...

fevin 2019-06-27 18:31 評論0 收藏0
IPFS安裝與概覽

摘要：安裝與概覽由于我使用的實現為，所以首先要安裝配置環境。六安裝輔助工具和，前者是一個桌面客戶端，后者是一個瀏覽器插件，可以在及等瀏覽器上安裝。你可以新開一個終端使用下等功能好了，本次對的安裝配置到此結束，后續會更新更多內容。 IPFS安裝與概覽由于我使用的IPFS實現為go-ipfs，所以首先要安裝配置Golang環境。我使用的系統為Ubuntu18.04，后面所有操作均在此系統下完...

leanxi 2019-06-27 18:50 評論0 收藏0
【戴嘉樂】基于IPFS和GeoHash構建具有地理位置價值服務的DDApp（理論篇）

摘要：數據將具有如下個特點將二維的經緯度轉換成字符串，比如下圖展示了北京個區域的字符串，分別是，等等，每一個字符串代表了某一矩形區域。例如，坐標對，位于北京安定門附近，后形成的值為。作者簡介：戴嘉樂( Mr.Maple ) | 前百度高級研發工程師 | IPFS應用實踐者&布道師|個人網站：https://www.daijiale.cn聯系方式：微信號：daijiale6239。 show...

lmxdawn 2019-06-27 18:54 評論0 收藏0
【許曉笛】EOS：IPFS落地的重要途徑

摘要：寫在前面，這一篇文章是許曉笛在北京開發者圓桌會議上的發言實錄，感謝主辦方戴嘉樂和董天一的邀請，感謝編輯們。我這次分享題目是有可能有點標題黨，前面拉了三個字有可能是落地的一個非常重要的途徑。共識機制共識機制，就是所有代幣持有人選舉。寫在前面，這一篇文章是許曉笛 2018.05.20 在北京《IPFS開發者圓桌會議》上的發言實錄，感謝主辦方戴嘉樂和董天一的邀請，感謝編輯們。先介紹一下《...

tuomao 2019-06-27 18:55 評論0 收藏0