Centrally Banked Cryptocurrencies

George Danezis; Sarah Meiklejohn

Source-linked AI summary

Centrally Banked Cryptocurrencies

George Danezis, Sarah Meiklejohn

arXiv:1505.06895v2May 26, 2015cs.CR

TL;DR

Existing cryptocurrencies use decentralized proof-of-work ledgers but face scalability, computational-cost, and monetary-policy limitations. RSCoin separates monetary-supply generation from ledger maintenance, giving central banks control while distributed mintettes validate transactions. The framework retains transparency and auditability while enabling scalable double-spending prevention without wasteful hashing.

Problem
Existing cryptocurrencies have poor scalability, costly proof-of-work, and little control over monetary supply, limiting payment capacity and monetary-policy flexibility.
Method
RSCoin centralizes monetary-supply generation under a central bank and delegates transaction validation to a distributed set of authorized mintettes using an adapted Two-Phase Commit protocol.
Results
RSCoin maintains transparency and auditability while providing a scalable system for preventing double-spending and eliminating wasteful proof-of-work hashing.
Takeaways & Limitations
A modest degree of centralization can preserve transparency guarantees while improving cryptocurrency scalability and avoiding proof-of-work-based consensus costs.

Abstract

from arXiv · show

Current cryptocurrencies, starting with Bitcoin, build a decentralized blockchain-based transaction ledger, maintained through proofs-of-work that also generate a monetary supply. Such decentralization has benefits, such as independence from national political control, but also significant limitations in terms of scalability and computational cost. We introduce RSCoin, a cryptocurrency framework in which central banks maintain complete control over the monetary supply, but rely on a distributed set of authorities, or mintettes, to prevent double-spending. While monetary policy is centralized, RSCoin still provides strong transparency and auditability guarantees. We demonstrate, both theoretically and experimentally, the benefits of a modest degree of centralization, such as the elimination of wasteful hashing and a scalable system for avoiding double-spending attacks.

I. INTRODUCTION

RSCoin addresses the scalability, computational-cost, and monetary-policy limitations of existing cryptocurrencies by separating monetary-supply generation from transaction-ledger maintenance. It centralizes monetary authority while retaining a transparent ledger and using accountable mintettes to support scalable double-spending prevention.

Motivation: Existing cryptocurrencies face poor scalability, costly proof-of-work, and loss of control over monetary supply.Bitcoin handles at most 7 transactions per second, while proof-of-work can consume power comparable to a large power plant.
Approach: RSCoin decouples monetary-supply generation from maintenance of the transaction ledger.The framework is motivated by creating a more scalable cryptocurrency and by whether central banks should issue digital currencies.
Approach: RSCoin centralizes monetary supply under a central bank while preserving a transparent, distributed transaction ledger and globally visible monetary supply.The design supports transparent monetary policy, direct payments and value transfers, pseudonymity, and blockchain-based uses.
Approach: The central bank delegates transaction validation to known, accountable mintettes instead of relying on anonymous miners and proof-of-work.An adapted Two-Phase Commit mechanism supports double-spending detection and ledger integrity.
Results: A 30-mintette experimental testbed processed over 2,000 transactions per second, with performance scaling linearly as mintettes increased.Most transactions took less than one second to clear, compared with many minutes in traditional cryptocurrency designs.
Scope: The framework aims to let any central bank deploy its own cryptocurrency and support transparent, auditable exchange across deployments.The paper discusses interoperability and exchange between currencies without fragmenting the global monetary system.

A. The Bitcoin protocol

Bitcoin combines decentralized monetary-supply generation with a decentralized transaction ledger maintained through broadcast and proof-of-work. RSCoin instead introduces a central bank and distributed mintettes, using layered blocks and delegated validation to maintain the ledger.

Bitcoin protocol: Bitcoin uses a global peer-to-peer network to generate currency units and witness transfers through transaction broadcast and proof-of-work.This blockchain design fulfills monetary-supply generation and transaction-ledger establishment without centralized control.
Bitcoin protocol: Users transfer value by creating transactions that are broadcast to peers and eventually sealed into the ledger by miners.A miner hashes a transaction pool with metadata and a nonce, seeking a hash below the network target.
Bitcoin protocol: Bitcoin blocks both generate monetary supply through mining rewards and provide a partial ordering for transactions.Miners receive optional transaction fees and a system-specific mining reward included in a coin-generation transaction.
RSCoin overview: RSCoin assigns monetary-supply control to a central bank and ledger maintenance to a distributed set of mintettes.Mintettes are authorized by the bank and replace computationally intensive mining with transaction collection and block production.
RSCoin overview: Mintettes create cross-referenced lower-level blocks, which the central bank merges into higher-level blocks incorporated into the main blockchain.Ordinary users track higher-level blocks, while auditors may retain lower-level blocks to inspect mintette and bank behavior.
Scope: RSCoin is intended as a framework that can incorporate existing cryptocurrency techniques, while comprehensive privacy integration remains future work.The paper identifies privacy-enhancing techniques as orthogonal to its main goals.

V. ACHIEVING CONSENSUS

RSCoin replaces proof-of-work consensus with authorized mintettes and an adapted Two-Phase Commit protocol, targeting scalable transaction validation and explicit integrity guarantees. Its threat models cover honest-majority processing and hostile collusion, while audit mechanisms expose misconduct and inactivity.

Motivation: RSCoin uses central-bank-authorized mintettes to reach consensus without the wasteful proof-of-work required by fully decentralized cryptocurrencies.Mintettes are known and accountable to some extent, enabling a lighter consensus requirement.
Threat models: The analysis considers an honest-majority-per-transaction model and a hostile model allowing all mintettes to collude, while retaining some guarantees for honest users.Misbehavior can also be detected and lead to accountability.
Security properties: The protocol addresses no double-spending and non-repudiable sealing as core integrity properties.A valid transaction cannot reuse an output address, and a mintette’s confirmation can implicate it if the transaction is not included in the next block.
Auditability: Users can perform timed personal audits of mintettes using lower-level blocks and prior interaction records.The property checks whether observed mintette behavior matches behavior implied by earlier interactions.
Auditability: Anyone with lower-level blocks can audit all transactions processed by mintettes and detect retroactive ledger modification, omission, or insertion.This is the universal-audit property.
Auditability: Anyone with lower-level blocks can observe substantial mintette inactivity in the Two-Phase Commit protocol.Such inactivity prevents a mintette from retroactively claiming fees for services it did not provide in time.

B. A basic consensus protocol

The basic protocol shards address ownership among authorized mintettes and uses a two-phase user-mediated process to validate inputs, collect signatures, and commit transactions. Under an honest majority for each transaction, it prevents double-spending and provides non-repudiable sealing with low mintette communication overhead.

Sharding: Transaction identifiers are partitioned into shards, each covered by potentially multiple mintettes whose ownership assignments are publicly known.All input addresses may have different owners, while all outputs of one transaction share an owner set.
State: Mintettes maintain unspent-output, pending-spend, and committed-transaction lists to track shard-local state during each period.The pending-spend list detects double-spending, while the committed-transaction list seals transactions into the ledger.
Validation: In phase one, input-address mintettes check transaction validity and whether inputs remain unspent, then return signed acknowledgments.The user proceeds after receiving signatures from at least a majority of owners for each input.
Commit: In phase two, output-address mintettes verify the transaction, evidence bundle, mintette authorization, and signatures before committing unseen transactions.The evidence bundle demonstrates that the input mintettes approved the transaction.
Security: Under an honest majority among the mintettes processing each transaction, honest mintettes accept no double-spending transactions and their confirmations provide evidence of sealing promises.These establish the first two integrity properties for the basic consensus protocol.
Communication overhead: Mintettes communicate indirectly through users’ evidence bundles rather than directly with one another, reducing communication overhead.The paper connects this design to scalability and compares it with systems requiring constant miner or server communication.

C. Achieving auditability

RSCoin augments its consensus protocol with hash-linked, signed action logs and cross-hashing among mintettes. These mechanisms support stronger auditability, while the security analysis shows how shard count and honest-majority assumptions constrain the probability of system security.

Integrity logs: Each mintette records absolutely ordered Query, Commit, and CloseEpoch actions in an action log.The log captures transaction assignment, commitment, and epoch closure activities.
Integrity logs: A rolling hash chain makes each log head a witness to the mintette’s current log state, and mintettes sign and share these heads in messages.The chain updates as h_seq = H(a_seq∥h_seq−1).
Cross-hashing: Cross-hashing makes each mintette’s chain depend on the latest known heads of its own and other mintette chains.CloseEpoch records known chain heads and their sequence numbers.
Auditability: The augmented consensus protocol provides timed personal audits, universal audits, and exposed inactivity in both threat models.These are the stronger integrity properties claimed by Lemma V.1.
Auditability: The protocol detects delayed actions because second-phase messages carry input mintettes’ hash heads, forming a low-degree graph with good expansion properties.The paper expects dependencies on other chains to propagate rapidly toward a supermajority.
Security assumptions: RSCoin assumes an honest majority within every shard, rather than merely an honest majority across all mintettes.Lemma V.2 relates this assumption to the fraction of corrupt mintettes and shard size.
Security assumptions: The security probability is ρ^y, so increasing the number of shards lowers the probability that all shards have honest majorities.The paper recommends the smallest practical shard count consistent with load balancing.

1) Theoretical analysis:

RSCoin’s theoretical analysis shows that transaction communication is bounded by the number of input addresses’ mintette assignments, while per-mintette work decreases linearly as the system grows.

Communication complexity: Each transaction requires at most 2(m + 1)Q messages for a user when it has m inputs and Q mintettes per address.The first 2PC phase uses at most mQ messages, and the second uses at most Q messages.
Scalability: With equal-sized shards and proportional transaction allocation, adding mintettes decreases each mintette’s workload linearly.The analysis assumes each mintette receives a proportional share of total transactions.

2) Experimental analysis:

Experiments on a modest EC2 deployment evaluate implementation performance, showing sub-second 2PC latency and throughput that scales linearly beyond three mintettes, with networking-related bottlenecks remaining.

Experimental setup: The evaluation implemented RSCoin’s basic consensus mechanism on Amazon EC2 to measure transaction-confirmation latency and validate theoretical performance estimates.The implementation used single-threaded services, and the setup included 30 mintettes and separate stress-testing servers.
Latency: Under data-center conditions, both 2PC phases and cryptographic checks introduced an intrinsic latency of less than 0.5 seconds.Figure 3 measures latency for transactions with freshly issued coins and arbitrary previous transactions.
Latency: Over a wide-area network, full 2PC latency remained usually well under a second under the tested conditions.The measurements contacted all three mintettes per input and required responses in both phases.
Throughput: Beyond three mintettes, throughput scales linearly because each transaction contacts a bounded number of mintettes; each added mintette contributes approximately 66 transactions per second.With fewer than three mintettes, throughput remained roughly flat below 400 transactions per second.
Limitations: The approximately 400-transaction-per-second end-to-end rate was below micro-benchmark rates, indicating bandwidth, networking, or interconnection bottlenecks for single mintettes.The client also opened a fresh TCP connection for every request because pipelining was not implemented.

VI. THE RSCOIN SYSTEM

RSCoin combines central-bank control with distributed mintettes that maintain transaction records through signed lower-level blocks and cross-references, allowing the bank to perform limited aggregation work.

System structure: RSCoin’s system structure centers on interactions between mintettes and the central bank, including system parameters and operational properties.The design also considers fees, overlays on existing cryptocurrencies, and incentives for mintettes.
Lower-level blocks: A lower-level block contains a hash, transaction set, mintette signature, and references to hashes of other previous mintette blocks.The cross-chain references encode dependencies among mintettes’ blocks.
Block validation: Block validity checks use the bank’s public key, the authorized mintette set from the previous higher-level block, and signatures binding mintettes to the period.The mintette’s own signature and the bank’s authorization signature are both checked.
Block formation: To form a lower-level block, a mintette combines its epoch transaction set with hashes received from other mintettes through the bundle-of-evidence mechanism.These hashes populate the cross-chain reference set and the hash input for the block.

B. Higher-level blocks

Higher-level blocks let the bank consolidate transactions, authorize mintettes for the next period, and allocate newly generated coins and fees while preserving auditability through action logs.

Higher-level block structure: A higher-level block contains a hash, transaction set, bank signature, and bank-signed public keys authorizing mintettes for the next period.The authorization set contains each mintette public key and the bank’s signature on that key.
Validation: Higher-level block validity requires a valid hash, the bank’s signature, and valid bank signatures for every authorized mintette.The checks bind the block contents and next-period mintette authorization to the central bank.
Aggregation: The bank collates mintette lower-level blocks and action logs, resolving conflicting transactions and identifying mintettes responsible for including them.Creating a consistent transaction set may require examining all received transaction sets for double-spending.
Supply and fees: Higher-level blocks may include a bank-controlled coin-generation transaction and fee allocations to mintettes that earned them during the previous period.The bank determines which mintettes earned fees using information from the action logs.
Auditability and incentives: The bank rewards mintettes involved in certifying input addresses, while action logs prevent inactive mintettes from later claiming prior contributions.Publishing the logs is expected to let anyone audit mintette actions and the bank’s operation, assuming an honest bank.

2) A simplified block structure:

RSCoin’s block structure distributes transaction collection across authorized mintettes while preserving bank oversight, with parameter choices balancing settlement speed, bank burden, scalability, and incentives. The design also supports pruning intermediate transactions, although such edits remain auditable and restricted.

2) A simplified block structure:: RSCoin uses additional block values and transactions to embed its mintette and bank metadata into a cryptocurrency-compatible transaction structure.These values support validation of lower-level blocks by checking authorization information in preceding higher-level blocks.
2) A simplified block structure:: Mintette incentives can make the presented ledger consistent before the central bank receives the distinct mintette blocks.Misbehaving mintettes may lose future authorization or earned fees, while active participation and authorization payments provide direct compensation.
2) A simplified block structure:: Mintette epoch lengths depend on processing rate, while periods trade off frequent official sealing against reducing central-bank intervention.Mintettes processing more transactions can have shorter epochs; longer periods ease bank burden, while promises from mintette quorums can support near-instantaneous settlement.
2) A simplified block structure:: RSCoin throughput scales linearly with the number of mintettes, but adding mintettes reduces their transaction-fee earnings.The system therefore balances competitive settlement and performance against the incentives needed to compensate participating mintettes.
2) A simplified block structure:: The central bank can prune intermediate transactions at period end, but action logs expose these changes and the permitted alterations must remain significantly restricted.Pruning can reduce transaction bloat when users make multiple transfers within a period.

B. Further incentives for honest behavior

The paper extends RSCoin’s incentive and interoperability design through escrow-based mintette accountability, shared infrastructure across central banks, and transparent cross-currency exchange. These mechanisms address misbehavior, fragmentation, and opacity while retaining central-bank control over authorized exchanges.

B. Further incentives for honest behavior: An escrow-based mechanism limits the value of transactions a mintette may collate and lets the central bank seize escrow after misbehavior.The mechanism is not fully robust because a mintette might accept many expenditures of the same currency unit, not merely two.
B. Further incentives for honest behavior: Periods can begin short when mintettes have little capital to post and grow longer as they accumulate currency, allowing an initial trial phase.The paper presents this as a path toward a more stable system as trustworthy mintettes emerge.
B. Further incentives for honest behavior: Using one platform across central banks can prevent duplicated infrastructure and let users store value in multiple currencies while keeping blockchains separate.Mintettes may validate transactions for multiple central banks according to their business interests.
B. Further incentives for honest behavior: The common third-party exchange approach is opaque because transactions across two ledgers are not visibly linked.RSCoin proposes a fair-exchange mechanism that makes the currency exchange observable as such in the ledger.
B. Further incentives for honest behavior: A modified atomic cross-chain protocol requires a third party to sign both transactions for authorized currency pairs, binding them across blockchains for auditing.The protocol enables transparent approved exchanges but cannot prevent exchanges conducted without that approval.
B. Further incentives for honest behavior: RSCoin combines central control of monetary policy with transparent ledgers and a 2PC-based consensus mechanism that avoids proof-of-work hashing.The paper reports theoretical and measured performance evidence for a more scalable double-spending-prevention system.

APPENDIX

The appendix presents a fair cross-currency exchange protocol in which authorized third-party approval links transactions across separate blockchains. Its timed refunds and secret revelation ensure that either the exchange completes or participants recover their funds.

APPENDIX: The protocol uses spend and refund transactions, including multisignature conditions and timed recovery paths.Alice and Bob prepare transactions that release funds under exchange conditions or return them after specified times.
APPENDIX: Alice commits to the exchange with a secret hash, obtains signatures from Carol and Bob, and then safely publishes her spend transaction.The signatures provide a refund path after t1 if the exchange does not proceed.
APPENDIX: Once both blockchain transactions are accepted, Alice reveals the secret while redeeming Bob’s currency, enabling Bob to redeem Alice’s currency.If Alice does not redeem, Bob can refund after t2, which must occur before t1.
APPENDIX: Figure 5 specifies a fair exchange of m units of c1 for n units of c2 with third-party approval, so either participant can stop without causing the other a loss.The figure’s participants are labeled A, B, and C, with C approving the exchange.