· 網路獎勵和激勵機制
先付費後服務還是先服務後付費？這是一個先有雞還是先有蛋的問題…
下面，我們將從技術性的角度深入探討部署在Ocean Network中的SEAs概念。服務執行中的unhappy路徑處理資料服務時可能會發生很多出錯。我們列舉了一些案例，但在邊緣案例中或許存在更多情況：· 服務可能不存在，但是消費者卻已支付該服務。· 服務可能已正確交付，但消費者拒絕或忘記回報服務提供商。· 服務提供商可能不授予合法使用者訪問許可權，或授予非合法使用者訪問許可權。· 服務沒有達到消費者的功能要求或者表現不如預期。· 服務響應或日誌在網路或翻譯中被“丟失”。服務請求/響應世界中的一些unhappy路徑。
有很多方法可以防止此類災難情況。典型的採購部門在提供商和消費者之間建立法律協議。數字服務能夠新增多層數位安全措施（加密、簽名、雜湊、加密證明和鑑證）並實現自動化。分散式服務網路在複製的代價上加了一層冗餘。隨著信任水平的降低，例如在（匿名）公鏈的情況下，人們可以探索底層原生代幣的經濟和聲譽激勵機制。服務協議和信任的色調（紅色：低信任 / 綠色：更多信任）
一項服務在供應鏈中越關鍵，需要確保執行的水平就越嚴格。就好比自然災害的預警系統需要比羅勒植物中的溼度感應更高水平的耐受度（大概可以這麼認為）。每個人都有條件類似於採購中法律SLAs的條款和條件，Ocean SEAs同樣具有可作為程式碼嵌入智慧合約的條件。協議中的交易方必須滿足這些條件。例如，我們描述了一個服務提供商向消費者提供受驗證的資料服務的場景。這樣的資料服務可以是一個簡單的資料檢索，也可以是機器學習（ML）或人工智慧（AI）環境中的複雜計算。三方締約參與一項服務協議。
在上述場景中，服務提供商願意提供資料服務，因為消費者確保在服務交付後就會付款。反過來，消費者只有在收到服務的情況下才會付款，而服務的表現則由驗證者來進行驗證。驗證者（或驗證者網路）也會要求在進行任何驗證工作之前檢視款項。
以上的場景可能會根據應用情況更復雜或簡單。因此，接下來我們將深入探討SEAs的構成。
模組化服務執行協議的剖析
在Ocean Protocol中，SEAs具有一個模組化的設計，以涵蓋使用各種web2.0（雲端/內部部署）和web3.0服務的靈活性。
服務執行協議的組成部分。
我們說明SEA中的三個主要部分：服務識別符號加密ID用於具體標識要使用的服務。出於規模和隱私原因，服務的實際後設資料和端點/訪問詳細資訊將保持在鏈下。此類詳細資訊可以透過點對點的方式傳達，或在私鏈或公鏈的後設資料網路中解決。根據我們鼓勵標準和互動操作性，我們選擇採用新興的W3C去中心化身份（DID）標準。 代理、服務和域名均由Ocean Protocol中的DID（例如：“did:op:12345s3rv1c3”）來處理。它們各自的DID文件中包含後設資料和服務消費資訊儲存於公開/公鏈/私人資料中。我們正在研發具備完整性檢查、版本控制和不可抵賴性的Ocean Identifiers識別符號。欲知更多有關實施具體資訊，請檢視OEP7。條件和履行在一個不完美的世界裡，我們與鏈下、鏈上、側鏈和其它鏈服務和活動進行交易。這些服務可能是正確執行、幾乎正確執行甚至執行失敗。在某個時間點，Ocean SEAs將願意瞭解這些服務的狀態以解決糾紛。因此我們引入條件和履行措施。簡而言之，我們討論的是可以履行的加密和非加密條件。每個條件都有一個驗證功能，它將顯示“對”，“錯”或“未知”。“未知”值意味著條件尚未證明已履行。所有條件均從“未知”開始。驗證邏輯將在鏈上執行。條件可被視為SEA的輸入。我們在條件允許的情況下可以靈活地將“服務證明”編碼進SEA。條件是必須解決的挑戰，而履行則是其解決方案。獎勵邏輯會根據履行的條件來分配輸出。此類條件可能是簡單的加密挑戰（例如，提供一個用於計算零結尾雜湊值的原像，或證明您擁有與公鑰對應的私鑰），到更復雜的挑戰（例如SN / TARKs、計算鑑證、時空證明、可檢索性證明）以及更主觀的挑戰（例如投票或策展場景中的m-of-n簽名、質押/削減，等等）。當驗證活動發生在非Ocean網路中時，條件可以簡單地連結至預言機（oracles）或彌合合同以解決糾紛。根據條件的履行程度獲得獎勵。條件是必須解決的挑戰，而履行則是其解決方案（綠色：已履行/有效，橙色：未履行/未知，紅色：無效）。獎勵邏輯會根據履行情況來分配輸出。
條件和履行的實際實施是加密條件IETF草案的變體（由Interledger協議發起）。每個條件/履行均是加密挑戰/證明配對，例如：· 雜湊 / 原像：尋找一個計算給定雜湊的原像。原像的雜湊計算髮生在鏈上。這個條件對締約方很有用，以證明他們都瞭解這個秘密。· 公鑰 + 訊息 / 簽名：使用對應給公鑰的私鑰，簽署一個給定資訊。簽名的驗證發生在鏈上。適用於在非對稱金鑰配對方案中驗證身份。· m-of-n閾值：如果已正確履行n個條件中的m個，則驗證為“對”。適用於多方糾紛解決，如投票。· 查詢/解析：連結至一個公共可用狀態值（用時間戳來記錄），並在驗證時解析/對比該狀態值。查詢是在鏈上執行的，因此它僅限於鏈狀態情景內的GET操作（例如contractAddress.getValue）。適用於彌合服務和oraclize鏈下值。多個條件組合能在更復雜的邏輯中來表達：· 付款條件：提交至合同的代幣數量相等於預約定的代幣價格。· 訪問控制：傳達給消費者的一個訪問控制秘密。· 受驗證計算：驗證者網路同意並簽署有關服務是否已正確交付。我們預料到生態系統中可能會出現更多條件，因此透過仔細稽覈和管理，將這些條件可以安全置入SEA。我們可以利用管理合同，如代幣精選清單、權益機器或去中心化自治組織（DAOs）。獎勵邏輯SEA的輸出指的是一般上分配給已履行一個或多個條件的代理的獎勵。獎勵可以在網路獎勵功能中以款項、版稅、許可、徽章、聲譽或彩票等形式來發布。可以設想多種獎勵機制，並將它們在受管理的模板中進行整合（類似於條件庫）。Ocean Protocol中實施的基本獎勵結構為託管或持有代幣。在這種結構中，代幣被鎖定在SEA中以便實現：· 如果在超時前履行所有條件，則執行。執行款項意味著鎖定的代幣可以被轉移到接收方。· 如果在超時後未履行所有條件，則中止。中止款項意味著鎖定的代幣會被歸還給發起方。· 在未來的釋出中，我們將加入更復雜的獎勵計劃，如支付流、獎金、比賽和版稅計劃。服務執行協議的生命週期瞭解SEA的所有組成部分後，使用者可以開始釋出服務，透過SEA在市場上與消費者互動。我們會解釋每一個步驟，但首先讓我們來解釋一些細節。服務釋出提供者可以透過定義訪問、使用和監控（見OEP11）的後設資料（見OEP8）和API呼叫來提供服務。接下來，提供者在市場中扮演釋出者的角色（或委派該角色）。釋出者從模板中選擇一份SEA，並將其包含在服務身份文件中，然後才在市場中釋出。釋出方式包括公共後設資料儲存（名為Aquarius），Web API /論壇或點對點訊息。一旦服務釋出了，消費者就可以檢視它。雙方透過簽署和執行協議來實現SEA。Ocean Protocol的釋出流程：從資源到服務執行協議。
接下來，我們將在各種SEAs的操作過程中探索它們的幾個生命週期。訪問控制一個基本的SEA採用託管獎勵來提供鏈下資源的訪問控制。以下是SEA的相關活動：簽名和執行：雙方同意，並建立訪問控制SEA的例項。付款：消費者把所需的代幣數額鎖定在託管中。訪問：服務提供商授予資源的訪問並在鏈上報告這個活動。獎勵：託管要麼執行或中止，取決於訪問條件和超時情況。釋出後實現簡單訪問控制SEA的生命週期。
在鏈下訪問控制情景中，請注意僅證明已傳達某些訪問代幣，而非代幣在某環節中實際有效和消耗。服務驗證更復雜的用例可以擴充套件以上所述的訪問控制，透過新增驗證活動到服務中 [進展中，即將在下一個釋出中推出]。在這裡，資源提供者向驗證者網路提交一個或多個服務證明或鑑證。驗證者網路的任務是解決有關服務表現出的糾紛（例如Truebit、fitchain、Enigma、Filecoin等）。在這裡，SEAs由預言機或使用查詢條件的彌合合約連結。因此，SEA將可以簡單地連結和解決驗證者網路的糾紛解決結果。一個外部驗證者網路用於驗證服務以證明及彌合糾紛解決週期的結果。
綜上所述總之，我們已經為將所有活動都放在SEA的生活週期之中打下堅實的基礎。注意多個SEAs可以輕鬆並行執行。鏈下/側鏈資源和授權伺服器只需聽取SEA發出的預定義活動。Ocean Protocol SEA的生命週期，從釋出到消費和驗證。
結論我們剖析了Ocean Protocol服務執行協議和其生命週期。這些協議是可證明起源、糾紛解決和獎勵機制等的基礎。它們基本上連線起Ocean Protocol生態系統中的資料服務。現在您知道Ocean中存在SEAs，那就讓我們繼續探索…
