CN111433799B - 基于区块链的可信保函 - Google Patents

基于区块链的可信保函 Download PDF

Info

Publication number
CN111433799B
CN111433799B CN202080000560.0A CN202080000560A CN111433799B CN 111433799 B CN111433799 B CN 111433799B CN 202080000560 A CN202080000560 A CN 202080000560A CN 111433799 B CN111433799 B CN 111433799B
Authority
CN
China
Prior art keywords
insurance
beneficiary
blockchain
bank
guarantor
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN202080000560.0A
Other languages
English (en)
Other versions
CN111433799A (zh
Inventor
陆旭明
周徽
叶国俊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Ant Blockchain Technology Shanghai Co Ltd
Original Assignee
Alipay Hangzhou Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alipay Hangzhou Information Technology Co Ltd filed Critical Alipay Hangzhou Information Technology Co Ltd
Publication of CN111433799A publication Critical patent/CN111433799A/zh
Application granted granted Critical
Publication of CN111433799B publication Critical patent/CN111433799B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0609—Buyer or seller confidence or verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • G06Q30/0601—Electronic shopping [e-shopping]
    • G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
    • G06Q30/0635—Processing of requisition or of purchase orders
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0435—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply symmetric encryption, i.e. same key used for encryption and decryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/008—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols involving homomorphic encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3218—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using proof of knowledge, e.g. Fiat-Shamir, GQ, Schnorr, ornon-interactive zero-knowledge proofs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/06—Buying, selling or leasing transactions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • General Health & Medical Sciences (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Databases & Information Systems (AREA)
  • Medical Informatics (AREA)
  • Computing Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Tourism & Hospitality (AREA)
  • Power Engineering (AREA)
  • Technology Law (AREA)
  • Human Resources & Organizations (AREA)
  • Primary Health Care (AREA)

Abstract

本文公开了处理基于区块链的保函信息的方法、系统和装置，包括编码在计算机存储介质上的计算机程序。方法之一包括：接收指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明(ZKP)；验证一个或多个零知识证明；在成功验证了一个或多个零知识证明后，基于执行共识算法将密文存储到区块链中；从与受益人或受益人的代表相关联的第一计算设备接收第一消息，该第一消息指示没有针对保函的未支付索款；向与担保人相关联的第二计算设备发送第二消息，以确认担保人被解除保函下的付款义务；从与担保人相关联的第二计算设备接收第三消息，该第三消息请求将保函的状态更改为已到期；以及更新存储在区块链中的保函的状态，以指示保函已到期。

Description

基于区块链的可信保函
技术领域
本文涉及提供基于区块链技术的可信保函。
背景技术
分布式账本系统(DLS)，也可以被称为共识网络和/或区块链网络，使得参与的实体能够安全地并且不可篡改地存储数据。在不引用任何特定用例的情况下，DLS通常被称为区块链网络。区块链网络的类型的示例可以包括公有区块链网络、私有区块链网络和联盟区块链网络。联盟区块链网络针对选择的实体组群提供，该实体组群控制共识处理，并且联盟区块链网络包括访问控制层。
数字网络已使世界各地的人们能够方便有效地找到信息并互动。例如，社交媒体平台使人们可以轻松地与朋友和同事分享消息、照片和视频。在线购物网站允许消费者轻松地找到有关各种产品的信息，并通过电子方式发送付款以从世界各地的企业采购产品。新闻网站为用户提供有关世界各地发生的事件的最新信息。媒体平台为用户提供了大量音乐和电影，供用户下载或在线流播。用户可以在线使用各种金融服务，并且可以更轻松地进行国际交易。叫车平台使搭车者可以用移动电话轻松找到交通工具并为此付款。随着越来越多的人使用互联网，更多的交易以数字方式进行，欺诈性在线活动和各方之间的纠纷的数量也增加了。
传统的安全消息传送网络(如SWIFT)通常支持点对点消息。这类消息的语法专为所涉及的双方而设计，以确保数据安全和隐私。但是，由于不同的国际技术或金融法规，消息可能在到达最终目的地之前先经过多个节点，这使它们耗时、昂贵且缺乏透明度。当涉及两个以上的参与方时，在点对点的基础结构下，多方之间的消息路由效率变得更低。
期望一种可以提供透明、不可变且可验证的消息传送记录，同时确保所涉及的各方的数据隐私的统一平台。
发明内容
所描述的主题的实施例可以单独或组合地包括一个或多个特征。
例如，在一个实施例中，一种计算机实现的由与至少一个担保人相关联的计算系统执行的用于处理待存储在区块链上的保函信息的方法，所述方法包括：从与申请人相关联的计算设备接收由至少第一担保人向受益人作出的保函的申请，其中，该申请包括与申请人的身份、受益人的身份以及执行保函的一个或多个预定条件相关联的信息；基于包括在申请中的信息生成保函的数字版本；对该数字版本进行加密以生成保函的密文；生成与关联于保函的一个或多个值有关的一个或多个零知识证明(ZKP)；向区块链网络发送保函的密文以及一个或多个零知识证明，以将保函的密文存储在区块链上，其中，保函的密文是在一个或多个零知识证明被区块链网络中的区块链节点成功验证之后通过区块链节点的共识被存储在区块链上的。
在另一实施例中，一种计算机实现的由区块链网络中的区块链节点执行的方法包括：接收来自与第一担保人相关联的第一计算设备的指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证一个或多个零知识证明是正确的；在验证了一个或多个零知识证明是正确的之后，基于执行共识算法将密文存储到区块链中；从与受益人或受益人的代表相关联的第二计算设备接收第一消息，该第一消息包括受益人对保函的接受；以及更新保函的状态以指示受益人已接受保函。
在另一实施例中，一种计算机实现的由区块链网络中的区块链节点执行的方法包括：接收指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证一个或多个零知识证明；在成功验证了一个或多个零知识证明后，基于执行共识算法将密文存储到区块链中；从与受益人或受益人的代表相关联的第一计算设备接收针对保函的提款请求；基于执行共识算法将提款请求存储到区块链中；将关于提款请求的第一消息传递给与第一担保人相关联的第二计算设备；从与第一担保人相关联的第二计算设备接收第二消息，该第二消息指示第一担保人同意根据保函向受益人付款；更新存储在区块链中的保函的状态，以指示第一担保人已处理了针对保函的提款请求；将第三消息传递到与受益人或受益人的代表相关联的第一计算设备，该第三消息指示第一担保人同意根据保函向受益人付款；从与受益人或受益人的代表相关联的第一计算设备接收第四消息，该第四消息指示受益人已接收到来自第一担保人的付款；以及更新存储在区块链中的保函的状态，以指示受益人已接收到针对保函的付款。
在另一实施例中，一种计算机实现的由区块链网络中的区块链节点执行的方法包括：接收指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证一个或多个零知识证明；在成功验证了一个或多个零知识证明后，基于执行共识算法将密文存储到区块链中；从与受益人或受益人的代表相关联的第一计算设备接收第一消息，该第一消息指示没有针对保函的未支付索款；向与第一担保人相关联的第二计算设备发送第二消息，以确认第一担保人被解除保函下的付款义务；从与第一担保人相关联的第二计算设备接收第三消息，该第三消息请求将保函的状态更改为已到期；以及更新存储在区块链中的保函的状态以指示保函已到期。
在另一实施例中，一种计算机实现的由区块链网络中的区块链节点执行的方法包括：接收来自与至少第一担保人相关联的第一计算设备的指定保函的第一数字文档的第一密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证一个或多个零知识证明是正确的；在验证了一个或多个零知识证明是正确的之后，基于执行共识算法将第一密文存储到区块链中；从与受益人或受益人的代表相关联的第二计算设备接收第一消息，该第一消息包括修改保函的请求；向第一计算设备发送与用以修改保函的请求有关的第二消息；以及从第一计算设备接收指定保函的第二数字文档的第二密文，该第二数字文档表示第一数字文档的修改版本，其中，所述修改是基于所述请求进行的。
在另一实施例中，一种计算机实现的由区块链网络中的区块链节点执行的方法包括：接收来自与至少第一担保人相关联的第一计算设备的指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证一个或多个零知识证明是正确的；在验证了一个或多个零知识证明是正确的之后，基于执行共识算法将密文存储到区块链中；从与至少第一担保人相关联的第一计算设备接收第一消息，该第一消息包括用以撤销保函的请求；将用以撤销保函的请求存储在区块链中；向与受益人或受益人的代表相关联的第二计算设备发送第二消息，其中第二消息包括用以撤销保函的请求；从与受益人或受益人的代表相关联的第二计算设备接收第三消息，其中，第三消息包括受益人接受撤销保函的确认；以及更新存储在区块链中的保函的状态，以指示保函已经撤销。
在另一实施例中，一种计算机实现的由区块链网络中的区块链节点执行的方法包括：通过第一区块链网络中的区块链节点接收用于将数字文档的密文中继到第二区块链网络的跨链请求，其中，该跨链请求是从与第一担保人相关联的第一计算设备发送的，该数字文档指定来自第一担保人的保函和执行保函的一个或多个预定条件，并且保函是第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；基于执行共识算法将跨链请求和密文存储到与第一区块链网络相关联的第一区块链中；从第二计算设备接收用于在第一区块链网络和第二区块链网络之间中继信息的消息，该消息包括保函被受益人接受并被存储在与第二区块链网络相关联的第二区块链上的确认；以及更新保函的状态，以指示保函在第一区块链上已无效。
在一些实施例中，这些一般和特定方面可以使用系统、方法或计算机程序或者系统、方法和计算机程序的任何组合来实现。前述和其他描述的实施例可以各自可选地包括一个或多个以下方面：
在一些实施例中，保函的形式为备用信用证(SBLC)。在一些实施例中，保函指定当满足执行保函的一个或多个预定条件时，担保人应向受益人支付预定金额。
在一些实施例中，担保人是为申请人提供服务的离岸银行，并且该预定金额是在满足一个或多个预定条件时通过为受益人提供服务的在岸银行向受益人支付的。
在一些实施例中，该申请还包括指定在岸银行的身份的信息。
在一些实施例中，该申请还包括证明申请人在违约SBLC的情况下具有能力支付预定金额的信息。
在一些实施例中，申请人的身份包括申请人的姓名、地址、电话号码、电子邮件地址和业务类型中的一个或多个。
在一些实施例中，受益人的身份包括受益人的姓名、地址、电话号码、电子邮件地址和业务类型中的一个或多个。
在一些实施例中，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。
在一些实施例中，一个或多个零知识证明中的至少一个是基于同态加密生成的。
在一些实施例中，一个或多个零知识证明包括范围证明和/或零测试。
在一些实施例中，用于对数字版本进行加密的加密密钥是基于线性秘密共享方案来导出的。
保函是由第一担保人和第二担保人向受益人作出的，保函的形式为SBLC，并且保函指定在满足执行保函的一个或多个预定条件时，第一担保人和第二担保人应向受益人支付预定金额。
在一些实施例中，第一担保人是为申请人提供服务的第一银行，第二担保人是为申请人提供服务的第二银行，并且该申请还包括证明在申请人违约SBLC的情况下，申请人在第一银行和第二银行中具有足够资金用于支付预定金额的信息。
应当理解的是，根据本文的方法可包括本文描述的方面和特征的任何组合。也就是说，根据本文的方法不限于本文具体描述的方面和特征的组合，还包括所提供的方面和特征的任何组合。
在附图和以下描述中阐述了本文的一个或多个实施例的细节。根据说明书和附图以及权利要求，本文的其他特征和优点将显现。
附图说明
图1是示出可用于执行本文的实施例的环境的示例的示图。
图2是示出根据本文的实施例的架构的示例的示图。
图3是示出了根据本文实施例的区块链网络的示例的示图。
图4是示出根据本文实施例的在担保人的内部系统和区块链网络之间的消息流的示例的流程图。
图5是根据本文实施例的备用信用证的源代码的示例。
图6是示出根据本文实施例的对备用信用证执行的加密性操作的示例的图示。
图7是示出根据本文实施例的基于区块链的信用证签发处理的示例的泳道图。
图8是示出根据本文实施例的基于区块链的信用证提款处理的示例的泳道图。
图9是示出根据本文实施例的基于区块链的信用证到期处理的示例的泳道图。
图10是示出根据本文实施例的基于区块链的信用证修订处理的示例的泳道图。
图11是示出根据本文实施例的基于区块链的信用证撤销处理的示例的泳道图。
图12是示出根据本文实施例的基于跨链技术的SBLC签发处理的示例的泳道图。
图13是示出根据本文实施例的用于实现使可信保函成为可能的可信保函平台的系统的示例的示图。
图14a和图14b是示出根据本文实施例的使用基于区块链的可信保函平台的示例的示图。
图15描绘了可以根据本文的实施例执行的处理的示例。
图16描绘了根据本文的实施例的装置的模块的示例。
图17描绘了可以根据本文的实施例执行的处理的另一个示例。
图18描绘了根据本文的实施例的装置的模块的另一个示例。
图19描绘了可以根据本文的实施例执行的处理的又一个示例。
图20描绘了根据本文的实施例的装置的模块的又一个示例。
图21描绘了可以根据本文的实施例执行的处理的又一个示例。
图22描绘了根据本文的实施例的装置的模块的又一个示例。
图23描绘了可以根据本文的实施例执行的处理的又一个示例。
图24描绘了根据本文的实施例的装置的模块的又一个示例。
图25描绘了可以根据本文的实施例执行的处理的又一个示例。
图26描绘了根据本文的实施例的装置的模块的又一个示例。
图27描绘了可以根据本文的实施例执行的处理的又一个示例。
图28描绘了根据本文的实施例的装置的模块的又一个示例。
各附图中的相同附图标记和名称表示相同的元件。
具体实施方式
本文描述了用于处理基于区块链网络的保函的技术。这些技术一般涉及从与申请人相关联的计算设备接收由至少第一担保人向受益人作出的保函的申请，其中，该申请包括与申请人的身份、受益人的身份以及执行保函的一个或多个预定条件相关联的信息；基于包括在申请中的信息生成保函的数字版本；对该数字版本进行加密以生成保函的密文；生成与关联于保函的一个或多个值有关的一个或多个零知识证明(ZKP)；向区块链网络保函的密文以及一个或多个零知识证明，以将保函的密文存储在区块链上，其中，保函的密文是在一个或多个零知识证明被区块链网络中的区块链节点成功验证之后通过区块链节点的共识被存储在区块链上的。
本文还描述了用于基于区块链的信用证签发处理的技术。这些技术一般涉及接收来自与第一担保人相关联的第一计算设备的指定保函数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证一个或多个零知识证明是正确的；在验证了一个或多个零知识证明是正确的之后，基于执行共识算法将密文存储到区块链中；从与受益人或受益人的代表相关联的第二计算设备接收第一消息，该第一消息包括受益人对保函的接受；以及更新保函的状态以指示受益人已接受保函。
本文还描述了用于基于区块链的信用证提款处理的技术。这些技术一般涉及接收指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证一个或多个零知识证明；在成功验证了一个或多个零知识证明后，基于执行共识算法将密文存储到区块链中；从与受益人或受益人的代表相关联的第一计算设备接收针对保函的提款请求；基于执行共识算法将提款请求存储到区块链中；将关于提款请求的第一消息传递给与第一担保人相关联的第二计算设备；从与第一担保人相关联的第二计算设备接收第二消息，该第二消息指示第一担保人同意根据保函向受益人付款；更新存储在区块链中的保函的状态，以指示第一担保人已经处理了针对保函的提款请求；将第三消息传递到与受益人或受益人的代表相关联的第一计算设备，该第三消息指示第一担保人同意根据保函向受益人付款；从与受益人或受益人的代表相关联的第一计算设备接收第四消息，该第四消息指示受益人已经接收到来自第一担保人的付款；以及更新存储在区块链中的保函的状态，以指示受益人已经接收到针对保函的付款。
本文还描述了用于基于区块链的信用证到期处理的技术。这些技术一般涉及接收数字文档的密文，其指定保函以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证一个或多个零知识证明；在成功验证了一个或多个零知识证明后，基于执行共识算法将密文存储到区块链中；从与受益人或受益人的代表相关联的第一计算设备接收第一消息，该第一消息指示没有针对保函的未支付索款；向与第一担保人相关联的第二计算设备发送第二消息，以确认第一担保人被解除保函下的付款义务；从与第一担保人相关联的第二计算设备接收第三消息，该第三消息请求将保函的状态更改为已到期；以及更新存储在区块链中的保函的状态以指示保函已到期。
本文还描述了用于基于区块链的信用证修订处理的技术。这些技术一般涉及接收来自与至少第一担保人相关联的第一计算设备的指定保函的第一数字文档的第一密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证一个或多个零知识证明是正确的；在验证了一个或多个零知识证明是正确的之后，基于执行共识算法将第一密文存储到区块链中；从与受益人或受益人的代表相关联的第二计算设备接收第一消息，该第一消息包括修改保函的请求；向第一计算设备发送与用以修改保函的请求有关的第二消息；以及从第一计算设备接收指定保函的第二数字文档的第二密文，该第二数字文档表示第一数字文档的修改版本，其中，所述修改是基于所述请求进行的。
本文还描述了用于基于区块链的信用证撤销处理的技术。这些技术一般涉及接收来自与至少第一担保人相关联的第一计算设备的指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证一个或多个零知识证明是正确的；在验证了一个或多个零知识证明是正确的之后，基于执行共识算法将密文存储到区块链中；从与至少第一担保人相关联的第一计算设备接收第一消息，该第一消息包括用以撤销保函的请求；将用以撤销保函的请求存储在区块链中；向与受益人或受益人的代表相关联的第二计算设备发送第二消息，其中第二消息包括用以撤销保函的请求；从与受益人或受益人的代表相关联的第二计算设备接收第三消息，其中第三消息包括受益人接受撤销保函的确认；以及更新存储在区块链中的保函的状态，以指示保函已撤销。
本文还描述了用于基于跨链技术的SBLC签发处理的技术。这些技术一般涉及通过第一区块链网络中的区块链节点接收用于将数字文档的密文中继到第二区块链网络的跨链请求，其中，该跨链请求是从与第一担保人相关联的第一计算设备发送的，该数字文档指定来自第一担保人的保函和执行保函的一个或多个预定条件，并且保函是第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；基于执行共识算法将跨链请求和密文存储到与第一区块链网络相关联的第一区块链中；从第二计算设备接收用于在第一区块链网络和第二区块链网络之间中继信息的消息，该消息包括保函被受益人接受并被存储在与第二区块链网络相关联的第二区块链上的确认；以及更新保函的状态，以指示保函在第一区块链上已无效。
本文中描述的技术产生若干技术效果。在一些实施例中，保函服务可以由多个担保人提供。担保人之间的服务的整个生命周期可以记录在区块链上。例如，区块链可以存储担保人之间交互的不可篡改且透明的记录链。由于区块链上的记录是通过共识达成的，因此所有区块链节点都可以轻松地对其进行验证和信任。与两方之间的点对点加密通信相比，当涉及多于两方时，使用区块链技术提高了安全交易的效率。
在一些实施例中，保函可以是时间敏感的。例如，由于SBLC撤销或到期的时间可能会引起时间纠纷，尤其是当担保人包括位于不同时区的在岸和离岸银行时。区块链的使用可以为每次交互提供可信时间，从而可以缓解潜在的时间纠纷。
在一些实施例中，与保函服务相关联的交易中涉及的每方都可以嵌入用于标识其身份的唯一标识(ID)。当通过区块链网络发送消息时，该方还可以添加其数字签名。这样，可以验证和信任该方的身份。唯一ID也可用于追踪该方在区块链上执行的所有交易。
在一些实施例中，可以对要记录在区块链上的保函进行加密。可以在相关交易所涉及的各方之间生成和共享加密密钥。担保人还可以向区块链网络的共识节点提供零知识证明(ZKP)。共识节点可以使用零知识证明验证保函中的值是否适用于有效交易(例如，这些值是否在某个合理范围内)，而无需知道实际值。共识节点仅在验证零知识证明之后执行共识。这样，可以确保记录在区块链上的保函的内容的隐私性和安全性。
在一些实施例中，可以基于使用可信执行环境(TEE)技术来进一步保护保函的数据隐私性。可信执行环境是一个隔离的且可信的计算环境，其可以被集成在区块链网络中的区块链节点中。可信执行环境对保函内容的明文进行处理并输出该内容的密文。使用可信执行环境技术，可以在可信执行环境内部轻松更新保函，而无需透露任何内容或更新。此外，可信执行环境的输出被加密并被区块链网络中的所有区块链节点信任，因此可以在区块链节点达成共识后有效地被存储到区块链中。
为本文的实施例提供进一步的背景，如上所述，分布式账本系统(DLS)，其也可以称为共识网络(例如，由点对点节点组成)和区块链网络，使参与的实体能够安全地且不可篡改地进行交易和存储数据。尽管术语“区块链”通常与特定网络和/或用例相关联，但是在不参考任何特定用例的情况下，本文使用“区块链”来一般地指代DLS。
区块链是以交易不可篡改的方式存储交易的数据结构。因此，区块链上记录的交易是可靠且可信的。区块链包括一个或多个区块。链中的每个区块通过包含在链中紧邻其之前的前一区块的加密哈希值(cryptographic hash)链接到该前一区块。每个区块还包括时间戳、自身的加密哈希值以及一个或多个交易。已被区块链网络中的节点验证的交易经哈希处理并编入默克尔(Merkle)树中。Merkle树是一种数据结构，在该树的叶节点处的数据是经哈希处理的，并且在该树的每个分支中的所有哈希值在该分支的根处级联(concatenated)。此过程沿着树持续一直到整个树的根，在整个树的根处存储了代表树中所有数据的哈希值。可通过确定哈希值是否与树的结构一致而可快速验证该哈希值是否为存储在该树中的交易的哈希值。
区块链是用于存储交易的去中心化或至少部分去中心化的数据结构，而区块链网络是通过广播交易、验证交易和确认交易等来管理、更新和维护一个或多个区块链的计算节点的网络。如上所述，区块链网络可作为公有区块链网络、私有区块链网络或联盟区块链网络被提供。本文参考联盟区块链网络更详细地描述了本文的实施例。然而，可以预期，本文的实施例可以在任何适当类型的区块链网络中实现。
通常，联盟区块链网络在参与实体间是私有的。在联盟区块链网络中，共识处理由可被称为共识节点的授权的节点集控制，一个或多个共识节点由相应的实体(例如，金融机构、保险公司)操作。例如，由十(10)个实体(例如，金融机构、保险公司)组成的联盟可以操作联盟区块链网络，每个实体操作联盟区块链网络中的至少一个节点。
在一些示例中，在联盟区块链网络内，全局区块链被提供为跨所有节点复制的区块链。也就是说，对于全局区块链，所有共识节点处于完全共识状态。为了实现共识(例如，同意将区块添加到区块链)，在联盟区块链网络内实现共识协议。例如，联盟区块链网络可以实现实用拜占庭容错(PBFT)共识，下面将进一步详细描述。
图1是示出了可用于执行本文实施例的环境100的示例的示图。在一些示例中，环境100使得实体能够参与至联盟区块链网络102中。环境100包括计算设备106、108和网络110。在一些示例中，网络120包括局域网(LAN)、广域网(WAN)、因特网或其组合，并且连接网站、用户设备(例如，计算设备)和后端系统。在一些示例中，可以通过有线和/或无线通信链路访问网络120。在一些示例中，网络110使得能够与联盟区块链网络102通信或在联盟区块链网络102内通信。通常，网络110表示一个或多个通信网络。在一些情况下，计算系统106、108可以是云计算系统(未示出)的节点，或者每个计算系统106、108可以是单独的云计算系统，其包括通过网络互连并且用作分布式处理系统的多个计算机。
在所描绘的示例中，计算系统106、108可以各自包括能够作为节点参与至联盟区块链网络102中的任何适当的计算系统。示例计算设备包括但不限于服务器、台式计算机、膝上型计算机、平板计算设备以及智能电话。在一些示例中，计算系统106、108承载一个或多个由计算机实施的服务，用于与联盟区块链网络102进行交互。例如，计算系统106可以承载第一实体(例如，用户A)的计算机实施的、例如交易管理系统的服务，例如第一实体使用该交易管理系统管理其与一个或多个其他实体(例如，其他用户)的交易。计算系统108可以承载第二实体(例如，用户B)的由计算机实施的、例如交易管理系统的服务，例如，第二实体使用该交易管理系统管理其与一个或多个其他实体(例如，其他用户)的交易。在图1的示例中，联盟区块链网络102被表示为节点的点对点网络(Peer-to-Peer network)，并且计算系统106、108分别提供参与联盟区块链网络102的第一实体和第二实体的节点。
图2描绘了根据本文的实施例的架构200的示例。示例性概念架构200包括分别对应于参与者A、参与者B和参与者C的参与者系统202、204、206。每个参与者(例如，用户、企业)参与到作为点对点网络提供的区块链网络212中，该点对点网络包括多个节点214，至少一些节点将信息不可篡改地记录在区块链216中。如图中进一步详述，尽管在区块链网络212中示意性地描述了单个区块链216，但是在区块链网络212上提供并维护了区块链216的多个副本。
在所描绘的示例中，每个参与者系统202、204、206分别由参与者A、参与者B和参与者C提供或代表参与者A、参与者B和参与者C，并且在区块链网络中作为各自的节点214发挥作用。如这里所使用的，节点通常是指连接到区块链网络212且使相应的参与者能够参与到区块链网络中的个体系统(例如，计算机、服务器)。在图2的示例中，参与者对应于每个节点214。然而，可以预期，一个参与者可以操作区块链网络212内的多个节点214，和/或多个参与者可以共享一个节点214。在一些示例中，参与者系统202、204、206使用协议(例如，超文本传输协议安全(HTTPS))和/或使用远程过程调用(RPC)与区块链网络212通信或通过区块链网络212进行通信。
节点214可以在区块链网络212内具有不同的参与程度。例如，一些节点214可以参与共识处理(例如，作为将区块添加到区块链216的矿工节点)，而其他节点214不参与此共识处理。作为另一示例，一些节点214存储区块链216的完整的副本，而其他节点214仅存储区块链216的一部分的副本。例如，数据访问特权可以限制相应的参与者在其相应系统内存储的区块链数据。在图2的示例中，参与者系统202、204、206存储区块链216的相应的完整副本216'、216”和216”'。
区块链(例如，图2的区块链216)由一系列区块组成，每个区块存储数据。数据的示例包括表示两个或更多个参与者之间的交易的交易数据。尽管本文通过非限制性示例使用了“交易”，但是可以预期，任何适当的数据可以存储在区块链中(例如，文档、图像、视频、音频)。交易的示例可以包括但不限于交换有价值的东西(例如，资产、产品、服务、货币)。交易数据不可篡改地存储在区块链中。也就是说，交易数据不能改变。
在将交易数据存储在区块中之前，对交易数据进行哈希处理。哈希处理是将交易数据(作为字符串数据提供)转换为固定长度的哈希值(也作为字符串数据提供)的处理。不可能对哈希值进行去哈希处理(un-hash)以获取交易数据。哈希处理可确保即使交易数据轻微改变也会导致完全不同的哈希值。此外，如上所述，哈希值具有固定长度。也就是说，无论交易数据的大小如何，哈希值的长度都是固定的。哈希处理包括通过哈希函数处理交易数据以生成哈希值。示例性哈希函数包括但不限于输出256位哈希值的安全哈希算法(SHA)-256。
多个交易的交易数据被哈希处理并存储在区块中。例如，提供两个交易的哈希值，并对它们本身进行哈希处理以提供另一个哈希值。重复此过程，直到针对所有要存储在区块中的交易提供单个哈希值为止。该哈希值被称为Merkle根哈希值，并存储在区块的头中。任何交易中的更改都会导致其哈希值发生变化，并最终导致Merkle根哈希值发生变化。
通过共识协议将区块添加到区块链。区块链网络中的多个节点参与共识协议，并执行将区块添加到区块链中的工作。这样的节点被称为共识节点。上文介绍的PBFT用作共识协议的非限制性示例。共识节点执行共识协议以将交易添加到区块链，并更新区块链网络的整体状态。
更详细地，共识节点生成区块头，对区块中的所有交易进行哈希处理，并将所得的哈希值成对地组合以生成进一步的哈希值，直到为区块中的所有交易提供单个哈希值(Merkle根哈希值)。将此哈希值添加到区块头中。共识节点还确定区块链中最新的区块(即添加到区块链中的最后一个区块)的哈希值。共识节点还向区块头添加随机数(nonce)值和时间戳。
通常，PBFT提供容忍拜占庭错误(例如，故障节点、恶意节点)的实用拜占庭机器状态复制。这通过假设将发生故障(例如，假设存在独立节点故障和/或由共识节点发送的经操纵的消息)在PBFT中实现。在PBFT中，在包括主共识节点和备共识节点的序列中提供共识节点。主共识节点被周期性地改变。通过由区块链网络内的所有共识节点对区块链网络的全局状态达成一致，将交易添加到区块链中。在该处理中，消息在共识节点之间传输，并且每个共识节点证明消息是从指定的对等节点接收的，并验证在交易期间消息未被修改。
在PBFT中，共识协议是在所有共识节点始于相同的状态的情况下分多个阶段提供的。首先，客户端向主共识节点发送请求以调用服务操作(例如，在区块链网络内执行交易)。响应于接收到该请求，主共识节点将该请求组播到备共识节点。备共识节点执行请求，并且每个节点都向客户端发送回复。客户端等待直到收到阈值数量的恢复。在一些示例中，客户端等待接收f+1个回复，其中f是区块链网络内可以容忍的错误共识节点的最大数量。最终结果是，足够数量的共识节点就将记录添加到区块链的顺序达成一致，该记录被接受或者被拒绝。
在一些区块链网络中，用密码学来维护交易的隐私。例如，如果两个节点想要保持交易隐私，以使得区块链网络中的其他节点不能看出交易的细节，则这两个节点可以对交易数据进行加密处理。加密处理的示例包括(但不限于)对称加密和非对称加密。对称加密是指使用单个密钥既加密(从明文生成密文)又解密(从密文生成明文)的加密处理。在对称加密中，同一密钥可用于多个节点，因此每个节点都可以对交易数据进行加密/解密。
非对称加密使用密钥对，每个密钥对包括私钥和公钥，私钥仅对于相应节点是已知的，而公钥对于区块链网络中的任何或所有其他节点是已知的。节点可以使用另一个节点的公钥来加密数据，并且该加密的数据可以使用其他节点的私钥被解密。例如，再次参考图2，参与者A可以使用参与者B的公钥来加密数据，并将加密数据发送给参与者B。参与者B可以使用其私钥来解密该加密数据(密文)并提取原始数据(明文)。使用节点的公钥加密的消息只能使用该节点的私钥解密。
非对称加密用于提供数字签名，这使得交易中的参与者能够确认交易中的其他参与者以及交易的有效性。例如，节点可以对消息进行数字签名，而另一个节点可以根据参与者A的该数字签名来确认该消息是由该节点发送的。数字签名也可以用于确保消息在传输过程中不被篡改。例如，再次参考图2，参与者A将向参与者B发送消息。参与者A生成该消息的哈希值，然后使用其私钥加密该哈希值以提供作为加密哈希值的数字签名。参与者A将该数字签名附加到该消息上，并将该具有数字签名的消息发送给参与者B。参与者B使用参与者A的公钥解密该数字签名，并提取哈希值。参与者B对该消息进行哈希处理并比较哈希值。如果哈希值相同，参与者B可以确认该消息确实来自参与者A，且未被篡改。
在一些实施例中，区块链网络的节点和/或与区块链网络通信的节点能够使用可信执行环境(TEE)操作。在高层级处，可信执行环境是硬件(一个或多个处理器、存储器)内的可信环境，其与硬件的操作环境(例如，操作系统(OS)、基本输入/输出系统(BIOS))隔离。更详细地，可信执行环境是处理器的分离的安全区域，其确保在主处理器内加载的执行代码和数据的保密性和完整性。在处理器内，可信执行环境与操作系统并行运行。所谓的可信应用(TA)的至少部分在可信执行环境内执行，并且具有对处理器和存储器的访问。经过可信执行环境，可信应用被保护免受运行在主操作系统中的其它应用影响。进而，可信执行环境在其内部将可信应用彼此加密地隔离。
可信执行环境的示例包括由美国加利福尼亚的圣克拉拉的英特尔公司提供的软件保护扩展(SGX)。尽管SGX在本文中通过示例来讨论，但是可以预期，本申请的实施例可以使用任何合适的可信执行环境来实现。
SGX提供基于硬件的可信执行环境。在SGX中，可信硬件是中央处理单元(CPU)的裸片，并且一部分物理存储器被隔离以保护选择代码和数据。存储器的被隔离部分被称为飞地(enclave)。更加具体地，飞地被提供作为存储器中的飞地页高速缓存(EPC)并且被映射到应用地址空间。存储器(例如，DRAM)包括对于SGX预留的随机存储器(PRM)。随机存储器是基本输入/输出系统水平中的连续存储器空间并且不能够由任何软件访问。每一个飞地页高速缓存是由操作系统分配以将应用数据和代码加载到随机存储器中的存储器集(4KB)。飞地页高速缓存元数据(EPCM)是相应飞地页高速缓存的进入地址并且确保每一个飞地页高速缓存能够仅由一个飞地共享。即，单个飞地能够使用多个飞地页高速缓存，而飞地页高速缓存专用于单个飞地。
在可信应用的执行期间，处理器在访问存储在飞地中的数据时在所谓的飞地模式中操作。飞地模式中的操作强制对于每一个存储器访问的额外硬件检查。在SGX中，可信应用被编译到可信部分和不可信部分。可信部分例如对于操作系统、基本输入/输出系统、特权系统代码、虚拟机管理器(VMM)、系统管理模式(SMM)等不可访问。在操作中，可信应用在存储器的随机存储器内运行和创建飞地。由飞地内的可信部分执行的可信功能被不可信部分调用，并且在飞地内执行的代码将数据看作是明文数据(未加密)，并且对数据的外部访问被拒绝。可信部分向调用提供经加密的响应，并且可信应用继续执行。
可以执行认证处理以验证期望的节点(例如，可信应用的可信部分)正在SGX提供的可信执行环境内安全地执行。通常，认证处理包括可信应用从质询者(例如，区块链网络中的另一节点，区块链网络的密钥管理系统(KMS))接收认证请求。作为响应，可信应用请求其飞地产生远程认证，也被称为引用。产生远程认证包括本地认证被从飞地发送给所谓的引用飞地，其验证本地认证，并且通过使用非对称认证密钥对本地认证进行签名来将本地认证转换为远程认证。远程认证(引用)被提供给质询者(例如，区块链网络的密钥管理系统)。
质询者使用证实验证服务来验证远程认证。对于SGX，英特尔提供英特尔认证服务(IAS)，其从质询者接收远程认证，并且验证远程认证。更具体地说，IAS处理远程认证，并且提供报告(例如，认证验证报告(AVR))，其指示远程认证是否被验证。如果没有被验证，则会指示错误。如果被验证(期望的代码在可信执行环境中安全执行)，则质询者能够开始或者继续与可信应用交互。例如，响应于验证，密钥管理系统(作为质询者)能够向执行可信执行环境的节点发布非对称加密密钥(例如，公钥和私钥对)(例如，经过密钥交换处理，例如椭圆曲线Diffie-Hellman(ECDH))以使得节点能够与其它节点和/或客户端安全地通信。可信执行环境技术的附加细节被描述在例如2019年4月3日提交的PCT申请PCT/CN2019/081180中，其内容通过引用并入本文。
图3是示出根据本文实施例的系统300的示例的示图。系统300可以包括区块链网络310，该区块链网络310包括多个区块链节点。区块链节点与区块链相关联和/或维护区块链。区块链节点可以就与保函生命周期中的事件相关的交易达成共识。该保函可以是至少一名担保人对至少一名受益人所作的任何保证。例如，在买方从卖方购买商品的采购交易中，卖方承诺交付某些商品，而买方承诺向卖方支付一定的金额，则保函可以由银行作出，其担保买方支付给卖方的金额正确的款项会被及时收到。如果买方无法在到期日之前支付用于所述购买的全部款项，则银行将支付用于所述购买的全部或剩余款项。这种类型的保函可以称为信用证或跟单信用证。在一些示例中，银行的客户可以是买方，其中银行代表买方向卖方提供保函。例如，银行可以作出保函，以在买方(可以是银行的客户)不履行与卖方的协议的情况下，由银行向卖方付款。这种类型的保函可以称为备用信用证(SBLC)，有时也简称为SLOC。SBLC通常用于帮助促进彼此不熟悉的公司或位于具有不同法律和法规的国家或地区的公司之间进行国际贸易。
使用SBLC作为保函的示例，SBLC生命周期中的事件可以包括但不限于例如SBLC的签发、提款、撤销、修订等中的一项或多项。如上所述，SBLC是银行保函文件，其中申请人/债务人(通常是买方或进口商)向受益人/债权人(通常是供应商，卖方或出口商)担保，在债权人向银行出示存在索款的证明(例如通过向银行出示SBLC)的情况下，银行(即开证银行)可以在出现违约时代替申请人/债务人作为债务人。SBLC可用于确保合同、契约或商业交易流程的履行。
SBLC为受益人提供了附加的保函，即确保受益人可以收到债务金额。例如，SBLC是在债务人与受益人之间的营销合同或采购订单合同之外提供的金融合同。例如，当买方(债务人)打算从卖方(受益人)处购买商品时，买方和卖方签署一份采购订单合同(或协议)或营销合同(或协议)，所述合同说明了交易条款，例如商品规格、商品费用以及交付商品和付款的最后期限。采购订单合同是买方和卖方之间的协议。银行不是采购订单合同的订立方，而是SBLC的订立方。签发SBLC的银行可以称为开证银行302。债权人的银行可以称为收款银行306。在本文的一些示例中，交易是在位于第一国家(在岸)的进行出售的卖方与位于第二国家(离岸)的买方之间进行的。因此，开证银行302也称为离岸银行302，而收款银行306也称为在岸银行306。开证银行302通过签发SBLC担保：在固定的时间段内，在SBLC的申请人的指示下，在申请人违约的情况下支付担保金额，即使申请人没有偿付能力并且不能偿还开证银行302。如果债务人已根据营销合同部分或全部偿还了债务，或者SBLC已失效，则可以修订或撤销SBLC。
在一些实施例中，可以将SBLC中的信用担保金额视为申请人申请并由开证银行302预先批准的贷款。如果SBLC在其到期前被执行，则通过收款银行306将贷款发放给受益人。开证银行然后，申请人将需要向开证银行302还清贷款。如果SBLC在其生命周期内从未被执行过，则贷款将在到期时被撤销，也将永远不会发放给受益人。
对于具有重复交易的业务操作，SBLC可能是实用的。例如，在长期或定期的业务关系中，可以确保在与买方定期进行大额交易、或者有时在收到付款之前就发起产品交付的卖方获得担保资金。在这种情况下，可以在业务关系初期即办理SBLC，并将其用于双方之间的所有后续交易，直到买方违约，或者SBLC被撤销或失效。
在一些实施例中，与SBLC的生命周期中的事件相关联的交易可以由开证银行302或收款银行306来发起。例如，开证银行302的内部系统可以执行内部交易审批处理，并且通过云节点304将内部批准的交易存储在区块链上。在一些实施例中，云节点304可以是区块链网络310上属于开证银行302的区块链节点。云节点304可以由开证银行302管理和控制，并参与区块链网络310的共识。区块链网络310中的区块链节点可以预验证交易。预验证可以包括基于零知识证明验证数字签名和交易的合法性。交易通过预验证后，可被包含在要追加到区块链的区块中。收款银行306可以经由云节点308从区块链检索相关交易，并调用其自己的内部系统以审批交易。与开证银行302的云节点304类似，云节点308可以是区块链网络310上属于收款银行306的共识节点。
图4是示出根据本文实施例的在担保人的内部系统和区块链网络之间的消息流的示例400的流程图。在高级别上，担保人的内部系统401可以包括应用(APP)402、数据库404、密钥管理系统(KMS)406以及计算和连接组件408。在一些实施例中，内部系统401可以包括更少或更多的组件。内部系统401连接到包括多个区块链节点的区块链网络409(为了说明的目的，在图4中仅示出了区块链节点410和区块链节点412，应当理解，区块链网络409可以包括许多附加的区块链节点)。
应用402可以是用于提供保函服务的软件程序。应用402可以是保函的申请人和担保人的内部系统401之间的接口。例如，应用402可以用于接收包括保函的申请人的身份信息、时间、金额、条件和内容等的输入。在一些实施例中，与保函有关的数据可以存储在数据库404中。数据库404可以包括任何存储器或数据库模块，并且可以采取易失性或非易失性存储器的形式，包括但不限于磁性介质、光学介质、随机存取存储器(RAM)、只读存储器(ROM)、可移动介质或任何其他合适的本地或远程存储器组件。数据库404可以存储各种对象或数据，包括类、框架、应用、备份数据、业务对象、任务、网页、网页模板、数据库表、存储业务或动态信息的存储库，以及包括与应用402或内部系统401的目的相关联的任何参数、变量、算法、指令、规则、约束或其引用的任何其他合适的信息。
示例性数据可以包括来自申请人的输入、参与交易的其他担保人发送或转发的与保函、模板和加密密钥有关的数据，等等。此外，数据库404可以包括任何其他适当的数据，例如VPN应用、固件日志和策略、防火墙策略、安全或访问日志、打印或其他报告文件，以及其他文件。在一些示例中，应用402可以通过数据库应用程序接口(API)从数据库404检索数据。
应用402可以与计算和连接组件408通信与保函有关的信息。在一些实施例中，计算和连接组件408可以包括可信计算模块420、可信时间模块422和可信身份模块424。可信计算模块420可以包括执行由软件开发工具包(SDK)提供的指令的一个或多个处理器。示例性指令可以包括执行加密、生成数字签名和/或零知识证明或其他适用的证明。在一些实施例中，一个或多个数据处理器可以具有可信执行环境(TEE)，其与一个或多个处理器的操作系统隔离并被配置为为一个或多个数据处理器内执行的代码和加载的数据提供增强的私密性和完整性。
在一些实施例中，可信计算模块420可以被配置为根据隐私法记录与保函的申请人相关联的信息。例如，可信计算模块420可以生成记录的哈希值，并且将包括该记录和哈希值的区块添加到与存储了保函关联的记录的区块链网络409相关联的区块链。
在一些实施例中，可信计算模块420可以被配置为响应于与针对保函受益人的保函相关联的经验证记录的请求，提供由应用402执行的步骤/操作的经验证记录。可信计算模块420还可以提供由可信时间模块422生成的经验证时间戳、由可信身份模块424生成的经验证身份，和/或与由应用402执行的步骤/操作中的每个步骤/操作相关联的计算结果。
在一些实施例中，可以由密钥管理系统406将用于执行加密以及生成数字签名和证明的加密密钥提供给可信计算模块420。在一些实施例中，密钥管理系统406可以生成、存储和管理加密密钥。在一些实施例中，密钥管理系统406包括使用可信执行环境技术(例如英特尔SGX)实现的安全应用环境。可信执行环境可以执行一个或多个软件程序或库。
在一些实施例中，可信时间模块422可以被配置为基于国家标准时间信息(例如格林威治标准时间(GMT)、UTC)或从全球定位系统获得的时间信息来生成时间戳。在一些实施例中，可信时间模块422可以将其维持的时间与区块链网络409中的区块链节点所采用的全球时间同步，以确保存储在区块链上的时间戳的准确性。
在一些实施例中，可信时间模块422可以被配置为使用针对不同区域中的金融系统的不同标准时间来生成与不同用户相关联的时间戳。例如，可信时间模块422可以使用与第一用户相关联的离岸金融系统所承认的第一标准时间来生成与第一用户相关联的时间戳，并使用与第二用户相关联的在岸金融系统所承认的第二标准时间来生成与第二用户相关联的时间戳，其中第一用户和第二用户位于具有不同金融系统的不同区域中。
可信身份模块424可以被配置为基于与用户相关联的唯一ID中的一个或多个来验证用户(例如申请人或受益人)的身份。在一些实施例中，唯一ID可以包括以下至少之一：(i)移动电话号码，(ii)信用卡号，(iii)与在线支付系统相关联的用户ID，(iv)与在线购物账户相关联的用户ID，(v)与音乐流播或下载账户相关联的用户ID，(vi)与电影流播或下载账户相关联的用户ID，(vii)与消息传送或聊天账户相关联的用户ID，(viii)与在线银行账户相关联的用户ID，(ix)与叫车服务相关联的用户ID，(x)与在线食品订购服务相关联的用户ID，(xi)社会安全号；(xii)驾驶执照号，(xiii)护照号，(xiv)与在线游戏服务相关联的用户ID，(xv)政府实体发布的ID，(xvi)一个或多个指纹，(xvii)一个或多个声纹，或(xviii)虹膜信息。
在一些实施方式中，唯一ID还可以包括用户的去中心化标识(DID)。去中心化标识可以包括统一资源定位符(URL)方案标识、用于去中心化标识方法的标识以及专用于去中心化标识方法的标识。去中心化标识可以指向相应的去中心化标识文档，该文档可以包括预设格式(例如JSON-LD)的描述性文本，该描述性文本与去中心化标识和去中心化标识的所有者有关。去中心化标识可以用作用于定位去中心化标识文档的统一资源标识(URI)。去中心化标识文档可以包括各种属性，例如上下文、去中心化标识主体、公钥、认证、授权和代理、服务端点、创建、更新、证明和可扩展性。去中心化标识文档可以定义或指向定义多个操作的资源，所述操作可以相对于去中心化标识执行。在本文描述的示例中，去中心化标识符合由万维网联合会(W3C)指定的标准。但是，也可以使用其他去中心化标识。关于去中心化标识的附加信息可以在2019年7月9日提交的申请PCT/CN2019/095299、2019年8月30日提交的申请PCT/CN2019/103780以及2019年10月11日提交的申请CN201910963431.0中找到。以上申请通过引用并入本文。
在一些实施例中，可信身份模块424可以被配置为通过使用不同的标识来验证位于具有不同金融系统的不同区域中的不同用户。例如，可信身份模块424可以被配置为使用由与第一用户相关联的第一金融系统识别的第一组标识中的至少一个来验证第一用户的身份，并使用由与第二用户相关联的第二金融系统识别的第二组标识中的至少一个来验证第二用户的身份，其中第一用户和第二用户位于具有不同金融系统的不同区域中。
在一些示例中，计算和连接组件408还可包括路由器426，其可将由一个或多个处理器处理的信息路由至可通信地耦接至内部系统401的区块链网络409中的区块链节点410。如前所述，区块链节点410可以是可以对消息进行签名和/或验证消息并与其他区块链节点通信的云节点。区块链节点410还可以是区块链网络409中参与共识过程的共识节点。在一些实施例中，可以基于诸如超文本传输协议安全(HTTPS)或传输层安全性(TLS)之类的安全通信协议来执行内部系统401和区块链网络409内部以及它们之间的通信。例如，可以在智能合约中定义由区块链节点410执行的函数，其中，区块链网络的挖矿节点执行智能合约中的函数，并且区块链网络的共识全节点验证交易。
区块链网络409中的区块链节点可以通过基于共识协议的共识来验证并同意添加在区块链上的交易。示例性共识协议可以包括工作量证明(PoW)、权益证明(PoS)和PBFT等。在SBLC示例中，区块链节点可以与银行、信用合作社、信托公司、贷款公司、保险公司、投资机构、管理机构等相关联。一旦交易被添加，交易就变得不可篡改，并且各方可以信任它们作为相应保函服务或处理的证据。
记录在区块链上的交易数据所携带的时间、身份和内容是可信的。区块链使提供保函服务的应用402能够保存与在服务的多个步骤或关键时间点中的每个期间发生的事件有关的信息(例如，何人、何事以及何时)的经验证记录。信息的记录以符合(或与以前的系统相比更符合)预定规则的方式保存。例如，当保函是信用证或SBLC时，预定规则可以是与跟单信用证有关的统一规则和用途(国际商会的UCR 600)或与备用信用证有关的国际规则和惯例(国际商会的RPIS 98)。
图5是根据本文实施例的SBLC的源代码500的示例。在此示例中，SBLC源代码500包括SBLC编号(“sblcNo”)、SBLC类型(“sblcType”)、开证银行的代码(“issueBankCode”)，收款行的代码(“beneficiaryBankCode”)、数字和文字形式的最大可贷金额(“maxAggregateSum”，“maxAggregateSumInWord”)、申请人名称(“principal”)、受益人名称(“borrower”)、SBLC到期日期和时间(“expiryDatetime”)、SBLC生效日期和时间(“effectiveDatetime”)、SBLC申请日期和时间(“applicationDatetime”)、剩余可贷金额(“remainAggregateSum”)、SBLC中的实际贷款金额(“totalLoanAmount”)、与SBLC相关联的条款列表(“actionNoList”)和SBLC的状态(“status”)。上述的SBLC源代码500仅是示例，在其他示例中，SBLC源代码500可以包括更多或更少的信息。
SBLC类型可以表示SBLC的类型。SBLC的类型可以包括履约备用信用证、预付款备用信用证、招标/投标备用信用证、反担保备用信用证、融资备用信用证、直接付款备用信用证、保险备用信用证、商业备用信用证等。最大可贷金额可以表示开证银行可以向申请人批准的贷款总额。在一些示例中，最大可贷金额可以是申请人在开证银行的账户的可用余额。实际贷款金额可以表示SBLC中的担保金额。剩余可贷金额可以是在发放了SBLC中申请的额度之后，开证银行可以向申请人批准的剩余贷款。SBLC的状态表示SBLC在其生命周期中的当前状态，例如已签发、正在处理、有效、已撤销或到期等。
为了保护与SBLC相关的交易涉及的各方的隐私，可以在将SBLC发送给区块链节点进行共识之前对其进行加密。例如，如在图4的描述中所讨论的，在将加密的SBLC发送给区块链节点410以进行共识之前，可以由计算和连接组件408执行对SBLC的加密。可以基于线性秘密共享方案(LSSS)，通过参与交易的各方之间的协商来导出加密密钥。加密密钥协商的附加细节在例如2019年11月27日提交的申请号为201911187078.8的中国申请中描述，其内容通过引用并入本文。这种加密密钥导出技术增强了加密密钥的安全性，并减少了由第三方解密的可能性。
在一些实施例中，开证银行(例如，图3中的302)也可以生成与SBLC相关联的零知识证明。零知识证明与加密的SBLC一起被提供给区块链节点，使得区块链节点可以在不知道SBLC的内容的情况下验证SBLC的合法性。在验证SBLC合法之后，区块链节点可以执行共识以将加密的SBLC记录在区块链上。
图6是示出根据本文实施例的对SBLC 620执行的加密操作的示例600的示图。在此示例中，假定银行A 602和银行B 604是SBLC 620的两个联合担保人。换句话说，银行A 602和银行B 604是开证银行。银行C 606是SBLC 620的收款银行。银行D 608可以是未参与SBLC620的相关交易的银行。如前所述，可以在参与SBLC 620的相关交易的各方之间协商加密密钥。在该示例600中，各方包括银行A 602、银行B 604和银行C 606。各方同意的加密密钥可用于加密SBLC620字符串或添加数字签名612。不是交易的参与方的银行D 608无法解密该加密的SBLC。
银行A 602和银行B 604还可以生成与SBLC 620相关联的值的一个或多个零知识证明。这样的零知识证明可以包括同态加密方案614下的证明、范围证明616和/或零测试618。同态加密方案614可以用于分别对最大可贷金额、实际贷款金额和剩余可贷金额进行加密。在执行同态加密方案614之后，加密的最大可贷金额、实际贷款金额和剩余可贷金额在不进行解密的情况下不会被透露。但是，基于加密方案的同态性质，如果加密的实际贷款金额和加密的剩余可贷金额之和等于加密的最大可贷金额，则可以验证实际贷款金额和剩余可贷金额之和等于最大可贷金额。同态加密的附加细节在例如2019年4月22日提交的PCT/CN2018/114344、PCT/CN2018/114421和PCT/CN2018/114420中进行了描述，其内容通过引用并入本文。
在一些实施例中，范围证明可以用于在不透露实际金额的情况下证明某金额在一定范围内。在一些示例中，银行A 602和银行B 604可以提供范围证明，以表明最大可贷金额在合理范围内。例如，可以将合理范围设置为0到240。在一些示例中，可以提供范围证明以表明实际贷款金额或剩余可贷金额小于最大可贷金额。零测试可用于证明金额为零。例如，在SBLC到期或还清贷款之后，可以提供零测试以证明SBLC 620中的实际贷款金额为零。加密的SBLC和零知识证明可以形成要由区块链网络624中的区块链节点验证的加密的SBLC 622的密文。银行A 602和银行B 604之一可以例如通过调用与区块链网络624相关联的区块链上的智能合约来将加密的SBLC 622的密文发送给区块链网络624。在区块链节点验证零知识证明以确认SBLC 620合法之后，它们可以执行共识处理并将加密的SBLC 622的密文记录在区块链上。
附加地或替代地，可信执行环境可用于为SBLC内容提供数据隐私性。如前所述，可信执行环境处理明文并输出密文。在一些实施例中，可以在可信执行环境内部处理SBLC的明文。例如，当银行A 602发起对SBLC的修订或状态更新时，例如修订SBLC的担保金额、接受或撤销SLBC，可以在可信执行环境内部的SBLC的明文上进行相应的更新。可信执行环境的输出被区块链网络624中的区块链节点加密和信任。在一些实施例中，可信执行环境加密的SBLC可以与零知识证明一起被发送给区块链网络624中的其他区块链节点。在验证了零知识证明之后，区块链节点可以执行共识以将更新的SBLC存储到区块链。
以下描述提供了与信用证的生命周期相关联的基于区块链的处理的各种实施例。出于说明目的，SBLC用作信用证的示例。其他类型的信用证或保函可适用于根据本文实施例的处理。
图7是示出根据本文实施例的基于区块链的信用证签发处理700的示例的泳道图。在该示例中，信用证是备用信用证，但是相同的原理可以应用于其他类型的信用证。处理700的参与者可以包括申请人702、开证银行704、区块链网络706、收款银行708和受益人710。如前所述，申请人702通常是商业交易的买方。开证银行702通常是买方的离岸银行。受益人710通常是商业交易的卖方。收款银行708通常是卖方的在岸银行。在一些实施例中，收款银行708可以充当受益人710的代表，以通过区块链网络706与开证银行704进行交互。
在712，申请人702可以向开证银行704提交SBLC的申请。在一些实施例中，申请人702和受益人710可以商定SBLC的条款，例如SBLC中的担保付款金额或担保贷款金额。可以将对受益人710的担保付款金额视为对申请人702的担保贷款金额。在申请人702无法支付欠受益人710的担保金额的情况下，担保人将向受益人710支付担保金额，并向申请人702提供相同金额的贷款。例如，担保付款金额或担保贷款金额可以是申请人702和受益人710之间的商业交易中涉及的货币金额，例如买方打算从卖方购买的商品的价格。可以以物理形式或通过银行的网站或APP(例如，如图4的描述中所讨论的应用402的用户端版本)以电子方式提交申请。通常，申请人702可以在申请中指明申请人的身份信息、信用信息、保函信息、收款银行信息以及受益人的身份信息等。在某些情况下，一些信息可以作为申请的附件提交。
申请人的身份信息可以包括申请人的姓名、地址、电话号码、电子邮件地址和业务类型等中的一个或多个。信用信息可以包括申请人的信用历史、与开证银行704相关联的账户信息、钞票、代管账户信息或可以表明申请人具有足够的信用额度以偿还SBLC中的担保贷款金额的其他信息中的一个或多个。保函信息可以包括SBLC的担保金额、保函的服务或对象、保函的期限以及保函的实施条件等。收款银行信息可以包括收款银行的银行名称、地址、电话号码、银行汇款码(swift code)、和汇款路线码(routing number)等中的一个或多个。受益人的身份信息可以包括受益人的姓名、地址、电话号码、电子邮件地址、业务类型和在收款银行708的账号等中的一个或多个。
在接收到申请之后，开证银行704可以将申请中的信息输入或存储到银行的内部系统。例如，可以通过如图4的描述中所讨论的应用402来执行信息输入。在一些示例中，开证银行704还可以将申请转换为SBLC的标准源代码格式。然后，在714，开证银行704可以执行对申请的内部审批处理。
在一些示例中，内部审批处理714可以涉及开证银行704验证申请中是否缺少用于批准的任何所需信息。如果缺少任何所需信息，则可以拒绝申请(716a)，并且开证银行704可以请求申请人702补充所缺少的信息。在违约的情况下，开证银行704还可以验证申请人702是否具有足够的额度以偿还SBLC中的担保付款金额或担保贷款金额。例如，如果申请人在开证银行704具有银行账户，则开证银行704可以验证该银行账户的余额是否超过担保贷款金额。在一些示例中，开证银行还可以检查申请人702是否已提交了其他信用证明。如果没有足够的额度来支付担保贷款金额，则开证银行704可以拒绝该申请。否则，开证银行704可以批准该申请(716b)。
在一些示例中，开证银行704可以基于申请人的可用额度批准小于申请人702所申请的金额的金额，并且向申请人702提供较少的金额报价。如果申请人702接受该报价，则可以以所接受的金额批准SBLC。在一些示例中，开证银行704可以从申请人的银行账户中扣留担保付款金额或担保贷款金额，直到付款被发放到收款银行708或者SBLC被撤销或到期为止。
在716b处批准SBLC之后，开证银行704可以最终确定SBLC源代码，对SBLC源代码进行加密并生成证明(例如，零知识证明)。如在图6的描述中所讨论的，可以使用与收款银行708协商的加密协议来对SBLC源代码进行加密。例如，开证银行704可以通过调用与区块链网络706相关联的区块链上的智能合约来向区块链网络706发送加密的SBLC的密文。在下面的描述中，假设通过调用区块链上的相关智能合约来执行与区块链网络706的交互。智能合约可以例如更新SBLC的密文、更新SBLC的状态、将消息发送给开证银行704以及将消息发送给收款银行708。
在某些示例中，可以在不涉及第三方的情况下使用智能合约来实现更新和记录可跟踪、不可逆和防篡改的SBLC交易，这样可以确保整个SBLC生命周期的安全可信记录。智能合约的自主执行能力将区块链的交易安全保证扩展到需要动态事件更新、检索和验证的情况。
在一些实施例中，发证行704可以向关联的云节点(例如，图4的描述中讨论的区块链节点410)提交请求，并且云节点可以进行智能合约调用。智能合约可以包括指令以基于智能合约调用中包括的请求来更新SBLC的密文或SBLC的状态。
在操作中，云节点可以生成包括模板的智能合约，以执行诸如更新SBLC的密文、更新SBLC的状态、向开证银行704发送消息以及向收款银行708发送消息等操作。在一些实施例中，云节点可以进一步在智能合约中注册账户并基于智能合约生成更新日志。例如，与申请人702、开证银行704、收款银行708和受益人710中的一个或多个相关联的账户可以调用智能合约模板来执行相关操作。在一些实施例中，在智能合约中定义了与SBLC交易有关的那些实体，以获得调用智能合约的授权。
在一些实施例中，云节点可以进一步在智能合约模板中定义规则以用于更新SBLC的不同方面，或者向不同实体发布授权以用于更新SBLC或其状态。在被授权调用智能合约的实体的请求下，云节点可以进一步向智能合约添加更多模板。在一些模板中，模板中的规则包括将与SBLC的更新事件相关联的日期、时间、位置和/或实体名称关联起来的规则。
在一些示例中，云节点生成智能合约的交易并将智能合约的交易提交给区块链网络706。智能合约706的交易可以包括智能合约的程序和发起者。区块链网络中的区块链节点验证智能合约的交易。在区块链节点成功验证智能合约的交易之后，智能合约可以以分布式方式部署在区块链网络706中，并且具有唯一的智能合约地址，可以从该地址调用智能合约。
在718，可以通过区块链网络706中的区块链节点的共识处理在区块链上发布加密的SBLC。例如，连接到开证银行704的内部系统的区块链节点(例如，云节点)可以将加密的SBLC和证明提交给区块链网络706以用于共识。区块链共识节点验证证实SBLC的合法性的证明以达成共识，然后将加密的SBLC存储在要追加到区块链的一个或多个区块中。在区块链中生成和记录加密的SBLC的细节已在前面的图5和6的描述中进行了讨论。
在将加密的SBLC记录在区块链上之后，收款银行708可以检索加密的SBLC并基于与开证银行702协商的加密密钥执行解密。然后，在720，收款银行708可以确认接受SBLC，或者在出现任何打字错误的情况下，在724，请求对SBLC的修订。如果在区块链上签发的SBLC被接受，则收款银行708可以将SBLC状态更新为“已签发”，并请求区块链网络706通过共识将更新的SBLC状态记录在区块链上。在722，响应于该请求，区块链网络706可以通过共识来相应地存储更新的SBLC状态。
如果收款银行708在SBLC中检测到打字错误，则它可以在724通过向区块链网络706提交提议的修订以用于共识处理，从而请求对SBLC的修订。如果修订与SBLC中的货币价值有关，则收款银行708可以生成用于对所提议的修订进行合法性检查的证据。
在达成共识之后，提议的修订可以被记录在区块链上并在726被传递给开证银行704。例如，区块链上的智能合约可以生成关于提议的修订的消息，并将该消息传递给开证银行704。在728，开证银行704执行对提议的修订的内部审批处理。在批准之后，开证银行704可以在730修订SBLC，对修订后的SBLC进行加密，并将其提交给区块链网络706以更新区块链上的SBLC。例如，可以通过调用区块链上的智能合约来实现对区块链上的SBLC的更新，其中，智能合约被配置为更新SBLC。在732，通过区块链网络706将指示SBLC已被修订的消息传递给收款银行708。例如，该消息可以由区块链上的智能合约生成，并由智能合约发送给收款银行708。在734，收款银行确认接受修订的SBLC，并请求区块链网络706将SBLC状态更新为“已签发”。例如，收款银行可以调用区块链上的智能合约以更新SBLC状态。在736，区块链网络706可以响应于对修订的请求(724)来更新SBLC状态。例如，区块链上的智能合约可以更新SBLC状态。
在本文中，当我们说消息或文档被发送给诸如申请人702、离岸(开证)银行704、在岸(收款)银行708或受益人710之类的实体或从该实体发送时，是指该消息或文档被发送给与该实体关联的计算设备或从与该实体相关联的计算设备发送。在处理700中，实体可以发送或接收一个或多个消息或文档，其中用于发送或接收特定消息或文档的计算设备可以不同于用于发送或接收其他消息或文档的计算设备。与该实体相关联的计算设备可以是例如该实体本地的计算机或可通过网络访问该实体的云计算设备。
图8是示出根据本文实施例的基于区块链的信用证提款处理800的示例的泳道图。在该示例中，信用证是备用信用证，但是相同的原理可以应用于其他类型的信用证。处理800的参与者可以包括离岸(开证)银行704、区块链网络706、在岸(收款)银行708和受益人710。
在802，受益人710或受益人710的代表可以向收款银行708提交SBLC的提款请求。当申请人702违约时，例如在营销或采购订单协议中的双方商定的付款截止日期之后不付款，受益人710可以发起提款请求，在一些实施例中，提款请求802还可以包括支持文档以支持其请求。例如，支持文档可以包括发送给申请人702的受益人710的发票、对申请人702的索款以及索款证明。例如，关于发票未支付的违约声明的证明可以是出示书面证书或提及未支付的签名宣誓书。
在804，收款银行708可以执行内部审批处理以审查提款请求。在一些实施例中，收款银行708可以执行初步检查，以确定提款请求中是否包括必要的文件。收款银行708可能不会对索款和证明的内容进行实质性审查。例如，收款银行708可以检查提款请求是否至少包括带有相应证明的索款信。如果所包括的文件足以支持初步索款，则提款行708可以在806b批准提款请求。否则，收款银行708可以在806a拒绝提款请求，并要求受益人710补充或纠正信息。如果提款行708在806b批准了提款请求，则提款行708可以在812通过区块链网络706向开证银行704提交提款请求，该请求包括索款信(带有证明)。在一些示例中，收款银行708可以在将提款请求发送给区块链网络706以用于共识之前对提款请求进行加密。
在814，区块链网络706中的区块链节点可以执行共识以记录提款请求，并向开证银行704通知该提款请求已被提交。例如，可以通过调用与区块链网络706相关联的区块链上的智能合约来执行对提款请求的记录和通知。在816，开证银行704可以在对索款信进行解密之后执行内部审批处理。基于对索款信中包括的索款和证明的审查，如果索款满足表明违反了在SBLC的条款中定义的申请人702和受益人710之间的协议的一个或多个条件，并且证据足以支持该索款，则开证银行704可以在818a批准提款请求。否则，开证银行704在818b拒绝提款请求。
如果在818a批准了提款请求，则开证银行704可以向收款银行708付款，并在820将SBLC的状态更新为“已处理索款”。例如，可以基于包括在SBLC中的收款银行708的身份信息，通过诸如电汇的银行转账服务向收款银行708付款。
在822，区块链网络706通过共识记录SBLC的状态更新，并将消息传递给收款银行708。在824，收款银行708确认接收到付款，并将SBLC状态更新为“已处理付款”。在826，区块链网络706将SBLC状态相应地更新为“已处理付款”。例如，对状态更新的记录可以通过调用与区块链网络706相关联的区块链上的智能合约来执行。
如果在818b拒绝了提款请求，则在828，开证银行704可以通过区块链网络706向收款银行708发送拒付通知。在830，区块链网络706记录拒付通知，并将消息传递给收款银行708。在832，收款银行708可以确认接收到拒付通知，并将SBLC的状态更新为“索款已结束”。在834，区块链网络706将SBLC的状态相应地更新为“索款已结束”。
图9是示出了根据本文实施例的基于区块链的信用证到期处理900的示例的泳道图。在该示例中，信用证是备用信用证，但是相同的原理可以应用于其他类型的信用证。处理900的参与者可以包括离岸(开证)银行704、区块链网络706和在岸(收款)银行708。
如前所述，SBLC可以具有开证银行704提供的由申请人702和受益人710同意的签发日期、生效日期以及到期日期。SBLC中的保函从生效日期至到期日期有效。可以根据管理SBLC的辖区的时区来确定到期日期。到期日期还可以基于申请人702和受益人710同意的时区，例如开证银行704所处的时区、收款银行708所处的时区或GMT。通常，如果申请人702同意在某个到期日之前向受益人710付款，则SBLC的到期日将是在付款到期日之后的几天(例如，五个工作日)。在该示例中，受益人710提交了在步骤902、904、906a、906b、908和910中处理的提款请求，其分别类似于图8中的步骤802、804、806a、806b、812和814。
在SBLC的到期日，收款银行708可以在912确定是否有未支付索款。如果存在未支付索款，则收款银行708可以发送请求消息以请求延长SBLC的有效期限，直到支付了SBLC中的担保贷款金额以结束索款为止。另一方面，如果没有未支付索款，则收款银行708可以发送确认消息，以确认开证银行704被解除SBLC下的付款义务。在914，区块链网络706将请求消息或确认消息传递给开证银行704。
在916，开证银行704执行对接收到的消息的内部审批处理。如果该消息是请求延长SBLC的有效期限的请求消息，则开证银行704可以在内部批准之后更新SBLC中的条款以反映所请求的延长。在918，如果该消息是确认消息，则开证银行704可以将SBLC状态更新为已到期。开证银行704向区块链网络706发送关于状态更新的消息发送，并且在920，区块链网络706将记录在区块链上的SBLC的状态更新为“已到期”。例如，开证银行704可以调用区块链上的智能合约以更新SBLC的状态。
图10是示出根据本文实施例的基于区块链的信用证修订处理1000的示例的泳道图。在该示例中，信用证是备用信用证，但是相同的原理可以应用于其他类型的信用证。处理1000的参与者可以包括申请人702、离岸(开证)银行704、区块链网络706、在岸(收款)银行708和受益人710。在一些实施例中，在申请人702根据双方之间的采购订单合同向受益人710进行部分付款之后，执行处理1000。在一些示例中，可以通过传统金融渠道进行部分付款，例如在为申请人702提供服务的开证银行704和为受益人710提供服务的收款银行708之间的电汇。假设SBLC中的担保贷款金额涵盖了订单的全部付款，则由于已进行了部分付款，因此申请人702可以请求受益人710确认该部分付款。在确认之后，申请人702可以通过将担保贷款金额减少为该采购订单的全额付款减去该部分付款，来请求开证银行704修订SBLC。因此，受益人无法通过针对SBLC提出索款来从申请人702和开证银行704获得超过订单的全额付款金额的款项。
在1002，受益人710在SBLC的到期日期之前从申请人702接收部分付款。然后，受益人710可以向收款银行708通知该部分付款。在1004，收款银行708可以确认该部分付款，并通过区块链网络706将确认提交给开证银行704和申请人702。在1006，区块链网络706中的区块链节点达成共识并将对该部分付款的确认存储在区块链上，并将确认传递给开证银行704和/或申请人702。例如，收款银行708可以调用区块链上的智能合约以在区块链节点处发起共识处理，将对该部分付款的确认存储在区块链上，并将与对该部分付款的确认有关的消息传递给开证银行704和申请人702。
响应于识别出存储在区块链上的对该部分付款的确认，在1008，申请人702可以请求开证银行704提交对SBLC的修订请求以减少担保贷款金额。减少的金额可以等于通过区块链网络706接收到的受益人710确认的该部分付款的金额。在1010，开证银行704可以执行内部审批处理以审查该修订请求。在一些实施例中，开证银行704可以参考存储在区块链上的信息来执行内部审批处理。例如，响应于接收到修订请求，开证银行704可以检查收款银行706对该部分付款的确认是否存储在区块链上。如果未找到确认，则开证银行704可以拒绝修订请求，或者要求申请人702提供付款证明。假设在区块链上找到了收款银行706的确认，但如果修订请求有缺陷，则开证银行704可以在1012a拒绝修订请求。例如，如果未正确说明金额，SBLC已到期或受益人710提出索款，则该修订有缺陷。否则，开证银行704可以在1012b批准修订请求。在1014，开证银行704可以基于修订请求来修订SBLC，并且对修订后的SBLC进行加密以生成修订的SBLC的密文，其中密文将被存储在区块链上。
在1016，区块链网络706中的区块链节点达成共识，以将修订的SBLC的密文存储在区块链上，并将关于修订的SBLC的消息传递给收款银行708。例如，连接到开证银行704的区块链节点可以调用区块链上的智能合约以在区块链节点处发起共识处理。在1018，收款银行708执行内部审批处理以审查修订的SBLC。如果批准，则收款银行708可以在1022确认接受修订的SBLC。在一些示例中，收款银行708可以将该确认提交给区块链网络706以存储在区块链上。否则，在1024，收款银行708可以拒绝修订的SBLC，提供拒绝的原因，并提议进一步修订SBLC。
在1026，区块链网络706将拒绝决定存储在区块链上，并将与拒绝原因和提议的修订有关的消息传递给开证银行704。例如，连接到收款银行708的区块链节点可以调用与区块链网络706相关联的区块链上的智能合约以执行该步骤。在1028，开证银行704基于收款银行708所提供的拒绝原因，对提议的修订进行内部审批处理。如果被批准，则开证银行704可以在1030基于收款银行708提议的修订来修订SBLC。然后，开证银行704可以对修订的SBLC进行加密以生成修订的SBLC的密文，其中密文将被存储在区块链上。
在1032，区块链网络706中的区块链节点就将修订的SBLC的密文存储在区块链上达成共识，将修订的SBLC的密文存储在区块链上，并将关于修订的SBLC的消息传递给收款银行708。例如，连接到开证银行704的区块链节点可以调用区块链上的智能合约以在区块链节点处发起共识处理。在1034，收款银行708可以确认接受修订的SBLC并请求将状态更新记录在区块链上。在1036，区块链网络706可以将SBLC的状态更新为“已接受修订”。例如，连接到收款银行708的区块链节点可以调用区块链上的智能合约以将SBLC状态更新为“已接受修订”。
图11是示出根据本文实施例的基于区块链的信用证撤销处理1100的示例的泳道图。在该示例中，信用证是备用信用证，但是相同的原理可以应用于其他类型的信用证。处理1100的参与者可以包括申请人702、离岸(开证)银行704、区块链网络706、在岸(收款)银行708和受益人710。在一些实施例中，在申请人702根据双方之间的采购订单合同向受益人710进行全额付款之后，执行处理1100。在一些示例中，可以通过传统金融渠道进行全额付款，例如在为申请人702提供服务的开证银行704和为受益人710提供服务的收款银行708之间的电汇。假设SBLC中的担保贷款金额涵盖了订单的全部付款，则由于已进行了全部付款，因此申请人702可以请求受益人710确认该全部付款。在确认之后，由于解除了申请人702支付受益人710的任何义务，因此申请人702可以请求开证银行704撤销SBLC。
在1102，受益人710在SBLC的到期日期之前从申请人702接收全额付款。然后，受益人710可以向收款银行708通知有关全额付款。在1104，收款银行1004可以确认该全额付款，并通过区块链网络706将确认提交给开证银行704和申请人702。在1106，区块链网络706中的区块链节点达成共识，并将对全额付款的确认存储在区块链上。区块链网络706将确认传递给开证银行704和/或申请人702。例如，收款银行708可以调用区块链上的智能合约以在区块链节点处发起共识处理，将对该全额付款的确认存储在区块链上，并将与对该全额付款的确认有关的消息传递给开证银行704和申请人702。
响应于识别出存储在区块链上的对全额付款的确认，申请人702可以在1108请求开证银行704提交对SBLC的撤销请求。在1110，开证银行704可以针对该撤销请求执行内部审批处理。在一些实施例中，开证银行704可以参考存储在区块链上的信息来执行内部审批处理。例如，响应于接收到撤销请求，开证银行704可以检查收款银行708对全额付款的确认是否存储在区块链上。如果没有找到该确认，或者如果受益人710提出了未支付索款的记录，则开证银行704可以在1112a拒绝撤销请求，或者要求申请人702提供全额付款证明。假设在区块链上找到了收款银行708的确认，如果撤销请求无效，则开证银行704仍可以在1112a拒绝撤销请求。例如，如果SBLC已到期，则撤销请求无效。否则，开证银行704可以在1112b批准撤销请求。如果被批准，则开证银行704可以在1114将SBLC状态更新为“已请求撤销”。
在1116，区块链网络706将SBLC状态更新存储在区块链上，并将与撤销请求有关的消息传递给收款银行708。例如，连接到收款银行708的区块链节点可以调用与区块链网络706相关联的区块链上的智能合约以执行该步骤。在1118，收款银行708可以确认接受SBLC的撤销并请求将状态更新记录在区块链上。在1120，区块链网络706可以将SBLC的状态更新为“已撤销”。例如，连接到收款银行708的区块链节点可以调用区块链上的智能合约以将SBLC状态更新为“已撤销”。
图12是示出根据本文实施例的基于跨链技术的SBLC签发处理1200的示例的泳道图。处理1200的参与者可以包括申请人702、开证银行704、区块链网络1 703、中继705、区块链网络2 707和收款银行708。开发了跨链技术以促进不同区块链之间的交互和互操作性。如前所述，开证银行704通常是商业交易买方的离岸银行。收款银行708通常是位于不同国家或与不同金融系统相关联的卖方的在岸银行。因此，开证银行704和收款银行708可以具有连接到不同的区块链网络的区块链节点(诸如在图3的描述中讨论的云节点)。在图12所示的示例中，开证银行704具有连接到区块链网络1 703的区块链节点。收款银行708具有连接到区块链网络2 707的区块链节点。
在一些实施例中，可以使用中继705来促进区块链网络1 703和区块链网络2 707之间的交互。中继705是可信实体，并且可以采取各种形式。在一些示例中，中继705可以是区块链网络1 703和区块链网络2707的区块链节点。在一些示例中，中继器705可以是可信节点，其在中继区块链网络1 703和区块链网络2 707之间的跨链数据之前执行数据验证。在一些示例中，中继705还可以简单地中继跨链数据而不执行数据验证。在一些示例中，中继705可以是区块链网络，其在中继区块链网络1 703和区块链网络2 707之间的跨链数据之前通过共识执行数据验证。
可以基于本文实施例的各种技术来实现中继705的可信度。例如，这些技术可以包括可信执行环境、权威证明(POA)、安全多方计算、零知识证明、共识算法等。
在1212，申请人702可以将对SBLC的申请提交给开证银行704。如在图7的描述中所讨论的，申请人702和受益人可以就SBLC的条款(例如SBLC中的担保贷款金额)达成一致。在接收到申请之后，开证银行704可以将申请中的信息输入或存储到银行的内部系统。例如，可以通过如图4的描述中所讨论的应用402来执行信息输入。在一些示例中，开证银行704还可以将申请转换为SBLC的标准源代码格式。然后，在1214，开证银行704可以对申请执行内部审批处理并在批准之后发起跨链请求。
在一些示例中，内部审批处理可以涉及开证银行704验证申请中是否缺少用于批准的任何所需信息。如果缺少任何所需信息，则可以拒绝该申请，并且开证银行704可以请求申请人702补充所缺少的信息。在违约的情况下，开证银行704还可以验证申请人702是否具有足够的额度以偿还SBLC中的担保贷款金额。例如，如果申请人在开证银行704具有银行账户，则开证银行704可以验证该银行账户的余额是否超过担保贷款金额。在一些示例中，开证银行还可以检查申请人702是否已提交了其他信用证明。如果没有足够的额度来支付担保贷款金额，则开证银行704可以拒绝该申请。否则，开证银行704可以批准该申请。在SBLC被批准之后，开证银行704可以最终确定SBLC源代码，对SBLC源代码进行加密，生成证明，并将加密的SBLC和证明包括在对区块链网络2 707的跨链请求中。
在1216，可以通过共识将跨链请求存储在与区块链网络1 703相关联的第一区块链上，并传递给中继705。例如，连接到开证银行704的内部系统的区块链节点(例如，云节点)可以提交跨链请求以用于共识。在区块链节点验证了证实SBLC合法性的证明之后，区块链节点可以执行共识并将加密的SBLC存储在要追加到第一区块链的区块中。在区块链中生成和记录加密的SBLC的细节已在前面的图5和6的描述中进行了讨论。
在1218，中继705可以将跨链请求中继到区块链网络2 707。中继705可以是区块链网络1 703和区块链网络2 707两者的可信实体。该系统被配置为确保要中继的跨链数据实际上存储在第一区块链上，从而使其可信。在一些实施例中，中继705可以监视跨链消息并且在验证了消息被存储在第一区块链上之后中继所述消息。在一些实施例中，区块链网络中的区块链节点可以生成证明。中继705可以检索并验证证明以确认跨链消息源自第一区块链。在一些实施例中，可以将验证数据预先存储在目的地区块链网络的简单支付验证(SPV)节点中。SPV节点可以通过中继705获得跨链数据，验证跨链数据的真实性，并且将经验证跨链数据转发到目的地。同态加密的附加细节在例如2019年4月22日提交的PCT/CN2018/114344、PCT/CN2018/114421和PCT/CN2018/114420中进行了描述，其内容通过引用并入本文。
在1220，区块链网络2 707通过共识来记录跨链请求，并将加密的SBLC传递至收款银行708。收款银行708可以基于与开证银行702协商的加密密钥来执行对加密的SBLC的解密。然后，收款银行708可以在1222确认接受SBLC，并请求区块链网络2 707通过共识将更新的SBLC状态记录在与区块链网络2 707相关联的第二区块链上。在一些实施例中，收款银行708还可以发送跨链请求以将确认传递给开证银行708。
在1224，区块链网络2 707可以通过共识将第二区块链上的SBLC状态更新为“已签发”，并将确认传递给中继705。在1226，中继705可以验证SBLC是在第二区块链上签发的，提供验证证据，并且将接受确认中继到区块链网络1703。
在1228，区块链网络1703中的区块链节点可以验证SBLC是在第二区块链上签发的证明，并将验证结果和接受确认传递给开证银行704。在一些实施例中，信任根(RoT)可以被部署在区块链网络1703中的区块链节点上。信任根可以是承载可信执行环境的硬件模块。在接收到证明和接受确认之后，区块链节点可以使用信任根来验证中继705已验证了SBLC是在第二区块链上签发的证明。
在1230，开证银行704可以响应于接收到验证结果并且收款银行708已确认了接受SBLC，使存储在第一区块链上的SBLC无效。这是为了确保只有一个已签发的SBLC有效，以使受益人无法从存储在第一区块链和第二区块链上的SBLC获得双重付款。在1232，区块链网络1 703可以将第一区块链上的SBLC状态更新为“无效”。
在本文中，当描述用于处理与保函生命周期有关的事件的处理时，例如处理700、800、900、1000、1100和1200，为便于说明，我们可以说与实体相关联的计算设备发送第一消息、接收第二消息、发送第三条消息、接收第四条消息，依此类推。应当理解，与实体相关联的相同或不同的计算设备可以用于发送或接收第一消息、第二消息、第三消息和第四消息等。因此，例如，取决于上下文，短语“与实体相关联的计算设备”可以表示与该实体相关联的多个计算设备，其中多个计算设备中的第一个执行第一任务，而多个计算设备中的第二个执行第二任务，依此类推。
图13是示出根据本文实施例的用于实现使可信保函成为可能的基于区块链的可信保函平台1300的系统的示例的示图。可信保函平台1300可以提供与保函生命周期的各个阶段有关的服务。在该示例中，可信保函平台1300向第一保函的第一申请人1322a、第二保函的第二申请人…、第N1保函的第N1申请人1322b(统称为1322)，第一担保人1324a、第二担保人…、第N2担保人1324b(统称为1324)，第一受益人1326a、第二受益人…、第N3受益人1326b(统称为1326)、第一受益人代理1342a、第二受益人代理……和第N4受益人代理1342b(统称为1342)提供服务。
例如，第一申请人1322a可以是打算从受益人1326a购买商品的买方，该受益人可以是商品的卖方。第一申请人1322a可以申请由第一担保人1324a签发的第一保函，第一担保人可以是为第一申请人1322a提供服务的开证银行(或离岸银行)。第一担保人1324a可以与第一受益人代理1342a交互，第一受益人代理1342a可以是为第一受益人1326a提供服务的受益银行(或在岸银行)。
在一些示例中，保函可以涉及申请人1322、担保人1324、受益人1326和受益人代理1342。申请人1322可以具有与受益人1326的协议，其中申请人1322同意在预定到期日之前向受益人1326支付预定金额。担保人1324签发保函以作为在申请人1322不能在到期日之前支付全部预定金额的情况下，受益人1326将在预定到期日之前接收到预定金额的保证。担保人1324与受益人代理1342交互以执行与保函有关的处理。
可信保函平台1300被配置为提供使得申请人1322、担保人1324、受益人1326和受益人代理1342能够在保函生命周期中方便且及时地实施与各种事件相关联的处理的工具(例如，基于网络的端口和接口以及智能合约)。例如，可信保函平台1300可以提供基于网络的用户接口，其促进相关各方的保函的申请、签发、修订、提款、到期和撤销，并且促进对一个或多个区块链中与保函的申请、签发、修订、提款、到期和撤销保函有关的信息的记录。
例如，保函可以是信用证，并且可信保函平台1300可以提供工具以实现图7的基于区块链的信用证签发处理700、图8的基于区块链的信用证提款处理800、图9的基于区块链的信用证到期处理900、图10的基于区块链的信用证修订处理1000、图11的基于区块链的信用证撤销处理1100以及图12所示的基于跨链技术的SBLC签发处理1200。
通常，每个担保人1324可以向一个或多个申请人1322中的每个签发一个或多个保函，并且每个申请人1322可以从一个或多个担保人1324中的每个申请一个或多个保函。一个或多个担保人1324可以向申请人1322签发保函。担保人1324可以向一个或多个申请人1322签发保函。每个保函可以具有一个或多个受益人。
在一些实施方式中，可信保函平台1300包括保函文档生成模块1302、保函文档修订模块1304、保函文档加密模块1306、保函签发处理模块1308、保函履行处理模块1310、保函到期处理模块1312、保函撤销处理模块1344、保函跨链处理模块1346、零知识证明生成模块1348、用户接口模块1314和区块链处理模块1316。保函文档生成模块1302被配置为生成保函文档，例如保函的源代码，如SBLC的源代码500。例如，在图7的处理700中，离岸(开证)银行704可以使用其自己的系统或者使用保函文档生成模块1302来生成SBLC。在一些实施方式中，保函文档生成模块1302是基于网络的工具，其提供允许离岸银行704方便地生成保函文档的保函文档模板。保函文档修订模块1304被配置为使用与图7中的处理700和/或图10中的处理1000等效或相似的处理来促进对保函文档的修订。
保函文档加密模块1306被配置为对保函文档进行加密，并生成加密密钥。零知识证明生成模块1348被配置为生成零知识证明。保函签发处理模块1308被配置为使用与图7的处理700等效或相似的处理来促进保函的签发。保函履行处理模块1310被配置为处理与履行保函有关的处理，诸如使用与图8中的处理800等效或相似的处理来处理提款请求。
保函到期处理模块1312被配置为使用与图9的处理900等效或相似的处理来处理与保函到期有关的处理。保函撤销处理模块1344被配置为使用与图11的处理1100等效或相似的处理来处理与保函撤销有关的处理。保函跨链处理模块1346被配置为处理涉及多个区块链网络的处理，诸如使用与图12的处理1200等效或相似的处理来促进基于跨链技术的SBLC签发处理。
与保函和保函生命周期中的事件有关的信息可以被记录在由区块链网络1328维护的区块链1334中。区块链处理模块1316用作区块链网络1328中的区块链节点1330，并维护区块链1334的本地副本1318。区块链1318可以包括记录，例如1318a、1318b、1318c。例如实体1336的其他实体，可以作为区块链网络1328中的区块链节点1332参与，其中，实体1336可以包括计算机服务器1338，其维护区块链1334的本地副本1340并执行挖矿和/或共识操作。
在一些实施方式中，基于区块链的可信保函平台1300可以向申请人1322、担保人1324、受益人1326和受益人代理1342提供云服务，以促进与处理保函有关的各种处理。申请人1322、担保人1324、受益人1326和受益人代理1342中的每个在平台1300上具有账户，并且属于每个实体的隐私数据不与其他实体共享。一些模块可以处理特定应用、特定担保人、特定受益人或特定受益人代表私有的数据，并且任何其他方都无法访问该隐私数据。
例如，保函文档生成模块1302可以被担保人1324用来生成保函文档。保函文档加密模块1306可以被担保人1324用来生成加密密钥并生成保函文档的密文。零知识证明生成模块1348可以被担保人1324用来生成零知识证明。未经第一担保人1324的许可，任何其他担保人1324都不能访问由保函文档生成模块1302为第一担保人1324生成的保函文件。未经第一担保人1324的许可，任何其他担保人1324都不能访问由保函文档加密模块1306为第一担保人1324生成的加密密钥。未经第一担保人1324的许可，任何其他担保人1324都不能访问由零知识证明生成模块1348为第一担保人1324生成的零知识证明。
在一些实施方式中，用户接口模块1314可以提供集成的用户接口(例如，以网络端口的形式)，从而使得申请人1322、担保人1324、受益人1326和受益人代理1342能够访问可信保函平台1300的各种模块(例如1302、1304、1306、1308、1310、1312、1316、1344、1346和1348)的功能。例如，申请人1322可以使用集的用户接口来提交针对保函的申请并跟踪该申请的状态，和/或调用保函撤销处理模块1344以促进保函的撤销。担保人1324可以使用集成用户接口来调用保函文档生成模块1302以生成保函文档，调用保函文档加密模块1306以生成保函文档的密文并生成加密密钥，调用零知识证明生成模块1348以生成零知识证明，调用保函跨链处理模块1346以促进两个或更多个区块链网络之间的交互，或上述的任意组合。担保人1324可以使用集成用户接口来调用保函签发处理模块1308以签发保函。受益人代理1342可以使用集成用户接口来调用保函履行处理模块1310以处理提款请求，和/或调用保函到期处理模块1312以确认保函的到期。
图14a和图14b是示出了信用证的申请人、担保人和受益人如何使用基于区块链的可信保函平台1300的示例的图。图14a示出了申请人、担保人和受益人之间的关系。图14b示出了基于区块链的可信保函平台1300与申请人、担保人和受益人之间的关系。在该示例中，位于外国A的滑雪板制造商1400开发了一种新型滑雪板，其使用由本国的芯片制造商1402制造的半导体芯片。该滑雪板可与外国C的软件开发商1404开发的滑雪分析软件一起使用。位于本国的滑雪训练中心1406计划采购由滑雪板制造商1400制造的滑雪板，并将其分发给滑雪比赛队进行训练。
滑雪板制造商1400与芯片制造商1402签订采购协议，其中滑雪板制造商1400同意在交付可安装在滑雪板上的100,000个芯片后的30天内向芯片制造商1402支付100万美元。滑雪板制造商1400和芯片制造商1402彼此之间先前没有关系，并且芯片制造商1402不确定是否可以信任滑雪板制造商1400按时付款。芯片制造商1402要求滑雪板制造商1400提供担保支付100万美元的SBLC。滑雪板制造商1402在开证银行(或离岸银行)1408具有账户，该开证银行1408在此示例中为银行A。芯片制造商1402在收款银行(或在岸银行)1410中具有账户，该收款银行1410在此示例中为银行B。
滑雪板制造商1400根据图7的基于区块链的信用证签发处理700来访问可信保函平台1300以从开证银行1408(在此示例中为外国银行)获得100万美元的SBLC。SBLC被记录在区块链中(例如，使用与步骤718等效或类似的步骤)，并且在收款银行1410(本国工商银行)确认接受SBLC后，将SBLC的状态更新为“已签发”(例如，使用与步骤722等效或类似的步骤)。例如，如果在收款银行1410接受SBLC之前，收款银行1410在SBLC中发现了打字错误，则收款银行1410可以使用可信保函平台1300来使用包括与步骤724至736等效或类似的步骤的处理来请求对SBLC的修订。
在芯片制造商1402将100,000个芯片交付给滑雪板制造商1400之后，滑雪板制造商1400向芯片制造商1402发送100万美元的付款。使用可信保函平台1300，芯片制造商1402向收款银行1410通知有关全额付款，收款银行1410确认该付款并将确认提交给开证银行1408和滑雪制造商1400，并且对全额付款的确认被存储在区块链中(例如，使用与图11中的步骤1104和1106等效或类似的步骤)。滑雪板制造商1400使用可信保函平台1300来使用包括与步骤1108至1120等效或类似的步骤的处理来提交用以撤销SBLC的请求，从而导致SBLC的状态被更新为“已撤销”并被记录在区块链上。
例如，代替一次性支付一百万美元，滑雪板制造商1400可以同意分两期向芯片制造商1402付款。在达到第一预定里程碑之后，滑雪板制造商1400向芯片制造商1402支付50万美元。使用包括与图10的步骤1002至1006等效或类似的步骤的处理，芯片制造商1402确认接收到该部分付款，并且将对该部分付款的确认存储在区块链中。在进行了部分付款之后，使用包括与步骤1008至1036等效或类似的步骤的处理，滑雪板制造商1400提交对SBLC的修订，以将担保金额从100万美元减少到50万美元，从而导致SBLC被修订并且修订的SBLC被存储在区块链中。
例如，滑雪板制造商1400、软件开发商1404和滑雪训练中心1406签订协议，其中(i)滑雪板制造商1400同意在通用滑雪分析软件包交付后的30天内向软件开发商1404支付20万美元，该分析软件包可以处理由集成到滑雪板中的定制芯片产生的数据，以及(ii)滑雪训练中心1406同意在专为本国滑雪选手配置的定制滑雪分析软件包交付后的30天内向软件开发商1404支付10万美元，外加为期一年、每月1万美元的付款，用于软件更新和服务。软件开发商1404在收款银行1412具有账户，在此示例中，收款银行1412是自由国家银行。滑雪训练中心1406在开证银行1414具有账户，在此示例中，开证银行1414是本国银行。
滑雪板制造商1400和滑雪训练中心1406访问可信保函平台1300，以使用类似于图7的基于区块链的信用证签发处理700的处理从开证银行1408和1414共同获得SBLC。在此示例中，SBLC的总担保金额为42万美元，其中开证银行1408(为滑雪板制造商1400提供服务)担保20万美元，而开证银行1414(为滑雪训练中心1406提供服务)担保20万美元。
例如，开证银行1408(为滑雪板制造商1400提供服务)和开证银行1414(为滑雪训练中心1406提供服务)是维护第一区块链的第一区块链网络的参与者节点。收款银行1412(为软件开发者1404提供服务)是维护第二区块链的第二区块链网络的参与者节点。最初，在滑雪板制造商1400和滑雪训练中心1406申请SBLC之后，SBLC被记录在第一区块链中。各方决定将SBLC从第一区块链转移到第二区块链。这可以通过使用包括与图12的步骤1216至1232等效或类似的步骤的处理来实现。
在软件开发商1404将通用滑雪分析软件包交付给滑雪板制造商1400并且滑雪板制造商1400向软件开发商1404支付了20万美元之后，滑雪板制造商1400可以使用包括与图10的步骤1008到1036等效或类似的步骤的处理来请求对SBLC的修订，以将担保金额从42万美元减少至$22万美元，并更新SBLC的状态以确认软件开发商1404已接收到来自滑雪板制造商1400的20万美元的付款。
在软件开发商1404将定制滑雪分析软件包交付给滑雪训练中心1406并且滑雪训练中心1406向软件开发商1404支付了10万美元之后，滑雪训练中心1406可以使用包括与图10的步骤1008至1036等效或类似的步骤的处理来请求对SBLC的修订，以将担保金额从22万美元减少至12万美元，并更新SBLC的状态以确认软件开发商1404已接收到来自滑雪训练中心1406的10万美元付款。此后，每次滑雪训练中心1406进行1万美元的月度付款时，可以使用上述处理对SBLC进行修订，以减少担保金额。在连续十二个月向软件开发商1404进行1万美元的月度付款后，滑雪训练中心1406可以使用包括与图11中的步骤1108至1120等效或类似的步骤的处理来请求撤销SBLC。
图14a和图14b的示例示出了基于区块链的可信保函平台1300如何提供集成系统，该集成系统可以被位于不同大洲的不同国家中的公司用来方便地处理与例如信用证或备用信用证的保函有关的处理，以在各方之间建立信任并促进业务交易，从而使在任何地方开展业务变得容易。
图15描绘了可以根据本文实施例执行的处理1500的示例。为方便起见，处理1500将被描述为由位于一个或多个位置并根据本文被适当地编程的一个或多个计算机的系统执行。例如，诸如图4的内部系统401的、被适当地编程的内部计算机系统可以执行处理1500。
在1502，计算机系统从与申请人相关联的计算设备接收对由至少第一担保人向受益人作出的保函的申请，其中，该申请包括与申请人的身份、受益人的身份以及执行保函的一个或多个预定条件相关联的信息。
在1504，计算机系统基于包括在申请中的信息生成保函的数字版本。在1506，区块链节点对该数字版本进行加密以生成保函的密文。
在1508，计算机系统生成与关联于保函的一个或多个值有关的一个或多个零知识证明(ZKP)。在1510，区块链节点向区块链网络发送保函的密文以及一个或多个零知识证明，以将保函的密文存储在区块链上，其中，保函的密文是在一个或多个零知识证明被区块链网络中的区块链节点成功验证之后通过区块链节点的共识被存储在区块链上的。
在一些情况下，保函的形式为SBLC。在一些情况下，保函指定当满足执行保函的一个或多个预定条件时，担保人应向受益人支付预定金额。
在一些情况下，担保人是为申请人提供服务的离岸银行，并且该预定金额是在满足一个或多个预定条件时通过为受益人提供服务的在岸银行向受益人支付的。
在一些情况下，该申请还包括指定在岸银行的身份的信息。在一些情况下，该申请还包括证明申请人在违约SBLC的情况下有能力支付预定金额的信息。
在一些情况下，申请人的身份包括申请人的姓名、地址、电话号码、电子邮件地址和业务类型中的一个或多个。在一些情况下，受益人的身份包括受益人的姓名、地址、电话号码、电子邮件地址和业务类型中的一个或多个。
在一些情况下，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。在一些情况下，一个或多个零知识证明中的至少一个是基于同态加密生成的。
在一些情况下，一个或多个零知识证明包括范围证明和/或零测试。在一些情况下，用于对数字版本进行加密的加密密钥是基于线性秘密共享方案来导出的。
在一些情况下，保函是由第一担保人和第二担保人向受益人作出的，保函的形式为SBLC，并且保函指定在满足执行保函的一个或多个预定条件时，第一担保人和第二担保人应向受益人支付预定金额。
在一些情况下，第一担保人是为申请人提供服务的第一银行，第二担保人是为申请人提供服务的第二银行，并且该申请还包括证明在申请人违约SBLC的情况下，申请人在第一银行和第二银行中具有足够资金用于支付预定金额的信息。
在一些情况下，处理1500还包括：验证一个或多个零知识证明，并在一个或多个零知识证明被验证之后基于保函的密文执行共识，并在成功执行共识之后将保函的密文存储到与区块链网络相关联的区块链中。
在一些情况下，处理1500还包括：在第一计算设备处接收对由担保人向受益人作出的保函的申请，其中，该申请包括与申请人的身份、受益人的身份以及执行保函的一个或多个预定条件相关联的信息；将申请发送给与担保人相关联的第二计算设备；在第一计算设备处接收基于申请生成的保函的数字版本；对数字版本进行加密以生成保函的密文；生成与关联于保函的一个或多个值有关的一个或多个零知识证明；以及向区块链网络发送密文以及一个或多个零知识证明，以将密文存储在区块链上，其中，密文是在一个或多个零知识证明被区块链网络中的区块链节点成功验证之后通过区块链节点的共识被存储在区块链上的。
图16是根据本文实施例的装置1600的模块的示例的示图。装置1600可以是被配置为处理保函信息的计算机系统的实施例的示例。装置1600可以对应于上述实施例，并且装置1600包括以下：接收模块1602，用于从与申请人相关联的计算设备接收由至少第一担保人向受益人作出的保函的申请，其中，该申请包括与申请人的身份、受益人的身份，以及执行保函的一个或多个预定条件相关联的信息；生成模块1604，用于基于包括在申请中的信息生成保函的数字版本；加密模块1606，用于对数字版本进行加密以生成保函的密文；生成模块1604生成与关联于保函的一个或多个值有关的一个或多个零知识证明；发送模块1608，用于向区块链网络发送保函的密文以及一个或多个零知识证明，以将保函的密文存储在区块链上，其中，保函的密文是在一个或多个零知识证明被区块链网络中的区块链节点成功验证之后通过区块链节点的共识被存储在区块链上的。
在可选实施例中，保函的形式为SBLC。在可选实施例中，保函指定当满足执行保函的一个或多个预定条件时，担保人应向受益人支付预定金额。
在可选实施例中，担保人是为申请人提供服务的离岸银行，并且在预定金额是在满足一个或多个预定条件时通过为受益人提供服务的在岸银行将向受益人支付的。在可选实施例中，该申请还包括指定在岸银行的身份的信息。
在可选实施例中，该申请还包括证明申请人在违约SBLC的情况下有能力支付预定金额的信息。在可选实施例中，申请人的身份包括申请人的姓名、地址、电话号码、电子邮件地址和业务类型中的一个或多个。
在可选实施例中，受益人的身份包括受益人的姓名、地址、电话号码、电子邮件地址和业务类型中的一个或多个。在可选实施例中，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。
在可选实施例中，一个或多个零知识证明中的至少一个是基于同态加密生成的。在可选实施例中，一个或多个零知识证明包括范围证明和/或零测试。在可选实施例中，用于对数字版本进行加密的加密密钥是基于线性秘密共享方案来导出的。在可选实施例中，保函是由第一担保人和第二担保人向受益人作出的，保函的形式为SBLC，并且保函指定在满足执行保函的一个或多个预定条件时，第一担保人和第二担保人应向受益人支付预定金额。
在可选实施例中，第一担保人是为申请人提供服务的第一银行，第二担保人是为申请人提供服务的第二银行，并且该申请还包括证明在申请人违约SBLC的情况下，申请人在第一银行和第二银行中具有足够资金用于支付预定金额的信息。
在可选实施例中，装置1600还包括：验证子模块，用于验证一个或多个零知识证明，并在一个或多个零知识证明被验证之后基于保函的密文执行共识，并在成功执行共识之后将保函的密文存储到与区块链网络相关联的区块链中。
在可选实施例中，装置1600还包括：接收模块1602，在第一计算设备处接收对由担保人向受益人作出的保函的申请，其中，该申请包括与申请人的身份、受益人的身份以及执行保函的一个或多个预定条件相关联的信息；发送模块1608，将申请发送给与担保人相关联的第二计算设备；接收模块1602在第一计算设备处接收基于申请生成的保函的数字版本；加密模块1606，对数字版本进行加密以生成保函的密文；生成模块1604，生成与关联于保函的一个或多个值有关的一个或多个零知识证明；以及发送模块1608向区块链网络发送密文以及一个或多个零知识证明，以将密文存储在区块链上，其中，密文是在一个或多个零知识证明被区块链网络中的区块链节点成功验证之后通过区块链节点的共识被存储在区块链上的。
图17描绘了可以根据本文实施例执行的处理1700的另一示例的流程图。为方便起见，处理1700将被描述为由区块链节点执行，该区块链节点可以包括位于一个或多个位置并根据本文被适当地编程的一个或多个计算机的系统。例如，适当编程的计算机系统，例如图1的计算机系统100，可以执行处理1700。
在1702，区块链节点接收来自与第一担保人相关联的第一计算设备的指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件。
在1704，区块链节点验证一个或多个零知识证明是正确的。在1706，在验证了一个或多个零知识证明是正确的之后，区块链节点基于执行共识算法将密文存储到区块链中。
在1708，区块链节点从与受益人或受益人的代表相关联的第二计算设备接收第一消息，该第一消息包括受益人对保函的接受。在1710，区块链节点更新保函的状态以指示受益人已接受保函。
在一些情况下，保函的形式为SBLC。在一些情况下，保函指定当满足执行保函的一个或多个预定条件时，担保人应向受益人支付预定金额。
在一些情况下，担保人是为数字文档的申请人提供服务的离岸银行，受益人的代表是为受益人提供服务的在岸银行，并且该预定金额是在满足一个或多个预定条件时通过在岸银行向受益人支付的。
在一些情况下，该数字文档还包括指定在岸银行的身份的信息。在一些情况下，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。
在一些情况下，一个或多个零知识证明中的至少一个是基于同态加密生成的。在一些情况下，一个或多个零知识证明包括范围证明和/或零测试。
在一些情况下，密文是使用基于线性秘密共享方案导出的加密密钥来加密的。在一些情况下，保函是由第一担保人和第二担保人向受益人作出的，保函的形式为SBLC，并且保函指定在满足执行保函的一个或多个预定条件时，第一担保人和第二担保人应向受益人支付预定金额。在一些情况下，共识算法基于Pow、PoS和PBFT中的一种。
图18是根据本文实施例的装置1800的模块的另一示例的示图。装置1800可以是区块链节点的实施例的示例。装置1800可以对应于上述实施例，并且装置1800包括以下：接收模块1802，用于接收来自与第一担保人相关联的第一计算设备的指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证模块1804，用于验证一个或多个零知识证明是正确的；存储模块1806，用于在验证了一个或多个零知识证明是正确的之后，基于执行共识算法将密文存储到区块链中；接收模块1802从与受益人或受益人的代表相关联的第二计算设备接收第一消息，该第一消息包括受益人对保函的接受；以及更新模块1808，用于更新保函的状态以指示保函已被受益人接受。
在可选实施例中，保函的形式为SBLC。在可选实施例中，保函指定当满足执行保函的一个或多个预定条件时，担保人应向受益人支付预定金额。
在可选实施例中，担保人是为数字文档的申请人提供服务的离岸银行，受益人的代表是为受益人提供服务的在岸银行，并且该预定金额是在满足一个或多个预定条件时通过在岸银行向受益人支付的。
在可选实施例中，该申请还包括指定在岸银行的身份的信息。在可选实施例中，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。
在可选实施例中，一个或多个零知识证明中的至少一个是基于同态加密生成的。在可选实施例中，一个或多个零知识证明包括范围证明和/或零测试。
在可选实施例中，密文是使用基于线性秘密共享方案导出的加密密钥来加密的。在可选实施例中，保函是由第一担保人和第二担保人向受益人作出的，保函的形式为SBLC，并且保函指定在满足执行保函的一个或多个预定条件时，第一担保人和第二担保人应向受益人支付预定金额。在可选实施例中，共识算法基于Pow、PoS和PBFT中的一种。
图19是根据本文的实施例的处理1900的又一示例的流程图。为方便起见，处理1900将被描述为由区块链节点执行，该区块链节点包括位于一个或多个位置并根据本文被适当地编程的一个或多个计算机的系统。例如，适当编程的计算机系统，例如图1的计算机系统100，可以执行处理1900。
在1902，区块链节点接收指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件。
在1904，区块链节点验证一个或多个零知识证明。在1906，在成功验证了一个或多个零知识证明后，区块链节点基于执行共识算法将密文存储到区块链中。
在1908，区块链节点从与受益人或受益人的代表相关联的第一计算设备接收针对保函的提款请求。在1910，区块链节点基于执行共识算法将提款请求存储到区块链中。
在1912，区块链节点将关于提款请求的第一消息传递给与第一担保人相关联的第二计算设备。在1914，区块链节点从与第一担保人相关联的第二计算设备接收第二消息，该第二消息指示第一担保人同意根据保函向受益人付款。
在1916，区块链节点更新存储在区块链中的保函的状态，以指示第一担保人已处理了针对保函的提款请求。
在1918，区块链节点将第三消息传递给与受益人或受益人的代表相关联的第一计算设备，该第三消息指示第一担保人同意根据保函向受益人付款。
在1920，区块链节点从与受益人或受益人的代表相关联的第一计算设备接收第四消息，该第四消息指示受益人已接收到来自第一担保人的付款。
在1922，区块链节点更新存储在区块链中的保函的状态，以指示受益人已接收到针对保函的付款。
在一些情况下，保函的形式为SBLC。在一些情况下，保函指定当满足执行保函的一个或多个预定条件时，担保人应向受益人支付预定金额。
在一些情况下，第一担保人是为数字文档的申请人提供服务的离岸银行，受益人的代表是为受益人提供服务的在岸银行，并且该预定金额是在满足一个或多个预定条件时通过在岸银行向受益人支付的。
在一些情况下，数字文档还包括指定在岸银行的身份的信息。在一些情况下，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。
在一些情况下，一个或多个零知识证明中的至少一个是基于同态加密生成的。在一些情况下，一个或多个零知识证明包括范围证明和/或零测试。
在一些情况下，密文是使用基于线性秘密共享方案导出的加密密钥来加密的。在一些情况下，保函是由第一担保人和第二担保人向受益人作出的，保函的形式为SBLC，并且保函指定在满足执行保函的一个或多个预定条件时，第一担保人和第二担保人应向受益人支付预定金额。在一些情况下，共识算法基于Pow、PoS和PBFT中的一种。
在替代实施例中，处理1900包括，接收指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证一个或多个零知识证明；在成功验证了一个或多个零知识证明后，基于执行共识算法将密文存储到区块链中；从与受益人或受益人的代表相关联的第一计算设备接收针对保函的提款请求；基于执行共识算法将提款请求存储到区块链中；将关于提款请求的第一消息传递给与第一担保人相关联的第二计算设备；从与第一担保人相关联的第二计算设备接收第二消息，其中，该第二消息包括指示第一担保人不同意根据保函向受益人付款的拒付通知；基于执行共识算法将拒付通知存储在区块链中；将第三消息传递给与受益人或受益人的代表相关联的第一计算设备，其中，该第三消息包括拒付通知；从与受益人或受益人的代表相关联的第一计算设备接收第四消息，该第四消息指示受益人或受益人的代表已接收到拒付通知，以及更新存储在区块链中的保函的状态，以指示提款请求已结束。
图20是根据本文实施例的装置2000的模块的又一示例的示图。装置2000可以是区块链的实施例的示例。装置2000可以对应于上述实施例，并且装置2000包括以下：接收模块2002，用于接收指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证模块2004，用于验证一个或多个零知识证明；存储模块2006，用于在成功验证了一个或多个零知识证明后，区块链节点基于执行共识算法将密文存储到区块链中；接收模块2002从与受益人或受益人的代表相关联的第一计算设备接收针对保函的提款请求；存储模块2006基于执行共识算法将提款请求存储到区块链中；传递模块2008，用于将关于提款请求的第一消息传递给与第一担保人相关联的第二计算设备；接收模块2002从与第一担保人相关联的第二计算设备接收第二消息，该第二消息指示第一担保人同意根据保函向受益人付款；更新模块2010，用于更新存储在区块链中的保函的状态，以指示第一担保人已处理了针对保函的提款请求；传递模块2008将第三消息传递给与受益人或受益人的代表相关联的第一计算设备，该第三消息指示第一担保人同意根据保函向受益人付款；接收模块2002从与受益人或受益人的代表相关联的第一计算设备接收第四消息，该第四消息指示受益人已接收到来自第一担保人的付款；以及更新模块2010更新存储在区块链中的保函的状态，以指示受益人已接收到针对保函的付款。
在可选实施例中，保函的形式为SBLC。在可选实施例中，保函指定当满足执行保函的一个或多个预定条件时，担保人应向受益人支付预定金额。
在可选实施例中，第一担保人是为数字文档的申请人提供服务的离岸银行，受益人的代表是为受益人提供服务的在岸银行，并且该预定金额是在满足一个或多个预定条件时通过在岸银行向受益人支付的。
在可选实施例中，数字文档还包括指定在岸银行的身份的信息。在可选实施例中，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。
在可选实施例中，一个或多个零知识证明中的至少一个是基于同态加密生成的。在可选实施例中，一个或多个零知识证明包括范围证明和/或零测试。
在可选实施例中，密文是使用基于线性秘密共享方案导出的加密密钥来加密的。在可选实施例中，保函是由第一担保人和第二担保人向受益人作出的，保函的形式为SBLC，并且保函指定在满足执行保函的一个或多个预定条件时，第一担保人和第二担保人应向受益人支付预定金额。在可选实施例中，共识算法基于Pow、PoS和PBFT中的一种。
在替代实施例中，装置2000包括，接收模块2002，用于接收指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证模块2004，用于验证一个或多个零知识证明；存储模块2006，用于在成功验证了一个或多个零知识证明后，基于执行共识算法将密文存储到区块链中；接收模块2002进一步从与受益人或受益人的代表相关联的第一计算设备接收针对保函的提款请求；存储模块2006进一步基于执行共识算法将提款请求存储到区块链中；传递模块2008，用于将关于提款请求的第一消息传递给与第一担保人相关联的第二计算设备；接收模块2002进一步从与第一担保人相关联的第二计算设备接收第二消息，其中，该第二消息包括指示第一担保人不同意根据保函向受益人付款的拒付通知；存储模块2006进一步基于执行共识算法将拒付通知存储在区块链中；传递模块2008进一步将第三消息传递给与受益人或受益人的代表相关联的第一计算设备，其中，该第三消息包括拒付通知；接收模块2002进一步从与受益人或受益人的代表相关联的第一计算设备接收第四消息，该第四消息指示受益人或受益人的代表已接收到拒付通知，以及更新模块2010，用于更新存储在区块链中的保函的状态，以指示提款请求已结束。
图21是根据本文的实施例的处理2100的又一示例的流程图。为方便起见，处理2100将被描述为由区块链节点执行，该区块链节点包括位于一个或多个位置并根据本文被适当地编程的一个或多个计算机的系统。例如，适当编程的计算机系统，例如图1的计算机系统100，可以执行处理2100。
在2102，区块链节点接收指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件。
在2104，区块链节点验证一个或多个零知识证明。在2106，在成功验证了一个或多个零知识证明后，区块链节点基于执行共识算法将密文存储到区块链中。在2108，区块链节点从与受益人或受益人的代表相关联的第一计算设备接收第一消息，该第一消息指示没有针对保函的未支付索款。
在2110，区块链节点向与第一担保人相关联的第二计算设备发送第二消息，以确认第一担保人被解除保函下的付款义务。在2112，区块链节点从与第一担保人相关联的第二计算设备接收第三消息，该第三消息请求将保函的状态更改为已到期。
在2114，区块链节点更新存储在区块链中的保函的状态以指示保函已到期。
在一些情况下，保函的形式为SBLC。在一些情况下，保函指定当满足执行保函的一个或多个预定条件时，至少第一担保人应向受益人支付预定金额。
在一些情况下，第一担保人是为数字文档的申请人提供服务的离岸银行，受益人的代表是为受益人提供服务的在岸银行，并且该预定金额是在满足一个或多个预定条件时通过在岸银行向受益人支付的。在一些情况下，数字文档还包括指定在岸银行的身份的信息。
在一些情况下，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。在一些情况下，一个或多个零知识证明中的至少一个是基于同态加密生成的。
在一些情况下，一个或多个零知识证明包括范围证明和/或零测试。在一些情况下，密文是使用基于线性秘密共享方案导出的加密密钥来加密的。
在一些情况下，保函是由第一担保人和第二担保人向受益人作出的，保函的形式为SBLC，并且保函指定在满足执行保函的一个或多个预定条件时，第一担保人和第二担保人应向受益人支付预定金额。
在一些情况下，共识算法基于Pow、PoS和PBFT中的一种。在一些情况下，处理2100还包括：在接收第一消息之前，从与受益人或受益人的代表相关联的第一计算设备接收第四消息，其中，第四消息包括请求延长保函的有效期限的请求；以及将请求延长保函的有效期限的请求存储在区块链中。
图22是根据本文实施例的装置2200的模块的又一示例的示图。装置2200可以是区块链节点的实施例的示例。装置2200可以对应于上述实施例，并且装置2200包括以下：接收模块2202，用于接收指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证模块2204，用于验证一个或多个零知识证明；存储模块2206，用于在成功验证了一个或多个零知识证明后，基于执行共识算法将密文存储到区块链中；接收模块2202从与受益人或受益人的代表相关联的第一计算设备接收第一消息，该第一消息指示没有针对保函的未支付索款；发送模块2208，用于向与第一担保人相关联的第二计算设备发送第二消息，以确认第一担保人被解除保函下的付款义务；接收模块2202从与第一担保人相关联的第二计算设备接收第三消息，该第三消息请求将保函的状态更改为已到期；以及更新模块2210，用于更新存储在区块链中的保函的状态以指示保函已到期。
在可选实施例中，保函的形式为SBLC。在可选实施例中，保函指定当满足执行保函的一个或多个预定条件时，至少第一担保人应向受益人支付预定金额。
在可选实施例中，第一担保人是为数字文档的申请人提供服务的离岸银行，受益人的代表是为受益人提供服务的在岸银行，并且该预定金额是在满足一个或多个预定条件时通过在岸银行向受益人支付的。
在可选实施例中，数字文档还包括指定在岸银行的身份的信息。在可选实施例中，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。
在可选实施例中，一个或多个零知识证明中的至少一个是基于同态加密生成的。在可选实施例中，一个或多个零知识证明包括范围证明和/或零测试。
在可选实施例中，密文是使用基于线性秘密共享方案导出的加密密钥来加密的。在可选实施例中，保函是由第一担保人和第二担保人向受益人作出的，保函的形式为SBLC，并且保函指定在满足执行保函的一个或多个预定条件时，第一担保人和第二担保人应向受益人支付预定金额。
在可选实施例中，共识算法基于Pow、PoS和PBFT中的一种。在可选实施例中，装置2200还包括接收子模块，用于在接收第一消息之前，从与受益人或受益人的代表相关联的第一计算设备接收第四消息，其中，第四消息包括请求延长保函的有效期限的请求；以及存储子模块，用于将请求延长保函的有效期限的请求存储在区块链中。
图23是根据本文的实施例的处理2200的又一示例的流程图。为方便起见，处理2300将被描述为由区块链节点执行，该区块链节点包括位于一个或多个位置并根据本文被适当地编程的一个或多个计算机的系统。例如，适当编程的计算机系统，例如图1的计算机系统100，可以执行处理2300。
在2302，区块链节点接收来自与至少第一担保人相关联的第一计算设备的指定保函的第一数字文档的第一密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件。
在2304，区块链节点验证一个或多个零知识证明是正确的。在2306，在验证了一个或多个零知识证明是正确的之后，区块链节点基于执行共识算法将第一密文存储到区块链中。
在2308，区块链节点从与受益人或受益人的代表相关联的第二计算设备接收第一消息，该第一消息包括用以修改保函的请求。在2310，区块链节点向第一计算设备发送与用以修改保函的请求有关的第二消息。
在2312，区块链节点从第一计算设备接收指定保函的第二数字文档的第二密文，该第二数字文档表示第一数字文档的修改版本，其中，所述修改是基于所述请求进行的。
在一些情况下，处理2300还包括：基于执行共识算法，将第二密文存储到区块链；从第二计算设备接收指示接受第二数字文档中指定的保函的第三消息；修改第二密文以更新保函的状态，从而指示受益人已接受了保函。
在一些情况下，保函的形式为SBLC。在一些情况下，保函指定当满足执行保函的一个或多个预定条件时，至少第一担保人应向受益人支付预定金额。
在一些情况下，用以修改保函的请求是将预定金额修改为减少后的金额的请求，该减少后的金额等于预定金额减去已支付给受益人的付款金额，并且第一数字文档的修改版本包括减少后的金额。
在一些情况下，第一消息还包括与减少后的金额相关联的零知识证明，并且响应于成功验证了包括在第一消息中的零知识证明，执行第二密文的存储。
在一些情况下，担保人是为第一数字文档的申请人提供服务的离岸银行，并且该预定金额是在满足一个或多个预定条件时，通过为受益人提供服务的在岸银行向受益人支付的。
在一些情况下，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。在一些情况下，一个或多个零知识证明中的至少一个是基于同态加密生成的。
在一些情况下，一个或多个零知识证明包括范围证明和/或零测试。在一些情况下，用于对数字文档进行加密的加密密钥是基于线性秘密共享方案来导出的。
在一些情况下，保函是由第一担保人和第二担保人向受益人作出的，保函的形式为SBLC，并且保函指定在满足执行保函的一个或多个预定条件时，第一担保人和第二担保人应向受益人支付预定金额。
图24是根据本文的实施例的装置2400的模块的又一示例的示图。装置2400可以是区块链节点的实施例的示例。装置2400可以对应于上述实施例，并且装置2400包括以下：接收模块2402，用于接收来自与至少第一担保人相关联的第一计算设备的指定保函的第一数字文档的第一密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证模块2404，用于验证一个或多个零知识证明是正确的；存储模块2406，用于在验证了一个或多个零知识证明是正确的之后，基于执行共识算法将第一密文存储到区块链中；接收模块2402进一步从与受益人或受益人的代表相关联的第二计算设备接收第一消息，该第一消息包括用以修改保函的请求；发送模块2408，用于向第一计算设备发送与用以修改保函的请求有关的第二消息；接收模块2402进一步从第一计算设备接收指定保函的第二数字文档的第二密文，该第二数字文档表示第一数字文档的修改版本，其中，所述修改是基于所述请求进行的。
在可选实施例中，装置2400还包括，存储模块2406基于执行共识算法来将第二密文存储到区块链；接收模块2402从第二计算设备接收指示接受第二数字文档中指定的保函的第三消息；以及修改第二密文以更新保函的状态，从而指示受益人已接受了保函。
在可选实施例中，保函的形式为SBLC。在可选实施例中，保函指定当满足执行保函的一个或多个预定条件时，至少第一担保人应向受益人支付预定金额。
在可选实施例中，用以修改保函的请求是将预定金额修改为减少后的金额的请求，该减少后的金额等于预定金额减去已支付给受益人的付款金额，并且第一数字文档的修改版本包括减少后的金额。
在可选实施例中，第一消息还包括与减少后的金额相关联的零知识证明，并且响应于成功验证了包括在第一消息中的零知识证明，执行第二密文的存储。
在可选实施例中，担保人是为第一数字文档的申请人提供服务的离岸银行，并且该预定金额是在满足一个或多个预定条件时，通过为受益人提供服务的在岸银行向受益人支付的。
在可选实施例中，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。在可选实施例中，一个或多个零知识证明中的至少一个是基于同态加密生成的。
在可选实施例中，一个或多个零知识证明包括范围证明和/或零测试。在可选实施例中，用于对数字文档进行加密的加密密钥是基于线性秘密共享方案来导出的。
在可选实施例中，保函是由第一担保人和第二担保人向受益人作出的，保函的形式为SBLC，并且保函指定在满足执行保函的一个或多个预定条件时，第一担保人和第二担保人应向受益人支付预定金额。
图25是根据本文的实施例的装置2500的又一示例的流程图。为方便起见，处理2500将被描述为由区块链节点执行，该区块链节点包括位于一个或多个位置并根据本文被适当地编程的一个或多个计算机的系统。例如，适当编程的计算机系统，例如图1的计算机系统100，可以执行处理2500。
在2502，区块链节点接收来自与至少第一担保人相关联的第一计算设备的指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件。
在2504，区块链节点验证一个或多个零知识证明是正确的。在2506，在验证了一个或多个零知识证明是正确的之后，区块链节点基于执行共识算法将密文存储到区块链中。
在2508，区块链节点从与至少第一担保人相关联的第一计算设备接收第一消息，该第一消息包括用以撤销保函的请求。在2510，区块链节点将用以撤销保函的请求存储在区块链中。
在2512，区块链节点向与受益人或受益人的代表相关联的第二计算设备发送第二消息，其中，第二消息包括用以撤销保函的请求。
在2514，区块链节点从与受益人或受益人的代表相关联的第二计算设备接收第三消息，其中，第三消息包括受益人接受撤销保函的确认。在2516，区块链节点更新存储在区块链中的保函的状态，以指示保函已撤销。
在一些情况下，保函的形式为SBLC。在一些情况下，保函指定当满足执行保函的一个或多个预定条件时，至少第一担保人应向受益人支付预定金额。
在一些情况下，第一担保人是为保函的申请人提供服务的离岸银行，并且该预定金额是在满足一个或多个预定条件时，通过为受益人提供服务的在岸银行向受益人支付的。
在一些情况下，数字文档还包括指定在岸银行的身份的信息。在一些情况下，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。
在一些情况下，一个或多个零知识证明中的至少一个是基于同态加密生成的。在一些情况下，一个或多个零知识证明包括范围证明和/或零测试。
在一些情况下，用于对数字文档进行加密的加密密钥是基于线性秘密共享方案来导出的。在一些情况下，保函是由第一担保人和第二担保人向受益人作出的，保函的形式为SBLC，并且保函指定在满足执行保函的一个或多个预定条件时，第一担保人和第二担保人应向受益人支付预定金额。在一些情况下，共识算法基于Pow、PoS和PBFT中的一种。
图26是根据本文的实施例的装置2600的模块的又一示例的示图。装置2600可以是区块链的实施例的示例。装置2600可以对应于上述实施例，并且装置2600包括以下：接收模块2602，用于接收来自与至少第一担保人相关联的第一计算设备的指定保函的数字文档的密文，以及与关联于保函的一个或多个值有关的一个或多个零知识证明，其中，保函是由至少第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；验证模块2604，用于验证一个或多个零知识证明是正确的；存储模块2606，用于在验证了一个或多个零知识证明是正确的之后，基于执行共识算法将密文存储到区块链中；接收模块2602从与至少第一担保人相关联的第一计算设备接收第一消息，该第一消息包括用以撤销保函的请求；存储模块2606将用以撤销保函的请求存储在区块链中；发送模块2608，用于向与受益人或受益人的代表相关联的第二计算设备发送第二消息，其中，第二消息包括用以撤销保函的请求；接收模块2602从与受益人或受益人的代表相关联的第二计算设备接收第三消息，其中，第三消息包括受益人接受撤销保函的确认；更新模块2610，用于更新存储在区块链中的保函的状态，以指示保函已撤销。
在可选实施例中，保函的形式为SBLC。在可选实施例中，保函指定当满足执行保函的一个或多个预定条件时，至少第一担保人应向受益人支付预定金额。
在可选实施例中，第一担保人是为保函的申请人提供服务的离岸银行，并且该预定金额是在满足一个或多个预定条件时，通过为受益人提供服务的在岸银行向受益人支付的。
在可选实施例中，该数字文档还包括指定在岸银行的身份的信息。在可选实施例中，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。
在可选实施例中，一个或多个零知识证明中的至少一个是基于同态加密生成的。在可选实施例中，一个或多个零知识证明包括范围证明和/或零测试。
在可选实施例中，用于对数字文档进行加密的加密密钥是基于线性秘密共享方案来导出的。在可选实施例中，保函是由第一担保人和第二担保人向受益人作出的，保函的形式为SBLC，并且保函指定在满足执行保函的一个或多个预定条件时，第一担保人和第二担保人应向受益人支付预定金额。在可选实施例中，共识算法基于Pow、PoS和PBFT中的一种。
图27是根据本文的实施例的装置2700的模块的又一示例的流程图。为方便起见，处理2700将被描述为由区块链节点执行，该区块链节点包括位于一个或多个位置并根据本文被适当地编程的一个或多个计算机的系统。例如，适当编程的计算机系统，例如图1的计算机系统100，可以执行处理2700。
在2702，第一区块链网络中的区块链节点接收用于将数字文档的密文中继到第二区块链网络的跨链请求，其中，该跨链请求是从与第一担保人相关联的第一计算设备发送的，该数字文档指定来自第一担保人的保函和执行保函的一个或多个预定条件，并且保函是第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件。
在2704，区块链节点基于执行共识算法将跨链请求和密文存储到与第一区块链网络相关联的第一区块链中。在2706，区块链节点从第二计算设备接收用于在第一区块链网络和第二区块链网络之间中继信息的消息，该消息包括保函被受益人接受并被存储在与第二区块链网络相关联的第二区块链上的确认。在2708，区块链节点更新保函的状态，以指示保函在第一区块链上已无效。
在一些情况下，处理2700还包括：区块链节点接收与数字文档的密文相关联的一个或多个零知识证明，其中，一个或多个零知识证明与关联于保函的一个或多个值有关；在将密文存储到与第一区块链网络相关联的第一区块链中之前，验证一个或多个零知识证明是正确的。
在一些情况下，第二计算设备是以下中的至少一个(i)第一区块链网络和第二区块链网络中的区块链节点，或者(ii)第三区块链网络中的区块链节点。
在一些情况下，第二计算设备是支持可信执行环境或安全多方计算的可信设备。在一些情况下，更新保函的状态是响应于从第一计算设备接收到用以使保函无效的请求而执行的。
在一些情况下，保函的形式为SBLC。在一些情况下，保函指定当满足执行保函的一个或多个预定条件时，担保人应向受益人支付预定金额。
在一些情况下，担保人是为申请人提供服务的离岸银行，受益人的代表是为受益人提供服务的在岸银行，并且该预定金额是在满足一个或多个预定条件时通过在岸银行向受益人支付的。
在一些情况下，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。在一些情况下，一个或多个零知识证明包括范围证明和/或零测试，并且一个或多个零知识证明中的至少一个是基于同态加密生成的。在一些情况下，密文是使用基于线性秘密共享方案导出的加密密钥来加密的。
图28是根据本文的实施例的装置2800的模块的又一示例的示图。装置2800可以是区块链的实施例的示例。装置2800可以对应于上述实施例，装置2800包括以下：接收模块2802，用于通过第一区块链网络中的区块链节点接收用于将数字文档的密文中继到第二区块链网络的跨链请求，其中，该跨链请求是从与第一担保人相关联的第一计算设备发送的，该数字文档指定来自第一担保人的保函和执行保函的一个或多个预定条件，并且保函是第一担保人向受益人作出的，并且数字文档指定执行保函的一个或多个预定条件；存储模块2804，用于基于执行共识算法将跨链请求和密文存储到与第一区块链网络相关联的第一区块链中；接收模块2802，从第二计算设备接收用于在第一区块链网络和第二区块链网络之间中继信息的消息，该消息包括保函被受益人接受并被存储在与第二区块链网络相关联的第二区块链上的确认；以及更新模块2806，用于更新保函的状态，以指示保函在第一区块链上已无效。
在可选实施例中，装置2800还包括接收子模块，用于通过区块链节点接收与数字文档的密文相关联的一个或多个零知识证明，其中，一个或多个零知识证明与关联于保函的一个或多个值有关；以及验证子模块，用于在将密文存储到与第一区块链网络相关联的第一区块链中之前，验证一个或多个零知识证明是正确的。
在可选实施例中，第二计算设备是以下中的至少一个(i)第一区块链网络和第二区块链网络中的区块链节点，或者(ii)第三区块链网络中的区块链节点。
在可选实施例中，第二计算设备是支持可信执行环境或安全多方计算的可信设备。在可选实施例中，更新保函的状态是响应于从第一计算设备接收到用以使保函无效的请求而执行的。
在可选实施例中，保函的形式为SBLC。在可选实施例中，保函指定当满足执行保函的一个或多个预定条件时，担保人应向受益人支付预定金额。
在可选实施例中，担保人是为申请人提供服务的离岸银行，受益人的代表是为受益人提供服务的在岸银行，并且该预定金额是在满足一个或多个预定条件时通过在岸银行向受益人支付的。
在可选实施例中，一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。在可选实施例中，一个或多个零知识证明包括范围证明和/或零测试，并且一个或多个零知识证明中的至少一个是基于同态加密生成的。在可选实施例中，密文是使用基于线性秘密共享方案导出的加密密钥来加密的。
前述实施例中示出的系统、装置、模块或单元可以通过使用计算机芯片或实体来实施，或者可以通过使用具有特定功能的产品来实施。典型的实施例设备是计算机，计算机可以是个人计算机、膝上型计算机、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件收发设备、游戏控制台、平板计算机、可穿戴设备或这些设备的任意组合。
对于装置中每个模块的功能和作用的实施例处理，可以参考前一方法中相应步骤的实施例处理。为简单起见，这里省略了细节。
由于装置实施基本上对应于方法实施，对于相关部件，可以参考方法实施中的相关描述。先前描述的装置实施仅是示例。被描述为单独部分的模块可以或不是物理上分离的，并且显示为模块的部分可以是或不是物理模块，可以位于一个位置，或者可以分布在多个网络模块上。可以基于实际需求来选择一些或所有模块，以实现本文方案的目标。本领域的普通技术人员无需付出创造性劳动就能理解和实现本申请的实施例。
再次参考图16、18、20、22、24、26和28，它们可以被解释为示出了计算机系统或区块链节点的内部功能模块和结构。执行主体本质上可以是电子设备，并且该电子设备包括以下：一个或多个处理器；以及被配置为存储一个或多个处理器的可执行指令的一个或多个计算机可读存储器。在一些实施例中，一个或多个计算机可读存储器耦接至一个或多个处理器且其上存储有编程指令，所述编程指令能够由所述一个或多个处理器执行以执行如本文中所述的算法、方法、函数、处理、流程和程序。本文还提供了一个或多个非暂态计算机可读存储介质，其耦接到一个或多个处理器并且具有存储在其上的指令，当由一个或多个处理器执行时，该指令使得一个或多个处理器根据这里提供的方法的实施例执行操作。
本文还提供了用于实现本文提供的方法的系统。该系统包括一个或多个处理器，以及耦接到一个或多个处理器的计算机可读存储介质，其上存储有指令，当由一个或多个处理器执行时，该指令使得一个或多个处理器根据这里提供的方法的实施例执行操作。
本文中描述的主题、动作和操作的实施可以在数字电子电路、有形体现的计算机软件或固件、计算机硬件中实施，包括本文中公开的结构及其结构等同物，或者它们中的一个或多个的组合。本文中描述的主题的实施可以实现为一个或多个计算机程序，例如，编码在计算机程序载体上的一个或多个计算机程序指令模块，用于由数据处理装置执行或控制数据处理装置的操作。例如，计算机程序载体可以包括一个或多个计算机可读存储介质，其上编码或存储有指令。载体可以是有形的非暂态计算机可读介质，诸如磁盘、磁光盘或光盘、固态驱动器、随机存取存储器(RAM)、只读存储器(ROM)或其他类型的介质。可选地或附加地，载体可以是人工生成的传播信号，例如，机器生成的电信号、光信号或电磁信号，其被生成来编码信息用于传输到合适的接收器装置以供数据处理装置执行。计算机存储介质可以是或可以部分是机器可读存储设备、机器可读存储基板、随机或串行访问存储器设备或它们中的一个或多个的组合。计算机存储介质不是传播信号。
计算机程序，也可以被称为或描述为程序、软件、软件应用程序、app、模块、软件模块、引擎、脚本或代码，可以以任何形式的编程语言编写，包括编译或解释性语言、或声明或程序性语言；它可以配置为任何形式，包括作为独立程序，或作为模块、组件、引擎、子程序或适合在计算环境中执行的其他单元，该环境可包括由数据通信网络互连的一个或多个位置上的一台或多台计算机。
计算机程序可以但非必须对应于文件系统中的文件。计算机程序可以存储在：保存其他程序或数据的文件的一部分中，例如，存储在标记语言文档中的一个或多个脚本；专用于所讨论的程序的单个文件中；或者多个协调文件中，例如，存储一个或多个模块、子程序或代码部分的多个文件。
用于执行计算机程序的处理器包括：例如，通用和专用微处理器两者，和任意种类的数字计算机的任意一个或多个处理器。通常，处理器将接收用于执行的计算机程序的指令以及来自耦接至处理器的非暂态计算机可读介质的数据。
术语“数据处理装置”包括用于处理数据的所有种类的装置、设备和机器，例如包括可编程处理器、计算机或多个处理器或计算机。数据处理设备可以包括例如FPGA(现场可编程门阵列)，ASIC(专用集成电路)或GPU(图形处理单元)的专用逻辑电路。除了硬件，该装置还可以包括为计算机程序创建执行环境的代码，例如，构成处理器固件、协议栈、数据库管理系统、操作系统或者它们中一个或多个的组合的代码。
本文中描述的处理和逻辑流程可以由执行一个或多个计算机程序的一台或多台计算机或处理器执行，以通过对输入数据进行操作并生成输出来执行操作。处理和逻辑流程也可以由例如FPGA、ASIC或GPU等的专用逻辑电路或专用逻辑电路与一个或多个编程计算机的组合来执行。
适合于执行计算机程序的计算机可以基于通用和/或专用微处理器，或任何其他种类的中央处理单元。通常，中央处理单元将从只读存储器和/或随机存取存储器接收指令和数据。计算机的元件可包括用于执行指令的中央处理单元和用于存储指令和数据的一个或多个存储设备。中央处理单元和存储器可以补充有专用逻辑电路或集成在专用逻辑电路中。
通常，计算机还将包括或可操作地耦接至一个或多个存储设备，以从一个或多个存储设备接收数据或向一个或多个存储设备传送数据。大容量存储设备可以是例如，磁盘、磁光盘或光盘、固态驱动器或任何其他类型的非暂态计算机可读介质。但是，计算机不必需这样的设备。因此，计算机可以耦接到例如一个或多个存储器的本地和/或远程的一个或多个大容量存储设备。例如，计算机可以包括作为计算机的组成部件的一个或多个本地存储器，或者计算机可以耦接到云网络中的一个或多个远程存储器。此外，计算机可以嵌入在另一设备中，例如移动电话、个人数字助理(PDA)、移动音频或视频播放器、游戏控制台、全球定位系统(GPS)接收器或例如通用串行总线(USB)闪存驱动器的便携式存储设备，这里仅举几例。
组件可以通过直接或经由一个或多个中间件例如电连接或光连接地彼此连接通信而彼此“耦接”。如果部件中的一个部件被集成到另一个中，则部件也可以被彼此“耦接”。例如，集成到处理器中的大容量存储组件(例如，L2高速缓存组件)被“耦接到”处理器。
为了提供与用户的交互，本文中描述的主题的实施例可以在计算机上实现或配置为与该计算机通信，该计算机具有：显示设备，例如，LCD(液晶显示器)监视器，用于向用户显示信息；以及输入设备，用户可以通过该输入设备向计算机提供输入，例如键盘和例如鼠标、轨迹球或触摸板等的指针设备。其他类型的设备也可用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的感官反馈，例如视觉反馈、听觉反馈或触觉反馈；并且可以接收来自用户任何形式的输入，包括声音、语音输入或触觉输入。此外，计算机可以通过向用户使用的设备发送文档和从用户使用的设备接收文档来与用户交互；例如，通过向用户设备上的web浏览器发送web页面以响应从web浏览器收到的请求，或者通过与例如智能电话或电子平板电脑等的用户设备上运行的应用程序(app)进行交互。此外，计算机可以通过向个人设备(例如，运行消息传送应用程序的智能电话)轮流发送文本消息或其他形式的消息来并且从用户接收响应消息来与用户交互。
本文使用与系统、装置和计算机程序组件有关的术语“配置为”。对于被配置为执行特定操作或动作的一个或多个计算机的系统，意味着系统已在其上安装了在运行中促使该系统执行所述操作或动作的软件、固件、硬件或它们的组合。对于被配置为执行特定操作或动作的一个或多个计算机程序，意味着一个或多个程序包括当被数据处理装置执行时促使该装置执行所述操作或动作的指令。对于被配置为执行特定操作或动作的专用逻辑电路，意味着该电路具有执行所述操作或动作的电子逻辑。
虽然本文包含许多具体实施细节，但是这些细节不应被解释为由权利要求本身限定的对要求保护的范围的限制，而是作为对特定实施例的具体特征的描述。在本文中单个实施例的上下文中描述的多个特征也可以在单个实施例中组合实现。相反，在单个实施方式的上下文中描述的各种特征也可以单独地或以任何合适的子组合在多个实施方式中实现。此外，尽管上面的特征可以描述为以某些组合起作用并且甚至最初如此要求保护，但是在一些情况下可以从要求保护的组合中删除该组合的一个或多个特征，并且可以要求保护指向子组合或子组合的变体。
类似地，虽然以特定顺序在附图中描绘了操作并且在权利要求中叙述了操作，但是这不应该被理解为：为了达到期望的结果，要求以所示的特定顺序或依次执行这些操作，或者要求执行所有示出的操作。在某些情况下，多任务和并行处理可能是有利的。此外，上述实施例中的各种系统模块和组件的划分不应被理解为在所有实施例中都要求如此划分，而应当理解，所描述的程序组件和系统通常可以一起集成在单个软件产品中或打包成多个软件产品。
已描述了主题的特定实施方式。其他实施方式在以下权利要求的范围内。例如，权利要求中记载的动作可以以不同的顺序执行并且仍然实现所期望的结果。作为一个示例，附图中描绘的过程无需要求所示的特定顺序或次序来实现期望的结果。在一些情况下，多任务和并行处理可能是有利的。

Claims (14)

1.一种计算机实现的由区块链网络中的区块链节点执行的方法，包括：
接收指定保函的数字文档的密文，以及与关联于所述保函的一个或多个值有关的一个或多个零知识证明ZKP，其中，所述保函是由至少第一担保人向受益人作出的，并且所述数字文档指定执行所述保函的一个或多个预定条件；
验证所述一个或多个零知识证明；
在成功验证了所述一个或多个零知识证明后，基于执行共识算法将所述密文存储到区块链中；
从与所述受益人或所述受益人的代表相关联的第一计算设备接收第一消息，所述第一消息指示没有针对所述保函的未支付索款；
向与所述第一担保人相关联的第二计算设备发送第二消息，以确认所述第一担保人被解除所述保函下的付款义务；
从与所述第一担保人相关联的所述第二计算设备接收第三消息，所述第三消息请求将所述保函的状态更改为已到期；以及
更新存储在所述区块链中的所述保函的状态，以指示所述保函已到期。
2.如权利要求1所述的方法，其中，所述保函的形式为备用信用证SBLC。
3.如权利要求2所述的方法，其中，所述保函指定当满足执行所述保函的所述一个或多个预定条件时，所述至少第一担保人应向所述受益人支付预定金额。
4.如权利要求3所述的方法，其中，所述第一担保人是为所述数字文档的申请人提供服务的离岸银行，所述受益人的代表是为所述受益人提供服务的在岸银行，并且所述预定金额是在满足所述一个或多个预定条件时，通过所述在岸银行向所述受益人支付的。
5.如权利要求4所述的方法，其中，所述数字文档还包括指定所述在岸银行的身份的信息。
6.如权利要求1-5中任一项权利要求所述的方法，其中，所述一个或多个预定条件包括违约条件、修订条件、撤销条件、生效日期和到期日期中的一个或多个。
7.如权利要求1-5中任一项权利要求所述的方法，其中，所述一个或多个零知识证明中的至少一个是基于同态加密生成的。
8.如权利要求1-5中任一项权利要求所述的方法，其中，所述一个或多个零知识证明包括范围证明和/或零测试。
9.如权利要求1-5中任一项权利要求所述的方法，其中，所述密文是使用基于线性秘密共享方案导出的加密密钥来加密的。
10.如权利要求1所述的方法，其中，所述保函是由所述第一担保人和第二担保人向所述受益人作出的，所述保函的形式为备用信用证SBLC，并且所述保函指定在满足执行所述保函的所述一个或多个预定条件时，所述第一担保人和所述第二担保人应向所述受益人支付预定金额。
11.如权利要求1-5、10中任一项权利要求所述的方法，其中，所述共识算法基于工作量证明PoW、权益证明PoS和实用拜占庭容错PBFT之一。
12.如权利要求1-5、10中任一项权利要求所述的方法，包括：
在接收所述第一消息之前，从与所述受益人或所述受益人的代表相关联的第一计算设备接收第四消息，其中，所述第四消息包括请求延长所述保函的有效期限的请求；以及
将请求延长所述保函的有效期限的请求存储在所述区块链中。
13.一种用于处理基于区块链的保函信息的系统，包括：
一个或多个处理器；以及
耦接到所述一个或多个处理器并且其上存储有指令的一个或多个计算机可读存储器，所述指令能够由所述一个或多个处理器执行以执行权利要求1至12中任一项所述的方法。
14.一种用于处理基于区块链的保函信息的装置，所述装置包括用于执行权利要求1至12中任一项所述的方法的多个模块。
CN202080000560.0A 2020-02-03 2020-02-03 基于区块链的可信保函 Active CN111433799B (zh)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2020/074247 WO2020098837A2 (en) 2020-02-03 2020-02-03 Blockchain-based trustable guarantees

Publications (2)

Publication Number Publication Date
CN111433799A CN111433799A (zh) 2020-07-17
CN111433799B true CN111433799B (zh) 2022-03-25

Family

ID=70733034

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202080000560.0A Active CN111433799B (zh) 2020-02-03 2020-02-03 基于区块链的可信保函

Country Status (5)

Country Link
US (1) US11200570B2 (zh)
EP (1) EP3794483A4 (zh)
CN (1) CN111433799B (zh)
SG (1) SG11202012924WA (zh)
WO (1) WO2020098837A2 (zh)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210314293A1 (en) * 2020-04-02 2021-10-07 Hewlett Packard Enterprise Development Lp Method and system for using tunnel extensible authentication protocol (teap) for self-sovereign identity based authentication
CN117795903A (zh) * 2021-03-12 2024-03-29 迈克尔·艾拉·卡诺维茨 基于区块链的数据的认证修改
CN113515781B (zh) * 2021-06-07 2022-10-28 厦门国际银行股份有限公司 一种电子保函验真方法及装置
CN114239025A (zh) * 2021-12-20 2022-03-25 深圳前海微众银行股份有限公司 基于区块链的数据处理方法及设备
CN116388965A (zh) * 2021-12-23 2023-07-04 华为技术有限公司 一种可信证明方法及通信装置

Family Cites Families (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6012925A (en) * 1996-07-09 2000-01-11 Kelly; James B. Method for guaranteeing remuneration received by the owner when selling cattle
JP2003518683A (ja) 1999-12-24 2003-06-10 ラヴェンパック アクチェンゲゼルシャフト ユーザにデータを提示する方法および装置
US20040064402A1 (en) * 2002-09-27 2004-04-01 Wells Fargo Home Mortgage, Inc. Method of refinancing a mortgage loan and a closing package for same
JP2010503252A (ja) 2006-08-31 2010-01-28 インターナショナル・ビジネス・マシーンズ・コーポレーション コンピューティング・プラットフォームの証明
US8548829B1 (en) * 2008-02-22 2013-10-01 David Eichenblatt System and method for loan guarantee insurance
US20160203556A1 (en) * 2014-01-09 2016-07-14 Arthur Lipper, III Minimum outcome assurance contracts from revenue sharing of royalties
US10693658B2 (en) 2016-02-12 2020-06-23 Visa International Service Association Methods and systems for using digital signatures to create trusted digital asset transfers
US10055384B2 (en) * 2016-12-31 2018-08-21 Entefy Inc. Advanced zero-knowledge document processing and synchronization
US20180218176A1 (en) * 2017-01-30 2018-08-02 SALT Lending Holdings, Inc. System and method of creating an asset based automated secure agreement
WO2018152519A1 (en) * 2017-02-20 2018-08-23 AlphaPoint Performance of distributed system functions using a trusted execution environment
US11037118B2 (en) * 2017-04-28 2021-06-15 International Business Machines Corporation Zero knowledge third party guarantee of service on decentralized computing platform
CN107392608B (zh) 2017-07-11 2020-07-07 北京博晨技术有限公司 基于区块链系统的数字资产交易方法及区块链系统
US20190205898A1 (en) 2017-07-31 2019-07-04 Chronicled, Inc Decentralized confidential transfer system, method and device
US10460283B2 (en) * 2017-09-13 2019-10-29 Vijay Madisetti Smart contract optimization for multiparty service or product ordering system
US20190102850A1 (en) * 2017-09-29 2019-04-04 David McMakin Wheeler Smart city commodity exchange with smart contracts
CN108288159A (zh) 2018-03-07 2018-07-17 物数（上海）信息科技有限公司 基于多区块链的跨链交易方法、系统、设备及存储介质
US11669914B2 (en) * 2018-05-06 2023-06-06 Strong Force TX Portfolio 2018, LLC Adaptive intelligence and shared infrastructure lending transaction enablement platform responsive to crowd sourced information
US20200074415A1 (en) * 2018-06-18 2020-03-05 Baton Systems, Inc. Collateral optimization systems and methods
CN109242675B (zh) 2018-07-27 2021-09-24 创新先进技术有限公司 基于区块链的资产发布方法及装置、电子设备
CN109035029A (zh) * 2018-07-27 2018-12-18 阿里巴巴集团控股有限公司 基于区块链的资产转移方法及装置、电子设备
CN109377215B (zh) * 2018-08-06 2020-04-21 阿里巴巴集团控股有限公司 区块链交易方法及装置、电子设备
CN109102295A (zh) * 2018-08-31 2018-12-28 深圳市有钱科技有限公司 一种商誉使用权转让系统
US20200126075A1 (en) * 2018-10-18 2020-04-23 Temujin Labs, Inc. Confidential transaction auditing using an authenticated data structure
CN109558517B (zh) 2018-10-24 2023-02-03 中山大学 一种基于区块链的多方安全选举系统
US20200143337A1 (en) * 2018-11-02 2020-05-07 Figure Technologies, Inc. Secure computer network-based platform
KR102180991B1 (ko) 2018-11-07 2020-12-17 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. 블록 체인 기밀 거래의 규제
BR112019008151A2 (pt) 2018-11-07 2019-09-10 Alibaba Group Holding Ltd método implementado por computador, meio de armazenamento legível por computador não transitório e sistema
AU2018347190B2 (en) * 2018-11-07 2020-10-22 Advanced New Technologies Co., Ltd. Blockchain data protection based on account note model with zero-knowledge proof
EP3545483B1 (en) 2018-11-07 2021-04-28 Advanced New Technologies Co., Ltd. Blockchain data protection using homomorphic encryption
CN110035046B (zh) 2018-11-16 2020-02-21 阿里巴巴集团控股有限公司 跨区块链的交互系统
CN109614820A (zh) 2018-12-06 2019-04-12 山东大学 基于零知识证明的智能合约认证数据隐私保护方法
CN109903026A (zh) 2018-12-14 2019-06-18 阿里巴巴集团控股有限公司 基于区块链的事件处理方法及装置、电子设备
EP3566197B1 (en) * 2018-12-21 2022-03-30 Advanced New Technologies Co., Ltd. Blockchain data protection based on generic account model and homomorphic encryption
CA3057385C (en) 2019-03-01 2023-02-14 Alibaba Group Holding Limited Methods and devices for protecting sensitive data of transaction activity based on smart contract in blockchain
KR102247658B1 (ko) 2019-04-03 2021-05-06 어드밴스드 뉴 테크놀로지스 씨오., 엘티디. 신뢰 실행 환경에서 실행되는 스마트 계약 동작에 기초한 블록체인 데이터의 프로세싱
CN110033272A (zh) * 2019-04-03 2019-07-19 中国工商银行股份有限公司 基于区块链的保函数据处理方法、设备以及系统
US20200327608A1 (en) * 2019-04-09 2020-10-15 Jern Ern Chuah Proximity Based Engagement Apparatus, System, and Method
CN110311790B (zh) 2019-06-28 2020-07-28 阿里巴巴集团控股有限公司 一种跨链发送可认证消息的方法和装置
EP3688930B1 (en) 2019-07-02 2021-10-20 Advanced New Technologies Co., Ltd. System and method for issuing verifiable claims
CN116910726A (zh) 2019-07-02 2023-10-20 创新先进技术有限公司 用于将去中心化标识映射到真实实体的系统和方法
CN110428249A (zh) 2019-07-25 2019-11-08 重庆邮电大学 一种基于零知识证明的侧链小额支付系统
CN110428334A (zh) 2019-08-09 2019-11-08 中国工商银行股份有限公司 基于区块链网络的票据处理方法及装置
CN110609846B (zh) * 2019-09-19 2024-04-26 腾讯科技（深圳）有限公司 基于区块链的履约保函处理方法、装置和计算机设备
CN110650189B (zh) 2019-09-20 2022-01-18 深圳供电局有限公司 一种基于中继的区块链的交互系统及方法
CN110795501A (zh) 2019-10-11 2020-02-14 支付宝(杭州)信息技术有限公司 基于区块链的可验证声明的创建方法、装置、设备及系统
CN110995420A (zh) 2019-11-27 2020-04-10 支付宝(杭州)信息技术有限公司 一种数据处理方法和系统

Also Published As

Publication number Publication date
EP3794483A4 (en) 2021-04-28
EP3794483A2 (en) 2021-03-24
SG11202012924WA (en) 2021-01-28
US11200570B2 (en) 2021-12-14
WO2020098837A3 (en) 2020-12-17
WO2020098837A9 (en) 2022-03-31
US20210117971A1 (en) 2021-04-22
CN111433799A (zh) 2020-07-17
WO2020098837A2 (en) 2020-05-22

Similar Documents

Publication Publication Date Title
CN111373431B (zh) 基于区块链的可信保函
CN111418184B (zh) 基于区块链的可信保函
CN111357026B (zh) 基于区块链的可信保函
CN111417945B (zh) 基于区块链的可信保函
CN111433799B (zh) 基于区块链的可信保函
CN111433798B (zh) 基于区块链的可信保函
CN113826134B (zh) 基于区块链的可信保函

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40033813

Country of ref document: HK

GR01 Patent grant
GR01 Patent grant
TR01 Transfer of patent right

Effective date of registration: 20240918

Address after: Room 803, floor 8, No. 618 Wai Road, Huangpu District, Shanghai 200010

Patentee after: Ant blockchain Technology (Shanghai) Co.,Ltd.

Country or region after: China

Address before: 310000 801-11 section B, 8th floor, 556 Xixi Road, Xihu District, Hangzhou City, Zhejiang Province

Patentee before: Alipay (Hangzhou) Information Technology Co.,Ltd.

Country or region before: China