区块链应用第1讲：基于区块链的智慧货运平台

最新推荐文章于 2025-01-13 15:25:55 发布

程序员 jet_qi

最新推荐文章于 2025-01-13 15:25:55 发布

阅读量1.7k

点赞数 25

CC 4.0 BY-SA版权

分类专栏：区块链技术详解与实战文章标签：区块链智能合约货运平台可验性证明数字身份 DID VC

本文链接：https://blog.youkuaiyun.com/qq_28959087/article/details/143617863

基于区块链的智慧货运平台

网络货运平台已经比较成熟，提供了给货源方提供找司机的交易匹配方案；其中包含这几个角色：货主、承运人(司机、车队长)、监管机构、平台。司机要想接单，依赖于多个中心化的第三方平台，且三方平台数据互不通，造成了如下几个问题。用户身份重复上传，承运人需要在各个货运平台注册，上传相同的身份证、驾驶证、行驶证、道路运输证信息；运单信息人为瞒报误报，如何保证监管数据的准确性，减少人为瞒报误报；资金风险，如何保证资金管理公开透明，防止平台卷款跑路，随着货运平台的发展，以上问题亟待解决，以保障行业健康发展。

文章目录

基于区块链的智慧货运平台

1、背景

网络货运平台已经比较成熟，提供了给货源方提供找司机的交易匹配方案；其中包含这几个角色：货主、承运人(司机、车队长)、监管机构、平台。

其主要流程大体如下：

1、司机入驻平台，需要上传身份证，驾驶员信息，车辆信息；
2、接下来货主在平台发布货源，然后司机进行抢单或者接单或者转让运单，货主也对这笔运单进行调价处理；
3、在完成运单后，需要上报信息给平台，然后货主将应付款项支付给司机，且资金流水需要上报给平台，并将佣金支付给平台；
4、监管机构需监管运单整体生命周期，读取驾驶员信息，车辆信息，订单信息和流水信息。

司机要想接单，依赖于多个中心化的第三方平台，且三方平台数据互不通，造成了如下几个问题。

1、用户身份重复上传，承运人需要在各个货运平台注册，上传相同的身份证、驾驶证、行驶证、道路运输证信息；
2、运单信息人为瞒报误报，如何保证监管数据的准确性，减少人为瞒报误报；
瞒报：人/车信息不匹配

误报：司机各类证书已过期，但是还能在平台接单
3、资金风险，如何保证资金管理公开透明，防止平台卷款跑路

随着货运平台的发展，以上问题亟待解决，以保障行业健康发展。

2、解决方案

为了满足上述需求，通过区块链技术打造一个智慧货运平台，通过智能合约将资金管理权利合理分配，实现司机信息可信认证，并保证运单数据可溯源，防篡改，可信上链，提高信息监管的效率和安全性，减少欺诈和错误。

对于用户重复注册和校验问题，由数字身份合约解决；

使用DID+VC 实现去中心化验证
对于运单信息人为瞒报误报问题，运单的可信上链由运单合约完成；

减少或消除中介机构的业务场景，打造去中心化的市场
对于资金风险问题，平台只有审核权限，司机的运费由监管机构托管，平台只能收取佣金，由钱包合约完成
原来我们完成支付需要对接易宝、支付宝、微信、或者直接对接银行，现在通过区块链完成交易

3、数字身份简介

原来：中心化身份： 由单一的权威机构进行管理和控制的，现在互联网上的大多数身份还是中心化身份。

现在：以用户为中心的身份： 重点集中在去中心化上，通过授权和许可进行身份数据的共享，例如OpenID。

数字身份标识-DID(去中心化身份标识)

DID标识

去中心化：使用分布式储存技术

身份标识：在分布式系统中为用户身份生成唯一的编号

Identifier 一般为用户地址

DID文档

保存了与DID验证相关的密钥信息和验证方法

{
   
   
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ]
  "id": "did:example:123456789abcdefghi",
  // 里面是个数组，对应多个公钥
  "authentication": [{
   
   
    "id": "did:example:123456789abcdefghi#keys-1",
    "type": "Ed25519VerificationKey2020",
    "controller": "did:example:123456789abcdefghi",
    "publicKeyMultibase": "zH3C2AVvLMv6gmMNam3uVAjZpfkcJCwDwnZn6z3wXmqPV"
  }]
  ......
}

可验证声明（VC DID的生态技术主要包含3大角色和3大要素）

可验证声明(Verifiable Credential)提供了一种规范来描述实体所具有的某些属性，实现基于证据的信任。DID持有者，可以通过可验证声明，向其他实体(个人、组织、具体事物等)证明自己的某些属性是可信的。

在DID生态体系内，主要有用户、发行方、使用方三种角色。

发行方（Issuer 监管）： 可发行数字凭证的人/组织。例如：高校可为某个学生颁发数字毕业证，那么这个高校便是一个发证方，公安局给居民颁发身份证，交通运输局给承认人颁发驾驶证、行驶证。
- 身份证(公安局) 驾驶证和行驶证(交管部门)
用户（User 也称为holder 承运人）： 拥有链上数字身份的任何人/组织/实物。任何实体对象都可通过开发者的项目去创建、管理自己的DID。
- 拥有凭证并将其存储在数字钱包中的人
验证方（Verifier 货主）： 也称为业务方，指使用数字凭证的人/组织，验证方在经用户授权后，可对用户的身份或其数字凭证进行验证。例如：企业录取某个人的时候，要对其高校毕业证进行验证，那么这个企业便是一个验证方。
- 验证或鉴别证书的个人或组织，通过扫描二维码来启动验证过程

可验证证书3大要素：

Credential Metadata（证书元数据）： 由w3c定义的JSON-LD规范它可能由颁发者以加密方式签名，并包含证书标识符以及有关证书本身的属性，如到期日期和颁发者。
claims（声明）：对证书主题（如某人的员工编号和职务）提出的一组不可篡改的声明。
proof(s)（证明）：允许人们以密码学方式验证：
- 数据来源（如发行人是谁）
- 数据没有被篡改

// 一个简单的VC示例（JSON-LD格式）返回数据如下：
{
   
   
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "type": ["VerifiableCredential", "AlumniCredential"],
  "id": "http://example.edu/credentials/1872",
  "issuer": "https://example.edu/issuers/565049",
  "issuanceDate": "2010-01-01T19:23:24Z",
  "expirationDate":"2010-01-01T19:23:24Z",
  "credentialSubject": {
   
   
    "id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
    "alumniOf": {
   
   
      "id": "did:example:c276e12ec21ebfeb1f712ebc6f1",
      "name": [{
   
   
        "value": "Example University",
        "lang": "en"
      }, {
   
   
        "value": "Exemple d'Université",
        "lang": "fr"
      }]
    }
  },
  "proof": {
   
   
    "type": "RsaSignature2018",
    "created": "2017-06-18T21:19:10Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "https://example.edu/issuers/565049#key-1",
    "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
      sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
      X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
      PAYuNzVBAh4vGHSrQyHUdBBPM"
  }
}

JSON-LD文档

特点：是一个从未更新的静态文档，因此可以在客户端下载和缓存

作用：用于验证声明的主题属性在JSON-LD中是否存在，而且主题属性只能小于等于JSON-LD定义的属性范围

{
   
   
    "@context": {
   
   
        "Carrier": {
   
   
            "@id": "https://schema.affinidi.io/TCarrierV1R0.jsonld",
            "@context": {
   
   
                "@version": 1.1,
                "@protected": true
            }
        },
        "name": {
   
   
            "@id": "schema-id:name",
            "@type": "https://schema.org/Text"
        },
        "plateNo": {
   
   
            "@id": "schema-id:plateNo",
            "@type": "https://schema.org/Text"
        },
        "plateColor": {
   
   
            "@id": "schema-id:plateColor",
            "@type": "https://schema.org/Text"
        },
        "vehicleType": {
   
   
            "@id": "schema-id:vehicleType",
            "@type": "https://schema.org/Text"
        },
        "owner": {
   
   
            "@id": "schema-id:owner",
            "@type": "https://schema.org/Text"
        },
        "registerDate": {
   
   
            "@id": "schema-id:registerDate",
            "@type": "https://schema.org/Date"
        }
    }
}

问题1：哪些场景会导致VC创建或校验失败？

发行VC失败

1、用于可验证证明的属性不在JsonLd定义的范围内

2、jsonld无法下载

3、凭证类型为空

4、发行方秘钥信息没有对应

5、发行时间小于当前时间，或者超期时间小于当前时间

校验VC失败

1、用于可验证证明的属性不在JsonLd定义的范围内

2、凭证属性值被修改

3、超过了认证的有效期

问题2：如果相同用户相同属性多次创建可验性证明，那么得到的证书信息都能被验证吗？

经过代码验证，生成的jws不同，但是都可以用于身份验证

4、智慧货运平台功能点

4.1、参与方

货主：发布运单的个人或组织
承运人(司机、车队长)：提供运力的个人或组织
监管机构：具有一定公信力的机构，如：交通运输部-协会
货运平台：负责审批司机身份，提供交易匹配能力，审批运单状态(发布、调价、完结) 的机构

4.2、流程图

4.3、表结构设计

# 账户表，主要用来记录秘钥信息，角色信息，账户余额，数字身份信息 目前共5条数据，两承运人，一个货主，一平台，一个监管机构
CREATE TABLE `account` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
  `name` varchar(16) NOT NULL COMMENT '账户名',
  `private_key` varchar(64) NOT NULL COMMENT '私钥',
  `public_key` varchar(256) NOT NULL COMMENT '公钥',
  `did` varchar(64) NOT NULL COMMENT 'did合约地址',
  `role` tinyint(4) DEFAULT NULL COMMENT '1-承运人 2-货主 3-平台 4-监管',
  `account_no` varchar(64) NOT NULL COMMENT '账户编号',
  `balance` bigint(20) NOT NULL DEFAULT '0' COMMENT '余额',
  `ext_info` json DEFAULT NULL COMMENT '账户扩展信息',
  `vc_info` mediumtext COMMENT '数字身份信息',
  `is_deleted` tinyint(1) unsigned NOT NULL DEFAULT '0' COMMENT '0-正常 1-删除',
  `create_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
  `update_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_account_no` (`account_no`)
) ENGINE=InnoDB AUTO_INCREMENT=12 DEFAULT CHARSET=utf8 COMMENT='账户表'

# 账户流水表 采用双边记账法，记录充值，支付，提现流水，记录动账金额和余额，账户from to信息
CREATE TABLE `account_flow` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT COMMENT 'id',
  `flow_no` varchar(64) NOT NULL COMMENT '记录唯一编号',
  `account_no` varchar(64) NOT NULL COMMENT