区块链在供应链中的应用:机遇、挑战与设计考量
1. 区块链互操作性方法
区块链互操作性是实现不同区块链之间数据和价值流通的关键。以下是几种常见的互操作性方法:
-
APIs/Gateways
:应用程序编程接口(API)是一段代码,它管理着服务器的访问点以及开发者与数据库、库、软件工具或编程语言交互时必须遵循的规则。API 或网关充当翻译器,将源区块链的请求转换为目标区块链可理解的语言或格式。例如 Hyperledger Cactus,它是一个区块链集成框架,使用验证器网络来验证跨链交易。
-
Hashed/Time locked contracts (HTLCs)
:这些方法使用哈希锁和时间锁来强制双方(通常在不同的区块链系统上)之间的操作原子性。交易者在超时前提供进行交易的加密证明。HTLCs 实现了跨链原子操作或原子交换,例如从比特币到以太坊的有条件支付。其他例子包括比特币闪电网络和 BTC 中继。
-
Pub - Sub Models and Tokens
:发布 - 订阅模型采用发布者和订阅者区块链网络之间的消息交换概念。发布者区块链通常被称为信息源,而订阅者是请求者。消息交换可以通过代币、API 或侧链来完成。
| 互操作性方法 | 特点 | 示例 |
|---|---|---|
| APIs/Gateways | 充当翻译器,转换数据请求 | Hyperledger Cactus |
| HTLCs | 强制操作原子性,实现跨链交换 | 比特币闪电网络 |
| Pub - Sub Models and Tokens | 通过消息交换实现互操作 | 相关系统 |
2. 互操作性方法在供应链中的适用性
不同的互操作性方法在供应链中有不同的适用性:
-
侧链与公证人结合
:对于供应链中的治理和监管合规,侧链与公证人结合的互操作性方法非常重要。公证人联盟可以在定义隐私敏感数据的访问策略方面发挥重要作用。
-
代币化和 Pub - Sub 模型
:最适合集成金融交易与实物资产交换。
-
APIs 和网关
:可以通过翻译数据读写请求来减少基础设施挑战。
-
HTLCs 和智能合约
:虽然在实施方面较为复杂,设计可能无法通用,但这些方法非常适合供应链系统,以根据不同链的法律管辖范围强制执行标准化。
mermaid 流程图:
graph LR
A[供应链需求] --> B[侧链与公证人结合]
A --> C[代币化和 Pub - Sub 模型]
A --> D[APIs 和网关]
A --> E[HTLCs 和智能合约]
B --> F[治理和监管合规]
C --> G[金融与资产交换]
D --> H[减少基础设施挑战]
E --> I[强制执行标准化]
3. 可扩展区块链对供应链的重要性
供应链涉及多个利益相关者,通过交易和智能合约进行通信,导致区块链中产生大量交易。传统区块链由于以下原因存在可扩展性问题,不适合直接应用于供应链:
-
资源消耗
:区块链由所有参与节点分布式管理,传统的分布式管理方法会产生显著的计算、内存和带宽开销,这限制了其可扩展性。计算开销源于资源消耗大的共识算法。此外,新交易或区块生成后,所有参与者都要验证,这涉及验证交易历史,需要存储区块链数据库。由于区块链的不可变性,数据库大小会显著增加。
-
延迟
:在区块链中提交新交易并获得确认存在不可忽视的延迟,包括提交交易的延迟(遵循共识算法)和获得确认的延迟(等待特定数量的区块附加到存储特定交易的区块之后)。而供应链中的交易需要实时结算。
-
效率
:在大多数现有共识算法中,多个验证者同时工作以提交同一个区块,只有第一个遵循共识算法的节点被允许提交区块并获得奖励,其他节点的资源被浪费,限制了区块链效率。
-
吞吐量
:传统区块链的吞吐量有限,而供应链应用由于高交易生成率需要高吞吐量。随着新应用和用户加入系统,交易数量不断增加,需要吞吐量管理算法来确保区块链吞吐量能够适应网络负载。
为了提高区块链的可扩展性,有以下几种方法:
-
离链交易
:参与产品生命周期的节点共同创建一个通道,将与产品相关的所有交易存储在通道中。每个通道只在区块链中提交两笔交易,其余通信在通道内进行,从而减少了需要在区块链中提交的交易数量。
-
分片
:将网络划分为更小的组(分片),每个分片内生成的交易和区块在分片内广播和验证。分片通过限制账本范围来提高区块链的可扩展性,线性提高吞吐量并减少延迟。
-
VeriCom 模型
:引入动态多播和流量路由算法来减少区块链带宽消耗。使用基于 PK 的路由算法,根据目的地的 PK 路由流量。网络中一组高资源节点形成骨干网络,每个骨干节点分配一个特定的路由字符。参与节点根据其 PK 的哈希加入骨干节点以接收发送给它们的交易。骨干节点使用传统的基于 IP 的路由算法在骨干网络中路由流量。与传统区块链不同,VeriCom 将交易多播到随机选择的验证者集合。
-
优化共识算法
:
-
Proof of Elapsed Time (POET)
:英特尔引入的共识算法,依赖英特尔 CPU 中的可信执行环境(TEE)。验证者在提交新块时需要等待 TEE 确定的随机时间段。如果在等待期间收到包含相同交易的块,则放弃该块并开始提交新块。
-
Tree - chain
:一种领导者选择共识算法,在特定时间段内选择一个领导者将具有特定特征的交易提交到区块链。它依赖哈希函数输出在区块链级别和交易级别实现随机化。在区块链级别,共识代码范围(CCR)随机且不可预测地分配给验证者。验证者计算关键权重指标(KWM),根据 KWM 值将节点排序,KWM 值最高的节点分配到第一个 CCR 范围。在交易级别,根据交易内容的哈希随机选择每个交易的验证者。每个验证者创建一个与创世块相连的唯一账本,以确保快速交易结算。
| 可扩展性方法 | 原理 | 优点 |
|---|---|---|
| 离链交易 | 创建通道存储交易 | 减少区块链交易数量 |
| 分片 | 划分网络为分片 | 提高吞吐量,减少延迟 |
| VeriCom 模型 | 动态多播和流量路由 | 减少带宽消耗 |
| POET 共识算法 | 依赖 TEE 等待随机时间 | 优化资源消耗 |
| Tree - chain 共识算法 | 领导者选择和随机化 | 实现快速交易结算 |
4. 设计考量和开放挑战
在将区块链技术应用于供应链时,需要考虑以下设计考量和开放挑战:
-
公共与许可区块链
:
-
公共区块链
:主要依赖社区成员维护的节点。例如比特币和以太坊,任何具有计算能力的社区成员都可以加入网络并参与工作量证明(PoW)共识过程。成功解决加密难题的节点会获得加密货币奖励,奖励来自提交交易的用户。用户提交交易时需要支付交易费用。因此,依赖公共区块链平台的应用必须考虑交易费用。
-
许可区块链
:供应链网络中的利益相关者共享计算节点,以分布式和可信的方式管理和维护区块链。可以使用 Hyperledger Fabric、Tendermint 或定制的以太坊私有版本等平台。这些平台通常采用轻量级共识算法,与计算成本高的 PoW 共识模型不同。用户不需要支付交易费用,运营成本由使用这些区块链的企业承担,成本较低。
| 区块链类型 | 节点维护 | 共识算法 | 交易费用 | 运营成本 |
|---|---|---|---|---|
| 公共区块链 | 社区成员 | PoW | 有 | 较高 |
| 许可区块链 | 供应链利益相关者 | 轻量级 | 无 | 较低 |
- 防止垃圾进垃圾出问题 :区块链技术可以让利益相关者可靠地跟踪和追溯产品,但它无法验证用户提交数据的正确性,这就是垃圾进垃圾出问题。为了确保供应链生态系统的可靠性,利益相关者必须确保区块链账本中的信息准确。解决这个问题需要在区块链之外采取措施,包括使用人类、传感设备、可信第三方(如监管机构和认证实验室)来消除多利益相关者供应链系统中的虚假声明。
- 自动化合规验证 :供应链网络涉及多个司法管辖区的多个利益相关者,每个司法管辖区都有当地政府和监管机构强制执行的法规。传统的供应链应用依赖文书工作和大量人工操作来确保合规。利用区块链技术时,可以通过智能合约自动化合规验证过程。当局可以将监管标准转化为一个或多个智能合约,以加快合规验证过程。但自动化合规验证需要准确的数据,因此必须先解决垃圾进垃圾出问题。
- 缺乏通用数据标准 :当建立涉及多个司法管辖区的多个利益相关者的供应链网络时,每个利益相关者可能遵循当地的自定义数据标准。缺乏通用数据标准会导致互操作性问题,每个利益相关者可能需要为其现有基础设施开发新的扩展,这会阻碍采用。此外,供应链应用可能需要存储媒体文件(如图像和视频)和数字数据,但区块链技术不适合存储大文件。利益相关者可以将数据本地存储并在区块链上存储哈希,或者使用去中心化文件存储(如 IPFS)并在区块链上存储文件指针。因此,供应链应用必须开发和采用通用的、与应用无关的数据标准。
- 隐私问题 :产品信息有助于利益相关者了解供应链的状态,但利益相关者可能需要共享敏感细节,如食品生产商的成分信息和运输公司的位置信息。他们可能不愿意公开分享这些信息,因为这可能会泄露知识产权或其他商业秘密。此外,数据保护法规(如 GDPR、CCPA 和 APA)对数据使用提供了指导。因此,在设计基于区块链的供应链应用时,必须考虑这些法规和利益相关者的隐私担忧。例如,Malik 等人引入了 PrivChain,这是一种基于区块链的解决方案,使用零知识证明和 Pederson 承诺来保护供应链利益相关者的隐私。
- 与遗留 IT 系统缺乏互操作性 :许多供应链组织一直在使用企业系统来管理其供应链流程。这些系统使利益相关者能够共享产品信息、处理支付和生成监管合规的文书工作。将这些遗留系统与基于区块链的供应链连接可能需要进行大量的改造,成本高昂且具有破坏性。因此,基于区块链的供应链应用必须支持遗留和企业系统所使用的协议和服务。
mermaid 流程图:
graph LR
A[设计考量和挑战] --> B[公共与许可区块链选择]
A --> C[防止垃圾进垃圾出问题]
A --> D[自动化合规验证]
A --> E[缺乏通用数据标准]
A --> F[隐私问题]
A --> G[与遗留 IT 系统缺乏互操作性]
B --> H[权衡成本和功能]
C --> I[采用外部验证方法]
D --> J[转化法规为智能合约]
E --> K[开发通用数据标准]
F --> L[使用隐私保护技术]
G --> M[支持遗留系统协议]
综上所述,区块链在供应链中有巨大的应用潜力,但也面临着诸多挑战。在应用区块链技术时,需要综合考虑各种因素,选择合适的互操作性方法和区块链类型,解决数据准确性、合规性、数据标准、隐私和互操作性等问题,以实现供应链的高效、透明和可靠运行。
5. 互操作性方法的深入分析
在前面提到了几种区块链互操作性方法,下面对它们进行更深入的分析。
5.1 APIs/Gateways
APIs 或网关作为区块链之间的翻译器,其操作步骤如下:
1.
接收请求
:从源区块链接收数据读/写请求。
2.
格式转换
:将请求转换为目标区块链可理解的语言或格式。
3.
发送请求
:将转换后的请求发送到目标区块链。
4.
接收响应
:接收目标区块链的响应,并将其转换回源区块链可理解的格式。
5.
返回响应
:将转换后的响应返回给源区块链。
这种方法的优点是可以减少基础设施挑战,使不同区块链之间的数据交互更加顺畅。但缺点是需要对不同区块链的协议有深入的了解,开发和维护成本较高。
5.2 Hashed/Time locked contracts (HTLCs)
HTLCs 的操作步骤如下:
1.
设定条件
:交易双方设定哈希锁和时间锁的条件。
2.
提供证明
:交易者在超时前提供进行交易的加密证明。
3.
验证证明
:另一方验证加密证明是否符合设定的条件。
4.
执行交易
:如果证明通过验证,则执行交易;否则,交易失败。
HTLCs 的优点是可以实现跨链原子操作或原子交换,确保交易的安全性和可靠性。但缺点是实现复杂,设计难以通用,需要对加密算法有深入的了解。
5.3 Pub - Sub Models and Tokens
Pub - Sub 模型的操作步骤如下:
1.
发布信息
:发布者区块链发布信息。
2.
订阅信息
:订阅者区块链订阅感兴趣的信息。
3.
消息交换
:通过代币、API 或侧链进行消息交换。
4.
处理信息
:订阅者区块链处理接收到的信息。
这种方法的优点是可以实现信息的高效交换,提高供应链的透明度和可追溯性。但缺点是需要建立可靠的消息交换机制,确保信息的准确性和及时性。
| 互操作性方法 | 操作步骤 | 优点 | 缺点 |
|---|---|---|---|
| APIs/Gateways | 接收请求、格式转换、发送请求、接收响应、返回响应 | 减少基础设施挑战,数据交互顺畅 | 开发和维护成本高 |
| HTLCs | 设定条件、提供证明、验证证明、执行交易 | 实现跨链原子操作,确保交易安全 | 实现复杂,设计难通用 |
| Pub - Sub Models and Tokens | 发布信息、订阅信息、消息交换、处理信息 | 信息高效交换,提高透明度 | 需要可靠消息交换机制 |
6. 可扩展性方法的实施要点
在提高区块链可扩展性的方法中,每种方法都有其实施要点。
6.1 离链交易
离链交易的实施要点如下:
1.
确定通道成员
:参与产品生命周期的节点共同确定通道成员。
2.
创建通道
:通道成员共同创建通道。
3.
存储交易
:将与产品相关的所有交易存储在通道中。
4.
提交交易
:每个通道只在区块链中提交两笔交易,其余通信在通道内进行。
6.2 分片
分片的实施要点如下:
1.
划分网络
:将网络划分为更小的组(分片)。
2.
分配节点
:将参与节点分配到不同的分片。
3.
广播和验证
:每个分片内生成的交易和区块在分片内广播和验证。
6.3 VeriCom 模型
VeriCom 模型的实施要点如下:
1.
建立骨干网络
:网络中一组高资源节点形成骨干网络。
2.
分配路由字符
:每个骨干节点分配一个特定的路由字符。
3.
加入骨干节点
:参与节点根据其 PK 的哈希加入骨干节点以接收发送给它们的交易。
4.
路由流量
:骨干节点使用传统的基于 IP 的路由算法在骨干网络中路由流量。
5.
多播交易
:将交易多播到随机选择的验证者集合。
6.4 优化共识算法
-
POET 共识算法
- 依赖 TEE :验证者依赖英特尔 CPU 中的可信执行环境(TEE)。
- 等待随机时间 :验证者在提交新块时需要等待 TEE 确定的随机时间段。
- 处理冲突 :如果在等待期间收到包含相同交易的块,则放弃该块并开始提交新块。
-
Tree - chain
- 选择领导者 :在特定时间段内选择一个领导者将具有特定特征的交易提交到区块链。
- 随机化分配 :依赖哈希函数输出在区块链级别和交易级别实现随机化,分配共识代码范围(CCR)和选择交易验证者。
- 创建唯一账本 :每个验证者创建一个与创世块相连的唯一账本,以确保快速交易结算。
mermaid 流程图:
graph LR
A[可扩展性方法] --> B[离链交易]
A --> C[分片]
A --> D[VeriCom 模型]
A --> E[优化共识算法]
B --> F[确定通道成员]
B --> G[创建通道]
B --> H[存储交易]
B --> I[提交交易]
C --> J[划分网络]
C --> K[分配节点]
C --> L[广播验证]
D --> M[建立骨干网络]
D --> N[分配路由字符]
D --> O[加入骨干节点]
D --> P[路由流量]
D --> Q[多播交易]
E --> R[POET 共识算法]
E --> S[Tree - chain]
R --> T[依赖 TEE]
R --> U[等待随机时间]
R --> V[处理冲突]
S --> W[选择领导者]
S --> X[随机化分配]
S --> Y[创建唯一账本]
7. 应对设计挑战的策略
针对前面提到的设计考量和开放挑战,可以采取以下策略来应对。
7.1 公共与许可区块链选择
- 评估成本 :考虑交易费用、运营成本等因素,评估公共区块链和许可区块链的成本。
- 分析需求 :根据供应链的具体需求,分析哪种区块链类型更适合。例如,如果交易频繁且对成本敏感,许可区块链可能更合适;如果需要广泛的参与和去中心化,公共区块链可能更合适。
7.2 防止垃圾进垃圾出问题
- 建立验证机制 :采用人类、传感设备、可信第三方(如监管机构和认证实验室)来验证数据的准确性。
- 加强数据管理 :对数据的采集、传输和存储进行严格管理,确保数据的质量。
7.3 自动化合规验证
- 转化法规 :将监管标准转化为智能合约,实现自动化合规验证。
- 确保数据准确 :解决垃圾进垃圾出问题,确保用于合规验证的数据准确。
7.4 缺乏通用数据标准
- 制定标准 :供应链参与者共同制定通用的数据标准。
- 采用存储方案 :对于大文件,采用将数据本地存储并在区块链上存储哈希,或者使用去中心化文件存储(如 IPFS)并在区块链上存储文件指针的方案。
7.5 隐私问题
- 使用隐私保护技术 :如零知识证明和 Pederson 承诺等技术,保护供应链利益相关者的隐私。
- 遵守法规 :遵守数据保护法规(如 GDPR、CCPA 和 APA)的要求。
7.6 与遗留 IT 系统缺乏互操作性
- 支持协议和服务 :基于区块链的供应链应用支持遗留和企业系统所使用的协议和服务。
- 逐步集成 :采用逐步集成的方式,减少对现有系统的影响。
| 挑战 | 策略 |
|---|---|
| 公共与许可区块链选择 | 评估成本,分析需求 |
| 防止垃圾进垃圾出问题 | 建立验证机制,加强数据管理 |
| 自动化合规验证 | 转化法规,确保数据准确 |
| 缺乏通用数据标准 | 制定标准,采用存储方案 |
| 隐私问题 | 使用隐私保护技术,遵守法规 |
| 与遗留 IT 系统缺乏互操作性 | 支持协议和服务,逐步集成 |
总之,区块链在供应链中的应用前景广阔,但要实现其潜力,需要深入理解各种互操作性方法和可扩展性技术,同时积极应对设计挑战。通过合理选择区块链类型、解决数据和隐私问题以及实现与现有系统的互操作性,可以构建一个高效、透明和可靠的供应链区块链生态系统。
超级会员免费看
14

被折叠的 条评论
为什么被折叠?



