WO2019174430A1 - 区块链数据处理方法、管理端、用户端、转换装置及介质 - Google Patents

区块链数据处理方法、管理端、用户端、转换装置及介质 Download PDF

Info

Publication number
WO2019174430A1
WO2019174430A1 PCT/CN2019/074440 CN2019074440W WO2019174430A1 WO 2019174430 A1 WO2019174430 A1 WO 2019174430A1 CN 2019074440 W CN2019074440 W CN 2019074440W WO 2019174430 A1 WO2019174430 A1 WO 2019174430A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
address
data
chain
user
Prior art date
Application number
PCT/CN2019/074440
Other languages
English (en)
French (fr)
Inventor
郑杰骞
Original Assignee
郑杰骞
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
Priority claimed from CN201810210284.5A external-priority patent/CN108416578A/zh
Priority claimed from CN201810411150.XA external-priority patent/CN108647964B/zh
Application filed by 郑杰骞 filed Critical 郑杰骞
Priority to JP2020562824A priority Critical patent/JP2021512569A/ja
Priority to KR1020207022809A priority patent/KR20200108024A/ko
Priority to SG11202006981QA priority patent/SG11202006981QA/en
Priority to EP19766756.1A priority patent/EP3731162A1/en
Priority to AU2019232978A priority patent/AU2019232978A1/en
Priority to US16/965,788 priority patent/US20210042744A1/en
Priority to CA3088712A priority patent/CA3088712A1/en
Priority to BR112020016151-9A priority patent/BR112020016151A2/pt
Publication of WO2019174430A1 publication Critical patent/WO2019174430A1/zh

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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/901—Indexing; Data structures therefor; Storage structures
    • G06F16/9024—Graphs; Linked lists
    • 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/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • 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/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • 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
    • 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
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
    • 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/3247—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 involving digital 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
    • G06Q2220/00—Business processing using cryptography
    • 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

Definitions

  • the invention relates to, but is not limited to, the field of computer data processing technology, in particular to a blockchain data processing method, a management device, a client device, a conversion device, and a computer readable storage medium.
  • an embodiment of the present application provides a data processing method of a management terminal, including:
  • the embodiment of the present application provides a data processing method of a client, including:
  • the embodiment of the present application provides a management device, including a verification module and an endorsement signature module, where:
  • the verification module is configured to verify transaction data
  • the endorsement signature module is configured to perform endorsement signature on the transaction data after the verification module verifies the transaction data, and the transaction data after the endorsement signature is written into the block data of the first chain system;
  • the transaction data includes a transaction address of the transaction receiving end and an address parameter generated during the transaction, and the transaction address is generated by using an address parameter generated when the transaction receiving end receives the transaction last time, and the transaction is generated during the transaction.
  • the address parameter is used to generate a transaction address for receiving the transaction next time by the transaction receiving end, so that all received transaction data of the same transaction receiving end form a logical chain structure.
  • the second address generating module is configured to generate a transaction address of the current transaction according to the address parameter in the last received transaction data
  • the retrieval module is configured to look up transaction data including the transaction address from the second chain system.
  • an embodiment of the present application provides a conversion apparatus, including an initiation module and a signature module, where:
  • the initiating module is configured to initiate a conversion transaction according to the enabling of the management device
  • FIG. 2 is a schematic diagram of a trusted system according to an embodiment of the present application.
  • FIG. 5 is a flowchart of another embodiment of a data processing method of a management terminal according to an embodiment of the present application.
  • Token refers to the token on the blockchain, also known as the pass.
  • the second chain system may further include extended data, where the extended data may be system state data of the second chain system itself, and does not involve the system state of the first chain system, so the first chain system and the first chain system are not affected.
  • the logical state of the two-chain system is different.
  • the management side can generate a system status tree to get the status of any account.
  • the status of the account may include: an account balance, and status information such as an initial address parameter, freezing or thawing; on the second chain, the balance status of the account may be known by accumulating the result of the transaction, and the user in the control data is retrieved.
  • the encrypted information acquires the remaining state; the state of the account obtained by accumulating the transaction result is consistent with the state of the account obtained on the management side.
  • the wallet of the client can automatically verify whether the status of the account acquired on the first chain of the management end is consistent with the status of the account acquired on the external second chain.
  • the data on the private chain of the management side may include a control data set and a transaction data set, and block header data generated by the chain generator consensus algorithm.
  • the control data set is mainly a collection of information data issued by the management terminal for managing and controlling the first chain system, including but not limited to one or more of the following information: registration information of users and institutions, issuance and recycling of tokens, Transaction rules, identity certificates, and updated information (such as updated user information, and/or updated system algorithm keys, etc.), and the like. Except that the user's identity information is ciphertext, most of the rest of the data is in plain text to facilitate effective supervision and protect the user's identity privacy.
  • a transaction data set is a collection of all individual transactions within a time segment.
  • the signature key is generated and managed locally by the client, using non-exportable hardware as a carrier to ensure the secure use of the key.
  • the signature key is used by the CA to issue the user's identity authentication certificate or use the eID mechanism to implement the user's real-name identity authentication.
  • the signature key includes the certificate signature public key and the signature private key.
  • the system may adopt a multi-signature manner, and the user end may use a signature key trusted by a trusted third party in addition to the local signature key, and the key is the identity of the user end. After the authentication certificate or eID is registered on the management terminal, the managed party signs the trusted signing certificate applied by the trusted third party.
  • the asset can also be securely transferred to the new account by using the escrow key when the user loses the locally unexportable signature key.
  • the asset can also be transferred to the new account by converting the institutional account, so that the user asset is not lost. .
  • the encryption key is issued by the management end for each client after the user end registers with the eID through the authentication certificate or eID, and is stored and used by the local wallet of the user.
  • the encryption key may include a secret transaction key, a secret shared subkey, and a symmetric encryption key.
  • the secret transaction key can be used to encrypt and decrypt the token amount related parameters (such as the blinding factor) in the user transaction data;
  • the secret sharing subkey can be used to encrypt and decrypt the data of the identity of both sides of the transaction by using the secret sharing algorithm;
  • the key can be used to encrypt data such as the identity information of the storage client.
  • one or more of the encryption keys may also be used to generate a transaction address.
  • the secret sharing algorithm is a secret sharing scheme using an optional subkey, and the encryptor (the management side) can learn the N secret sharing subkeys thereof, and use the (2, N+1) threshold secret sharing algorithm. If a newly generated subkey is released with the encryption result, the secret message can be recovered based on any one of the N shares, and then the secret message can be used as the key to encrypt with a symmetric encryption algorithm. Share data.
  • the threshold secret sharing algorithm of (2, N+1) indicates that the secret message is divided into N+1 shares of the shared secret message, and any two or more shared shares can be used to recover the secret message.
  • the N+1 subkeys include a newly generated shadow subkey, and the client having a secret shared subkey shares the subkey according to its own secret and the shadow subkey issued with the encryption result, that is, You can recover the secret message and then use the secret message to view the shared data.
  • the encryption key includes the foregoing three types of keys, which is only one implementation manner. In other embodiments, the encryption key may also include only one or two types of keys, or may also include four types of keys. The key, as long as it can achieve the above functions. The name of the key is not limited to the use of the names in the above embodiments as long as it can be distinguished.
  • the UTXO (Unspent Transaction Outputs) model is used in the system of this embodiment.
  • a transaction includes one or more inputs and one or more outputs.
  • Each input is a reference to the forward unsuccessful transaction output and the corresponding unlock script.
  • the unlock cannot be referenced again, that is, it cannot be double-flowered.
  • Each output includes a token amount and a lock script, and the lock script needs to be unlocked to be unlocked, that is, a new unspent transaction output is created.
  • Step S2 after the transaction data is verified, the transaction data is endorsed and signed, and the transaction data after the endorsement signature is written into the block data of the first chain.
  • the management terminal when the user registers, the management terminal generates an initial address parameter (or a nonce value) for it, and generates a receiving transaction address.
  • the user acts as a transaction receiving end, all received transaction data of the user forms a Logical chain.
  • the management terminal After the same user is issued by the management terminal for generating a new key for the transaction address, the management terminal will regenerate an initial address parameter for the user, and record the transaction address generated by the regenerated initial address parameter in the status tree.
  • the regenerated initial address parameter is associated with, or is associated with, the issued new key.
  • all of the user's received transaction data form a new logical chain. It can be seen that the received transaction data of the same transaction receiving end can have one or more logical chain structures. Each time the newly generated initial address parameter is encrypted and stored in the control data, the user can find the logical chain by itself according to the initial address parameter in the control data.
  • the management end-ends the signature of the transaction data After the management end-ends the signature of the transaction data, it notifies the management chain of the private chain system.
  • the transaction data is written by the chain generating mechanism of the management end into the book data of the private chain, and then the generated block data is synchronized to the chain generating node of the external public chain.
  • the chain generation node After the block data verification is passed, the chain generation node writes the block data of the second chain through the consensus algorithm of the second chain.
  • the transaction data including the same transaction address is mutually sibling nodes in the chain structure.
  • Step S3 when it is determined that the transaction address in the transaction data is the same as the transaction address of the transaction receiving end in the status tree, generate a new transaction address by using the generated address parameter and update the status tree.
  • the transaction address of the transaction receiving end when it is determined that the transaction address in the transaction data is the same as the transaction address of the transaction receiving end in the status tree, generate a new transaction address by using the generated address parameter and update the status tree. The transaction address of the transaction receiving end.
  • the first address generation module generates a new transaction address by using the generated address parameter, including: the first address generation module utilizes a function to the generated address parameter and the The key of the transaction receiving end performs one or more operations to generate a transaction address.
  • the first address generating module generates a transaction address of the transaction receiving end by using the following first manner: the first address generating module uses the first function to use the first parameter to the address parameter and the user key of the transaction receiving end Performing an operation to obtain a first intermediate value, performing a first public key on the first intermediate value and the user public key of the transaction receiving end by using a second function, and performing a first public key on the first public key by using a third function Get the transaction address; or
  • Step 70 the client B calculates the transaction address through the nonce value of the last received transaction data of the local wallet, and uses the transaction address to query the account book data, and the transaction data can be found, and the transaction output address together with the lock script generates one.
  • the account transaction chain is associated with all the receiving transactions of the user.
  • an amount greater than the required amount may be input, so that in step 30, there is a change.
  • Output, or force a zero-valued zero output return the unspent output to the new account transaction when updating the account transaction chain, so try to avoid zero output).
  • all sent transactions will generate a change output that is linked to the user's account transaction chain, thereby associating all of the user's transactions with the account transaction chain.
  • the signature key and the symmetric encryption key of the management terminal, the user end, and the mechanism, including the corresponding algorithms can be updated. Because there is no mutual dependence, some user updates do not cause unavailability problems.
  • the secret shared subkey and the secret transaction key part of the user update key will not cause unavailability.
  • the update secret sharing algorithm can simultaneously issue the key corresponding to the old and new algorithms to the client, and then enable it at a certain block height.
  • the new secret sharing algorithm does not cause problems that are not available.
  • updating the confidential trading algorithm will bring the problem that the users of the old and new algorithms cannot trade each other, and if the update algorithm causes the ciphertext to verify the transaction amount, the total amount of tokens of the system will be uncertain.
  • the block header data of the public chain can be quickly verified on the public chain, and the block header data of the private chain of the management end can be quickly verified, and the block header data of the private chain has an associated signature to prevent forgery.
  • the management side verifies the voting information on the public chain, the relevant special transaction can be generated in the transaction data.
  • automatic supervision and/or human participation supervision may be employed.
  • the automatic supervision mainly monitors the transaction data, verifies whether the transaction is legal (such as whether the account is frozen, whether the certificate is cancelled or expired, etc.), whether the management endorsement signature and the client unlock signature are correct, and whether the confidential transaction amount is correct, if it is issued or recycled. Whether the transaction has relevant information in the previous control data, if it is the conversion transaction input and output is the transaction address of the same user.
  • Both the automatic supervision and chain generation nodes can verify the validity of the transaction amount and ensure that the total amount of tokens in the system is certain.
  • both parties need to register in the system to be transferred.
  • user A registers with the management nodes of system SA and system SB
  • user B registers with the management nodes of system SA and system SB. Since the client side of the transaction does not know who the other party is, it is necessary to make a hosting contract statement.
  • the statement of the escrow contract is similar to the above transaction.
  • the signature of the client is validated by the end of the management endorsement, and the user's assets are transferred to the escrow account of the user.
  • the user's escrow account can establish a separate user escrow account transaction chain in the manner described above.
  • the above example is an account transaction chain formed by the transaction address of the UTXO model.
  • the account transaction chain can also be formed in a similar manner.
  • the following is an example of the account balance model.
  • the system is the account balance model, since there is no concept of inputting the reference address and outputting the address, only the user account identifier and the corresponding transaction amount are included in the transaction data, and the sending transaction and the receiving transaction of the client have no dependency, so the transaction ID can be sent. And receiving the transaction ID, so that the transaction data of the client forms a transmission chain and a reception chain with a fraternity node.
  • the sending transaction ID is generated by the nonce value of the last transaction sent by the client and the encryption key of the client by a one-way irreversible function, and the sending transaction ID is unique in the system; the receiving transaction ID is received by the user terminal last time.
  • the nonce value and the encryption key of the client are generated by a one-way irreversible function.
  • the receiving transaction IDs of different users are unique, but because there are concurrent transactions, there are different receiving transactions of the same user. Receive the transaction ID.
  • the management terminal When the client registers with the management terminal, the management terminal generates a random initial nonce value and an initial received transaction ID, and uses the symmetric encryption key of the client to perform encrypted storage.
  • the transaction ID is generated by a non-one-way irreversible function by the nonce value and the client's encryption key at the time of the transaction.
  • the nonce value is randomly generated by the management side and ensures that the next transmitted transaction ID and the received transaction ID (for the recipient) are unique in the system.
  • the initial receiving transaction ID is the ID of the first receiving transaction of the user. When the receiving transaction ID of the user is equal to the receiving transaction ID of the user in the status tree, the received nonce value of the transaction and the receiving of the user's encryption key are generated.
  • the transaction ID updates the receiving transaction ID in the status tree.
  • computer storage medium includes volatile and nonvolatile, implemented in any method or technology for storing information, such as computer readable instructions, data structures, program modules or other data. Sex, removable and non-removable media.
  • Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridge, magnetic tape, magnetic disk storage or other magnetic storage device, or may Any other medium used to store the desired information and that can be accessed by the computer.
  • communication media typically includes computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and can include any information delivery media. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Databases & Information Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)

Abstract

本申请实施例提供了一种区块链数据处理方法、管理端、用户端和转换装置以及存储介质，所述区块链数据处理方法包括：交易数据验证通过且背书签名后被写入第一链系统的区块数据中；所述第一链系统的区块数据被写入第二链系统的区块数据中，所述第二链系统的区块数据由所述第一链系统的一个或多个区块数据顺序组成，所述第一链系统上任一账户的状态与所述第二链系统上所述账户的状态一致。

Description

区块链数据处理方法、管理端、用户端、转换装置及介质 技术领域
本文涉及但不限于计算机数据处理技术领域，尤指一种区块链数据处理方法、管理端装置、用户端装置、转换装置以及计算机可读存储介质
背景技术
目前的去中心化系统例如公有链系统，因为有着公开、透明、可追溯、不可篡改等特点，所以能降低交易参与方之间的信任成本，可作为信任的基础实现价值传递。
然而，目前的去中心化系统存在以下问题：效率较低下，缺乏完善的监管和隐私保护，token(可称为代币或通证)的发行也缺少相关背书，无法在海量数据下实现隐私交易并检索。
发明概述
以下是对本文详细描述的主题的概述。本概述并非是为了限制权利要求的保护范围。
第一方面，本申请实施例提供一种管理端的数据处理方法，包括：
交易数据验证通过且背书签名后被写入第一链系统的区块数据中；
所述第一链系统的区块数据被写入第二链系统的区块数据中，所述第二链系统的区块数据由所述第一链系统的一个或多个区块数据顺序组成，所述第一链系统上任一账户的状态与所述第二链系统上所述账户的状态一致。
第二方面，本申请实施例提供一种用户端的数据处理方法，包括：
交易接收端根据上一次接收交易数据中的地址参数生成本次接收交易的交易地址，从第二链系统中查找包含所述交易地址的交易数据；所述第二链系统中的区块数据由第一链系统的一个或多个区块数据顺序组成，所述第一链系统上任一账户的状态与所述第二链系统上所述账户的状态一致。
第三方面，本申请实施例提供一种转换装置的数据处理方法，包括：
发起转换交易，使用转换机构账户的签名密钥对所述交易数据进行签名，生成第一解锁脚本，以将用户端原账户中的未花费的交易输出转换为新的未花费交易输出，由所述转换机构账户发起的交易形成的交易数据验证通过且背书签名后被写入第一链系统的区块数据中，所述第一链系统的区块数据被写入第二链系统的区块数据中，所述第二链系统的区块数据由所述第一链系统的一个或多个区块数据顺序组成，所述第一链系统上任一账户的状态与所述第二链系统上所述账户的状态一致。
第四方面，本申请实施例提供一种管理端装置，包括验证模块和背书签名模块，其中：
所述验证模块，设置为对交易数据进行验证；
所述背书签名模块，设置为在所述验证模块对交易数据验证通过后，对所述交易数据进行背书签名，背书签名后的交易数据将被写入第一链系统的区块数据中；
其中，所述交易数据包括交易接收端的交易地址和本次交易时生成的地址参数，所述交易地址利用所述交易接收端上次接收交易时生成的地址参数生成，所述本次交易时生成的地址参数用于生成所述交易接收端下次接收交易的交易地址，使同一交易接收端的所有接收交易数据形成逻辑链式结构。
第五方面，本申请实施例提供一种用户端装置，包括第二地址生成模块和检索模块，其中：
所述第二地址生成模块，设置为根据上一次接收交易数据中的地址参数生成本次接收交易的交易地址；
所述检索模块，设置为从第二链系统中查找包含所述交易地址的交易数据。
第六方面，本申请实施例提供一种转换装置，包括发起模块和签名模块，其中：
所述发起模块，设置为根据管理端装置的使能发起转换交易；
所述签名模块，设置为使用转换机构账户的签名密钥对所述交易数据进 行签名，生成第一解锁脚本，以将用户端原账户中的未花费的交易输出转换为新的未花费交易输出；
由所述转换机构账户发起的交易形成的交易数据验证通过且背书签名后被写入第一链系统的区块数据中，所述第一链系统的区块数据被写入第二链系统的区块数据中，所述第二链系统的区块数据由所述第一链系统的一个或多个区块数据顺序组成，所述第一链系统上任一账户的状态与所述第二链系统上所述账户的状态一致。
第七方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现上述管理端的数据处理方法、或者用户端的数据处理方法、或者转换装置的数据处理方法的步骤。
在阅读并理解了附图和详细描述后，可以明白其他方面。
附图概述
图1为本申请实施例数据处理方法流程图；
图2为本申请实施例可信系统示意图；
图3为本申请实施例提供可信系统中第一链与第二链的链间流转示意图；
图4为本申请实施例管理端数据处理方法一种实施方式流程图；
图5为本申请实施例管理端数据处理方法另一种实施方式流程图；
图6为本申请实施例管理端装置结构示意图；
图7为本申请实施例用户端数据处理方法流程图；
图8为本申请实施例用户端装置结构示意图；
图9为本申请一种实施方式流程图。
详述
在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互任意组合。
在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机 系统中执行。并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。
本文及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。
本申请实施例提出一种中心化与去中心化结合的可信系统，以解决背景技术中目前存在的问题。
下面先对本申请实施例涉及的概念进行说明。
token，指区块链上的代币，也称为通证。
公有链，指任何人都可以读取、发送交易和参与共识的区块链，属于完全去中心化的系统。本文实施例中采用的是一种除任何人都可以发送交易外，其余都与公有链系统相同的类公有链系统。在本文所述的类公有链系统中，任何人都可以读取、验证交易和参与共识，能够实现可追溯、不可篡改。
私有链，指写入权限在一个组织手里的数据链，属于中心化的系统。
联盟链，指写入权限在多个组织手里的数据链，属于部分去中心化的系统。
eID(electronic Identity)，指公民网络电子身份标识，是可信的实名认证方式。
秘密共享：指秘密消息以适当的方式拆分为N份，只有M份或M份以上协作才能恢复秘密消息，标记为(M，N)，M和N为大于1的正整数。
本申请实施例提供了一种中心化和去中心化结合的可信系统。在本申请实施例中，中心化系统(或称第一链系统、第一链)可以是私有链或联盟链。去中心化系统(或称第二链系统、第二链)可以是公有链或联盟链。第一链用使用哪种链与第二链使用哪种链没有必然关系，例如。第一链为私有链时，第二链可以是公有链也可以是联盟链，同样地，第一链为联盟链时，第二链可以是公有链也可以是联盟链。第二链具有对外公开的特性，故本实施例中也称为对外系统。中心化系统可以有管理员角色(管理端节点或管理端装置，以下简称管理端)和用户角色(用户端节点或用户端装置，以下简称用户端)。可选地，第一链系统还可以包括一个或多个特定的机构角色(例如包括但不 限于以下一种或多种：链生成机构、发行机构、转换机构等)，因为第一链系统是管理端的系统，所以以下也称为管理端的第一链系统。去中心化系统可以有用户角色(第一链系统上的用户角色与第二链系统上的用户角色相同)和链生成节点(与中心化系统的链生成机构不同，链生成机构生成第一链，链生成节点生成第二链)。可选地，第二链系统还可以有第三方和监管者的参与，第三方可以是其他任何人或机构，监管者是具有特定权限(例如验证)的机构。因为第二链系统是对外提供查询、验证和监管的系统，所以以下也称为对外的第二链系统。
本申请实施例的数据处理方法如图1所示，包括以下步骤：
步骤1，交易数据验证通过且背书签名后被写入第一链系统的区块数据中；
用户提交的交易数据需要管理端对交易数据验证以及进行背书签名，验证通过且背书签名后的交易数据将通过链生成机构写入第一链的区块数据中。
步骤2，所述第一链系统的区块数据被写入第二链系统的区块数据中，所述第二链系统的区块数据由所述第一链系统的一个或多个区块数据顺序组成，所述第一链系统上任一账户的状态与所述第二链系统上所述账户的状态一致。
当第一链产生新的区块数据后，会同步到第二链的链生成节点，区块数据验证通过后由链生成节点根据第二链的共识算法产生新的区块数据，其中验证包括区块内所有数据的验证。而第二链中只顺序记录管理端的第一链提交的区块数据，并且第二链上每个区块数据包含的第一链的区块数据的数量可以不固定，也即第二链上每个区块可以包含1至n个第一链的区块数据，数量由第二链的共识算法决定。所以对外的第二链系统上的每个区块数据是由管理端的第一链系统的一个或多个区块数据顺序组合而成，因此管理端的第一链系统和对外的第二链系统在逻辑状态上是相同的。本实例提供的可信系统可以看作是一个双层的体系(包括管理端的第一链系统和对外的第二链系统)。然而，本申请对此并不限定。在实际运用中，该系统还可以扩展到多层体系，比如，在管理端进行扩展，可扩展为多层。
管理端的第一链系统和对外的第二链系统可以使用不同的共识算法。例 如，管理端的第一链系统使用共识时间更短的算法，可以满足快速确认和高频交易的需求，而对外的第二链系统使用共识时间更长的算法。所以两条链各自产生区块数据的时间也可以不相同，可以是一个异步的过程，如图2所示。因此，对外的第二链的生成不会影响管理端的第一链的产生，从而满足管理端的高并发需求。第二链的区块数据是由第一链的一个或多个区块数据顺序组合而成，由于第二链使用的数据块都是管理端的第一链打包后的区块数据，所以也有利于第二链的区块数据生成并能满足海量数据的需求。可见，本实施例可信系统的第一链和第二链是异步同态的，管理端的第一链系统可以通过第二链系统检查自身的数据状态，并且可以通过第二链系统恢复除了没有及时同步到第二链系统的所有区块数据。
可选地，第二链系统还可以包括扩展数据，扩展数据可以是第二链系统自身的系统状态数据，并不会涉及第一链系统的系统状态，所以不会影响第一链系统和第二链系统逻辑状态的不同。
本实施例中，在管理端的第一链系统以及对外的第二链系统上使用不同方式获取到的任一账户的状态是一致的。示例性地，管理端可以生成系统状态树，从而得到任一账户的状态。所述账户的状态可以包括：账户余额，以及初始地址参数、冻结或解冻等状态信息；在第二链上，可以通过累计交易结果的方式获知该账户的余额状态，以及检索控制数据中的用户加密信息获取其余状态；通过累计交易结果获知的账户的状态与管理端上得到的该账户的状态是一致的。用户端的钱包可以自动验证在管理端的第一链上获取到的账户的状态与在对外的第二链上获取到的该账户的状态是否一致。
下面以管理端的第一链系统为私有链，对外的第二链系统为公有链为例进行说明。
管理端是系统的管理者，用户和机构的注册、注销、证书更新和加密密钥发行等都是通过管理端进行的，管理端还可以具有冻结、解冻账户，以及阻止非法交易的功能，并且系统token的发行和回收也需要管理端的参与。链生成机构是管理端的私有链的生成者，发行机构参与token的发行，转换机构在用户只具有本地的不可导出的签名密钥并且丢失时参与，上述机构的 身份都是公开并不保密的。与管理端的私有链系统有关联的还可以包括可信的第三方CA(Certificate Authority，认证授权)机构(或eID机构)，或可信的第三方托管签名密钥机构等。
对外的公有链系统里的链生成节点不需要管理端的许可，可按照相应规则验证公有链上的数据及参与公有链系统的共识和生成，链上的数据是公开、可追溯、不可篡改的，但并不是完全透明的，链生成节点、第三方和监管者都可以验证链上数据的正确性，但并不会知道对应的用户身份、用户的相关交易和资产信息，即使使用地址追溯用户身份和相关交易也做不到，但第三方和监管者可以在获取到用户端或管理端的加密密钥授权后，自行地从公有链上获取到用户的相关交易和资产信息，用户自己也是从公有链上通过加密密钥获取到与自己相关的交易数据、资产信息和用户信息，如图3所示。
为使用本实施例所述可信系统，用户首先需要实名认证后在管理端的私有链上进行注册。注册后，用户发起交易生成的交易数据通过管理端验证且背书签名后由链生成机构写入私有链，私有链会同步数据到公有链上，而交易的双方、链生成节点、第三方和监管者等都是在公有链上对交易数据进行查询和验证，也即整个系统对用户、第三方和监管者的读取操作都是在公有链上进行的，而写入操作则是通过管理端在私有链上进行的，所以本实施例系统是读写分离的。
在本文实施例中，管理端的私有链上的数据可以包括控制数据集和交易数据集，以及链生成机构共识算法产生的区块头数据。控制数据集主要是管理端用来管理和控制第一链系统而发布的信息数据的集合，包括但不限于以下信息的一种或多种：用户和机构的注册信息、token的发行和回收、交易规则、身份证书和更新信息(例如更新的用户信息，和/或更新的系统算法密钥等)等。除用户的身份信息为密文外，其余的大部分数据都为明文，以方便有效监管，也能保护用户的身份隐私。交易数据集是一时间片段内所有单笔交易的集合。每笔交易数据中除token数额和输出地址对应的用户标识为密文外，其余数据都为明文，其中输出地址对应的用户标识在交易数据中为可选项。交易的token数额使用机密交易的方式加密(如加法同态承诺)，除该token对应的机密加密密钥(交易地址对应的用户端和管理端所拥有的密 钥)能解密明文外，其余均不能解密查看明文，但可以用密文验证机密交易token数额的有效性，即在密文的情况下验证交易的所有输入token之和减去所有输出token之和是否等于零并且所有项值没有负数。区块头数据包括控制数据集生成的默克尔树(Merkle Tree)根哈希和交易数据集生成的Merkle Tree根哈希，以及管理端生成的当前系统状态树的默克尔-帕特里夏树(Merkle Patricia Tree)根哈希，还有上一个区块头的哈希值、区块号、时间戳、共识参数等，还需有相关签名以保障区块头数据的防伪造和抗抵赖。管理端需要有系统全部的加密密钥才能生成系统状态树，所以该状态树只在管理端使用，并且是一个虚拟的状态树。
在本实施例中，用户端的密钥分为签名密钥和加密密钥两类。其中：
签名密钥是由用户端本地生成和管理使用的，使用不可导出的硬件作为载体，以确保密钥的安全使用。签名密钥通过CA机构颁发用户的身份认证证书或使用eID机制，实现用户的实名身份认证。签名密钥包括证书签名公钥和签名私钥。另外，在一种可选实施方式中，本系统可采用多重签名的方式，用户端除了本地的签名密钥外还可以使用可信第三方托管的签名密钥，该密钥是用户端通过身份认证证书或eID在管理端注册后，由管理端在可信第三方申请的托管签名密钥，用户端可以使用FIDO(线上快速身份验证)的方式使用托管签名密钥，连同用户端的本地签名密钥组成多重签名地址。可选地，可以标识多重签名的类型，比如为用户小额支付时方便使用的目的，可以采用本地不可导出的签名密钥支付额度较高的费用，而采用可信第三方托管的签名密钥支付额度较低的费用，也可以联合使用两种签名密钥以加强用户账户的安全性，还可以使用多个用户的签名密钥组成联合账户的多重签名地址。在一个可选实施方式中，还可以在用户丢失本地不可导出的签名密钥时，通过使用托管密钥安全地将资产转移至新的账户。在另一个可选实施方式中，如果用户端不具有托管签名密钥并且本地的不可导出的签名密钥丢失，还可以通过转换机构账户将资产转移至新的账户，以使用户资产不受损失。
加密密钥是用户端通过身份认证证书或eID在管理端注册后，由管理端为每个用户端颁发不同的加密密钥，并由用户端的本地钱包存储和使用。加 密密钥可以包括机密交易密钥、秘密共享子密钥和对称加密密钥。其中，机密交易密钥可用于加解密用户交易数据中的token数额相关参数(如盲化因子)；秘密共享子密钥可用于使用秘密共享算法加解密交易双方的身份标识等数据；对称加密密钥可用于加密存储用户端的身份信息等数据。除上述解释的用途外，加密密钥中的一个或多个密钥还可以用于生成交易地址。其中，秘密共享算法是使用可选子密钥的秘密共享方案，并且加密者(管理端)可得知其中的N份秘密共享子密钥，使用(2，N+1)的门限秘密共享算法，新生成的一份子密钥随加密结果发布，则基于N份中的任意一份秘密共享子密钥即可恢复秘密消息，然后，可以使用秘密消息作为密钥采用对称加密算法加密需要保护的共享数据。其中，(2，N+1)的门限秘密共享算法表示秘密消息被分为N+1个份额的共享秘密消息，利用其中任意两个或两个以上共享份额就可以恢复出秘密消息。所以，N+1个子密钥包括一份新生成的影子子密钥，具有一个秘密共享子密钥的用户端根据自身的秘密共享子密钥以及随加密结果发布的该影子子密钥，即可以恢复出秘密消息，再利用秘密消息查看共享数据。在本实施例中，加密密钥包含上述三种密钥仅为一种实施方式，在其他实施方式中，加密密钥也可以只包含一种或两种密钥，或者还可以包含四种密钥，只要能实现上述功能即可。密钥的名称也不限于使用上述实施例中的名称，只要可以区分即可。
本实施例系统中使用UTXO(Unspent Transaction Outputs，未花费的交易输出)模型。在UTXO模型中，一笔交易包括一个或多个输入和一个或多个输出。每个输入是一个对前向的未花费交易输出的引用，以及对应的解锁脚本。当对前向的未花费交易输出引用解锁后，就不能再次引用解锁，也即不能够双花。而每个输出包括token数额和锁定脚本，锁定脚本需对应的解锁脚本才能够解锁，也即创建了一个新的未花费交易输出。锁定脚本包含一个交易地址和解锁方式，其中交易地址是用一非对称密钥的公钥通过一单向不可逆函数得到，而解锁脚本是交易地址对应的公钥数据和私钥对交易数据的签名，可以使用该公钥验证签名。锁定脚本和解锁脚本还可以使用多重签名的方式。
本实施例中，管理端的私有链系统可以生成系统的状态树，从而可以方 便获取每个用户的当前状态。状态树由当前所有的控制数据和交易数据产生，记录了系统当前的状态以及每个用户当前的状态。状态树中用户的资产状态包括根据用户的UTXO交易记录维护的账户余额，而对外的公有链系统上的用户端、第三方和监管者可以根据用户的UTXO交易记录累计交易结果，从而得到用户余额。也即管理端能根据系统状态树查询用户的当前状态和账户余额，而对外公有链系统上的用户必须使用该用户所有的交易记录才能得到该用户的账户余额。可见，用户端的资产状态在管理端的私有链系统和对外的公有链系统的使用方式是不一样的，但这两种方式得到的账户余额是一致的。由于状态树只在管理端的私有链上使用，管理端可以通过状态树的方式方便获取每个用户端的当前状态，而为了给用户端、第三方和监管者提供一种从对外的公有链上获取到用户端所有的交易记录的方式，因此引入了一种账户交易链，检索该账户交易链不仅方便快捷，而且还能够保护用户隐私。
以下对账户交易链进行说明：
在一个可选实施例中，账户交易链的数据处理方法，如图4所示，包括以下步骤：
步骤S1，对交易数据进行验证；
所述交易数据包括交易接收端的交易地址和本次交易时生成的地址参数，所述交易地址利用所述交易接收端上次接收交易时生成的地址参数生成，所述本次交易时生成的地址参数用于生成所述交易接收端下次接收交易的交易地址；
交易数据由用户端提交给管理端，管理端对交易数据的验证主要是验证有效性，例如包括验证用户状态的有效性，解锁脚本的有效性，token数额的有效性，以及交易地址是否是有效的地址等；
步骤S2，交易数据验证通过后，对所述交易数据进行背书签名，背书签名后的交易数据将被写入第一链的区块数据中。
管理端的背书签名是对用户端提交的整个交易数据的签名。
所述交易数据上链后，同一交易接收端的所有接收交易数据将会形成逻辑链式结构。该逻辑链隐含在生成的账本数据中。
可选地，用户在注册时管理端为其生成初始地址参数(或称为nonce值)，并生成接收交易地址，该用户作为交易接收端发生交易时，该用户的所有接收交易数据会形成一个逻辑链。当同一用户被管理端颁发了用于生成交易地址的新密钥后，管理端会重新为该用户生成一个初始地址参数，并在状态树中记录由重新生成的初始地址参数生成的交易地址，所述重新生成的初始地址参数与颁发的新密钥是配套的，或者说是相关联的。此后，当该用户作为交易接收端发生交易时，该用户的所有接收交易数据会形成一个新的逻辑链。可见同一交易接收端的接收交易数据可有一个或多个逻辑链式结构。每次新生成的初始地址参数会加密存储在控制数据中，用户可以根据控制数据中的初始地址参数自行查找逻辑链。
管理端对交易数据背书签名后，通知管理端的私有链系统上链。由管理端的链生成机构将所述交易数据写入私有链的账本数据中，然后生成的区块数据同步到对外公有链的链生成节点。区块数据验证通过后由链生成节点通过第二链的共识算法写入第二链的区块数据中。
可选地，如果有多个针对同一交易接收端的并发交易，即存在多个包含相同交易地址的交易数据，则包含相同交易地址的交易数据在所述链式结构中互为兄弟节点。
通过交易数据中包含的用上一次接收交易中的地址参数生成的交易地址和用于生成下一次交易地址的地址参数，使得同一用户端的接收交易数据形成或有兄弟节点的逻辑链条，从而能够快速检索用户端的所有接收交易数据，且由于发送交易数据是引用接收交易数据，进而能够实现快速获取到所有交易数据。同时该交易地址是一次性的，对不同用户是唯一的，从而可以达到保护用户身份隐私的目的。
在一个可选实施例中，如图5所示：
对交易数据验证(步骤S1)之前，所述方法还包括：
步骤S0，生成地址参数，从状态树查找所述交易接收端的交易地址，将生成的地址参数和查找到的所述交易地址发送给交易发送端，由所述交易发送端将所述交易地址和地址参数添加到交易数据中；
所述对所述交易数据进行背书签名(步骤S2)之后，所述方法还包括：
步骤S3，判断所述交易数据中的交易地址与所述状态树中的所述交易接收端的交易地址相同时，利用所述生成的地址参数生成一个新的交易地址并更新所述状态树中的所述交易接收端的交易地址。
如果判断所述交易数据中的交易地址与所述状态树中的所述交易接收端的交易地址不相同，则说明该交易接收端的交易地址已经更新过了，无需更新所述状态树中的所述交易接收端的交易地址。
在本可选实施例中，通过用状态树存储接收交易地址保证每次接收交易时的交易地址都是最新的。
在一个可选实施例中，所述地址参数可以为一随机数；上述利用所述生成的地址参数生成一个新的交易地址，包括：利用函数对所述生成的地址参数以及所述交易接收端的密钥进行一次或多次运算，生成交易地址。进行多次运算时可以使用相同或者不同的函数。
除了可以使用上述提到的加密密钥中的一个或多个生成交易地址外，也可以由管理端为用户发行新的密钥专用于生成交易地址。
可选地，所述交易接收端的交易地址可以采用以下第一方式生成：利用第一函数对所述地址参数以及所述交易接收端的用户密钥进行运算得到第一中间值，利用第二函数对所述第一中间值以及所述交易接收端的用户公钥进行运算得到一第一公钥，利用第三函数对所述第一公钥进行运算得到交易地址；
例如，第一中间值(K)通过一单向不可逆函数(即第一函数)对所述地址参数以及所述交易接收端的用户密钥进行运算生成，第一公钥用第一中间值(K)和用户公钥通过椭圆曲线上的标量乘运算(即第二函数)得到，再用第一公钥通过另一单向不可逆函数(即第三函数)生成交易地址。
可选地，所述交易接收端的交易地址还可以是多重签名地址，该多重签名地址可以采用以下第二方式生成：利用不同的函数对所述地址参数以及所述交易接收端的用户密钥进行运算得到多个中间值，利用第四函数分别将每个中间值与所述交易接收端的多个用户公钥进行运算得到多个新公钥，利用 第五函数对所述多个新公钥进行运算得到多重签名地址。
例如，由多个不同的单向不可逆函数对所述地址参数以及所述交易接收端的用户密钥进行运算生成多个中间值(K’)，对每个中间值与接收交易端的多个用户公钥通过椭圆曲线上的标量乘运算(即第四函数)得到多个新公钥，再用多个新公钥通过另一单向不可逆函数(即第五函数)生成多重签名地址。每个中间值与多个用户公钥是一一对应的关系，所以多个不同的单向不可逆函数与多个用户公钥也是一一对应的关系。
上述单向不可逆函数例如可以是散列函数或散列函数的组合。
上述第一方式与第二方式中的运算函数可以相同。
在一个可选实施例中，收到用户端发起的密钥更新请求，管理端对所述用户端进行身份认证后，颁发新的加密密钥，发起转换交易流程，使转换机构账户发起交易，由所述转换机构账户的签名密钥对所述交易数据进行签名，生成第一解锁脚本，以将所述用户端原账户中的未花费的交易输出转换为新的未花费交易输出。所述第一解锁脚本是一种特殊(或特定)的解锁脚本，是由转换机构生成的，区别于由用户端生成的解锁脚本。采用该可选实施例可以解决用户丢失本地签名密钥导致资产损失的问题。
在一个可选实施例中，所述方法还可包括以下步骤中的一个或多个：
生成用于发行token的指定发行交易，所述指定发行交易中的输入地址为采用第一格式的地址；
生成用于回收token的指定回收交易，所述指定回收交易中的输出地址为采用第二格式的地址；
生成用于奖励token的指定奖励交易，所述指定奖励交易中的输入地址为采用第三格式的地址。
上述第一格式是指一种特殊的地址格式，没有UTXO地址的上下文关系，即输入不需要引用未花费交易输出，输出也不能作为输入，可以是预先约定的。同样地，第二格式和第三格式也类似。
采用本实施例方法，由于同一交易接收端的所有接收交易数据形成逻辑 链式结构，并且所述接收端的所有发送交易都需引用接收交易数据，所以获取相关密钥后就能检索所述接收端的所有交易数据。
实现本实施例方法的管理端装置可包括验证模块101和签名背书模块102，如图6所示，其中：
所述验证模块101，设置为对交易数据进行验证；
所述背书签名模块102，设置为在所述验证模块验证通过后，对所述交易数据进行背书签名，背书签名后的交易数据将被写入第一链系统的区块数据中；
其中，所述交易数据包括交易接收端的交易地址和本次交易时生成的地址参数，所述交易地址利用所述交易接收端上次接收交易时生成的地址参数生成，所述本次交易时生成的地址参数用于生成所述交易接收端下次接收交易的交易地址；使同一交易接收端的所有接收交易数据形成逻辑链式结构。
在所述链式结构中包含相同交易地址的交易数据互为兄弟节点。
在一个可选实施例中，该装置还可包括第一地址生成模块，设置为生成地址参数，以及从状态树查找所述交易接收端的交易地址，将生成的地址参数和查找到的所述交易地址发送给交易发送端；以及设置为判断所述交易数据中的交易地址与所述状态树中的所述交易接收端的交易地址相同时，利用所述生成的地址参数生成一个新的交易地址，并更新所述状态树中的所述交易接收端的交易地址。
在一个可选实施例中，所述第一地址生成模块利用所述生成的地址参数生成一个新的交易地址，包括：所述第一地址生成模块利用函数对所述生成的地址参数以及所述交易接收端的密钥进行一次或多次运算，生成交易地址。
可选地，所述第一地址生成模块采用以下第一方式生成所述交易接收端的交易地址：所述第一地址生成模块利用第一函数对所述地址参数以及所述交易接收端的用户密钥进行运算得到第一中间值，利用第二函数对所述第一中间值以及所述交易接收端的用户公钥进行运算得到一第一公钥，利用第三函数对所述第一公钥进行运算得到交易地址；或者
所述第一地址生成模块采用以下第二方式生成所述交易接收端的交易地址，所述交易接收端的交易地址为多重签名地址，所述第一地址生成模块利用不同的函数对所述地址参数以及所述交易接收端的用户密钥进行运算得到多个中间值，利用第四函数分别将每个中间值与所述交易接收端的多个用户公钥进行运算得到多个新公钥，利用第五函数对所述多个新公钥进行运算得到多重签名地址。
在一个可选实施例中，所述第一地址生成模块还设置为在用户注册时，生成所述用户的初始地址参数，并在状态树中记录由所述初始地址参数生成的交易地址；以及
所述第一地址生成模块还设置为重新为被颁发了新密钥的用户生成初始地址参数，并在状态树中记录由所述重新生成的初始地址参数生成的交易地址，所述新密钥为用于生成交易地址的密钥。
在一个可选实施例中，所述装置还包括颁发密钥模块和转换交易模块，其中：
所述颁发密钥模块，设置为收到用户端发起的密钥更新请求，对所述用户端进行身份认证后，颁发新的加密密钥；
所述转换交易模块，设置为发起转换交易流程，使能转换机构账户发起交易，由所述转换机构账户的签名密钥对所述交易数据进行签名，生成第一解锁脚本，以将所述用户端原账户中的未花费的交易输出转换为新的未花费交易输出。
可选地，当用户发起注册时，颁发密钥模块对用户端进行身份认证后，也会颁发新的加密密钥。
所述装置还包括以下模块中的一个或多个：发行交易模块、回收交易模块和奖励交易模块，其中：
所述发行交易模块，设置为生成用于发行token的指定发行交易，所述指定发行交易中的输入地址为采用第一格式的地址；
所述回收交易模块，设置为生成用于回收token的指定回收交易，所述指定回收交易中的输出地址为采用第二格式的地址；
所述奖励交易模块，设置为生成用于奖励token的指定奖励交易，所述指定奖励交易中的输入地址为采用第三格式的地址。
上述管理端装置还可以是一种计算机设备，包括处理器、存储器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时可实现上述实施例部分或全部步骤。
本实施例在具有管理端的区块链系统中，使用户端的接收交易数据形成或有兄弟节点的逻辑链条，从而能够快速检索同一用户端的所有接收交易数据，进而检索该用户端的所有交易数据，同时使用户端具有一次性交易地址的特征，达到保护用户身份隐私的目的。
以下实施例描述用户端的数据处理方法，如图7所示，包括以下步骤：
步骤S11，交易接收端根据上一次接收交易数据中的地址参数生成本次接收交易的交易地址；
步骤S12，从对外的第二链系统中查找包含所述交易地址的交易数据；所述对外的第二链系统中的区块数据由第一链系统的一个或多个区块数据顺序组成，所述第一链系统上任一账户的状态与所述第二链系统上所述账户的状态一致。
由于同一交易接收端的所有接收交易数据形成逻辑上的链式结构，因此使得交易接收端可以依据上一次接收交易数据中的地址参数生成本次接收交易的交易地址，根据本次接收交易的交易地址可以快速查找到本次交易数据。同时由于交易地址是一次性的，保护了该交易接收端的用户隐私。
在一个可选实施例中，所述方法还包括：用户端将通过所述管理端从状态树获取到的账户状态与自行从第二链系统获取到的账户状态进行比对。
在一个可选实施例中，当所述交易接收端作为交易发送端时，所述方法还包括：所述交易发送端提交交易时，使用引用接收交易数据的上一次接收交易数据中的地址参数生成公私钥对(该公钥为上文中通过第一方式或第二方式生成的公钥，公钥一致才能保证地址相同)，使用所述公私钥对生成当前交易中的解锁脚本。
实现本实施例方法的用户端装置可包括第二地址生成模块201、检索模块202和验证模块203，如图8所示，其中：
所述第二地址生成模块201，设置为根据上一次接收交易数据中的地址参数生成本次接收交易的交易地址；
所述检索模块202，设置为从第二链系统中查找包含所述交易地址的交易数据。
在一个可选实施方式中，上述用户端装置还可以包括验证模块，其设置为将通过所述管理端从状态树获取到的账户状态与自行从第二链系统获取到的账户状态进行比对。
在一个可选实施例中，所述用户端装置还可包括签名模块，所述签名模块设置为在所述用户端作为交易发送端时，在提交交易时，使用引用接收交易数据的上一次接收交易数据中的地址参数生成公私钥对(公钥即为上文中通过第一方式或第二方式生成的公钥)，使用所述公私钥对生成当前交易中的解锁脚本。
上述用户端装置还可以是一种计算机设备，包括处理器、存储器以及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时可实现上述实施例部分或全部步骤。
本实施例基于同一用户端的接收交易数据链条，能够快速检索同一用户端的所有接收交易数据，进而检索该用户端的所有交易数据。
以下实施例描述转换装置的数据处理方法，包括：
发起转换交易，使用转换机构账户的签名密钥对所述交易数据进行签名，生成第一解锁脚本，以将用户端原账户中的未花费的交易输出转换为新的未花费交易输出，由所述转换机构账户发起的交易形成的交易数据验证通过且背书签名后被写入第一链系统的区块数据中，所述第一链的区块数据被写入对外的第二链系统的区块数据中，所述第二链系统的区块数据由所述第一链系统的一个或多个区块数据顺序组成，所述第一链系统上任一账户的状态与所述第二链系统上所述账户的状态一致。
上述转换装置发起的转换交易需要由管理端装置发起交易流程以使能所述转换装置，然后转换装置才能发起。
实现上述方法的转换装置，包括发起模块和签名模块，其中：
所述发起模块，设置为根据管理端装置的使能发起转换交易；
所述签名模块，设置为使用转换机构账户的签名密钥对所述交易数据进行签名，生成第一解锁脚本，以将用户端原账户中的未花费的交易输出转换为新的未花费交易输出；
由所述转换机构账户发起的交易形成的交易数据验证通过且背书签名后被写入第一链系统的区块数据中，所述第一链系统的区块数据被写入对外的第二链系统的区块数据中，所述第二链系统的区块数据由所述第一链系统的一个或多个区块数据顺序组成，所述第一链系统上任一账户的状态与所述第二链系统上所述账户的状态一致。
以下实施例中将管理端和用户端的数据处理方法结合在一起描述。
本例系统中的交易地址可以是通过一个单向不可逆函数对地址参数和用户密钥计算得出的K值(即中间值)与用户端的签名公钥做运算，比如椭圆曲线上的标量乘运算，得到一个新的公钥，对该新的公钥通过另一单向不可逆函数得到交易地址，该新的公钥也称为交易地址对应的公钥。该新的公钥对应的私钥也可通过K值与用户端的签名私钥做运算，比如有限域的乘运算得到。而同一用户端的接收交易数据中的交易地址都是通过计算得出的不同K值参与运算得到的，具有一次性地址的特征，所以外部不能够通过交易地址的相关信息追踪用户的相关身份，但可以验证用户的解锁签名。同理，本实施例生成交易地址的方式还可以用于多重签名的地址(即用多个不同公钥生成的地址)，只需采用前述第二方式进行相关运算即可。
下面描述本示例中区块链系统的数据处理方法，如图9所示，包括以下步骤：
步骤10，用户端A向管理端提交与用户端B的交易请求；
本实施例以交易接收端为用户端B为例进行说明，交易接收端可以有多 个；
步骤20，管理端从系统状态树中获取用户端B的交易地址并随机生成nonce值，并将该交易地址和nonce值发送给用户端A，作为本次交易的输出地址和nonce值；
同理，如果用户端A要与多个接收端进行交易，即在步骤10中提交了与多个接收端的交易请求，则管理端传输多个接收端相应的交易地址给用户端A即可；
可选的，管理端还可以将交易地址对应的用户标识(本实施例中该交易地址对应的用户标识为用户端B的用户标识，在其他实施例中，如果有多个输出，每个交易地址对应一个用户标识)使用秘密共享算法加密发送给用户端A，该秘密共享者为用户端A、交易地址对应的用户端和管理端，只有这三者的秘密共享子密钥能解密数据；用户端A解密用户标识的明文并验证是否正确，并在相应的交易数据中包含该密文的用户标识，就能在具有密钥的情况下追溯输出地址的用户标识；
可选的，管理端还可以将用户端A的用户标识使用秘密共享算法加密发送给用户端A，该秘密共享者为用户端A和管理端，只有这两者的秘密共享子密钥能解密数据；
nonce值和用户端的密钥(如对称加密密钥)通过一单向不可逆函数得到前文所述K值，进而根据前文所述的方法得到用户端的一个新交易地址；该K值可称为交易地址对应的K值，该nonce值可称为交易地址对应的nonce值；管理端需确保通过nonce值计算出的本次交易用户的新交易地址在系统内都是唯一的；
用户注册时管理端会生成该用户的初始nonce值，并使用该用户的密钥(如对称加密密钥)加密存储在控制数据集中，并在系统状态树中记录该nonce值生成的用户交易地址，也即用户的第一个接收交易地址；
步骤30，用户端A可使用本地钱包中的最后一个接收交易数据中的nonce值计算出自己的找零地址，找零地址也即用户端A的接收交易地址，生成方式同步骤20中的交易地址，当需要给自己找零时，将作为本次交易的 输出地址(一个交易的多个输出之一)；
本步骤为可选步骤，如果用户端A需要找零，则执行本步骤，如果不需要找零，则步骤20后直接执行步骤40；
在步骤20中管理端将用户端A的用户标识使用秘密共享算法加密发送给用户端A，该秘密共享者为用户端A和管理端；这样在交易数据中还包含找零地址对应的该密文的用户标识；
因为UTXO模型的输入是引用未花费的交易输出，所以包含输出地址对应的密文用户标识，就能追溯交易输入的密文用户标识；
步骤40，用户端A获取本次交易的输入所引用的未花费交易输出的交易地址对应的K值，根据前文所述方法得到交易地址对应的公私钥对，使用该私钥对不含解锁脚本的交易数据进行签名，连同该公钥数据，产生未花费交易输出对应的解锁脚本；交易数据中包含步骤20的交易输出地址和nonce值，如果有的话，还包含步骤30的找零地址；除token数额为机密交易的密文和输出地址对应的用户标识(可选)为密文外，其余数据都为明文；用户端A向管理端提交包含解锁脚本的交易数据；用户端A向管理端提交的包含解锁脚本的交易数据包括：版本信息、引用未花费的交易输出和对应的解锁脚本、密文的用户标识(可选)、密文的token数据、锁定脚本、nonce值(步骤20中获得)、时间戳；锁定脚本包括：交易输出地址和解锁方式。
本实施例的方法中由于交易数据中包含一次性交易地址(根据上一次接收交易的nonce值计算得出)和nonce值(用于生成下一次接收交易的交易地址)，所以对同一用户而言，该用户的所有接收交易数据即未花费的交易输出形成了或有兄弟节点的逻辑链条；而未花费交易输出的交易地址对应的K值，可通过引用接收交易数据的上一个接收交易数据中的nonce值计算得到的，计算方式同步骤20中的计算K值；
步骤50，管理端验证用户端A提交的交易数据的有效性，包括验证用户状态的有效性，解锁脚本的有效性，token数额的有效性，以及交易地址是否是有效的地址；
管理端验证交易地址是否是有效的地址时，可以从系统状态树中的用户 交易地址和管理端缓存过期时间内新生成的交易地址缓存中查询，验证交易地址是否是对应用户的地址并且没有过期；
步骤60，管理端验证交易数据通过后，对交易数据进行背书签名，并且通知管理端的私有链系统上链；由管理端的链生成机构把背书后的交易数据写入私有链的账本数据中，然后生成的区块数据同步到对外公有链的链生成节点；
管理端在通知上链时，验证交易数据中的用户交易地址与系统状态树中的用户交易地址是否相同，如果相同，则使用该交易的nonce值和用户端的密钥(如对称加密密钥)通过一单向不可逆函数得到一个K值，进而得到一个对应的交易地址；生成方式同步骤20中的交易地址；使用该交易地址更新系统状态树中对应的用户交易地址；
由此可见，对同一个接收用户端而言，下一个接收交易的地址是该用户本次接收交易数据中的nonce值和该用户密钥计算得出，而用户初始nonce值是在注册时加密存储在链上；所以用户通过获取初始nonce值，就能计算出第一个接收交易地址，通过地址获取到接收交易数据，并通过交易数据中的nonce值就能计算出下一个接收交易地址，进而通过nonce值和交易地址使用户的接收交易数据形成逻辑链条；
而在多个用户端给该用户发起并发交易时，管理端从系统状态树中获取到的交易地址是同一个地址；只有当第一个提交交易数据并通过后，才会修改系统状态树中的交易地址为下一个地址；所以存在并发交易时使用相同地址的情况，而这些相同地址的接收交易数据形成逻辑链条上的兄弟节点；
用户端的本地钱包根据该用户的初始nonce值，就能获取到该用户的所有接收交易数据；并由于UTXO模型中用户所有的发送交易都需引用相应的未花费交易输出作为输入，也即引用接收交易数据，所以用户能检索到所有的接收交易数据，就能通过相关交易的引用从而检索所有的发送交易数据；用户端本地钱包保存了该逻辑链条的关系，而用户端的一个接收交易中的交易地址是通过对应的上一个接收交易数据中的nonce值计算得出的；这也就解释了步骤40中用户能够直接查找到未花费交易输出的上一个接收交易数据的nonce值，进而能够解锁该未花费交易；
步骤70，用户端B通过本地钱包的最后一个接收交易数据的nonce值计算出交易地址，利用该交易地址查询账本数据，即可查找到本次交易数据，该交易输出地址连同锁定脚本即产生一个新的未花费交易输出，并且只有用户端B能生成对应的解锁脚本，而外部并不知道该交易地址与用户端B的关联。
从上可得出本次交易的输出地址，是对应用户端的上一个接收交易的nonce值计算得出，所以输出用户端的本地钱包根据最后一个接收交易数据的nonce值计算出的交易地址，并在对外的公有链上查找该地址的交易数据，当本次交易数据上链写入账本数据后，就能通过该地址查找到本次交易数据。而这个查找的过程并不依赖任何消息通知机制，也不依赖管理端，用户端可自行在对外的公有链上根据交易地址进行查找。
用户端的每一个发送交易的输入都需引用相应的未花费交易输出，且不存在次序关联，所以用户端的发送交易也可以进行并发操作，并具有防重放攻击的功能。
采用本实施例方法，用户端、链生成节点，以及第三方和监管者等都可以验证对外的公有链交易数据中每笔交易的管理端的背书签名，用户端的解锁签名，以及密文验证机密交易数额的有效性，但并不知道对应的用户信息和交易数额，也不会知道用户的账户交易链，从而达到用户数据隐私的目的。
用户端的本地钱包是一个轻量级的钱包，只需要同步对外公有链的区块头数据即可，再获取控制数据中加密的用户身份信息和加密的初始nonce值，就可以获取到用户的相关信息和账户交易链，而无需同步其它与用户无关的数据。而公有链区块头的数据量很少，用户只需同步少量数据即可，完全满足移动设备的存储需求。用户端根据区块头数据，还可以使用SPV(Simplified Payment Verification)验证该交易是否存在，只需少量其它交易数据的哈希运算结果即可。并且用户端或管理端只需授权相应的加密密钥，监管者和第三方就可以在对外的公有链上获取该用户的账户交易链，快速检索用户相关的所有交易数据。系统只有管理端的私有链和对外的公有链的链生成节点需要存储全部的区块数据，在能保障账本数据安全的情况下，大大减小了账本数据的存储冗余，节省相关资源。
在一个可选实施例中，系统还可以设置一个特殊的公开身份的转换机构账户。其作用是当用户只有不可导出的本地签名密钥并且丢失时，由用户端本地生成一个新的签名密钥并通过更新的身份认证证书或eID在系统中更新用户信息，并由管理端颁发新的加密密钥和生成新的初始nonce值(更新账户交易链)。但由于用户端新的签名密钥并不能解锁之前的锁定脚本，所以需由转换机构账户生成一个特殊的转换交易。该转换交易由管理端审核用户更新通过后，由管理端的系统发起。转换交易中只包含一笔输入和一笔输出，交易的输入是引用用户原账户的一笔未花费的交易输出，交易的输出是用户新生成的交易地址，转换机构账户对该交易数据进行签名，生成一个特殊的第一解锁脚本，使用户原账户的一笔未花费的交易输出转换为一笔新的未花费交易输出。这样就能通过转换交易解决用户的本地签名密钥丢失后资产损失的问题。而转换交易除特殊的解锁脚本外，其余和普通的交易一致，所以外部并不知道对应的用户信息和交易数额，以保护用户的身份隐私。而特殊的解锁脚本使用的是公开身份的转换机构账户的签名，所以外部可以验证该签名并能知道该交易为转换交易。转换交易也按照前文所述的链式结构使转换交易在用户新的账户交易链上。由于转换交易是由管理端的系统发起，所以需要监管转换交易的输入和输出是否是同一个用户的交易地址，由管理端授权相应的密钥给监管者(或K值参数，验证用户的证书签名公钥与K值运算结果生成对应的地址)，监管者可在对外的公有链上进行验证。
在一个可选实施例中，系统的用户密钥和证书可具有定期更新机制，并且同时更新用户的账户交易链。所以之前账户交易链上的所有未花费输出，会转移到新的账户交易链上。因此旧的区块数据里的交易数据会因为更新不再具有未花费输出，管理端可通过策略对旧的区块数据进行归档和裁剪。而客户端因为重建了账户交易链，也可使客户端的数据量长期保持可控范围。
上述示例中账户交易链关联的是用户所有的接收交易，为使用户所有的发送交易最后都能关联到账户交易链上，可输入一个大于需要花费的数额，使在步骤30，具有一个找零输出，或者强制输出一个数额为零的找零输出(更新账户交易链时需把未花费的输出转移到新的账户交易上，所以尽量避免零输出)。这样所有的发送交易都会生成一个找零输出，关联到用户的账户交 易链上，从而把用户所有的交易都关联到账户交易链上。
用户端的交易数据只需要较短的时间就能同步到对外的公有链的链生成节点(私有链产生一个数据块并同步到链生成节点的时间)，这时用户端就可以通过接收交易地址查询到交易信息并可获取到交易数据，以及验证管理端的背书签名，用户端的解锁签名和交易数额，但此时的交易数据是还没有添加到对外的公有链上的，在小额交易的情况下，用户可以认为交易已经成功。在大额交易的情况下为确保交易成功，可以等待一段时间，等交易数据添加到对外的公有链上并经过了几个确认，通过SPV验证了相关信息，就可以认为交易一定存在并且不可篡改也不可逆了。
本实施例系统中管理端、用户端以及机构的签名密钥和对称加密密钥包括其对应的算法都可以更新，因为没有相互依赖，所以部分用户更新不会造成不可用的问题。秘密共享子密钥和机密交易密钥部分用户更新密钥也不会造成不可用的问题，更新秘密共享算法可以给用户端同时发行新旧算法对应的密钥，然后在某个区块高度上启用新的秘密共享算法，所以也不会造成不可用的问题。但更新机密交易算法则会带来新旧算法的用户不能相互交易的问题，并且如果更新算法造成不能密文验证交易数额，会导致系统的token总量不确定的问题。为确保系统的token总量是一定的，机密交易算法更新可采用回收再发行的策略。因为新旧机密交易算法不能互通，所以可认为新旧算法的token是等值但并不相同的，通过逐步回收再发行等值的新旧token到发行机构上，再通过发行机构回收和发行新旧token到用户，系统里也同时存在新旧token的交易，就能使系统逐步过渡完成新旧token的替换，并在替换过程中能确保系统中的新旧token的总量是一定的。系统的哈希算法也可以在某个区块高度上启用新的哈希算法，通过新旧地址的替换，就能使系统逐步完成过渡。上述可采用部分用户更新也即系统可采用分批逐次更新的机制。如果需要更新用户的账户交易链，则颁发新的用于生成交易地址的密钥以及新的初始nonce值，并可指定在某个区块高度上生效。所以系统的密码算法都可以更新，未来可以更新升级为具有安全保障的抗量子计算的密码算法。
以上管理端的私有链系统并不局限于私有链系统，还可以采用联盟链的 方式。而对外的公有链系统并不局限于公有链系统，也可以采用联盟链的方式，并且可以加强数据的安全性，以下举例说明。
为确保数据的安全性，防止由于量子计算机出现用户密钥被破解而导致隐私泄露的问题，对外的公有链系统可采用对外的联盟链的方式。控制数据中的明文数据对外公开，但涉及用户身份隐私的加密数据和加密初始nonce值并不对外公开。交易数据中的输入引用和输出地址数据以及时间戳数据对外公开，交易数额和地址参数以及可选的加密用户标识不对外公开。对外系统的区块头数据对外公开，由于联盟链的共识方式是确定的，一旦达成共识是不可逆转的，所有的用户端、第三方和监管者都同步对外系统的区块头数据，并且可以快速进行相互验证(例如比对秘密消息与初始区块号到指定区块号的区块头数据的散列值以及指定区块号到最后区块号的区块头数据生成的哈希运算结果)，所以认为区块头数据是可信的。并且可以把交易数据中不对外公开的数据(交易数额、地址参数和可选的加密用户标识)使用具有防止量子计算破解的哈希运算结果替换交易数据中需要签名的不对外公开数据，对输入引用也使用替换的数据。这样外部也可以通过UTXO的输入引用和输出地址验证交易是否引用未花费输出并且没有双花，并能获取交易的时间信息，以及验证交易数据的管理端的背书签名和用户端的解锁签名。用户端、监管者和链生成节点才能获取到不公开的数据完成交易数额的验证(密文验证)，并且用户端只能获取到自己相关交易数据中的不公开数据，用户端还可以通过SPV验证检查交易数据是否存在。而通过nonce值和加密密钥计算下一个接收交易地址的参数K值可采用具有防止量子计算破解的哈希运算，也即对同一个交易里的多个用户而言，也不能通过共享的信息获取到别的用户的账户交易链，并且由于区块头数据是可信的，通过SPV验证也只需获取其它交易数据的哈希运算结果，所以也就在不泄漏关键信息的情况下达到用户数据可信的目的。即使由于量子计算机的出现而导致公开的UTXO的输入引用和输出地址对应的密钥被破解，但由于并不公开交易数额和地址参数，也就不能获取到相关的交易数额，以及相关的输出地址是通过哪个用户的公钥运算得到的，因为所有的用户公钥都有相关的可能性(都能找到相应的K`值)，也不能获取到用户的账户交易链，所以也就保护了用户的身份隐 私。在多重签名地址的情况下，生成多重签名地址的每个公钥相关的K值参数需采用不同方式产生出不同的K值，以避免使用相同K值导致隐私泄露。上述控制数据和交易数据中不对外公开的数据在计算Merkle Tree根哈希时也可以替换为具有防止量子计算破解的哈希运算结果，第三方也可以验证链的正确性以防止篡改。因为系统的密码算法可以更新，未来可以更新升级为具有安全保障的抗量子计算的密码算法，就能使系统平稳过渡，并不会由于公开的数据泄露之前交易数据用户的隐私。
对外的公有链上交易验证可分为两步分别进行。第一步是验证交易的输入引用是否正确，有无双花，区块头的有效性等。这一步只需验证输入引用和输出地址，以及区块数据的哈希运算结果，验证速度非常快，即使是对外的联盟链这部分数据也是完全公开透明的，所以可作为公开的验证服务。第二步是验证交易数据的签名和交易数额，验证速度比较慢，并且是对外的联盟链时验证交易数额需要不公开的部分交易数据。因为交易数据之间是相互独立的，所以可以使用并行的方式进行验证。链生成节点可采取相应策略以避免因为海量数据而造成性能瓶颈。
本实施例中，为鼓励并保障公有链上记录数据是符合系统规则的，由管理端的私有链发行共识奖励并同步到公有链上。系统的共识奖励过程可以包括：管理端获取公有链上要奖励的链生成节点的相关信息，等待多个(比如6个)公有链的区块数据确认后，在控制数据中明文发布奖励到相应的账户中，然后根据控制数据中奖励的信息在交易数据中生成一个特殊的奖励交易(参见下文的系统token发行)。可见，公有链上的共识奖励会在后面的数据块中由管理端进行颁发，并且奖励是不可逆的，奖励规则由管理端自定。链生成节点在产生链的信息中保存由最后一个账户交易链的地址参数生成的接收交易地址，管理端会把相应的共识奖励发行到相应的地址中，所以该奖励交易也是在用户账户交易链上。
系统中的token总量变化由管理端控制，由管理端在控制数据中明文发行或回收相应数量的token，通过指定的发行机构，生成一次特殊的发行或回收交易。首先需要在控制数据中发布相应的发行或回收明文信息(本次发行或回收的地址、交易数额明文和相关K值参数等)后，才可以在后续的交易 数据中生成该特殊交易。如果是发行则是输入引用地址为特定的本次发行地址，相应数额为控制数据中对应的数额明文，输出地址是发行机构的公钥和K值运算的地址(属于发行机构的账户交易链)，以及相应的密文数额。如果是回收则是输入引用发行机构的公钥和K值运算的地址(属于发行机构未花费的输出)，输出地址为特定的本次回收地址，相应数额为控制数据中对应的数额明文，余额则按密文方式输出。奖励交易类似发行交易。特殊交易可公开部分参数，可以验证具有部分明文的机密交易。可以看出发行(或奖励)和回收交易都需有特定地址的参与，比如发行用(10…0X)，回收用(20…0X)，奖励用(30…0X)，其中X表示递增，这些特定的地址并不具有UTXO地址的上下文关系，输入不需要引用未花费交易输出，输出也不能作为输入，并且发行或奖励交易只需要管理端的背书签名，回收交易需要相应发行机构的解锁签名和管理端的背书签名。通过这些特定地址的发行或回收，以达到调节系统中token总量的目的，而这些信息都是明文公开的，以方便监管。可选的在控制数据中发布相应明文信息后，需要经过一定比例的公有链的链生成节点投票确认后才能生效。投票结果记录在公有链上，也即公有链上除了包含私有链的区块数据外，还可以包含公有链的扩展数据，例如投票结果，但扩展数据只是公有链自身的数据状态，不会影响公有链和私有链逻辑状态的不同。对外公有链的区块头数据包括私有链区块中交易数据生成的Merkle Tree根哈希，控制数据以及私有链区块头数据和公有链的扩展数据生成的Merkle Tree根哈希，还有上一个公有链区块头的哈希值、区块号、时间戳、共识参数等。公有链上可以快速验证公有链的区块头数据，也可以快速验证管理端私有链的区块头数据，并且私有链的区块头数据是具有相关签名以防止伪造。管理端验证公有链上的投票信息后，才能在交易数据中生成相关的特殊交易。
本实施例中，为了有效的监管本实施例系统，可采用自动监管和/或人为参与监管。自动监管主要是监管交易数据，验证交易是否合法(比如账户是否冻结，证书有无注销、过期等)，管理端背书签名和用户端解锁签名是否正确，机密交易数额是否正确，如果是发行或回收交易是否在之前的控制数据中有相关信息，如果是转换交易输入和输出是否是同一个用户的交易地址。 自动监管和链生成节点都能验证交易数额的有效性，确保系统中token的总量是一定的。而人为参与的监管一部分是通过监管控制数据中发布的明文信息，主要包括发行的token数额是否合法，比如需要管理端具有相关资产抵押或保证金证明等才能发行相应的token；另一部分是需要监管系统中某些用户的账户信息，管理端可授权相应用户端的加密密钥给监管者，监管者就能获取该用户的账户交易链和资产信息。
由上文可以看出，账户交易链和区块链是不同的，区块链是物理的、外部的、公开的，而账户交易链是逻辑的、内部的、隐蔽的。区块链解决的是可追溯、不可篡改等问题，而账户交易链解决的是隐私和易用等问题，并且账户交易链是无数条融入到区块链里的。
可以把上述的中心化与去中心化结合的系统看作是一个具有管理端的区块链系统。多个具有管理端的区块链系统之间的数据流转可以通过在该多个系统的管理端之间建立秘密通道实现。秘密通道上可以不存储重要数据，仅作为数据协商和触发链间流转的通道，用户合约数据都在各自区块链系统上存储。因此用户端可以在对外的公有链上查询相关的合约数据，并通过跨链合约ID，使不同系统之间数据流转的合约数据关联起来，用户端的钱包就可以获取跨链合约的关联信息。秘密通道可以采用在多个管理端之间建立联盟链的方式实现。
在多个区块链系统之间进行数据流转时，交易双方需要在要流转的系统中进行注册。比如，用户A向系统SA和系统SB的管理端进行注册，用户B向系统SA和系统SB的管理端进行注册。由于交易双方的用户端并不知道交易的对方是谁，所以需要进行托管合约声明。托管合约的声明类似上述的交易，用户端签名并由管理端背书签名上链后生效，用户资产就转移至用户的托管账户中。用户的托管账户可以按照前文所述的方式建立单独的用户托管账户交易链，托管账户的签名密钥可由第三方或管理端进行托管，由管理端在触发托管账户交易时使用。托管合约交易的公平性由管理端之间的联盟链保证，合约交易中需要包含跨链合约ID。用户端的钱包通过公有链上的托管账户交易链就能获取到所有的托管交易，通过合约交易中的跨链合约ID，就可以在对应流转的另一个公有链上的用户托管账户交易链中查询包含 该跨链合约ID相关的合约交易。用户端的钱包获取到托管合约声明信息和分别在两个系统的流转合约交易信息后，就可以分析相关合约的执行情况。
在本示例中，在多个具有管理端的区块链系统之间，交易双方用户端的跨链合约交易并不会影响各自系统中token总量的变化，只是双方系统内不同用户token流转的过程。链生成节点和监管者都可以验证各自系统内的托管合约交易数额的有效性，确保系统中token的总量是一定的。而在多个具有管理端的区块链系统之间，管理端相互建立了联盟链后，就可以实现用户数据在系统间的流转，并且流转的数据都在相应的公有链上记录并可查询验证，也方便进行监管。
以上示例是通过UTXO模型的交易地址形成的账户交易链，还可以用类似的方式形成账户交易链，以下通过系统是账户余额模型为例说明。系统是账户余额模型时，由于不存在输入引用地址和输出地址的概念，交易数据中只有用户账户标识和对应的交易数额，用户端的发送交易和接收交易也没有依赖关系，所以可以通过发送交易ID和接收交易ID，使用户端的交易数据形成一个发送链条和一个或有兄弟节点的接收链条。其中，发送交易ID是由用户端上次发送交易的nonce值和用户端的加密密钥通过一单向不可逆函数产生，发送交易ID在系统中是唯一的；接收交易ID由用户端上次接收交易的nonce值和用户端的加密密钥通过一单向不可逆函数产生，在系统中不同用户端的接收交易ID是唯一的，但因为存在并发交易的原因，所以存在同一个用户端的不同接收交易具有相同的接收交易ID。用户端在向管理端注册时，由管理端生成一随机的初始nonce值和初始接收交易ID，并使用用户端的对称加密密钥进行加密存储。在交易时由nonce值和用户端的加密密钥通过一单向不可逆函数产生发送交易ID。nonce值由管理端随机生成，并确保计算出的下一个发送交易ID和接收交易ID(对于接收者)在系统中都是唯一的。而初始接收交易ID则是用户的第一个接收交易的ID，当有用户的接收交易ID等于状态树中的用户接收交易ID时，则用交易的nonce值和用户的加密密钥生成的接收交易ID更新状态树中的接收交易ID。可以看出发送交易ID需依赖上次发送交易的nonce值(或初始nonce值)，且不能够进行并发交易，以防止重放攻击，所以形成了一个发送链条。而接收交易ID 使用类似上文所述的接收交易地址方式，所以形成了一个或有兄弟节点的接收链条。这两条链就形成了系统是账户余额模型时的账户交易链。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、装置中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由一个或多个物理组件合作执行。某些组件或所有组件可以被实施为由处理器，如数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。
本领域的普通技术人员应当理解，可以对本申请实施例的技术方案进行修改或者等同替换，而不脱离本申请技术方案的精神和范围，均应涵盖在本申请的权利要求范围当中。

Claims (25)

  1. 一种数据处理方法，包括：
    交易数据验证通过且背书签名后被写入第一链系统的区块数据中；
    所述第一链系统的区块数据被写入第二链系统的区块数据中，所述第二链系统的区块数据由所述第一链系统的一个或多个区块数据顺序组成，所述第一链系统上任一账户的状态与所述第二链系统上所述账户的状态一致。
  2. 根据权利要求1所述的方法，其中，
    所述第一链系统包括私有链，所述第二链系统包括公有链或联盟链；或者
    所述第一链系统包括联盟链，所述第二链系统包括公有链或联盟链。
  3. 根据权利要求1或2所述的方法，其中，所述交易数据验证通过且背书签名后被写入第一链系统的区块数据中，包括：
    对交易数据验证通过后，对所述交易数据进行背书签名，背书签名后的交易数据将被写入第一链系统的区块数据中；
    其中，所述交易数据包括交易接收端的交易地址和本次交易时生成的地址参数，所述交易地址利用所述交易接收端上次接收交易时生成的地址参数生成，所述本次交易时生成的地址参数用于生成所述交易接收端下次接收交易的交易地址，使同一交易接收端的所有接收交易数据形成逻辑链式结构。
  4. 根据权利要求3所述的方法，
    对交易数据验证之前，所述方法还包括：生成地址参数，从状态树查找所述交易接收端的交易地址，将生成的地址参数和查找到的所述交易地址发送给交易发送端，以使所述交易发送端将所述交易地址和地址参数添加到交易数据中；
    对所述交易数据进行背书签名后，所述方法还包括：判断所述交易数据中的交易地址与所述状态树中的所述交易接收端的交易地址相同时，利用所述生成的地址参数生成新的交易地址，并更新所述状态树中的所述交易接收端的交易地址。
  5. 根据权利要求4所述的方法，其中，所述利用所述生成的地址参数生成新的交易地址，包括：
    利用函数对所述生成的地址参数以及所述交易接收端的密钥进行一次或多次运算，生成交易地址。
  6. 根据权利要求5所述的方法，其中，
    所述交易接收端的交易地址采用以下方式生成：利用第一函数对所述地址参数以及所述交易接收端的用户密钥进行运算得到第一中间值，利用第二函数对所述第一中间值以及所述交易接收端的用户公钥进行运算得到一第一公钥，利用第三函数对所述第一公钥进行运算得到交易地址；或者
    所述交易接收端的交易地址为多重签名地址，所述多重签名地址采用以下方式生成：利用不同的函数对所述地址参数以及所述交易接收端的用户密钥进行运算得到多个中间值，利用第四函数分别将每个中间值与所述交易接收端的多个用户公钥进行运算得到多个新公钥，利用第五函数对所述多个新公钥进行运算得到多重签名地址。
  7. 根据权利要求5所述的方法，所述方法还包括：
    在用户注册时，生成所述用户的初始地址参数，并在状态树中记录由所述初始地址参数生成的交易地址；或者
    重新为被颁发了新密钥的用户生成初始地址参数，并在状态树中记录由所述重新生成的初始地址参数生成的交易地址，所述新密钥为用于生成交易地址的密钥。
  8. 根据权利要求3所述的方法，所述方法还包括：
    收到用户端发起的密钥更新请求，对所述用户端进行身份认证后，颁发新的加密密钥，发起转换交易流程，使转换机构账户发起交易，由所述转换机构账户的签名密钥对所述交易数据进行签名，生成第一解锁脚本，以将所述用户端原账户中的未花费的交易输出转换为新的未花费交易输出。
  9. 根据权利要求1所述的方法，所述方法还包括以下步骤中的一个或多个：
    生成用于发行通证token的指定发行交易，所述指定发行交易中的输入 地址为采用第一格式的地址；
    生成用于回收token的指定回收交易，所述指定回收交易中的输出地址为采用第二格式的地址；
    生成用于奖励token的指定奖励交易，所述指定奖励交易中的输入地址为采用第三格式的地址。
  10. 一种数据处理方法，所述方法包括：
    交易接收端根据上一次接收交易数据中的地址参数生成本次接收交易的交易地址，从第二链系统中查找包含所述交易地址的交易数据；所述第二链系统中的区块数据由第一链系统的一个或多个区块数据顺序组成，所述第一链系统上任一账户的状态与所述第二链系统上所述账户的状态一致。
  11. 根据权利要求10所述的方法，所述方法还包括：
    将通过管理端从状态树获取到的账户状态与从第二链系统获取到的账户状态进行比对。
  12. 根据权利要求10所述的方法，当所述交易接收端作为交易发送端时，所述方法还包括：
    所述交易发送端提交交易时，使用引用接收交易数据的上一次接收交易数据中的地址参数生成公私钥对，使用所述公私钥对生成当前交易中的解锁脚本。
  13. 一种数据处理方法，所述方法包括：
    发起转换交易，使用转换机构账户的签名密钥对所述交易数据进行签名，生成第一解锁脚本，以将用户端原账户中的未花费的交易输出转换为新的未花费交易输出，由所述转换机构账户发起的交易形成的交易数据验证通过且背书签名后被写入第一链系统的区块数据中，所述第一链系统的区块数据被写入第二链系统的区块数据中，所述第二链系统的区块数据由所述第一链系统的一个或多个区块数据顺序组成，所述第一链系统上任一账户的状态与所述第二链系统上所述账户的状态一致。
  14. 一种管理端装置，所述管理端装置包括验证模块和背书签名模块，其中：
    所述验证模块，设置为对交易数据进行验证；
    所述背书签名模块，设置为在所述验证模块对交易数据验证通过后，对所述交易数据进行背书签名，背书签名后的交易数据将被写入第一链系统的区块数据中；
    其中，所述交易数据包括交易接收端的交易地址和本次交易时生成的地址参数，所述交易地址利用所述交易接收端上次接收交易时生成的地址参数生成，所述本次交易时生成的地址参数用于生成所述交易接收端下次接收交易的交易地址，使同一交易接收端的所有接收交易数据形成逻辑链式结构。
  15. 根据权利要求14所述的管理端装置，
    所述装置还包括第一地址生成模块，其设置为生成地址参数，以及从状态树查找所述交易接收端的交易地址，将生成的地址参数和查找到的所述交易地址发送给交易发送端；以及设置为判断所述交易数据中的交易地址与所述状态树中的所述交易接收端的交易地址相同时，利用所述生成的地址参数生成新的交易地址，并更新所述状态树中的所述交易接收端的交易地址。
  16. 根据权利要求15所述的管理端装置，其中，
    所述第一地址生成模块利用所述生成的地址参数生成新的交易地址，包括：所述第一地址生成模块利用函数对所述生成的地址参数以及所述交易接收端的密钥进行一次或多次运算，生成交易地址。
  17. 根据权利要求16所述的管理端装置，其中，
    所述第一地址生成模块采用以下方式生成所述交易接收端的交易地址：所述第一地址生成模块利用第一函数对所述地址参数以及所述交易接收端的用户密钥进行运算得到第一中间值，利用第二函数对所述第一中间值以及所述交易接收端的用户公钥进行运算得到一第一公钥，利用第三函数对所述第一公钥进行运算得到交易地址；或者
    所述第一地址生成模块采用以下方式生成所述交易接收端的交易地址，所述交易接收端的交易地址为多重签名地址，所述第一地址生成模块利用不同的函数对所述地址参数以及所述交易接收端的用户密钥进行运算得到多个中间值，利用第四函数分别将每个中间值与所述交易接收端的多个用户公钥 进行运算得到多个新公钥，利用第五函数对所述多个新公钥进行运算得到多重签名地址。
  18. 根据权利要求16所述的管理端装置，其中：
    所述第一地址生成模块还设置为在用户注册时，生成所述用户的初始地址参数，并在状态树中记录由所述初始地址参数生成的交易地址；以及
    所述第一地址生成模块还设置为重新为被颁发了新密钥的用户生成初始地址参数，并在状态树中记录由所述重新生成的初始地址参数生成的交易地址，所述新密钥为用于生成交易地址的密钥。
  19. 根据权利要求14所述的管理端装置，
    所述装置还包括颁发密钥模块和转换交易模块，其中：
    所述颁发密钥模块，设置为收到用户端发起的密钥更新请求，对所述用户端进行身份认证后，颁发新的加密密钥；
    所述转换交易模块，设置为发起转换交易流程，使能转换机构账户发起交易，由所述转换机构账户的签名密钥对所述交易数据进行签名，生成第一解锁脚本，以将所述用户端原账户中的未花费的交易输出转换为新的未花费交易输出。
  20. 根据权利要求14所述的管理端装置，所述装置还包括以下模块中的一个或多个：发行交易模块、回收交易模块和奖励交易模块，其中：
    所述发行交易模块，设置为生成用于发行token的指定发行交易，所述指定发行交易中的输入地址为采用第一格式的地址；
    所述回收交易模块，设置为生成用于回收token的指定回收交易，所述指定回收交易中的输出地址为采用第二格式的地址；
    所述奖励交易模块，设置为生成用于奖励token的指定奖励交易，所述指定奖励交易中的输入地址为采用第三格式的地址。
  21. 一种用户端装置，所述用户端装置包括第二地址生成模块和检索模块，其中：
    所述第二地址生成模块，设置为根据上一次接收交易数据中的地址参数 生成本次接收交易的交易地址；
    所述检索模块，设置为从第二链系统中查找包含所述交易地址的交易数据。
  22. 根据权利要求21所述的用户端装置，
    所述用户端装置还包括验证模块，其设置为将通过管理端从状态树获取到的账户状态与从第二链系统获取到的账户状态进行比对。
  23. 根据权利要求21所述的用户端装置，
    所述用户端装置还包括签名模块，所述签名模块设置为在所述用户端作为交易发送端时，在提交交易时，使用引用接收交易数据的上一次接收交易数据中的地址参数生成公私钥对，使用所述公私钥对生成当前交易中的解锁脚本。
  24. 一种转换装置，所述转换装置包括发起模块和签名模块，其中：
    所述发起模块，设置为根据管理端装置的使能发起转换交易；
    所述签名模块，设置为使用转换机构账户的签名密钥对所述交易数据进行签名，生成第一解锁脚本，以将用户端原账户中的未花费的交易输出转换为新的未花费交易输出；
    由所述转换机构账户发起的交易形成的交易数据验证通过且背书签名后被写入第一链系统的区块数据中，所述第一链系统的区块数据被写入第二链系统的区块数据中，所述第二链系统的区块数据由所述第一链系统的一个或多个区块数据顺序组成，所述第一链系统上任一账户的状态与所述第二链系统上所述账户的状态一致。
  25. 一种计算机可读存储介质，其上存储有计算机指令，该指令被处理器执行时实现权利要求1-9中任一权利要求或者权利要求10-12中任一权利要求或权利要求13所述方法的步骤。
PCT/CN2019/074440 2018-03-14 2019-02-01 区块链数据处理方法、管理端、用户端、转换装置及介质 WO2019174430A1 (zh)

Priority Applications (8)

Application Number Priority Date Filing Date Title
JP2020562824A JP2021512569A (ja) 2018-03-14 2019-02-01 ブロックチェーンのデータ処理方法、管理側、クライアント側、変換装置及び媒体
KR1020207022809A KR20200108024A (ko) 2018-03-14 2019-02-01 블록체인 데이터 처리 방법, 관리단, 사용자단, 전환 장치 및 매체
SG11202006981QA SG11202006981QA (en) 2018-03-14 2019-02-01 Block chain data processing method, management terminal, user terminal, conversion device, and medium
EP19766756.1A EP3731162A1 (en) 2018-03-14 2019-02-01 Block chain data processing method, management terminal, user terminal, conversion device, and medium
AU2019232978A AU2019232978A1 (en) 2018-03-14 2019-02-01 Block chain data processing method, management terminal, user terminal, conversion device, and medium
US16/965,788 US20210042744A1 (en) 2018-03-14 2019-02-01 Block chain data processing method, management terminal, user terminal, conversion device, and medium
CA3088712A CA3088712A1 (en) 2018-03-14 2019-02-01 Block chain data processing method, management end, user end, conversion apparatus and medium
BR112020016151-9A BR112020016151A2 (pt) 2018-03-14 2019-02-01 Método para processar processamento de dados, método para processar dados, aparelho de extremidade de gerenciamento, aparelho de extremidade de usuário e meio de armazenamento legível por computador

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
CN201810210284.5A CN108416578A (zh) 2018-03-14 2018-03-14 一种区块链系统及数据处理方法
CN201810210284.5 2018-03-14
CN201810411150.X 2018-05-02
CN201810411150.XA CN108647964B (zh) 2018-05-02 2018-05-02 一种区块链数据处理方法、装置及计算机可读存储介质

Publications (1)

Publication Number Publication Date
WO2019174430A1 true WO2019174430A1 (zh) 2019-09-19

Family

ID=67907351

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2019/074440 WO2019174430A1 (zh) 2018-03-14 2019-02-01 区块链数据处理方法、管理端、用户端、转换装置及介质

Country Status (9)

Country Link
US (1) US20210042744A1 (zh)
EP (1) EP3731162A1 (zh)
JP (1) JP2021512569A (zh)
KR (1) KR20200108024A (zh)
AU (1) AU2019232978A1 (zh)
BR (1) BR112020016151A2 (zh)
CA (1) CA3088712A1 (zh)
SG (1) SG11202006981QA (zh)
WO (1) WO2019174430A1 (zh)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111181730A (zh) * 2019-12-31 2020-05-19 航天信息股份有限公司 用户身份生成及更新方法和装置、存储介质和节点设备
CN111212026A (zh) * 2019-11-21 2020-05-29 深圳壹账通智能科技有限公司 基于区块链的数据处理方法、装置及计算机设备
CN111275554A (zh) * 2020-01-22 2020-06-12 北京瑞卓喜投科技发展有限公司 一种证券型通证的交易方法和系统、存储介质
CN111598701A (zh) * 2020-05-22 2020-08-28 深圳市网心科技有限公司 一种信息监控方法、系统、设备及存储介质
CN111640017A (zh) * 2020-05-06 2020-09-08 深圳前海微众银行股份有限公司 一种应用于联盟链跨链转账的交易正确性验证方法及装置
CN113328854A (zh) * 2021-05-24 2021-08-31 杭州溪塔科技有限公司 基于区块链的业务处理方法及系统
TWI749583B (zh) * 2019-12-16 2021-12-11 鄭傑騫 鏈式結構資料儲存、驗證、實現方法、系統、裝置及媒體
WO2022000134A1 (zh) * 2020-06-28 2022-01-06 天津理工大学 一种基于供应链管理的商业数据保护方法及系统
JP2022542168A (ja) * 2020-02-26 2022-09-29 テサ カンパニー リミテッド 透明な取引履歴の管理を可能にする資産取引システム
CN115170322A (zh) * 2022-09-05 2022-10-11 深圳市明源云科技有限公司 不动产产权的转让方法、装置、终端设备及计算机介质
JP2023509006A (ja) * 2020-04-24 2023-03-06 ▲騰▼▲訊▼科技（深▲セン▼）有限公司 ブロックチェーンデータのアーカイブ方法、ブロックチェーンデータのアーカイブ装置、電子機器、及びコンピュータプログラム
JP7432443B2 (ja) 2020-05-28 2024-02-16 株式会社日立製作所 移行支援システム、移行支援方法、およびノード

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018123463A1 (de) * 2018-09-24 2020-03-26 Akarion GmbH Personendatenbank
EP3902227A4 (en) * 2018-12-21 2022-12-14 Swempire Co., Ltd. PROCEDURE FOR SHARING AND VERIFICATION OF BLOCKS AND ELECTRONIC DOCUMENTS BETWEEN NODES IN A BLOCKCHAIN
US11838400B2 (en) * 2019-11-19 2023-12-05 International Business Machines Corporation Image encoding for blockchain
US11146386B2 (en) * 2020-01-17 2021-10-12 Agile Blockchain Corp. Method and system for authentication seal deployment in networked immutable transactions
CN111460525B (zh) * 2020-03-31 2024-06-18 腾讯科技（深圳）有限公司 一种基于区块链的数据处理方法、装置及存储介质
CN111626680B (zh) * 2020-06-02 2023-07-25 重庆云创科技有限公司 一种用于信誉评价的交易数据链式存储方法及区块链存储方法
US20220094555A1 (en) * 2020-09-18 2022-03-24 Fujitsu Limited Validator control for transaction between blockchains
US20220114584A1 (en) * 2020-10-08 2022-04-14 Geeq Corporation Apparatus and methods to define and use bearer tokens, certified tokens and applications using bearer tokens and certified tokens
CN112488688B (zh) * 2020-12-17 2024-03-26 广州智链未来科技有限公司 基于区块链的交易处理方法、装置、设备及存储介质
CN112818379B (zh) * 2021-01-11 2023-04-25 北京信息科技大学 一种基于区块链的航空重力数据安全访问控制方法及系统
CN113191756B (zh) * 2021-06-04 2022-07-19 杭州复杂美科技有限公司 跨链资产安全管理方法、计算机设备和存储介质
CN113450225B (zh) * 2021-07-13 2023-07-28 成都质数斯达克科技有限公司 跨链业务管理系统
CN113360861B (zh) * 2021-07-27 2022-07-05 北京理工大学 一种面向抵押贷款的基于中继器跨链的去中心化身份方法
CN113569300B (zh) * 2021-09-27 2021-11-30 环球数科集团有限公司 一种基于云计算的区块链数据处理系统
CN113821536B (zh) * 2021-11-23 2022-03-18 腾讯科技（深圳）有限公司 基于区块链的数据处理方法、装置、设备及可读存储介质
US20220191003A1 (en) * 2021-12-10 2022-06-16 Tamas Mihaly Varhegyi Complete Tree Structure Encryption Software
CN114461623A (zh) * 2022-01-27 2022-05-10 东南大学 一种许可链上授权的非交易有害数据完全擦除方法
CN115208898B (zh) * 2022-03-29 2023-12-08 深圳大学 区块广播方法、装置、计算机设备和存储介质
CN117478303B (zh) * 2023-12-28 2024-03-01 湖南天河国云科技有限公司 区块链隐蔽通信方法、系统和计算机设备

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016170538A1 (en) * 2015-04-20 2016-10-27 Ogy Docs, Inc. A method of distributed management of electronic documents of title (edt) and system thereof
CN106372941A (zh) * 2016-08-31 2017-02-01 江苏通付盾科技有限公司 基于区块链的ca认证管理方法、装置及系统
CN107733855A (zh) * 2017-08-31 2018-02-23 中国科学院信息工程研究所 一种可同时支持公有链、联盟链及私有链的区块链系统及应用方法
KR101837166B1 (ko) * 2016-10-26 2018-03-09 주식회사 코인플러그 블록체인 내의 블록별로 발란스 데이터베이스를 관리하여 통화를 발행 및 지급 결제하는 방법과 이를 이용한 서버
CN107786339A (zh) * 2016-08-31 2018-03-09 陈新 分层可控联盟区块链系统
CN108416578A (zh) * 2018-03-14 2018-08-17 郑杰骞 一种区块链系统及数据处理方法
CN108647964A (zh) * 2018-05-02 2018-10-12 郑杰骞 一种区块链数据处理方法、装置及计算机可读存储介质

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6628188B2 (ja) * 2016-05-10 2020-01-08 日本電信電話株式会社 決済システム、決済方法、トランザクション生成装置及びトランザクション生成プログラム

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016170538A1 (en) * 2015-04-20 2016-10-27 Ogy Docs, Inc. A method of distributed management of electronic documents of title (edt) and system thereof
CN106372941A (zh) * 2016-08-31 2017-02-01 江苏通付盾科技有限公司 基于区块链的ca认证管理方法、装置及系统
CN107786339A (zh) * 2016-08-31 2018-03-09 陈新 分层可控联盟区块链系统
KR101837166B1 (ko) * 2016-10-26 2018-03-09 주식회사 코인플러그 블록체인 내의 블록별로 발란스 데이터베이스를 관리하여 통화를 발행 및 지급 결제하는 방법과 이를 이용한 서버
CA3039899A1 (en) * 2016-10-26 2018-05-03 Coinplug, Inc. Method for issuing currency and making payment by managing balance database for each block in blockchain and server using same
US20190236565A1 (en) * 2016-10-26 2019-08-01 Coinplug, Inc. Method for issuing currency and making payment by managing balance database for each block in blockchain network and server using same
CN107733855A (zh) * 2017-08-31 2018-02-23 中国科学院信息工程研究所 一种可同时支持公有链、联盟链及私有链的区块链系统及应用方法
CN108416578A (zh) * 2018-03-14 2018-08-17 郑杰骞 一种区块链系统及数据处理方法
CN108647964A (zh) * 2018-05-02 2018-10-12 郑杰骞 一种区块链数据处理方法、装置及计算机可读存储介质

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111212026A (zh) * 2019-11-21 2020-05-29 深圳壹账通智能科技有限公司 基于区块链的数据处理方法、装置及计算机设备
TWI749583B (zh) * 2019-12-16 2021-12-11 鄭傑騫 鏈式結構資料儲存、驗證、實現方法、系統、裝置及媒體
CN111181730A (zh) * 2019-12-31 2020-05-19 航天信息股份有限公司 用户身份生成及更新方法和装置、存储介质和节点设备
CN111275554A (zh) * 2020-01-22 2020-06-12 北京瑞卓喜投科技发展有限公司 一种证券型通证的交易方法和系统、存储介质
JP2022542168A (ja) * 2020-02-26 2022-09-29 テサ カンパニー リミテッド 透明な取引履歴の管理を可能にする資産取引システム
JP7330596B2 (ja) 2020-04-24 2023-08-22 ▲騰▼▲訊▼科技（深▲セン▼）有限公司 ブロックチェーンデータのアーカイブ方法、ブロックチェーンデータのアーカイブ装置、電子機器、及びコンピュータプログラム
JP2023509006A (ja) * 2020-04-24 2023-03-06 ▲騰▼▲訊▼科技（深▲セン▼）有限公司 ブロックチェーンデータのアーカイブ方法、ブロックチェーンデータのアーカイブ装置、電子機器、及びコンピュータプログラム
CN111640017A (zh) * 2020-05-06 2020-09-08 深圳前海微众银行股份有限公司 一种应用于联盟链跨链转账的交易正确性验证方法及装置
CN111640017B (zh) * 2020-05-06 2024-05-28 深圳前海微众银行股份有限公司 一种应用于联盟链跨链转账的交易正确性验证方法及装置
CN111598701A (zh) * 2020-05-22 2020-08-28 深圳市网心科技有限公司 一种信息监控方法、系统、设备及存储介质
CN111598701B (zh) * 2020-05-22 2023-09-19 深圳市迅雷网络技术有限公司 一种信息监控方法、系统、设备及存储介质
JP7432443B2 (ja) 2020-05-28 2024-02-16 株式会社日立製作所 移行支援システム、移行支援方法、およびノード
WO2022000134A1 (zh) * 2020-06-28 2022-01-06 天津理工大学 一种基于供应链管理的商业数据保护方法及系统
CN113328854B (zh) * 2021-05-24 2022-09-16 杭州溪塔科技有限公司 基于区块链的业务处理方法及系统
CN113328854A (zh) * 2021-05-24 2021-08-31 杭州溪塔科技有限公司 基于区块链的业务处理方法及系统
CN115170322A (zh) * 2022-09-05 2022-10-11 深圳市明源云科技有限公司 不动产产权的转让方法、装置、终端设备及计算机介质
CN115170322B (zh) * 2022-09-05 2022-12-27 深圳市明源云科技有限公司 不动产产权的转让方法、装置、终端设备及计算机介质

Also Published As

Publication number Publication date
EP3731162A1 (en) 2020-10-28
KR20200108024A (ko) 2020-09-16
US20210042744A1 (en) 2021-02-11
CA3088712A1 (en) 2019-09-19
JP2021512569A (ja) 2021-05-13
AU2019232978A1 (en) 2020-08-13
BR112020016151A2 (pt) 2020-12-08
SG11202006981QA (en) 2020-08-28

Similar Documents

Publication Publication Date Title
WO2019174430A1 (zh) 区块链数据处理方法、管理端、用户端、转换装置及介质
TWI706275B (zh) 用於資訊保護的系統和方法
KR102150814B1 (ko) 정보 보호를 위한 시스템 및 방법
US11080694B2 (en) System and method for information protection
TWI716034B (zh) 用於資訊保護的系統和方法
CN108418680B (zh) 一种基于安全多方计算技术的区块链密钥恢复方法、介质
CN108647964B (zh) 一种区块链数据处理方法、装置及计算机可读存储介质
CN110288480B (zh) 一种区块链的私密交易方法及装置
WO2021120253A1 (zh) 链式结构数据存储、验证、实现方法、系统、装置及介质
Huang et al. Scalable and redactable blockchain with update and anonymity
Chase et al. Transparency overlays and applications
El Defrawy et al. Founding digital currency on secure computation
CN109214921B (zh) 基于云计算的文件加密传输方法
AU2019101590A4 (en) System and method for information protection

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19766756

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2020562824

Country of ref document: JP

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 20207022809

Country of ref document: KR

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2019232978

Country of ref document: AU

Date of ref document: 20190201

Kind code of ref document: A

ENP Entry into the national phase

Ref document number: 2019766756

Country of ref document: EP

Effective date: 20200720

NENP Non-entry into the national phase

Ref country code: DE

REG Reference to national code

Ref country code: BR

Ref legal event code: B01A

Ref document number: 112020016151

Country of ref document: BR

ENP Entry into the national phase

Ref document number: 112020016151

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20200807