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

我们之前已经解释了为什么服务水平协议（SLA）可以支持我们所知道的世界。整个物理和数字服务供应链捆绑在一起，以降低交易对手风险并确保其可用性，可靠性和正常运行时间。

在海洋网络中，我们专注于公平交换数据和人工智能服务，以保护商业交易各方。可以提前理解此类服务协议的条款和条件，而无需依赖外部方来解决争议。服务协议及其生命周期基于以下几个方面：

·分散访问控制
·和解纠纷
·可追溯性服务消费

·网络奖励和奖励

服务是先支付还是在服务之后支付？这首先是鸡肉或鸡蛋的问题......

下面，我们将从技术角度深入研究部署在海洋网络中的SEA的概念。

服务执行中的不愉快路径

处理数据服务时可能会发生许多错误。我们已经列出了一些案例，但边缘案例可能有更多案例：

·服务可能不存在，但消费者已经支付了服务费用。
·服务可能已正确送达，但消费者拒绝或忘记退回服务提供商。
·服务提供商可能不授予对合法用户的访问权限或授予对非合法用户的访问权限。
·该服务不符合消费者的功能要求或性能不如预期。
·服务响应或日志在网络或翻译中“丢失”。

服务请求/响应世界中的一些不愉快的路径。

有许多方法可以预防此类灾难。典型的采购部门在提供者和消费者之间建立法律协议。数字服务可以添加和自动化多层数字安全措施（加密，签名，散列，加密和证明）。

分布式服务网络为复制成本增加了一层冗余。随着信任程度的降低，例如在（匿名）公共链的情况下，人们可以探索基础本地令牌的经济和声誉激励。

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

服务在供应链中越关键，确保实施就越严格。像自然灾害这样的早期预警系统需要比罗勒植物的湿度诱导更高的耐受性（可能是这样）。

每个人都有条件

与采购中合法SLA的条款和条件类似，Ocean SEA也有条件将智能合约作为代码嵌入。协议各方必须符合这些条件。

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

三方签约参加服务协议。
在上述场景中，服务提供商愿意提供数据服务，因为消费者确保在服务交付之后进行支付。相反，消费者只会在收到服务时付费，并且验证者将验证服务的性能。验证者（或验证者网络）还将要求在执行任何验证工作之前审查资金。

取决于应用，上述场景可能更复杂或更简单。那么，接下来我们将深入研究SEA的组成。

模块化服务执行协议的剖析

在海洋协议中，SEAA采用模块化设计，以涵盖使用各种Web 2.0（云/内部部署）和Web 3.0服务的灵活性。

服务执行协议的组成部分。

我们解释了SEA的三个主要部分：

服务标识符

加密的ID用于具体标识要使用的服务。出于规模和隐私原因，服务的实际元数据和端点/访问详细信息将保留在链中。这些细节可以以对等方式或在私有或公共链元数据网络中传送。

基于我们对标准和互操作性的鼓励，我们选择采用新兴的W3C分散身份（DID）标准。代理，服务和域名都由海洋协议中的DID处理（例如：“did: op: 12345s3rv1c3”）。包含在其各自的DID文档中的元数据和服务消费信息存储在公共/公共/私有数据中。我们正在开发具有完整性检查，版本控制和不可否认性的海洋标识符标识符。有关更具体的实施信息，请参阅OEP7。

条件和表现

在一个不完美的世界中，我们与连锁，连锁，侧链和其他连锁服务和活动进行贸易。这些服务可以正确执行，几乎正确执行，甚至失败。在某些时候，海洋SEA将愿意了解这些服务的状态以解决争议。

因此，我们介绍条件和实施措施。简而言之，我们正在谈论可以实现的加密和非加密条件。每个条件都有一个验证功能，显示“正确”，“错误”或“未知”。 “未知”值意味着尚未证实该条件已得到满足。所有条件均以“未知”开头。验证逻辑将在链上执行。条件可被视为SEA的输入。

如果条件允许，我们可以灵活地将“服务证书”编码到SEA中。条件是必须解决的挑战，履行是解决方案。奖励逻辑根据履行条件分配输出。这些条件可能是简单的加密挑战（例如，提供用于计算零端哈希值的原始图像，或证明您具有与公钥对应的私钥），以应对更复杂的挑战（例如SN/TARK，计算保证，时间和空间证明，可搜索性证明）和更多主观挑战（如投票或策展方案中的m-of-n签名，承诺/削减等）。

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

奖项根据条件的履行程度颁发。条件是必须解决的挑战，履行是其解决方案（绿色：履行/有效，橙色：未履行/未知，红色：无效）。奖励逻辑基于履行来分配输出。

条件和性能的实际实现是IETF加密条件草案的变体（由Interledger协议启动）。每个条件/性能都是加密质询/认证匹配，例如：
· 哈希/原始：查找计算给定哈希值的原始图像。原始图像的哈希计算发生在链上。这种情况对于缔约方证明他们都了解这一秘密很有用。
· 公钥+消息/签名：使用与公钥对应的私钥对给定消息进行签名。签名的验证发生在链上。适用于验证非对称密钥配对方案中的身份。
·  m-of-n阈值：如果n个条件中的m个已正确满足，则验证为“正确”。适用于多方争议解决，例如投票。
· 查询/解析：链接到公共状态值（使用时间戳记录）并在验证时解析/对比状态值。查询在链上执行，因此它仅限于链状态上下文中的GET操作（例如contractAddress.getValue）。适用于桥接服务和oraclize链值。

多种条件组合可以用更复杂的逻辑表达：

·付款条件：提交给合同的代币数量等于商定的代币价格。
·访问控制：传递给消费者的访问控制秘密。
·验证计算：验证者网络同意并签署该服务已正确交付。

我们预计生态系统中可能存在更多条件，因此可以通过仔细审查和管理将这些条件安全地纳入SEA。我们可以使用管理合同，例如令牌选择列表，权益机器或分散的自治组织（DAO）。

奖励逻辑

SEA的输出是指通常分配给已满足一个或多个条件的代理的奖励。奖励可以在线奖励功能中以支付，版税，许可证，徽章，声誉或彩票的形式发布。可以设想各种奖励机制并将其集成在托管模板中（类似于条件库）。

“海洋议定书”中实施的基本奖励结构是托管或持有代币。在此结构中，令牌被锁定在SEA中以实现：

·如果在超时之前满足所有条件，则执行。执行资金意味着锁定的令牌可以转移给收件人。
·如果超时后未满足所有条件，则中止它们。暂停资金意味着锁定的令牌将返回给发起人。
·在未来的版本中，我们将添加更复杂的奖励计划，如支付流，奖金，竞赛和版税计划。

服务执行协议生命周期

利用SEA的所有组件，用户可以通过SEA开始发布服务并与市场中的消费者进行交互。我们将解释每一步，但让我们先解释一些细节。

服务发布

提供者可以通过定义访问，使用和监视元数据（参见OEP11）（参见OEP8）和API调用来提供服务。

接下来，提供者扮演市场中发布者的角色（或委派角色）。发布者从模板中选择SEA，并在服务标识文档在市场上发布之前将其包含在服务标识文档中。发布方法包括公共元数据存储（名为Aquarius），Web API /论坛或点对点消息传递。

一旦服务发布，消费者就可以查看它。双方通过签署和实施协议来实施SEA。

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

接下来，我们将探讨各种SEAAs的几个生命周期。

门禁控制

基本SEA使用托管奖励为链下的资源提供访问控制。以下是SEA的相关活动：

签名和执行：双方同意并创建访问控制SEA的实例。
付款：消费者在主机中锁定所需的令牌金额。
访问：服务提供商授予对资源的访问权限并在链上报告此活动。
奖励：托管执行或中止，具体取决于访问条件和超时。

发布后实施简单的访问控制SEA生命周期。

在链访问控制方案中，请注意，只传达了某些访问令牌，而且令牌实际上并未在某个段中有效使用。

服务验证

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

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

外部验证者网络用于验证服务以证明并弥合争议解决周期的结果。

总之，

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

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

结论

我们分析了海洋协议服务执行协议及其生命周期。这些协议是证明起源，争议解决和奖励机制的基础。它们基本上连接到海洋协议生态系统中的数据服务。

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