Oyster Protocol 筆記

• 參考: Oyster Whitepaper Rev. 0.7b

Oyster

• 基於智能合約的系統

• 結合 IOTA Tangle 及以太坊區塊鏈

• 分散式儲存

• 現有架構
  

• Oyster 架構
  

Oyster 生態系統成員

• 儲存用戶
  • 花費 Oyster Pearls，安全、可靠、匿名地儲存檔案
• 網站所有者
  • 獲得報酬
• Web 節點
  • 網站瀏覽者使用的瀏覽器
  • POW
• 經紀人節點
  • 和 Tangle 、區塊鏈溝通
• IOTA Tangle
  • 保存資料
• 以太坊區塊鏈
  • Oyster Pearls 智能合約框架

Tangle 上資料儲存

• datamap
  datamap-generator
  

• 根據 Oyster Protocol 規定選擇 2 個經紀人節點

• 儲存用戶將 Genesis Hash 交給 2 個經紀人節點

• 儲存用戶支付的珍珠數量是最終嵌入 Data Map 中的數量的一半

• 經紀人節點

  • 若不履行義務，透過分散式信譽系統 (Distributed Reputation System) 回報
  • 在數據地圖正確安裝後，經紀人節點被允許保留任何剩餘的珍珠
  • 做 POW 把 Data Map 上 tangle，address 為 Genesis, …, Hash NX
  • 經紀人節點可把 POW 委派給 Web 節點
  • 經紀人節點分為 Alpha Node, Beta Node

    • Alpha Node

      • 從 Genesis Hash 開始向下，確認 Data Map
      • 收到全部 Pearl、Beta Node 的以太坊地址
      • 發送一半的 Pearl 給 Beta Node

    • Beta Node

      • 從 Hash NX 開始向上，確認 Data Map

由經紀人節點埋藏 Pearls

• 由經紀人節點埋藏的理由:

  • 經紀人節點可存取 ETH 餘額，可以支付搬動 Pearls 所需 gas (類似手續費)。 每 X GB 需要一個以太坊區塊鏈的交易。
  • 對儲存用戶而言發起交易和智能合約太複雜。
  • 減輕紅鯡魚的攻擊

• 紅鯡魚的攻擊

  • 儲存用戶假裝將 Pearls 嵌入到數據映射中但實際上並未嵌入 Pearls。
  • 如果儲存用戶惡意放入不合法的 Pearls，經紀人節點發現後會回報，降地其信譽。

紅鯡魚 (Red Herring) 在英文中有誤導、混淆群眾的含義。

• 經紀人節點在分散式信譽系統的身份要一致，因為關聯信譽分數；儲存用戶跟 Web 節點的身份則是動態的。

  • 儲存用戶、Web 節點很難產生一致加密身分。
  • Web 節點每挖到 X 個寶藏，其身分要重設。
  • 儲存用戶除了與經紀人節點溝通外沒有可識別身分。

• 大約儲存用戶支付 Pearls 的一半被嵌入 Data Map，一半給經紀人節點。

• 兩個經紀人節點安裝 Data Map 就像兩頭燒的蠟燭。

  • 經紀人節點安裝愈慢或不完全愈有利，因為有權保留剩下沒埋藏的 Pearls。

  • 經紀人節點一開始被指派一個信譽分數為 (最小值) 0 的加密身分。

  • 儲存用戶、Web 節點尋找分數最高的經紀人節點。

  • 分數隨燃燒速度線性增加而指數型增加。

  • 儘管前面提到愈慢愈有利，經紀人節點仍會盡可能的增加燃燒速度。短期看來獲利較少；長期卻會指數型的多很多。

• 埋藏寶藏

  • 一個區段 (Sector) 代表 1000000 個 hash。
    
  • 每個區段至少有一個包含 Pearls 的寶藏。有時候兩個經紀人節點沒完美合作，會包含 2 個寶藏。
  • 寶藏的位置由兩個經紀人節點隨機選擇
  • 每個區段 Pearls 的數量愈多，可以保存在 Tangle 上時間愈長。 1 PRL 保證 X GB 可在 Tangle 存上 1 年。
  • Oyster 合約查看 Pearls 的數量來看儲存持續的時間。這段時間內 Web 節點做 POW 來尋找 Pearls。

• Oyster Protocol 定義一個 Epoch 為一年。

• 舉例來說，一個 Sector 有 2 PRL (儲存時間 4 年)，有 4 個 Epoch：第一年、第二年、第三年、第四年，每個 Epoch 有剛好 0.5 PRL 被聲明擁有。

注意: 白皮書內說明不一致

Oyster Pearls 尋寶

• Web 節點從經紀人節點或其他 Web 節點取得 Genesis Hash

  • 並不是平白無故取得，需做對方定義的 POW 任務才可以拿到 Genesis Hash。
  • 做完後回報給對方，對方完驗證後發送 Genesis Hash 給 Web 節點。

• 隨機選 Data Map 的一個區段。 在 Tangle 上找這個區段 POW 在這個 Epoch 是否已經被執行。如果 POW 被執行過，放棄這個區段重做選擇。 如果沒有，瀏覽整個區段內的 Hash。

• Web 節點果不遵守規定，成為唬人的 Web 節點 (bluffing Web Nodes)。

  • 對沒有寶藏的區段做 POW ，導致下個 Epoch 只有自己可以保有這個區段，別的節點不能存取。

• 每次遇到 hash，Web 節點會對 Tangle 上相對應的交易做 POW，並使用 GPU (WebGL2)。 取回 payload 後算 hash (SHA512)，並作為解密金鑰。如果解鎖了，代表找到寶藏；如果沒有，再做一次 hash，直到找到寶藏，或到達上限並嘗試下一組。

  跑完一組 hash chain 要好幾天 (< 5 MB per day)

  • 每個區段一定有一個寶藏，如果沒有是不合法的，回報分散式信譽系統並降低發出該 hash 經紀人節點的信譽分數。
  • 尋寶 (SHA256、SHA512、解密) 使用 CPU。
  • POW、和其他節點協商使用 GPU。

• 寶藏裡是包含 Pearls 的乙太坊 private seed key。但有以下兩個問題。

  • Web 節點不能直接存取乙太坊區塊鏈。
  • private seed key 內有 Pearls 但沒有 ETH，所以不能付 Gas。

• 於是 Web 節點安全的發送 private seed key 給經紀人節點。 經紀人節點確認 Pearls 存在後，付 ETH 作為 Gas。 然後提交 Oyster 合約的交易到區塊鏈上。 合約中聲明 Pearls 為網站所有人的乙太坊地址所擁有。 但有兩個疑慮:

  • Web 節點怕經紀人節點偷取 Pearls，沒有使用正確的乙太坊地址。
    • 用分散式信譽系統解決。
  • 經紀人節點怕 Web 節點騙 Gas。
    • 騙 Gas 必須先做 POW，成本遠大於 Gas

Web 節點和經紀人節點的協作

• 技術上來說 Web 節點可以直接存取 Tangle ，但現階段能函式庫、吞吐量、硬體等限制，因此仍需要透過經紀人節點。 Oysrter Protocol 需藉由 SSL 傳輸，Tangle lite client host 現階段無法辦到。

• 經紀人節點允許 Web 節點間 P2P 溝通。

  • PeerJS Library

• Web 節點做 POW，跟經紀人節點交換 Genesis Hash

  1. Web 節點詢問經紀人節點有無新的 Genesis Hash，或新的鄰居。
  2. 經紀人節點回應，並指示 POW 任務
  3. 如果 Web 節點同意，回復接受任務
  4. 經紀人節點回復 3 筆 Tangle 上的交易，關於儲存資料一筆，要驗證的交易兩筆 (tips)。
  5. Web 節點執行 replayBundle function，設定經紀人節點指定的 branch、trunk。
  6. Web 節點完成 POW 並提出交易後，回傳該交易資訊給經紀人節點。
  7. 經紀人節點驗證交易內容
  8. 滿足所有條件後，經紀人節點送出 Genesis Hash，或鄰居的身分。 並在分散式信譽系統提交相關資訊。

• 檔案過期後 Genesis Hash 會被忘掉，並不會保證檔案存在 Tangle 上。

Web 節點到 Web 節點的互動

• P2P conection via PeerJS Library
• 在 Oyster Network 上有一個 cryptographic pseudo-persistent 的身分(id)
  • id 會維持可信賴和一致，直到尋報到一個階段並重頭開始
  • 刷新 id 是為了避免網路過於靜態，不希望維持鄰居關係太久
• 當新 Web 節點首次加入時並沒有鄰居，先取得鄰居列表，這時會面對 "Catch-22(坑人二十二)" 的困境。鄰居由其他 Web 節點共享，但新 Web 節點無法取得，所以必須靠經紀人節點提供。

坑人二十二
e.g. 沒有工作經驗便不能找到一份工作，但沒有工作便不能得到工作經驗

• 做 POW 跟經紀人節點換 id 列表

• Web 節點做 POW 跟其他節點換有價值的資訊(如:Genesis Hash)，流程如下

  1. Web 節點詢問鄰居是否有可用的新 Genesis Hashes 或鄰居 id
  2. 鄰居回應，並請求 POW 任務做交換。POW 難度隨 Oyster Network 波動
  3. 如果 Web 節點同意 POW 負擔則接受
  4. 鄰居傳送 3 個 Tangle 上的交易，關於儲存資料一筆，要驗證的交易兩筆，他們被指定為 branch and trunk 交易。
  5. Web 節點在 Tangle 上執行replayBundle函數，因此完全按照鄰居指定的方式設置交易的 branch and trunk
  6. 完成 POW 並發出交易後，回傳該交易資訊給鄰居
  7. 鄰居節點驗證內容
  8. 如果還有其他 POW 負荷量，重複以上流程
  9. 一旦完成所有負荷量，鄰居節點將新 Genesis Hashes 或鄰居 id 作為交換

• 通常來自經紀人節點的 POW 負擔比來自鄰居 Web 節點的大，因為經紀人節點有較新的 Genesis Hashes，新的 Genesis Hashes 挖到寶藏的期望值較高。

• Web 節點間連接時會計算連線延遲，並持續優化鄰居列表，以便與較近的節點溝通

• 優化的結果讓 Oyster Network 為一個低延遲的網路，具有高效的節點跳躍路徑 (Node hop pathways)，並可在其上構建第三方應用程序。

  • e.g. Javascript telephone service

內容消費權利

• 網頁擁有者得到經濟支持是合理的，因此產生了廣告的方式，但卻分散了瀏覽者注意力、侵犯隱私權、打亂網頁設計結構等等，因此廣告在互聯網上被藐視，廣告攔截軟體成了主流，卻打破了互聯網的經濟模式。

• Oyster Protocol 是個全新的廣告範例，瀏覽者有付出算力且不受廣告干擾，網頁擁有者得到收入並繼續提升網頁品質。

• 網頁擁有者只需加入像下面的程式碼就可啟用 Oyster Protocol 並自動收款(Pearls)

  • <script id="o.ws" data-payout=“ETH_ADDRESS”src=“https://oyster.ws/webnode.js"></script>

• 如果瀏覽者不願付出算力也可以禁止，而網頁擁有者也可輕易停止提供網頁內容。

• Web 節點使用 HTML5 localstorage 保存數據，因此在不同網站上仍保有相同 Web 節點身分。

• 情境: 一個人用電腦瀏覽 A 、 B 網站，電腦上運行的 Web 節點身分一樣，在瀏覽 A 網站時挖到的 Pearls 歸 A 網站擁有者，在瀏覽 B 網站時挖到的 Pearls 歸 B 網站擁有者。

Oyster Pearls 代幣功能

tags: oyster