JP2021512569A - ブロックチェーンのデータ処理方法、管理側、クライアント側、変換装置及び媒体 - Google Patents

ブロックチェーンのデータ処理方法、管理側、クライアント側、変換装置及び媒体 Download PDF

Info

Publication number
JP2021512569A
JP2021512569A JP2020562824A JP2020562824A JP2021512569A JP 2021512569 A JP2021512569 A JP 2021512569A JP 2020562824 A JP2020562824 A JP 2020562824A JP 2020562824 A JP2020562824 A JP 2020562824A JP 2021512569 A JP2021512569 A JP 2021512569A
Authority
JP
Japan
Prior art keywords
transaction
address
data
chain
chain system
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.)
Pending
Application number
JP2020562824A
Other languages
English (en)
Other versions
JP2021512569A5 (ja
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 ツェン，ジェチエン
Publication of JP2021512569A publication Critical patent/JP2021512569A/ja
Publication of JP2021512569A5 publication Critical patent/JP2021512569A5/ja
Pending legal-status Critical Current

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

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

本願はコンピュータデータ処理技術分野に関し、特にブロックチェーンのデータ処理方法、管理側装置、クライアント側装置、変換装置及びコンピュータ可読記憶媒体に関するが、それらに限らない。
従来の分散化システム、例えばパブリックチェーンシステムは公開、透明、追跡可能、改竄不可能等の特徴を有するため、取引関与者同士の信頼コストを削減することができ、信頼の基礎として価値伝達を実現することができる。
ところが、従来の分散化システムには、効率が低く、完全な監督管理及びプライバシー保護に欠け、ｔｏｋｅｎ（代用貨幣又はトークンと称されてもよい）の発行も関連裏書を行わず、大量のデータにおいてプライベート取引を実現して検索することができないという問題がある。
以下は本明細書において詳しく説明された主題の概要である。本概要は特許請求の範囲を制限するためのものではない。
第１態様では、本願の実施例は管理側のデータ処理方法を提供し、
取引データが検証に成功して裏書署名してから第１チェーンシステムのブロックデータに書き込まれることと、
前記第１チェーンシステムのブロックデータが第２チェーンシステムのブロックデータに書き込まれ、前記第２チェーンシステムのブロックデータが前記第１チェーンシステムの１つ又は複数のブロックデータで順次構成され、前記第１チェーンシステムにおけるいずれか１つのアカウントの状態が前記第２チェーンシステムにおける前記アカウントの状態に合致することと、を含む。
第２態様では、本願の実施例はクライアント側のデータ処理方法を提供し、
取引受信側が前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成し、第２チェーンシステムから前記取引アドレスを含む取引データを検索することを含み、前記第２チェーンシステムにおけるブロックデータが第１チェーンシステムの１つ又は複数のブロックデータで順次構成され、前記第１チェーンシステムにおけるいずれか１つのアカウントの状態が前記第２チェーンシステムにおける前記アカウントの状態に合致する。
第３態様では、本願の実施例は変換装置のデータ処理方法を提供し、
変換取引を開始し、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第１アンロックスクリプトを生成し、それによりクライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換し、前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第１チェーンシステムのブロックデータに書き込まれ、前記第１チェーンシステムのブロックデータが第２チェーンシステムのブロックデータに書き込まれ、前記第２チェーンシステムのブロックデータが前記第１チェーンシステムの１つ又は複数のブロックデータで順次構成され、前記第１チェーンシステムにおけるいずれか１つのアカウントの状態が前記第２チェーンシステムにおける前記アカウントの状態に合致することを含む。
第４態様では、本願の実施例は管理側装置を提供し、検証モジュール及び裏書署名モジュールを備え、
前記検証モジュールは、取引データを検証するように設定され、
前記裏書署名モジュールは、前記検証モジュールが取引データの検証に成功した後、前記取引データを裏書署名し、裏書署名後の取引データが第１チェーンシステムのブロックデータに書き込まれるように設定され、
前記取引データは取引受信側の取引アドレスと今回取引時に生成したアドレスパラメータとを含み、前記取引アドレスは前記取引受信側が前回取引を受信する際に生成したアドレスパラメータを利用して生成したものであり、前記今回取引時に生成したアドレスパラメータは前記取引受信側が次回取引を受信する取引アドレスを生成することに用いられ、同じ取引受信側のすべての受信取引データに論理チェーン構造を形成させる。
第５態様では、本願の実施例はクライアント側装置を提供し、第２アドレス生成モジュール及び検索モジュールを備え、
前記第２アドレス生成モジュールは、前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成するように設定され、
前記検索モジュールは、第２チェーンシステムから前記取引アドレスを含む取引データを検索するように設定される。
第６態様では、本願の実施例は変換装置を提供し、開始モジュール及び署名モジュールを備え、
前記開始モジュールは、管理側装置のイネーブルに基づいて変換取引を開始するように設定され、
前記署名モジュールは、クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第１アンロックスクリプトを生成するように設定され、
前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第１チェーンシステムのブロックデータに書き込まれ、前記第１チェーンシステムのブロックデータが第２チェーンシステムのブロックデータに書き込まれ、前記第２チェーンシステムのブロックデータが前記第１チェーンシステムの１つ又は複数のブロックデータで順次構成され、前記第１チェーンシステムにおけるいずれか１つのアカウントの状態が前記第２チェーンシステムにおける前記アカウントの状態に合致する。
第７態様では、本願の実施例はコンピュータ可読記憶媒体を提供し、コンピュータ命令が記憶され、該命令がプロセッサにより実行されるとき、上記管理側のデータ処理方法、クライアント側のデータ処理方法又は変換装置のデータ処理方法のステップを実現する。
図面及び詳細な説明を読んで理解した後、他の態様を理解することができる。
図１は本願の実施例のデータ処理方法のフローチャートである。 図２は本願の実施例の信頼可能なシステムの模式図である。 図３は本願の実施例に係る信頼可能なシステムにおける第１チェーン及び第２チェーンのチェーン間転送の模式図である。 図４は本願の実施例の管理側のデータ処理方法の実施形態のフローチャートである。 図５は本願の実施例の管理側のデータ処理方法の他の実施形態のフローチャートである。 図６は本願の実施例の管理側装置の構造模式図である。 図７は本願の実施例のクライアント側のデータ処理方法のフローチャートである。 図８は本願の実施例のクライアント側装置の構造模式図である。 図９は本願の実施形態のフローチャートである。
衝突しない限り、本願の実施例及び実施例の特徴は任意に組み合わせられてもよい。
図面のフローチャートに示されるステップは、１組のコンピュータ実行可能な命令のコンピュータシステム等において実行されてもよい。そして、フローチャートに論理順序を示すが、いくつかの場合、ここの順序と異なる順序で図示又は説明されるステップを実行してもよい。
本明細書及び上記図面における用語「第１」「第２」等は類似のオブジェクトを区別するためのものであって、特定の順序又は前後順序を説明するためのものではない。
背景技術における既存の問題を解決するために、本願の実施例は中心化と分散化とを組み合わせた信頼可能なシステムを提供する。
以下、まず本願の実施例に関わる概念を説明する。
ｔｏｋｅｎとはブロックチェーンにおける代用貨幣を指し、トークンとも称される。
パブリックチェーンとは誰でも取引を読み取って送信し、コモンセンスに関与することのできるブロックチェーンを指し、完全な分散化システムに属する。本明細書の実施例に用いるのは誰でも取引を送信することができること以外に、残りがパブリックチェーンシステムと同じである準パブリックチェーンシステムである。本明細書に記載の準パブリックチェーンシステムにおいて、誰でも取引を読み取んで検証し、コモンセンスに関与することができ、追跡可能、改竄不可能を実現することができる。
プライベートチェーンとは書き込み権限が１つの組織にあるデータチェーンを指し、中心化システムに属する。
コンソーシアムチェーンとは書き込み権限が複数の組織にあるデータチェーンを指し、部分的な分散化システムに属する。
ｅＩＤ（ｅｌｅｃｔｒｏｎｉｃ Ｉｄｅｎｔｉｔｙ）とは国民のネットワーク電子アイデンティティ識別子を指し、信頼可能な実名認証方式である。
秘密の共有とは秘密メッセージを適切な方式でＮ部に分割し、Ｍ部又はＭ部以上が協力しなければ秘密メッセージを回復できないことを意味し、（Ｍ，Ｎ）と記され、ＭとＮが１より大きな正の整数である。
本願の実施例は中心化と分散化とを組み合わせた信頼可能なシステムを提供する。本願の実施例では、中心化システム（第１チェーンシステム、第１チェーンとも称される）はプライベートチェーン又はコンソーシアムチェーンであってもよい。分散化システム（第２チェーンシステム、第２チェーンとも称される）はパブリックチェーン又はコンソーシアムチェーンであってもよい。第１チェーンがどのチェーンを用いるかは必ずしも第２チェーンがどのチェーンを用いるかに関連するとは限らない。例えば、第１チェーンがプライベートチェーンである場合、第２チェーンがパブリックチェーンであってもよく、コンソーシアムチェーンであってもよく、同様に、第１チェーンがコンソーシアムチェーンである場合、第２チェーンがパブリックチェーンであってもよく、コンソーシアムチェーンであってもよい。第２チェーンが対外公開する特性を有するため、本実施例において対外システムとも称される。中心化システムが管理者の役割（管理側ノード又は管理側装置であり、以下、管理側と略称される）及びユーザーの役割（クライアント側ノード又はクライアント側装置であり、以下、クライアント側と略称される）を有してもよい。選択肢として、第１チェーンシステムは更に１つ又は複数の特定の機構の役割（例えば、チェーン生成機構、発行機構、変換機構等のうちの１つ又は複数を含むが、それらに限らない）を含んでもよく、第１チェーンシステムは管理側システムであるため、以下では管理側の第１チェーンシステムとも称される。分散化システムがユーザーの役割（第１チェーンシステムにおけるユーザーの役割が第２チェーンシステムにおけるユーザーの役割と同じである）及びチェーン生成ノード（中心化システムのチェーン生成機構と異なり、チェーン生成機構が第１チェーンを生成し、チェーン生成ノードが第２チェーンを生成する）を有してもよい。選択肢として、第２チェーンシステムには更に第三者及び監督管理者が関与してもよく、第三者が他のいかなる者又は機構であってもよく、監督管理者が特定の権限（例えば、検証）を有する機構である。第２チェーンシステムは外部にクエリ、検証及び監督管理を提供するシステムであるため、以下に対外の第２チェーンシステムとも称される。
本願の実施例のデータ処理方法は図１に示されるように、以下のステップを含む。
ステップ１、取引データが検証に成功して裏書署名してから第１チェーンシステムのブロックデータに書き込まれ、
ユーザーの提出した取引データは、管理側が取引データを検証して裏書署名する必要があり、検証に成功して裏書署名した取引データは、チェーン生成機構により第１チェーンのブロックデータに書き込まれる。
ステップ２、前記第１チェーンシステムのブロックデータが第２チェーンシステムのブロックデータに書き込まれ、前記第２チェーンシステムのブロックデータが前記第１チェーンシステムの１つ又は複数のブロックデータで順次構成され、前記第１チェーンシステムにおけるいずれか１つのアカウントの状態が前記第２チェーンシステムにおける前記アカウントの状態に合致する。
第１チェーンが新しいブロックデータを生成した後、第２チェーンのチェーン生成ノードに同期することとなり、ブロックデータの検証に成功した後、チェーン生成ノードにより第２チェーンのコモンセンスアルゴリズムに基づいて新しいブロックデータを生成し、検証がブロックにおけるすべてのデータの検証を含む。そして、第２チェーンに管理側の第１チェーンの提出したブロックデータのみを順次記録し、且つ第２チェーンにおける各ブロックデータに含まれる第１チェーンのブロックデータの数は一定でなくてもよく、即ち第２チェーンにおける各ブロックは１〜ｎ個の第１チェーンのブロックデータを含んでもよく、その数が第２チェーンのコモンセンスアルゴリズムによって決定される。従って、対外の第２チェーンシステムにおける各ブロックデータは、管理側の第１チェーンシステムの１つ又は複数のブロックデータで順次組み合わせられてなり、このため、管理側の第１チェーンシステムと対外の第２チェーンシステムとは論理状態において同じである。本実例に係る信頼可能なシステムは二層システム（管理側の第１チェーンシステムと対外の第２チェーンシステムとを含む）であると見なされてもよい。ところが、本願は制限しない。実際の応用のとき、該システムは更に多層システムに拡張されてもよく、例えば、管理側で拡張すれば、多層に拡張されてもよい。
管理側の第１チェーンシステムと対外の第２チェーンシステムとは、異なるコモンセンスアルゴリズムを用いてもよい。例えば、管理側の第１チェーンシステムはコモンセンス時間のより短いアルゴリズムを用いれば、クイック確認及び高頻度取引のニーズを満足することができるが、対外の第２チェーンシステムはコモンセンス時間のより長いアルゴリズムを用いる。従って、図２に示すように、２つのチェーンがそれぞれブロックデータを生成する時間は同じでなくてもよく、１つの非同期過程であってもよい。従って、対外の第２チェーンの生成は管理側の第１チェーンの生成に影響せず、それにより管理側の高並行性ニーズを満足する。第２チェーンのブロックデータは第１チェーンの１つ又は複数のブロックデータで順次組み合わせられてなり、第２チェーンが使用するデータブロックは、いずれも管理側の第１チェーンがパッケージ化した後のブロックデータであるため、第２チェーンのブロックデータの生成にも役立って、大量データのニーズを満足することができる。以上によれば、本実施例の信頼可能なシステムは第１チェーンと第２チェーンが非同期且つ準同型であり、管理側の第１チェーンシステムは第２チェーンシステムにより自体のデータ状態を検査することができ、且つ第２チェーンシステムにより第２チェーンシステムにタイムリーに同期していないもの以外のすべてのブロックデータを回復することができる。
選択肢として、第２チェーンシステムは更に拡張データを含んでもよく、拡張データは第２チェーンシステムそのもののシステム状態データであってもよく、第１チェーンシステムのシステム状態に関わらないため、第１チェーンシステム及び第２チェーンシステムの論理状態の相違に影響しない。
本実施例では、管理側の第１チェーンシステム及び対外の第２チェーンシステムにおいて異なる方式で取得されたいずれか１つのアカウントの状態は合致する。例示的に、管理側はシステム状態ツリーを生成することにより、いずれか１つのアカウントの状態を取得してもよい。前記アカウントの状態はアカウント残高、初期アドレスパラメータ、凍結又は凍結解除等の状態情報を含んでもよく、第２チェーンにおいて、取引結果を累計することで該アカウントの残高状態を把握し、制御データにおけるユーザーの暗号化情報を検索して残りの状態を取得してもよく、取引結果を累計することで把握したアカウントの状態は管理側において取得された該アカウントの状態に合致する。クライアント側のウォレットは、管理側の第１チェーンにおいて取得されたアカウントの状態が対外の第２チェーンにおいて取得された該アカウントの状態に合致するかどうかを自動的に検証してもよい。
以下、管理側の第１チェーンシステムがプライベートチェーン、対外の第２チェーンシステムがパブリックチェーンである場合を例として説明する。
管理側はシステムの管理者であり、ユーザー及び機構の新規登録、ログオフ、証明書の更新及び暗号化暗号鍵の発行等はいずれも管理側により行われ、管理側は更にアカウントの凍結、凍結解除及び闇取引を阻止する機能を有してもよく、且つシステムｔｏｋｅｎの発行及び回収も管理側の関与を必要とする。チェーン生成機構は管理側のプライベートチェーンの生成者であり、発行機構はｔｏｋｅｎの発行に関与し、変換機構はユーザーがローカルの導出不可能な署名暗号鍵のみを有してそれを紛失した場合に関与し、上記機構の身分はいずれも公開したものであって、秘密にしたものではない。管理側のプライベートチェーンシステムに関連付けられるものは、更に信頼可能な第三者ＣＡ（Ｃｅｒｔｉｆｉｃａｔｅ Ａｕｔｈｏｒｉｔｙ、認証局）機構（又は、ｅＩＤ機構）又は信頼可能な第三者委託管理署名暗号鍵機構等を含んでもよい。
対外のパブリックチェーンシステムにおけるチェーン生成ノードは管理側の許可を必要とせず、対応するルールに従ってパブリックチェーンにおけるデータを検証してパブリックチェーンシステムのコモンセンス及び生成に関与してもよく、チェーンにおけるデータが公開、追跡可能、改竄不可能であるが、完全に透明なものではなく、チェーン生成ノード、第三者及び監督管理者はいずれもチェーンにおけるデータの正当性を検証することができるが、対応するユーザーＩＤ、ユーザーの関連取引及び資産情報を把握することができず、アドレスを利用してユーザーＩＤ及び関連取引をトレースしても把握できないが、第三者及び監督管理者はクライアント側又は管理側の暗号化暗号鍵の承認を取得した後、自主的にパブリックチェーンからユーザーの関連取引及び資産情報を取得することができ、ユーザー自身もパブリックチェーンから暗号化暗号鍵によって自身に関連する取引データ、資産情報及びユーザー情報を取得し、図３に示される。
本実施例に記載の信頼可能なシステムを利用するために、ユーザーはまず実名認証後に管理側のプライベートチェーンに新規登録する必要がある。新規登録後、ユーザーが取引を開始して生成した取引データは、管理側の検証に成功して裏書署名してからチェーン生成機構によりプライベートチェーンに書き込まれ、プライベートチェーンはデータをパブリックチェーンに同期するが、取引の関与者、チェーン生成ノード、第三者及び監督管理者等は、いずれもパブリックチェーンにおいて取引データをクエリ・検証し、即ちシステム全体のユーザー、第三者及び監督管理者に対する読み取り操作がいずれもパブリックチェーンにおいて行われるが、書き込み操作が管理側によりプライベートチェーンにおいて行われ、従って、本実施例のシステムは読み取り及び書き込みが分離したものである。
本明細書の実施例では、管理側のプライベートチェーンにおけるデータは、制御データセット及び取引データセット、並びにチェーン生成機構のコモンセンスアルゴリズムにより生成されたブロックヘッダーデータを含んでもよい。制御データセットは、主に管理側が第１チェーンシステムを管理・制御するために公布した情報データの集合であり、ユーザー及び機構の新規登録情報、ｔｏｋｅｎの発行及び回収、取引ルール、身分証明書及び更新情報（例えば、更新後のユーザー情報及び／又は更新後のシステムアルゴリズム暗号鍵等）等のうちの１つ又は複数を含むが、それらに限らない。効果的な監督管理のために、ユーザーの身分情報が暗号文である以外に、他の多くのデータが平文であり、これによりユーザーの身分プライバシーを保護することもできる。取引データセットは１つの時間セグメントにおけるすべての１回限りの取引の集合である。１回の取引データにはｔｏｋｅｎ額及び出力アドレスに対応するユーザー識別子が暗号文である以外に、残りのデータがいずれも平文であり、出力アドレスに対応するユーザー識別子は取引データにおいて選択可能項目である。取引のｔｏｋｅｎ額が機密取引方式で暗号化され（例えば、加算準同型承諾）、該ｔｏｋｅｎに対応する機密暗号化暗号鍵（取引アドレスに対応するクライアント側及び管理側の有する暗号鍵）が平文を復号化できる以外に、残りがいずれも平文を復号化して確認することができないが、暗号文を利用して機密取引ｔｏｋｅｎ額の有効性を検証することができ、即ち暗号文の場合に取引のすべての入力ｔｏｋｅｎの和からすべての出力ｔｏｋｅｎの和を引いたものがゼロに等しく且つすべての項値が負数ではないかどうかを検証する。ブロックヘッダーデータは制御データセットにより生成されたマークルツリー（Ｍｅｒｋｌｅ Ｔｒｅｅ）ルートハッシュ及び取引データセットにより生成されたＭｅｒｋｌｅ Ｔｒｅｅルートハッシュ、並びに管理側により生成された現在のシステム状態ツリーのマークル−パトリシアツリー（Ｍｅｒｋｌｅ Ｐａｔｒｉｃｉａ Ｔｒｅｅ）ルートハッシュを含み、更に前のブロックヘッダーのハッシュ値、ブロック番号、タイムスタンプ、コモンセンスパラメータ等を含み、ブロックヘッダーデータの偽造防止及び否認防止を確保するよう、更に関連署名を含む必要がある。管理側はシステムのすべての暗号化暗号鍵を有しなければシステム状態ツリーを生成できないため、該状態ツリーは管理側のみで使用され、１つの仮想状態ツリーである。
本実施例では、クライアント側の暗号鍵は署名暗号鍵及び暗号化暗号鍵の２種類に分けられる。このうち、署名暗号鍵はクライアント側によりローカルに生成して管理のために使用されるものであり、暗号鍵の安全使用を確保するよう、導出不可能なハードウェアを媒体として利用する。署名暗号鍵はＣＡ機構によりユーザーの身分認証証明書を公布することによって、又はｅＩＤメカニズムを用いて、ユーザーの実名身分認証を実現する。署名暗号鍵は証明書署名公開鍵及び署名秘密鍵を含む。また、選択可能な実施形態では、該システムは多重署名方式を用いてもよく、クライアント側はローカル署名暗号鍵のほか、更に信頼可能な第三者の委託管理する署名暗号鍵を用いてもよく、該暗号鍵はクライアント側が身分認証証明書又はｅＩＤによって管理側に新規登録した後、管理側により信頼可能な第三者に申請する委託管理署名暗号鍵であり、クライアント側はＦＩＤＯ（オンライン高速身分検証）方式で委託管理署名暗号鍵を用いて、クライアント側のローカル署名暗号鍵とともに多重署名アドレスを構成してもよい。選択肢として、多重署名のタイプを識別してもよく、例えばユーザーが少額で支払うことを容易にするために、ローカルの導出不可能な署名暗号鍵を用いて限度額のより高い費用を支払うが、信頼可能な第三者の委託管理する署名暗号鍵を用いて限度額のより低い費用を支払ってもよく、ユーザーアカウントの安全性を強化するように２種類の署名暗号鍵を組み合わせて用いてもよく、複数のユーザーの署名暗号鍵を用いてジョイントアカウントの多重署名アドレスを構成してもよい。選択可能な実施形態では、更にユーザーがローカルの導出不可能な署名暗号鍵を紛失した場合、委託管理暗号鍵を用いて資産を新しいアカウントに安全に移転してもよい。他の選択可能な実施形態では、クライアント側が委託管理署名暗号鍵を有せず、且つローカルの導出不可能な署名暗号鍵が紛失された場合、ユーザーの資産を損失しないよう、更に変換機構アカウントによって資産を新しいアカウントに移転してもよい。
暗号化暗号鍵はクライアント側が身分認証証明書又はｅＩＤによって管理側に新規登録した後、管理側が各クライアント側に異なる暗号化暗号鍵を公布し、且つクライアント側のローカルウォレットにより記憶・使用される。暗号化暗号鍵は機密取引暗号鍵、秘密共有サブ暗号鍵及び対称暗号化暗号鍵を含んでもよい。機密取引暗号鍵がユーザーの取引データにおけるｔｏｋｅｎ額の関連パラメータ（例えば、盲検化因子）を暗号化／復号化することに用いられてもよく、秘密共有サブ暗号鍵が秘密共有アルゴリズムを用いて取引当事者の身分識別子等のデータを暗号化／復号化することに用いられてもよく、対称暗号化暗号鍵がクライアント側の身分情報等のデータを暗号化して記憶することに用いられてもよい。上記解釈された用途を除き、暗号化暗号鍵のうちの１つ又は複数の暗号鍵は更に取引アドレスを生成することに用いられてもよい。秘密共有アルゴリズムは選択可能なサブ暗号鍵を用いる秘密共有方式であり、且つ暗号化者（管理側）はその中のＮ部の秘密共有サブ暗号鍵を把握することができ、（２，Ｎ＋１）の閾値秘密共有アルゴリズムを用いて生成したばかりの１つのサブ暗号鍵を暗号化結果とともに公布する場合、Ｎ部のうちのいずれか１つの秘密共有サブ暗号鍵に基づいて秘密メッセージを回復することができ、次に、秘密メッセージを暗号鍵として利用して、対称暗号化アルゴリズムを用いて、保護すべき共有データを暗号化してもよい。（２，Ｎ＋１）の閾値秘密共有アルゴリズムは秘密メッセージがＮ＋１個のシェアの共有秘密メッセージに分けられることを示し、その中のいずれか２つ又は２つ以上の共有シェアを利用して秘密メッセージを回復することができる。従って、Ｎ＋１個のサブ暗号鍵は１部の生成したばかりのシャドーサブ暗号鍵を含み、１つの秘密共有サブ暗号鍵を有するクライアント側は、自体の秘密共有サブ暗号鍵及び暗号化結果とともに公布した該シャドーサブ暗号鍵に基づいて、秘密メッセージを回復することができ、更に秘密メッセージを利用して共有データを確認する。本実施例では、暗号化暗号鍵が上記３種類の暗号鍵を含むことは一実施形態に過ぎず、他の実施形態では、暗号化暗号鍵は１種類又は２種類の暗号鍵のみを含んでもよく、又は、更に４種類の暗号鍵を含んでもよく、上記機能を実現できればよい。暗号鍵の名称は上記実施例における名称を用いるものに限らず、区別できればよい。
本実施例のシステムにおいてＵＴＸＯ（Ｕｎｓｐｅｎｔ Ｔｒａｎｓａｃｔｉｏｎ Ｏｕｔｐｕｔｓ、未使用の取引出力）モデルを用いる。ＵＴＸＯモデルにおいて、１回の取引は１つ又は複数の入力と１つ又は複数の出力とを含む。各入力は、順方向の未使用の取引出力に対する参照、及び対応するアンロックスクリプトである。順方向の未使用の取引出力に対する参照をアンロックした後、再び参照をアンロックできず、即ち二重支払いが不可能になる。そして、各出力はｔｏｋｅｎ額及びロックスクリプトを含み、ロックスクリプトを対応するアンロックスクリプトでなければアンロックできず、即ち１つの新しい未使用の取引出力を作成する。ロックスクリプトは１つの取引アドレス及びアンロック方式を含み、取引アドレスは非対称暗号鍵の公開鍵を用いて一方向の不可逆関数によって取得されたものであるが、アンロックスクリプトは取引アドレスに対応する公開鍵データ及び秘密鍵の取引データに対する署名であり、該公開鍵を用いて署名を検証してもよい。ロックスクリプトとアンロックスクリプトとは更に多重署名方式を用いてもよい。
本実施例では、管理側のプライベートチェーンシステムはシステムの状態ツリーを生成してもよく、それにより各ユーザーの現在の状態を容易に取得することができる。状態ツリーは現在のすべての制御データ及び取引データにより生成されたものであり、システムの現在の状態及び各ユーザーの現在の状態が記録される。状態ツリーにおけるユーザーの資産状態は、ユーザーのＵＴＸＯ取引記録に基づいて維持するアカウント残高を含むが、対外のパブリックチェーンシステムにおけるクライアント側、第三者及び監督管理者は、ユーザーのＵＴＸＯ取引記録に基づいて取引結果を累計することにより、ユーザー残高を取得してもよい。即ち、管理側はシステム状態ツリーに基づいてユーザーの現在の状態及びアカウント残高をクエリすることができるが、対外のパブリックチェーンシステムにおけるユーザーは、該ユーザーのすべての取引記録を用いなければ該ユーザーのアカウント残高を取得できない。以上によれば、クライアント側の資産状態が管理側のプライベートチェーンシステム及び対外のパブリックチェーンシステムでの使用方式は同じではないが、この２つの方式で取得されたアカウント残高は合致する。状態ツリーが管理側のプライベートチェーンのみにおいて使用されるため、管理側は状態ツリーの方式で各クライアント側の現在の状態を容易に取得することができるが、クライアント側、第三者及び監督管理者に対外パブリックチェーンからクライアント側のすべての取引記録を取得する方式を提供するために、アカウント取引チェーンを導入し、該アカウント取引チェーンの検索は容易で迅速であるだけでなく、ユーザープライバシーを保護することもできる。
以下、アカウント取引チェーンを説明する。
選択可能な実施例では、アカウント取引チェーンのデータ処理方法は図４に示されるように、以下のステップステップＳ１とステップＳ２を含む。
ステップＳ１、取引データを検証し、
前記取引データは取引受信側の取引アドレスと今回取引時に生成したアドレスパラメータとを含み、前記取引アドレスは前記取引受信側が前回取引を受信する際に生成したアドレスパラメータを利用して生成したものであり、前記今回取引時に生成したアドレスパラメータは前記取引受信側が次回取引を受信する取引アドレスを生成することに用いられる。
取引データがクライアント側により管理側に送信され、管理側の取引データに対する検証は主に有効性を検証し、例えばユーザー状態の有効性、アンロックスクリプトの有効性、ｔｏｋｅｎ額の有効性及び取引アドレスが有効なアドレスであるかどうか等を検証することを含む。
ステップＳ２、取引データの検証に成功した後、前記取引データを裏書署名し、裏書署名後の取引データが第１チェーンのブロックデータに書き込まれる。
管理側の裏書署名はクライアント側の提出した取引データ全体に対する署名である。
前記取引データがチェーンアップされた後、同じ取引受信側のすべての受信取引データが論理チェーン構造を形成することとなる。該論理チェーンは生成された帳簿データに暗黙的に含まれる。
選択肢として、ユーザーが新規登録するとき、管理側はユーザーのために初期アドレスパラメータ（ｎｏｎｃｅ値とも称される）を生成して、受信取引アドレスを生成し、該ユーザーが取引受信側として取引するとき、該ユーザーのすべての受信取引データが１つの論理チェーンを形成することとなる。同じユーザーが管理側により取引アドレスの生成のための新しい暗号鍵を公布された後、管理側は改めて該ユーザーに１つの初期アドレスパラメータを生成して、状態ツリーに改めて生成された初期アドレスパラメータにより生成された取引アドレスを記録し、前記改めて生成された初期アドレスパラメータは公布された新しい暗号鍵に対応し又は関連する。その後、該ユーザーが取引受信側として取引するとき、該ユーザーのすべての受信取引データが１つの新しい論理チェーンを形成することとなる。以上によれば、同じ取引受信側の受信取引データが１つ又は複数の論理チェーン構造を有してもよい。各回生成したばかりの初期アドレスパラメータが暗号化して制御データに記憶されることとなり、ユーザーは、制御データにおける初期アドレスパラメータに基づいて、自主的に論理チェーンを検索してもよい。
管理側が取引データを裏書署名した後、チェーンアップすることを管理側のプライベートチェーンシステムに通知する。管理側のチェーン生成機構により前記取引データをプライベートチェーンの帳簿データに書き込み、次に生成されたブロックデータを対外パブリックチェーンのチェーン生成ノードに同期する。ブロックデータの検証に成功した後、チェーン生成ノードにより第２チェーンのコモンセンスアルゴリズムを用いて第２チェーンのブロックデータに書き込む。
選択肢として、同じ取引受信側に対する並行取引が複数あり、即ち同じ取引アドレスを含む取引データが複数ある場合、同じ取引アドレスを含む取引データは、前記チェーン構造において互いに兄弟ノードである。
取引データに含まれる前回の受信取引におけるアドレスパラメータにより生成された取引アドレス及び次回の取引アドレスを生成するためのアドレスパラメータによって、同じクライアント側の受信取引データに論理チェーン又は兄弟ノードのある論理チェーンを形成させ、これにより、クライアント側のすべての受信取引データを迅速に検索することができ、且つ送信取引データが受信取引データを参照するため、更にすべての取引データを迅速に取得することができる。同時に、該取引アドレスが一回限りのものであり、異なるユーザーにとって唯一なものであり、それによりユーザーＩＤのプライバシーを保護するという目的を実現することができる。
選択可能な実施例では、図５に示すように、取引データを検証する（ステップＳ１）前に、前記方法は更に、
アドレスパラメータを生成し、状態ツリーから前記取引受信側の取引アドレスを検索し、生成されたアドレスパラメータ及び検索された前記取引アドレスを取引送信側に送信し、前記取引送信側により前記取引アドレス及びアドレスパラメータを取引データに追加するステップＳ０を含み、
前記取引データを裏書署名した（ステップＳ２）後、前記方法は更に、
前記取引データにおける取引アドレスが前記状態ツリーにおける前記取引受信側の取引アドレスと同じであると判断した場合、前記生成されたアドレスパラメータを利用して１つの新しい取引アドレスを生成して、前記状態ツリーにおける前記取引受信側の取引アドレスを更新するステップＳ３を含む。
前記取引データにおける取引アドレスが前記状態ツリーにおける前記取引受信側の取引アドレスと異なると判断した場合、該取引受信側の取引アドレスが既に更新されたことを示すため、前記状態ツリーにおける前記取引受信側の取引アドレスを更新する必要がない。
該選択可能な実施例では、状態ツリーで受信取引アドレスを記憶することにより、各回取引を受信する際の取引アドレスが新しいものであるように確保する。
選択可能な実施例では、前記アドレスパラメータは乱数であってもよく、前記生成されたアドレスパラメータを利用して１つの新しい取引アドレスを生成することは、関数を利用して前記生成されたアドレスパラメータ及び前記取引受信側の暗号鍵を１回又は複数回演算して、取引アドレスを生成することを含む。複数回演算する際に同じ又は異なる関数を用いてもよい。
上記言及した暗号化暗号鍵のうちの１つ又は複数を利用して取引アドレスを生成する以外に、管理側によりユーザーのために取引アドレスの生成のための新しい暗号鍵を発行してもよい。
選択肢として、前記取引受信側の取引アドレスは、第１関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して第１中央値を取得し、第２関数を利用して前記第１中央値及び前記取引受信側のユーザー公開鍵を演算して第１公開鍵を取得し、第３関数を利用して前記第１公開鍵を演算して取引アドレスを取得するという第１方式で生成されてもよい。
例えば、第１中央値（Ｋ）が一方向の不可逆関数（即ち、第１関数）によって前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算することで生成され、第１公開鍵は第１中央値（Ｋ）及びユーザー公開鍵を利用して楕円曲線におけるスカラー乗算（即ち、第２関数）によって取得され、更に第１公開鍵によって他の一方向の不可逆関数（即ち、第３関数）によって取引アドレスを生成する。
選択肢として、前記取引受信側の取引アドレスは更に多重署名アドレスであってもよく、該多重署名アドレスは、異なる関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して複数の中央値を取得し、第４関数を利用してそれぞれ各中央値及び前記取引受信側の複数のユーザー公開鍵を演算して複数の新しい公開鍵を取得し、第５関数を利用して前記複数の新しい公開鍵を演算して多重署名アドレスを取得するという第２方式で生成されてもよい。
例えば、複数の異なる一方向の不可逆関数により前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して複数の中央値（Ｋ′）を生成し、各中央値及び受信取引側の複数のユーザー公開鍵に対して楕円曲線におけるスカラー乗算（即ち、第４関数）によって複数の新しい公開鍵を取得し、更に複数の新しい公開鍵を利用して他の一方向の不可逆関数（即ち、第５関数）によって多重署名アドレスを生成する。各中央値と複数のユーザー公開鍵は１対１に対応する関係を有するため、複数の異なる一方向の不可逆関数と複数のユーザー公開鍵も１対１に対応する関係を有する。
上記一方向の不可逆関数は、例えばハッシュ関数又はハッシュ関数の組み合わせであってもよい。
上記第１方式及び第２方式における演算関数は同じであってもよい。
選択可能な実施例では、クライアント側の開始した暗号鍵更新要求を受信し、管理側が前記クライアント側に対して身分認証を行った後、新しい暗号化暗号鍵を公布し、変換取引プロセスを開始し、変換機構アカウントをイネーブルして取引を開始し、前記変換機構アカウントの署名暗号鍵により前記取引データを署名して、第１アンロックスクリプトを生成し、それにより前記クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換する。前記第１アンロックスクリプトは特別（又は特定）のアンロックスクリプトであり、変換機構により生成されたものであり、クライアント側により生成されたアンロックスクリプトと異なる。該選択可能な実施例を用いれば、ユーザーがローカル署名暗号鍵を紛失したことにより資産を損失させるという問題を解決することができる。
選択可能な実施例では、前記方法は更に、
ｔｏｋｅｎを発行するための指定された発行取引を生成し、前記指定された発行取引における入力アドレスが第１フォーマットを用いるアドレスであるステップ、
ｔｏｋｅｎを回収するための指定された回収取引を生成し、前記指定された回収取引における出力アドレスが第２フォーマットを用いるアドレスであるステップ、
ｔｏｋｅｎを報奨するための指定された報奨取引を生成し、前記指定された報奨取引における入力アドレスが第３フォーマットを用いるアドレスであるステップ、のうちの１つ又は複数を含んでもよい。
上記第１フォーマットとは特別なアドレスフォーマットを指し、ＵＴＸＯアドレスのコンテクスト関係を有せず、即ち入力には未使用の取引出力を参照する必要がなく、出力も入力とされることが不可能であり、予め決められたものであってもよい。同様に、第２フォーマット及び第３フォーマットも類似である。
本実施例の方法によれば、同じ取引受信側のすべての受信取引データが論理チェーン構造を形成し、且つ前記受信側のすべての送信取引がいずれも受信取引データを参照する必要があるため、関連暗号鍵を取得した後に前記受信側のすべての取引データを検索することができる。
本実施例の方法を実現する管理側装置は検証モジュール１０１及び署名裏書モジュール１０２を備えてもよく、図６に示すように、
前記検証モジュール１０１は、取引データを検証するように設定され、
前記裏書署名モジュール１０２は、前記検証モジュールが検証に成功した後、前記取引データを裏書署名し、裏書署名後の取引データが第１チェーンシステムのブロックデータに書き込まれるように設定され、
前記取引データは取引受信側の取引アドレスと今回取引時に生成したアドレスパラメータとを含み、前記取引アドレスは前記取引受信側が前回取引を受信する際に生成したアドレスパラメータを利用して生成したものであり、前記今回取引時に生成したアドレスパラメータは前記取引受信側が次回取引を受信する取引アドレスを生成することに用いられ、同じ取引受信側のすべての受信取引データに論理チェーン構造を形成させる。
前記チェーン構造に含まれる同じ取引アドレスの取引データは互いに兄弟ノードである。
選択可能な実施例では、該装置は更に第１アドレス生成モジュールを備えてもよく、該第１アドレス生成モジュールは、アドレスパラメータを生成し、状態ツリーから前記取引受信側の取引アドレスを検索し、生成されたアドレスパラメータ及び検索された前記取引アドレスを取引送信側に送信するように設定され、及び、前記取引データにおける取引アドレスが前記状態ツリーにおける前記取引受信側の取引アドレスと同じであると判断した場合、前記生成されたアドレスパラメータを利用して１つの新しい取引アドレスを生成して、前記状態ツリーにおける前記取引受信側の取引アドレスを更新するように設定される。
選択可能な実施例では、前記第１アドレス生成モジュールが前記生成されたアドレスパラメータを利用して１つの新しい取引アドレスを生成することは、前記第１アドレス生成モジュールが関数を利用して前記生成されたアドレスパラメータ及び前記取引受信側の暗号鍵を１回又は複数回演算して、取引アドレスを生成することを含む。
選択肢として、前記第１アドレス生成モジュールは、前記第１アドレス生成モジュールが第１関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して第１中央値を取得し、第２関数を利用して前記第１中央値及び前記取引受信側のユーザー公開鍵を演算して第１公開鍵を取得し、第３関数を利用して前記第１公開鍵を演算して取引アドレスを取得するという第１方式で、前記取引受信側の取引アドレスを生成し、又は、
前記第１アドレス生成モジュールは、前記取引受信側の取引アドレスが多重署名アドレスであり、前記第１アドレス生成モジュールが異なる関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して複数の中央値を取得し、第４関数を利用してそれぞれ各中央値及び前記取引受信側の複数のユーザー公開鍵を演算して複数の新しい公開鍵を取得し、第５関数を利用して前記複数の新しい公開鍵を演算して多重署名アドレスを取得するという第２方式で、前記取引受信側の取引アドレスを生成する。
選択可能な実施例では、前記第１アドレス生成モジュールは更に、ユーザーが新規登録するとき、前記ユーザーの初期アドレスパラメータを生成して、状態ツリーに前記初期アドレスパラメータにより生成された取引アドレスを記録するように設定され、及び、
前記第１アドレス生成モジュールは更に、新しい暗号鍵を公布されたユーザーのために初期アドレスパラメータを改めて生成して、状態ツリーに前記改めて生成された初期アドレスパラメータにより生成された取引アドレスを記録するように設定され、前記新しい暗号鍵は取引アドレスを生成するための暗号鍵である。
選択可能な実施例では、前記装置は更に暗号鍵公布モジュール及び変換取引モジュールを備え、
前記暗号鍵公布モジュールは、クライアント側の開始した暗号鍵更新要求を受信し、前記クライアント側に対して身分認証を行った後、新しい暗号化暗号鍵を公布するように設定され、
前記変換取引モジュールは、変換取引プロセスを開始し、変換機構アカウントをイネーブルして取引を開始し、前記クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、前記変換機構アカウントの署名暗号鍵により前記取引データを署名して、第１アンロックスクリプトを生成するように設定される。
選択肢として、ユーザーが新規登録を開始するとき、暗号鍵公布モジュールはクライアント側に対して身分認証を行った後、新しい暗号化暗号鍵も公布することとなる。
前記装置は更に発行取引モジュール、回収取引モジュール及び報奨取引モジュールのうちの１つ又は複数を備え、
前記発行取引モジュールは、ｔｏｋｅｎを発行するための指定された発行取引を生成するように設定され、前記指定された発行取引における入力アドレスは第１フォーマットを用いるアドレスであり、
前記回収取引モジュールは、ｔｏｋｅｎを回収するための指定された回収取引を生成するように設定され、前記指定された回収取引における出力アドレスは第２フォーマットを用いるアドレスであり、
前記報奨取引モジュールは、ｔｏｋｅｎを報奨するための指定された報奨取引を生成するように設定され、前記指定された報奨取引における入力アドレスは第３フォーマットを用いるアドレスである。
上記管理側装置は更にコンピュータ装置であってもよく、プロセッサと、メモリと、メモリに記憶されてプロセッサにおいて実行されるコンピュータプログラムと、を備え、前記プロセッサは前記プログラムを実行するとき、上記実施例の一部又は全部のステップを実現することができる。
本実施例は管理側を有するブロックチェーンシステムにおいて、クライアント側の受信取引データに論理チェーン又は兄弟ノードのある論理チェーンを形成させ、それにより同じクライアント側のすべての受信取引データを迅速に検索することができ、更に該クライアント側のすべての取引データを検索すると同時に、クライアント側に一回限りの取引アドレスの特徴を有させ、ユーザーＩＤのプライバシーを保護するという目的を実現する。
以下の実施例はクライアント側のデータ処理方法を説明し、図７に示すように、
取引受信側が前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成するステップＳ１１と、
対外の第２チェーンシステムから前記取引アドレスを含む取引データを検索し、前記対外の第２チェーンシステムにおけるブロックデータが第１チェーンシステムの１つ又は複数のブロックデータで順次構成され、前記第１チェーンシステムにおけるいずれか１つのアカウントの状態が前記第２チェーンシステムにおける前記アカウントの状態に合致するステップＳ１２と、を含む。
同じ取引受信側のすべての受信取引データが論理的なチェーン構造を形成するため、取引受信側は前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成することができ、今回の受信取引の取引アドレスに基づいて今回の取引データを迅速に検索することができる。同時に、取引アドレスが一回限りのものであるため、該取引受信側のユーザープライバシーを保護する。
選択可能な実施例では、前記方法は更に、クライアント側が前記管理側によって状態ツリーから取得されたアカウント状態と自主的に第２チェーンシステムから取得されたアカウント状態とを比較することを含む。
選択可能な実施例では、前記取引受信側が取引送信側とされる場合、前記方法は更に、前記取引送信側が取引を提出するとき、受信取引データを参照した前回の受信取引データにおけるアドレスパラメータを利用して公開鍵／秘密鍵対を生成し（該公開鍵が以上の説明における第１方式又は第２方式で生成された公開鍵であり、公開鍵が合致しなければアドレスが同じであるように確保することができない）、前記公開鍵／秘密鍵対を利用して現在の取引におけるアンロックスクリプトを生成することを含む。
本実施例の方法を実現するクライアント側装置は第２アドレス生成モジュール２０１、検索モジュール２０２及び検証モジュール２０３を備えてもよく、図８に示すように、
前記第２アドレス生成モジュール２０１は、前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成するように設定され、
前記検索モジュール２０２は、第２チェーンシステムから前記取引アドレスを含む取引データを検索するように設定される。
選択可能な実施形態では、上記クライアント側装置は更に、前記管理側によって状態ツリーから取得されたアカウント状態と自主的に第２チェーンシステムから取得されたアカウント状態とを比較するように設定される検証モジュールを備えてもよい。
選択可能な実施例では、前記クライアント側装置は更に署名モジュールを備えてもよく、前記署名モジュールは、前記クライアント側が取引送信側とされる場合、取引を提出するとき、受信取引データを参照した前回の受信取引データにおけるアドレスパラメータを利用して公開鍵／秘密鍵対を生成し（公開鍵が以上の説明における第１方式又は第２方式で生成された公開鍵である）、前記公開鍵／秘密鍵対を利用して現在の取引におけるアンロックスクリプトを生成するように設定される。
上記クライアント側装置は更にコンピュータ装置であってもよく、プロセッサと、メモリと、メモリに記憶されてプロセッサにおいて実行されるコンピュータプログラムと、を備え、前記プロセッサは前記プログラムを実行するとき、上記実施例の一部又は全部のステップを実現することができる。
本実施例は同じクライアント側の受信取引データチェーンに基づいて、同じクライアント側のすべての受信取引データを迅速に検索し、更に該クライアント側のすべての取引データを検索することができる。
以下の実施例は変換装置のデータ処理方法を説明し、該方法は、
変換取引を開始し、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第１アンロックスクリプトを生成し、それによりクライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換し、前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第１チェーンシステムのブロックデータに書き込まれ、前記第１チェーンのブロックデータが対外の第２チェーンシステムのブロックデータに書き込まれ、前記第２チェーンシステムのブロックデータが前記第１チェーンシステムの１つ又は複数のブロックデータで順次構成され、前記第１チェーンシステムにおけるいずれか１つのアカウントの状態が前記第２チェーンシステムにおける前記アカウントの状態に合致することを含む。
上記変換装置の開始した変換取引は、前記変換装置をイネーブルするように管理側装置により取引プロセスを開始する必要があり、次に変換装置が開始可能になる。
上記方法を実現する変換装置は、開始モジュール及び署名モジュールを備え、
前記開始モジュールは、管理側装置のイネーブルに基づいて変換取引を開始するように設定され、
前記署名モジュールは、クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第１アンロックスクリプトを生成するように設定され、
前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第１チェーンシステムのブロックデータに書き込まれ、前記第１チェーンシステムのブロックデータが対外の第２チェーンシステムのブロックデータに書き込まれ、前記第２チェーンシステムのブロックデータが前記第１チェーンシステムの１つ又は複数のブロックデータで順次構成され、前記第１チェーンシステムにおけるいずれか１つのアカウントの状態が前記第２チェーンシステムにおける前記アカウントの状態に合致する。
以下の実施例では、管理側及びクライアント側のデータ処理方法を組み合わせて説明する。
該例のシステムにおける取引アドレスは、一方向の不可逆関数によってアドレスパラメータ及びユーザー暗号鍵により計算されたＫ値（即ち、中央値）とクライアント側の署名公開鍵とを演算し、例えば楕円曲線におけるスカラー乗算によって１つの新しい公開鍵を取得し、該新しい公開鍵に対して他の一方向の不可逆関数によって取引アドレスを取得してもよく、該新しい公開鍵は取引アドレスに対応する公開鍵とも称される。該新しい公開鍵に対応する秘密鍵はＫ値とクライアント側の署名秘密鍵とを演算し、例えばガロア域の乗算によって取得されてもよい。そして、同じクライアント側の受信取引データにおける取引アドレスは、いずれも計算によって取得された異なるＫ値が演算に関与して取得されたものであり、一回限りのアドレスの特徴を有するため、外部は取引アドレスの関連情報によってユーザーの関連身分を追跡することができないが、ユーザーのアンロック署名を検証することができる。同様に、本実施例における取引アドレスを生成する方式は、更に多重署名のアドレス（即ち、複数の異なる公開鍵で生成されたアドレス）に適用されてもよく、上記第２方式で関連演算を行えばよい。
以下、該例におけるブロックチェーンシステムのデータ処理方法を説明し、図９に示すように、以下のステップを含む。
ステップ１０、クライアント側Ａは管理側にクライアント側Ｂとの取引要求を提出する。
本実施例は取引受信側がクライアント側Ｂである場合を例として説明し、取引受信側が複数あってもよい。
ステップ２０、管理側はシステム状態ツリーからクライアント側Ｂの取引アドレスを取得してｎｏｎｃｅ値をランダムに生成して、該取引アドレス及びｎｏｎｃｅ値を今回の取引の出力アドレス及びｎｏｎｃｅ値としてクライアント側Ａに送信し、
同様に、クライアント側Ａが複数の受信側と取引をしようとし、即ちステップ１０において複数の受信側との取引要求を提出した場合、管理側は複数の受信側に対応する取引アドレスをクライアント側Ａに伝送すればよい。
選択肢として、管理側は更に取引アドレスに対応するユーザー識別子（本実施例では、該取引アドレスに対応するユーザー識別子はクライアント側Ｂのユーザー識別子であり、他の実施例では、出力が複数ある場合、各取引アドレスは１つのユーザー識別子に対応する）を秘密共有アルゴリズムでクライアント側Ａに暗号化して送信し、該秘密共有者はクライアント側Ａ、取引アドレスに対応するクライアント側及び管理側であり、この３つの秘密共有サブ暗号鍵のみがデータを復号化でき、クライアント側Ａはユーザー識別子の平文を復号化して正しいかどうかを検証して、対応する取引データに該暗号文のユーザー識別子を含ませ、これにより、暗号鍵を有する場合に出力アドレスのユーザー識別子をトレースすることができるようになる。
選択肢として、管理側は更にクライアント側Ａのユーザー識別子を秘密共有アルゴリズムでクライアント側Ａに暗号化して送信してもよく、該秘密共有者がクライアント側Ａ及び管理側であり、これらの秘密共有サブ暗号鍵のみがデータを復号化でき、
ｎｏｎｃｅ値及びクライアント側の暗号鍵（例えば、対称暗号化暗号鍵）が一方向の不可逆関数によって前記Ｋ値を取得し、更に前記方法に基づいてクライアント側の１つの新しい取引アドレスを取得し、該Ｋ値は取引アドレスに対応するＫ値と称されてもよく、該ｎｏｎｃｅ値は取引アドレスに対応するｎｏｎｃｅ値と称されてもよく、管理側は、ｎｏｎｃｅ値により計算された今回の取引のユーザーの新しい取引アドレスがシステムにおいて唯一であるように確保する必要があり、
ユーザーが新規登録する際に管理側は該ユーザーの初期ｎｏｎｃｅ値を生成して、該ユーザーの暗号鍵（例えば、対称暗号化暗号鍵）を利用して制御データセットに暗号化して記憶して、システム状態ツリーに該ｎｏｎｃｅ値により生成されたユーザー取引アドレス、即ちユーザーの１番目の受信取引アドレスを記録する。
ステップ３０、クライアント側Ａは、ローカルウォレットにおける最後の受信取引データにおけるｎｏｎｃｅ値を利用して自体のお釣り用アドレスを計算してもよく、お釣り用アドレスはクライアント側Ａの受信取引アドレスであり、生成方式はステップ２０における取引アドレスと同様であり、自体にお釣りを返す必要がある場合、今回の取引の出力アドレス（１つの取引の複数の出力のうちの１つ）とし、
該ステップは選択可能なステップであり、クライアント側Ａはお釣りを返す必要がある場合、該ステップを実行し、お釣りを返す必要がない場合、ステップ２０の後で直接ステップ４０を実行する。
ステップ２０では、管理側がクライアント側Ａのユーザー識別子を秘密共有アルゴリズムでクライアント側Ａに暗号化して送信し、該秘密共有者がクライアント側Ａ及び管理側であり、このように、取引データに更にお釣り用アドレスに対応する該暗号文のユーザー識別子が含まれる。
ＵＴＸＯモデルの入力は未使用の取引出力を参照したものであるため、出力アドレスに対応する暗号文ユーザー識別子を含めば、取引入力の暗号文ユーザー識別子をトレースすることができる。
ステップ４０、クライアント側Ａは今回の取引の入力の参照した未使用の取引出力の取引アドレスに対応するＫ値を取得し、前記方法に基づいて取引アドレスに対応する公開鍵／秘密鍵対を取得し、該秘密鍵を利用してアンロックスクリプトを含まない取引データを署名し、該公開鍵データとともに未使用の取引出力に対応するアンロックスクリプトを生成し、取引データにステップ２０における取引出力アドレス及びｎｏｎｃｅ値が含まれており、お釣り用アドレスがある場合、更にステップ３０におけるお釣り用アドレスが含まれており、ｔｏｋｅｎ額は機密取引の暗号文であって出力アドレスに対応するユーザー識別子（選択可能）は暗号文である以外に、残りのデータはいずれも平文であり、クライアント側Ａは管理側にアンロックスクリプトを含む取引データを提出し、クライアント側Ａが管理側に提出した、アンロックスクリプトを含む取引データは、バージョン情報、参照とする未使用の取引出力及び対応するアンロックスクリプト、暗号文のユーザー識別子（選択可能）、暗号文のｔｏｋｅｎデータ、ロックスクリプト、ｎｏｎｃｅ値（ステップ２０で取得される）、タイムスタンプを含み、ロックスクリプトは取引出力アドレス及びアンロック方式を含む。
本実施例の方法において、取引データに一回限りの取引アドレス（前回の受信取引のｎｏｎｃｅ値に基づいて計算された）及びｎｏｎｃｅ値（次回の受信取引の取引アドレスを生成することに用いられる）が含まれるため、同じユーザーにとって、該ユーザーのすべての受信取引データである未使用の取引出力は、論理チェーンを形成し又は兄弟ノードのある論理チェーンを形成したが、未使用の取引出力の取引アドレスに対応するＫ値は、受信取引データの前の受信取引データにおけるｎｏｎｃｅ値を参照して計算されてもよく、計算方式はステップ２０におけるＫ値を計算する場合と同様である。
ステップ５０、管理側はクライアント側Ａの提出した取引データの有効性を検証し、ユーザー状態の有効性、アンロックスクリプトの有効性、ｔｏｋｅｎ額の有効性、及び取引アドレスが有効アドレスであるかどうかの検証を含み、
管理側は取引アドレスが有効アドレスであるかどうかを検証するとき、システム状態ツリーにおけるユーザー取引アドレス及び管理側のキャッシュ期限が過ぎる時間内に生成したばかりの取引アドレスキャッシュからクエリし、取引アドレスがユーザーに対応するアドレスであって期限が過ぎないかどうかを検証する。
ステップ６０、管理側は取引データが検証に成功した後、取引データを裏書署名して、チェーンアップすることを管理側のプライベートチェーンシステムに通知し、管理側のチェーン生成機構により裏書後の取引データをプライベートチェーンの帳簿データに書き込み、次に生成されたブロックデータを対外パブリックチェーンのチェーン生成ノードに同期し、
管理側はチェーンアップすることを通知するとき、取引データにおけるユーザー取引アドレスがシステム状態ツリーにおけるユーザー取引アドレスと同じであるかどうかを検証し、同じである場合、該取引のｎｏｎｃｅ値及びクライアント側の暗号鍵（例えば、対称暗号化暗号鍵）を利用して一方向の不可逆関数によって１つのＫ値を取得し、更に１つの対応する取引アドレスを取得し、生成方式はステップ２０における取引アドレスと同様であり、該取引アドレスを利用してシステム状態ツリーにおける対応するユーザー取引アドレスを更新する。
以上によれば、同じ受信クライアント側にとって、次の受信取引のアドレスは、該ユーザーの今回の受信取引データにおけるｎｏｎｃｅ値及び該ユーザー暗号鍵により計算されたものであるが、ユーザーの初期ｎｏｎｃｅ値は新規登録時にチェーンに暗号化して記憶されるものであり、従って、ユーザーは初期ｎｏｎｃｅ値を取得することにより、１番目の受信取引アドレスを計算することができ、アドレスによって受信取引データを取得して、取引データにおけるｎｏｎｃｅ値によって次の受信取引アドレスを計算することができ、更にｎｏｎｃｅ値及び取引アドレスによってユーザーの受信取引データに論理チェーンを形成させる。
そして、複数のクライアント側が該ユーザーに対して並行取引を開始するとき、管理側がシステム状態ツリーから取得した取引アドレスは同じアドレスであり、取引データを１番目に提出して成功した場合のみ、システム状態ツリーにおける取引アドレスを次のアドレスに修正し、従って、取引が同時発生した場合に同じアドレスを用いる場合があり、これらの同じアドレスの受信取引データは論理チェーンにおける兄弟ノードを形成する。
クライアント側のローカルウォレットは、該ユーザーの初期ｎｏｎｃｅ値に基づいて該ユーザーのすべての受信取引データを取得することができ、且つ、ＵＴＸＯモデルにおけるユーザーのすべての送信取引はいずれも対応する未使用の取引出力を入力として参照し、即ち受信取引データを参照する必要があるため、ユーザーはすべての受信取引データを検索できれば、関連取引の参照によりすべての送信取引データを検索することができ、クライアント側のローカルウォレットに該論理チェーンの関係が保存されるが、クライアント側の１つの受信取引における取引アドレスは対応する前の受信取引データにおけるｎｏｎｃｅ値により計算されたものであり、これはステップ４０におけるユーザーが直接に未使用の取引出力における前の受信取引データのｎｏｎｃｅ値を検索することができることを解釈し、更に該未使用の取引をアンロックすることができる。
ステップ７０、クライアント側Ｂがローカルウォレットの最後の受信取引データのｎｏｎｃｅ値によって取引アドレスを計算し、該取引アドレスを利用して帳簿データをクエリすれば、今回の取引データを検索することができ、該取引出力アドレスがロックスクリプトとともに１つの新しい未使用の取引出力を生成し、且つクライアント側Ｂのみは対応するアンロックスクリプトを生成できるが、外部は該取引アドレスとクライアント側Ｂとの関連を把握しない。
以上によれば、今回の取引の出力アドレスはクライアント側の前の受信取引のｎｏｎｃｅ値により計算されたものであり、従って、クライアント側のローカルウォレットが最後の受信取引データのｎｏｎｃｅ値に基づいて計算した取引アドレスを出力して、対外パブリックチェーンから該アドレスの取引データを検索し、今回の取引データがチェーンアップされ帳簿データに書き込まれた後、該アドレスによって今回の取引データを検索することができる。そして、この検索過程はいかなるメッセージ通知メカニズムに依存せず、管理側にも依存せず、クライアント側は自主的に対外パブリックチェーンから取引アドレスに基づいて検索してもよい。
クライアント側の各送信取引の入力はいずれも対応する未使用の取引出力を参照する必要があり、且つ順位関連がなく、従って、クライアント側の送信取引も並行操作を行ってもよく、リプレイアタックを防止する機能を有する。
本実施例の方法を用いれば、クライアント側、チェーン生成ノード、並びに第三者及び監督管理者等は、いずれも対外パブリックチェーン取引データにおける各回の取引の管理側の裏書署名、クライアント側のアンロック署名を検証し、暗号文で機密取引額の有効性を検証することができるが、対応するユーザー情報及び取引額を把握せず、ユーザーのアカウント取引チェーンも把握せず、これによりユーザーデータプライバシーの目的を実現する。
クライアント側のローカルウォレットは１つの軽量級のウォレットであり、対外パブリックチェーンのブロックヘッダーデータを同期すればよく、更に制御データにおける暗号化されたユーザーＩＤ情報及び暗号化された初期ｎｏｎｃｅ値を取得すれば、他のユーザーに関連しないデータを同期する必要とせずに、ユーザーの関連情報及びアカウント取引チェーンを取得できる。そして、パブリックチェーンブロックヘッダーのデータ量が少なく、ユーザーは少量のデータを同期すればよく、携帯機器の記憶ニーズを完全に満足することができる。クライアント側はブロックヘッダーデータに基づいて、ＳＰＶ（Ｓｉｍｐｌｉｆｉｅｄ Ｐａｙｍｅｎｔ Ｖｅｒｉｆｉｃａｔｉｏｎ）を利用して該取引があるかどうかを検証してもよく、少量の他の取引データのハッシュ演算結果があればよい。且つ、クライアント側又は管理側は対応する暗号化暗号鍵を承認すれば、監督管理者及び第三者は対外パブリックチェーンから該ユーザーのアカウント取引チェーンを取得して、ユーザーに関連するすべての取引データを迅速に検索することができる。システムでは管理側のプライベートチェーン及び対外パブリックチェーンのチェーン生成ノードのみがすべてのブロックデータを記憶する必要があり、帳簿データの安全を確保できる場合、帳簿データの冗長記憶を大幅に軽減し、関連リソースを節約する。
選択可能な実施例では、システムは更に１つの特別な公開身分の変換機構アカウントを設定してもよい。その作用はユーザーが導出不可能なローカル署名暗号鍵を有してそれを紛失した場合、クライアント側により１つの新しい署名暗号鍵をローカルに生成して、更新された身分認証証明書又はｅＩＤによってシステムにおいてユーザー情報を更新して、管理側により新しい暗号化暗号鍵を公布して新しい初期ｎｏｎｃｅ値を生成する（アカウント取引チェーンを更新する）。しかしながら、クライアント側の新しい署名暗号鍵が前のロックスクリプトをアンロックできないため、変換機構アカウントにより１つの特別な変換取引を生成する必要がある。該変換取引は管理側により監査してユーザーの更新に成功した後、管理側のシステムにより開始される。変換取引は１回の入力及び１回の出力のみを含み、取引の入力はユーザーの元のアカウントを参照した１回の未使用の取引出力であり、取引の出力はユーザーが生成したばかりの取引アドレスであり、変換機構アカウントは該取引データを署名して、１つの特別な第１アンロックスクリプトを生成し、ユーザーの元のアカウントの１回の未使用の取引出力を１回の新しい未使用の取引出力に変換させる。このように、変換取引によってユーザーのローカル署名暗号鍵が紛失された後に資産を損失させるという問題を解決することができる。そして、変換取引は特別なアンロックスクリプトを除き、残りが一般的な取引に合致し、従って、ユーザーの身分プライバシーを保護するよう、外部は対応するユーザー情報及び取引額を把握しない。そして、特別なアンロックスクリプトに用いるのが身分を公開した変換機構アカウントの署名であるため、外部は該署名を検証することができて、該取引が変換取引であることを把握できる。変換取引も前記チェーン構造に応じて変換取引をユーザーの新しいアカウント取引チェーンにおいて行わせる。変換取引が管理側のシステムにより開始されるため、変換取引の入力及び出力が同じユーザーの取引アドレスであるかどうかを監督管理する必要があり、管理側により対応する暗号鍵を監督管理者に承認し（又はＫ値パラメータ、ユーザーを検証する証明書署名公開鍵とＫ値の演算結果が対応のアドレスを生成する）、監督管理者は対外パブリックチェーンにおいて検証してもよい。
選択可能な実施例では、システムのユーザー暗号鍵及び証明書は定期更新メカニズムを有してもよく、且つユーザーのアカウント取引チェーンを同時に更新する。従って、前のアカウント取引チェーンにおけるすべての未使用の出力は新しいアカウント取引チェーンに移転することとなる。従って、古いブロックデータにおける取引データは更新のため未使用の出力を有しなくなり、管理側はポリシーによって古いブロックデータをアーカイブ・除去してもよい。そして、クライアント側はアカウント取引チェーンを再確立したため、クライアント側のデータ量を長期間に制御可能範囲に維持できる。
上記例では、アカウント取引チェーンに関連付けられるのはユーザーのすべての受信取引であり、ユーザーのすべての送信取引を最後にすべてアカウント取引チェーンに関連付けることを可能にするために、支出額より大きい額を入力して、ステップ３０では、１つの釣り出力を有させ、又は額がゼロである釣り出力を強制的に出力させる（アカウント取引チェーンを更新するとき、未使用の出力を新しいアカウント取引に移転する必要があるため、ゼロ出力をできる限り回避する）。このように、すべての送信取引はいずれも１つの釣り出力を生成して、ユーザーのアカウント取引チェーンに関連付けることとなり、それによりユーザーのすべての取引をいずれもアカウント取引チェーンに関連付ける。
クライアント側の取引データは、より短い時間（プライベートチェーンが１つのデータブロックを生成してチェーン生成ノードに同期する時間）内に対外パブリックチェーンのチェーン生成ノードに同期でき、このとき、クライアント側は受信取引アドレスによって取引情報をクエリして取引データを取得し、管理側の裏書署名、クライアント側のアンロック署名及び取引額を検証することができるが、このときの取引データはまだ対外パブリックチェーンに追加されておらず、少額取引の場合、ユーザーは取引に成功したと見なしてもよい。多額取引の場合、取引に成功するように確保するために、所定期間待ってもよく、取引データを対外パブリックチェーンに追加していくつかの確認を経て、ＳＰＶによって関連情報を検証すれば、取引があって改竄不可能で不可逆であると見なされてもよい。
本実施例のシステムにおいて、管理側、クライアント側並びに機構の署名暗号鍵及び対称暗号化暗号鍵、ひいては対応するアルゴリズムは更新可能であり、互いに依存しないため、一部のユーザーの更新に起因して利用不可能になることがない。秘密共有サブ暗号鍵及び機密取引暗号鍵は、一部のユーザーが暗号鍵を更新しても利用不可能になることもなく、秘密共有アルゴリズムを更新することはクライアント側に新旧アルゴリズムに対応する暗号鍵を同時に発行でき、次にあるブロックの高さで新しい秘密共有アルゴリズムをイネーブルし、従って、利用不可能になることもない。しかしながら、機密取引アルゴリズムを更新すると、新旧アルゴリズムのユーザーが互いに取引することができなくなり、且つアルゴリズムの更新に起因して暗号文による取引額の検証が不可能になると、システムのｔｏｋｅｎ総量が一定でなくなる。システムのｔｏｋｅｎ総量が一定であるように確保するために、機密取引アルゴリズムの更新は回収再発行ポリシーを用いてもよい。新旧機密取引アルゴリズムが交換不可能であるため、新旧アルゴリズムのｔｏｋｅｎが等値であるが同じではないと見なされてもよく、徐々に等値の新旧ｔｏｋｅｎを発行機構に回収して再発行し、更に発行機構により新旧ｔｏｋｅｎをユーザーに回収・発行し、システムにも新旧ｔｏｋｅｎの取引が同時にあれば、システムが徐々に移行して新旧ｔｏｋｅｎの置換を完了するようにすることができ、且つ置換過程においてシステムにおける新旧ｔｏｋｅｎの総量が一定であるように確保することができる。システムのハッシュアルゴリズムもあるブロックの高さで新しいハッシュアルゴリズムをイネーブルしてもよく、新旧アドレスの置換によって、システムが徐々に移行を完了するようにすることができる。上記した一部のユーザーによる更新を用いてもよいことは、システムが何回かに分けて順次更新するメカニズムを用いてもよいことである。ユーザーのアカウント取引チェーンを更新する必要がある場合、取引アドレスを生成するための新しい暗号鍵及び新しい初期ｎｏｎｃｅ値を公布して、あるブロックの高さで発効するように指定してもよい。従って、システムのパスワードアルゴリズムはすべて更新可能であり、将来では安全保障を有する抗量子計算のパスワードアルゴリズムに更新してアップグレードされてもよい。
以上の管理側のプライベートチェーンシステムはプライベートチェーンシステムに限らず、更にコンソーシアムチェーンの方式を用いてもよい。そして、対外のパブリックチェーンシステムはパブリックチェーンシステムに限らず、コンソーシアムチェーンの方式を用いてもよく、且つデータの安全性を強化することができ、以下、例を挙げて説明する。
データの安全性を確保して、量子コンピュータはユーザー暗号鍵がクラッキングされたためプライバシーが漏れるという問題を防止するために、対外のパブリックチェーンシステムは対外のコンソーシアムチェーンの方式を用いてもよい。制御データにおける平文データは対外公開されるが、ユーザーＩＤプライバシーに関わる暗号化データ及び暗号化初期ｎｏｎｃｅ値は対外公開されていない。取引データにおける入力参照及び出力アドレスデータ並びにタイムスタンプデータは対外公開されるが、取引額及びアドレスパラメータ並びに選択可能な暗号化ユーザー識別子は対外公開されていない。対外システムのブロックヘッダーデータは対外公開されており、コンソーシアムチェーンのコモンセンス方式が決定されたものであるため、コモンセンスになると不可逆となり、すべてのクライアント側、第三者及び監督管理者はいずれも対外システムのブロックヘッダーデータを同期し、且つ迅速に相互検証を行うことができ（例えば、秘密メッセージと、初期ブロック番号から指定されたブロック番号までのブロックヘッダーデータのハッシュ値、及び指定されたブロック番号から最後のブロック番号までのブロックヘッダーデータにより生成されたハッシュ演算結果と、を比較する）、従って、ブロックヘッダーデータが信頼可能なものであると見なされる。且つ、取引データにおける未対外公開のデータ（取引額、アドレスパラメータ及び選択可能な暗号化ユーザー識別子）を、量子計算によるクラッキングを防止するハッシュ演算結果で、取引データにおける署名すべき未対外公開のデータを置換してもよく、入力参照も置換後のデータを用いる。このように、外部はＵＴＸＯの入力参照及び出力アドレスによって、取引が未使用の出力を参照したかどうか、及び二重支払いがないかどうかを検証してもよく、且つ取引の時間情報を取得でき、並びに取引データの管理側の裏書署名及びクライアント側のアンロック署名を検証することができる。クライアント側、監督管理者及びチェーン生成ノードは未公開のデータを取得して取引額の検証（暗号文の検証）を完了することができ、且つクライアント側は自体の関連取引データにおける未公開のデータしか取得できず、クライアント側は更にＳＰＶ検証によって取引データがあるかどうかを検査してもよい。そして、ｎｏｎｃｅ値及び暗号化暗号鍵によって次の受信取引アドレスのパラメータＫ値を計算することは、量子計算によるクラッキングを防止するハッシュ演算を用いてもよく、即ち同じ取引における複数のユーザーにとって、共有情報によって他のユーザーのアカウント取引チェーンを取得できず、且つブロックヘッダーデータが信頼可能なものであるため、ＳＰＶ検証によって他の取引データのハッシュ演算結果を取得する必要があるだけで、重要な情報が漏れない場合にユーザーデータを信頼可能にするという目的を実現する。量子コンピュータの出現に起因して公開されたＵＴＸＯの入力参照及び出力アドレスに対応する暗号鍵がクラッキングされても、取引額及びアドレスパラメータを公開しないため、関連する取引額を取得できず、及び関連する出力アドレスがどのユーザーの公開鍵により演算されたかを取得することができず、すべてのユーザー公開鍵がいずれも関連する可能性を有する（いずれも対応するＫ｀値を見つけることができる）ため、ユーザーのアカウント取引チェーンも取得できなく、ユーザーの身分プライバシーを保護する。多重署名アドレスの場合、同じＫ値の利用によるプライバシーの漏れを回避するよう、多重署名アドレスの各公開鍵に関連するＫ値パラメータを生成することは、異なる方式で異なるＫ値を生成する必要がある。上記制御データ及び取引データにおける未対外公開のデータはＭｅｒｋｌｅ Ｔｒｅｅルートハッシュを計算するとき、量子計算によるクラッキングを防止するハッシュ演算結果に置換されてもよく、改竄を防止するように第三者もチェーンの正当性を検証してもよい。システムのパスワードアルゴリズムは更新可能で、将来では安全保障を有する抗量子計算のパスワードアルゴリズムに更新してアップグレードすることが可能であるため、システムをスムーズに移行させることができ、公開されたデータに起因して前の取引データのユーザーのプライバシーを漏らすことがない。
対外パブリックチェーンにおいて取引検証が２つのステップに分けてそれぞれ行われてもよい。第１ステップでは取引の入力参照が正しいかどうか、二重支払いがあるかどうか、ブロックヘッダーの有効性等を検証する。このステップは入力参照及び出力アドレス、並びにブロックデータのハッシュ演算結果のみを検証する必要があり、検証速度が速く、対外のコンソーシアムチェーンにおけるデータでも完全に公開されたものであるため、公開された検証サービスとされてもよい。第２ステップでは取引データの署名及び取引額を検証し、検証速度がより遅く、且つ対外のコンソーシアムチェーンの場合に取引額を検証するために未公開の一部の取引データを必要とする。取引データ同士が独立したものであるため、並行方式で検証してもよい。大量のデータによる性能のボトルネックを回避するよう、チェーン生成ノードは対応するポリシーを用いてもよい。
本実施例では、パブリックチェーンでのデータ記録がシステムルールに準拠するように励んで確保するために、管理側のプライベートチェーンがコモンセンス報奨を発行してパブリックチェーンに同期する。システムのコモンセンス報奨過程は、管理側がパブリックチェーンにおける報奨すべきチェーン生成ノードの関連情報を取得し、複数（例えば、６つ）のパブリックチェーンのブロックデータが確認された後、制御データにおいて平文で報奨を対応のアカウントに公布し、次に制御データにおける報奨の情報に基づいて取引データにおいて１つの特別な報奨取引を生成する（下記システムｔｏｋｅｎの発行を参照する）ことを含んでもよい。以上によれば、パブリックチェーンにおけるコモンセンス報奨は以後のデータブロックにおいて管理側により公布され、且つ報奨が不可逆であり、報奨ルールが管理側により決定される。チェーン生成ノードは生成チェーンの情報に最後のアカウント取引チェーンのアドレスパラメータにより生成された受信取引アドレスを保存し、管理側は対応するコモンセンス報奨を対応のアドレスに発行することとなり、従って、該報奨取引もユーザーアカウント取引チェーンにある。
システムにおけるｔｏｋｅｎ総量の変化が管理側により制御され、管理側により制御データにおいて対応数のｔｏｋｅｎを平文で発行し又は回収し、指定された発行機構によって１回の特別な発行又は回収取引を生成する。まず、制御データにおいて対応する発行は回収平文情報（今回発行又は回収したアドレス、取引額平文及び関連するＫ値パラメータ等）を公布した後、後続の取引データにおいて該特別な取引を生成することが可能になる。発行の場合、入力参照アドレスは特定の今回の発行アドレスであり、対応額は制御データにおける対応の額平文であり、出力アドレスは発行機構の公開鍵とＫ値とを演算したアドレス（発行機構のアカウント取引チェーンに属する）及び対応する暗号文額である。回収の場合、入力参照発行機構の公開鍵とＫ値とを演算したアドレス（発行機構の未使用の出力に属する）であり、出力アドレスは特定の今回の回収アドレスであり、対応額は制御データにおける対応の額平文であり、残高は暗号文方式で出力される。報奨取引は発行取引と類似する。特別な取引は一部のパラメータを公開してもよく、一部の平文を有する機密取引を検証してもよい。以上によれば、発行（又は報奨）及び回収取引にはいずれも特定アドレス、例えば発行用（１０・・・０Ｘ）、回収用（２０・・・０Ｘ）、報奨用（３０・・・０Ｘ）の関与を必要とし、Ｘが逓増を示し、これらの特定のアドレスはＵＴＸＯアドレスのコンテクスト関係を有せず、入力は未使用の取引出力を参照する必要がなく、出力も入力とされず、且つ発行又は報奨取引は管理側の裏書署名のみを必要とし、回収取引は対応する発行機構のアンロック署名及び管理側の裏書署名を必要とする。これらの特定アドレスの発行又は回収によって、システムにおけるｔｏｋｅｎ総量を調節する目的を実現するが、監督管理都合上、これらの情報はいずれも平文で公開されたものである。選択肢として、制御データにおいて対応する平文情報を公布した後、一定比率のパブリックチェーンのチェーン生成ノードによる投票確認を経て発効できる。投票結果がパブリックチェーンに記録され、即ちパブリックチェーンにはプライベートチェーンのブロックデータが含まれる以外に、更にパブリックチェーンの拡張データ、例えば投票結果が含まれてもよいが、拡張データはパブリックチェーンそのもののデータ状態に過ぎず、パブリックチェーン及びプライベートチェーン論理状態の相違に影響を与えない。対外パブリックチェーンのブロックヘッダーデータは、プライベートチェーンブロックにおける取引データにより生成されたＭｅｒｋｌｅ Ｔｒｅｅルートハッシュ、制御データ、並びにプライベートチェーンブロックヘッダーデータ及びパブリックチェーンの拡張データにより生成されたＭｅｒｋｌｅ Ｔｒｅｅルートハッシュを含み、更に前のパブリックチェーンブロックヘッダーのハッシュ値、ブロック番号、タイムスタンプ、コモンセンスパラメータ等を含む。パブリックチェーンにおいてパブリックチェーンのブロックヘッダーデータを迅速に検証してもよく、管理側プライベートチェーンのブロックヘッダーデータを迅速に検証してもよく、且つ偽造を防止するようにプライベートチェーンのブロックヘッダーデータが関連署名を有する。管理側はパブリックチェーンにおける投票情報を検証した後、取引データにおいて関連する特別な取引を生成することが可能になる。
本実施例では、本実施例のシステムを効果的に監督管理するために、自動監督管理及び／又は手動監督管理を用いてもよい。自動監督管理は主に取引データを監督管理し、取引が正当であるかどうか（例えば、アカウントが凍結されたかどうか、証明書がログオフされたかどうか、期限が過ぎたかどうか等）、管理側による裏書署名及びクライアント側によるアンロック署名が正しいかどうか、機密取引額が正しいかどうか、発行又は回収取引の場合に前の制御データに関連情報があるかどうか、変換取引の場合に入力及び出力が同じユーザーの取引アドレスであるかどうか、を検証する。自動監督管理及びチェーン生成ノードはいずれも取引額の有効性を検証し、システムにおけるｔｏｋｅｎの総量が一定であるように確保することができる。そして、手動監督管理は、一部が制御データに公布された平文情報を監督管理し、主に発行したｔｏｋｅｎ額が正当であるかどうかを含み、例えば管理側が関連の資産抵当又は保証金証明書等を有しなければ対応のｔｏｋｅｎを発行できず、他の一部がシステムにおけるいくつかのユーザーのアカウント情報を監督管理する必要があり、管理側は対応するクライアント側の暗号化暗号鍵を監督管理者に承認してもよく、これにより、監督管理者は該ユーザーのアカウント取引チェーン及び資産情報を取得することができる。
以上によれば、アカウント取引チェーンとブロックチェーンとは異なり、ブロックチェーンが物理的なもの、外部のもの、公開されたものであるが、アカウント取引チェーンが論理的なもの、内部のもの、隠されたものである。ブロックチェーンが解決するのは追跡可能、改竄不可能等の問題であるが、アカウント取引チェーンが解決するのはプライバシー及び使用し易さ等の問題であり、且つアカウント取引チェーンは無数のチェーンをブロックチェーンに溶け込むものである。
上記の中心化と分散化を組み合わせたシステムは、管理側を有するブロックチェーンシステムと見なされてもよい。管理側を有する複数のブロックチェーンシステム間のデータ転送は、該複数のシステムの管理側間に秘密チャネルを構築することで実現されてもよい。秘密チャネルに重要なデータが記憶されなくてもよく、データ交渉及びチェーン間転送をトリガーするチャネルのみとされ、ユーザー契約データはいずれもそれぞれのブロックチェーンシステムに記憶される。従って、クライアント側は対外パブリックチェーンから関連の契約データをクエリして、チェーン間契約ＩＤによって、異なるシステム間にデータを転送する契約データを関連付けさせ、これにより、クライアント側のウォレットはチェーン間契約の関連情報を取得することができる。秘密チャネルは複数の管理側間にコンソーシアムチェーンを確立することで実現されてもよい。
複数のブロックチェーンシステム間にデータ転送を行うとき、取引当事者は転送すべきシステムに新規登録する必要がある。例えば、ユーザーＡはシステムＳＡ及びシステムＳＢの管理側に新規登録し、ユーザーＢはシステムＳＡ及びシステムＳＢの管理側に新規登録する。取引当事者のクライアント側は取引相手が誰であるかを把握しないため、委託管理契約声明を行う必要がある。委託管理契約声明は上記取引と類似し、クライアント側が署名して管理側により裏書署名してチェーンアップされた後に発効し、ユーザーの資産がユーザーの委託管理アカウントに移転される。ユーザーの委託管理アカウントは前記方式で独立したユーザー委託管理アカウント取引チェーンを確立してもよく、委託管理アカウントの署名暗号鍵が第三者又は管理側により委託管理されてもよく、管理側が委託管理アカウントの取引をトリガーする際に使う。委託管理契約取引の公平性が管理側間のコンソーシアムチェーンにより確保され、契約取引にチェーン間契約ＩＤが含まれる必要がある。クライアント側のウォレットはパブリックチェーンにおける委託管理アカウント取引チェーンによってすべての委託管理取引を取得することができ、契約取引におけるチェーン間契約ＩＤによって、対応転送の他のパブリックチェーンにおけるユーザー委託管理アカウント取引チェーンから、該チェーン間契約ＩＤに関連する契約取引をクエリしてもよい。クライアント側のウォレットは委託管理契約声明情報及び２つのシステムの転送契約取引情報を取得した後、関連契約の実行状況を分析してもよい。
本例では、管理側を有する複数のブロックチェーンシステムの間に、取引当事者のクライアント側のチェーン間契約取引は、それぞれのシステムにおけるｔｏｋｅｎ総量の変化に影響を与えることがなく、両者のシステムにおける異なるユーザーｔｏｋｅｎの転送過程である。チェーン生成ノード及び監督管理者はいずれもそれぞれのシステムにおける委託管理契約取引額の有効性を検証し、システムにおけるｔｏｋｅｎの総量が一定であるように確保してもよい。そして、管理側を有する複数のブロックチェーンシステムの間に、管理側同士がコンソーシアムチェーンを確立した後、ユーザーデータのシステム間での転送を実現することができ、且つ監督管理都合上、転送するデータはいずれも対応するパブリックチェーンに記録されてクエリ・検証されることができる。
以上の例はＵＴＸＯモデルの取引アドレスにより形成されたアカウント取引チェーンであり、更に類似の方式でアカウント取引チェーンを形成してもよく、以下、システムがアカウント残高モデルである場合を例として説明する。システムがアカウント残高モデルである場合、入力参照アドレス及び出力アドレスの概念がないため、取引データにはユーザーアカウント識別子及び対応する取引額のみがあり、クライアント側の送信取引及び受信取引も依存関係がなく、従って、送信取引ＩＤ及び受信取引ＩＤによって、クライアント側の取引データに１つの送信チェーン及び１つの受信チェーン又は兄弟ノードのある受信チェーンを形成させることができる。送信取引ＩＤはクライアント側の前回の送信取引のｎｏｎｃｅ値とクライアント側の暗号化暗号鍵が一方向の不可逆関数により生成したものであり、送信取引ＩＤはシステムにおいて唯一なものであり、受信取引ＩＤはクライアント側の前回の受信取引のｎｏｎｃｅ値とクライアント側の暗号化暗号鍵が一方向の不可逆関数により生成したものであり、システムにおいて異なるクライアント側の受信取引ＩＤが唯一なものであるが、並行取引があるため、同じクライアント側にある異なる受信取引は同じ受信取引ＩＤを有する。クライアント側は管理側に新規登録するとき、管理側によりランダムな初期ｎｏｎｃｅ値及び初期受信取引ＩＤを生成して、クライアント側の対称暗号化暗号鍵を利用して暗号化して記憶する。取引時にｎｏｎｃｅ値とクライアント側の暗号化暗号鍵とは一方向の不可逆関数によって送信取引ＩＤを生成する。ｎｏｎｃｅ値が管理側によりランダムに生成され、且つ計算された次の送信取引ＩＤ及び受信取引ＩＤ（受信者にとって）がシステムにおいて唯一なものであるように確保する。そして、初期受信取引ＩＤがユーザーの１番目の受信取引のＩＤであり、ユーザーの受信取引ＩＤが状態ツリーにおけるユーザー受信取引ＩＤに等しい場合、取引のｎｏｎｃｅ値及びユーザーの暗号化暗号鍵により生成された受信取引ＩＤを利用して状態ツリーにおける受信取引ＩＤを更新する。以上によれば、送信取引ＩＤは前回の送信取引のｎｏｎｃｅ値（又は初期ｎｏｎｃｅ値）に依存する必要があり、且つリプレイアタックを防止するように並行取引を行うことができず、従って、１つの送信チェーンを形成する。そして、受信取引ＩＤが前記受信取引アドレスと類似の方式を用いるため、１つの受信チェーン又は兄弟ノードのある受信チェーンを形成する。この２つのチェーンはシステムがアカウント残高モデルである場合のアカウント取引チェーンを形成する。
当業者であれば理解できるように、以上に公開される方法における全部又は一部のステップ、システム、装置における機能モジュール／ユニットはソフトウェア、ファームウェア、ハードウェア及びそれらの適切な組み合わせとして実施されてもよい。ハードウェア実施形態では、以上の説明に言及した機能モジュール／ユニット間の区別は物理コンポーネントの区別に対応するとは限らず、例えば、１つの物理コンポーネントは複数の機能を有してもよく、又は１つの機能又はステップは１つ又は複数の物理コンポーネントが協力して実行してもよい。いくつかのコンポーネント又はすべてのコンポーネントはプロセッサ、例えばデジタルシグナルプロセッサ又はマイクロプロセッサにより実行されるソフトウェアとして実施され、又はハードウェアとして実施され、又は集積回路、例えば特定用途向け集積回路として実施されてもよい。このようなソフトウェアはコンピュータ可読媒体に配置されてもよく、コンピュータ可読媒体はコンピュータ記憶媒体（又は非一時的媒体）及び通信媒体（又は一時的媒体）を含んでもよい。当業者であれば理解できるように、コンピュータ記憶媒体の用語は情報（例えば、コンピュータ可読命令、データ構造、プログラムモジュール又は他のデータ）を記憶するためのいかなる方法又は技術において実施される揮発性及び不揮発性、取り外し可能及び固定媒体を含む。コンピュータ記憶媒体はＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリ又は他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）又は他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ又は他の磁気記憶装置、又は所望の情報を記憶するために使用することができてコンピュータによってアクセスすることが可能ないかなる他の媒体を含むが、それらに限らない。なお、当業者であれば理解できるように、通信媒体は一般的にコンピュータ可読命令、データ構造、プログラムモジュール又はキャリア又は他の伝送メカニズム等の変調データ信号における他のデータを含み、且ついかなる情報配信媒体を含んでもよい。
当業者であれば理解すべきように、本願の技術案の趣旨及び範囲を逸脱せずに、本願の実施例の技術案に対して修正や等価置換を行うことができ、これらの修正や等価置換はいずれも本願の特許請求の範囲に含まれるべきである。

Claims (25)

  1. データ処理方法であって、
    取引データが検証に成功して裏書署名してから第１チェーンシステムのブロックデータに書き込まれることと、
    前記第１チェーンシステムのブロックデータが第２チェーンシステムのブロックデータに書き込まれ、前記第２チェーンシステムのブロックデータが前記第１チェーンシステムの１つ又は複数のブロックデータで順次構成され、前記第１チェーンシステムにおけるいずれか１つのアカウントの状態が前記第２チェーンシステムにおける前記アカウントの状態に合致することと、を含むデータ処理方法。
  2. 前記第１チェーンシステムがプライベートチェーンを含み、前記第２チェーンシステムがパブリックチェーン又はコンソーシアムチェーンを含み、又は
    前記第１チェーンシステムがコンソーシアムチェーンを含み、前記第２チェーンシステムがパブリックチェーン又はコンソーシアムチェーンを含む請求項１に記載の方法。
  3. 前記取引データが検証に成功して裏書署名してから第１チェーンシステムのブロックデータに書き込まれることは、
    取引データの検証に成功した後、前記取引データを裏書署名し、裏書署名後の取引データが第１チェーンシステムのブロックデータに書き込まれることを含み、
    前記取引データは取引受信側の取引アドレスと今回取引時に生成したアドレスパラメータとを含み、前記取引アドレスは前記取引受信側が前回取引を受信する際に生成したアドレスパラメータを利用して生成したものであり、前記今回取引時に生成したアドレスパラメータは前記取引受信側が次回取引を受信する取引アドレスを生成することに用いられ、同じ取引受信側のすべての受信取引データに論理チェーン構造を形成させる請求項１又は２に記載の方法。
  4. 取引データを検証する前に、前記方法は更に、アドレスパラメータを生成し、状態ツリーから前記取引受信側の取引アドレスを検索し、取引送信側が前記取引アドレス及びアドレスパラメータを取引データに追加するよう、生成されたアドレスパラメータ及び検索された前記取引アドレスを前記取引送信側に送信することを含み、
    前記取引データを裏書署名した後、前記方法は更に、前記取引データにおける取引アドレスが前記状態ツリーにおける前記取引受信側の取引アドレスと同じであると判断した場合、前記生成されたアドレスパラメータを利用して新しい取引アドレスを生成して、前記状態ツリーにおける前記取引受信側の取引アドレスを更新することを含む請求項３に記載の方法。
  5. 前記生成されたアドレスパラメータを利用して新しい取引アドレスを生成することは、
    関数を利用して前記生成されたアドレスパラメータ及び前記取引受信側の暗号鍵を１回又は複数回演算して、取引アドレスを生成することを含む請求項４に記載の方法。
  6. 前記取引受信側の取引アドレスは、第１関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して第１中央値を取得し、第２関数を利用して前記第１中央値及び前記取引受信側のユーザー公開鍵を演算して第１公開鍵を取得し、第３関数を利用して前記第１公開鍵を演算して取引アドレスを取得するという方式で生成され、又は
    前記取引受信側の取引アドレスが多重署名アドレスであり、前記多重署名アドレスは、異なる関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して複数の中央値を取得し、第４関数を利用してそれぞれ各中央値及び前記取引受信側の複数のユーザー公開鍵を演算して複数の新しい公開鍵を取得し、第５関数を利用して前記複数の新しい公開鍵を演算して多重署名アドレスを取得するという方式で生成される請求項５に記載の方法。
  7. 前記方法は更に、
    ユーザーが新規登録するとき、前記ユーザーの初期アドレスパラメータを生成して、状態ツリーに前記初期アドレスパラメータにより生成された取引アドレスを記録すること、又は
    新しい暗号鍵を公布されたユーザーのために初期アドレスパラメータを改めて生成して、状態ツリーに前記改めて生成された初期アドレスパラメータにより生成された取引アドレスを記録し、前記新しい暗号鍵が取引アドレスの生成のための暗号鍵であることを含む請求項５に記載の方法。
  8. 前記方法は更に、
    クライアント側の開始した暗号鍵更新要求を受信し、前記クライアント側に対して身分認証を行った後、新しい暗号化暗号鍵を公布し、変換取引プロセスを開始し、変換機構アカウントをイネーブルして取引を開始し、前記クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、前記変換機構アカウントの署名暗号鍵により前記取引データを署名して、第１アンロックスクリプトを生成することを含む請求項３に記載の方法。
  9. 前記方法は更に、
    トークン（ｔｏｋｅｎ）を発行するための指定された発行取引を生成し、前記指定された発行取引における入力アドレスが第１フォーマットを用いるアドレスであるステップ、
    ｔｏｋｅｎを回収するための指定された回収取引を生成し、前記指定された回収取引における出力アドレスが第２フォーマットを用いるアドレスであるステップ、
    ｔｏｋｅｎを報奨するための指定された報奨取引を生成し、前記指定された報奨取引における入力アドレスが第３フォーマットを用いるアドレスであるステップ、のうちの１つ又は複数を含む請求項１に記載の方法。
  10. データ処理方法であって、
    取引受信側が前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成し、第２チェーンシステムから前記取引アドレスを含む取引データを検索することを含み、
    前記第２チェーンシステムにおけるブロックデータが第１チェーンシステムの１つ又は複数のブロックデータで順次構成され、前記第１チェーンシステムにおけるいずれか１つのアカウントの状態が前記第２チェーンシステムにおける前記アカウントの状態に合致するデータ処理方法。
  11. 管理側により状態ツリーから取得したアカウント状態と第２チェーンシステムから取得したアカウント状態とを比較することを更に含む請求項１０に記載の方法。
  12. 前記取引受信側が取引送信側とされる場合、前記方法は更に、
    前記取引送信側が取引を提出するとき、受信取引データを参照した前回の受信取引データにおけるアドレスパラメータを利用して公開鍵／秘密鍵対を生成し、前記公開鍵／秘密鍵対を利用して現在の取引におけるアンロックスクリプトを生成することを含む請求項１０に記載の方法。
  13. データ処理方法であって、
    変換取引を開始し、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第１アンロックスクリプトを生成し、それによりクライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換し、前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第１チェーンシステムのブロックデータに書き込まれ、前記第１チェーンシステムのブロックデータが第２チェーンシステムのブロックデータに書き込まれ、前記第２チェーンシステムのブロックデータが前記第１チェーンシステムの１つ又は複数のブロックデータで順次構成され、前記第１チェーンシステムにおけるいずれか１つのアカウントの状態が前記第２チェーンシステムにおける前記アカウントの状態に合致することを含むデータ処理方法。
  14. 管理側装置であって、検証モジュールと裏書署名モジュールを備え、
    前記検証モジュールは、取引データを検証するように設定され、
    前記裏書署名モジュールは、前記検証モジュールが取引データの検証に成功した後、前記取引データを裏書署名し、裏書署名後の取引データが第１チェーンシステムのブロックデータに書き込まれるように設定され、
    前記取引データは取引受信側の取引アドレスと今回取引時に生成したアドレスパラメータとを含み、前記取引アドレスは前記取引受信側が前回取引を受信する際に生成したアドレスパラメータを利用して生成したものであり、前記今回取引時に生成したアドレスパラメータは前記取引受信側が次回取引を受信する取引アドレスを生成することに用いられ、同じ取引受信側のすべての受信取引データに論理チェーン構造を形成させる管理側装置。
  15. 前記装置は第１アドレス生成モジュールを更に備え、前記第１アドレス生成モジュールは、アドレスパラメータを生成し、状態ツリーから前記取引受信側の取引アドレスを検索し、生成されたアドレスパラメータ及び検索された前記取引アドレスを取引送信側に送信するように設定され、及び、前記取引データにおける取引アドレスが前記状態ツリーにおける前記取引受信側の取引アドレスと同じであると判断した場合、前記生成されたアドレスパラメータを利用して新しい取引アドレスを生成して、前記状態ツリーにおける前記取引受信側の取引アドレスを更新するように設定される請求項１４に記載の管理側装置。
  16. 前記第１アドレス生成モジュールが前記生成されたアドレスパラメータを利用して新しい取引アドレスを生成することは、前記第１アドレス生成モジュールが関数を利用して前記生成されたアドレスパラメータ及び前記取引受信側の暗号鍵を１回又は複数回演算して、取引アドレスを生成することを含む請求項１５に記載の管理側装置。
  17. 前記第１アドレス生成モジュールは、前記第１アドレス生成モジュールが第１関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して第１中央値を取得し、第２関数を利用して前記第１中央値及び前記取引受信側のユーザー公開鍵を演算して第１公開鍵を取得し、第３関数を利用して前記第１公開鍵を演算して取引アドレスを取得するという方式で、前記取引受信側の取引アドレスを生成し、又は
    前記第１アドレス生成モジュールは、前記取引受信側の取引アドレスが多重署名アドレスであり、前記第１アドレス生成モジュールが異なる関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して複数の中央値を取得し、第４関数を利用してそれぞれ各中央値及び前記取引受信側の複数のユーザー公開鍵を演算して複数の新しい公開鍵を取得し、第５関数を利用して前記複数の新しい公開鍵を演算して多重署名アドレスを取得するという方式で、前記取引受信側の取引アドレスを生成する請求項１６に記載の管理側装置。
  18. 前記第１アドレス生成モジュールは更に、ユーザーが新規登録するとき、前記ユーザーの初期アドレスパラメータを生成して、状態ツリーに前記初期アドレスパラメータにより生成された取引アドレスを記録するように設定され、及び、
    前記第１アドレス生成モジュールは更に、新しい暗号鍵を公布されたユーザーのために初期アドレスパラメータを改めて生成して、状態ツリーに前記改めて生成された初期アドレスパラメータにより生成された取引アドレスを記録するように設定され、前記新しい暗号鍵は取引アドレスを生成するための暗号鍵である請求項１６に記載の管理側装置。
  19. 前記装置は暗号鍵公布モジュールと変換取引モジュールを更に備え、
    前記暗号鍵公布モジュールは、クライアント側の開始した暗号鍵更新要求を受信し、前記クライアント側に対して身分認証を行った後、新しい暗号化暗号鍵を公布するように設定され、
    前記変換取引モジュールは、変換取引プロセスを開始し、変換機構アカウントをイネーブルして取引を開始し、前記クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、前記変換機構アカウントの署名暗号鍵により前記取引データを署名して、第１アンロックスクリプトを生成するように設定される請求項１４に記載の管理側装置。
  20. 前記装置は発行取引モジュール、回収取引モジュール及び報奨取引モジュールのうちの１つ又は複数を更に備え、
    前記発行取引モジュールは、ｔｏｋｅｎを発行するための指定された発行取引を生成するように設定され、前記指定された発行取引における入力アドレスは第１フォーマットを用いるアドレスであり、
    前記回収取引モジュールは、ｔｏｋｅｎを回収するための指定された回収取引を生成するように設定され、前記指定された回収取引における出力アドレスは第２フォーマットを用いるアドレスであり、
    前記報奨取引モジュールは、ｔｏｋｅｎを報奨するための指定された報奨取引を生成するように設定され、前記指定された報奨取引における入力アドレスは第３フォーマットを用いるアドレスである請求項１４に記載の管理側装置。
  21. クライアント側装置であって、第２アドレス生成モジュールと検索モジュールを備え、
    前記第２アドレス生成モジュールは、前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成するように設定され、
    前記検索モジュールは、第２チェーンシステムから前記取引アドレスを含む取引データを検索するように設定されるクライアント側装置。
  22. 前記クライアント側装置は、管理側により状態ツリーから取得したアカウント状態と第２チェーンシステムから取得したアカウント状態とを比較するように設定される検証モジュールを更に備える請求項２１に記載のクライアント側装置。
  23. 前記クライアント側装置は署名モジュールを更に備え、前記署名モジュールは、前記クライアント側が取引送信側とされる場合、取引を提出するとき、受信取引データを参照した前回の受信取引データにおけるアドレスパラメータを利用して公開鍵／秘密鍵対を生成し、前記公開鍵／秘密鍵対を利用して現在の取引におけるアンロックスクリプトを生成するように設定される請求項２１に記載のクライアント側装置。
  24. 変換装置であって、開始モジュールと署名モジュールを備え、
    前記開始モジュールは、管理側装置のイネーブルに基づいて変換取引を開始するように設定され、
    前記署名モジュールは、クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第１アンロックスクリプトを生成するように設定され、
    前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第１チェーンシステムのブロックデータに書き込まれ、前記第１チェーンシステムのブロックデータが第２チェーンシステムのブロックデータに書き込まれ、前記第２チェーンシステムのブロックデータが前記第１チェーンシステムの１つ又は複数のブロックデータで順次構成され、前記第１チェーンシステムにおけるいずれか１つのアカウントの状態が前記第２チェーンシステムにおける前記アカウントの状態に合致する変換装置。
  25. コンピュータ可読記憶媒体であって、コンピュータ命令が記憶され、該命令がプロセッサにより実行されるとき、請求項１〜９のいずれか１項又は請求項１０〜１２のいずれか１項又は請求項１３に記載の方法のステップを実現するコンピュータ可読記憶媒体。
JP2020562824A 2018-03-14 2019-02-01 ブロックチェーンのデータ処理方法、管理側、クライアント側、変換装置及び媒体 Pending JP2021512569A (ja)

Applications Claiming Priority (5)

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 一种区块链数据处理方法、装置及计算机可读存储介质
PCT/CN2019/074440 WO2019174430A1 (zh) 2018-03-14 2019-02-01 区块链数据处理方法、管理端、用户端、转换装置及介质

Publications (2)

Publication Number Publication Date
JP2021512569A true JP2021512569A (ja) 2021-05-13
JP2021512569A5 JP2021512569A5 (ja) 2021-06-24

Family

ID=67907351

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020562824A Pending JP2021512569A (ja) 2018-03-14 2019-02-01 ブロックチェーンのデータ処理方法、管理側、クライアント側、変換装置及び媒体

Country Status (9)

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

Families Citing this family (30)

* 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
WO2020130331A1 (ko) * 2018-12-21 2020-06-25 (주)소프트제국 블록체인에서 노드들간 블록 및 전자 문서를 공유 및 검증하는 방법
US11838400B2 (en) * 2019-11-19 2023-12-05 International Business Machines Corporation Image encoding for blockchain
CN111212026A (zh) * 2019-11-21 2020-05-29 深圳壹账通智能科技有限公司 基于区块链的数据处理方法、装置及计算机设备
CN111159288B (zh) * 2019-12-16 2023-04-28 郑杰骞 链式结构数据存储、验证、实现方法、***、装置及介质
CN111181730A (zh) * 2019-12-31 2020-05-19 航天信息股份有限公司 用户身份生成及更新方法和装置、存储介质和节点设备
US11146386B2 (en) * 2020-01-17 2021-10-12 Agile Blockchain Corp. Method and system for authentication seal deployment in networked immutable transactions
CN111275554A (zh) * 2020-01-22 2020-06-12 北京瑞卓喜投科技发展有限公司 一种证券型通证的交易方法和***、存储介质
KR102141069B1 (ko) * 2020-02-26 2020-08-04 주식회사 아트블록코리아 투명한 거래이력 관리를 가능하게 하는 자산 거래 시스템
CN111460525B (zh) * 2020-03-31 2024-06-18 腾讯科技（深圳）有限公司 一种基于区块链的数据处理方法、装置及存储介质
CN111209346B (zh) * 2020-04-24 2020-07-28 腾讯科技（深圳）有限公司 一种区块链数据归档方法、装置和计算机可读存储介质
CN111640017B (zh) * 2020-05-06 2024-05-28 深圳前海微众银行股份有限公司 一种应用于联盟链跨链转账的交易正确性验证方法及装置
CN111598701B (zh) * 2020-05-22 2023-09-19 深圳市迅雷网络技术有限公司 一种信息监控方法、***、设备及存储介质
JP7432443B2 (ja) 2020-05-28 2024-02-16 株式会社日立製作所 移行支援システム、移行支援方法、およびノード
CN111626680B (zh) * 2020-06-02 2023-07-25 重庆云创科技有限公司 一种用于信誉评价的交易数据链式存储方法及区块链存储方法
WO2022000134A1 (zh) * 2020-06-28 2022-01-06 天津理工大学 一种基于供应链管理的商业数据保护方法及***
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 北京信息科技大学 一种基于区块链的航空重力数据安全访问控制方法及***
CN113328854B (zh) * 2021-05-24 2022-09-16 杭州溪塔科技有限公司 基于区块链的业务处理方法及***
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
CN115208898B (zh) * 2022-03-29 2023-12-08 深圳大学 区块广播方法、装置、计算机设备和存储介质
CN115170322B (zh) * 2022-09-05 2022-12-27 深圳市明源云科技有限公司 不动产产权的转让方法、装置、终端设备及计算机介质
CN117478303B (zh) * 2023-12-28 2024-03-01 湖南天河国云科技有限公司 区块链隐蔽通信方法、***和计算机设备

Citations (1)

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

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115174089B (zh) * 2015-04-20 2024-05-03 欧吉达克斯公司 物权电子凭证(edt)的分布式管理方法及其***
CN106372941B (zh) * 2016-08-31 2019-07-16 江苏通付盾科技有限公司 基于区块链的ca认证管理方法、装置及***
CN107786339A (zh) * 2016-08-31 2018-03-09 陈新 分层可控联盟区块链***
KR101837166B1 (ko) * 2016-10-26 2018-03-09 주식회사 코인플러그 블록체인 내의 블록별로 발란스 데이터베이스를 관리하여 통화를 발행 및 지급 결제하는 방법과 이를 이용한 서버
CN107733855B (zh) * 2017-08-31 2019-11-05 中国科学院信息工程研究所 一种可同时支持公有链、联盟链及私有链的区块链***及应用方法
CN108416578A (zh) * 2018-03-14 2018-08-17 郑杰骞 一种区块链***及数据处理方法
CN108647964B (zh) * 2018-05-02 2023-07-28 郑杰骞 一种区块链数据处理方法、装置及计算机可读存储介质

Patent Citations (1)

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

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
東角 芳樹 ほか: "コンソーシアムチェーンにおける証明書管理に関する一考察", ２０１７年 暗号と情報セキュリティシンポジウム（ＳＣＩＳ２０１７）予稿集 ［ＵＳＢ］, vol. １Ｆ２−３, JPN6018017174, 24 January 2017 (2017-01-24), JP, pages 1 - 4, ISSN: 0004755512 *
淵田 康之: "特集：イノベーションと金融 ブロックチェーンと金融取引の革新", 野村資本市場クォータリー, vol. 第１９巻第２号（通巻７４号）, JPN6016047552, 1 November 2015 (2015-11-01), JP, pages 11 - 35, ISSN: 0004755513 *
石黒 尚久 ほか, 最新ブロックチェーンがよ〜くわかる本, vol. 第１版, JPN6021037405, 1 August 2017 (2017-08-01), JP, pages 99 - 107, ISSN: 0004755514 *

Also Published As

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

Similar Documents

Publication Publication Date Title
JP2021512569A (ja) ブロックチェーンのデータ処理方法、管理側、クライアント側、変換装置及び媒体
CN109829326B (zh) 基于区块链的跨域认证与公平审计去重云存储***
US11336455B2 (en) Consensus protocol for blockchain DAG structure
US20230299938A9 (en) System for privacy protection during iot secure data sharing and method thereof
US11238543B2 (en) Payroll based blockchain identity
CN108418680B (zh) 一种基于安全多方计算技术的区块链密钥恢复方法、介质
CN108429759B (zh) 去中心化存储安全实现方法
WO2021120253A1 (zh) 链式结构数据存储、验证、实现方法、***、装置及介质
CN108647964B (zh) 一种区块链数据处理方法、装置及计算机可读存储介质
CN110288480B (zh) 一种区块链的私密交易方法及装置
US11323269B2 (en) Preserving privacy of linked cross-network transactions
CN115210741B (zh) 部分有序的区块链
US11580240B2 (en) Protecting sensitive data
CN114172735A (zh) 基于智能合约的双链混合式区块链数据共享方法及***
El Defrawy et al. Founding digital currency on secure computation
US11924348B2 (en) Honest behavior enforcement via blockchain
Kokoris-Kogias et al. Verifiable management of private data under byzantine failures
JP2024509666A (ja) ブロックチェーンデータセグリゲーション
US20220393858A1 (en) Limiting data availability on distributed ledger
JP2023551458A (ja) Ｏｐｒｆを介したブロックチェーンネットワークにおける鍵再生
Zhang et al. Data security in cloud storage
Dumas et al. LocalPKI: An interoperable and IoT friendly PKI
JP2023098847A (ja) 装置、方法、コンピュータプログラム（プライバシー保護ブロックチェーンの選択的監査プロセス）
US11632237B2 (en) Configuration override in a blockchain network
Fiore Providing trust to multi-cloud storage platforms through the blockchain

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200727

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200727

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210928

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20220420