Cryptocurrency with Fully Asynchronous Communication based on Banks and Democracy

Abstract

Cryptocurrencies emerged in the last decade attempting to offer a new financial system not governed by centralized entities, where users have complete control over their accounts without needing to trust strangers. However, cryptocurrency systems face challenges preventing them from being used as everyday coins.

This paper introduces a cryptocurrency system with important properties, most notably deterministic operation over fully asynchronous communication networks. By avoiding temporal assumptions, the system is robust against arbitrary network delays, with latency only a function of actual communication delay.

The system is based on banking and democratic concepts. Banks keep clients' money and perform requests, but cannot act without user permission due to cryptographic schemes. Democracy means every bank operation must be accepted by a majority of coin holders, resembling representative democracy where banks are representatives.

The approach employs centralization advantages while providing a completely trustless, decentralized system. By using familiar concepts and achieving high throughput with low latency, this paper lays foundations for a cryptocurrency usable as a practical daily coin.

1. Introduction

Cryptocurrency is a digital coin accompanied by cryptographic tools providing several benefits. In traditional systems, banks keep your money, requiring trust in these institutions. In cryptocurrency, the amount of money you have is determined by consensus among users.

Bitcoin emerged in 2008 offering a solution but has known flaws including transaction acceptance time, limited throughput, and high energy consumption. Numerous works attempt to fix these flaws.

Common to all cryptocoins are two groups: users and administrators. Users hold coins and use them for trade or investment. Administrators ensure consensus about account balances and committed transactions.

The paper shows that deterministic cryptocurrency systems can be implemented over asynchronous communications, contrary to common belief based on the FLP impossibility result. The key difference is in handling conflicting values - in cryptocurrency, conflicting transactions can be rejected rather than forcing acceptance of one.

The system uses coin possession as the basis for consensus, avoiding the energy consumption of proof-of-work systems. Voting power is delegated by coin holders to their banks, creating a democratic governance model.

2. Related Works

The greatest challenge of cryptocurrency is reaching consensus on money balance and committed transactions. Bitcoin's blockchain approach uses Proof-of-Work (PoW), with great resource consumption.

Proof-of-Stake (PoS) was introduced to alleviate resource consumption, deciding blocks based on coin ownership rather than external resources. Delegating voting power is not new, but our approach ensures users cannot be indifferent - they must choose functioning banks to receive service.

Blockchain results in relatively low throughput and high latency because effectively only one admin at a time can add blocks. Solutions include doing things outside the main chain or avoiding a main blockchain entirely.

Instead of a blockchain, Directed Acyclic Graphs (DAGs) can be used, maintaining partial order rather than total order. Various cryptocurrencies use DAGs implicitly or explicitly.

Our solution maintains a blockchain for every admin/bank, with users submitting transactions to their chosen bank. Conflicting transactions should not appear in different blockchains, except when users switch banks.

3. Model

A cryptocurrency system is defined by the tuple (A,I,𝔹,P) where A is a set of possible account numbers, I:A→ℝ≥0 defines initial balance for each account, 𝔹 is a set of possible admin IDs, and P is the protocol every admin should follow.

A transaction is defined by (s,t,m,i,d) where s,t∈A are source and destination accounts, m∈ℝ+ is the amount transferred, i∈ℕ is a sequence number, and d is a digital signature.

In every execution, nodes act as users and admins. Users create transactions and send them to admins. Admins send messages between them and accept or reject transactions.

The system uses permissionless settings with asynchronous communications and Byzantine crashes. An execution is valid if it satisfies:

• Agreement: A transaction accepted by a valid admin will be eventually accepted by all valid admins.
• Positive Balance: At every time point, applying accepted transactions results in non-negative balance in all accounts.
• Termination: Every transaction sent to a valid admin must be eventually either accepted or rejected.
• Rejection Restriction: A valid admin may reject a transaction only under specific conditions.

4. Solution

The solution describes a cryptocurrency system satisfying the requirements under specific assumptions. Every admin and user holds a pair of public and secret keys.

Account numbers are combinations of user's public key and admin's public key. Admins are called banks. Users send signed transactions to their own bank but can switch banks by transferring all money to a new bank.

4.1 The Blockgraph

Instead of a blockchain, the system uses a Blockgraph - a DAG where every bank has its own chain containing blocks issued by that bank. Each block is split into several nodes:

• Start node: Contains transactions to be committed
• Update node: Contains references to nodes of other banks
• Accept node: Marks the end of a block
• Init node: Defines initial coin distribution

A bank creates a start node to publish transactions, then sends it to other banks. Other banks create update nodes referencing that start node. Once enough banks have acknowledged the start node, the bank can create an accept node.

Consensus is defined by coin possession. Each user has voting power proportional to balance, delegated to their bank. An accept node is valid if it has supporting voting power above a predefined threshold.

4.2 The Protocol

Banks follow protocol P:

• When receiving a transaction from a user, check if it may be rejected according to rejection restriction.
• If able to create a start node and waiting transactions exist, create a new start node with valid transactions.
• If having an open transaction block and able to validly create an accept/close node, create it.
• When receiving a node from another bank, check if it's valid and won't make the graph improper, then add it and create an update node.
• After creating a node, send it to all other banks.
• After adding an accept node, accept the transactions that should be applied.

The protocol ensures the system fulfills the requirements under the assumption that more than two-thirds of voting power is in the hands of valid banks.

5. Conclusions

Cryptocurrency systems should allow easy money transfer without excess bureaucracy and supervision. The complexity is in managing required consensus in permissionless settings.

The paper defines requirements for a "fair" cryptocurrency system where users creating valid transaction sequences can be sure their transactions will be accepted, and once accepted, remain accepted.

The solution has beneficial characteristics: consensus based on coin possession avoids energy waste of proof-of-work, latency is only due to message transmission and basic computations, and security is plain and simple.

Security can only be undermined if more than one-third of voting power is in malicious hands. The deterministic protocol works even with asynchronous communication.

Future Work

Open challenges include memory optimization, handling large numbers of banks, privacy limitations, and addressing the "nothing at stake" problem through financial incentives.

A promising direction is limiting transparency to the bank level, where only banks know transaction details. Another is incentivizing banks to keep private money as collateral, similar to real banks' capital requirements.

References

The paper references 20 works covering blockchain, consensus algorithms, DAG-based cryptocurrencies, and theoretical foundations of distributed systems.

Appendices

The paper includes three appendices:

• Appendix A: Formal definition of system execution
• Appendix B: Proof of Lemma 3 (Positive Balance)
• Appendix C: Proof of Lemma 4 (Proper Graphs)