rail Astro
DSN 2020 / BRB-only payment system
問題設定: オンライン決済に全取引の total order は必要なのか、という rail 側の根本疑問を立てる。決済では「同じ資産を二重に使わない」ことが本質で、DEX や汎用 smart contract のような全体順序は過剰かもしれない。
核心アイデア: 各クライアントに exclusive log を持たせ、同じ sequence number の二重支払いだけを reliable broadcast で検出する。全員が全取引を同じ順序で見る必要を捨てる。
技術構成: Byzantine reliable broadcast、client-local sequence、double-spend detection。ブロックチェーンというより「支払い専用の分散オブジェクト」として設計される。
前進点: broadcast だけで高スループット・低遅延の決済 rail が成立することを示し、FastPay/Zef/PaxPay の思想的土台になった。
限界: privacy なし、regulation なし、permissioned committee 前提。shared account や複雑な状態遷移も主対象ではない。
後続への意味: PaxPay を理解するには、まず「決済は consensus から切り離せる」という Astro/FastPay の発想が必要。
rail FastPay
AFT 2020 line / low-latency asset transfer
問題設定: 汎用 blockchain consensus を使わず、asset transfer だけに特化すれば、どこまで高速化できるか。
核心アイデア: single-owner account の支払いは所有者が順序を決めればよい。validators は owner-local ordering と quorum validation を行い、全体 consensus を避ける。
技術構成: owner-signed transfer、validator quorum、spent certificate、client-driven finality。決済は「全体状態」ではなく「各所有者の支出系列」として扱われる。
前進点: payment rail を general-purpose ledger から分離し、低遅延 transfer object として定式化した。
限界: privacy、regulation、shared account は扱わない。高速性は single-owner という単純化に依存する。
後続への意味: Zef は FastPay に privacy を載せ、PaxPay はさらに regulation を載せる。
rail CryptoConcurrency
CCS 2023 / shared account extension
問題設定: FastPay 型は single-owner には強いが、企業 treasury、共同口座、multi-device wallet、escrow のような shared account では競合が起きる。
核心アイデア: 平時は consensus を避け、overspending や競合が起きる時だけ account-local consensus を呼ぶ。全体 consensus ではなく「問題が起きた口座だけ」を調停する。
技術構成: conflict-free path、owner-specific fallback consensus、shared account semantics。競合処理を localize する点が中心。
前進点: consensus-free rail を現実の資金管理モデルに近づけた。payment rail 側の未解決である shared account + privacy の直接の土台。
限界: privacy なし。conflict が起きたこと自体が observable で、private conflict resolution は未解決。
後続への意味: 次の研究テーマは Private CryptoConcurrency。Zef/PaxPay の privacy と CryptoConcurrency の shared state を接続すること。
privacy Zef
WPES 2023 / FastPay + Coconut
問題設定: FastPay は速いが透明すぎる。低遅延・高スループットの rail に匿名性と unlinkability を載せられるか。
核心アイデア: Coconut 系 threshold anonymous credential によって、validator が正当性を署名しつつ coin を opaque にする。FastPay 型の quorum validation を保ったまま、支払い内容を秘匿する。
技術構成: threshold credentials、blind issuance、opaque coin、FastPay-style validation。privacy coin ではなく payment rail の上に privacy を後付けする設計。
前進点: consensus-free rail × privacy の最初の重要な合流点。PaxPay の直接の前段。
限界: regulation がない。PaxPay 側の批判では、coin 作成者が追跡できる余地など privacy 強度にも改善余地がある。
後続への意味: Zef が「fast + private」を作り、PaxPay が「fast + private + regulated」に進む。
rail Pastro
2023 / permissionless asynchronous asset transfer
問題設定: Astro/FastPay 的な asset transfer を permissioned committee ではなく open environment に拡張できるか。
核心アイデア: 非同期 asset transfer の安全性を、固定委員会より開いた参加モデルで扱う方向へ進める。
技術構成: asynchronous transfer、open participation、asset-specific validation。privacy や compliance ではなく permissionless 化が主眼。
前進点: payment rail の実配備に近い「誰が validator か固定できない」問題へ進んだ。
限界: regulated-private payment の主課題、つまり KYC/AML と privacy の同居は未解決。
後続への意味: PaxPay 系を permissionless 化する時、execution committee と compliance committee を分ける研究の比較対象になる。
regulated PRCash
FC 2019 / speed + privacy + regulation
問題設定: 匿名送金と規制遵守は両立不能なのか。CBDC/regulated payment では、ユーザー privacy を守りつつ KYC や上限規制を満たす必要がある。
核心アイデア: per-transaction limit、cumulative limit、KYC 条件を ZK proof で enforce し、ユーザーの identity や詳細履歴は隠す。
技術構成: ZK range/statement proof、regulated account、limit enforcement。後続と比べると primitive は粗いが、問題設定が重要。
前進点: 「制約付き匿名送金」という regulated-private payment の基本問題を明示した起点。
限界: PaxPay/PEReDi/DART と比べると、非同期 rail、権限分散、audit semantics、実装評価が弱い。
後続への意味: holding limit や cumulative limit の議論は PRCash から PaxPay まで続く。
regulated PEReDi
CCS 2022 / threshold CBDC tracing
問題設定: 中央銀行 CBDC に現金的 privacy を持たせつつ、違法行為には規制当局が対応できるようにする。
核心アイデア: Coconut/Pointcheval-Sanders 系 threshold blind signature と encrypted ledger を使い、通常時は匿名、必要時は threshold quorum で open/trace できる。
技術構成: maintainer committee、threshold issuance、simulatable tracing tag、per-tx/cumulative limit、UC-style CBDC functionality。
前進点: regulated-private CBDC の canonical reference。full privacy だけでなく、開示権限の閾値化を制度設計として扱った。
限界: receiver が対話的で、支払い rail としては重い。validator privacy 仮定も PaxPay より強い。
後続への意味: PaxPay の self-provable history と対比すると、PEReDi は「当局による tracing」を重視する設計。
regulated Platypus
CCS 2022 / split-trust CBDC
問題設定: CBDC の監督権を単独主体に置くと、privacy 侵害や権限濫用が起きやすい。開示権限をどう分割するか。
核心アイデア: 中央銀行と規制当局の split trust。通常時は e-cash 的 unlinkability を保ち、違反時だけ複数権限で開示する。
技術構成: account/e-cash hybrid、unlinkable transfer、multi-authority oversight。PEReDi と同時期の別トポロジー。
前進点: 「誰が開示できるのか」をプロトコル設計の中心に置いた。規制対応 privacy の trust topology を豊かにした。
限界: payment rail の高速化や非同期性は主眼ではない。PaxPay ほど性能評価も前面にない。
後続への意味: bounded oversight や judge-gated opening の設計で参照すべき。
regulated PARScoin
Preprint 2023 / stablecoin + reserve audit
問題設定: 民間 stablecoin では、規制の焦点はユーザー追跡だけでなく、発行量が準備資産を超えていないかという reserve audit に移る。
核心アイデア: transfer と claim を分けて receiver 非対話化を実現し、auditability を supply/reserve の健全性として再定義する。
技術構成: threshold issuer、ElGamal 系暗号、sigma protocol、range proof、claim database、proof of burn、reserve audit。
前進点: CBDC から regulated stablecoin へ問題設定を移し、issuer/custodian/auditor の三者構造を明示した。
限界: honest validator 仮定が重い。PEReDi 的な user tracing は後退し、PaxPay のような fast rail benchmark も弱い。
後続への意味: DART の multi-asset tokenization と PaxPay の compliance coin をつなぐ中間点。
regulated DART
ePrint 2025 / tokenization + affirmation
問題設定: RWA や証券トークン化では、単に匿名送金できるだけでは足りない。受取確認、巻き戻し、asset-specific auditor、proof of balance が必要になる。
核心アイデア: account state を finalized balance と pending balance に分け、receiver affirmation / reverse を組み込む。各 asset には issuer が指定する auditor を持たせる。
技術構成: commitment/nullifier、accumulator、threshold blind re-randomizable signatures、key-private encryption、per-asset auditor、multi-party transaction。
前進点: regulated-private payment を multi-asset tokenization / RWA settlement まで拡張した最も機能豊富な設計。
限界: 機能豊富なぶん複雑で、low-latency payment rail としては重い。single auditor 前提も制度的に議論が残る。
後続への意味: PaxPay compliance coin を multi-asset world に一般化する時の主要比較対象。
合流点 PaxPay
AFT 2025 / async + full privacy + regulation
問題設定: FastPay/Zef 的な asynchronous rail を捨てずに、full privacy と regulation enforcement を同時に満たせるか。
核心アイデア: 通常 coin に加えて compliance coin を導入する。compliance coin はユーザーの累計送金額と履歴 commitment を保持し、送金ごとに古いものを消費して新しいものへ更新する。
技術構成: coin-based UTXO、Groth16、threshold blind signature、MiMC、incremental commitment、SancList non-membership、π_transfer + π_comply の統合 proof。
前進点: consensus-free rail、full privacy、sanctions、per-tx/cumulative limit、provable transaction history を一つにまとめた。semi-honest validator が adversary と情報共有しても privacy を保つ点が強い。
限界: holding limit 未対応、prover が重い、Groth16 trusted setup、full tracing ではなく user self-proof 型。法域によっては当局側の直接追跡要求と合わない可能性がある。
後続への意味: このHTMLの中心。次の研究は holding limit、bounded oversight、shared account privacy、offline reconciliation。
別系統 NickPay
2025 / auditable-private payment on Ethereum
問題設定: Ethereum 型の既存 smart contract 環境で、private payment と auditability をどう同居させるか。
核心アイデア: group signature と stealth address により、送受信の unlinkability と必要時の監査を両立する。
技術構成: group signatures、stealth addresses、smart-contract payment flow。PaxPay のような consensus-free rail ではなく、EVM 上での auditable privacy が主眼。
前進点: regulated-private payment の別解として、Ethereum 配備可能性を前面に出す。
限界: rail innovation は弱く、性能前提は EVM に縛られる。
後続への意味: PaxPay 型 rail と EVM composability をつなぐ時の比較対象。
CBDC RSCoin
NDSS 2016 / central-bank digital currency ancestor
問題設定: 中央銀行が monetary policy を保持したまま、分散台帳でスケーラブルなデジタル通貨を作れるか。
核心アイデア: 中央銀行が発行権を持ち、mintette と呼ばれる shard-like validators に transaction processing を委譲する。
技術構成: central bank + mintettes、sharded validation、accountability。privacy より CBDC scalability が主眼。
前進点: CBDC を学術的に分散システムとして扱った初期の重要論文。
限界: privacy は弱く、regulated-private payment の暗号機能はまだない。
後続への意味: PEReDi/Platypus 以降の「中央銀行 + 分散処理 + 規制権限」の祖先。
CBDC Rayls
2025 / bank-ledger federation + private CBDC
問題設定: 中央銀行単一台帳ではなく、商業銀行ごとの private ledger を連邦的に接続して CBDC を運用できるか。
核心アイデア: 各銀行が Privacy Ledger を持ち、中央銀行側の commit chain へ接続する。銀行間匿名送金を ZK/暗号プロトコルで扱う。
技術構成: bank-specific privacy ledger、commit chain、Enygma、ZK-SNARK、post-quantum key exchange 方向。
前進点: regulated-private CBDC を単一台帳から既存銀行インフラ統合へ拡張した。
限界: 信頼前提は銀行連邦に寄る。open/payment-rail innovation とは別方向。
後続への意味: 実配備志向の private CBDC と PaxPay 型暗号設計の接点を考える材料。
CBDC Aegis
2025 / scalable privacy CBDC + dynamic proof of liabilities
問題設定: privacy-preserving CBDC にスケーラビリティと発行体健全性の動的監査を同時に入れられるか。
核心アイデア: CP-SNARK などで transaction batching を行い、proof of liabilities を動的に統合する。
技術構成: batching proof、commitment-based accounting、smart-contract verification、dynamic liability proof。
前進点: regulated-private payment を「個別送金の匿名性」だけでなく issuer/liability audit へ広げる。
限界: payment rail の非同期性や receiver UX は中心ではない。
後続への意味: PARScoin の reserve audit と PaxPay の compliance coin をつなぐ audit layer として読める。
offline Project Hamilton
USENIX NSDI 2023 / high-performance CBDC processor
問題設定: CBDC transaction processor はどれくらい高性能にできるか。privacy 以前に、国レベル retail payment のスループットが必要。
核心アイデア: UTXO 的な transaction processing を高性能分散システムとして実装・評価する。
技術構成: high-throughput transaction processor、parallel validation、CBDC-specific architecture。
前進点: CBDC の性能基準を引き上げ、privacy paper の benchmark を評価する物差しを与える。
限界: privacy / regulation / offline は主眼ではない。
後続への意味: PaxPay の 925 tx/s などの数値を現実の CBDC processor 文脈で比較する時に必要。
offline Project Tourbillon
BIS 2023 / privacy, security, scalability for CBDC
問題設定: 実際の central-bank prototype で、payer anonymity、scalability、quantum-safe crypto をどう組み合わせるか。
核心アイデア: payer anonymity を中心に、複数プロトタイプで privacy/security/scalability の trade-off を評価する。
技術構成: e-cash-like withdrawal/payment、denomination design、quantum-safe variant、central-bank prototype。
前進点: 学術論文だけでなく、中央銀行実験として privacy payment の現実制約を示す。
限界: DeFi composability や permissionless rail は扱わない。設計は制度側に寄る。
後続への意味: offline/retail CBDC の需要と制約を評価する実務側の基準点。
offline PayOff
2024 / regulated CBDC with private offline payments
問題設定: payer/payee がネットワークから切断されていても、private かつ regulated な CBDC 支払いを行えるか。
核心アイデア: offline token lifecycle と fraud/double-spend handling を設計し、再接続時に不正検出と規制対応を行う。
技術構成: offline token、secure hardware/credential、double-spend evidence、regulated reconciliation。
前進点: offline privacy payment を現金代替として真正面から扱う。
限界: offline はどうしても hardware trust、revocation lag、再同期 semantics に難が残る。
後続への意味: PaxPay 型 async rail と統合するなら、offline-to-online reconciliation の直接の比較対象。
offline Secure-Element Offline CBDC
2024 / secure and privacy-preserving offline payments
問題設定: スマートカードや secure element を使えば、offline payment の double-spending と privacy を現実的に両立できるか。
核心アイデア: secure element が offline spending authorization を担い、payee は限られた情報だけで token validity を確認する。
技術構成: secure element、offline authorization、fraud tracing、lightweight cryptographic verification。
前進点: offline CBDC を実装制約のある端末で動かす方向へ進めた。
限界: hardware trust が強い。端末故障、鍵漏洩、強要、更新不能状態が残る。
後続への意味: privacy rail 研究で hardware trust をどこまで許すかの境界線を与える。
audit Sander-TaShma
CRYPTO 1999 / auditable anonymous e-cash
問題設定: e-cash は匿名であるべきだが、総額や発行量の監査はできるべき。この二つをどう両立するか。
核心アイデア: anonymous e-cash に auditability を組み込み、ユーザー匿名性と金額整合性を切り分ける。
技術構成: blind-signature 系 e-cash、public log、audit mechanism。
前進点: auditable anonymous payment の古典的出発点。
限界: pre-blockchain 文脈で、現代の smart contract や distributed ledger は前提にない。
後続への意味: zkLedger、PARScoin、Aegis の supply/reserve audit 系に思想がつながる。
audit Solidus
CCS 2017 / confidential distributed ledger
問題設定: 銀行仲介型の分散台帳で、取引グラフと金額を隠しながら整合性を検証できるか。
核心アイデア: 銀行が顧客口座を privacy-preserving data structure として管理し、公開検証可能な形で transfer を処理する。
技術構成: PVORM/ORAM、confidential ledger、bank-mediated transfer。
前進点: privacy-preserving ledger を銀行モデルで現実的に扱った重要論文。
限界: ORAM 系は重く、permissionless/open rail には直接乗りにくい。
後続への意味: CBDC/銀行台帳連邦の Rayls などと比較すると、bank-mediated privacy の祖先として読める。
audit zkLedger
NSDI 2018 / privacy-preserving auditing for ledgers
問題設定: 金融機関間の台帳で、個別取引は秘匿しながら監査者が総量・整合性を検証できるか。
核心アイデア: commitments と NIZK によって、各参加者の残高・取引を隠しつつ、監査可能な table-of-commitments を構成する。
技術構成: Pedersen commitments、NIZK、table-wide audit、confidential transaction accounting。
前進点: auditable ledger の標準形を作った。個別開示ではなく aggregate audit という方向を明確にした。
限界: table 全体の更新・証明が重く、retail payment rail には直接向かない。
後続への意味: PARScoin/Aegis の reserve/liability audit、Rayls の銀行私的台帳に接続する。
audit Fabric Auditable Tokens
AFT 2020 / permissioned auditable anonymous tokens
問題設定: Hyperledger Fabric のような permissioned 環境で、匿名 token と issuer/auditor の監査権限をどう組み合わせるか。
核心アイデア: anonymous credentials と ZK を使い、permissioned consortium の中で private かつ auditable な token transfer を実現する。
技術構成: Pointcheval-Sanders signatures、ZK proofs、Fabric integration、issuer/auditor keys。
前進点: enterprise/permissioned blockchain に private token を載せる具体設計。
限界: issuer 信頼が強く、permissionless private rail とは別物。
後続への意味: CBDC/regulated stablecoin の consortium deployment を考える時の実装寄り基盤。
audit UTT
2022 / decentralized e-cash with accountable privacy
問題設定: decentralized e-cash で、ユーザー privacy と budget/accountability を両立できるか。
核心アイデア: KVAC/re-randomizable credential 系で、匿名支払いと budget tracing を組み合わせる。
技術構成: KVAC、re-randomizable signatures、budget mechanism、distributed validation。
前進点: Zef/PaxPay の比較表にも現れる、privacy + accountability + performance の重要ベースライン。
限界: PaxPay と比べると検証コストや regulation feature の粒度で差がある。
後続への意味: PaxPay の throughput/verification advantage を評価する比較対象。
audit ASOZ
2023 / anonymous and auditable cryptocurrency
問題設定: Zerocash 級の強い匿名性を保ちながら、監査者が必要時に取引相手と金額を確認できるか。
核心アイデア: global mixing と full transaction audit を組み合わせる。強い匿名性と強い監査権限を同時に置く設計。
技術構成: Twisted ElGamal、ElGamal、NIZK/Sigma、zk-SNARK、offline audit。
前進点: 「匿名性は強いが監査者には全件見える」という extreme point を提示。
限界: auditor 権限が強すぎる。bounded oversight の観点では危険。
後続への意味: PEReDi/PaxPay/AuditPay と比較して、監査権限をどこまで制限すべきかを考える材料。
audit AuditPay
2026 / anonymous payments with controlled oversight
問題設定: 規制当局に追跡権限を与えるとしても、無制限監視は避けたい。監査の回数・対象・条件を暗号的に制限できるか。
核心アイデア: 監査者が epoch ごとに追跡できる対象数を制限し、監視対象集合自体も秘匿する controlled oversight。
技術構成: selective encryption、oblivious audit-key vector、audit budget、anonymous payment layer。
前進点: full tracing vs no tracing の二択を超えて、bounded oversight という研究方向を明確にした。
限界: mixer/Tornado 型の前提が強く、PaxPay rail にそのまま載るわけではない。
後続への意味: Bounded Oversight PaxPay の直接素材。
audit UC Auditable Surveillance
2023 / judge-gated threshold surveillance
問題設定: key escrow や lawful access は濫用されやすい。令状付き・監査可能・閾値化された surveillance を形式化できるか。
核心アイデア: UC ideal functionality として auditable surveillance を定義し、裁判官署名・閾値復号・監査証跡を組み合わせる。
技術構成: threshold encryption、YOSO MPC、ZK warrant verification、audit trail。
前進点: judge-gated opening を形式的に扱うための道具を提供。
限界: payment-specific ではなく汎用 lawful access。支払い上限や sanctions とは別途統合が必要。
後続への意味: PaxPay/PEReDi の中間、つまり statement-specific opening を設計する時の形式化材料。
ancestor Zerocoin / Zerocash
S&P 2013/2014 / decentralized anonymous payments
問題設定: Bitcoin の透明 UTXO から、送信者・受信者・金額を隠す decentralized anonymous payment を作れるか。
核心アイデア: commitment tree と nullifier によって「有効な coin を消費した」ことだけを ZK で証明する。
技術構成: note commitment、Merkle membership、nullifier、zk-SNARK、shielded pool。
前進点: private payment の暗号パターン、つまり commitment + nullifier + ZK の標準形を作った。
限界: 初期 Zcash は trusted setup と opt-in privacy の問題を抱えた。regulation は設計外。
後続への意味: DART、PaxPay、MASP、Aztec、Privacy Pools などの根底にある。
ancestor CryptoNote / RingCT / Monero
2013-2024 / ring signature privacy line
問題設定: trusted setup なしで、送信者・受信者・金額を隠す実用的な private cash を作れるか。
核心アイデア: ring signature で送信者を k-anonymity に隠し、stealth address で受取人を隠し、RingCT/Bulletproofs で金額を隠す。
技術構成: linkable ring signatures、key images、Pedersen commitments、range proofs、CLSAG、Triptych/FCMP++ 方向。
前進点: default-private payment の実運用例として最重要。privacy demand の実証でもある。
限界: regulation hooks が弱い。匿名集合はデコイ選択や network/app-layer leakage に依存する。
後続への意味: PaxPay とは逆に「規制より cash-like privacy」を優先する参照点。
ancestor Zether
2020 / account-based confidential payments for smart contracts
問題設定: Ethereum 的 account model で、残高・送金額・送受信者を隠せるか。
核心アイデア: account balances を Pedersen commitment として持ち、ring-style anonymity と ZK proof で送金を検証する。
技術構成: account commitments、range proof、Sigma/Bulletproof-style proof、epoch-based update。
前進点: UTXO ではなく account model の confidential payment を示した。
限界: sender は epoch あたり制約を受け、証明は anonymity set に依存して重い。regulation はない。
後続への意味: PEReDi/PARScoin/DART が account model と concurrency 問題を議論する時の比較対象。
ancestor Quisquis
2019 / updatable public keys + account anonymity
問題設定: UTXO と account の中間で、アカウントを更新しながら匿名性を保てるか。
核心アイデア: updatable public keys により、取引ごとに account representation を変え、linkability を抑える。
技術構成: re-randomizable public keys、confidential transaction、anonymity set proof。
前進点: account-oriented privacy payment の別系統を提示。
限界: anonymity set サイズに依存し、PaxPay のような regulation/rail 統合はない。
後続への意味: DART/PARScoin が比較対象にする account privacy primitive。
ancestor Mimblewimble
2016/2019 / CT + cut-through
問題設定: 金額秘匿と blockchain size 削減を同時に達成できるか。
核心アイデア: Confidential Transactions と cut-through により、中間 UTXO を削除しつつ金額整合性を検証する。
技術構成: Pedersen commitments、range proofs、kernel excess、interactive transaction construction、cut-through。
前進点: privacy と scalability を同時に狙う別アプローチ。transaction graph を構造的に薄くする。
限界: 送受信者匿名性は Zerocash ほど直接的ではなく、interactive TX と network leakage が課題。
後続への意味: payment rail の「履歴をどこまで残すべきか」という設計軸で重要。
ancestor Lelantus / Spark
2019 / FC 2022 / trusted-setup-free anonymity set
問題設定: trusted setup なしで、大規模 anonymity set と confidential payment を実用化できるか。
核心アイデア: serial-number based spend と sigma-style proof で、coin mint/spend の unlinkability を提供する。Spark は address/viewing key/UX を強化する。
技術構成: one-out-of-many proof、serial number、commitment、Spark address/viewing mechanism。
前進点: Zcash と Monero の中間にある、trusted setup 不要の shielded pool 系。
限界: regulation rail ではなく privacy coin 設計。採用率と set quality が効く。
後続への意味: PaxPay 論文でも比較対象に出る privacy baseline。
compliance Privacy Pools
2023 / association sets + self-certification
問題設定: mixer/shielded pool を全面禁止せず、ユーザーが「自分の資金は汚染集合に属さない」と証明できるか。
核心アイデア: association set / dissociation set を ZK proof に組み込み、ユーザーが資金源泉について必要な statement だけを示す。
技術構成: Merkle membership/non-membership、nullifier、association set、self-certification proof。
前進点: permissionless DeFi における compliance-aware privacy の代表。
限界: set curator と set quality の政治性が残る。payment rail 自体を高速化するものではない。
後続への意味: PaxPay の provable transaction history と同じく、ユーザー自己証明型 compliance の重要系譜。
offline Two-Tier Offline CBDC
2020 / two-tier offline retail CBDC
位置づけ: offline CBDC を中央銀行と仲介機関の two-tier model で考える初期重要論文。
焦点: offline transferability、double-spend detection、仲介機関の役割分担。
このHTMLでの意味: PayOff / secure-element CBDC の前史として、offline payment が制度アーキテクチャ問題でもあることを示す。
offline DOTM
2022 / dual offline transaction model
位置づけ: offline CBDC を単なる端末間送金ではなく、online/offline の二重モードで設計する流れ。
焦点: offline token の流通、再接続時の整合性、支払い失敗時の処理。
このHTMLでの意味: PaxPay 型 async rail と offline rail を統合する時の mode-switching 参考資料。
offline Balancing Compliance and Privacy in Offline SE
2025 / secure element + compliance/privacy balance
位置づけ: secure element 依存の offline CBDC で、privacy と compliance の両立点を細かく探る。
焦点: offline spending limit、sanctions/revocation lag、端末信頼、規制当局に何を見せるか。
このHTMLでの意味: offline compliance の比較軸を作る時に必須。
offline Privacy-Compliance Design for Offline CBDC
TNSM 2025 / offline CBDC design
位置づけ: offline CBDC のプライバシー保護とコンプライアンス要件を設計論として整理する論文。
焦点: offline identity privacy、二重支払い、監査、端末管理。
このHTMLでの意味: PayOff と secure-element 系を比較する中間サーベイ的材料。
CBDC CBDC Composable Treatment
2023 / UC formulation for CBDC
位置づけ: CBDC を UC/形式的モデルで扱い、匿名性と脱税対策を同時に議論する。
焦点: ideal functionality、income transparency、Chaum 型 e-cash 的構成。
このHTMLでの意味: PaxPay/PEReDi の機能リストを formal model に落とす際の参照。
CBDC How to Issue CBDC
Chaum line 2021 / e-cash CBDC
位置づけ: Chaum 型 e-cash を CBDC 発行に戻す設計系譜。
焦点: cash-like privacy、中央発行、double-spend control、軽量支払い。
このHTMLでの意味: trust-minimized e-cash や Tourbillon と合わせて「古典 e-cash 回帰」を整理する材料。
CBDC Kaime
2024 / modular privacy for CBDC
位置づけ: CBDC privacy を単一方式ではなく modular component として設計する方向。
焦点: privacy layer、audit layer、policy layer の分離。
このHTMLでの意味: PaxPay の rail/compliance plane separation を拡張する設計思想。
CBDC Gross-Sedlmeir Cashlike Privacy
2021 / cash-like privacy for CBDC
位置づけ: CBDC が現金代替になるには、どの privacy property が必要かを整理する。
焦点: cash-like privacy、central bank visibility、retail usability、offline needs。
このHTMLでの意味: 技術論文を需要側から評価する基準。
CBDC Rayls II
2025 / private compliant CBDC iteration
位置づけ: Rayls の改良版。銀行別 privacy ledger と compliant CBDC を本番志向に近づける。
焦点: bank identifier privacy、ZK optimization、quantum-private direction。
このHTMLでの意味: Rayls を単発でなく実装系譜として扱うための後続。
CBDC PQC-DLT CBDC Feasibility
2024 / post-quantum CBDC feasibility
位置づけ: CBDC/DLT の耐量子移行を実装評価する流れ。
焦点: NIST PQ signatures、hybrid signature、Besu/SGX、DREX 文脈。
このHTMLでの意味: Groth16/Coconut 依存の PaxPay 系が将来 PQ 対応で抱える gap を示す。
CBDC Fabric-X
2026 / scaling Hyperledger Fabric for CBDC
位置づけ: permissioned ledger を高スループット CBDC 基盤へ拡張する実装寄り論文。
焦点: Fabric performance、resilience、transparent/high-throughput CBDC。
このHTMLでの意味: privacy-heavy protocol と enterprise CBDC processing の性能差を見る基準。
CBDC CBDC Cross-Border Layer2
2023 / cross-border CBDC L2
位置づけ: CBDC を国内 retail だけでなく cross-border settlement に拡張する。
焦点: L2 architecture、jurisdiction boundary、interoperability。
このHTMLでの意味: cross-jurisdiction compliance の未解決問題を具体化する材料。
CBDC UCoin
TDSC 2023 / privacy cryptocurrency/CBDC adjacent
位置づけ: privacy-preserving cryptocurrency/CBDC 系の中間的設計。
焦点: privacy transfer、regulated currency architecture、accountability。
このHTMLでの意味: CBDC と privacy coin の境界にある設計例として扱う。
CBDC PPChain
2021 / permissioned blockchain CBDC
位置づけ: permissioned blockchain 上の privacy-preserving payment/CBDC 系。
焦点: consortium operation、privacy、auditable processing。
このHTMLでの意味: Fabric/Rayls と同じ permissioned deployment 系の補完。
CT PGC
ESORICS 2020 / practical confidential payment with audit
位置づけ: decentralized confidential payment と auditor-friendly decryption の代表。
焦点: Twisted ElGamal、Bulletproofs、auditor key。
このHTMLでの意味: ASOZ/zkLedger/UTT と並ぶ auditable confidential transfer の基盤。
shielded Aztec Connect
2022 / private DeFi bridge/application layer
位置づけ: payment privacy を DeFi application access に接続した実装例。
焦点: shielded account、DeFi interaction、rollup bridge、UX と shutdown lessons。
このHTMLでの意味: private rail adapter for DeFi の先行実装として重要。
shielded MASP
Anoma/Namada 2022 / multi-asset shielded pool
位置づけ: Zerocash 型 note commitment を multi-asset に拡張する代表。
焦点: asset-type privacy、multi-asset notes、shielded pool UX。
このHTMLでの意味: DART/PaxPay の multi-asset privacy と比較する基盤。
CT Confidential Assets
2019 / asset-type and amount confidentiality
位置づけ: 金額だけでなく asset type も隠す confidential transfer の基礎。
焦点: Pedersen commitments、asset tags、multi-asset CT。
このHTMLでの意味: DART の asset-type privacy や MASP の先祖として重要。
CT Solana Confidential Transfer
2024 / Token-2022 confidential balances
位置づけ: 高速 public chain の token 標準に confidential transfer を入れる実装系。
焦点: encrypted balances、auditor/decryptor role、ZK proof、wallet/SDK constraints。
このHTMLでの意味: PaxPay 型専用 rail と L1 token standard 型 privacy の対比。
CT XRPL Confidential Transfers
2026 / confidential MPTs on XRPL
位置づけ: 既存決済 ledger に金額秘匿を追加する現実寄りの設計。
焦点: EC-ElGamal、NIZK、supply transparency、selective disclosure。
このHTMLでの意味: payment rail 既存インフラ統合の比較対象。
async ePAss
2025 / asynchronous private payment
位置づけ: async private payment という PaxPay 近傍の未収録重要候補。
焦点: asynchronous transfer、privacy、receiver availability。
このHTMLでの意味: PaxPay/Zef と並べて rail + privacy の最近接 baseline として扱うべき。
token BAT
2026 / cryptocurrency-backed anonymous tokens
位置づけ: 既存 cryptocurrency を backing として匿名 token を発行する系譜。
焦点: backing proof、anonymous token issuance、redeemability。
このHTMLでの意味: trust-minimized e-cash と regulated stablecoin の中間に置ける。
CT Merces
2026 / confidential transfers with MPC/coSNARK
位置づけ: MPC と coSNARK を使って confidential transfer の proving/verification を分散化する方向。
焦点: collaborative proving、confidential balance update、scalability。
このHTMLでの意味: PaxPay の heavy prover 問題を分散 proving で解く可能性の比較対象。
account NIZK Account Model
TDSC 2021 / account-model private payments
位置づけ: UTXO ではなく account model で private payment を構成する研究。
焦点: account balance privacy、NIZK、double-spend/replay prevention。
このHTMLでの意味: Zether/Quisquis/DART の account privacy 系に接続。
account BlockMaze
TDSC 2022 / account-model privacy
位置づけ: account-based privacy payment の別設計。
焦点: account anonymity、confidential transfer、transaction graph hiding。
このHTMLでの意味: account model private payments の比較母集団を増やす。
CT PRIDE
2023 / forward-secure confidential transfer line
位置づけ: confidential transfer に forward secrecy や長期鍵漏洩耐性を入れる方向。
焦点: forward secrecy、epoch update、receiver offline handling。
このHTMLでの意味: payment privacy を「現在の匿名性」だけでなく将来漏洩耐性で評価するために必要。
DP Verifiable Local DP Transactions
2023 / verifiable local differential privacy
位置づけ: 個別取引を秘匿しつつ、統計利用のために検証可能な local DP を入れる方向。
焦点: local randomization、ZK correctness proof、central-bank/statistical use。
このHTMLでの意味: privacy payment の需要が「匿名送金」だけでなく政策統計にもあることを示す。
Zether Many-out-of-Many Zether
2021 / Zether scalability variant
位置づけ: Zether の anonymity set / account update コストを改善する方向。
焦点: many-out-of-many proof、account anonymity、proof compression。
このHTMLでの意味: account-model privacy の性能改善系として補完。
exchange Private Atomic Exchange on ZK Ledger
2019 / private atomic exchange
位置づけ: private payment を交換・settlement に拡張する初期研究。
焦点: atomicity、confidential balances、ledger audit。
このHTMLでの意味: private payment rail と DeFi/DEX adapter の古い接点。
notes Evolving Nullifiers
ePrint 2025 / note model refinement
位置づけ: note/nullifier モデルの進化形。shielded state の細部設計に関わる。
焦点: evolving nullifiers、note lifecycle、linkability reduction。
このHTMLでの意味: PaxPay/DART の coin/account state をより柔軟にする設計材料。
ecash GNU Taler
2019 / taxable anonymous e-cash
要点: payer privacy と merchant/receiver accountability を分離する実用 e-cash。税務・商取引に寄った匿名決済の代表。
意味: regulated-private payment の需要が「匿名 payer + 監査可能 merchant」にあることを示す。
ecash Trust-Minimized eCash
2024 / modular chain add-on e-cash
要点: Chaum 型 e-cash を既存チェーンに 1:1 backed issuance として載せる。
意味: PaxPay より単純な self-custody e-cash / backing transparency の比較対象。
ecash Transferable eCash Cleaner
PKC 2021 / transferable e-cash
要点: 受け取った e-cash をさらに transfer できる transferable e-cash の効率化。
意味: offline transferable CBDC と直接接続する古典暗号側の基盤。
ecash Compact Divisible eCash
PoPETs 2023 / divisible e-cash
要点: e-cash を細かい額面に分割可能にしつつ、証明・wallet サイズを抑える。
意味: exact amount payment と offline usability の基盤。
ecash OCash
PKC 2025 / light-client e-cash
要点: light client が扱いやすい e-cash を目指す。
意味: PaxPay の mobile prover cost 問題を考える時に重要。
ecash Blind Multisig Anonymous Tokens
2024 / threshold issuance
要点: blind multisignature で匿名 token の分散発行を扱う。
意味: Coconut/PS-sig/PaxPay の threshold issuance と比較すべき。
ecash Non-Transferable Anonymous Tokens
2025 / privacy token with non-transferability
要点: 匿名性を持たせつつ譲渡不能性を入れる。
意味: credential と money の境界、KYC credential/payment credential の分離に関わる。
ecash Everlasting Anonymous Rate-Limited Tokens
2025 / rate-limited anonymous tokens
要点: 匿名性を保ったまま利用頻度・発行量を制限する。
意味: PaxPay の cumulative limit / holding limit の credential 版として重要。
ecash Lattice Threshold Blind Signatures
2025 / post-quantum blind issuance
要点: threshold blind signature を lattice/PQ 方向へ移す。
意味: Coconut/Groth16 系の PQ gap を埋める候補。
ecash NI Blind Signature Threshold Issuance
2026 / non-interactive threshold issuance
要点: threshold issuance の対話コストを下げる。
意味: PaxPay/Zef の発行・更新 UX を軽くする方向。
trace DCAP
TIFS 2020 / conditional anonymous payment
要点: 通常は匿名、条件成立時に追跡可能な conditional anonymity。
意味: PEReDi/AuditPay の前段として、条件付き開示設計を比較する。
trace Traceable Monero
TDSC 2021 / traceability in Monero-like systems
要点: Monero 型 privacy に tracing hook を入れる方向。
意味: default-private coin に規制機能を足す時の危険な設計点を示す。
KYC RegKYC
2025 / privacy-compliant KYC
要点: KYC credential を privacy preserving に扱う。
意味: payment execution と portable compliance credential を分離する研究に必要。
KYC Bind Anonymous Credentials to Humans
USENIX 2023 / human-bound credentials
要点: anonymous credential を実在人間に binding し Sybil を抑える。
意味: PaxPay の「1人1 compliance coin」問題の基礎。
compliance Toxic Decoys
PoPETs 2025 / compliance and decoy risk
要点: privacy set に悪性 decoy が混ざることで生じる compliance risk を扱う。
意味: Monero/RingCT と sanctions compliance の衝突を理解する材料。
compliance Balancing Privacy Accountability ZK-SNARK
PST 2022 / accountable privacy with ZK
要点: ZK-SNARK で privacy と accountability の中間設計を作る。
意味: ASOZ/AuditPay/PaxPay の中間解として位置づける。
audit Accountable Privacy
2016 / Zerocash extension with tracing
要点: Zerocash に selective tracing を足す初期の重要研究。
意味: privacy coin に規制 hook を入れる系譜の起点。
audit SeDe
2023 / selective deanonymization
要点: selective deanonymization を暗号的に制御する。
意味: judge-gated / statement-specific opening の比較対象。
ledger MiniLedger
ESORICS 2021 / compact zkLedger line
要点: zkLedger の履歴・サイズ問題を compact 化する。
意味: auditable ledger の scalability frontier を補う。
reserves Provisions
CCS 2015 / proof of solvency
要点: 取引所等が顧客残高を隠しつつ solvency を証明する。
意味: PARScoin/Aegis の reserve/liability audit の祖先。
reserves MProve / MProve+
2018-2025 / proof of reserves evolution
要点: proof of reserves / liabilities を効率化・一般化する系譜。
意味: stablecoin reserve audit を payment privacy とつなぐために必要。
reserves XieZhi / IZPR / PoA SNARKs
2022-2024 / succinct proof of assets/reserves
要点: proof of assets / reserves を SNARK や succinct proof で軽くする。
意味: Aegis/PARScoin の監査性能を具体化する数値比較候補。
coin Dusk
regulated privacy L1 / Phoenix + Citadel
要点: ZK-ID と selective disclosure を持つ規制対応 privacy L1。
意味: DART/RWA と Privacy Pools の中間に置ける実装系。
coin Dero
homomorphic encrypted account balances
要点: account balance を常時暗号化し、homomorphic に更新する privacy coin。
意味: account-model private payment と FHE/HE payment の祖先。
coin Ouroboros Crypsinous
S&P 2019 / privacy-preserving PoS ledger
要点: Zerocash 的 privacy と proof-of-stake ledger を結合する。
意味: privacy payment を consensus layer と統合する別方向の代表。
coin Nopenena
2024 / untraceable payments
要点: privacy coin 系の近年型 untraceable payment。
意味: Zcash/Monero/Quisquis 以後の匿名送金設計を補う。
coin StakeNote
2026 / PoS CryptoNote direction
要点: CryptoNote/Monero 系を proof-of-stake に寄せる研究。
意味: default-private coin の consensus 移行問題を示す。
Zcash Sapling / Orchard / Halo2
Zcash protocol evolution
要点: Sprout/Sapling から Orchard/Halo2 へ、trusted setup や UX を改善してきた系譜。
意味: Groth16 を使う PaxPay と、transparent setup 方向の将来差分を評価する基盤。
ZK Groth16 / Halo / Powers of Tau
SNARK proving system foundations
要点: private payment の proving cost と trusted setup を決める証明系の基盤。
意味: PaxPay の trusted setup / prover cost 問題を評価するには必須。
Zcash Kappos Anonymity Analysis
2018 / empirical anonymity analysis
要点: Zcash の opt-in privacy は shielded adoption と entry/exit pattern に依存することを実証。
意味: protocol privacy と実効 privacy の差を示す代表研究。
Monero Triptych / Omniring / CLSAG
2019-2020 / ring signature scaling
要点: Monero 系 ring proof のサイズ・検証コストを改善する系譜。
意味: trusted setup なし private payment の性能 frontier。
Monero Seraphis / FCMP++
2022-2024 / full-chain membership direction
要点: ring size 依存を超え、全チェーン規模の membership proof を目指す。
意味: anonymity set quality の根本改善として、privacy payment の重要潮流。
network Dandelion++
2018 / transaction broadcast privacy
要点: 取引内容だけでなく broadcast origin を隠す network-layer privacy。
意味: PaxPay/Zef でも network timing/origin leakage を無視できないことを示す。
analysis Monero Traceability Studies
2017-2025 / empirical traceability and wallet bugs
要点: デコイ選択、wallet bugs、cross-chain behavior によって Monero の実効匿名性が崩れることを示す系譜。
意味: 暗号定義だけでなく wallet/behavioral leakage を評価軸に入れる理由。