JP2021512569A - ブロックチェーンのデータ処理方法、管理側、クライアント側、変換装置及び媒体 - Google Patents
ブロックチェーンのデータ処理方法、管理側、クライアント側、変換装置及び媒体 Download PDFInfo
- 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
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 25
- 238000006243 chemical reaction Methods 0.000 claims abstract description 61
- 238000000034 method Methods 0.000 claims description 82
- 230000007246 mechanism Effects 0.000 claims description 61
- 230000006870 function Effects 0.000 claims description 56
- 238000012795 verification Methods 0.000 claims description 34
- 230000008569 process Effects 0.000 claims description 11
- 238000010586 diagram Methods 0.000 abstract description 5
- 238000004422 calculation algorithm Methods 0.000 description 32
- 230000002427 irreversible effect Effects 0.000 description 17
- 230000005540 biological transmission Effects 0.000 description 14
- 238000004364 calculation method Methods 0.000 description 12
- 238000012546 transfer Methods 0.000 description 11
- 230000008859 change Effects 0.000 description 9
- 230000000694 effects Effects 0.000 description 4
- 230000001360 synchronised effect Effects 0.000 description 4
- 238000005336 cracking Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 238000012790 confirmation Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 230000000903 blocking effect Effects 0.000 description 1
- 239000000969 carrier Substances 0.000 description 1
- 238000013508 migration Methods 0.000 description 1
- 230000005012 migration Effects 0.000 description 1
- 239000000203 mixture Substances 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000008520 organization Effects 0.000 description 1
- 230000000737 periodic effect Effects 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 238000012545 processing Methods 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
- 238000013519 translation Methods 0.000 description 1
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
本願の実施例はブロックチェーンのデータ処理方法、管理側、クライアント側及び変換装置並びに記憶媒体を提供し、前記ブロックチェーンのデータ処理方法は、取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれることと、前記第1チェーンシステムのブロックデータが第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致することと、を含む。【選択図】図1
Description
本願はコンピュータデータ処理技術分野に関し、特にブロックチェーンのデータ処理方法、管理側装置、クライアント側装置、変換装置及びコンピュータ可読記憶媒体に関するが、それらに限らない。
従来の分散化システム、例えばパブリックチェーンシステムは公開、透明、追跡可能、改竄不可能等の特徴を有するため、取引関与者同士の信頼コストを削減することができ、信頼の基礎として価値伝達を実現することができる。
ところが、従来の分散化システムには、効率が低く、完全な監督管理及びプライバシー保護に欠け、token(代用貨幣又はトークンと称されてもよい)の発行も関連裏書を行わず、大量のデータにおいてプライベート取引を実現して検索することができないという問題がある。
以下は本明細書において詳しく説明された主題の概要である。本概要は特許請求の範囲を制限するためのものではない。
第1態様では、本願の実施例は管理側のデータ処理方法を提供し、
取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれることと、
前記第1チェーンシステムのブロックデータが第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致することと、を含む。
取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれることと、
前記第1チェーンシステムのブロックデータが第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致することと、を含む。
第2態様では、本願の実施例はクライアント側のデータ処理方法を提供し、
取引受信側が前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成し、第2チェーンシステムから前記取引アドレスを含む取引データを検索することを含み、前記第2チェーンシステムにおけるブロックデータが第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致する。
取引受信側が前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成し、第2チェーンシステムから前記取引アドレスを含む取引データを検索することを含み、前記第2チェーンシステムにおけるブロックデータが第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致する。
第3態様では、本願の実施例は変換装置のデータ処理方法を提供し、
変換取引を開始し、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第1アンロックスクリプトを生成し、それによりクライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換し、前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれ、前記第1チェーンシステムのブロックデータが第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致することを含む。
変換取引を開始し、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第1アンロックスクリプトを生成し、それによりクライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換し、前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれ、前記第1チェーンシステムのブロックデータが第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致することを含む。
第4態様では、本願の実施例は管理側装置を提供し、検証モジュール及び裏書署名モジュールを備え、
前記検証モジュールは、取引データを検証するように設定され、
前記裏書署名モジュールは、前記検証モジュールが取引データの検証に成功した後、前記取引データを裏書署名し、裏書署名後の取引データが第1チェーンシステムのブロックデータに書き込まれるように設定され、
前記取引データは取引受信側の取引アドレスと今回取引時に生成したアドレスパラメータとを含み、前記取引アドレスは前記取引受信側が前回取引を受信する際に生成したアドレスパラメータを利用して生成したものであり、前記今回取引時に生成したアドレスパラメータは前記取引受信側が次回取引を受信する取引アドレスを生成することに用いられ、同じ取引受信側のすべての受信取引データに論理チェーン構造を形成させる。
前記検証モジュールは、取引データを検証するように設定され、
前記裏書署名モジュールは、前記検証モジュールが取引データの検証に成功した後、前記取引データを裏書署名し、裏書署名後の取引データが第1チェーンシステムのブロックデータに書き込まれるように設定され、
前記取引データは取引受信側の取引アドレスと今回取引時に生成したアドレスパラメータとを含み、前記取引アドレスは前記取引受信側が前回取引を受信する際に生成したアドレスパラメータを利用して生成したものであり、前記今回取引時に生成したアドレスパラメータは前記取引受信側が次回取引を受信する取引アドレスを生成することに用いられ、同じ取引受信側のすべての受信取引データに論理チェーン構造を形成させる。
第5態様では、本願の実施例はクライアント側装置を提供し、第2アドレス生成モジュール及び検索モジュールを備え、
前記第2アドレス生成モジュールは、前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成するように設定され、
前記検索モジュールは、第2チェーンシステムから前記取引アドレスを含む取引データを検索するように設定される。
前記第2アドレス生成モジュールは、前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成するように設定され、
前記検索モジュールは、第2チェーンシステムから前記取引アドレスを含む取引データを検索するように設定される。
第6態様では、本願の実施例は変換装置を提供し、開始モジュール及び署名モジュールを備え、
前記開始モジュールは、管理側装置のイネーブルに基づいて変換取引を開始するように設定され、
前記署名モジュールは、クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第1アンロックスクリプトを生成するように設定され、
前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれ、前記第1チェーンシステムのブロックデータが第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致する。
前記開始モジュールは、管理側装置のイネーブルに基づいて変換取引を開始するように設定され、
前記署名モジュールは、クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第1アンロックスクリプトを生成するように設定され、
前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれ、前記第1チェーンシステムのブロックデータが第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致する。
第7態様では、本願の実施例はコンピュータ可読記憶媒体を提供し、コンピュータ命令が記憶され、該命令がプロセッサにより実行されるとき、上記管理側のデータ処理方法、クライアント側のデータ処理方法又は変換装置のデータ処理方法のステップを実現する。
図面及び詳細な説明を読んで理解した後、他の態様を理解することができる。
衝突しない限り、本願の実施例及び実施例の特徴は任意に組み合わせられてもよい。
図面のフローチャートに示されるステップは、1組のコンピュータ実行可能な命令のコンピュータシステム等において実行されてもよい。そして、フローチャートに論理順序を示すが、いくつかの場合、ここの順序と異なる順序で図示又は説明されるステップを実行してもよい。
本明細書及び上記図面における用語「第1」「第2」等は類似のオブジェクトを区別するためのものであって、特定の順序又は前後順序を説明するためのものではない。
背景技術における既存の問題を解決するために、本願の実施例は中心化と分散化とを組み合わせた信頼可能なシステムを提供する。
以下、まず本願の実施例に関わる概念を説明する。
tokenとはブロックチェーンにおける代用貨幣を指し、トークンとも称される。
パブリックチェーンとは誰でも取引を読み取って送信し、コモンセンスに関与することのできるブロックチェーンを指し、完全な分散化システムに属する。本明細書の実施例に用いるのは誰でも取引を送信することができること以外に、残りがパブリックチェーンシステムと同じである準パブリックチェーンシステムである。本明細書に記載の準パブリックチェーンシステムにおいて、誰でも取引を読み取んで検証し、コモンセンスに関与することができ、追跡可能、改竄不可能を実現することができる。
プライベートチェーンとは書き込み権限が1つの組織にあるデータチェーンを指し、中心化システムに属する。
コンソーシアムチェーンとは書き込み権限が複数の組織にあるデータチェーンを指し、部分的な分散化システムに属する。
eID(electronic Identity)とは国民のネットワーク電子アイデンティティ識別子を指し、信頼可能な実名認証方式である。
秘密の共有とは秘密メッセージを適切な方式でN部に分割し、M部又はM部以上が協力しなければ秘密メッセージを回復できないことを意味し、(M,N)と記され、MとNが1より大きな正の整数である。
本願の実施例は中心化と分散化とを組み合わせた信頼可能なシステムを提供する。本願の実施例では、中心化システム(第1チェーンシステム、第1チェーンとも称される)はプライベートチェーン又はコンソーシアムチェーンであってもよい。分散化システム(第2チェーンシステム、第2チェーンとも称される)はパブリックチェーン又はコンソーシアムチェーンであってもよい。第1チェーンがどのチェーンを用いるかは必ずしも第2チェーンがどのチェーンを用いるかに関連するとは限らない。例えば、第1チェーンがプライベートチェーンである場合、第2チェーンがパブリックチェーンであってもよく、コンソーシアムチェーンであってもよく、同様に、第1チェーンがコンソーシアムチェーンである場合、第2チェーンがパブリックチェーンであってもよく、コンソーシアムチェーンであってもよい。第2チェーンが対外公開する特性を有するため、本実施例において対外システムとも称される。中心化システムが管理者の役割(管理側ノード又は管理側装置であり、以下、管理側と略称される)及びユーザーの役割(クライアント側ノード又はクライアント側装置であり、以下、クライアント側と略称される)を有してもよい。選択肢として、第1チェーンシステムは更に1つ又は複数の特定の機構の役割(例えば、チェーン生成機構、発行機構、変換機構等のうちの1つ又は複数を含むが、それらに限らない)を含んでもよく、第1チェーンシステムは管理側システムであるため、以下では管理側の第1チェーンシステムとも称される。分散化システムがユーザーの役割(第1チェーンシステムにおけるユーザーの役割が第2チェーンシステムにおけるユーザーの役割と同じである)及びチェーン生成ノード(中心化システムのチェーン生成機構と異なり、チェーン生成機構が第1チェーンを生成し、チェーン生成ノードが第2チェーンを生成する)を有してもよい。選択肢として、第2チェーンシステムには更に第三者及び監督管理者が関与してもよく、第三者が他のいかなる者又は機構であってもよく、監督管理者が特定の権限(例えば、検証)を有する機構である。第2チェーンシステムは外部にクエリ、検証及び監督管理を提供するシステムであるため、以下に対外の第2チェーンシステムとも称される。
本願の実施例のデータ処理方法は図1に示されるように、以下のステップを含む。
ステップ1、取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれ、
ユーザーの提出した取引データは、管理側が取引データを検証して裏書署名する必要があり、検証に成功して裏書署名した取引データは、チェーン生成機構により第1チェーンのブロックデータに書き込まれる。
ユーザーの提出した取引データは、管理側が取引データを検証して裏書署名する必要があり、検証に成功して裏書署名した取引データは、チェーン生成機構により第1チェーンのブロックデータに書き込まれる。
ステップ2、前記第1チェーンシステムのブロックデータが第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致する。
第1チェーンが新しいブロックデータを生成した後、第2チェーンのチェーン生成ノードに同期することとなり、ブロックデータの検証に成功した後、チェーン生成ノードにより第2チェーンのコモンセンスアルゴリズムに基づいて新しいブロックデータを生成し、検証がブロックにおけるすべてのデータの検証を含む。そして、第2チェーンに管理側の第1チェーンの提出したブロックデータのみを順次記録し、且つ第2チェーンにおける各ブロックデータに含まれる第1チェーンのブロックデータの数は一定でなくてもよく、即ち第2チェーンにおける各ブロックは1〜n個の第1チェーンのブロックデータを含んでもよく、その数が第2チェーンのコモンセンスアルゴリズムによって決定される。従って、対外の第2チェーンシステムにおける各ブロックデータは、管理側の第1チェーンシステムの1つ又は複数のブロックデータで順次組み合わせられてなり、このため、管理側の第1チェーンシステムと対外の第2チェーンシステムとは論理状態において同じである。本実例に係る信頼可能なシステムは二層システム(管理側の第1チェーンシステムと対外の第2チェーンシステムとを含む)であると見なされてもよい。ところが、本願は制限しない。実際の応用のとき、該システムは更に多層システムに拡張されてもよく、例えば、管理側で拡張すれば、多層に拡張されてもよい。
管理側の第1チェーンシステムと対外の第2チェーンシステムとは、異なるコモンセンスアルゴリズムを用いてもよい。例えば、管理側の第1チェーンシステムはコモンセンス時間のより短いアルゴリズムを用いれば、クイック確認及び高頻度取引のニーズを満足することができるが、対外の第2チェーンシステムはコモンセンス時間のより長いアルゴリズムを用いる。従って、図2に示すように、2つのチェーンがそれぞれブロックデータを生成する時間は同じでなくてもよく、1つの非同期過程であってもよい。従って、対外の第2チェーンの生成は管理側の第1チェーンの生成に影響せず、それにより管理側の高並行性ニーズを満足する。第2チェーンのブロックデータは第1チェーンの1つ又は複数のブロックデータで順次組み合わせられてなり、第2チェーンが使用するデータブロックは、いずれも管理側の第1チェーンがパッケージ化した後のブロックデータであるため、第2チェーンのブロックデータの生成にも役立って、大量データのニーズを満足することができる。以上によれば、本実施例の信頼可能なシステムは第1チェーンと第2チェーンが非同期且つ準同型であり、管理側の第1チェーンシステムは第2チェーンシステムにより自体のデータ状態を検査することができ、且つ第2チェーンシステムにより第2チェーンシステムにタイムリーに同期していないもの以外のすべてのブロックデータを回復することができる。
選択肢として、第2チェーンシステムは更に拡張データを含んでもよく、拡張データは第2チェーンシステムそのもののシステム状態データであってもよく、第1チェーンシステムのシステム状態に関わらないため、第1チェーンシステム及び第2チェーンシステムの論理状態の相違に影響しない。
本実施例では、管理側の第1チェーンシステム及び対外の第2チェーンシステムにおいて異なる方式で取得されたいずれか1つのアカウントの状態は合致する。例示的に、管理側はシステム状態ツリーを生成することにより、いずれか1つのアカウントの状態を取得してもよい。前記アカウントの状態はアカウント残高、初期アドレスパラメータ、凍結又は凍結解除等の状態情報を含んでもよく、第2チェーンにおいて、取引結果を累計することで該アカウントの残高状態を把握し、制御データにおけるユーザーの暗号化情報を検索して残りの状態を取得してもよく、取引結果を累計することで把握したアカウントの状態は管理側において取得された該アカウントの状態に合致する。クライアント側のウォレットは、管理側の第1チェーンにおいて取得されたアカウントの状態が対外の第2チェーンにおいて取得された該アカウントの状態に合致するかどうかを自動的に検証してもよい。
以下、管理側の第1チェーンシステムがプライベートチェーン、対外の第2チェーンシステムがパブリックチェーンである場合を例として説明する。
管理側はシステムの管理者であり、ユーザー及び機構の新規登録、ログオフ、証明書の更新及び暗号化暗号鍵の発行等はいずれも管理側により行われ、管理側は更にアカウントの凍結、凍結解除及び闇取引を阻止する機能を有してもよく、且つシステムtokenの発行及び回収も管理側の関与を必要とする。チェーン生成機構は管理側のプライベートチェーンの生成者であり、発行機構はtokenの発行に関与し、変換機構はユーザーがローカルの導出不可能な署名暗号鍵のみを有してそれを紛失した場合に関与し、上記機構の身分はいずれも公開したものであって、秘密にしたものではない。管理側のプライベートチェーンシステムに関連付けられるものは、更に信頼可能な第三者CA(Certificate Authority、認証局)機構(又は、eID機構)又は信頼可能な第三者委託管理署名暗号鍵機構等を含んでもよい。
対外のパブリックチェーンシステムにおけるチェーン生成ノードは管理側の許可を必要とせず、対応するルールに従ってパブリックチェーンにおけるデータを検証してパブリックチェーンシステムのコモンセンス及び生成に関与してもよく、チェーンにおけるデータが公開、追跡可能、改竄不可能であるが、完全に透明なものではなく、チェーン生成ノード、第三者及び監督管理者はいずれもチェーンにおけるデータの正当性を検証することができるが、対応するユーザーID、ユーザーの関連取引及び資産情報を把握することができず、アドレスを利用してユーザーID及び関連取引をトレースしても把握できないが、第三者及び監督管理者はクライアント側又は管理側の暗号化暗号鍵の承認を取得した後、自主的にパブリックチェーンからユーザーの関連取引及び資産情報を取得することができ、ユーザー自身もパブリックチェーンから暗号化暗号鍵によって自身に関連する取引データ、資産情報及びユーザー情報を取得し、図3に示される。
本実施例に記載の信頼可能なシステムを利用するために、ユーザーはまず実名認証後に管理側のプライベートチェーンに新規登録する必要がある。新規登録後、ユーザーが取引を開始して生成した取引データは、管理側の検証に成功して裏書署名してからチェーン生成機構によりプライベートチェーンに書き込まれ、プライベートチェーンはデータをパブリックチェーンに同期するが、取引の関与者、チェーン生成ノード、第三者及び監督管理者等は、いずれもパブリックチェーンにおいて取引データをクエリ・検証し、即ちシステム全体のユーザー、第三者及び監督管理者に対する読み取り操作がいずれもパブリックチェーンにおいて行われるが、書き込み操作が管理側によりプライベートチェーンにおいて行われ、従って、本実施例のシステムは読み取り及び書き込みが分離したものである。
本明細書の実施例では、管理側のプライベートチェーンにおけるデータは、制御データセット及び取引データセット、並びにチェーン生成機構のコモンセンスアルゴリズムにより生成されたブロックヘッダーデータを含んでもよい。制御データセットは、主に管理側が第1チェーンシステムを管理・制御するために公布した情報データの集合であり、ユーザー及び機構の新規登録情報、tokenの発行及び回収、取引ルール、身分証明書及び更新情報(例えば、更新後のユーザー情報及び/又は更新後のシステムアルゴリズム暗号鍵等)等のうちの1つ又は複数を含むが、それらに限らない。効果的な監督管理のために、ユーザーの身分情報が暗号文である以外に、他の多くのデータが平文であり、これによりユーザーの身分プライバシーを保護することもできる。取引データセットは1つの時間セグメントにおけるすべての1回限りの取引の集合である。1回の取引データにはtoken額及び出力アドレスに対応するユーザー識別子が暗号文である以外に、残りのデータがいずれも平文であり、出力アドレスに対応するユーザー識別子は取引データにおいて選択可能項目である。取引のtoken額が機密取引方式で暗号化され(例えば、加算準同型承諾)、該tokenに対応する機密暗号化暗号鍵(取引アドレスに対応するクライアント側及び管理側の有する暗号鍵)が平文を復号化できる以外に、残りがいずれも平文を復号化して確認することができないが、暗号文を利用して機密取引token額の有効性を検証することができ、即ち暗号文の場合に取引のすべての入力tokenの和からすべての出力tokenの和を引いたものがゼロに等しく且つすべての項値が負数ではないかどうかを検証する。ブロックヘッダーデータは制御データセットにより生成されたマークルツリー(Merkle Tree)ルートハッシュ及び取引データセットにより生成されたMerkle Treeルートハッシュ、並びに管理側により生成された現在のシステム状態ツリーのマークル−パトリシアツリー(Merkle Patricia Tree)ルートハッシュを含み、更に前のブロックヘッダーのハッシュ値、ブロック番号、タイムスタンプ、コモンセンスパラメータ等を含み、ブロックヘッダーデータの偽造防止及び否認防止を確保するよう、更に関連署名を含む必要がある。管理側はシステムのすべての暗号化暗号鍵を有しなければシステム状態ツリーを生成できないため、該状態ツリーは管理側のみで使用され、1つの仮想状態ツリーである。
本実施例では、クライアント側の暗号鍵は署名暗号鍵及び暗号化暗号鍵の2種類に分けられる。このうち、署名暗号鍵はクライアント側によりローカルに生成して管理のために使用されるものであり、暗号鍵の安全使用を確保するよう、導出不可能なハードウェアを媒体として利用する。署名暗号鍵はCA機構によりユーザーの身分認証証明書を公布することによって、又はeIDメカニズムを用いて、ユーザーの実名身分認証を実現する。署名暗号鍵は証明書署名公開鍵及び署名秘密鍵を含む。また、選択可能な実施形態では、該システムは多重署名方式を用いてもよく、クライアント側はローカル署名暗号鍵のほか、更に信頼可能な第三者の委託管理する署名暗号鍵を用いてもよく、該暗号鍵はクライアント側が身分認証証明書又はeIDによって管理側に新規登録した後、管理側により信頼可能な第三者に申請する委託管理署名暗号鍵であり、クライアント側はFIDO(オンライン高速身分検証)方式で委託管理署名暗号鍵を用いて、クライアント側のローカル署名暗号鍵とともに多重署名アドレスを構成してもよい。選択肢として、多重署名のタイプを識別してもよく、例えばユーザーが少額で支払うことを容易にするために、ローカルの導出不可能な署名暗号鍵を用いて限度額のより高い費用を支払うが、信頼可能な第三者の委託管理する署名暗号鍵を用いて限度額のより低い費用を支払ってもよく、ユーザーアカウントの安全性を強化するように2種類の署名暗号鍵を組み合わせて用いてもよく、複数のユーザーの署名暗号鍵を用いてジョイントアカウントの多重署名アドレスを構成してもよい。選択可能な実施形態では、更にユーザーがローカルの導出不可能な署名暗号鍵を紛失した場合、委託管理暗号鍵を用いて資産を新しいアカウントに安全に移転してもよい。他の選択可能な実施形態では、クライアント側が委託管理署名暗号鍵を有せず、且つローカルの導出不可能な署名暗号鍵が紛失された場合、ユーザーの資産を損失しないよう、更に変換機構アカウントによって資産を新しいアカウントに移転してもよい。
暗号化暗号鍵はクライアント側が身分認証証明書又はeIDによって管理側に新規登録した後、管理側が各クライアント側に異なる暗号化暗号鍵を公布し、且つクライアント側のローカルウォレットにより記憶・使用される。暗号化暗号鍵は機密取引暗号鍵、秘密共有サブ暗号鍵及び対称暗号化暗号鍵を含んでもよい。機密取引暗号鍵がユーザーの取引データにおけるtoken額の関連パラメータ(例えば、盲検化因子)を暗号化/復号化することに用いられてもよく、秘密共有サブ暗号鍵が秘密共有アルゴリズムを用いて取引当事者の身分識別子等のデータを暗号化/復号化することに用いられてもよく、対称暗号化暗号鍵がクライアント側の身分情報等のデータを暗号化して記憶することに用いられてもよい。上記解釈された用途を除き、暗号化暗号鍵のうちの1つ又は複数の暗号鍵は更に取引アドレスを生成することに用いられてもよい。秘密共有アルゴリズムは選択可能なサブ暗号鍵を用いる秘密共有方式であり、且つ暗号化者(管理側)はその中のN部の秘密共有サブ暗号鍵を把握することができ、(2,N+1)の閾値秘密共有アルゴリズムを用いて生成したばかりの1つのサブ暗号鍵を暗号化結果とともに公布する場合、N部のうちのいずれか1つの秘密共有サブ暗号鍵に基づいて秘密メッセージを回復することができ、次に、秘密メッセージを暗号鍵として利用して、対称暗号化アルゴリズムを用いて、保護すべき共有データを暗号化してもよい。(2,N+1)の閾値秘密共有アルゴリズムは秘密メッセージがN+1個のシェアの共有秘密メッセージに分けられることを示し、その中のいずれか2つ又は2つ以上の共有シェアを利用して秘密メッセージを回復することができる。従って、N+1個のサブ暗号鍵は1部の生成したばかりのシャドーサブ暗号鍵を含み、1つの秘密共有サブ暗号鍵を有するクライアント側は、自体の秘密共有サブ暗号鍵及び暗号化結果とともに公布した該シャドーサブ暗号鍵に基づいて、秘密メッセージを回復することができ、更に秘密メッセージを利用して共有データを確認する。本実施例では、暗号化暗号鍵が上記3種類の暗号鍵を含むことは一実施形態に過ぎず、他の実施形態では、暗号化暗号鍵は1種類又は2種類の暗号鍵のみを含んでもよく、又は、更に4種類の暗号鍵を含んでもよく、上記機能を実現できればよい。暗号鍵の名称は上記実施例における名称を用いるものに限らず、区別できればよい。
本実施例のシステムにおいてUTXO(Unspent Transaction Outputs、未使用の取引出力)モデルを用いる。UTXOモデルにおいて、1回の取引は1つ又は複数の入力と1つ又は複数の出力とを含む。各入力は、順方向の未使用の取引出力に対する参照、及び対応するアンロックスクリプトである。順方向の未使用の取引出力に対する参照をアンロックした後、再び参照をアンロックできず、即ち二重支払いが不可能になる。そして、各出力はtoken額及びロックスクリプトを含み、ロックスクリプトを対応するアンロックスクリプトでなければアンロックできず、即ち1つの新しい未使用の取引出力を作成する。ロックスクリプトは1つの取引アドレス及びアンロック方式を含み、取引アドレスは非対称暗号鍵の公開鍵を用いて一方向の不可逆関数によって取得されたものであるが、アンロックスクリプトは取引アドレスに対応する公開鍵データ及び秘密鍵の取引データに対する署名であり、該公開鍵を用いて署名を検証してもよい。ロックスクリプトとアンロックスクリプトとは更に多重署名方式を用いてもよい。
本実施例では、管理側のプライベートチェーンシステムはシステムの状態ツリーを生成してもよく、それにより各ユーザーの現在の状態を容易に取得することができる。状態ツリーは現在のすべての制御データ及び取引データにより生成されたものであり、システムの現在の状態及び各ユーザーの現在の状態が記録される。状態ツリーにおけるユーザーの資産状態は、ユーザーのUTXO取引記録に基づいて維持するアカウント残高を含むが、対外のパブリックチェーンシステムにおけるクライアント側、第三者及び監督管理者は、ユーザーのUTXO取引記録に基づいて取引結果を累計することにより、ユーザー残高を取得してもよい。即ち、管理側はシステム状態ツリーに基づいてユーザーの現在の状態及びアカウント残高をクエリすることができるが、対外のパブリックチェーンシステムにおけるユーザーは、該ユーザーのすべての取引記録を用いなければ該ユーザーのアカウント残高を取得できない。以上によれば、クライアント側の資産状態が管理側のプライベートチェーンシステム及び対外のパブリックチェーンシステムでの使用方式は同じではないが、この2つの方式で取得されたアカウント残高は合致する。状態ツリーが管理側のプライベートチェーンのみにおいて使用されるため、管理側は状態ツリーの方式で各クライアント側の現在の状態を容易に取得することができるが、クライアント側、第三者及び監督管理者に対外パブリックチェーンからクライアント側のすべての取引記録を取得する方式を提供するために、アカウント取引チェーンを導入し、該アカウント取引チェーンの検索は容易で迅速であるだけでなく、ユーザープライバシーを保護することもできる。
以下、アカウント取引チェーンを説明する。
選択可能な実施例では、アカウント取引チェーンのデータ処理方法は図4に示されるように、以下のステップステップS1とステップS2を含む。
ステップS1、取引データを検証し、
前記取引データは取引受信側の取引アドレスと今回取引時に生成したアドレスパラメータとを含み、前記取引アドレスは前記取引受信側が前回取引を受信する際に生成したアドレスパラメータを利用して生成したものであり、前記今回取引時に生成したアドレスパラメータは前記取引受信側が次回取引を受信する取引アドレスを生成することに用いられる。
取引データがクライアント側により管理側に送信され、管理側の取引データに対する検証は主に有効性を検証し、例えばユーザー状態の有効性、アンロックスクリプトの有効性、token額の有効性及び取引アドレスが有効なアドレスであるかどうか等を検証することを含む。
ステップS2、取引データの検証に成功した後、前記取引データを裏書署名し、裏書署名後の取引データが第1チェーンのブロックデータに書き込まれる。
前記取引データは取引受信側の取引アドレスと今回取引時に生成したアドレスパラメータとを含み、前記取引アドレスは前記取引受信側が前回取引を受信する際に生成したアドレスパラメータを利用して生成したものであり、前記今回取引時に生成したアドレスパラメータは前記取引受信側が次回取引を受信する取引アドレスを生成することに用いられる。
取引データがクライアント側により管理側に送信され、管理側の取引データに対する検証は主に有効性を検証し、例えばユーザー状態の有効性、アンロックスクリプトの有効性、token額の有効性及び取引アドレスが有効なアドレスであるかどうか等を検証することを含む。
ステップS2、取引データの検証に成功した後、前記取引データを裏書署名し、裏書署名後の取引データが第1チェーンのブロックデータに書き込まれる。
管理側の裏書署名はクライアント側の提出した取引データ全体に対する署名である。
前記取引データがチェーンアップされた後、同じ取引受信側のすべての受信取引データが論理チェーン構造を形成することとなる。該論理チェーンは生成された帳簿データに暗黙的に含まれる。
選択肢として、ユーザーが新規登録するとき、管理側はユーザーのために初期アドレスパラメータ(nonce値とも称される)を生成して、受信取引アドレスを生成し、該ユーザーが取引受信側として取引するとき、該ユーザーのすべての受信取引データが1つの論理チェーンを形成することとなる。同じユーザーが管理側により取引アドレスの生成のための新しい暗号鍵を公布された後、管理側は改めて該ユーザーに1つの初期アドレスパラメータを生成して、状態ツリーに改めて生成された初期アドレスパラメータにより生成された取引アドレスを記録し、前記改めて生成された初期アドレスパラメータは公布された新しい暗号鍵に対応し又は関連する。その後、該ユーザーが取引受信側として取引するとき、該ユーザーのすべての受信取引データが1つの新しい論理チェーンを形成することとなる。以上によれば、同じ取引受信側の受信取引データが1つ又は複数の論理チェーン構造を有してもよい。各回生成したばかりの初期アドレスパラメータが暗号化して制御データに記憶されることとなり、ユーザーは、制御データにおける初期アドレスパラメータに基づいて、自主的に論理チェーンを検索してもよい。
管理側が取引データを裏書署名した後、チェーンアップすることを管理側のプライベートチェーンシステムに通知する。管理側のチェーン生成機構により前記取引データをプライベートチェーンの帳簿データに書き込み、次に生成されたブロックデータを対外パブリックチェーンのチェーン生成ノードに同期する。ブロックデータの検証に成功した後、チェーン生成ノードにより第2チェーンのコモンセンスアルゴリズムを用いて第2チェーンのブロックデータに書き込む。
選択肢として、同じ取引受信側に対する並行取引が複数あり、即ち同じ取引アドレスを含む取引データが複数ある場合、同じ取引アドレスを含む取引データは、前記チェーン構造において互いに兄弟ノードである。
取引データに含まれる前回の受信取引におけるアドレスパラメータにより生成された取引アドレス及び次回の取引アドレスを生成するためのアドレスパラメータによって、同じクライアント側の受信取引データに論理チェーン又は兄弟ノードのある論理チェーンを形成させ、これにより、クライアント側のすべての受信取引データを迅速に検索することができ、且つ送信取引データが受信取引データを参照するため、更にすべての取引データを迅速に取得することができる。同時に、該取引アドレスが一回限りのものであり、異なるユーザーにとって唯一なものであり、それによりユーザーIDのプライバシーを保護するという目的を実現することができる。
選択可能な実施例では、図5に示すように、取引データを検証する(ステップS1)前に、前記方法は更に、
アドレスパラメータを生成し、状態ツリーから前記取引受信側の取引アドレスを検索し、生成されたアドレスパラメータ及び検索された前記取引アドレスを取引送信側に送信し、前記取引送信側により前記取引アドレス及びアドレスパラメータを取引データに追加するステップS0を含み、
前記取引データを裏書署名した(ステップS2)後、前記方法は更に、
前記取引データにおける取引アドレスが前記状態ツリーにおける前記取引受信側の取引アドレスと同じであると判断した場合、前記生成されたアドレスパラメータを利用して1つの新しい取引アドレスを生成して、前記状態ツリーにおける前記取引受信側の取引アドレスを更新するステップS3を含む。
アドレスパラメータを生成し、状態ツリーから前記取引受信側の取引アドレスを検索し、生成されたアドレスパラメータ及び検索された前記取引アドレスを取引送信側に送信し、前記取引送信側により前記取引アドレス及びアドレスパラメータを取引データに追加するステップS0を含み、
前記取引データを裏書署名した(ステップS2)後、前記方法は更に、
前記取引データにおける取引アドレスが前記状態ツリーにおける前記取引受信側の取引アドレスと同じであると判断した場合、前記生成されたアドレスパラメータを利用して1つの新しい取引アドレスを生成して、前記状態ツリーにおける前記取引受信側の取引アドレスを更新するステップS3を含む。
前記取引データにおける取引アドレスが前記状態ツリーにおける前記取引受信側の取引アドレスと異なると判断した場合、該取引受信側の取引アドレスが既に更新されたことを示すため、前記状態ツリーにおける前記取引受信側の取引アドレスを更新する必要がない。
該選択可能な実施例では、状態ツリーで受信取引アドレスを記憶することにより、各回取引を受信する際の取引アドレスが新しいものであるように確保する。
選択可能な実施例では、前記アドレスパラメータは乱数であってもよく、前記生成されたアドレスパラメータを利用して1つの新しい取引アドレスを生成することは、関数を利用して前記生成されたアドレスパラメータ及び前記取引受信側の暗号鍵を1回又は複数回演算して、取引アドレスを生成することを含む。複数回演算する際に同じ又は異なる関数を用いてもよい。
上記言及した暗号化暗号鍵のうちの1つ又は複数を利用して取引アドレスを生成する以外に、管理側によりユーザーのために取引アドレスの生成のための新しい暗号鍵を発行してもよい。
選択肢として、前記取引受信側の取引アドレスは、第1関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して第1中央値を取得し、第2関数を利用して前記第1中央値及び前記取引受信側のユーザー公開鍵を演算して第1公開鍵を取得し、第3関数を利用して前記第1公開鍵を演算して取引アドレスを取得するという第1方式で生成されてもよい。
例えば、第1中央値(K)が一方向の不可逆関数(即ち、第1関数)によって前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算することで生成され、第1公開鍵は第1中央値(K)及びユーザー公開鍵を利用して楕円曲線におけるスカラー乗算(即ち、第2関数)によって取得され、更に第1公開鍵によって他の一方向の不可逆関数(即ち、第3関数)によって取引アドレスを生成する。
例えば、第1中央値(K)が一方向の不可逆関数(即ち、第1関数)によって前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算することで生成され、第1公開鍵は第1中央値(K)及びユーザー公開鍵を利用して楕円曲線におけるスカラー乗算(即ち、第2関数)によって取得され、更に第1公開鍵によって他の一方向の不可逆関数(即ち、第3関数)によって取引アドレスを生成する。
選択肢として、前記取引受信側の取引アドレスは更に多重署名アドレスであってもよく、該多重署名アドレスは、異なる関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して複数の中央値を取得し、第4関数を利用してそれぞれ各中央値及び前記取引受信側の複数のユーザー公開鍵を演算して複数の新しい公開鍵を取得し、第5関数を利用して前記複数の新しい公開鍵を演算して多重署名アドレスを取得するという第2方式で生成されてもよい。
例えば、複数の異なる一方向の不可逆関数により前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して複数の中央値(K′)を生成し、各中央値及び受信取引側の複数のユーザー公開鍵に対して楕円曲線におけるスカラー乗算(即ち、第4関数)によって複数の新しい公開鍵を取得し、更に複数の新しい公開鍵を利用して他の一方向の不可逆関数(即ち、第5関数)によって多重署名アドレスを生成する。各中央値と複数のユーザー公開鍵は1対1に対応する関係を有するため、複数の異なる一方向の不可逆関数と複数のユーザー公開鍵も1対1に対応する関係を有する。
上記一方向の不可逆関数は、例えばハッシュ関数又はハッシュ関数の組み合わせであってもよい。
上記第1方式及び第2方式における演算関数は同じであってもよい。
選択可能な実施例では、クライアント側の開始した暗号鍵更新要求を受信し、管理側が前記クライアント側に対して身分認証を行った後、新しい暗号化暗号鍵を公布し、変換取引プロセスを開始し、変換機構アカウントをイネーブルして取引を開始し、前記変換機構アカウントの署名暗号鍵により前記取引データを署名して、第1アンロックスクリプトを生成し、それにより前記クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換する。前記第1アンロックスクリプトは特別(又は特定)のアンロックスクリプトであり、変換機構により生成されたものであり、クライアント側により生成されたアンロックスクリプトと異なる。該選択可能な実施例を用いれば、ユーザーがローカル署名暗号鍵を紛失したことにより資産を損失させるという問題を解決することができる。
選択可能な実施例では、前記方法は更に、
tokenを発行するための指定された発行取引を生成し、前記指定された発行取引における入力アドレスが第1フォーマットを用いるアドレスであるステップ、
tokenを回収するための指定された回収取引を生成し、前記指定された回収取引における出力アドレスが第2フォーマットを用いるアドレスであるステップ、
tokenを報奨するための指定された報奨取引を生成し、前記指定された報奨取引における入力アドレスが第3フォーマットを用いるアドレスであるステップ、のうちの1つ又は複数を含んでもよい。
tokenを発行するための指定された発行取引を生成し、前記指定された発行取引における入力アドレスが第1フォーマットを用いるアドレスであるステップ、
tokenを回収するための指定された回収取引を生成し、前記指定された回収取引における出力アドレスが第2フォーマットを用いるアドレスであるステップ、
tokenを報奨するための指定された報奨取引を生成し、前記指定された報奨取引における入力アドレスが第3フォーマットを用いるアドレスであるステップ、のうちの1つ又は複数を含んでもよい。
上記第1フォーマットとは特別なアドレスフォーマットを指し、UTXOアドレスのコンテクスト関係を有せず、即ち入力には未使用の取引出力を参照する必要がなく、出力も入力とされることが不可能であり、予め決められたものであってもよい。同様に、第2フォーマット及び第3フォーマットも類似である。
本実施例の方法によれば、同じ取引受信側のすべての受信取引データが論理チェーン構造を形成し、且つ前記受信側のすべての送信取引がいずれも受信取引データを参照する必要があるため、関連暗号鍵を取得した後に前記受信側のすべての取引データを検索することができる。
本実施例の方法を実現する管理側装置は検証モジュール101及び署名裏書モジュール102を備えてもよく、図6に示すように、
前記検証モジュール101は、取引データを検証するように設定され、
前記裏書署名モジュール102は、前記検証モジュールが検証に成功した後、前記取引データを裏書署名し、裏書署名後の取引データが第1チェーンシステムのブロックデータに書き込まれるように設定され、
前記取引データは取引受信側の取引アドレスと今回取引時に生成したアドレスパラメータとを含み、前記取引アドレスは前記取引受信側が前回取引を受信する際に生成したアドレスパラメータを利用して生成したものであり、前記今回取引時に生成したアドレスパラメータは前記取引受信側が次回取引を受信する取引アドレスを生成することに用いられ、同じ取引受信側のすべての受信取引データに論理チェーン構造を形成させる。
前記検証モジュール101は、取引データを検証するように設定され、
前記裏書署名モジュール102は、前記検証モジュールが検証に成功した後、前記取引データを裏書署名し、裏書署名後の取引データが第1チェーンシステムのブロックデータに書き込まれるように設定され、
前記取引データは取引受信側の取引アドレスと今回取引時に生成したアドレスパラメータとを含み、前記取引アドレスは前記取引受信側が前回取引を受信する際に生成したアドレスパラメータを利用して生成したものであり、前記今回取引時に生成したアドレスパラメータは前記取引受信側が次回取引を受信する取引アドレスを生成することに用いられ、同じ取引受信側のすべての受信取引データに論理チェーン構造を形成させる。
前記チェーン構造に含まれる同じ取引アドレスの取引データは互いに兄弟ノードである。
選択可能な実施例では、該装置は更に第1アドレス生成モジュールを備えてもよく、該第1アドレス生成モジュールは、アドレスパラメータを生成し、状態ツリーから前記取引受信側の取引アドレスを検索し、生成されたアドレスパラメータ及び検索された前記取引アドレスを取引送信側に送信するように設定され、及び、前記取引データにおける取引アドレスが前記状態ツリーにおける前記取引受信側の取引アドレスと同じであると判断した場合、前記生成されたアドレスパラメータを利用して1つの新しい取引アドレスを生成して、前記状態ツリーにおける前記取引受信側の取引アドレスを更新するように設定される。
選択可能な実施例では、前記第1アドレス生成モジュールが前記生成されたアドレスパラメータを利用して1つの新しい取引アドレスを生成することは、前記第1アドレス生成モジュールが関数を利用して前記生成されたアドレスパラメータ及び前記取引受信側の暗号鍵を1回又は複数回演算して、取引アドレスを生成することを含む。
選択肢として、前記第1アドレス生成モジュールは、前記第1アドレス生成モジュールが第1関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して第1中央値を取得し、第2関数を利用して前記第1中央値及び前記取引受信側のユーザー公開鍵を演算して第1公開鍵を取得し、第3関数を利用して前記第1公開鍵を演算して取引アドレスを取得するという第1方式で、前記取引受信側の取引アドレスを生成し、又は、
前記第1アドレス生成モジュールは、前記取引受信側の取引アドレスが多重署名アドレスであり、前記第1アドレス生成モジュールが異なる関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して複数の中央値を取得し、第4関数を利用してそれぞれ各中央値及び前記取引受信側の複数のユーザー公開鍵を演算して複数の新しい公開鍵を取得し、第5関数を利用して前記複数の新しい公開鍵を演算して多重署名アドレスを取得するという第2方式で、前記取引受信側の取引アドレスを生成する。
前記第1アドレス生成モジュールは、前記取引受信側の取引アドレスが多重署名アドレスであり、前記第1アドレス生成モジュールが異なる関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して複数の中央値を取得し、第4関数を利用してそれぞれ各中央値及び前記取引受信側の複数のユーザー公開鍵を演算して複数の新しい公開鍵を取得し、第5関数を利用して前記複数の新しい公開鍵を演算して多重署名アドレスを取得するという第2方式で、前記取引受信側の取引アドレスを生成する。
選択可能な実施例では、前記第1アドレス生成モジュールは更に、ユーザーが新規登録するとき、前記ユーザーの初期アドレスパラメータを生成して、状態ツリーに前記初期アドレスパラメータにより生成された取引アドレスを記録するように設定され、及び、
前記第1アドレス生成モジュールは更に、新しい暗号鍵を公布されたユーザーのために初期アドレスパラメータを改めて生成して、状態ツリーに前記改めて生成された初期アドレスパラメータにより生成された取引アドレスを記録するように設定され、前記新しい暗号鍵は取引アドレスを生成するための暗号鍵である。
前記第1アドレス生成モジュールは更に、新しい暗号鍵を公布されたユーザーのために初期アドレスパラメータを改めて生成して、状態ツリーに前記改めて生成された初期アドレスパラメータにより生成された取引アドレスを記録するように設定され、前記新しい暗号鍵は取引アドレスを生成するための暗号鍵である。
選択可能な実施例では、前記装置は更に暗号鍵公布モジュール及び変換取引モジュールを備え、
前記暗号鍵公布モジュールは、クライアント側の開始した暗号鍵更新要求を受信し、前記クライアント側に対して身分認証を行った後、新しい暗号化暗号鍵を公布するように設定され、
前記変換取引モジュールは、変換取引プロセスを開始し、変換機構アカウントをイネーブルして取引を開始し、前記クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、前記変換機構アカウントの署名暗号鍵により前記取引データを署名して、第1アンロックスクリプトを生成するように設定される。
前記暗号鍵公布モジュールは、クライアント側の開始した暗号鍵更新要求を受信し、前記クライアント側に対して身分認証を行った後、新しい暗号化暗号鍵を公布するように設定され、
前記変換取引モジュールは、変換取引プロセスを開始し、変換機構アカウントをイネーブルして取引を開始し、前記クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、前記変換機構アカウントの署名暗号鍵により前記取引データを署名して、第1アンロックスクリプトを生成するように設定される。
選択肢として、ユーザーが新規登録を開始するとき、暗号鍵公布モジュールはクライアント側に対して身分認証を行った後、新しい暗号化暗号鍵も公布することとなる。
前記装置は更に発行取引モジュール、回収取引モジュール及び報奨取引モジュールのうちの1つ又は複数を備え、
前記発行取引モジュールは、tokenを発行するための指定された発行取引を生成するように設定され、前記指定された発行取引における入力アドレスは第1フォーマットを用いるアドレスであり、
前記回収取引モジュールは、tokenを回収するための指定された回収取引を生成するように設定され、前記指定された回収取引における出力アドレスは第2フォーマットを用いるアドレスであり、
前記報奨取引モジュールは、tokenを報奨するための指定された報奨取引を生成するように設定され、前記指定された報奨取引における入力アドレスは第3フォーマットを用いるアドレスである。
前記発行取引モジュールは、tokenを発行するための指定された発行取引を生成するように設定され、前記指定された発行取引における入力アドレスは第1フォーマットを用いるアドレスであり、
前記回収取引モジュールは、tokenを回収するための指定された回収取引を生成するように設定され、前記指定された回収取引における出力アドレスは第2フォーマットを用いるアドレスであり、
前記報奨取引モジュールは、tokenを報奨するための指定された報奨取引を生成するように設定され、前記指定された報奨取引における入力アドレスは第3フォーマットを用いるアドレスである。
上記管理側装置は更にコンピュータ装置であってもよく、プロセッサと、メモリと、メモリに記憶されてプロセッサにおいて実行されるコンピュータプログラムと、を備え、前記プロセッサは前記プログラムを実行するとき、上記実施例の一部又は全部のステップを実現することができる。
本実施例は管理側を有するブロックチェーンシステムにおいて、クライアント側の受信取引データに論理チェーン又は兄弟ノードのある論理チェーンを形成させ、それにより同じクライアント側のすべての受信取引データを迅速に検索することができ、更に該クライアント側のすべての取引データを検索すると同時に、クライアント側に一回限りの取引アドレスの特徴を有させ、ユーザーIDのプライバシーを保護するという目的を実現する。
以下の実施例はクライアント側のデータ処理方法を説明し、図7に示すように、
取引受信側が前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成するステップS11と、
対外の第2チェーンシステムから前記取引アドレスを含む取引データを検索し、前記対外の第2チェーンシステムにおけるブロックデータが第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致するステップS12と、を含む。
取引受信側が前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成するステップS11と、
対外の第2チェーンシステムから前記取引アドレスを含む取引データを検索し、前記対外の第2チェーンシステムにおけるブロックデータが第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致するステップS12と、を含む。
同じ取引受信側のすべての受信取引データが論理的なチェーン構造を形成するため、取引受信側は前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成することができ、今回の受信取引の取引アドレスに基づいて今回の取引データを迅速に検索することができる。同時に、取引アドレスが一回限りのものであるため、該取引受信側のユーザープライバシーを保護する。
選択可能な実施例では、前記方法は更に、クライアント側が前記管理側によって状態ツリーから取得されたアカウント状態と自主的に第2チェーンシステムから取得されたアカウント状態とを比較することを含む。
選択可能な実施例では、前記取引受信側が取引送信側とされる場合、前記方法は更に、前記取引送信側が取引を提出するとき、受信取引データを参照した前回の受信取引データにおけるアドレスパラメータを利用して公開鍵/秘密鍵対を生成し(該公開鍵が以上の説明における第1方式又は第2方式で生成された公開鍵であり、公開鍵が合致しなければアドレスが同じであるように確保することができない)、前記公開鍵/秘密鍵対を利用して現在の取引におけるアンロックスクリプトを生成することを含む。
本実施例の方法を実現するクライアント側装置は第2アドレス生成モジュール201、検索モジュール202及び検証モジュール203を備えてもよく、図8に示すように、
前記第2アドレス生成モジュール201は、前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成するように設定され、
前記検索モジュール202は、第2チェーンシステムから前記取引アドレスを含む取引データを検索するように設定される。
前記第2アドレス生成モジュール201は、前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成するように設定され、
前記検索モジュール202は、第2チェーンシステムから前記取引アドレスを含む取引データを検索するように設定される。
選択可能な実施形態では、上記クライアント側装置は更に、前記管理側によって状態ツリーから取得されたアカウント状態と自主的に第2チェーンシステムから取得されたアカウント状態とを比較するように設定される検証モジュールを備えてもよい。
選択可能な実施例では、前記クライアント側装置は更に署名モジュールを備えてもよく、前記署名モジュールは、前記クライアント側が取引送信側とされる場合、取引を提出するとき、受信取引データを参照した前回の受信取引データにおけるアドレスパラメータを利用して公開鍵/秘密鍵対を生成し(公開鍵が以上の説明における第1方式又は第2方式で生成された公開鍵である)、前記公開鍵/秘密鍵対を利用して現在の取引におけるアンロックスクリプトを生成するように設定される。
上記クライアント側装置は更にコンピュータ装置であってもよく、プロセッサと、メモリと、メモリに記憶されてプロセッサにおいて実行されるコンピュータプログラムと、を備え、前記プロセッサは前記プログラムを実行するとき、上記実施例の一部又は全部のステップを実現することができる。
本実施例は同じクライアント側の受信取引データチェーンに基づいて、同じクライアント側のすべての受信取引データを迅速に検索し、更に該クライアント側のすべての取引データを検索することができる。
以下の実施例は変換装置のデータ処理方法を説明し、該方法は、
変換取引を開始し、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第1アンロックスクリプトを生成し、それによりクライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換し、前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれ、前記第1チェーンのブロックデータが対外の第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致することを含む。
変換取引を開始し、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第1アンロックスクリプトを生成し、それによりクライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換し、前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれ、前記第1チェーンのブロックデータが対外の第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致することを含む。
上記変換装置の開始した変換取引は、前記変換装置をイネーブルするように管理側装置により取引プロセスを開始する必要があり、次に変換装置が開始可能になる。
上記方法を実現する変換装置は、開始モジュール及び署名モジュールを備え、
前記開始モジュールは、管理側装置のイネーブルに基づいて変換取引を開始するように設定され、
前記署名モジュールは、クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第1アンロックスクリプトを生成するように設定され、
前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれ、前記第1チェーンシステムのブロックデータが対外の第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致する。
前記開始モジュールは、管理側装置のイネーブルに基づいて変換取引を開始するように設定され、
前記署名モジュールは、クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第1アンロックスクリプトを生成するように設定され、
前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれ、前記第1チェーンシステムのブロックデータが対外の第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致する。
以下の実施例では、管理側及びクライアント側のデータ処理方法を組み合わせて説明する。
該例のシステムにおける取引アドレスは、一方向の不可逆関数によってアドレスパラメータ及びユーザー暗号鍵により計算されたK値(即ち、中央値)とクライアント側の署名公開鍵とを演算し、例えば楕円曲線におけるスカラー乗算によって1つの新しい公開鍵を取得し、該新しい公開鍵に対して他の一方向の不可逆関数によって取引アドレスを取得してもよく、該新しい公開鍵は取引アドレスに対応する公開鍵とも称される。該新しい公開鍵に対応する秘密鍵はK値とクライアント側の署名秘密鍵とを演算し、例えばガロア域の乗算によって取得されてもよい。そして、同じクライアント側の受信取引データにおける取引アドレスは、いずれも計算によって取得された異なるK値が演算に関与して取得されたものであり、一回限りのアドレスの特徴を有するため、外部は取引アドレスの関連情報によってユーザーの関連身分を追跡することができないが、ユーザーのアンロック署名を検証することができる。同様に、本実施例における取引アドレスを生成する方式は、更に多重署名のアドレス(即ち、複数の異なる公開鍵で生成されたアドレス)に適用されてもよく、上記第2方式で関連演算を行えばよい。
以下、該例におけるブロックチェーンシステムのデータ処理方法を説明し、図9に示すように、以下のステップを含む。
ステップ10、クライアント側Aは管理側にクライアント側Bとの取引要求を提出する。
本実施例は取引受信側がクライアント側Bである場合を例として説明し、取引受信側が複数あってもよい。
ステップ20、管理側はシステム状態ツリーからクライアント側Bの取引アドレスを取得してnonce値をランダムに生成して、該取引アドレス及びnonce値を今回の取引の出力アドレス及びnonce値としてクライアント側Aに送信し、
同様に、クライアント側Aが複数の受信側と取引をしようとし、即ちステップ10において複数の受信側との取引要求を提出した場合、管理側は複数の受信側に対応する取引アドレスをクライアント側Aに伝送すればよい。
同様に、クライアント側Aが複数の受信側と取引をしようとし、即ちステップ10において複数の受信側との取引要求を提出した場合、管理側は複数の受信側に対応する取引アドレスをクライアント側Aに伝送すればよい。
選択肢として、管理側は更に取引アドレスに対応するユーザー識別子(本実施例では、該取引アドレスに対応するユーザー識別子はクライアント側Bのユーザー識別子であり、他の実施例では、出力が複数ある場合、各取引アドレスは1つのユーザー識別子に対応する)を秘密共有アルゴリズムでクライアント側Aに暗号化して送信し、該秘密共有者はクライアント側A、取引アドレスに対応するクライアント側及び管理側であり、この3つの秘密共有サブ暗号鍵のみがデータを復号化でき、クライアント側Aはユーザー識別子の平文を復号化して正しいかどうかを検証して、対応する取引データに該暗号文のユーザー識別子を含ませ、これにより、暗号鍵を有する場合に出力アドレスのユーザー識別子をトレースすることができるようになる。
選択肢として、管理側は更にクライアント側Aのユーザー識別子を秘密共有アルゴリズムでクライアント側Aに暗号化して送信してもよく、該秘密共有者がクライアント側A及び管理側であり、これらの秘密共有サブ暗号鍵のみがデータを復号化でき、
nonce値及びクライアント側の暗号鍵(例えば、対称暗号化暗号鍵)が一方向の不可逆関数によって前記K値を取得し、更に前記方法に基づいてクライアント側の1つの新しい取引アドレスを取得し、該K値は取引アドレスに対応するK値と称されてもよく、該nonce値は取引アドレスに対応するnonce値と称されてもよく、管理側は、nonce値により計算された今回の取引のユーザーの新しい取引アドレスがシステムにおいて唯一であるように確保する必要があり、
ユーザーが新規登録する際に管理側は該ユーザーの初期nonce値を生成して、該ユーザーの暗号鍵(例えば、対称暗号化暗号鍵)を利用して制御データセットに暗号化して記憶して、システム状態ツリーに該nonce値により生成されたユーザー取引アドレス、即ちユーザーの1番目の受信取引アドレスを記録する。
nonce値及びクライアント側の暗号鍵(例えば、対称暗号化暗号鍵)が一方向の不可逆関数によって前記K値を取得し、更に前記方法に基づいてクライアント側の1つの新しい取引アドレスを取得し、該K値は取引アドレスに対応するK値と称されてもよく、該nonce値は取引アドレスに対応するnonce値と称されてもよく、管理側は、nonce値により計算された今回の取引のユーザーの新しい取引アドレスがシステムにおいて唯一であるように確保する必要があり、
ユーザーが新規登録する際に管理側は該ユーザーの初期nonce値を生成して、該ユーザーの暗号鍵(例えば、対称暗号化暗号鍵)を利用して制御データセットに暗号化して記憶して、システム状態ツリーに該nonce値により生成されたユーザー取引アドレス、即ちユーザーの1番目の受信取引アドレスを記録する。
ステップ30、クライアント側Aは、ローカルウォレットにおける最後の受信取引データにおけるnonce値を利用して自体のお釣り用アドレスを計算してもよく、お釣り用アドレスはクライアント側Aの受信取引アドレスであり、生成方式はステップ20における取引アドレスと同様であり、自体にお釣りを返す必要がある場合、今回の取引の出力アドレス(1つの取引の複数の出力のうちの1つ)とし、
該ステップは選択可能なステップであり、クライアント側Aはお釣りを返す必要がある場合、該ステップを実行し、お釣りを返す必要がない場合、ステップ20の後で直接ステップ40を実行する。
該ステップは選択可能なステップであり、クライアント側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値及びクライアント側の暗号鍵(例えば、対称暗号化暗号鍵)を利用して一方向の不可逆関数によって1つのK値を取得し、更に1つの対応する取引アドレスを取得し、生成方式はステップ20における取引アドレスと同様であり、該取引アドレスを利用してシステム状態ツリーにおける対応するユーザー取引アドレスを更新する。
管理側はチェーンアップすることを通知するとき、取引データにおけるユーザー取引アドレスがシステム状態ツリーにおけるユーザー取引アドレスと同じであるかどうかを検証し、同じである場合、該取引のnonce値及びクライアント側の暗号鍵(例えば、対称暗号化暗号鍵)を利用して一方向の不可逆関数によって1つのK値を取得し、更に1つの対応する取引アドレスを取得し、生成方式はステップ20における取引アドレスと同様であり、該取引アドレスを利用してシステム状態ツリーにおける対応するユーザー取引アドレスを更新する。
以上によれば、同じ受信クライアント側にとって、次の受信取引のアドレスは、該ユーザーの今回の受信取引データにおけるnonce値及び該ユーザー暗号鍵により計算されたものであるが、ユーザーの初期nonce値は新規登録時にチェーンに暗号化して記憶されるものであり、従って、ユーザーは初期nonce値を取得することにより、1番目の受信取引アドレスを計算することができ、アドレスによって受信取引データを取得して、取引データにおけるnonce値によって次の受信取引アドレスを計算することができ、更にnonce値及び取引アドレスによってユーザーの受信取引データに論理チェーンを形成させる。
そして、複数のクライアント側が該ユーザーに対して並行取引を開始するとき、管理側がシステム状態ツリーから取得した取引アドレスは同じアドレスであり、取引データを1番目に提出して成功した場合のみ、システム状態ツリーにおける取引アドレスを次のアドレスに修正し、従って、取引が同時発生した場合に同じアドレスを用いる場合があり、これらの同じアドレスの受信取引データは論理チェーンにおける兄弟ノードを形成する。
クライアント側のローカルウォレットは、該ユーザーの初期nonce値に基づいて該ユーザーのすべての受信取引データを取得することができ、且つ、UTXOモデルにおけるユーザーのすべての送信取引はいずれも対応する未使用の取引出力を入力として参照し、即ち受信取引データを参照する必要があるため、ユーザーはすべての受信取引データを検索できれば、関連取引の参照によりすべての送信取引データを検索することができ、クライアント側のローカルウォレットに該論理チェーンの関係が保存されるが、クライアント側の1つの受信取引における取引アドレスは対応する前の受信取引データにおけるnonce値により計算されたものであり、これはステップ40におけるユーザーが直接に未使用の取引出力における前の受信取引データのnonce値を検索することができることを解釈し、更に該未使用の取引をアンロックすることができる。
ステップ70、クライアント側Bがローカルウォレットの最後の受信取引データのnonce値によって取引アドレスを計算し、該取引アドレスを利用して帳簿データをクエリすれば、今回の取引データを検索することができ、該取引出力アドレスがロックスクリプトとともに1つの新しい未使用の取引出力を生成し、且つクライアント側Bのみは対応するアンロックスクリプトを生成できるが、外部は該取引アドレスとクライアント側Bとの関連を把握しない。
以上によれば、今回の取引の出力アドレスはクライアント側の前の受信取引のnonce値により計算されたものであり、従って、クライアント側のローカルウォレットが最後の受信取引データのnonce値に基づいて計算した取引アドレスを出力して、対外パブリックチェーンから該アドレスの取引データを検索し、今回の取引データがチェーンアップされ帳簿データに書き込まれた後、該アドレスによって今回の取引データを検索することができる。そして、この検索過程はいかなるメッセージ通知メカニズムに依存せず、管理側にも依存せず、クライアント側は自主的に対外パブリックチェーンから取引アドレスに基づいて検索してもよい。
クライアント側の各送信取引の入力はいずれも対応する未使用の取引出力を参照する必要があり、且つ順位関連がなく、従って、クライアント側の送信取引も並行操作を行ってもよく、リプレイアタックを防止する機能を有する。
本実施例の方法を用いれば、クライアント側、チェーン生成ノード、並びに第三者及び監督管理者等は、いずれも対外パブリックチェーン取引データにおける各回の取引の管理側の裏書署名、クライアント側のアンロック署名を検証し、暗号文で機密取引額の有効性を検証することができるが、対応するユーザー情報及び取引額を把握せず、ユーザーのアカウント取引チェーンも把握せず、これによりユーザーデータプライバシーの目的を実現する。
クライアント側のローカルウォレットは1つの軽量級のウォレットであり、対外パブリックチェーンのブロックヘッダーデータを同期すればよく、更に制御データにおける暗号化されたユーザーID情報及び暗号化された初期nonce値を取得すれば、他のユーザーに関連しないデータを同期する必要とせずに、ユーザーの関連情報及びアカウント取引チェーンを取得できる。そして、パブリックチェーンブロックヘッダーのデータ量が少なく、ユーザーは少量のデータを同期すればよく、携帯機器の記憶ニーズを完全に満足することができる。クライアント側はブロックヘッダーデータに基づいて、SPV(Simplified Payment Verification)を利用して該取引があるかどうかを検証してもよく、少量の他の取引データのハッシュ演算結果があればよい。且つ、クライアント側又は管理側は対応する暗号化暗号鍵を承認すれば、監督管理者及び第三者は対外パブリックチェーンから該ユーザーのアカウント取引チェーンを取得して、ユーザーに関連するすべての取引データを迅速に検索することができる。システムでは管理側のプライベートチェーン及び対外パブリックチェーンのチェーン生成ノードのみがすべてのブロックデータを記憶する必要があり、帳簿データの安全を確保できる場合、帳簿データの冗長記憶を大幅に軽減し、関連リソースを節約する。
選択可能な実施例では、システムは更に1つの特別な公開身分の変換機構アカウントを設定してもよい。その作用はユーザーが導出不可能なローカル署名暗号鍵を有してそれを紛失した場合、クライアント側により1つの新しい署名暗号鍵をローカルに生成して、更新された身分認証証明書又はeIDによってシステムにおいてユーザー情報を更新して、管理側により新しい暗号化暗号鍵を公布して新しい初期nonce値を生成する(アカウント取引チェーンを更新する)。しかしながら、クライアント側の新しい署名暗号鍵が前のロックスクリプトをアンロックできないため、変換機構アカウントにより1つの特別な変換取引を生成する必要がある。該変換取引は管理側により監査してユーザーの更新に成功した後、管理側のシステムにより開始される。変換取引は1回の入力及び1回の出力のみを含み、取引の入力はユーザーの元のアカウントを参照した1回の未使用の取引出力であり、取引の出力はユーザーが生成したばかりの取引アドレスであり、変換機構アカウントは該取引データを署名して、1つの特別な第1アンロックスクリプトを生成し、ユーザーの元のアカウントの1回の未使用の取引出力を1回の新しい未使用の取引出力に変換させる。このように、変換取引によってユーザーのローカル署名暗号鍵が紛失された後に資産を損失させるという問題を解決することができる。そして、変換取引は特別なアンロックスクリプトを除き、残りが一般的な取引に合致し、従って、ユーザーの身分プライバシーを保護するよう、外部は対応するユーザー情報及び取引額を把握しない。そして、特別なアンロックスクリプトに用いるのが身分を公開した変換機構アカウントの署名であるため、外部は該署名を検証することができて、該取引が変換取引であることを把握できる。変換取引も前記チェーン構造に応じて変換取引をユーザーの新しいアカウント取引チェーンにおいて行わせる。変換取引が管理側のシステムにより開始されるため、変換取引の入力及び出力が同じユーザーの取引アドレスであるかどうかを監督管理する必要があり、管理側により対応する暗号鍵を監督管理者に承認し(又はK値パラメータ、ユーザーを検証する証明書署名公開鍵とK値の演算結果が対応のアドレスを生成する)、監督管理者は対外パブリックチェーンにおいて検証してもよい。
選択可能な実施例では、システムのユーザー暗号鍵及び証明書は定期更新メカニズムを有してもよく、且つユーザーのアカウント取引チェーンを同時に更新する。従って、前のアカウント取引チェーンにおけるすべての未使用の出力は新しいアカウント取引チェーンに移転することとなる。従って、古いブロックデータにおける取引データは更新のため未使用の出力を有しなくなり、管理側はポリシーによって古いブロックデータをアーカイブ・除去してもよい。そして、クライアント側はアカウント取引チェーンを再確立したため、クライアント側のデータ量を長期間に制御可能範囲に維持できる。
上記例では、アカウント取引チェーンに関連付けられるのはユーザーのすべての受信取引であり、ユーザーのすべての送信取引を最後にすべてアカウント取引チェーンに関連付けることを可能にするために、支出額より大きい額を入力して、ステップ30では、1つの釣り出力を有させ、又は額がゼロである釣り出力を強制的に出力させる(アカウント取引チェーンを更新するとき、未使用の出力を新しいアカウント取引に移転する必要があるため、ゼロ出力をできる限り回避する)。このように、すべての送信取引はいずれも1つの釣り出力を生成して、ユーザーのアカウント取引チェーンに関連付けることとなり、それによりユーザーのすべての取引をいずれもアカウント取引チェーンに関連付ける。
クライアント側の取引データは、より短い時間(プライベートチェーンが1つのデータブロックを生成してチェーン生成ノードに同期する時間)内に対外パブリックチェーンのチェーン生成ノードに同期でき、このとき、クライアント側は受信取引アドレスによって取引情報をクエリして取引データを取得し、管理側の裏書署名、クライアント側のアンロック署名及び取引額を検証することができるが、このときの取引データはまだ対外パブリックチェーンに追加されておらず、少額取引の場合、ユーザーは取引に成功したと見なしてもよい。多額取引の場合、取引に成功するように確保するために、所定期間待ってもよく、取引データを対外パブリックチェーンに追加していくつかの確認を経て、SPVによって関連情報を検証すれば、取引があって改竄不可能で不可逆であると見なされてもよい。
本実施例のシステムにおいて、管理側、クライアント側並びに機構の署名暗号鍵及び対称暗号化暗号鍵、ひいては対応するアルゴリズムは更新可能であり、互いに依存しないため、一部のユーザーの更新に起因して利用不可能になることがない。秘密共有サブ暗号鍵及び機密取引暗号鍵は、一部のユーザーが暗号鍵を更新しても利用不可能になることもなく、秘密共有アルゴリズムを更新することはクライアント側に新旧アルゴリズムに対応する暗号鍵を同時に発行でき、次にあるブロックの高さで新しい秘密共有アルゴリズムをイネーブルし、従って、利用不可能になることもない。しかしながら、機密取引アルゴリズムを更新すると、新旧アルゴリズムのユーザーが互いに取引することができなくなり、且つアルゴリズムの更新に起因して暗号文による取引額の検証が不可能になると、システムのtoken総量が一定でなくなる。システムのtoken総量が一定であるように確保するために、機密取引アルゴリズムの更新は回収再発行ポリシーを用いてもよい。新旧機密取引アルゴリズムが交換不可能であるため、新旧アルゴリズムのtokenが等値であるが同じではないと見なされてもよく、徐々に等値の新旧tokenを発行機構に回収して再発行し、更に発行機構により新旧tokenをユーザーに回収・発行し、システムにも新旧tokenの取引が同時にあれば、システムが徐々に移行して新旧tokenの置換を完了するようにすることができ、且つ置換過程においてシステムにおける新旧tokenの総量が一定であるように確保することができる。システムのハッシュアルゴリズムもあるブロックの高さで新しいハッシュアルゴリズムをイネーブルしてもよく、新旧アドレスの置換によって、システムが徐々に移行を完了するようにすることができる。上記した一部のユーザーによる更新を用いてもよいことは、システムが何回かに分けて順次更新するメカニズムを用いてもよいことである。ユーザーのアカウント取引チェーンを更新する必要がある場合、取引アドレスを生成するための新しい暗号鍵及び新しい初期nonce値を公布して、あるブロックの高さで発効するように指定してもよい。従って、システムのパスワードアルゴリズムはすべて更新可能であり、将来では安全保障を有する抗量子計算のパスワードアルゴリズムに更新してアップグレードされてもよい。
以上の管理側のプライベートチェーンシステムはプライベートチェーンシステムに限らず、更にコンソーシアムチェーンの方式を用いてもよい。そして、対外のパブリックチェーンシステムはパブリックチェーンシステムに限らず、コンソーシアムチェーンの方式を用いてもよく、且つデータの安全性を強化することができ、以下、例を挙げて説明する。
データの安全性を確保して、量子コンピュータはユーザー暗号鍵がクラッキングされたためプライバシーが漏れるという問題を防止するために、対外のパブリックチェーンシステムは対外のコンソーシアムチェーンの方式を用いてもよい。制御データにおける平文データは対外公開されるが、ユーザーIDプライバシーに関わる暗号化データ及び暗号化初期nonce値は対外公開されていない。取引データにおける入力参照及び出力アドレスデータ並びにタイムスタンプデータは対外公開されるが、取引額及びアドレスパラメータ並びに選択可能な暗号化ユーザー識別子は対外公開されていない。対外システムのブロックヘッダーデータは対外公開されており、コンソーシアムチェーンのコモンセンス方式が決定されたものであるため、コモンセンスになると不可逆となり、すべてのクライアント側、第三者及び監督管理者はいずれも対外システムのブロックヘッダーデータを同期し、且つ迅速に相互検証を行うことができ(例えば、秘密メッセージと、初期ブロック番号から指定されたブロック番号までのブロックヘッダーデータのハッシュ値、及び指定されたブロック番号から最後のブロック番号までのブロックヘッダーデータにより生成されたハッシュ演算結果と、を比較する)、従って、ブロックヘッダーデータが信頼可能なものであると見なされる。且つ、取引データにおける未対外公開のデータ(取引額、アドレスパラメータ及び選択可能な暗号化ユーザー識別子)を、量子計算によるクラッキングを防止するハッシュ演算結果で、取引データにおける署名すべき未対外公開のデータを置換してもよく、入力参照も置換後のデータを用いる。このように、外部はUTXOの入力参照及び出力アドレスによって、取引が未使用の出力を参照したかどうか、及び二重支払いがないかどうかを検証してもよく、且つ取引の時間情報を取得でき、並びに取引データの管理側の裏書署名及びクライアント側のアンロック署名を検証することができる。クライアント側、監督管理者及びチェーン生成ノードは未公開のデータを取得して取引額の検証(暗号文の検証)を完了することができ、且つクライアント側は自体の関連取引データにおける未公開のデータしか取得できず、クライアント側は更にSPV検証によって取引データがあるかどうかを検査してもよい。そして、nonce値及び暗号化暗号鍵によって次の受信取引アドレスのパラメータK値を計算することは、量子計算によるクラッキングを防止するハッシュ演算を用いてもよく、即ち同じ取引における複数のユーザーにとって、共有情報によって他のユーザーのアカウント取引チェーンを取得できず、且つブロックヘッダーデータが信頼可能なものであるため、SPV検証によって他の取引データのハッシュ演算結果を取得する必要があるだけで、重要な情報が漏れない場合にユーザーデータを信頼可能にするという目的を実現する。量子コンピュータの出現に起因して公開されたUTXOの入力参照及び出力アドレスに対応する暗号鍵がクラッキングされても、取引額及びアドレスパラメータを公開しないため、関連する取引額を取得できず、及び関連する出力アドレスがどのユーザーの公開鍵により演算されたかを取得することができず、すべてのユーザー公開鍵がいずれも関連する可能性を有する(いずれも対応するK`値を見つけることができる)ため、ユーザーのアカウント取引チェーンも取得できなく、ユーザーの身分プライバシーを保護する。多重署名アドレスの場合、同じK値の利用によるプライバシーの漏れを回避するよう、多重署名アドレスの各公開鍵に関連するK値パラメータを生成することは、異なる方式で異なるK値を生成する必要がある。上記制御データ及び取引データにおける未対外公開のデータはMerkle Treeルートハッシュを計算するとき、量子計算によるクラッキングを防止するハッシュ演算結果に置換されてもよく、改竄を防止するように第三者もチェーンの正当性を検証してもよい。システムのパスワードアルゴリズムは更新可能で、将来では安全保障を有する抗量子計算のパスワードアルゴリズムに更新してアップグレードすることが可能であるため、システムをスムーズに移行させることができ、公開されたデータに起因して前の取引データのユーザーのプライバシーを漏らすことがない。
対外パブリックチェーンにおいて取引検証が2つのステップに分けてそれぞれ行われてもよい。第1ステップでは取引の入力参照が正しいかどうか、二重支払いがあるかどうか、ブロックヘッダーの有効性等を検証する。このステップは入力参照及び出力アドレス、並びにブロックデータのハッシュ演算結果のみを検証する必要があり、検証速度が速く、対外のコンソーシアムチェーンにおけるデータでも完全に公開されたものであるため、公開された検証サービスとされてもよい。第2ステップでは取引データの署名及び取引額を検証し、検証速度がより遅く、且つ対外のコンソーシアムチェーンの場合に取引額を検証するために未公開の一部の取引データを必要とする。取引データ同士が独立したものであるため、並行方式で検証してもよい。大量のデータによる性能のボトルネックを回避するよう、チェーン生成ノードは対応するポリシーを用いてもよい。
本実施例では、パブリックチェーンでのデータ記録がシステムルールに準拠するように励んで確保するために、管理側のプライベートチェーンがコモンセンス報奨を発行してパブリックチェーンに同期する。システムのコモンセンス報奨過程は、管理側がパブリックチェーンにおける報奨すべきチェーン生成ノードの関連情報を取得し、複数(例えば、6つ)のパブリックチェーンのブロックデータが確認された後、制御データにおいて平文で報奨を対応のアカウントに公布し、次に制御データにおける報奨の情報に基づいて取引データにおいて1つの特別な報奨取引を生成する(下記システムtokenの発行を参照する)ことを含んでもよい。以上によれば、パブリックチェーンにおけるコモンセンス報奨は以後のデータブロックにおいて管理側により公布され、且つ報奨が不可逆であり、報奨ルールが管理側により決定される。チェーン生成ノードは生成チェーンの情報に最後のアカウント取引チェーンのアドレスパラメータにより生成された受信取引アドレスを保存し、管理側は対応するコモンセンス報奨を対応のアドレスに発行することとなり、従って、該報奨取引もユーザーアカウント取引チェーンにある。
システムにおけるtoken総量の変化が管理側により制御され、管理側により制御データにおいて対応数のtokenを平文で発行し又は回収し、指定された発行機構によって1回の特別な発行又は回収取引を生成する。まず、制御データにおいて対応する発行は回収平文情報(今回発行又は回収したアドレス、取引額平文及び関連する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に関連する契約取引をクエリしてもよい。クライアント側のウォレットは委託管理契約声明情報及び2つのシステムの転送契約取引情報を取得した後、関連契約の実行状況を分析してもよい。
本例では、管理側を有する複数のブロックチェーンシステムの間に、取引当事者のクライアント側のチェーン間契約取引は、それぞれのシステムにおけるtoken総量の変化に影響を与えることがなく、両者のシステムにおける異なるユーザーtokenの転送過程である。チェーン生成ノード及び監督管理者はいずれもそれぞれのシステムにおける委託管理契約取引額の有効性を検証し、システムにおけるtokenの総量が一定であるように確保してもよい。そして、管理側を有する複数のブロックチェーンシステムの間に、管理側同士がコンソーシアムチェーンを確立した後、ユーザーデータのシステム間での転送を実現することができ、且つ監督管理都合上、転送するデータはいずれも対応するパブリックチェーンに記録されてクエリ・検証されることができる。
以上の例はUTXOモデルの取引アドレスにより形成されたアカウント取引チェーンであり、更に類似の方式でアカウント取引チェーンを形成してもよく、以下、システムがアカウント残高モデルである場合を例として説明する。システムがアカウント残高モデルである場合、入力参照アドレス及び出力アドレスの概念がないため、取引データにはユーザーアカウント識別子及び対応する取引額のみがあり、クライアント側の送信取引及び受信取引も依存関係がなく、従って、送信取引ID及び受信取引IDによって、クライアント側の取引データに1つの送信チェーン及び1つの受信チェーン又は兄弟ノードのある受信チェーンを形成させることができる。送信取引IDはクライアント側の前回の送信取引のnonce値とクライアント側の暗号化暗号鍵が一方向の不可逆関数により生成したものであり、送信取引IDはシステムにおいて唯一なものであり、受信取引IDはクライアント側の前回の受信取引のnonce値とクライアント側の暗号化暗号鍵が一方向の不可逆関数により生成したものであり、システムにおいて異なるクライアント側の受信取引IDが唯一なものであるが、並行取引があるため、同じクライアント側にある異なる受信取引は同じ受信取引IDを有する。クライアント側は管理側に新規登録するとき、管理側によりランダムな初期nonce値及び初期受信取引IDを生成して、クライアント側の対称暗号化暗号鍵を利用して暗号化して記憶する。取引時にnonce値とクライアント側の暗号化暗号鍵とは一方向の不可逆関数によって送信取引IDを生成する。nonce値が管理側によりランダムに生成され、且つ計算された次の送信取引ID及び受信取引ID(受信者にとって)がシステムにおいて唯一なものであるように確保する。そして、初期受信取引IDがユーザーの1番目の受信取引のIDであり、ユーザーの受信取引IDが状態ツリーにおけるユーザー受信取引IDに等しい場合、取引のnonce値及びユーザーの暗号化暗号鍵により生成された受信取引IDを利用して状態ツリーにおける受信取引IDを更新する。以上によれば、送信取引IDは前回の送信取引のnonce値(又は初期nonce値)に依存する必要があり、且つリプレイアタックを防止するように並行取引を行うことができず、従って、1つの送信チェーンを形成する。そして、受信取引IDが前記受信取引アドレスと類似の方式を用いるため、1つの受信チェーン又は兄弟ノードのある受信チェーンを形成する。この2つのチェーンはシステムがアカウント残高モデルである場合のアカウント取引チェーンを形成する。
当業者であれば理解できるように、以上に公開される方法における全部又は一部のステップ、システム、装置における機能モジュール/ユニットはソフトウェア、ファームウェア、ハードウェア及びそれらの適切な組み合わせとして実施されてもよい。ハードウェア実施形態では、以上の説明に言及した機能モジュール/ユニット間の区別は物理コンポーネントの区別に対応するとは限らず、例えば、1つの物理コンポーネントは複数の機能を有してもよく、又は1つの機能又はステップは1つ又は複数の物理コンポーネントが協力して実行してもよい。いくつかのコンポーネント又はすべてのコンポーネントはプロセッサ、例えばデジタルシグナルプロセッサ又はマイクロプロセッサにより実行されるソフトウェアとして実施され、又はハードウェアとして実施され、又は集積回路、例えば特定用途向け集積回路として実施されてもよい。このようなソフトウェアはコンピュータ可読媒体に配置されてもよく、コンピュータ可読媒体はコンピュータ記憶媒体(又は非一時的媒体)及び通信媒体(又は一時的媒体)を含んでもよい。当業者であれば理解できるように、コンピュータ記憶媒体の用語は情報(例えば、コンピュータ可読命令、データ構造、プログラムモジュール又は他のデータ)を記憶するためのいかなる方法又は技術において実施される揮発性及び不揮発性、取り外し可能及び固定媒体を含む。コンピュータ記憶媒体はRAM、ROM、EEPROM、フラッシュメモリ又は他のメモリ技術、CD−ROM、デジタル多用途ディスク(DVD)又は他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ又は他の磁気記憶装置、又は所望の情報を記憶するために使用することができてコンピュータによってアクセスすることが可能ないかなる他の媒体を含むが、それらに限らない。なお、当業者であれば理解できるように、通信媒体は一般的にコンピュータ可読命令、データ構造、プログラムモジュール又はキャリア又は他の伝送メカニズム等の変調データ信号における他のデータを含み、且ついかなる情報配信媒体を含んでもよい。
当業者であれば理解すべきように、本願の技術案の趣旨及び範囲を逸脱せずに、本願の実施例の技術案に対して修正や等価置換を行うことができ、これらの修正や等価置換はいずれも本願の特許請求の範囲に含まれるべきである。
Claims (25)
- データ処理方法であって、
取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれることと、
前記第1チェーンシステムのブロックデータが第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致することと、を含むデータ処理方法。 - 前記第1チェーンシステムがプライベートチェーンを含み、前記第2チェーンシステムがパブリックチェーン又はコンソーシアムチェーンを含み、又は
前記第1チェーンシステムがコンソーシアムチェーンを含み、前記第2チェーンシステムがパブリックチェーン又はコンソーシアムチェーンを含む請求項1に記載の方法。 - 前記取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれることは、
取引データの検証に成功した後、前記取引データを裏書署名し、裏書署名後の取引データが第1チェーンシステムのブロックデータに書き込まれることを含み、
前記取引データは取引受信側の取引アドレスと今回取引時に生成したアドレスパラメータとを含み、前記取引アドレスは前記取引受信側が前回取引を受信する際に生成したアドレスパラメータを利用して生成したものであり、前記今回取引時に生成したアドレスパラメータは前記取引受信側が次回取引を受信する取引アドレスを生成することに用いられ、同じ取引受信側のすべての受信取引データに論理チェーン構造を形成させる請求項1又は2に記載の方法。 - 取引データを検証する前に、前記方法は更に、アドレスパラメータを生成し、状態ツリーから前記取引受信側の取引アドレスを検索し、取引送信側が前記取引アドレス及びアドレスパラメータを取引データに追加するよう、生成されたアドレスパラメータ及び検索された前記取引アドレスを前記取引送信側に送信することを含み、
前記取引データを裏書署名した後、前記方法は更に、前記取引データにおける取引アドレスが前記状態ツリーにおける前記取引受信側の取引アドレスと同じであると判断した場合、前記生成されたアドレスパラメータを利用して新しい取引アドレスを生成して、前記状態ツリーにおける前記取引受信側の取引アドレスを更新することを含む請求項3に記載の方法。 - 前記生成されたアドレスパラメータを利用して新しい取引アドレスを生成することは、
関数を利用して前記生成されたアドレスパラメータ及び前記取引受信側の暗号鍵を1回又は複数回演算して、取引アドレスを生成することを含む請求項4に記載の方法。 - 前記取引受信側の取引アドレスは、第1関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して第1中央値を取得し、第2関数を利用して前記第1中央値及び前記取引受信側のユーザー公開鍵を演算して第1公開鍵を取得し、第3関数を利用して前記第1公開鍵を演算して取引アドレスを取得するという方式で生成され、又は
前記取引受信側の取引アドレスが多重署名アドレスであり、前記多重署名アドレスは、異なる関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して複数の中央値を取得し、第4関数を利用してそれぞれ各中央値及び前記取引受信側の複数のユーザー公開鍵を演算して複数の新しい公開鍵を取得し、第5関数を利用して前記複数の新しい公開鍵を演算して多重署名アドレスを取得するという方式で生成される請求項5に記載の方法。 - 前記方法は更に、
ユーザーが新規登録するとき、前記ユーザーの初期アドレスパラメータを生成して、状態ツリーに前記初期アドレスパラメータにより生成された取引アドレスを記録すること、又は
新しい暗号鍵を公布されたユーザーのために初期アドレスパラメータを改めて生成して、状態ツリーに前記改めて生成された初期アドレスパラメータにより生成された取引アドレスを記録し、前記新しい暗号鍵が取引アドレスの生成のための暗号鍵であることを含む請求項5に記載の方法。 - 前記方法は更に、
クライアント側の開始した暗号鍵更新要求を受信し、前記クライアント側に対して身分認証を行った後、新しい暗号化暗号鍵を公布し、変換取引プロセスを開始し、変換機構アカウントをイネーブルして取引を開始し、前記クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、前記変換機構アカウントの署名暗号鍵により前記取引データを署名して、第1アンロックスクリプトを生成することを含む請求項3に記載の方法。 - 前記方法は更に、
トークン(token)を発行するための指定された発行取引を生成し、前記指定された発行取引における入力アドレスが第1フォーマットを用いるアドレスであるステップ、
tokenを回収するための指定された回収取引を生成し、前記指定された回収取引における出力アドレスが第2フォーマットを用いるアドレスであるステップ、
tokenを報奨するための指定された報奨取引を生成し、前記指定された報奨取引における入力アドレスが第3フォーマットを用いるアドレスであるステップ、のうちの1つ又は複数を含む請求項1に記載の方法。 - データ処理方法であって、
取引受信側が前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成し、第2チェーンシステムから前記取引アドレスを含む取引データを検索することを含み、
前記第2チェーンシステムにおけるブロックデータが第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致するデータ処理方法。 - 管理側により状態ツリーから取得したアカウント状態と第2チェーンシステムから取得したアカウント状態とを比較することを更に含む請求項10に記載の方法。
- 前記取引受信側が取引送信側とされる場合、前記方法は更に、
前記取引送信側が取引を提出するとき、受信取引データを参照した前回の受信取引データにおけるアドレスパラメータを利用して公開鍵/秘密鍵対を生成し、前記公開鍵/秘密鍵対を利用して現在の取引におけるアンロックスクリプトを生成することを含む請求項10に記載の方法。 - データ処理方法であって、
変換取引を開始し、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第1アンロックスクリプトを生成し、それによりクライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換し、前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれ、前記第1チェーンシステムのブロックデータが第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致することを含むデータ処理方法。 - 管理側装置であって、検証モジュールと裏書署名モジュールを備え、
前記検証モジュールは、取引データを検証するように設定され、
前記裏書署名モジュールは、前記検証モジュールが取引データの検証に成功した後、前記取引データを裏書署名し、裏書署名後の取引データが第1チェーンシステムのブロックデータに書き込まれるように設定され、
前記取引データは取引受信側の取引アドレスと今回取引時に生成したアドレスパラメータとを含み、前記取引アドレスは前記取引受信側が前回取引を受信する際に生成したアドレスパラメータを利用して生成したものであり、前記今回取引時に生成したアドレスパラメータは前記取引受信側が次回取引を受信する取引アドレスを生成することに用いられ、同じ取引受信側のすべての受信取引データに論理チェーン構造を形成させる管理側装置。 - 前記装置は第1アドレス生成モジュールを更に備え、前記第1アドレス生成モジュールは、アドレスパラメータを生成し、状態ツリーから前記取引受信側の取引アドレスを検索し、生成されたアドレスパラメータ及び検索された前記取引アドレスを取引送信側に送信するように設定され、及び、前記取引データにおける取引アドレスが前記状態ツリーにおける前記取引受信側の取引アドレスと同じであると判断した場合、前記生成されたアドレスパラメータを利用して新しい取引アドレスを生成して、前記状態ツリーにおける前記取引受信側の取引アドレスを更新するように設定される請求項14に記載の管理側装置。
- 前記第1アドレス生成モジュールが前記生成されたアドレスパラメータを利用して新しい取引アドレスを生成することは、前記第1アドレス生成モジュールが関数を利用して前記生成されたアドレスパラメータ及び前記取引受信側の暗号鍵を1回又は複数回演算して、取引アドレスを生成することを含む請求項15に記載の管理側装置。
- 前記第1アドレス生成モジュールは、前記第1アドレス生成モジュールが第1関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して第1中央値を取得し、第2関数を利用して前記第1中央値及び前記取引受信側のユーザー公開鍵を演算して第1公開鍵を取得し、第3関数を利用して前記第1公開鍵を演算して取引アドレスを取得するという方式で、前記取引受信側の取引アドレスを生成し、又は
前記第1アドレス生成モジュールは、前記取引受信側の取引アドレスが多重署名アドレスであり、前記第1アドレス生成モジュールが異なる関数を利用して前記アドレスパラメータ及び前記取引受信側のユーザー暗号鍵を演算して複数の中央値を取得し、第4関数を利用してそれぞれ各中央値及び前記取引受信側の複数のユーザー公開鍵を演算して複数の新しい公開鍵を取得し、第5関数を利用して前記複数の新しい公開鍵を演算して多重署名アドレスを取得するという方式で、前記取引受信側の取引アドレスを生成する請求項16に記載の管理側装置。 - 前記第1アドレス生成モジュールは更に、ユーザーが新規登録するとき、前記ユーザーの初期アドレスパラメータを生成して、状態ツリーに前記初期アドレスパラメータにより生成された取引アドレスを記録するように設定され、及び、
前記第1アドレス生成モジュールは更に、新しい暗号鍵を公布されたユーザーのために初期アドレスパラメータを改めて生成して、状態ツリーに前記改めて生成された初期アドレスパラメータにより生成された取引アドレスを記録するように設定され、前記新しい暗号鍵は取引アドレスを生成するための暗号鍵である請求項16に記載の管理側装置。 - 前記装置は暗号鍵公布モジュールと変換取引モジュールを更に備え、
前記暗号鍵公布モジュールは、クライアント側の開始した暗号鍵更新要求を受信し、前記クライアント側に対して身分認証を行った後、新しい暗号化暗号鍵を公布するように設定され、
前記変換取引モジュールは、変換取引プロセスを開始し、変換機構アカウントをイネーブルして取引を開始し、前記クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、前記変換機構アカウントの署名暗号鍵により前記取引データを署名して、第1アンロックスクリプトを生成するように設定される請求項14に記載の管理側装置。 - 前記装置は発行取引モジュール、回収取引モジュール及び報奨取引モジュールのうちの1つ又は複数を更に備え、
前記発行取引モジュールは、tokenを発行するための指定された発行取引を生成するように設定され、前記指定された発行取引における入力アドレスは第1フォーマットを用いるアドレスであり、
前記回収取引モジュールは、tokenを回収するための指定された回収取引を生成するように設定され、前記指定された回収取引における出力アドレスは第2フォーマットを用いるアドレスであり、
前記報奨取引モジュールは、tokenを報奨するための指定された報奨取引を生成するように設定され、前記指定された報奨取引における入力アドレスは第3フォーマットを用いるアドレスである請求項14に記載の管理側装置。 - クライアント側装置であって、第2アドレス生成モジュールと検索モジュールを備え、
前記第2アドレス生成モジュールは、前回の受信取引データにおけるアドレスパラメータに基づいて今回の受信取引の取引アドレスを生成するように設定され、
前記検索モジュールは、第2チェーンシステムから前記取引アドレスを含む取引データを検索するように設定されるクライアント側装置。 - 前記クライアント側装置は、管理側により状態ツリーから取得したアカウント状態と第2チェーンシステムから取得したアカウント状態とを比較するように設定される検証モジュールを更に備える請求項21に記載のクライアント側装置。
- 前記クライアント側装置は署名モジュールを更に備え、前記署名モジュールは、前記クライアント側が取引送信側とされる場合、取引を提出するとき、受信取引データを参照した前回の受信取引データにおけるアドレスパラメータを利用して公開鍵/秘密鍵対を生成し、前記公開鍵/秘密鍵対を利用して現在の取引におけるアンロックスクリプトを生成するように設定される請求項21に記載のクライアント側装置。
- 変換装置であって、開始モジュールと署名モジュールを備え、
前記開始モジュールは、管理側装置のイネーブルに基づいて変換取引を開始するように設定され、
前記署名モジュールは、クライアント側の元のアカウントにおける未使用の取引出力を新しい未使用の取引出力に変換するよう、変換機構アカウントの署名暗号鍵を利用して前記取引データを署名し、第1アンロックスクリプトを生成するように設定され、
前記変換機構アカウントの開始した取引により形成された取引データが検証に成功して裏書署名してから第1チェーンシステムのブロックデータに書き込まれ、前記第1チェーンシステムのブロックデータが第2チェーンシステムのブロックデータに書き込まれ、前記第2チェーンシステムのブロックデータが前記第1チェーンシステムの1つ又は複数のブロックデータで順次構成され、前記第1チェーンシステムにおけるいずれか1つのアカウントの状態が前記第2チェーンシステムにおける前記アカウントの状態に合致する変換装置。 - コンピュータ可読記憶媒体であって、コンピュータ命令が記憶され、該命令がプロセッサにより実行されるとき、請求項1〜9のいずれか1項又は請求項10〜12のいずれか1項又は請求項13に記載の方法のステップを実現するコンピュータ可読記憶媒体。
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 (31)
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 |
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 |
CN114461623A (zh) * | 2022-01-27 | 2022-05-10 | 东南大学 | 一种许可链上授权的非交易有害数据完全擦除方法 |
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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017204070A (ja) * | 2016-05-10 | 2017-11-16 | 日本電信電話株式会社 | 決済システム、決済方法、トランザクション生成装置及びトランザクション生成プログラム |
Family Cites Families (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP3955181A1 (en) * | 2015-04-20 | 2022-02-16 | OGY Docs Inc. | A method of distributed management of electronic documents of title (edt) and system thereof |
CN107786339A (zh) * | 2016-08-31 | 2018-03-09 | 陈新 | 分层可控联盟区块链系统 |
CN106372941B (zh) * | 2016-08-31 | 2019-07-16 | 江苏通付盾科技有限公司 | 基于区块链的ca认证管理方法、装置及系统 |
KR101837166B1 (ko) * | 2016-10-26 | 2018-03-09 | 주식회사 코인플러그 | 블록체인 내의 블록별로 발란스 데이터베이스를 관리하여 통화를 발행 및 지급 결제하는 방법과 이를 이용한 서버 |
CN107733855B (zh) * | 2017-08-31 | 2019-11-05 | 中国科学院信息工程研究所 | 一种可同时支持公有链、联盟链及私有链的区块链系统及应用方法 |
CN108647964B (zh) * | 2018-05-02 | 2023-07-28 | 郑杰骞 | 一种区块链数据处理方法、装置及计算机可读存储介质 |
CN108416578A (zh) * | 2018-03-14 | 2018-08-17 | 郑杰骞 | 一种区块链系统及数据处理方法 |
-
2019
- 2019-02-01 US US16/965,788 patent/US20210042744A1/en not_active Abandoned
- 2019-02-01 BR BR112020016151-9A patent/BR112020016151A2/pt not_active IP Right Cessation
- 2019-02-01 JP JP2020562824A patent/JP2021512569A/ja active Pending
- 2019-02-01 EP EP19766756.1A patent/EP3731162A1/en not_active Withdrawn
- 2019-02-01 AU AU2019232978A patent/AU2019232978A1/en not_active Abandoned
- 2019-02-01 SG SG11202006981QA patent/SG11202006981QA/en unknown
- 2019-02-01 KR KR1020207022809A patent/KR20200108024A/ko not_active Application Discontinuation
- 2019-02-01 CA CA3088712A patent/CA3088712A1/en not_active Abandoned
- 2019-02-01 WO PCT/CN2019/074440 patent/WO2019174430A1/zh unknown
Patent Citations (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2017204070A (ja) * | 2016-05-10 | 2017-11-16 | 日本電信電話株式会社 | 決済システム、決済方法、トランザクション生成装置及びトランザクション生成プログラム |
Non-Patent Citations (3)
Title |
---|
東角 芳樹 ほか: "コンソーシアムチェーンにおける証明書管理に関する一考察", 2017年 暗号と情報セキュリティシンポジウム(SCIS2017)予稿集 [USB], vol. 1F2−3, JPN6018017174, 24 January 2017 (2017-01-24), JP, pages 1 - 4, ISSN: 0004755512 * |
淵田 康之: "特集:イノベーションと金融 ブロックチェーンと金融取引の革新", 野村資本市場クォータリー, vol. 第19巻第2号(通巻74号), JPN6016047552, 1 November 2015 (2015-11-01), JP, pages 11 - 35, ISSN: 0004755513 * |
石黒 尚久 ほか, 最新ブロックチェーンがよ〜くわかる本, vol. 第1版, JPN6021037405, 1 August 2017 (2017-08-01), JP, pages 99 - 107, ISSN: 0004755514 * |
Also Published As
Publication number | Publication date |
---|---|
EP3731162A1 (en) | 2020-10-28 |
KR20200108024A (ko) | 2020-09-16 |
US20210042744A1 (en) | 2021-02-11 |
WO2019174430A1 (zh) | 2019-09-19 |
CA3088712A1 (en) | 2019-09-19 |
AU2019232978A1 (en) | 2020-08-13 |
BR112020016151A2 (pt) | 2020-12-08 |
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) | 去中心化存储安全实现方法 | |
US11422981B2 (en) | Information management and access control in a database | |
WO2021120253A1 (zh) | 链式结构数据存储、验证、实现方法、系统、装置及介质 | |
CN108647964B (zh) | 一种区块链数据处理方法、装置及计算机可读存储介质 | |
CN110288480B (zh) | 一种区块链的私密交易方法及装置 | |
CN115210741B (zh) | 部分有序的区块链 | |
US11323269B2 (en) | Preserving privacy of linked cross-network transactions | |
US11580240B2 (en) | Protecting sensitive data | |
CN114172735A (zh) | 基于智能合约的双链混合式区块链数据共享方法及系统 | |
El Defrawy et al. | Founding digital currency on secure computation | |
US11924348B2 (en) | Honest behavior enforcement via blockchain | |
JP2024509666A (ja) | ブロックチェーンデータセグリゲーション | |
Kokoris-Kogias et al. | Verifiable management of private data under byzantine failures | |
US20220393858A1 (en) | Limiting data availability on distributed ledger | |
JP2023551458A (ja) | Oprfを介したブロックチェーンネットワークにおける鍵再生 | |
US11632237B2 (en) | Configuration override in a blockchain network | |
Zhang et al. | Data security in cloud storage | |
Dumas et al. | LocalPKI: An interoperable and IoT friendly PKI | |
CN116361823A (zh) | 用于隐私保护的区块链的选择性审计处理 |
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 |