探索SEAs：服务执行协议！

此文意在扩展补充Ocean Protocol的技术架构，因此我们将深入探讨服务执行协议（SEAs）。SEAs将Ocean Protocol Network中的服务提供商、消费者和验证者紧密结合在一起。

以前我们解释过服务等级协议（SLAs）几乎能够支撑着我们所知世界的原因。整个物理和数字服务供应链通过合约绑定在一起，以减少交易对手风险并确保其可用性、可靠性和正常运行时间。

在Ocean Network中我们注重数据和人工智能服务的公平交换，以保护商业交易的各方。这样服务协议的条款和条件便可以提前了解，而无需依赖外部来进行纠纷调解。服务协议及其生命周期基于以下方面：

· 去中心化的访问控制

· 解决纠纷

· 溯源服务消费

· 网络奖励和激励机制

先付费后服务还是先服务后付费？这是一个先有鸡还是先有蛋的问题…

下面，我们将从技术性的角度深入探讨部署在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生态系统中的数据服务。

—-

编译者/作者：开往春天的火车

玩币族申明：玩币族作为开放的资讯翻译/分享平台，所提供的所有资讯仅代表作者个人观点，与玩币族平台立场无关，且不构成任何投资理财建议。文章版权归原作者所有。