DePIN中如何构造和验证PoPW

<!--StartFragment-->

如上篇《构建DePIN项目需要考虑的问题》所述，DePIN项目的信任基础是能够验证DePIN设备真实地完成了其工作，且对其工作量进行衡量。我们一般通过在DePIN设备内产生一个真实工作的证明，并对该证明进行可信验证的方式完成该工作。这个真实工作的证明称为PoPW(Proof of Physical Work)。本篇中我们将探讨如何产生及验证PoPW。

我们称DePIN设备为DU(DePIN Unit)，它可能是一个智能电表，一个太阳能电池板，或者一个充电桩等。它进行的工作内容多种多样，在其工作过程中会产生能证明其工作的数据，如太阳能电池板的发电数据等，我们称这个数据为PW(Physical Work）。我们的目标是能对PW生成可信的PoPW证明，并验证它。

PW产生于DU内部，因此最简单的方式就是证明PW数据在DU内生成后，没有经过任何额外加工，直接对PW使用私钥签名生成PoPW；同时还需要证明PW不是在没有DU的情况下凭空捏造出来的。如何才能做到这一点呢？一般来说有如下几种方式：

1. IoT设备内一般都包含通讯模组，通讯模组中一般会包含安全执行环境，如TEE。安全执行环境中可以安全地生成，保存私钥，并进行数字签名等密码学运算。安全执行环境可保障任何人都无法读出私钥，包括项目方。\ 项目方可以在生产DU时在安全执行环境内生成非对称密钥对（公私钥），并取出公钥，将公钥在区块链上注册为DID（此工作也可由IoT芯片生产商等完成）。\ DU生成的PW数据可以被发送至安全执行环境，由其内保存的私钥签名后，签名数据即为PoPW。可将此PoPW发送至Oracle等验证服务，通过链上注册的设备DID查询到该设备的公钥，验证签名的正确性。\ 该方案原理简单，安全性可信度都非常高，但对IoT设备采用的通信模组有一定要求。

2. 市场上有很多IoT平台，以及云服务厂商等提供数据存储加工服务。对于无法使用方案1的DU，可考虑将DU生成的PW数据发送至这些平台后，由平台做信用背书，PW经平台私钥签名后，成为PoPW。\ 该方案要求PW数据不会在DU侧被修改，且送至平台的原始数据被平台签名作为信任来源。因此需额外信任项目方和平台不会作恶，安全性略低于方案1，但适用范围更广。很多市场上已有的设备仅需简单进行签名处理后即可使用。

另外还有种生成PoPW的方式，即通过区块链生成有时限的可信挑战，如每小时都在变化的随机数。该挑战会被下发至每台矿机，矿机需要在其有效时间内，结合自身的IoT工作数据完成挑战，并将其生成PoPW，发回DePIN网络。DePIN网络根据挑战来验证IoT设备的工作是否真实有效。该方案无需对IoT设备芯片生产商或IoT平台等产生信任和依赖。但如何设计完善可信的挑战机制是件有挑战的工作，而完成挑战也许需要额外消耗IoT设备的计算能力和资源等，对设备硬件有较高要求。本篇中不讨论此类方案。

PoPW生成并从设备发出后，需要被可信地验证，才能作为发放奖励的依据。由于DU设备一般数量巨大，PoPW数据量也会很大，因此在区块链上验证PoPW是不现实不经济的，一般通过Oracle完成PoPW的验证。TLay中使用BoAT3 Oracle完成该工作。BoAT3 Oracle收到PoPW后，根据其DU id从链上DID合约中读取该DU的公钥，使用公钥验证PoPW的签名，即可确认PoPW的真实性。

BoAT3 Oracle验证PoPW真实后，会将PoPW原始数据存储到去中心化存储系统（如Filecoin，Arweave等），并将数据获取方式和数据承诺写到链上，因此任何人都可以自行获取PoPW和DID并验证所有数据。验证后的PW数据会被BoAT3 Oracle发送至DePIN项目方Connector程序（运行于BoAT3 Oracle的可信环境内，由DePIN项目方编写的数据处理程序），由Connector程序完成奖励发放等工作。

PoPW的生成，验证和使用的全流程如下：

\

其中蓝色线条代表PoPW从DU中生成后，经过Wallet签名，被传输至BoAT3 Oracle内验证。绿色线条代表被验证后的PW数据被传输至DApp Connector内处理后，根据处理结果将结果发送至链上合约中（如奖励分配）。红色线条代表非PoPW数据可能被直接发送至DApp处理。

根据可信密钥存储于DU内的安全执行环境内，还是网关内，或IoT平台内等，其具有不同的安全模型，如下图所示。对于可信密钥存储于DU内的安全执行环境的情况，BoAT3 Oracle已经适配了大量IoT设备通信模组。DePIN项目方可直接基于这些适配后的模组开发DU。

BoAT3 Oracle是去中心化的，任何人或组织在抵押足够资产后都可以运行Oracle。DU可以选择任意一个Oracle来验证自己的PoPW，因此DU不会遇到“审查攻击”，除非所有BoAT3 Oracle都是恶意的。但即使BoAT3 Oracle是恶意的，它也无法伪造PoPW，因为它无法控制密钥的生成，DID写入过程。如果BoAT3 Oracle作恶，提供错误的PW数据来误导奖励分发过程，是非常容易被发现的。被证明作恶的BoAT3 Oracle抵押的资产会被罚没，并用于奖励举报者。

对想要开发DePIN项目的开发者来说，基于BoAT3 Oracle对PoPW的处理模型，他一般需要完成如下工作：

1. 如上面信任拓扑图，选择合适的信任锚点位置，确定信任模型。

2. 使用SDK完成PoPW的生成，传输流程。

3. 开发BoAT3 Oracle内的Connector程序，完成对PW的处理和奖励发放策略等。

4. 开发完成链上合约，完成链上奖励发放。

作为信任流程的闭环，还有一件事情需要考虑：密钥是如何安全地写入通信模组的？这一般有两种方式：

1. 在芯片生产和初始化阶段，由生产商直接操作安全容器，完成密钥对的生成，并读出公钥，将公钥数据提供给购买方，即DePIN项目方。

2. 通过去中心化TSM（Trusted Service Manager）系统进行空中初始化。TLay会构建去中心化TSM服务网络，通过去中心化方式和密码学算法，配合通用的芯片内安全容器接口，完成密钥对的初始化过程，并读出公钥，直接写入DID合约。

方案一是业界成熟方案，成本低，适合一次性大批量初始化芯片，可作为通用产品使用。可以一次性批量生产大量芯片后，向多个不同DePIN项目方供应该芯片。并由芯片生产方或可信第三方批量在链上初始化DID数据。

方案二更加灵活，可在任意阶段通过无线网络和去中心化TSM网络完成对芯片内密钥对的初始化。由于密钥种子来自多个去中心化参与方，因此只要去中心化TSM网络中有一个诚实参与方，整个流程就是安全可信的，没有任何参与方可以解码出芯片内的私钥。

<!--EndFragment-->