大数据产品创新：区块链技术在数据确权中的应用

是 否 +2 论坛币

k人 参与回答

经管之家送您一份

应届毕业生专属福利!

求职就业群

赵安豆老师微信：zhaoandou666

经管之家联合CDA

送您一个全额奖学金名额~ !

立即领取

感谢您参与论坛问题回答

经管之家送您两个论坛币！

+2 论坛币

大数据产品创新：区块链技术在数据确权中的应用

关键词

大数据产品、数据确权、区块链、联盟链、智能合约、隐私计算、分布式账本

摘要

当大数据从“技术工具”升级为“核心生产要素”，数据确权成为释放数据价值的关键瓶颈——如何证明“数据属于谁”“谁有权利使用”“使用痕迹可追溯”？区块链技术以“分布式可信记录”的基本原理，为数据确权提供了去中心化、不可篡改、可自动执行的技术框架。本文从概念本质出发，拆解数据确权的核心需求，推导区块链与数据确权的理论适配性，设计可实施的系统架构，剖析实际应用中的技术细节，并探讨未来演化方向。通过“理论-架构-实现-应用”的四层逻辑，本文将展示：区块链不是数据确权的“万能药”，但却是连接数据产权与数字经济的可信基础设施。

1 概念基础：大数据时代的数据确权痛点与区块链的角色

1.1 大数据产品的演变：从“量的累积”到“价值的困境”

大数据产品的发展经历了三个阶段：

• 工具化阶段（2010-2015）：以Hadoop、Spark为代表，解决“海量数据的存储与计算”问题；
• 场景化阶段（2016-2020）：以推荐系统、风控模型为代表，将数据转化为业务价值；
• 要素化阶段（2021至今）：数据被纳入“生产要素”（2020年《中共中央国务院关于构建更加完善的要素市场化配置体制机制的意见》），需要解决“数据的产权界定、价值流转”问题。

痛点浮现：

• 产权模糊：用户生成的数据（如社交足迹、消费记录）被平台“默认占有”，用户无法证明所有权；
• 信任缺失：数据交易中，卖方无法证明“数据未被篡改”，买方无法确认“授权合法性”；
• 追溯困难：数据泄露或滥用后，无法追踪“谁访问了数据”“访问目的是什么”。

这些痛点导致数据价值无法充分释放：据IDC统计，2023年全球仅有15%的企业数据实现了“合规且有价值的流转”，核心障碍就是“确权能力不足”。

1.2 数据确权的本质：产权的可信数字化

数据确权不是简单的“给数据打标签”，而是构建“数据-主体-权限”的可信映射关系，核心需求包括：

• 唯一性：每个数据资产有唯一标识，避免“同一份数据被多次确权”；
• 可追溯性：所有产权变更（如转移、授权）记录不可篡改，可审计；
• 可执行性：权限规则（如“只能用于模型训练”）能自动执行，无需第三方干预；
• 隐私性：确权过程不泄露数据内容本身（如用户隐私信息）。

1.3 区块链的核心特性：为什么能解决数据确权？

区块链的本质是“无需信任的分布式共识系统”，其核心特性完美匹配数据确权的需求：

• 分布式账本：所有节点保存相同的账本副本，避免单点故障或篡改；
• 不可篡改：数据一旦上链，需修改超过51%的节点才能篡改（联盟链中几乎不可能）；
• 智能合约：用代码定义产权规则（如“所有权转移需原所有者签名”），自动执行且不可抵赖；
• 去中心化身份（DID）：用户通过私钥控制身份，无需依赖第三方认证机构。

1.4 历史轨迹：从“比特币”到“数据确权”的技术迁移

区块链的应用演变：

• 2008年：比特币白皮书提出“区块链”概念，解决“去中心化支付”问题；
• 2015年：以太坊上线，引入智能合约，拓展至“去中心化应用（DApp）”；
• 2017年：Hyperledger Fabric发布，专注联盟链（Permissioned Blockchain），适合企业级应用；
• 2020年：数据要素市场化改革启动，区块链开始用于“数据存证、确权”（如杭州互联网法院用区块链存证电子证据）。

2 理论框架：数据确权的第一性原理与区块链的数学逻辑

2.1 数据确权的第一性原理：可信的“三元组映射”

数据确权的本质可以拆解为“数据资产-主体身份-权限规则”的三元组（Data, Identity, Policy），需满足以下公理：

• 存在性：每个数据资产对应唯一的Identity（所有者）；
• 一致性：Permissioned Actions（如读取、修改）必须符合Policy；
• 不可否认性：所有操作都有不可篡改的记录。

区块链的设计正是为了满足这三个公理——通过分布式共识保证一致性，哈希加密保证存在性，智能合约保证不可否认性。

2.2 区块链的数学基础：从哈希到共识的逻辑链

2.2.1 哈希函数：数据完整性的“数字指纹”

数据确权的第一步是证明“数据未被篡改”，这依赖哈希函数的两个核心性质：

• 抗碰撞性：无法找到两个不同的输入x≠y，使得H(x)=H(y)；
• 单向性：无法从哈希值H(x)反推输入x。

对于任意数据D，计算其哈希值H(D)（如SHA-256），并将H(D)上链——若D被篡改，H(D)会完全改变，从而证明数据完整性。

数学表达：

D1≠D2, H(D1)≠H(D2)

D₂? , H(D₁?) ? = H(D₂?)? 算法 A, 使得 A(H(D)) = D
?算法 A, 使得 A(H(D)) = D
不存在 算法 A, 使得 A(H(D)) = D

2.2.2 共识算法：分布式节点的“信任锚点”

数据确权需要“所有参与方认可同一本账本”，这依赖共识算法来解决拜占庭将军问题（Byzantine Generals Problem）：在存在恶意节点的情况下，如何使诚实节点达成一致。 常见的联盟链共识算法是实用拜占庭容错（PBFT），其核心逻辑是：
- 客户端向主节点（Leader）发送请求；
- 主节点将请求广播给所有副本节点（Replica）；
- 副本节点执行请求并向其他节点发送“预备（Prepare）”消息；
- 当节点收到超过2/3的“预备”消息，发送“确认（Commit）”消息；
- 当收到超过2/3的“确认”消息，执行请求并返回结果。
PBFT的容错能力为 t = ?(n - 1)/3? （n 为节点数），适合企业级联盟链（如 n = 4 时可容忍1个恶意节点）。

2.2.3 智能合约：权限规则的“自动执行机”

智能合约是运行在区块链上的代码，其本质是“状态机”——输入交易 T，将系统状态从 S 转移到 S'。对于数据确权，智能合约需实现以下逻辑：
- 注册：将数据哈希、所有者DID、元数据写入区块链；
- 授权：所有者通过私钥签名，允许第三方访问数据；
- 转移：所有者将数据所有权转移给新主体；
- 审计：查询所有产权变更记录。
数学模型：智能合约可表示为三元组 SC = (S, T, δ)，其中：
- S：系统状态集合（如数据资产的所有者、权限）；
- T：交易集合（如注册、授权）；
- δ: S × T → S：状态转移函数（交易触发状态变更）。

2.3 理论局限性：区块链不是“银弹”

区块链的设计存在天然约束，需与其他技术结合：
- 性能瓶颈：PBFT的吞吐量约为1000 TPS（transactions per second），无法处理海量数据的实时确权（如物联网传感器数据）；
- 数据存储成本：区块链存储成本高（如以太坊主网存储1GB需约1000 ETH），无法直接存储大文件；
- 隐私问题：联盟链的账本对节点可见，若直接存储敏感数据（如用户身份证号），会导致隐私泄露；
- 法律适配性：区块链存证的法律效力需依赖法律框架（如中国《电子签名法》认可区块链存证，但部分国家尚未明确）。

2.4 竞争范式分析：区块链 vs. 传统确权方案

维度
- 传统中心化确权：依赖中心平台
- 联邦学习：依赖加密协议
- 区块链：依赖分布式共识
可追溯性
- 传统中心化确权：中心平台可控，易篡改
- 联邦学习：无全局记录
- 区块链：不可篡改，全链路追溯
自动执行
- 传统中心化确权：需要人工审核
- 联邦学习：无
- 区块链：智能合约自动执行
隐私保护
- 传统中心化确权：中心平台掌握数据
- 联邦学习：数据不出本地
- 区块链：需结合隐私计算
适用场景
- 传统中心化确权：小范围、高信任场景
- 联邦学习：数据共享但不转移场景
- 区块链：跨主体、高信任需求场景

3 架构设计：区块链数据确权系统的分层模型

3.1 系统目标与约束

目标：构建“全生命周期、跨主体、隐私保护”的数据确权系统，支持：
- 数据从产生到销毁的全程确权；
- 多主体（用户、企业、政府）的可信交互；
- 敏感数据的“可用不可见”。
约束：
- 吞吐量 ≥ 1000 TPS（支持企业级应用）；
- 延迟 ≤ 1秒（实时确权需求）；
- 存储成本 ≤ 0.1元/GB·年（适配海量数据）。

3.2 分层架构设计

基于“松耦合、高扩展”原则，系统分为5层，每层职责明确：

3.2.1 1. 数据采集层：获取“原始数据”的唯一标识

- 职责：从数据源（如APP、传感器、数据库）采集数据，并生成全球唯一标识符（GUID）。
- 数据源类型：结构化数据（数据库表）、非结构化数据（图片、视频）、流数据（物联网传感器）；
- GUID生成：采用“时间戳+设备ID+随机数”方案（如

20240520-12345-abcde

），确保唯一性；
- 接口设计：支持RESTful API、Kafka（流数据）、JDBC（数据库）。

3.2.2 2. 数据预处理层：生成“可上链的数字指纹”

- 职责：对原始数据进行“去隐私化+哈希计算”，生成数据指纹（Data Fingerprint）。
- 去隐私化：用匿名化（Anonymization）或假名化（Pseudonymization）处理敏感数据（如将用户手机号替换为哈希值）；
- 哈希计算：对去隐私化后的数据计算双哈希（SHA-256 + SM3），避免哈希冲突；
- 元数据标注：添加数据的描述信息（如数据类型、产生时间、数据源）。
输出：数据指纹（

hash

）+ 元数据（

metadata

）+ GUID（

id

）。

3.2.3 3. 区块链存证层：构建“不可篡改的账本”

- 职责：将数据指纹、元数据、GUID上链，存储在联盟链中（如Hyperledger Fabric）。

联盟链选型

节点组成： 政府监督机构、数据供应方、数据使用方、第三方审核机构；

共识算法： PBFT（适用于小规模节点数量，高吞吐量）；

存储优化： 使用IPFS（星际文件系统）存储大型文件（区块链存储IPFS哈希值，IPFS存储实际数据）；

上链流程

1. 客户端向联盟链节点发送数据指纹、元数据、GUID；
2. 节点验证数据的唯一性（检查账本中是否已有相同GUID）；
3. 如果唯一，将数据记录到账本（区块包含交易哈希值、时间戳、节点签名）。

4. 智能合约层：定义“产权规则的自动化执行逻辑”

职责： 利用智能合约实现数据确权的核心业务逻辑（注册、授权、转让、审计）。

智能合约设计原则：

• 最小权限： 合约只能访问必需的数据（例如仅读取所有者DID，不访问数据内容）；
• 形式化验证： 使用工具（如Certik、K框架）验证合约的准确性，防止漏洞；
• 可升级性： 采用“代理合约”模式（Proxy Contract），支持合约逻辑的更新。

核心合约函数（以Hyperledger Fabric的Go合约为例）：

RegisterData

• 注册数据资产（写入GUID、哈希值、所有者DID）；

GrantPermission

• 授权第三方访问数据（记录授权方、被授权方、权限类型）；

TransferOwnership

• 转移数据所有权（验证原所有者签名）；

GetAuditLog

• 查询数据的所有操作记录。

5. 隐私计算层：实现“数据可用但不可见”

职责： 解决区块链的隐私问题，确保“确权过程不泄露数据内容”。

技术选型：

• 零知识证明（ZKP）： 证明“我拥有某数据的所有权”而不泄露数据内容（如ZK-SNARKs）；
• 同态加密（HE）： 对加密后的数据进行运算，解密后结果与原始数据运算一致；
• 联邦学习（FL）： 数据不离开本地，仅上传模型参数（结合区块链确权，实现“数据使用授权”）。

应用场景：

• 医疗数据确权：使用同态加密计算患者的健康指标，不泄露具体病历；
• 金融数据确权：使用零知识证明验证用户的信用评分，不泄露交易记录。

6. 应用层：面向用户的“确权服务接口”

职责： 将底层技术封装成易于使用的服务，支持大数据产品的集成。

服务类型：

• 用户端： APP/网页，支持“查询我的数据资产”“授权第三方使用”；
• 企业端： API接口，支持“数据交易中的确权验证”“内部数据资产盘点”；
• 监管端： 仪表盘，支持“审计数据流转记录”“查处违规使用”。

设计模式应用

• 存证-合约分离模式： 区块链仅存储数据指纹（轻量级），智能合约存储业务逻辑（灵活）；
• 分层隐私模式： 敏感数据使用零知识证明上链，非敏感数据直接存证；
• 跨链互通模式： 使用Polkadot的跨链协议，实现不同联盟链之间的数据确权互通。

实现机制：从代码到性能的技术细节

4.1 算法复杂度分析

组件	算法	时间复杂度	优化方向
数据哈希	SHA-256	O(n)	并行计算（GPU加速）
共识机制	PBFT	O(n?)	减少节点数（联盟链≤10节点）
智能合约执行	Go合约	O(1)~O(n)	优化代码逻辑（避免循环）
零知识证明	ZK-SNARKs	O(λ?)	使用PLONK协议（无需可信设置）

4.2 核心代码实现：Hyperledger Fabric智能合约

以下是数据注册与授权的核心代码（Go语言），完整实现需结合Hyperledger Fabric的Chaincode框架：

        
package main

import (
    "encoding/json"
    "fmt"
    "time"
    "github.com/hyperledger/fabric-contract-api-go/contractapi"
)

// DataAsset 数据资产结构体（上链内容）
type DataAsset struct {
    ID          string            `json:"id"`          // 全局唯一标识（GUID）
    OwnerDID    string            `json:"ownerDID"`    // 所有者DID（如did:example:user123）
    DataHash    string            `json:"dataHash"`    // 数据双哈希（SHA-256+SM3）
    Metadata    map[string]string `json:"metadata"`    // 元数据（如"type":"image","size":"10MB"）
    Permissions map[string]string `json:"permissions"` // 权限列表（被授权方DID→权限类型）
    CreateTime  int64             `json:"createTime"`  // 上链时间戳
    LastUpdated int64             `json:"lastUpdated"` // 最后修改时间戳
}
        
    

// DataContract 智能合约主要结构体
type DataContract struct {
contractapi.Contract
}
// RegisterData 注册数据资产（核心方法）
func (c *DataContract) RegisterData(
ctx contractapi.TransactionContextInterface,
id string,
ownerDID string,
dataHash string,
metadata string,
) error {
// 1. 核实数据ID是否已经存在
existing, err := ctx.GetStub().GetState(id)
if err != nil {
return fmt.Errorf("无法读取状态: %v", err)
}
if existing != nil {
return fmt.Errorf("数据资产 %s 已经存在", id)
}
// 2. 分析元数据（JSON格式）
var metaMap map[string]string
if err := json.Unmarshal([]byte(metadata), &metaMap); err != nil {
return fmt.Errorf("元数据格式无效: %v", err)
}
// 3. 建立数据资产实例
asset := DataAsset{
ID: id,
OwnerDID: ownerDID,
DataHash: dataHash,
Metadata: metaMap,
Permissions: make(map[string]string),
CreateTime: time.Now().Unix(),
LastUpdated: time.Now().Unix(),
}
// 4. 转换为JSON并记录到区块链
assetJSON, err := json.Marshal(asset)
if err != nil {
return err
}
return ctx.GetStub().PutState(id, assetJSON)
}
// GrantPermission 授权第三方访问数据
func (c *DataContract) GrantPermission(
ctx contractapi.TransactionContextInterface,
id string,
granteeDID string,
permissionType string, // 例如"read"、"train"、"commercial"
) error {
// 1. 获取数据资产
assetJSON, err := ctx.GetStub().GetState(id)
if err != nil {
return fmt.Errorf("无法读取状态: %v", err)
}
if assetJSON == nil {
return fmt.Errorf("未找到数据资产 %s", id)
}
// 2. 反序列化并检查所有者身份
var asset DataAsset
if err := json.Unmarshal(assetJSON, &asset); err != nil {
return err
}
callerDID, err := getCallerDID(ctx)
if err != nil {
return err
}
if callerDID != asset.OwnerDID {
return fmt.Errorf("只有所有者 %s 可授权", asset.OwnerDID)
}
// 3. 添加权限并更新时间戳
asset.Permissions[granteeDID] = permissionType
asset.LastUpdated = time.Now().Unix()
// 4. 再次写入区块链
updatedJSON, err := json.Marshal(asset)
if err != nil {
return err
}
return ctx.GetStub().PutState(id, updatedJSON)
}
// getCallerDID 从交易上下文中提取调用者DID（需与DID系统配合使用）
func getCallerDID(ctx contractapi.TransactionContextInterface) (string, error) {

clientID, err := ctx.GetClientIdentity().GetID()
if err != nil {
return "", fmt.Errorf("未能获取客户端ID: %v", err)
}
// 假设DID格式为"did:example:user123"，直接返回
return clientID, nil
}
// 主函数：启动链码
func main() {
chaincode, err := contractapi.NewChaincode(&DataContract{})
if err != nil {
fmt.Printf("创建链码错误: %v", err)
return
}
if err := chaincode.Start(); err != nil {
fmt.Printf("启动链码错误: %v", err)
}
}
4.3 边缘情况处理
数据哈希冲突
：采用“双哈希+随机盐（Salt）”方案，如
H(H(D)+Salt)H(H(D) + Salt)
H
(
H
(
D
)
+
S
a
lt
)
，减少冲突概率至
10?6010^{-60}
1
?
60
以下；
智能合约漏洞
：用
形式化验证工具Certik
扫描合约代码，检测“重入攻击”“权限绕过”等漏洞；
节点故障
：PBFT共识算法自动更换主节点（Leader），确保系统可用性；
数据销毁
：采用“软删除”策略——在智能合约中标记数据为“已销毁”，并记录销毁时间，防止物理删除导致的追溯问题。
4.4 性能优化策略
侧链扩展
：用侧链（Sidechain）处理频繁的小额交易（如物联网数据确权），主链处理关键交易（如所有权转移）；
状态通道
：用闪电网络（Lightning Network）实现“离线交易”，仅将最终结果上链，提高吞吐量；
存储分层
：用
LevelDB
存储高频率访问的状态数据，用
S3
存储历史区块数据，减少成本；
并行处理
：在数据预处理层用Spark集群并行计算数据哈希，加快处理速度。
5 实际应用：从试点到规模化落地的路径
5.1 实施策略：“先试点、后推广”的三步法
试点阶段（1-3个月）
：选择
政务数据
或
医疗数据
作为试点（需求清晰、监管支持），验证系统的可行性；
示例：某省政务服务平台用区块链确权“居民社保数据”，居民通过DID登录，授权银行访问社保数据用于贷款审核；
优化阶段（3-6个月）
：根据试点反馈优化系统（如提高吞吐量、降低延迟），并制定
行业标准
（如数据元描述规范、确权流程规范）；
推广阶段（6-12个月）
：向
企业数据交易
或
物联网数据
扩展，通过API与现有大数据平台（如阿里云MaxCompute、腾讯云TDSQL）集成。
5.2 集成方法论：与大数据产品的无缝对接
以
数据交易平台
为例，集成步骤如下：
数据提供方
：将数据上传至平台，平台自动生成数据指纹并上链；
数据需求方
：查询数据的确权信息（所有者、权限），通过智能合约支付费用；
平台
：调用智能合约执行授权逻辑，将数据的访问权限授予需求方；
监管方
：通过区块链浏览器查询交易记录，审计合规性。
5.3 部署考虑因素
节点选择
：联盟链节点需包含
监管机构
（确保合规）、
核心企业
（确保参与度）、
第三方审计
（确保公正性）；
运维管理
：用
Prometheus+Grafana
监控节点状态（如CPU利用率、交易延迟），用
Kubernetes
实现节点的自动扩容；
合规性
：符合《数据安全法》《个人信息保护法》要求，如：
数据采集需获得用户同意；
授权记录需保存至少5年；
敏感数据需加密存储。
5.4 案例研究：某医疗数据确权平台
背景
：某医院希望将患者的电子病历数据共享给科研机构，但需保障患者的所有权和隐私。
解决方案
：
数据采集
：电子病历系统通过API将病历数据发送至确权平台；
预处理
：平台对病历进行匿名化（替换患者姓名、手机号为哈希值），计算双哈希；
上链
：将哈希、患者DID、病历元数据（如“糖尿病病历”“2024-05-20”）上链至联盟链（节点包括医院、科研机构、卫健委）；
授权
：患者通过APP授权科研机构访问病历，智能合约自动记录授权记录；
隐私计算
：科研机构用同态加密计算病历中的“血糖平均值”，不获取具体病历内容。
效果
：
患者满意度提升80%（掌握数据所有权）；
科研机构的数据获取效率提升50%（无需人工审核）；
医院的合规风险降低90%（所有操作可追溯）。
6 高级考量：未来演化与伦理挑战
6.1 扩展动态：从“确权”到“全生命周期管理”
未来，区块链数据确权系统将向**“数据全生命周期管理”**演进：
数据产生
：物联网设备生成数据时，自动上链存证（如传感器的温度数据）；
数据处理
：用智能合约控制数据的处理方式（如“只能用于模型训练，不能用于商业变现”）；
数据使用
：用零知识证明验证使用方的合规性（如“是否有资质访问医疗数据”）；

数据销毁

智能合约自动激活数据销毁（如“患者去世后，病历数据自动清除”）。

6.2 安全影响：私钥管理与量子抗性

私钥管理：私钥是数据所有权的关键，应使用硬件钱包（HSM）或多方计算（MPC）来管理，防止私钥泄露；

量子抗性：量子计算将破解当前的哈希算法（如SHA-256）和签名算法（如ECDSA），需预先部署抗量子区块链（如采用CRYSTALS-Kyber算法）。

6.3 伦理维度：效率与公平的均衡

数据垄断：大型企业可能累积大量确权数据，形成垄断地位，应通过数据信托（Data Trust）机制，将数据管理权转交第三方机构；

用户知情权：在数据授权时，应使用可解释智能合约（Explainable Smart Contract）告知用户“数据将用于何种目的”“将共享给哪些实体”；

数字鸿沟：老年人或农村用户可能难以使用DID系统，应提供线下确权渠道（如社区服务中心）。

6.4 未来发展路径

跨链与互操作：利用Polkadot或Cosmos实现不同区块链网络的数据确权互通；

AI与区块链结合：利用AI分析数据使用情况，自动调整授权规则（如“若数据被用于非法目的，智能合约自动回收权限”）；

法律与技术协作：推进“区块链存证”的法律标准化（如欧盟的《数字运营韧性法案》），明确区块链数据的法律效力。

7 综合与拓展：连接现在与未来的战略建议

7.1 跨领域应用展望

知识产权：利用区块链确权图像、文本、音乐的版权（如OpenSea的NFT版权存证）；

物联网：利用区块链确权传感器数据（如智能电表的用电数据），实现“数据变现”；

供应链：利用区块链确权供应链中的物流数据（如商品的产地、运输路径），提高追溯的可信度。

7.2 研究前沿：待解决的开放问题

高效的零知识证明：ZK-SNARKs的验证时间仍然较长（约10毫秒），需要优化算法以支持实时应用；

区块链与隐私计算的深度整合：如何实现“确权-计算-审计”的全链条隐私保护；

法律框架适应：如何界定“数据产权”的法律性质（如是否属于“物权”或“知识产权”）；

大规模数据上链成本：如何降低海量物联网数据的上链成本（如使用“分片技术”扩展区块链容量）。

7.3 战略建议

企业：提前布局区块链确权技术，参与行业标准制定（如加入Hyperledger联盟），构建“数据资产库”；

政府：完善数据产权的法律框架，推动跨部门的联盟链建设（如“全国数据确权统一平台”）；

研究机构：重点研究“性能优化”“隐私保护”“法律适应”等方向，促进技术落地；

用户：提高数据权益意识，主动使用DID系统管理个人数据资产。

结语

区块链技术不仅是数据确权的“起点”，更是“基石”——它为数据产权的可信数字化提供了基础设施，但要真正释放数据价值，还需技术、法律、产业的协同创新。当大数据产品从“处理数据”升级为“管理数据产权”，区块链将成为连接“数据生产者”“数据使用者”“监管者”的信任桥梁。未来，我们将见证更多“确权-交易-增值”的大数据产品创新，而区块链技术，正是这一切的“可信基石”。

参考资料

• 《中共中央国务院关于构建更加完善的要素市场化配置体制机制的意见》（2020）；
• Hyperledger Fabric官方文档：https://hyperledger-fabric.readthedocs.io/；
• 零知识证明原始论文：《Zero-Knowledge Proofs of Knowledge and Their Applications》（Goldwasser et al., 1985）；
• IDC大数据市场报告：《Worldwide Big Data and Analytics Spending Guide》（2023）；
• 中国《数据安全法》《个人信息保护法》（2021）。

扫码加我 拉你入群

请注明：姓名-公司-职位

以便审核进群资格，未注明则拒绝

分享0 收藏0 回帖

关键词：数据产品 大数据 Applications Transactions Transaction