本文旨在扩展和补充海洋协议的技术架构，因此我们将深入研究服务执行协议（SEA）。 SEA 将海洋协议网络中的服务提供者、消费者和验证者紧密结合在一起。

准备好征服东南亚……[来源：Kwinten Crauwels]

在之前的文章[1, 2] 中，我们解释了为什么服务级别协议(SLA) 实际上支撑着我们所知道的世界。整个物理和数字服务供应链通过合同捆绑在一起，以降低交易对手风险并确保可用性、可靠性和正常运行时间。

在Ocean Network，我们专注于数据和人工智能服务的公平交换，以保护商业交易中的各方。这样可以提前了解服务协议的条款和条件，而不必依赖外部各方解决争议。服务协议及其生命周期基于：

去中心化的访问控制、争议解决、溯源服务、消费网络奖励激励机制，先付费后服务，还是先服务后付费？这是先有鸡还是先有蛋的问题……

下面，我们将从技术角度深入探讨Ocean Network中部署的SEA的概念。

服务执行中的不愉快路径在处理数据服务时，很多事情都可能出错。我们列出了一些情况，但边缘情况可能还有更多：

该服务可能不存在，但消费者已为该服务付费。服务可能已正确提供，但消费者拒绝或忘记向服务提供商报告。服务提供商可能会拒绝合法用户的访问或向非合法用户授予访问权限。服务不满足消费者的功能需求或执行不符合预期。服务响应或日志在网络或翻译过程中“丢失”。服务请求/响应世界中的一些不愉快的路径。

有很多方法可以防止此类灾难的发生。典型的采购部门在供应商和消费者之间建立法律协议。数字服务能够添加多层数字安全（加密、签名、散列、加密证明和证明）并实现自动化。

分布式服务网络以复制为代价增加了一层冗余。随着信任水平的降低，例如在（匿名）公共链的情况下，人们可以探索底层原生代币的经济和声誉激励。

服务协议和信任度（红色：低信任度/绿色：更多信任度）

服务在供应链中越重要，需要确保的执行水平就越严格。这就像自然灾害预警系统需要比罗勒植物中的湿度传感更高的耐受性（或者是这样）。

每个协议都有与采购中的法律SLA 类似的条款和条件，海洋SEA 也有可以作为代码嵌入到智能合约中的条款和条件。协议各方必须满足这些条件。

例如，我们描述了服务提供商向消费者提供经过身份验证的数据服务的场景。这样的数据服务可以是简单的数据检索，也可以是机器学习（ML）或人工智能（AI）环境中的复杂计算。

三方签订服务协议。

在上述场景中，服务提供商愿意提供数据服务，因为消费者确信一旦提供服务就会付款。反过来，消费者只有在接受服务时才会付费，并且服务的性能由验证者验证。验证者（或验证者网络）还将要求在进行任何验证工作之前查看资金。

根据应用的不同，上述场景可能更复杂或更简单。因此，接下来我们将深入研究SEA的组成。

模块化服务执行协议剖析在Ocean Protocol 中，SEA 采用模块化设计，涵盖使用各种web2.0（云/本地）和web3.0 服务的灵活性。

服务执行协议的一部分。

我们说明SEA 中的三个主要部分：

服务标识符CryptoID用于专门标识要使用的服务。出于规模和隐私原因，服务的实际元数据和端点/访问详细信息将保留在链外。这些详细信息可以在私有链或公共链上的元数据网络中进行点对点通信或解析。

为了符合我们对标准和互操作性的鼓励，我们选择采用新兴的W3C 去中心化身份(DID) 标准。代理、服务和域名均由Ocean Protocol 中的DID 处理（例如：“did:op:12345s3rv1c3”）。它们各自的DID文档包含存储在公有/公链/私有数据中的元数据和服务消费信息。我们正在开发具有完整性检查、版本控制和不可否认性的海洋标识符。有关更多具体实施信息，请参阅OEP7。

条件和履行在一个不完美的世界中，我们通过链下、链上、侧链和其他链服务和活动进行交易。这些服务可能会正确执行、几乎正确执行，甚至会失败。在某个时间点，海洋SEA将愿意了解这些服务的状态以解决争端。

所以我们介绍一下条件和落实措施。简而言之，我们讨论的是可以满足的加密和非加密条件。每个条件都有一个验证功能，将显示“True”、“False”或“Unknown”。 “未知”值意味着尚未证明条件已满足。所有条件均以“未知”开头。验证逻辑将在链上执行。条件可以被视为战略环评的输入。

在条件允许的情况下，我们可以灵活地将“服务证明”编码到SEA中。条件是必须解决的挑战，而满足则是它们的解决方案。奖励逻辑根据满足的条件分配输出。此类条件可能包括从简单的密码挑战（例如，提供用于计算零终止哈希的原像，或证明您拥有与公钥相对应的私钥）到更复杂的挑战（例如SN/TARK、计算取证、时空分析）证明、可检索性证明）以及更主观的挑战（例如投票或管理场景中的m-of-n 签名、质押/削减等）。

当验证活动发生在非海洋网络中时，可以简单地将条件链接到预言机或桥接合同来解决争议。

根据满足条件获得奖励。条件是必须解决的挑战，而履行是其解决方案（绿色：已履行/有效，橙色：未履行/未知，红色：无效）。奖励逻辑根据履行情况分配输出。

条件和履行的实际实施是加密条件IETF 草案的变体（由Interledger 协议赞助）。每个条件/满足都是一个加密挑战/证明配对，例如：

哈希/原像：查找计算给定哈希值的原像。原像的哈希计算发生在链上。此条件对于双方证明他们都了解该秘密很有用。公钥+消息/签名：使用公钥对应的私钥对给定消息进行签名。签名验证发生在链上。适用于非对称密钥配对方案中的身份验证。 m-of-n 阈值：如果正确满足n 个条件中的m 个，则验证为“正确”。适合多方争议解决，比如投票。查询/解析：链接到公开可用的状态值（用时间戳记录）并在验证时解析/比较该状态值。查询在链上执行，因此仅限于链状态上下文中的GET 操作（例如contractAddress.getValue）。与桥梁服务合作并oraclize链下价值。多个条件组合可以用更复杂的逻辑来表达：

付款条件：提交给合约的代币数量等于预定的代币价格。访问控制：传达给消费者的访问控制秘密。 [查看这篇文章] 验证计算：验证者网络同意并签署服务是否已正确交付。 [链接到即将发表的文章]我们预计生态系统中可能会出现更多条件，因此通过仔细审查和管理，这些条件可以安全地放入SEA中。我们可以利用治理合约，例如代币管理列表、质押机或去中心化自治组织（DAO）。

奖励逻辑

SEA的输出是指通常分配给满足一个或多个条件的代理的奖励。奖励可以通过网络奖励功能内的付款、版税、许可证、徽章、声誉或彩票的形式发放。可以设想多种奖励机制并将它们集成到托管模板中（类似于条件库）。

Ocean Protocol 实施的基本奖励结构是代币的托管或持有。在此结构中，代币被锁定在SEA 中以启用：

如果在超时之前所有条件都满足，则执行。执行支付意味着锁定的代币可以转移给接收者。如果超时后未满足所有条件，则中止。暂停支付意味着锁定的代币将被返还给发起者。在未来的版本中，我们将包括更复杂的奖励计划，例如付款流、奖金、竞赛和版税计划。服务执行协议的生命周期在了解了SEA的所有组成部分之后，用户就可以开始发布服务并通过SEA与市场上的消费者进行互动。我们将解释每个步骤，但首先让我们解释一些细节。

服务发布提供商可以通过元数据（请参阅OEP8）和定义访问、使用和监控（请参阅OEP11）的API 调用来提供服务。

接下来，提供商在市场中扮演发布者的角色（或委托该角色）。发布者从模板中选择SEA 并将其包含在服务身份文档中，然后再将其发布到市场中[单击此处了解详细信息]。发布方法包括公共元数据存储（称为Aquarius）、Web API/论坛或点对点消息传递。

服务一旦发布，消费者就可以查看。双方通过签署并执行协议来实施SEA [请参阅此处的详细信息]。

海洋协议发布流程：从资源到服务执行协议。

接下来，我们将探讨各种SEA在运行过程中的几个生命周期。

访问控制基本SEA 使用托管奖励来提供对链下资源的访问控制。有关示例应用程序的详细信息，请参阅本文。以下是SEA的相关活动：

签名和执行：双方同意并创建访问控制SEA的实例。付款：消费者将所需数量的代币锁定在托管中。访问：服务提供商授予对资源的访问权限并在链上报告此活动。奖励：托管要么执行，要么中止，具体取决于访问条件和超时。发布后实施简单的访问控制SEA生命周期。

在链下访问控制场景中，请注意，仅证明某些访问令牌已进行通信，而不是令牌实际上在链接中有效和消耗。

更复杂的服务身份验证用例可以通过向服务添加身份验证活动来扩展上述访问控制[正在进行中，将在下一个版本中发布]。这里，资源提供者向验证者网络提交一个或多个服务证明或证明。

验证者网络的任务是解决有关服务性能的争议（例如Truebit、fitchain、Enigma、Filecoin 等）。在这里，SEA 通过预言机或桥接合约使用查询条件进行链接。因此，SEA将能够简单地链接并解决验证人网络的争议解决结果。

外部验证器网络用于验证服务以证明和桥接争议解决周期。

总而言之，我们为将所有活动置于SEA 生命周期内奠定了坚实的基础。请注意，多个SEA 可以轻松并行执行。链下/侧链资源和授权服务器只需监听SEA 发出的预定义活动。

海洋协议SEA的生命周期，从发布到消费和验证。

结论我们分析了Ocean Protocol服务执行协议及其生命周期。这些协议是可证明来源、争议解决、奖励机制等的基础。它们基本上连接了海洋协议生态系统中的数据服务。

现在您知道海洋中存在SEA，让我们继续探索.