知財求人 - 知財ポータルサイト「IP Force」
▶ リョダン、システムズ、アクチエンゲゼルシャフトの特許一覧
特開2024-164832ブロックチェーン用のＺＫロールアップ・ネットワークのためのトランザクション方法
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024164832
(43)【公開日】2024-11-27
(54)【発明の名称】ブロックチェーン用のＺＫロールアップ・ネットワークのためのトランザクション方法
(51)【国際特許分類】
G06Q 20/22 20120101AFI20241120BHJP
【ＦＩ】
G06Q20/22
【審査請求】未請求
【請求項の数】10
【出願形態】ＯＬ
【外国語出願】
(21)【出願番号】P 2024078744
(22)【出願日】2024-05-14
(31)【優先権主張番号】23173367
(32)【優先日】2023-05-15
(33)【優先権主張国・地域又は機関】EP
(71)【出願人】
【識別番号】524182352
【氏名又は名称】リョダン、システムズ、アクチエンゲゼルシャフト
【氏名又は名称原語表記】Ｒｙｏｄａｎ Ｓｙｓｔｅｍｓ ＡＧ
(74)【代理人】
【識別番号】100120031
【弁理士】
【氏名又は名称】宮嶋 学
(74)【代理人】
【識別番号】100107582
【弁理士】
【氏名又は名称】関根 毅
(74)【代理人】
【識別番号】100213654
【弁理士】
【氏名又は名称】成瀬 晃樹
(72)【発明者】
【氏名】エリック、リーバッケン
【テーマコード（参考）】
5L020
【Ｆターム（参考）】
5L020AA51
(57)【要約】 （修正有）
【課題】ブロックチェーン用のＺＫロールアップ・ネットワークのためのコンピュータ実行トランザクション方法を提供する。
【解決手段】トランザクション・ルールが、ブロックチェーンに展開されたＺＫ（ｚｅｒｏ ｋｎｏｗｌｅｄｇｅ）ロールアップ・スマート・コントラクト３によって規定され、ＺＫロールアップ・ネットワークが、そのうちの少なくとも１つがアグリゲータＺＫロールアップ・ノード５であるいくつかのユーザＺＫロールアップ・ノード４を含み、ＺＫロールアップ・スマート・コントラクト３によって、アグリゲータ引出しトランザクションを受け取り、１つまたは複数のブロックチェーン・アドレスへの資金の引出しを処理する。
【選択図】図５Ｄ
【解決手段】トランザクション・ルールが、ブロックチェーンに展開されたＺＫ（ｚｅｒｏ ｋｎｏｗｌｅｄｇｅ）ロールアップ・スマート・コントラクト３によって規定され、ＺＫロールアップ・ネットワークが、そのうちの少なくとも１つがアグリゲータＺＫロールアップ・ノード５であるいくつかのユーザＺＫロールアップ・ノード４を含み、ＺＫロールアップ・スマート・コントラクト３によって、アグリゲータ引出しトランザクションを受け取り、１つまたは複数のブロックチェーン・アドレスへの資金の引出しを処理する。
【選択図】図５Ｄ
【特許請求の範囲】
【請求項1】
ブロックチェーン用のＺＫロールアップ・ネットワークのためのトランザクション方法であって、トランザクション・ルールが、前記ブロックチェーンに展開されたＺＫロールアップ・スマート・コントラクト（３）によって規定され、前記ＺＫロールアップ・ネットワークが、そのうちの少なくとも１つがアグリゲータＺＫロールアップ・ノード（５）であるいくつかのユーザＺＫロールアップ・ノード（４）を含み、前記ＺＫロールアップ・スマート・コントラクト（３）によって、
ａ）前記少なくとも１つのアグリゲータＺＫロールアップ・ノード（５）のアグリゲータＺＫロールアップ・ノードＡ（５）から、アグリゲータ振替トランザクション（５１）を受け取ることであって、前記アグリゲータ振替トランザクション（５１）が、前記アグリゲータＺＫロールアップ・ノードＡ（５）において生成され、
ｉ．少なくとも１つのユーザ振替命令（４３）についてのマークル木（５２）のマークル・ルート（５３）であって、前記少なくとも１つのユーザ振替命令（４３）のそれぞれが、前記いくつかのユーザＺＫロールアップ・ノード（４）のうちの１つにおいて生成され、前記アグリゲータＺＫロールアップ・ノードＡ（５）に振り替えられる、マークル・ルート（５３）、
ｉｉ．前記マークル・ルート（５３）の少なくとも１つのユーザ署名（４４、４４’）から構築された集約済み署名（５４）であって、前記マークル・ルート（５３）の前記少なくとも１つのユーザ署名（４４、４４’）のそれぞれが、ユーザＺＫロールアップ・アカウントに対応し、前記アグリゲータＺＫロールアップ・ノードＡ（５）から前記ユーザＺＫロールアップ・ノード（４）において生成された前記ユーザ振替命令（４３）の包含の証明と一緒に前記マークル・ルート（５３）を前記いくつかのユーザＺＫロールアップ・ノードが受け取った後、前記いくつかのユーザＺＫロールアップ・ノード（４）のうちの１つから、前記アグリゲータＺＫロールアップ・ノードＡ（５）に振り替えられる、集約済み署名（５４）、および
ｉｉｉ．前記集約済み署名（５４）が構築される元である前記マークル・ルート（５３）の前記少なくとも１つのユーザ署名（４４、４４’）のいずれかに対応するあらゆるユーザＺＫロールアップ・アカウントのリスト（５５）
を含む、こと、
ｂ）前記アグリゲータ振替トランザクション（５１）が正式に有効であることを検証すること、ならびに
ｃ）前のステップでの前記検証が成功だった場合、さらなる検証を行わず、前記アグリゲータ振替トランザクション（５１）の内容から、および直前の履歴ルート・ハッシュ（３１’）から履歴ルート・ハッシュ（３１）を計算し、事前定義済み条件が満たされるまで、前記計算された履歴ルート・ハッシュ（３１）をＺＫロールアップ・コントラクト・ステート（３２）に格納すること
によって、ユーザ振替を処理することと、
ａ）前記少なくとも１つのアグリゲータＺＫロールアップ・ノード（５）のアグリゲータＺＫロールアップ・ノードＢ（５）から、アグリゲータ引出しトランザクションを受け取ることであって、前記アグリゲータ引出しトランザクションが、前記アグリゲータＺＫロールアップ・ノードＢ（５）において生成され、
ｉ．１つまたは複数のブロックチェーン・アドレス、
ｉｉ．履歴ルート・ハッシュＭ（３１）、
ｉｉｉ．履歴ルート・ハッシュＭ（３１）における前記１つまたは複数のブロックチェーン・アドレスのそれぞれによって受け取られた総額とされる金額、
ｉｖ．受け取られた各総額とされる金額の正しさについての１つまたは複数の再帰的ＺＫ証明（４６）
を含む、こと、
ｂ）
ｉ．前記アグリゲータ引出しトランザクションが正式に有効であること、
ｉｉ．前記履歴ルート・ハッシュＭ（３１）が前記ＺＫロールアップ・コントラクト・ステート（３２）に格納されること、および
ｉｉｉ．受け取られた各総額とされる金額の正しさについての前記１つまたは複数の再帰的ＺＫ証明（４６）のそれぞれ
を検証すること、
ｃ）前のステップでの前記検証が成功だった場合、
ｉ．履歴ルート・ハッシュＭ（３１）における前記１つまたは複数のブロックチェーン・アドレスのそれぞれによって受け取られた前記総額とされる金額に応じて、および前記１つまたは複数のブロックチェーン・アドレスのそれぞれに既に引き出された総額に応じて、資金を振り替えること、
ｉｉ．ステップｉにおいて前記１つまたは複数のブロックチェーン・アドレス毎に処理された前記金額に応じて、前記１つまたは複数のブロックチェーン・アドレスのそれぞれに既に引き出された総額のリストをアップデートすることであって、前記１つまたは複数のブロックチェーン・アドレスのそれぞれに引き出された総額の前記リストが、前記ＺＫロールアップ・コントラクト・ステート（３２）に格納される、こと
によって、１つまたは複数のブロックチェーン・アドレスへの資金の引出しを処理することと
を行うステップを含む、トランザクション方法。
ａ）前記少なくとも１つのアグリゲータＺＫロールアップ・ノード（５）のアグリゲータＺＫロールアップ・ノードＡ（５）から、アグリゲータ振替トランザクション（５１）を受け取ることであって、前記アグリゲータ振替トランザクション（５１）が、前記アグリゲータＺＫロールアップ・ノードＡ（５）において生成され、
ｉ．少なくとも１つのユーザ振替命令（４３）についてのマークル木（５２）のマークル・ルート（５３）であって、前記少なくとも１つのユーザ振替命令（４３）のそれぞれが、前記いくつかのユーザＺＫロールアップ・ノード（４）のうちの１つにおいて生成され、前記アグリゲータＺＫロールアップ・ノードＡ（５）に振り替えられる、マークル・ルート（５３）、
ｉｉ．前記マークル・ルート（５３）の少なくとも１つのユーザ署名（４４、４４’）から構築された集約済み署名（５４）であって、前記マークル・ルート（５３）の前記少なくとも１つのユーザ署名（４４、４４’）のそれぞれが、ユーザＺＫロールアップ・アカウントに対応し、前記アグリゲータＺＫロールアップ・ノードＡ（５）から前記ユーザＺＫロールアップ・ノード（４）において生成された前記ユーザ振替命令（４３）の包含の証明と一緒に前記マークル・ルート（５３）を前記いくつかのユーザＺＫロールアップ・ノードが受け取った後、前記いくつかのユーザＺＫロールアップ・ノード（４）のうちの１つから、前記アグリゲータＺＫロールアップ・ノードＡ（５）に振り替えられる、集約済み署名（５４）、および
ｉｉｉ．前記集約済み署名（５４）が構築される元である前記マークル・ルート（５３）の前記少なくとも１つのユーザ署名（４４、４４’）のいずれかに対応するあらゆるユーザＺＫロールアップ・アカウントのリスト（５５）
を含む、こと、
ｂ）前記アグリゲータ振替トランザクション（５１）が正式に有効であることを検証すること、ならびに
ｃ）前のステップでの前記検証が成功だった場合、さらなる検証を行わず、前記アグリゲータ振替トランザクション（５１）の内容から、および直前の履歴ルート・ハッシュ（３１’）から履歴ルート・ハッシュ（３１）を計算し、事前定義済み条件が満たされるまで、前記計算された履歴ルート・ハッシュ（３１）をＺＫロールアップ・コントラクト・ステート（３２）に格納すること
によって、ユーザ振替を処理することと、
ａ）前記少なくとも１つのアグリゲータＺＫロールアップ・ノード（５）のアグリゲータＺＫロールアップ・ノードＢ（５）から、アグリゲータ引出しトランザクションを受け取ることであって、前記アグリゲータ引出しトランザクションが、前記アグリゲータＺＫロールアップ・ノードＢ（５）において生成され、
ｉ．１つまたは複数のブロックチェーン・アドレス、
ｉｉ．履歴ルート・ハッシュＭ（３１）、
ｉｉｉ．履歴ルート・ハッシュＭ（３１）における前記１つまたは複数のブロックチェーン・アドレスのそれぞれによって受け取られた総額とされる金額、
ｉｖ．受け取られた各総額とされる金額の正しさについての１つまたは複数の再帰的ＺＫ証明（４６）
を含む、こと、
ｂ）
ｉ．前記アグリゲータ引出しトランザクションが正式に有効であること、
ｉｉ．前記履歴ルート・ハッシュＭ（３１）が前記ＺＫロールアップ・コントラクト・ステート（３２）に格納されること、および
ｉｉｉ．受け取られた各総額とされる金額の正しさについての前記１つまたは複数の再帰的ＺＫ証明（４６）のそれぞれ
を検証すること、
ｃ）前のステップでの前記検証が成功だった場合、
ｉ．履歴ルート・ハッシュＭ（３１）における前記１つまたは複数のブロックチェーン・アドレスのそれぞれによって受け取られた前記総額とされる金額に応じて、および前記１つまたは複数のブロックチェーン・アドレスのそれぞれに既に引き出された総額に応じて、資金を振り替えること、
ｉｉ．ステップｉにおいて前記１つまたは複数のブロックチェーン・アドレス毎に処理された前記金額に応じて、前記１つまたは複数のブロックチェーン・アドレスのそれぞれに既に引き出された総額のリストをアップデートすることであって、前記１つまたは複数のブロックチェーン・アドレスのそれぞれに引き出された総額の前記リストが、前記ＺＫロールアップ・コントラクト・ステート（３２）に格納される、こと
によって、１つまたは複数のブロックチェーン・アドレスへの資金の引出しを処理することと
を行うステップを含む、トランザクション方法。
【請求項2】
前記方法が、前記ＺＫロールアップ・スマート・コントラクト（３）によって、
ａ）前記いくつかのユーザＺＫロールアップ・ノード（４）のうちの１つからユーザ登録トランザクションを受け取ることであって、前記ユーザ登録トランザクションが、前記ユーザＺＫロールアップ・アカウントのユーザ識別子および前記ユーザ識別子のユーザ署名を含む、こと、
ｂ）前記ユーザ識別子の前記ユーザ署名を検証すること、ならびに
ｃ）前のステップでの前記検証が成功だった場合、
ｉ．前記ユーザ登録トランザクションの内容および前記直前の履歴ルート・ハッシュ（３１’）から履歴ルート・ハッシュ（３１）を計算し、前記事前定義済み条件が満たされるまで、前記計算された履歴ルート・ハッシュ（３１）を前記ＺＫロールアップ・コントラクト・ステート（３２）に格納すること、ならびに
ｉｉ．ＺＫロールアップ・アドレスを前記ユーザＺＫロールアップ・アカウントに割り当てること
によって、ユーザＺＫロールアップ・アカウントの登録を処理すること
を行う追加のステップを含む、請求項１に記載のトランザクション方法。
ａ）前記いくつかのユーザＺＫロールアップ・ノード（４）のうちの１つからユーザ登録トランザクションを受け取ることであって、前記ユーザ登録トランザクションが、前記ユーザＺＫロールアップ・アカウントのユーザ識別子および前記ユーザ識別子のユーザ署名を含む、こと、
ｂ）前記ユーザ識別子の前記ユーザ署名を検証すること、ならびに
ｃ）前のステップでの前記検証が成功だった場合、
ｉ．前記ユーザ登録トランザクションの内容および前記直前の履歴ルート・ハッシュ（３１’）から履歴ルート・ハッシュ（３１）を計算し、前記事前定義済み条件が満たされるまで、前記計算された履歴ルート・ハッシュ（３１）を前記ＺＫロールアップ・コントラクト・ステート（３２）に格納すること、ならびに
ｉｉ．ＺＫロールアップ・アドレスを前記ユーザＺＫロールアップ・アカウントに割り当てること
によって、ユーザＺＫロールアップ・アカウントの登録を処理すること
を行う追加のステップを含む、請求項１に記載のトランザクション方法。
【請求項3】
ユーザ署名（４４、４４’）および／または集約済み署名（５４）がＢＬＳ署名である、請求項１から２の一項に記載のトランザクション方法。
【請求項4】
前記方法が、前記ＺＫロールアップ・スマート・コントラクト（３）によって、
ａ）前記いくつかのユーザＺＫロールアップ・ノード（４）のうちの１つから、ユーザ・トークン預金トランザクション（７）と一緒にトークンのセットを受け取ることであって、前記ユーザ・トークン預金トランザクション（７）が、前記ユーザＺＫロールアップ・ノード（４）において生成され、
ｉ．少なくとも１つのトークンＩＤ、
ｉｉ．前記少なくとも１つのトークンＩＤ毎のトークンの量、および
ｉｉｉ．トークンの前記量を受け取るためのＺＫロールアップ・アドレス
を含む、こと、
ｂ）
ｉ．前記ユーザ・トークン預金トランザクション（７）が正式に有効であること、および
ｉｉ．前記少なくとも１つのトークンＩＤ毎に、受け取られたトークンの前記セットが、前記トークンＩＤのトークンの前記量によって指示されたものと同じ数の、前記トークンＩＤに対応するトークンを含むこと
を検証すること、
ｃ）前のステップでの前記検証が成功だった場合、
ｉ．前記ユーザ・トークン預金トランザクション（７）の内容および前記直前の履歴ルート・ハッシュ（３１’）から履歴ルート・ハッシュ（３１）を計算し、前記事前定義済み条件が満たされるまで、前記計算された履歴ルート・ハッシュ（３１）を前記ＺＫロールアップ・コントラクト・ステート（３２）に格納すること
によって、ユーザ・トークン預金を処理すること
を行う追加のステップを含む、請求項１から３の一項に記載のトランザクション方法。
ａ）前記いくつかのユーザＺＫロールアップ・ノード（４）のうちの１つから、ユーザ・トークン預金トランザクション（７）と一緒にトークンのセットを受け取ることであって、前記ユーザ・トークン預金トランザクション（７）が、前記ユーザＺＫロールアップ・ノード（４）において生成され、
ｉ．少なくとも１つのトークンＩＤ、
ｉｉ．前記少なくとも１つのトークンＩＤ毎のトークンの量、および
ｉｉｉ．トークンの前記量を受け取るためのＺＫロールアップ・アドレス
を含む、こと、
ｂ）
ｉ．前記ユーザ・トークン預金トランザクション（７）が正式に有効であること、および
ｉｉ．前記少なくとも１つのトークンＩＤ毎に、受け取られたトークンの前記セットが、前記トークンＩＤのトークンの前記量によって指示されたものと同じ数の、前記トークンＩＤに対応するトークンを含むこと
を検証すること、
ｃ）前のステップでの前記検証が成功だった場合、
ｉ．前記ユーザ・トークン預金トランザクション（７）の内容および前記直前の履歴ルート・ハッシュ（３１’）から履歴ルート・ハッシュ（３１）を計算し、前記事前定義済み条件が満たされるまで、前記計算された履歴ルート・ハッシュ（３１）を前記ＺＫロールアップ・コントラクト・ステート（３２）に格納すること
によって、ユーザ・トークン預金を処理すること
を行う追加のステップを含む、請求項１から３の一項に記載のトランザクション方法。
【請求項5】
前記事前定義済み条件が、固定数ｘ個の後の履歴ルート・ハッシュが格納されることであるか、または前記事前定義済み条件が、同じブロックチェーン・ブロックに対応する別の履歴ルート・ハッシュ、および／もしくは固定数ｘ個の後の履歴ルート・ハッシュが格納されることである、請求項１から４の一項に記載のトランザクション方法。
【請求項6】
前記固定数ｘが、１から２１６までの自然数、および好ましくは２７＜＝ｘ＜＝２９、および最も好ましくはｘ＝２８である、請求項５に記載のトランザクション方法。
【請求項7】
各ユーザ振替命令が、２つの異なるＺＫロールアップ・アドレス間の、またはＺＫロールアップ・アドレスからブロックチェーン・アドレスへの、資金の少なくとも１つの振替のための命令を含む、請求項１から６の一項に記載のトランザクション方法。
【請求項8】
前記ブロックチェーンが、イーサリアム・ブロックチェーンである、請求項１から７の一項に記載のトランザクション方法。
【請求項9】
前記資金が、暗号通貨および／またはデジタル・トークンのタイプの資産である、請求項１から８の一項に記載のトランザクション方法。
【請求項10】
コンピュータ・デバイス・ネットワーク上で実行したとき、請求項１から９の一項に記載のトランザクション方法を実行するコンピュータ・プログラム製品。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、ブロックチェーン用の（ＺＫ（ｚｅｒｏ ｋｎｏｗｌｅｄｇｅ）ロールアップと呼ばれる）ゼロ知識ロールアップ・ネットワークのためのコンピュータ実行トランザクション方法に関し、トランザクション・ルールは、ブロックチェーンに預金されたＺＫロールアップ・スマート・コントラクトによって規定される。
【背景技術】
【0002】
ブロックチェーンのコンテキストでは、いわゆるオン・チェーン計算およびオン・チェーン・データ・ストレージ、つまり、ブロックチェーン自体の上で実行される計算および格納されるデータは高価であり、しばしば技術的ボトルネックにもなる。したがって、（ＺＫロールアップと呼ばれる）ゼロ知識ロールアップのようないわゆるレイヤ２ソリューションは、オフ・チェーンで実行されるバッチに、トランザクションを束ねるかロールアップする。オフ・チェーン計算は、ブロックチェーンにポストされなければならないデータ量を低減させる。ＺＫロールアップ・オペレータは、各トランザクションを個別に送るのではなく、バッチ内のトランザクション全てを表すのに要求される変更の概要を投入する。ＺＫロールアップ・オペレータは、また、彼らの変更の正しさを証明するための有効性証明を生み出す。このような有効性証明は、ブロックチェーンの状態への提案された変更が真にバッチ内のトランザクション全てを実行した最終結果であるという暗号的確かさで示す。ＺＫロールアップのケースでは、有効性証明は、ゼロ知識証明（または略してＺＫ証明）から知られている技法を伴う。
【0003】
オン・チェーン計算およびオン・チェーン・データ・ストレージが、いずれかのＺＫロールアップの採用によって低減されたとしても、トランザクションがＺＫロールアップによって処理される方式は多様であり、方式がもたらし得るコストの点からの恩恵に非常に影響を及ぼす。
【0004】
ほとんどの既存のＺＫロールアップの場合、トランザクション・データは、トランザクション毎にオン・チェーンでポストされる必要があり、トランザクション・データは、トランザクションの送り手、トークン・インデックス、金額、および受取人を含む。これは、ＺＫロールアップであるＳｐｒｉｎｇｒｏｌｌｕｐで改善されており、この場合、送り手は、他のアカウントへの任意の数の振替をバッチ処理できると同時に、ブロック毎のいくつかの小さい一定サイズのデータに加えて、コールデータ、つまり、ロールアップからブロックチェーンに投入されるデータとして、これらのアドレスをポストするだけでよい。各送り手は、オン・チェーン・データ・コストを追加することなく、ブロック内で各送り手が望むのと同じ数のトランザクションを送ることができる。これは、以前のソリューションに比べて、オン・チェーン・データの低減をもたらす。副産物として、オン・チェーンにポストされるユーザ・データが少なくなるので、プライバシの向上が達成される。
【0005】
Ｓｐｒｉｎｇｒｏｌｌｕｐで採用された技法は、クライアント側のＺＫ証明と限定的なオンライン想定との組合せによる、Ｉｎｔｍａｘでさらに改善された。これによって、前者は、ゼロ知識検証プロセスの一部をユーザにアウトソーシングすることによって、アグリゲータ・コストの低減に寄与する。これらは、ＺＫ証明を生成し、ＺＫ証明をアグリゲータにポストし、アグリゲータは、次いで、ユーザ・トランザクションを集約し、トランザクションの集約されたバッチをオン・チェーンで送ってトランザクションを完了させる必要がある。
【発明の概要】
【発明が解決しようとする課題】
【0006】
ＺＫロールアップのコンテキストにおける別の難題は、データの圧縮、および計算リソースの必要性の減少を可能にする、ユーザからのトランザクションを集約する、非集中型アグリゲータに関する。この難題は、アグリゲータを信頼する必要なく、活気をどのように確保するかである。Ｉｎｔｍａｘの場合、複数のアグリゲータを単純に可能にする場合、各アグリゲータは、次のアグリゲータが新しいブロックを作れるように、データ（アップデートされたユーザ・ステート）を次のアグリゲータに提供しなければならない。このアプローチには２つの短所がある。第１に、各アグリゲータが前のブロックを構築する必要があるので、この方法は、どのアグリゲータが、新しいブロックを作成できるか決定するために、リーダ選択方法の複雑性を要求する。第２に、また、より重要なことには、アグリゲータのうちの１つがデータを次のアグリゲータに提供できない場合、ＺＫロールアップは中止することになり、全てのユーザが、ロールアップを出る必要があるはずである。
【課題を解決するための手段】
【0007】
従来技術の問題のうちの少なくとも１つを解決する、ブロックチェーン用のＺＫロールアップのためのトランザクション方法を提供することが本発明の目的である。
【0008】
ブロックチェーンは、例えばイーサリアムといった、スマート・コントラクト互換ブロックチェーンであることが、ここでは理解される。
【0009】
本発明の目的のうちの少なくとも１つは、請求項１に記載のブロックチェーン用のＺＫロールアップのためのトランザクション方法によって達成される。
【0010】
ブロックチェーン用のＺＫロールアップ・ネットワークのためのトランザクション方法であって、トランザクション・ルールが、ブロックチェーンに展開されたＺＫロールアップ・スマート・コントラクトによって規定され、ＺＫロールアップ・ネットワークが、少なくとも１つがアグリゲータＺＫロールアップ・ノードであるいくつかのユーザＺＫロールアップ・ノードを含み、ＺＫロールアップ・スマート・コントラクトによって、
ａ）少なくとも１つのアグリゲータＺＫロールアップ・ノードのアグリゲータＺＫロールアップ・ノードＡから、アグリゲータ振替トランザクションを受け取ることであって、アグリゲータ振替トランザクションが、アグリゲータＺＫロールアップ・ノードＡにおいて生成され、
ｉ．少なくとも１つのユーザ振替命令についてのマークル木のマークル・ルートであって、少なくとも１つのユーザ振替命令のそれぞれが、いくつかのユーザＺＫロールアップ・ノードのうちの１つにおいて生成され、アグリゲータＺＫロールアップ・ノードＡに振り替えられる、マークル・ルート、
ｉｉ．マークル・ルートの少なくとも１つのユーザ署名から構築された集約済み署名であって、マークル・ルートの少なくとも１つのユーザ署名のそれぞれが、ユーザＺＫロールアップ・アカウントに対応し、アグリゲータＺＫロールアップ・ノードＡからこのユーザＺＫロールアップ・ノードにおいて生成されたユーザ振替命令の包含の証明と一緒にマークル・ルートをいくつかのユーザＺＫロールアップ・ノードが受け取った後、いくつかのユーザＺＫロールアップ・ノードのうちの１つから、アグリゲータＺＫロールアップ・ノードＡに振り替えられる、集約済み署名、および
ｉｉｉ．集約済み署名が構築される元であるマークル・ルートの少なくとも１つのユーザ署名のいずれかに対応するあらゆるユーザＺＫロールアップ・アカウントのリスト
を含む、受け取ること、
ｂ）アグリゲータ振替トランザクションが正式に有効であることを検証すること、ならびに
ｃ）前のステップでの検証が成功だった場合、さらなる検証を行わず、アグリゲータ振替トランザクションの内容から、および直前の履歴ルート・ハッシュから履歴ルート・ハッシュを計算し、事前定義済み条件が満たされるまで、計算された履歴ルート・ハッシュをＺＫロールアップ・コントラクト・ステートに格納すること
によって、ユーザ振替を処理することと、
ａ）少なくとも１つのアグリゲータＺＫロールアップ・ノードのアグリゲータＺＫロールアップ・ノードＢから、アグリゲータ引出しトランザクションを受け取ることであって、アグリゲータ引出しトランザクションが、アグリゲータＺＫロールアップ・ノードＢにおいて生成され、
ｉ．１つまたは複数のブロックチェーン・アドレス、
ｉｉ．履歴ルート・ハッシュＭ、
ｉｉｉ．履歴ルート・ハッシュＭにおける１つまたは複数のブロックチェーン・アドレスのそれぞれによって受け取られた総額とされる金額（ｐｕｒｐｏｒｔｅｄ ｔｏｔａｌ ａｍｏｕｎｔ）、
ｉｖ．受け取られた各総額とされる金額の正しさについての１つまたは複数の再帰的ＺＫ証明
を含む、受け取ること、
ｂ）
ｉ．アグリゲータ引出しトランザクションが正式に有効であること、
ｉｉ．履歴ルート・ハッシュＭがＺＫロールアップ・コントラクト・ステートに格納されること、および
ｉｉｉ．受け取られた各総額とされる金額の正しさについての１つまたは複数の再帰的ＺＫ証明のそれぞれ
を検証すること、
ｃ）前のステップでの検証が成功だった場合、
ｉ．履歴ルート・ハッシュＭにおける１つまたは複数のブロックチェーン・アドレスのそれぞれによって受け取られた総額とされる金額に応じて、および１つまたは複数のブロックチェーン・アドレスのそれぞれに既に引き出された総額に応じて、資金を振り替えること、
ｉｉ．ステップｉにおいて１つまたは複数のブロックチェーン・アドレス毎に処理された金額に応じて、１つまたは複数のブロックチェーン・アドレスのそれぞれに既に引き出された総額のリストをアップデートすることであって、１つまたは複数のブロックチェーン・アドレスのそれぞれに引き出された総額のリストが、ＺＫロールアップ・コントラクト・ステートに格納される、アップデートすること
によって、１つまたは複数のブロックチェーン・アドレスへの資金の引出しを処理することと
を行うステップを含む、トランザクション方法。
ａ）少なくとも１つのアグリゲータＺＫロールアップ・ノードのアグリゲータＺＫロールアップ・ノードＡから、アグリゲータ振替トランザクションを受け取ることであって、アグリゲータ振替トランザクションが、アグリゲータＺＫロールアップ・ノードＡにおいて生成され、
ｉ．少なくとも１つのユーザ振替命令についてのマークル木のマークル・ルートであって、少なくとも１つのユーザ振替命令のそれぞれが、いくつかのユーザＺＫロールアップ・ノードのうちの１つにおいて生成され、アグリゲータＺＫロールアップ・ノードＡに振り替えられる、マークル・ルート、
ｉｉ．マークル・ルートの少なくとも１つのユーザ署名から構築された集約済み署名であって、マークル・ルートの少なくとも１つのユーザ署名のそれぞれが、ユーザＺＫロールアップ・アカウントに対応し、アグリゲータＺＫロールアップ・ノードＡからこのユーザＺＫロールアップ・ノードにおいて生成されたユーザ振替命令の包含の証明と一緒にマークル・ルートをいくつかのユーザＺＫロールアップ・ノードが受け取った後、いくつかのユーザＺＫロールアップ・ノードのうちの１つから、アグリゲータＺＫロールアップ・ノードＡに振り替えられる、集約済み署名、および
ｉｉｉ．集約済み署名が構築される元であるマークル・ルートの少なくとも１つのユーザ署名のいずれかに対応するあらゆるユーザＺＫロールアップ・アカウントのリスト
を含む、受け取ること、
ｂ）アグリゲータ振替トランザクションが正式に有効であることを検証すること、ならびに
ｃ）前のステップでの検証が成功だった場合、さらなる検証を行わず、アグリゲータ振替トランザクションの内容から、および直前の履歴ルート・ハッシュから履歴ルート・ハッシュを計算し、事前定義済み条件が満たされるまで、計算された履歴ルート・ハッシュをＺＫロールアップ・コントラクト・ステートに格納すること
によって、ユーザ振替を処理することと、
ａ）少なくとも１つのアグリゲータＺＫロールアップ・ノードのアグリゲータＺＫロールアップ・ノードＢから、アグリゲータ引出しトランザクションを受け取ることであって、アグリゲータ引出しトランザクションが、アグリゲータＺＫロールアップ・ノードＢにおいて生成され、
ｉ．１つまたは複数のブロックチェーン・アドレス、
ｉｉ．履歴ルート・ハッシュＭ、
ｉｉｉ．履歴ルート・ハッシュＭにおける１つまたは複数のブロックチェーン・アドレスのそれぞれによって受け取られた総額とされる金額（ｐｕｒｐｏｒｔｅｄ ｔｏｔａｌ ａｍｏｕｎｔ）、
ｉｖ．受け取られた各総額とされる金額の正しさについての１つまたは複数の再帰的ＺＫ証明
を含む、受け取ること、
ｂ）
ｉ．アグリゲータ引出しトランザクションが正式に有効であること、
ｉｉ．履歴ルート・ハッシュＭがＺＫロールアップ・コントラクト・ステートに格納されること、および
ｉｉｉ．受け取られた各総額とされる金額の正しさについての１つまたは複数の再帰的ＺＫ証明のそれぞれ
を検証すること、
ｃ）前のステップでの検証が成功だった場合、
ｉ．履歴ルート・ハッシュＭにおける１つまたは複数のブロックチェーン・アドレスのそれぞれによって受け取られた総額とされる金額に応じて、および１つまたは複数のブロックチェーン・アドレスのそれぞれに既に引き出された総額に応じて、資金を振り替えること、
ｉｉ．ステップｉにおいて１つまたは複数のブロックチェーン・アドレス毎に処理された金額に応じて、１つまたは複数のブロックチェーン・アドレスのそれぞれに既に引き出された総額のリストをアップデートすることであって、１つまたは複数のブロックチェーン・アドレスのそれぞれに引き出された総額のリストが、ＺＫロールアップ・コントラクト・ステートに格納される、アップデートすること
によって、１つまたは複数のブロックチェーン・アドレスへの資金の引出しを処理することと
を行うステップを含む、トランザクション方法。
【0011】
アグリゲータＺＫロールアップ・ノードＡおよびアグリゲータＺＫロールアップ・ノードＢは、同じアグリゲータＺＫロールアップ・ノードでもよいことに注意されたい。
【0012】
アグリゲータ振替トランザクションは、ＺＫロールアップ・スマート・コントラクトへのコールデータまたはブロブデータとして、それぞれのトランザクションの内容を伴うブロックチェーン・トランザクションを作ることによって、対応するノードによってＺＫロールアップ・チェーンに追加された、ＺＫロールアップ・ブロックの形で届くことが可能である。アグリゲータ引出しトランザクションは、ＺＫロールアップ・スマート・コントラクトの引出し関数を介して実行されることが可能である。
【0013】
ここで提示されるこのトランザクション方法は、Ｉｎｔｍａｘデザインに基づき、以下の２つの方式で既存のソリューションを改善する。
第１に、並行して作業する多くの独立した信頼できないアグリゲータが可能にされ、可用性および検閲耐性を向上させる。前のブロックを全く知る必要なく、ブロック・プロダクションが発生することが可能である。
第２に、トランザクションのための最終決裁時間が減少され、最終決裁時間は、ユーザが支払いを開始してから、支払いが成功し、元に戻されることがないという保証を同じユーザが受け取るまでの時間である。
第１に、並行して作業する多くの独立した信頼できないアグリゲータが可能にされ、可用性および検閲耐性を向上させる。前のブロックを全く知る必要なく、ブロック・プロダクションが発生することが可能である。
第２に、トランザクションのための最終決裁時間が減少され、最終決裁時間は、ユーザが支払いを開始してから、支払いが成功し、元に戻されることがないという保証を同じユーザが受け取るまでの時間である。
【0014】
その上、これらの改善は、いわゆるオン・チェーン計算およびオン・チェーン・データ・ストレージ、つまり、ブロックチェーン自体の上で実行される計算および格納されるデータのリソース要件の減少と一緒に生じる。ブロックチェーンのコンテキストでは、このようなオン・チェーン計算およびオン・チェーン・データ・ストレージは高価であり、技術的ボトルネックにもなる。これについての理由は、ブロックチェーンが、ネットワーク内の２つ以上のノードにわたってアップデートおよび共有される公開データベースであることである。したがって、オン・チェーンでデータを格納することは、あらゆるノードにデータを格納することを意味する。その上、ブロックチェーンは通常、コンセンサス方法で機能するので、１つのノードによって示唆されるオン・チェーン計算は通常、他のノードによって検証される必要がある。したがって、オン・チェーン・データ・ストレージおよびオン・チェーン計算の量は、ブロックチェーンに関与できるようにするためにノードによって満たされるべきハードウェア要件の決定に非常に関連がある。
【0015】
その上、ＺＫロールアップ・ブロックをＺＫロールアップ・チェーンに追加するコスト、およびしたがって、ＺＫロールアップ・トランザクションのコストは、ブロックをブロックチェーンにポストするために要求される料金に縛られる。例えば、イーサリアムまたは類似のブロックチェーンでは、ユーザは、トランザクションをブロックチェーンに送るときに料金を支払う必要がある。これらの料金は、トランザクションが使用するリソースの量によって決定される。これらのリソースは、ＺＫ証明を検証するときに必要な計算リソース、ブロックチェーンに送られるデータである帯域幅リソース、および、ＺＫロールアップ・スマート・コントラクトのストレージに格納されたデータであるストレージという、３つのカテゴリにカテゴライズされることが可能である。ＺＫロールアップは、ＺＫ証明を検証するために主に計算リソースを、および、トランザクション・データを利用できるようにするために帯域幅リソースを使用し、その一方で、ストレージは、ＺＫロールアップによってわずかに使用され、例えばステートまたは履歴ハッシュを格納するためだけに使用される。ストレージと帯域幅との間の差にここでは注意されたい。ストレージは、ＺＫロールアップ・スマート・コントラクトのストレージ内のブロックチェーンにデータを永久に格納するときに使用される一方で、帯域幅は、格納されないデータ、およびブロックチェーン・ノードによって取り除かれることが可能なデータのためのものである。帯域幅は、ストレージに比べて安価である。計算は、固定されており、ＺＫロールアップ・ブロック内のトランザクションの数とは無関係なので、ＺＫ証明が、証明の検証コストを増加させることなく、任意の数のトランザクションを証明できるとき、ＺＫロールアップの主なボトルネックは帯域幅の消費量であり、帯域幅の消費量は、既存のＺＫロールアップにおけるケースのとき、ＺＫロールアップ・ブロック内のトランザクションの数、または、本プロトコルにおけるケースのとき、ブロック内の送り手の数に比例する。この点に関して、本デザインは、本デザインが、ブロック内の送り手毎の送り手アドレスのポストだけしか要求しない一方で、他のＺＫロールアップは、送り手アドレスと、トークンＩＤ、金額、および受取人アドレスなどの他のトランザクション詳細との両方をポストする必要があるので、既存のＺＫロールアップよりデータ効率がよい。これは、本デザインを既存のＺＫロールアップより効率的なものにする。本デザインは、また、既存のＺＫロールアップより計算上効率がよい。実際には、引き出すときにだけＺＫ証明のオン・チェーン検証を行うことによって、引出し動作は、新しいＺＫロールアップ・ブロックを追加することより少ない頻度で実施されることが可能である。このようにして、頻繁なＺＫロールアップ・ブロックを有することによって、高速な最終決裁時間が維持されることが可能である一方で、オン・チェーン計算コストは、あまり頻繁でない引出しを有することによって低く維持される。例えば、１つのＺＫロールアップ・ブロックがあらゆるブロックチェーン・ブロック内に追加され、引出し動作が、平均１００個のブロックチェーン・ブロック毎に実施された場合、本デザインは、追加されたときにあらゆるＺＫロールアップ・ブロックを検証するＺＫロールアップより、オン・チェーン計算に関しておよそ１００倍効率がよい。
【0016】
本トランザクション方法の戦略は、再帰的ＺＫ証明の使用によって部分的に可能にされ、再帰的ＺＫ証明は、安全を保証するために必要な検証を束ねることおよび延期することを可能にする。
【0017】
通常のケースのように、トランザクションがＺＫロールアップによって処理される方式は、ブロックチェーンに展開されたＺＫロールアップ・スマート・コントラクトによって実施されるトランザクション・ルールによって規定される。ＺＫロールアップ・スマート・コントラクトは、ＺＫロールアップ・スマート・コントラクト・プログラムを含む互換ブロックをブロックチェーンに追加することによってブロックチェーンに展開可能なプログラムである。ＺＫロールアップ・スマート・コントラクト・プログラムは、少なくとも１つの関数およびＺＫロールアップ・ステートを備え、少なくとも１つの関数は、ＺＫロールアップ・スマート・コントラクトの展開後にブロックチェーンに追加されたブロックによってコール可能であり、ＺＫロールアップ・ステートは、少なくとも１つの関数をコールすることによって、または、２つ以上ある場合、少なくとも１つの関数のサブセットまたは全てをコールすることによって、および、ＺＫロールアップ・スマート・コントラクトの展開後に、ブロックがブロックチェーンおよび／またはＺＫロールアップ・チェーンに追加されることによって、変換可能であることが可能なデータセットである。
【0018】
ここでは、コンピュータ・デバイス上でブロックチェーンのノードを実行することによって、クライアントがこのコンピュータ・デバイス上で実行されることが理解されており、このクライアントは、ブロックチェーンのコピーをダウンロードし、ブロック毎の有効性を検証し、次いで、新しいブロックおよびトランザクションでブロックチェーンを最新に保ち、他のソフトウェアが独自のコピーをダウンロードおよびアップデートするのに役立てる、ソフトウェアである。ユーザＺＫロールアップ・ノード、およびしたがって、アグリゲータＺＫロールアップ・ノードも、ブロックチェーンのノードである。
【0019】
ユーザは、コンピュータ・デバイス上のユーザＺＫロールアップ・ノードにアクセスできるユーザ・オペレータとして、ここでは理解される。ユーザ・オペレータは、１人または複数の自然人またはソフトウェアであることが可能である。
【0020】
アグリゲータは、コンピュータ・デバイス上のアグリゲータＺＫロールアップ・ノードにアクセスできるアグリゲータ・オペレータとして、ここでは理解される。アグリゲータ・オペレータは、１人または複数の自然人またはソフトウェアであることが可能である。ユーザＺＫロールアップ・ノードが、アグリゲータ振替トランザクションおよび／またはアグリゲータ引出しトランザクションをオン・チェーンＺＫロールアップ・スマート・コントラクトに送ることによって、オン・チェーンＺＫロールアップ・スマート・コントラクトと対話する場合、ユーザＺＫロールアップ・ノードもアグリゲータＺＫロールアップ・ノードであることが、ここでは理解される。
【0021】
ノードにアクセスできることは、Ｉｎｆｕｒａなどの信頼できる第三者によって提供されるコンピュータ・デバイスおよびユーザ・インターフェースを介してノードを実行することまたはノードにアクセスすることを、ここでは意味する。
【0022】
ＺＫロールアップのあらゆるユーザおよびあらゆるアグリゲータが、ブロックチェーンにアクセスできなければならない。ブロックチェーン・ノードを実行することを含む、または、Ｉｎｆｕｒａなどの信頼できる第三者ノードを使用することによって、ブロックチェーンにアクセスするためのいくつかの方式がある。あらゆるブロックチェーン・ノードは、ＺＫロールアップ・スマート・コントラクトへのトランザクション、および、ブロックチェーン上で発生する他のトランザクション全てを処理する必要があるが、他の方式でＺＫロールアップに関与する必要は必ずしもない。
【0023】
トランザクションを作るために、ユーザは、ユーザ振替命令をアグリゲータのうちの１つに送ることが可能である。ユーザが、異なるユーザ振替命令を異なるアグリゲータに送れることが条件であることが可能であることに注意されたい。アグリゲータは、次いで、受け取られたユーザ振替命令のセットを束ね、これらの命令からマークル木を構築する。次いで、アグリゲータは、この特定のユーザのユーザ振替命令の包含の証明と一緒に、マークル木にユーザ振替命令を提供したユーザのそれぞれに、構築されたばかりのマークル木のマークル・ルートを送る。マークル・ルート、および対応するマークル木におけるユーザのユーザ振替命令の包含の証明を受け取ると、ユーザは、マークル・ルートに署名し、署名をアグリゲータに送り返すことができる。アグリゲータは、次いで、アグリゲータが署名を全て受け取るまで、または好ましくは、何らかの特定の制限時間まで、マークル・ルートに対応する署名を集めることが可能である。その後、アグリゲータは、受け取られたユーザ署名から集約済み署名を生成し、対応するマークル・ルート、および署名を集約済み署名に提供したユーザのリストと一緒に、この集約済み署名を、ＺＫロールアップ・スマート・コントラクトに送ることが可能である。これは、ＺＫロールアップ・スマート・コントラクトをコールしたＺＫロールアップ・チェーンに、ブロックを追加することによって行われる。
【0024】
ＺＫロールアップ・スマート・コントラクトをコールすることによって、スマート・コントラクトの関数が呼び出され、ＺＫロールアップ・ステートが変更されることが、ここでは理解される。
【0025】
少なくとも１つのユーザ振替命令が、アグリゲータＺＫロールアップ・ノードＡ自体であるユーザＺＫロールアップ・ノードにおいて生成されたユーザ振替命令を含むことが可能であることに注意されたい。さらに、アグリゲータ振替トランザクションは、アグリゲータＺＫロールアップ・ノードＡ自体において生成されたこのようなユーザ振替命令だけを含むことが可能である。しかし、これは、この方式ではデータがより効率的に圧縮されることが可能なので、あらゆるユーザが独自のトランザクションを単に送るのではなく、いくつかのユーザ振替トランザクションがアグリゲータ振替命令内に一緒にまとめられる場合、コストおよびリソースの点で有利である。
【0026】
アグリゲータＺＫロールアップ・ノードとユーザＺＫロールアップ・ノードとの間の通信は、ユーザＺＫロールアップ・ノードが、ＪＳＯＮ－ＲＰＣまたは同様のものなどの既存のデータ通信プロトコルを使用して、対応するアグリゲータによって所有される１つまたは複数のサーバと通信することによって典型的に実現される。
【0027】
ユーザからのユーザ振替命令は、このユーザのユーザＺＫロールアップ・アカウントに割り当てられたＺＫロールアップ・アドレスから、別のＺＫロールアップ・アドレスまたはブロックチェーン・アドレスへの、資金の少なくとも１つの振替のための命令を含むことが可能である。単一のユーザ振替命令に含まれる全ての振替が、同じ送信ＺＫロールアップ・アドレスを有していなければならないが、異なる受取りアドレスを有することが可能であり、各受取りアドレスは、いくつかのＺＫロールアップ・アドレスまたはいくつかのブロックチェーン・アドレスであることが可能である。
【0028】
ブロックチェーン・アドレスは、ブロックチェーン自体のレベルのものであり、その一方で、ＺＫロールアップ・アドレスは、ＺＫロールアップのレベルのものである。
【0029】
ブロックチェーンおよび／またはＺＫロールアップ・アドレスの間の資金の振替は、１つのアドレスから別のアドレスへの資金の割当ての変更を指す。
【0030】
資金は、ここでは、基礎をなすブロックチェーンによってサポートされる任意の種類の資産である。このような資産は、典型的には、トークンのセットである。トークンは、非代替性トークン（ＮＦＴ）、ＥＲＣ－２０、または、ネイティブな暗号通貨の何らかの単位などの、デジタル・トークンとして、ここでは理解される。
【0031】
マークル木は、コンピュータ科学の意味での木であり、葉であるあらゆる木ノードが、データ・ブロックの暗号学的ハッシュでラベル付けされ、葉でないあらゆる木ノードが、その子の木ノードのラベルの暗号学的ハッシュでラベル付けされる。
【0032】
マークル木のコンテキストでの包含の証明はマークル証明とも呼ばれ、包含が証明されることになる葉の兄弟と、ルート・ハッシュ、つまり中間ノードおよびその兄弟のハッシュを計算する必要がある各中間ハッシュとから成る。
【0033】
マークル・ルートのユーザ署名は、アグリゲータＺＫロールアップ・ノードＡにユーザ署名を振り替えるユーザＺＫロールアップ・ノードにおいて生成されること、または、別個のソフトウェアによって、場合によっては別個のコンピュータ・デバイス上で生成され、次いでアグリゲータＺＫロールアップ・ノードＡへのさらなる振替のためにユーザＺＫロールアップ・ノードに振り替えられることが可能である。後者のオプションの場合、別個のソフトウェアは、署名を生成する前に、ユーザＺＫロールアップ・ノードからマークル・ルートおよび包含証明を受け取っていてもよい。
【0034】
ユーザ振替命令毎のマークル・ルートのユーザ署名である必要はないことに注意されたい。ユーザ署名がない場合、対応するユーザ振替命令は、アグリゲータ振替トランザクション内に維持されることが可能であるが、再帰的ＺＫ証明によって有効に参照されることは可能ではない。
【0035】
ユーザＺＫロールアップ・アカウントのリストは、例えば、ユーザ・アカウントに割り当てられたユーザ識別子を含むことができ、ユーザ識別子は、例えば、ユーザ登録時にユーザに割り当てられたＢＬＳ公開鍵またはより短い識別子であることが可能である。
【0036】
ＺＫロールアップ・スマート・コントラクトが、アグリゲータからトランザクションのバッチを受け取ったとき、つまり、スマート・コントラクトをコールするアグリゲータによってブロックがＺＫロールアップ・チェーンに追加されたとき、ＺＫロールアップ・スマート・コントラクトは、トランザクションのバッチが正式に有効である場合、トランザクションのバッチを受け入れる。トランザクションのバッチは、対応するブロックおよび命令が意図されるフォーマットである場合、正式に有効である。特に、ＺＫロールアップ・スマート・コントラクトは、トランザクションのバッチのどの内容も検証しない。トランザクションのバッチが正式に有効である場合、スマート・コントラクトは、以前に計算されたことがある最後の履歴ルート・ハッシュ、およびトランザクションのバッチの内容の全てまたは一部だけを、少なくとも入力として有する、ハッシュ関数を使用して、履歴ルート・ハッシュを計算する。ＺＫロールアップ・スマート・コントラクトは、次いで、事前定義済み条件が満たされるまで、計算された履歴ルート・ハッシュをＺＫロールアップ・ステートに格納する。したがって、現在の履歴ルート・ハッシュは、ＺＫロールアップ・ステートに格納された後、事前定義済み条件が満たされるまでそこに留まり、その後、ＺＫロールアップ・ステートから自動で削除される。
【0037】
ハッシュ関数の出力は、ハッシュまたはハッシュ値と呼ばれ、Ｘをハッシングすることは、Ｘを含む入力でハッシュ関数を計算することとして、ここでは理解される。
【0038】
第１の履歴ルート・ハッシュは、対応するトランザクションの内容の全てまたは一部、および、前の履歴ルート・ハッシュの置換えとしての事前定義済みの入力を入力としてとることが可能である。
【0039】
さらなる検証がないことは、アグリゲータ振替トランザクションの内容の有効性が検証されないことを意味する。例えば、署名の有効性が検証されない。
【0040】
Ｘから履歴ルート・ハッシュを計算することは、入力Ｘでいくつかのハッシュ関数の出力を計算することを、ここでは意味する。ここでは、アグリゲータ振替トランザクションの内容の全てまたは一部だけが、ハッシュ関数の入力に含まれ得ることに注意されたい。
【0041】
アグリゲータ振替トランザクション内のユーザのトランザクションの包含証明を各ユーザが受け取ったので、トランザクション自体をオン・チェーンで公開する必要はなく、トランザクションのマークル木のルートだけがあることに注意されたい。これは、全てのトランザクション・データがオン・チェーンで公開される他のＺＫロールアップ・トランザクション方法より、本方法をデータ効率のよいものにする。
【0042】
アグリゲータは、新しいトランザクションをロールアップに追加するために、前に処理されたトランザクションを知っている必要がないことにも注意されたい。これは、アグリゲートが完全に許可なしであり、したがって、新しいトランザクションは、誰からでも同時に追加されることが可能であることを意味する。
【0043】
ユーザが資金をブロックチェーン・アドレスに引き出したいと思った場合、ユーザは、上述のように、対応するトランザクションを開始することができる。その後、考慮に入れるべき最後のトランザクションを含むブロックの追加の処理後または処理中に、いずれかのアグリゲータが、格納されている履歴ルート・ハッシュＭを選ぶことができる。履歴ルート・ハッシュＭを選んだアグリゲータは、次いで、ブロックチェーン・アドレスのセットのために、履歴ルート・ハッシュＭにおけるブロックチェーン・アドレスのうちの１つによって受け取られた所与の総額が正しいという再帰的ＺＫ証明をユーザ自身で生成すること、および／または、他のユーザからこのような証明を集めることが可能である。再帰的ＺＫ証明は、履歴ルート・ハッシュＭが計算された時点で、ブロックチェーン・アドレスが、少なくとも、総額とされる金額を受け取ったという暗号証明であることが可能であり、あらゆる関連トランザクションについての情報を含む。アグリゲータは、次いで、受け取られた総額とされる金額、履歴ルート・ハッシュＭ、およびアグリゲータ引出しトランザクション内の対応するブロックチェーン・アドレスと一緒に、再帰的ＺＫ証明を、ＺＫロールアップ・スマート・コントラクトに送ることができる。ＺＫロールアップ・スマート・コントラクトは、アグリゲータ引出しトランザクションを受け取ると、アグリゲータ引出しトランザクションが正式に有効であること、つまり、意図されるフォーマットを有していること、履歴ルート・ハッシュＭがＺＫロールアップ・コントラクト・ステートに格納されていること、および各再帰的ＺＫ証明を検証する。ＺＫロールアップ・スマート・コントラクトによる全ての検証が成功だった場合、ＺＫロールアップ・スマート・コントラクトは、ブロックチェーン・アドレスによって受け取られた総額とされる金額に応じて、および関係するブロックチェーン・アドレスのそれぞれに既に引き出された総額に応じて、資金を振替し、既に引き出された総額は、ＺＫロールアップ・コントラクト・ステートに格納され、引出し毎にアップデートされ、対応するブロックチェーン・アドレスへの引出しがまだ処理されていない場合、例えば０といった何らかの事前定義済みの初期値にセットされる。振替は、アグリゲータ引出しトランザクションに応じて、ブロックチェーン・アドレスに属する資産を、ならびに、ＺＫロールアップ・コントラクト・ステートに格納されたブロックチェーン・アドレスに引き出された総額に応じて、引き出されたことがない、およびしたがって、以前に振替したことがない資産を、ブロックチェーン・アドレスに振り替えることによって行われることが可能である。最後に、ＺＫロールアップ・スマート・コントラクトは、本引出し前に、ＺＫロールアップ・コントラクト・ステートに格納されたブロックチェーン・アドレスに引き出された総額を、本引出し後に、ブロックチェーン・アドレスに引き出されたアップデート済みの総額に置き換える。より詳細には、ＺＫロールアップ・スマート・コントラクトは、引出し関数を備えることができ、引出し関数は、任意のアグリゲータによってコール可能であり、アグリゲータ引出しトランザクションの内容を入力としてとり、検証を実施し、検証が成功だった場合、資金の振替を実施し、引き出された総額をアップデートする。
【0044】
ここで、履歴ルート・ハッシュＭにおけるＭは、計算されたあらゆる履歴ルート・ハッシュの、単に何らかのラベルまたはカウントであることが可能である。
【0045】
もちろん、履歴ルート・ハッシュＭを備えるアグリゲータ引出しトランザクションは、履歴ルート・ハッシュＭが計算され、ＺＫロールアップ・コントラクト・ステートに格納された後、アグリゲータＺＫロールアップ・ノードＢによって生成されなければならないことに注意されたい。
【0046】
ブロックチェーン・アドレスによって受け取られた総額とされる金額は、例えば、このアドレスによって受け取られた種類毎の資産の金額のリストであることが可能である。
【0047】
ブロックチェーン・アドレスに引き出された総額は、ブロックチェーン・アドレスに引き出された資産の種類毎の総額のリストであることが可能である。このブロックチェーン・アドレスへのいずれかの引出しの前のブロックチェーン・アドレスに引き出された総額は、例えば値０といったデフォルト値またはインデックスにセットされることが可能である。
【0048】
各ブロックチェーン・アドレスに引き出された総額は、ＺＫロールアップ・コントラクト・ステートに格納され、アップデートされる。アグリゲータ引出しトランザクションに応じて、および含まれるブロックチェーン・アドレスのうちの１つに既に引き出された総額に応じて資金を振り替えることは、トランザクションおよび引き出された総額のデータが考慮され、実際の振替額が場合によってはこのデータによって指示される金額から計算されることを意味する。
【0049】
再帰的ＺＫ証明は、受け取られた総額とされる金額毎の再帰的ＺＫ証明のセットとして維持されることが可能であるか、または、再帰的ＺＫ証明は、受け取られた全ての総額とされる金額のための組み合わされた再帰的ＺＫ証明に要約されることが可能である。前者のケースでは、各再帰的ＺＫ証明は、いくつかのユーザＺＫロールアップ・ノードのうちの１つにおいて生成され、次いで、アグリゲータＺＫロールアップ・ノードＢに振り替えられることが可能であるか、または、各再帰的ＺＫ証明は、別個のソフトウェアにおいて生成され、次いで、いくつかのユーザＺＫロールアップ・ノードのうちの１つに提供されることが可能であり、その後、各再帰的ＺＫ証明は、いくつかのユーザＺＫロールアップ・ノードのうちの１つからアグリゲータＺＫロールアップ・ノードＢに振り替えられる。後者のケースでは、受け取られた全ての総額とされる金額のための組み合わされた再帰的ＺＫ証明は、例えば受け取られた総額とされる金額毎の再帰的ＺＫ証明から集約されたＺＫ証明を生成することによって、アグリゲータＺＫロールアップ・ノードＢにおいて生成されることが可能であり、後者の証明は、前者のケースと同じ方式で提供可能である。
【0050】
本ＺＫロールアップ・デザインは、ステートがハンドリングされる方式が他のデザインとは異なる。ユーザ残高のグローバル・ステートを有するのではなく、各ユーザは、このユーザによって所有されるＺＫロールアップ・アドレスおよびブロックチェーン・アドレスの残高の再帰的ＺＫ証明を維持およびアップデートする。新しいＺＫロールアップ・ブロック毎、または、スマート・コントラクトによって処理されたトランザクション毎に、各ユーザは、その残高をアップデートし、そのアドレスの残高の新しい再帰的ＺＫ証明を計算することが可能である。
【0051】
再帰的ＺＫ証明が正式に有効であるための要件は、対応するＺＫ証明システムに依存する。
【0052】
残高再帰的ＺＫ証明は、Ｐｌｏｎｋｙ２および／またはＮｏｖａおよび／またはＳｕｐｅｒＮｏｖａに基づくことが可能である。
【0053】
残高再帰的ＺＫ証明によって参照されるトランザクションに対応するＺＫロールアップ・ブロックが追加された時点は、これが、履歴ルート・ハッシュＭが格納される前またはその間でなければならないという意味でのみ関連していることに注意されたい。あらゆる履歴ルート・ハッシュが前の履歴ルート・ハッシュから計算されるので、トランザクションは、対応するブロックがかなり前に追加されたとしても、検証可能である。
【0054】
ここで提示されるプロトコルについてのセキュリティ想定は、採用されたＺＫ証明システムがセキュアであるという想定と共に、基礎をなすブロックチェーンについての想定と同じである。
【0055】
本発明のさらなる実施形態が従属請求項で説明されている。
【0056】
いくつかの実施形態では、トランザクション方法は、ＺＫロールアップ・スマート・コントラクトによって、
ａ）いくつかのユーザＺＫロールアップ・ノードのうちの１つからユーザ登録トランザクションを受け取ることであって、ユーザ登録トランザクションが、ユーザＺＫロールアップ・アカウントのユーザ識別子およびユーザ識別子のユーザ署名を含む、受け取ること、
ｂ）ユーザ識別子のユーザ署名を検証すること、ならびに
ｃ）前のステップでの検証が成功だった場合、（ｉ）ユーザ登録トランザクションの内容および直前の履歴ルート・ハッシュ（３１’）から履歴ルート・ハッシュ（３１）を計算し、事前定義済み条件が満たされるまで、計算された履歴ルート・ハッシュ（３１）をＺＫロールアップ・コントラクト・ステート（３２）に格納すること、ならびに（ｉｉ）ＺＫロールアップ・アドレスをユーザＺＫロールアップ・アカウントに割り当てること
によって、ユーザＺＫロールアップ・アカウントの登録を処理すること
を行う追加のステップを含むことができる。
ａ）いくつかのユーザＺＫロールアップ・ノードのうちの１つからユーザ登録トランザクションを受け取ることであって、ユーザ登録トランザクションが、ユーザＺＫロールアップ・アカウントのユーザ識別子およびユーザ識別子のユーザ署名を含む、受け取ること、
ｂ）ユーザ識別子のユーザ署名を検証すること、ならびに
ｃ）前のステップでの検証が成功だった場合、（ｉ）ユーザ登録トランザクションの内容および直前の履歴ルート・ハッシュ（３１’）から履歴ルート・ハッシュ（３１）を計算し、事前定義済み条件が満たされるまで、計算された履歴ルート・ハッシュ（３１）をＺＫロールアップ・コントラクト・ステート（３２）に格納すること、ならびに（ｉｉ）ＺＫロールアップ・アドレスをユーザＺＫロールアップ・アカウントに割り当てること
によって、ユーザＺＫロールアップ・アカウントの登録を処理すること
を行う追加のステップを含むことができる。
【0057】
いくつかのユーザＺＫロールアップ・アカウントがこれによって登録されるユーザＺＫロールアップ・ノードがあること、または単一のユーザＺＫロールアップ・ノードがあること、またはユーザＺＫロールアップ・ノードがないことが可能であることに注意されたい。ユーザは、ユーザＺＫロールアップ・アカウントを１つのユーザＺＫロールアップ・ノードに登録し、その後、ＺＫロールアップに同様に、または、他のユーザＺＫロールアップ・ノードと共に排他的に、関与することが可能である。
【0058】
資金が引き出されることが可能なブロックチェーン・アドレスは、スマート・コントラクト・アカウントまたは外部所有アカウント（ＥＯＡ）に対応することが可能である。
【0059】
いくつかの実施形態では、ユーザ署名および／または集約済み署名は、ＢＬＳ署名でもよい。
【0060】
Ｂｏｎｅｈ－Ｌｙｎｎ－Ｓｈａｃｈａｍ（ＢＬＳ）署名は、署名者が本物であることをユーザが検証できるようにする暗号署名スキームである。スキームは、秘密鍵および対応する公開鍵を伴う。このスキームでは、ユーザは、ビット列および秘密鍵から所与の関数を計算することによって、ビット列のユーザ署名を生成することが可能である。検証者はその後、署名および公開鍵を考慮に入れて署名を検証することが可能である。複数の秘密鍵および／または複数のビット列に対応する複数のＢＬＳ署名が、単一のＢＬＳ署名に集約されることが可能である。
【0061】
ＢＬＳ署名を使用するとき、ユーザ登録トランザクションに含まれるユーザ識別子およびユーザ識別子のユーザ署名は、公開ＢＬＳ鍵、および、対応する秘密ＢＬＳ鍵と一緒に公開ＢＬＳ鍵から計算された署名であることが可能である。
【0062】
いくつかの実施形態では、トランザクション方法は、ＺＫロールアップ・スマート・コントラクトによって、
ａ）いくつかのユーザＺＫロールアップ・ノードのうちの１つから、ユーザ・トークン預金トランザクションと一緒にトークンのセットを受け取ることであって、ユーザ・トークン預金トランザクションが、このユーザＺＫロールアップ・ノードにおいて生成され、
ｉ．少なくとも１つのトークンＩＤ、
ｉｉ．少なくとも１つのトークンＩＤ毎のトークンの量、および
ｉｉｉ．トークンの量を受け取るためのＺＫロールアップ・アドレス
を含む、受け取ること、
ｂ）
ｉ．ユーザ・トークン預金トランザクションが正式に有効であること、および
ｉｉ．少なくとも１つのトークンＩＤ毎に、受け取られたトークンのセットが、このトークンＩＤのトークンの量によって指示されたものと同じ数の、このトークンＩＤに対応するトークンを含むこと
を検証すること、
ｃ）前のステップでの検証が成功だった場合、ユーザ・トークン預金トランザクションの内容および直前の履歴ルート・ハッシュから履歴ルート・ハッシュを計算し、事前定義済み条件が満たされるまで、計算された履歴ルート・ハッシュをＺＫロールアップ・コントラクト・ステートに格納すること
によって、ユーザ・トークン預金を処理すること
を行う追加のステップを含むことができる。
ａ）いくつかのユーザＺＫロールアップ・ノードのうちの１つから、ユーザ・トークン預金トランザクションと一緒にトークンのセットを受け取ることであって、ユーザ・トークン預金トランザクションが、このユーザＺＫロールアップ・ノードにおいて生成され、
ｉ．少なくとも１つのトークンＩＤ、
ｉｉ．少なくとも１つのトークンＩＤ毎のトークンの量、および
ｉｉｉ．トークンの量を受け取るためのＺＫロールアップ・アドレス
を含む、受け取ること、
ｂ）
ｉ．ユーザ・トークン預金トランザクションが正式に有効であること、および
ｉｉ．少なくとも１つのトークンＩＤ毎に、受け取られたトークンのセットが、このトークンＩＤのトークンの量によって指示されたものと同じ数の、このトークンＩＤに対応するトークンを含むこと
を検証すること、
ｃ）前のステップでの検証が成功だった場合、ユーザ・トークン預金トランザクションの内容および直前の履歴ルート・ハッシュから履歴ルート・ハッシュを計算し、事前定義済み条件が満たされるまで、計算された履歴ルート・ハッシュをＺＫロールアップ・コントラクト・ステートに格納すること
によって、ユーザ・トークン預金を処理すること
を行う追加のステップを含むことができる。
【0063】
ユーザ・トークン預金トランザクションは、意図されるフォーマットである場合、正式に有効である。
【0064】
Ｘから履歴ルート・ハッシュを計算することは、入力Ｘでいくつかのハッシュ関数の出力を計算することを、ここでは意味する。ここでは、ユーザ預金トランザクションの内容の全てまたは一部だけが、ハッシュ関数の入力に含まれることが可能であることに注意されたい。
【0065】
ユーザ登録トランザクション、ユーザ・トークン預金トランザクション、およびアグリゲータ振替トランザクションは、それぞれ、ＺＫロールアップ・スマート・コントラクトへのコールデータまたはブロブデータとしてそれぞれのトランザクションの内容を伴うブロックチェーン・トランザクションを作ることによって、対応するノードによってＺＫロールアップ・チェーンに追加されたＺＫロールアップ・ブロックの形で届くことが可能であることに注意されたい。
【0066】
トークンＩＤは、例えば、ＥＴＨ、ＤＡＩ、もしくはＵＳＤＣ、または特定のＮＦＴのような、暗号通貨の種類のような、トークンの、つまりトークンの種類の特定のクラスの識別子として、ここでは理解される。トークンＩＤは、例えば自然数であることが可能である。
【0067】
ブロックチェーン上のＺＫロールアップ・チェーンに加えて、オフ・チェーンで計算された対応する有効であると認められたＺＫロールアップ・チェーンがあることが可能である。ここでは、アグリゲータ振替トランザクションが正式に有効であり、アグリゲータ振替トランザクションのユーザＺＫロールアップ・アカウントのリストに対する、アグリゲータ振替トランザクションの集約済み署名が正しい場合、アグリゲータ振替トランザクションに対応するＺＫロールアップ・ブロックを有効とみなす。そうでなければ、アグリゲータ振替トランザクションに対応するＺＫロールアップ・ブロックは無効とみなされる。さらに、アグリゲータ振替トランザクションが正式に有効であり、ユーザ識別子に対するユーザ識別子のユーザ署名が正しい場合、ユーザ登録トランザクションに対応するＺＫロールアップ・ブロックを有効とみなす。ユーザ・トークン預金トランザクションは、これらが追加されたときに、その内容がＺＫロールアップ・スマート・コントラクトによって検証されるので、常に有効であると考えられる。有効であると認められたＺＫロールアップ・チェーンは、次いで、有効であると認められたＺＫロールアップ・ブロックだけを含むこと、および無効なＺＫロールアップ・ブロックをスキップすることによって計算される。より正確には、現在のＺＫロールアップ・ブロックが有効であるかどうかに関わらず、以前の元の履歴ルート・ハッシュ、および現在のＺＫロールアップ・ブロックの内容から、元のＺＫロールアップ・チェーンの元の履歴ルート・ハッシュが計算されるが、現在のＺＫロールアップ・ブロックが有効である場合だけ、有効であると認められたＺＫロールアップ・チェーンに対して同じことが行われる。したがって、有効であると認められたＺＫロールアップ・チェーンをアップデートするために、元のＺＫロールアップ・チェーンに新たに追加されたＺＫロールアップ・ブロックの有効性が、あらかじめ検証されなければならない。この検証は、ユーザＺＫロールアップ・アカウントまたはユーザ識別子に対応する署名の検証を伴い、オフ・チェーン・ユーザＺＫロールアップ・ステート内のユーザＺＫロールアップ・アカウントおよびその対応するＺＫロールアップ・アドレスを追跡することによって行われることが可能である。ＺＫロールアップ・ブロックが検証されたとき、このＺＫロールアップ・ブロックの有効性の証明が生成され、オン・チェーンでポストされることが可能である。有効であると認められたＺＫロールアップ・チェーンのための計算および証明は、ＺＫロールアップに関与している、つまり、少なくとも１つのユーザＺＫロールアップ・アカウントを登録している、任意のユーザによって実施されることが可能であることに注意されたい。その上、ＺＫロールアップに関与しているユーザは、オン・チェーンでポストされたＺＫロールアップ・ブロックの有効性証明を信頼することによって、計算を行うことなく有効であると認められたチェーンの独自のバージョンを格納することができる。例えば、ＺＫロールアップ・ブロックを検証し、証明を生成し、証明をオン・チェーンでポストするタスクをアグリゲータが処理することを奨励するために、適切なルールがＺＫロールアップ・スマート・コントラクトに組み込まれることが可能である。同様に、適切なルールは、ほとんどのケースにおいて、ＺＫロールアップ・ブロックのポストされた有効性証明がオン・チェーンで検証される必要なく、これらの有効性証明を信頼することを動機づけるのに役立てることが可能である。
【0068】
有効であると認められたＺＫロールアップ・チェーンが、（ＺＫロールアップ・ブロックの有効性証明がオン・チェーンでポストされるという意味で）利用可能な場合、ユーザ引出し命令の残高再帰的ＺＫ証明は、元の履歴ルート・ハッシュＭ、１つまたは複数のブロックチェーン・アドレス、および、元の履歴ルート・ハッシュＭにおけるこれらの請求残高を公開入力としてとり、１）有効であると認められた履歴ルート・ハッシュＭ’、およびこれが、元の履歴ルート・ハッシュＭに対応する正しい有効であると認められた履歴ルート・ハッシュであるという再帰的ＺＫ証明が存在すること、ならびに、２）１つまたは複数のブロックチェーン・アドレス毎に、このブロックチェーン・アドレスが、有効であると認められた履歴ルート・ハッシュＭ’において指定残高を有するという再帰的ＺＫ証明が存在することを、証明することができる。
【0069】
より一般には、証明システムは、再帰的ＺＫ証明を行う能力がある任意の証明システムであることが可能である。
【0070】
いくつかの実施形態では、事前定義済み条件は、固定数ｘ個の後の履歴ルート・ハッシュが格納されることでもよく、または事前定義済み条件は、同じブロックチェーン・ブロックに対応する別の履歴ルート・ハッシュ、および／もしくは固定数ｘ個の後の履歴ルート・ハッシュが格納されることである。
【0071】
ここで、固定数ｘは、１以上の自然数である。
【0072】
両方のオプションに関して、最大ｘ＋１個の履歴ルート・ハッシュがストレージ内に維持される。１つのブロックチェーン・ブロック、つまり１つのブロックチェーン・トランザクションに含まれるいくつかのＺＫロールアップ・ブロックがあり得るので、それでも２つのオプションは異なってもよい。第２のオプションは、ＺＫロールアップ・コントラクト・ステート内で最後のＺＫロールアップ・ブロックが追加されたブロックチェーン・ブロック番号を格納することによって実現されることが可能である。
【0073】
ここで、ｘ番目の後の履歴ルート・ハッシュで、または同じブロックチェーン・ブロックに対応する他の履歴ルート・ハッシュでそれぞれ、ストレージから消される予定の履歴ルート・ハッシュを上書きすることによって、ストレージから消される予定の履歴ルート・ハッシュが消されることが可能であることに注意されたい。このケースでは、古い履歴ルート・ハッシュを削除すること、および、ｘ番目の後の履歴ルート・ハッシュ、または同じブロックチェーン・ブロックに対応する他の履歴ルート・ハッシュをそれぞれ格納することは、一斉に発生している。これは、このケースでは、ストレージ内に最大ｘ個の履歴ルート・ハッシュが同時に存在することも意味する。
【0074】
いくつかの実施形態では、固定数ｘは、１から２１６までの自然数、および好ましくは２７＜＝ｘ＜＝２９、および最も好ましくはｘ＝２８でもよい。
【0075】
原則として、ｘは、任意の自然数＞０でもよいことに注意されたい。しかし、以下のトレード・オフがあり、一方では、数字が小さすぎる場合、履歴ルート・ハッシュがＺＫロールアップ・コントラクト・ステートから削除される前に、引き出すために必要な残高再帰的ＺＫ証明を生成するための時間が十分にないこともある。一方で、数字が大きすぎる場合、ＺＫロールアップ・スマート・コントラクトによって格納されることが必要な多くのデータがある。
【0076】
事前定義済み条件が、同じブロックチェーン・ブロックに対応する別の履歴ルート・ハッシュ、および／もしくは固定数ｘ個の後の履歴ルート・ハッシュが格納されることである場合、ブロックチェーン・ブロック毎に最大１つの履歴ルート・ハッシュが格納される。したがって、例えば、１２秒毎にブロックチェーン・ブロックが追加される場合、ｘ＝２８＝２５６を設定することは、少なくとも２５６＊１２秒＝５１分間に、各履歴ルート・ハッシュが格納されることを保証する。さらに、２５６は、１バイトに収まる最大数であり、実装形態において利点になり得ることに注意されたい。それでも、この数字は、例えば、証明に必要な時間に応じて、調節されることが可能である。
【0077】
いくつかの実施形態では、各ユーザ振替命令は、２つの異なるＺＫロールアップ・アドレス間の、またはＺＫロールアップ・アドレスからブロックチェーン・アドレスへの、資金の少なくとも１つの振替のための命令を含むことができる。
【0078】
資金の単一の振替は、常に２つの全く異なるアドレス間であり、受取りアドレスがブロックチェーン・アドレスであるケースでは、ブロックチェーン・アドレスは、ロールアップ構造内の適切な方式で表されることに注意されたい。しかし、ユーザ振替命令は、ＺＫロールアップ・アドレスから、他のＺＫロールアップ・アドレスおよび／またはブロックチェーン・アドレスへの、いくつかの振替を含むことができる。ユーザ振替命令は、ただ１つのＺＫロールアップ・アドレスからの振替を典型的に含む。それでも、ユーザは、登録された２つ以上のユーザＺＫロールアップ・アカウントを有することが可能である。
【0079】
いくつかの実施形態では、ブロックチェーンは、イーサリアム・ブロックチェーンでもよい。
【0080】
いくつかの実施形態では、資金は、暗号通貨および／またはデジタル・トークンのタイプの資産でもよい。
【0081】
本発明は、また、コンピュータ・デバイス・ネットワーク上で実行するときに上述のトランザクション方法を実行するコンピュータ・プログラム製品に言及する。
【0082】
本発明は、図を参照しながら下記でさらに説明される。
【図面の簡単な説明】
【0083】
【図1】ＺＫロールアップ・チェーンの概略図である。
【図2】バッチをＺＫロールアップに追加することについての概略図である。
【図3】登録バッチの例の図である。
【図4】預金バッチの例の図である。
【図5】ＺＫロールアップ・ネットワークのための振替トランザクション方法の概略図である。
【図6】有効であると認められたチェーンの概略図である。
【図7】有効な登録バッチを追加することについての概略図である。
【図8】有効な預金または振替バッチを追加することについての概略図である。
【図9】無効なバッチを追加することについての概略図である。
【図10】ユーザ・ステート／残高をアップデートすることについての概略図である。
【図11】引出しの概略図である。
【発明を実施するための形態】
【0084】
本セクションおよび図では、読みやすくするために、ＺＫロールアップ・ブロックがバッチと呼ばれ、ブロックチェーン・ブロックがブロックと呼ばれる。
【0085】
ＺＫロールアップ・チェーンは、ここでは、図１に見られるように、バッチのバッチ・ハッシュ３１（履歴ルート・ハッシュ）と共にバッチのチェーンから成る。登録バッチ６（ユーザ登録トランザクション）、預金バッチ７（ユーザ・トークン預金トランザクション）、および振替バッチ５１（アグリゲータ振替トランザクション）という、３種類のバッチがある。これらは、後で説明される。各バッチ・ハッシュ３１は、前のバッチ・ハッシュ３１’（直前の履歴ルート・ハッシュ）と共にバッチ内容のハッシュである。
【0086】
ＺＫロールアップ・スマート・コントラクトは、ここでは、後で説明されるように引出しのために必要な、最後の２５６個のバッチ・ハッシュ３１のリストを格納する、ブロックチェーン（レイヤ１またはＬ１とも呼ばれ、その一方で、ＺＫロールアップは、レイヤ２またはＬ２とも呼ばれる）スマート・コントラクトである。ＺＫロールアップにバッチを追加するプロセスは、図２に示されている。
【0087】
ＺＫロールアップに関与する誰もが、コールデータまたはブロブデータとして含まれる新しいブロック６、７、５１の内容を伴うＺＫロールアップ・スマート・コントラクト３へのブロックチェーン・トランザクションを作ることによって、新しいバッチ６、７、５１をＺＫロールアップに追加することが可能である。ＺＫロールアップ・スマート・コントラクト３は、次いで、前のバッチ・ハッシュ３１’と一緒に新しいバッチの内容をハッシングすることによって、新しいバッチのバッチ・ハッシュ３１を計算することになり、前のバッチ・ハッシュ３１’は、コントラクト・ストレージ３２（ＺＫロールアップ・コントラクト・ステート）に既に格納されている。ＺＫロールアップ・スマート・コントラクト３は、次いで、最近のバッチ・ハッシュ３１’（Ｎ－１、．．．、Ｎ－２５５）のリストに新しいバッチ・ハッシュ３１（Ｎ）を追加し、最も古いバッチ・ハッシュをリストから除去する。
【0088】
アグリゲータ５は、ＺＫロールアップに新しいバッチを追加するために、前のバッチを知っている必要はない。これは、集約が、完全に許可なしであることが可能であり、したがって、新しいバッチは、誰からでも同時に追加されることが可能であることを意味する。
【0089】
ユーザが、ＺＫロールアップ・ネットワーク上にトランザクションを作ることが可能である前に、ユーザは、公開Ｂｏｎｅｈ－Ｌｙｎｎ－Ｓｈａｃｈａｍ（ＢＬＳ）鍵を登録することによって、ユーザＺＫロールアップ・アカウントを登録することができる。これは、登録バッチ６をＺＫロールアップに追加することによって行われることが可能である。登録バッチ６は、少なくとも、公開ＢＬＳ鍵、および対応する秘密鍵によるＢＬＳ鍵の署名を備える（図３）。署名は、やっかいな鍵攻撃を阻止する、各ユーザの公開ＢＬＳ鍵に対応する秘密鍵を各ユーザが知っていることを証明する。ユーザが新しいアカウントを登録したとき、アカウントにはアカウントＩＤ（例えばＬ２アドレス）が与えられ、アカウントＩＤは、新しいアカウント毎に増える整数でもよい。
【0090】
トークンをＺＫロールアップに預金するために、ユーザは、預金バッチ７（ユーザ・トークン預金トランザクション）を作成し、これを、預金バッチ７で指定されたトークンの量と一緒にＺＫロールアップ・スマート・コントラクト３に送らなければならない。預金バッチ７は、少なくとも、トークンを受け取る予定のアカウントＩＤ（Ｌ２アドレス）、トークンＩＤ（つまり、預金される予定のトークンの種類）、および種類毎のトークンの量（つまり、指定されたトークンＩＤのそれぞれに対応するもの）を指定する（図４）。ＺＫロールアップ・スマート・コントラクト３は、次いで、同じトランザクションでトークンの正しい金額を受け取ったことを検証し、預金バッチ７をＺＫロールアップに追加する。受取りＬ２アドレスは、預金を開始するユーザによって、または別のユーザによって所有可能である。
【0091】
図５（ａ）から図５（ｄ）は、ユーザが、ユーザＺＫロールアップ・ノード４、４’、４’’を介して、互いの間でトークンの振替をどのように開始できるかを示している。ユーザ間の振替は、アグリゲータＺＫロールアップ・ノード５を介してアグリゲータによって振替バッチ（アグリゲータ振替トランザクション）５１にアグリゲートされ、振替バッチ５１は、その後、ＺＫロールアップに追加される。
【0092】
ユーザは、コンピュータ・デバイス上のユーザＺＫロールアップ・ノード４にアクセスできるユーザ・オペレータとして、ここでは理解される。ユーザ・オペレータは、１人または複数の自然人またはソフトウェアであることが可能である。アグリゲータは、コンピュータ・デバイス上のアグリゲータＺＫロールアップ・ノード５にアクセスできるアグリゲータ・オペレータとして、ここでは理解される。アグリゲータ・オペレータは、１人または複数の自然人またはソフトウェアであることが可能である。
【0093】
トークンを別のユーザに送りたいと思っているユーザは、１つまたは複数の振替（ユーザ振替命令４３、４３’、４３’’）から成るトランザクションを作成し、これをアグリゲータ５に送ることができる（図５（ａ））。アグリゲータ５は、ユーザ・トランザクション４３、４３’、４３’’を受け取り、トランザクションのマークル木５２を作り、マークル・ルート５３およびユーザのトランザクションのマークル証明（つまり、ユーザのトランザクションがマークル木に含まれるという証明）を各ユーザ４、４’、４’’に送る（図５（ｂ））。図５（ｂ）では、第３のユーザ４’’はオフラインであり、マークル・ルートおよびユーザのマークル証明を受け取らない。アグリゲータ５からユーザ４、４’の包含証明を受け取ったユーザ４、４’は、ユーザ４、４’のＢＬＳ署名を使用して、トランザクション木ルート（つまり、マークル・ルート）に署名し、署名４４、４４’をアグリゲータ５に送り返す（図５（ｃ））。アグリゲータ５は、振替バッチ５１（アグリゲータ振替トランザクション、バッチをＺＫロールアップに追加することについての図２参照）を、ＺＫロールアップ・スマート・コントラクト３（ロールアップ・コントラクト）に送り、振替バッチ５１は、トランザクション木（マークル）ルート５３、ＢＬＳ集約済み署名５４（ユーザ署名４４、４４’から集約されたもの）、およびＢＬＳ（集約済み）署名５４に含まれるユーザのリスト５５から成る（図５（ｄ））。
【0094】
各送り手が、振替バッチ５１の中で送り手のトランザクションの包含証明を受け取ったので、トランザクション自体をオン・チェーンで公開する必要はなく、トランザクション木（マークル）ルートだけでよい。これは、全てのトランザクション・データをオン・チェーンで公開する他のロールアップより、本発明によるＺＫロールアップをデータ効率のよいものにする。
【0095】
ＺＫロールアップ・スマート・コントラクト３が新しいバッチ６、７、５１を受け取ったとき、ＺＫロールアップ・スマート・コントラクト３は、バッチ６、７、５１が正しいフォーマットを有することを検証するが、バッチ６、７、５１の内容の有効性、つまり、振替バッチ５１のＢＬＳ集約済み署名５４が正しいこと、または登録バッチ６の署名が正しいことを検証しない。これは、ＺＫロールアップが、有効バッチおよび無効バッチの両方を含むことができることを意味する。詳細には、ユーザ５５の指定されたリストによる振替バッチ５１の振替木（マークル）ルート５３の振替バッチ５１のＢＬＳ集約済み署名５４が正しい場合、振替バッチ５１は有効である。そうでなければ、振替ブロック５１は無効である。提供された署名が、対応する秘密鍵による提供された公開鍵の正しい署名である場合、登録バッチ６は有効である。ＺＫロールアップ内のあらゆる預金バッチ７が追加されるときに、ＺＫロールアップ・スマート・コントラクトによってこれらの預金バッチ７の有効性がチェックされるので、ＺＫロールアップ内のあらゆる預金バッチ７が有効である。
【0096】
ＺＫロールアップ・スマート・コントラクトによって各新しいＺＫロールアップ・バッチが追加されるときに、各新しいＺＫロールアップ・バッチを検証する代わりに、元のＺＫロールアップ・チェーンからの有効なバッチだけを含めることによって、ＺＫロールアップ・バッチの誘導されたチェーンがオフ・チェーンで計算される（図６）。このチェーンは、有効であると認められたチェーンと呼ばれる。
【0097】
有効であると認められたチェーンを計算すること：元のバッチ・ハッシュ３１、３１’は、Ｂｉ′で表され、有効であると認められたバッチ・ハッシュは、Ｂｉで表される。図６に示されたケースでは、（図６の左から右に）第１および第３のバッチは有効であり、その一方で、第２のバッチは無効である。元のバッチ・ハッシュ３１は、前の元のバッチ・ハッシュ３１のハッシュ、ならびに、有効バッチおよび無効バッチの両方を含む現在のバッチの内容をとることによって計算される。これらのハッシュ３１、３１’は、オン・チェーンでＺＫロールアップ・スマート・コントラクト３に格納されたものである。一方、有効であると認められたバッチ・ハッシュは、ここでは有効なバッチだけが含まれ、全ての無効バッチがスキップされることを除いて、元のバッチ・ハッシュ３１、３１’と同じ方式で計算される。
【0098】
振替バッチ５１の有効性をチェックするために、Ｌ２アドレスに対応する公開鍵が追跡される。詳細には、（Ｕｉと表された）ユーザＬ２アドレス（マークル）木のルート、および（Ｂｉと表された）有効であると認められたバッチ・ハッシュがオフ・チェーンで計算および維持される。
【0099】
登録バッチ６が有効である場合、新しい公開鍵が、Ｌ２アドレスの（マークル）木に追加される（図７）。
【0100】
有効な預金バッチ７または有効な振替バッチ５１が追加されたとき、有効な預金バッチ７または有効な振替バッチ５１は、前の有効であると認められたバッチ・ハッシュと一緒にハッシングされ、新しい有効であると認められたバッチ・ハッシュを形成する（図８）。
【0101】
無効バッチ（無効振替バッチ５１または無効登録バッチ６）が追加されたとき、Ｌ２アドレスのマークル木および有効であると認められたバッチ・ハッシュは変化しない（図９）。
【0102】
新しいバッチ６、７、５１をＺＫロールアップに追加するとき、新しい履歴ルート・ハッシュ３１、３１’を計算することを除いて、オン・チェーンで何も有効化されない。その代わりに、あらゆるユーザ４（図１０では例示的にＡｌｉｃｅとも名付けられている）が独自の残高を追跡し、特定の履歴ルート・ハッシュ３１、３１’においてユーザ４の残高が正しいというユーザ再帰的ＺＫ証明４６、４６’を計算する。ユーザが資金を送るか受け取るとき、残高がアップデートされ、新しい再帰的ＺＫ証明４６が生成され、古い再帰的ＺＫ証明４６’（図１０）を置き換える。
【0103】
ＺＫロールアップに追加された新しいバッチ６、７、５１毎に、各ユーザは、ユーザの残高をアップデートし、アップデートされた残高の新しい再帰的ＺＫ証明４６を計算することになる。詳細には、Ｂｉをｉ番目のバッチ・ハッシュ３１にし、ｘｉをＢｉにおけるユーザの残高にする。次いで、ＢＮにおけるユーザの残高が特定の値ｘＮであるという証明は、以下を証明する。
１．値ｘ′およびｘ′＝ｘＮー１という再帰的ＺＫ証明が存在する。
２．バッチＮ内のユーザからの全ての振替を減算し、バッチＮ内のユーザへの振替のセットを追加することによって、値ｘがｘ′から取得される。
３．上記の計算で使用されるバッチＮ内のユーザへの各振替が有効である、つまり、各送り手の残高が、振替後に非負であるという、再帰的ＺＫ証明が存在する。
１．値ｘ′およびｘ′＝ｘＮー１という再帰的ＺＫ証明が存在する。
２．バッチＮ内のユーザからの全ての振替を減算し、バッチＮ内のユーザへの振替のセットを追加することによって、値ｘがｘ′から取得される。
３．上記の計算で使用されるバッチＮ内のユーザへの各振替が有効である、つまり、各送り手の残高が、振替後に非負であるという、再帰的ＺＫ証明が存在する。
【0104】
Ｌ２（ＺＫロールアップ）アドレスおよびＬ１（ブロックチェーン）アドレスの両方が、振替バッチ５１における振替の受取人であることが可能である。しかし、ブロックチェーン（Ｌ１）アドレスへの振替は、対応する振替バッチ５１が追加されたとき、ＺＫロールアップ・スマート・コントラクト３によって処理されない。その代わりに、引出し関数がＺＫロールアップ・スマート・コントラクト３に実装され、ＺＫロールアップ・スマート・コントラクト３は、振替を処理するために誰からでも使用されることが可能である。さらに、ＺＫロールアップ・スマート・コントラクト３は、各ブロックチェーン（Ｌ１）アドレスに既にいくら引き出されたかについてのリストを格納することになる。
【0105】
引出し関数は、ＺＫロールアップに関与する誰からでもコールされることが可能であり、ブロックチェーン（Ｌ１）アドレスのリスト、ＺＫロールアップ内の各ブロックチェーン（Ｌ１）アドレスが受け取った金額、最近の元のバッチ・ハッシュＢｉ′３１、および、Ｂｉ′３１においてブロックチェーン（Ｌ１）アドレスが請求額を受け取ったというＺＫ証明を、入力としてとる（図１１）。
【0106】
ＺＫ証明は、最近のバッチ・ハッシュＢｉ′３１、ブロックチェーン（Ｌ１）アドレスのリスト、および、金額の対応するリストを公開入力としてとり、以下を証明する。
１．有効であると認められたとされるバッチ・ハッシュＢｉとされるもの、および、これが、Ｂｉ′３１に対応する正しい有効であると認められたバッチ・ハッシュであるというＺＫ証明が存在する。
２．リスト内のブロックチェーン（Ｌ１）アドレス毎に、有効であると認められたバッチ・ハッシュＢｉにおいてブロックチェーン（Ｌ１）アドレスが指定の金額を受け取ったというＺＫ証明が存在する。
１．有効であると認められたとされるバッチ・ハッシュＢｉとされるもの、および、これが、Ｂｉ′３１に対応する正しい有効であると認められたバッチ・ハッシュであるというＺＫ証明が存在する。
２．リスト内のブロックチェーン（Ｌ１）アドレス毎に、有効であると認められたバッチ・ハッシュＢｉにおいてブロックチェーン（Ｌ１）アドレスが指定の金額を受け取ったというＺＫ証明が存在する。
【0107】
引出し関数は、証明を検証し、提供された元のバッチ・ハッシュＢｉ′３１が、最近のバッチ・ハッシュのリスト内にあることをチェックし、受け取られた請求額をとること、およびコントラクト・ストレージ３２（ＺＫロールアップ・コントラクト・ステート）に格納された以前に引き出された金額を減算することによって与えられた額を、各ブロックチェーン・アドレスに振り替えることになる。
【0108】
要約すると、ブロックチェーン（Ｌ１）アカウントに資金を引き出すプロセスは、２つのステップから成る。第１のステップは、振替バッチ５１でブロックチェーン（Ｌ１）アドレスに資金を振り替えることである。第２のステップは、ＺＫロールアップ・スマート・コントラクト３内の引出し関数を呼び出すことであり、引出し関数は、引出しを実施することになる。
【符号の説明】
【0109】
３ ＺＫロールアップ・スマート・コントラクト
３１、３１’ 履歴ルート・ハッシュ／バッチ・ハッシュ
３２ ＺＫロールアップ・コントラクト・ステート／ストレージ
４、４’、４’’ ユーザＺＫロールアップ・ノード、ユーザ
４３、４３’、４３’’ ユーザ振替命令
４４、４４’ ユーザ署名
４６ 残高再帰的ＺＫ証明
５ アグリゲータＺＫロールアップ・ノード、アグリゲータ
５１、５１’ アグリゲータ振替トランザクション／振替バッチ
５２ ユーザ振替トランザクションのマークル木
５３ ユーザ振替トランザクションのマークル・ルート
５４ 集約済み署名
５５ ユーザＺＫロールアップ・アカウントのリスト
６ ユーザ登録トランザクション／登録バッチ
７ ユーザ・トークン預金トランザクション／預金バッチ
３１、３１’ 履歴ルート・ハッシュ／バッチ・ハッシュ
３２ ＺＫロールアップ・コントラクト・ステート／ストレージ
４、４’、４’’ ユーザＺＫロールアップ・ノード、ユーザ
４３、４３’、４３’’ ユーザ振替命令
４４、４４’ ユーザ署名
４６ 残高再帰的ＺＫ証明
５ アグリゲータＺＫロールアップ・ノード、アグリゲータ
５１、５１’ アグリゲータ振替トランザクション／振替バッチ
５２ ユーザ振替トランザクションのマークル木
５３ ユーザ振替トランザクションのマークル・ルート
５４ 集約済み署名
５５ ユーザＺＫロールアップ・アカウントのリスト
６ ユーザ登録トランザクション／登録バッチ
７ ユーザ・トークン預金トランザクション／預金バッチ
【図1】
【図2】
【図3】
【図4】
【図5A】
【図5B】
【図5C】
【図5D】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【外国語明細書】