|
The World of Deep Wealth
Culture hacker, software architect, & targeted currencies geek… Building bridges to the next economy & network society. http://ArtBrock.com
Beyond Blockchain: Simple Scalable Cryptocurrencies
Inappropriate Consensus: How to design the Universe NOT to scale effectiviely
Summary:
I clarify the core elements of cryptocurrency and outline a different approach to designing such currencies rooted in biomimicry (how nature functions and scales). I distinguish efficiencies of distributing process as a foundation for decentralized data and decision-making. Then I illustrate an implementation of a currency using these principles to bring a centuries old practice into the digital era. I address a basic vulnerability showing how these design principles can be deployed on a large scale. Finally, I confront social challenges involved in managing crypto systems and an invitation to partnership in building platform which addresses these issues.
Contents:
What is a Cryptocurrency?
Alternate Approach: Parallel Chains with Intrinsic Data Integrity
Currency Design Principle: Mutual Credit
A Minimum Viable Cryptocurrency
More Scalable Security: Notaries + DHT
Conclusions
What is a Cryptocurrency?
Currently, most people think of cryptocurrencies as things that run on blockchains like bitcoin, ethereum, dogecoin, and all the alt-coins and ledger systems. This post outlines a completely different strategy for implementing cryptocurrencies with completely distributed chains. Before presenting the approach, I want step back and validate some basic assumptions, because this very notion seems impossible to many, especially those steeped in blockchain.
In the MetaCurrency project we started with a different goal. Rather than trying to make one global, anonymous, digital cash (“One ring to rule them all…”), we are interested in the resilience that comes from building a rich ecosystem of interoperable currencies. We seek to empower communities of all shapes, flavors, and sizes to organize themselves and their flows of resources more effectively. Our different assumptions and design requirements has led us down a different path toward implementation.
First, some clarity on cryptocurrencies of any type. What are the core elements of a modern cryptocurrency?
Digital: This one may be obvious, but it’s worth saying. It’s electronic, not paper or coins. Holdings are electronic and only exist and operate by virtue of a community’s agreement about how to interpret digital bits according to rules about operation and accounting of the currency.
“Trustless:” You don’t have to trust a 3rd party central authority (a bank, government, business, or club) for the currency to work. The currency operates independent of the goodwill, integrity, practices, or decisions of any particular (non-representative / unaccountable) group.
Decentralized: The primary to ensure the currency is not controlled by a small group for their own benefit is to make the currency itself function in a decentralized manner so that it is literally held and managed by many, most, or all of its participants. Specifically, access, issuance, transaction accounting, rules & policies, should be collectively visible, known, and held.
Cryptographic: Since a decentralized information architecture also means many “fingers in the pie,” the currency should leverage cryptographic data structures (hash-chains, Merkle trees, etc) to ensure Intrinsic Data Integrity. This cryptographic structure is used to enable a variety of people to host the data without being able to alter it.
Identity: Since the currency only exists as bits, there must be a way to associate these bits with some kind of account, wallet, owner, or agent who can use them. Some kind of identity and authorization infrastructure is required (even if it permits anonymous use). This is typically implemented using cryptographic public/private key pairs. This is a second distinct use of cryptography from the cryptographic structures to ensure data integrity in #4.
Personally, I think that sums up the basic gist of a modern cryptocurrency. Other things that many take for granted in blockchains may not be core but subject to decisions in design and implementation, so they can vary between implementations. I acknowledge our assumptions stray from the norm in these ways:
It does not have to be stored in a synchronized global ledger, if you can meet the above criteria another way.
A currency does not have to be money. It may be a reputation currency, or data used for identity, or naming, etc.
Its units do not have to be cryptographic tokens or coins.
It does not have to protect the anonymity of users, although it may.
Items on this second list are decisions you make based on the use case for you currency — they are not inherent requirements for all cryptocurrencies. For example, if you think currency is only money, and that money must be artificially scarce to have value, then certainly you might choose to issue and track a limited supply of cryptographic tokens or coins. And you might mete them out for performing work managing ledger consensus, or other computationally intense tasks. Then you must tackle the problem of always tracking which coins exist, and which have been spent. That is one approach — the one blockchain takes.
You might optimize for anonymity if you think of cryptocurrency as a tool to escape governments, regulations, and taxes. However, if you think of it as a tool for building and sharing wealth inside communities, or if you want to establish and manage membership in new kinds of commons, then identity and accountability for actions may turn out to be necessary ingredients instead of anonymity.
In the case of the MetaCurrency Project, we are trying to support many use cases by building tools to enable a rich ecosystem of communities and current-sees (many are non-monetary) to enhance collective intelligence at all scales. Since we aren’t trying to build global, anonymous, digital cash, we took an alternate approach. I illustrate that alternative to blockchain here, but I don’t explain blockchain. You can find blockchain tutorials elsewhere if you like, but that should not be necessary for understanding our approach.
Alternate Approach: Parallel Chains with Intrinsic Data Integrity
Managing consensus about a shared reality is a central challenge at the heart of all distributed computing solutions. The bitcoin blockchain made a big step forward in practical Byzantine Fault Tolerance, by creating blocks of many transactions (with a 10 minute delay and randomized selection to append the block), instead of getting consensus about the sequence of thousands of transactions in a hash chain, it gives you 10 minutes to collect transactions, and then your peers just validate (signatures and unspent tokens) on the whole block. Currently the bitcoin blockchain has grown to almost 65GB and can only process 7 transactions per second.
If we want to democratize money by having cryptocurrencies become a significant and viable means of transacting on a daily basis, I believe we need fundamentally more scalable approaches that don’t require expensive, dedicated hardware just to participate. Luckily, if we only enforce consensus where consensus is actually what’s needed, the nature of the problem changes drastically. We need consensus about whether a domain name has been registered, who owns it and where it points to. We should not need system wide consensus for two people to do a transaction in a cryptocurrency. I understand why consensus is currently required in the blockchain, but to me it means the problem has been framed wrong.
Blockchain is about managing a consensus about what was “said.” Ceptr is about distributing a consensus about how to “speak.”
To see some other ways we could frame these kinds of problems, let’s look at how nature gets the job done in massively scalable systems which require coordination and consistency. Here are some of the core principles we’ve found:
Replicate the same processes across all nodes.
Empower every node with full agency (the ability to execute processes to transform itself).
Hold this transformed state locally and reliably.
Establish protocols for interaction (which trigger the shared processes that in turn produce expected transformations).
That is probably not a definitive list, but let’s use these as a high-level starting point. However, as they say: “The devil is in the details.” In later posts I’ll go into implementation details and how we’ve been building this in Ceptr. However, in this post, I’ll stick to a high-level illustration and work through an example of a minimal implementation for a cryptocurrency, which is simpler and lighter weight than a blockchain approach.
Let’s look at how highly scalable systems in the real world incorporate these principles rather than blockchain-like patterns.
Humans: Each speaker of a language carries the processes to understand sentences they hear, and generate sentences they need. When we use those rules properly, we are speakers of that language. We don’t have to be conscious of the rules. We don’t have to know all the same words (because we can use the rules to have unknown ones explained). We don’t need the same experiences. And we certainly don’t carry some kind of global ledger of everything that’s ever been said, or require consensus about what has been said. A global ledger approach would make it impossible to learn or speak a language, introducing ridiculous latency, bottlenecks, and stultification. Can you imagine not being able to say something until the language committee (miners) reaches consensus that it is a valid sentence for you to speak? Language IS a communication protocol we learn by emulating the processes of usage. For example, words don’t mean what a dictionary or any kind of shared ledger says; they mean how they’re used. Dictionaries try to catch up when the usage (processes) have become widespread (e.g. saying “sick” to mean “awesome”).
Cells: Cells each carry a copy of their instruction set (DNA). Stem cells use these instructions to differentiate into more specific cell types in response to their context and setting. Differentiated cells express different subsets of genes in the DNA — similar to a computer loading programs from disk into active memory. The expressed genes govern the behavior of the cell — provide the “program” the nucleus runs. It’s even called nuclear reprogramming. Again, there is certainly no global ledger with consensus about the state of trillions of cells. Yet, from a single zygote’s copy of DNA, our cells coordinate in a highly decentralized manner, on scales of trillions, and without the latency or bottlenecks of central control.
Atoms: We speak of atoms as if they’re objects made of sub-objects, made of yet smaller objects. Even though they provide us the experience of solidity and substance, they are far from solid and substantial. Instead, they are mostly empty space — fields of emptiness that embody complex processes. These processes transform the state of the atom (or its subparts/fields) through interactions with other atoms, fields, light, or energy. We don’t know how those processes are coded into the fabric of an atom, but they are so consistent and reliable that they form the basis of all of our physical reality — the “Laws of Physics.” Here also, it would be ridiculous for an atom not to be able to bond with another atom without first consulting a global electron ledger to see if it’s being double-spent. Imagine the bandwidth and processing power it would take to run a global ledger tracking the state of every atomic particle in the whole universe.
Applying these organizing principles to cryptocurrency
Replicate the same processes across all nodes:
Imagine something along the lines of a Java Virtual Machine connected to a distributed version of Github. Every time this JVM runs a program it confirms the hash of the code it is about to execute with the hash signed into the code repository by its developers. Similarly, when you create a distributed application or cryptocurrency, you use this method of implementing and distributing the code.
This allows each node that intends to be honest to be sure that they’re running the same processes as everyone else. So when two parties want to do a transaction, and each can have confidence their own code, and the results that your code produces. Then you treat it as authoritative and commit it to your local cryptographically self-validating data store.
Empower every node with full agency:
Allowing each node to treat itself as a full authority to process transactions (or interactions via shared protocols) is exactly how you empower each node with full agency. Each node runs its copy of the signed program/processes on its own virtual machine, taking the transaction request combined with the transaction chains of the parties to the transaction. Each node can confirm their counterparty’s integrity by replaying their transactions to produce their current state, while confirming signatures and integrity of the chain (at rates of 4k to 40k/sec depending on the signing algorithm used).
If both nodes are in an appropriate state which allows the current transaction, then they countersign the transaction and append to their respective chains. When you encounter a corrupted or dishonest node (as evidenced by a breach of integrity of their chain — passing through an invalid state, broken signatures, or broken links), your node can reject the transaction you were starting to process. Countersigning allows consensus at the appropriate scale of the decision (two people transacting in this case) to lock data into a tamper-proof state so it can be stored in as many parallel chains as you need.
Hold this transformed state locally:
When your node appends a mutually validated and signed transaction to its chain, it has updated its local state and is able to represent the integrity of its data locally. As long as each transaction (link in the chain) has valid linkages and countersignatures, we can know that it hasn’t been tampered with.
The cartoon about double-spending an electron is intended to illustrate what a bad idea it would be to run the universe with a global electron ledger. Two atoms should be able to “sort it out” without needing agreement from every other atom in the universe. It probably triggers a response in you like, “Duh, it either has the electron or it doesn’t.” And that’s exactly the point! If you can reliably embody the state of the node in the node itself using Intrinsic Data Integrity, then all nodes can interact in parallel, independent of other interactions to maximize scalability and simultaneous processing. Either the node has the credits or it doesn’t. I don’t have to refer to a global ledger to find out, the state of the node is in the countersigned, tamper-proof chain.
Establish protocols for interaction:
Any transaction is just a special kind of communication according to a specific grammar or protocol. For example, “Transfer X units of Currency Y from Account A to Account B for This Described Purpose.” Just like any meaningful communication, a protocol needs to be established to make sure that a transaction carries all the information needed for each node to run the processes and produce a new signed and chained state. This could be debits or credits to an account which modify the balance, or recoding courses and grades to a transcript which modify a Grade Point Average, or ratings and feedback contributing to a reputation score, and so on.
Order of Operation Matters
It turns out when you focus on distributing process first you end up with even more greatly distributed data. This is because each participant holds only their own data. In contrast, blockchains store everybody’s transactions in a single database that every node verifies and copies. The underlying foundation of distributed process enables deeper distribution of data and parallel architectures. Ethereum and smart contracts, are doing this the other way around — layering processes on top of a global ledger.
By distributing process at the foundation, and leveraging Intrinsic Data Integrity, our approach results in massive improvements in throughput (from parallel simultaneous independent processing), speed, latency, efficiency, and cost of hardware. There is no need to wait 10 minutes to see if your transaction gets committed. This architecture can facilitate huge volumes of even extremely “low value” transactions permitting creative uses for coordinating shared activities that wouldn’t merit the cost or energy of implementing on a blockchain. You also don’t need to incent people to hold their own record — they already want it.
Customizable Containers
Another noteworthy observation about humans, cells, and atoms, is that each has a general “container” that gets configured to a specific use. The human brain has specialized sections for language processing, but we can learn whatever language we’re raised in (plus more). Each cell has a lot in common with other cells even when its nucleus gets reprogrammed to be a bone, brain, or liver cell. The basic scaffolding of cell functions is fairly universal. We know a little bit less about the details of this on the atomic level, but the structure of electron valences remain the same no matter how many electrons an atom has. It’s even possible that all subatomic particles are organized into an 8 dimensional framework, with different activations present (bits flipped) to present different atomic states.
Likewise, the Receptors we’ve built are a general purpose framework which can load code for different distributed applications. These Receptors are a lightweight processing container for the Ceptr Virtual Machine Host. (Yes, Ceptr also gets its name from these Receptors.) Building certain universal capacities into these receptors makes the job much easier for the developer of a distributed application or cryptocurrency because the bulk of the infrastructure is already present for managing distributed processes, DHTs, and the validation, distribution, and release of code.
Ceptr enables a developer to focus on the rules and transactions for their use case instead of building a whole framework for distributed applications.
Currency Design Principle: Mutual Credit
The means to design better, more equitable currencies has come a long way in the past 500 years. So, it is probably a good idea to integrate best practices from community currencies instead of just basing the design on money. Most people think that money is just money, but there are literally hundreds of decisions you can make in designing a currency to target particular needs, niches, communities or patterns of flow. Some seemingly small decisions end up having large effects when iterated over centuries and billions of transactions. But, for the moment, let’s just stick to one core design principle regarding how units in a currency are issued.
Blockchain cryptocurrencies are fiat currencies. They create tokens or coins from nothing. Bitcoin does this through mining, allowing the miner who completes a complex processing task first, to commit the next block of transactions to the chain along with a transaction that creates a bunch of new coins. These coins are just “spoken into being” (the meaning of “fiat” in Latin) by the node committing the new block. Thus begins the challenging task of tracking all the coins that exist to ensure there is no counterfeiting or double-spending. You wouldn’t need to manage consensus about whether a cryptocoin is spent, if your system created accounts which have normal balances based on summing their transactions. Sounds simple, right?
There’s a name for this completely peer-to-peer approach to issuing managing a currency supply: mutual credit. In a mutual credit system, units of currency are issued when a participant extends credit to another user in a standard spending transaction. Picture a new mutual credit currency with all accounts having a zero balance. The first transaction could look like this: Alice pays Bob 20 credits for a haircut. Alice’s account now has -20, and Bob’s has +20.
Notice the net number units in the system remains zero, just like the balance sheet in standard accounting must always balance to zero. That accounting practice places no limits on the amount of cash or assets a business can have; it simply means they are offset by an equal amount of liabilities or equity. Every negative balance in a mutual credit system is offset by positive balances so there is always a systemwide ZERO balance. You could think of the total number of units in circulation at any time as the sum of all the negative balances (or, if you prefer, the sum of positive balances since they are the same number).
But wait — Alice spent credits she didn’t have! True. That’s exactly how issuance in mutual credit works. Managing the currency supply in a mutual credit system is about managing credit limits — how far people can spend into a negative balance. Different systems set different rules about this, ranging from everyone having the same limit (e.g. 100 credits), to having NO limits and leaving the choice up to each person as to whether they want to extend more credit to someone deep in debt. It really depends on the community, the relationships, and the use case.
One elegant approach to managing mutual credit limits is to set them based on actual demand. You can calculate credit limits to be an equivalent of what you can pay back in 3 months (or another arbitrary period) based on the transaction history of each account (with a couple of anti-gaming modifications). This allows the currency supply to expand and contract based on the actual usage patterns of the community which demonstrate the market demand for the value people are providing.
Yes… I know many of you are jumping out of your seats with concerns about manufacturing fake accounts to game credit limits (Sybil Attacks). Please keep in mind there can be different classes of accounts. Easy to create, anonymous accounts may get NO credit limit, and only be able to spend credits which they have earned. Just like in the regular world, to get a credit line, you may need to validate your identity, pay an application fee, or jump through whatever hoops the community decides are appropriate for the community to extend you credit (e.g. be a member of the church, live in the neighborhood, have placed a security deposit, confirmed a credit card on file which can be charged for fraud, or whatever).
What if I alter my code to give myself an unlimited credit limit, then spend as much as I want? As soon as you pass the credit limit encoded in the shared agreements, the next person you transact with will discover you’re in an invalid state and refuse the transaction. But what if they don’t want to refuse a transaction just because I’ve entered an invalid state? If two people collude to commit an illegal transaction by both hacking their code to allow a normally invalid state, the same still pattern still holds. The next person they try to transact with using untampered code will detect the problem and decline to transact. If you get everybody to collude with a new agreement, that sounds a lot like a software update. I’ll cover vulnerabilities in great detail in a later post — here I want to make sure the basic operation and implementation of mutual credit is clear.
Most modern community currency systems have been implemented as mutual credit, but I don’t know of anyone who has built a tokenless crypto-mutual-credit-currency yet, so let’s outline an approach to creating a basic one with minimal supporting infrastructure.
Minimum Viable Mutual Cryptocurrency
Instead of sending a check or wiring money through a bank or Western Union, hundreds of millions people transfer money through the hawala system. Hawala is a network of merchants and businessmen, which has been operating since the middle ages, performing money transfers on an honor system and typically settling balances through merchandise instead of transferring money. It works like this: a laborer building a skyscraper in Dubai wants to send some of his earnings home to his family in Egypt. He goes into a store in Dubai, gives the owner, who is a hawaladar, 1,200 UAE Dirham in cash, and provides a passphrase for collecting the cash. The hawaladar calls a hawaladar he knows in Egypt and arranges for an equivalent sum in Egyptian Pounds to be picked up using that password. The laborer calls his wife and tells her the password and at which store to collect the money. Each hawaladar makes a record on their own books of the debt, which is eventually settled by applying it as a discount to merchandise going from Dubai to Egypt.
Let’s look at building a minimum viable cryptocurrency with the hawala network as our use case. I’ll focus on the processing and data integrity of the transactions, not on user interface, because if the data is stable, and locally accessible, any kind or reporting and widgets could be made available via phone app, web interface, or whatever.
I’m making a few design decisions in the spirit of keeping this example simplified. To minimize key management infrastructure, each hawaladar’s public key is their address or identity on the network. To join the network you get a copy of the software from another hawaladar, generate your public and private keys, and complete your personal profile (name, location, contact info, etc.). You call, fax, or email at least 10 hawaladars who know you, and give them your IP address and ask them to vouch for you. (Yes, IP addresses are inconvenient but in a minimal example I want to show you don’t even need a domain name under the control of any group or individual.)
Once 10 other hawaladars have vouched for you, you can start doing other transactions because the protocol encoded in every node will reject a transaction chain that doesn’t start with at least 10 vouches. Having this requirement accomplishes a few things. It makes manufacturing fake accounts impractical (Sybil Attacks) and it begins building your peer routing table (which stores public keys, last-known IP addresses, names, locations, and contact info for other hawaladars that you interact with) while seeding your information with those other peers so you can be found by the rest of the network.
As described in the Mutual Credit section, at the time of transaction each party audits the counterparty’s transaction chain. This is when they confirm the initial 10 vouches and also validate that their counterparty’s balance(s) are in good standing — that they make good on their debts and are not too far indebted to want to transact with.
Hawala transactions often cross national boundaries and currencies. I’m not sure about the best way to approach conversion and accounting of many national currencies. You could store balances using a currency-neutral value-reference like the Terra Trade Reference Currency (TerraTRC) or Rogers International Commodities Index (RICI). For simplicity, I’ll stick with the current frequent practice of just recording the exchange rate of the national currencies at the time of transaction.
Our hawala crypto-clearinghouse protocol has two categories of transactions: some used for accounting and others for routing. Accounting transactions change balances. Routing transactions maintain network integrity by recording information about hawaladar. These two categories of transactions could be stored in a single chain, but it probably optimizes accounting operations and routing operations to store them in two separate chains for each node. Lets look at each in turn.
Accounting Transactions create signed data that changes account balances and contains these fields:
... Transaction type (Promise, Settlement, Transfer)
... Peer ID (public key) of sending hawaladar,
... Peer ID (public key) of recipient hawaladar,
... Sender currency,
... Recipient currency,
... Currency exchange rate (always structured as sender to recipient currency rate)
... Transaction amount (in sender currency. User Interface can render recipient amount using the exchange rate),
... Remittance passphrase (encrypted with receiver’s public key),
... Timestamp
... ID (hash) of sender’s previous transaction,
... ID (hash) of receiver’s prior transaction.
The final hash of all of the above fields is used as a unique transaction ID and is what each of party signs with their private keys. Signing indicates a party has agreed to the terms of the transaction. Only transactions signed by both parties are considered valid. Nodes can verify signatures by confirming that decryption of the signature using the public key yields a result which matches the transaction ID.
Promise: This is the normal way a hawaladar initiates a transaction. But now instead of calling the hawaladar on the recipient’s end after accepting a sender’s cash, they initiate a cryptocurrency transaction which notifies the receiving end of a transaction pending their approval and signature. This is used to show balances of outstanding promises owed between pairs of hawaladars. HA promises 1,200 to HB, so has a balance of 1,200 with HB. More promises to that hawaldar increase the balance, settlements between them decrease that balance. Promises to and settlements with other hawaladars have no effect on the balance between HA and HB. The receiving hawaladar can reject the transaction or accept by providing the hash of his previous transaction and signing it.
Settlement: When a hawaladar who has an outstanding promise to another applies a discount to the purchase and shipment of merchandise to them, this transaction accounts for the settlement of that amount against the prior promise. This reduces the balance owed to the receiving hawaladar. The receiving hawaladar could wait to sign the transaction upon receipt of the merchandise.
Transfer: The last accounting transaction is a transfer of crypto-credits. Instead of a pairwise balance between parties, there is just one overall balance of credits in each account. As described for mutual credit, each account starts at zero, and can go into whatever level of debt the hawaladar are willing to extend to each other. In this example, there are no preset credit limits. Transfers would be used for immediate settlement via crypto-credits in cases where two hawaladar don’t have enough relationship to trust a promise for future payment, or they don’t have relevant merchandise or distribution lines to be able to settle a promise. This is basically the normal transaction for spending cryptocurrency that all other coins do, but it is listed last here because the actual transfer of funds to settle a promise is less common than the transfer of merchandise in the hawala system.
Routing Transactions sign data that changes the peers list and contain these fields:
... Transaction Type (Vouch, Update, Denounce)
... Public key of profile sender (peer ID)
... Sender’s current IP address
... Hawaladar profile fields (Given name, Family name, Nick name?, Business name, Address (street, city, province, country, etc.), Geocoded location (latlong for mapping), Phone, Email, Website URL?, Merchandise — categories)
... Reference Data
... Timestamp
... ID (hash) of sender’s previous transaction,
... ID (hash) of receiver’s prior transaction.
As with accounting transactions, the hash of the above fields is used as the transaction’s unique key and the basis for the cryptographic signature of both counterparties. A transaction in a chain is only valid with both signatures attached, and those signatures decrypt to the transaction ID. In this case, the presence of the recipient’s signature simply means the peer profile information was accepted.
Remember, instead of making changes to account balances, routing transactions change a node’s local list of peers for finding each other and processing.
Vouch: The vouch transaction puts a profile entry on the transaction chain, adding it to the local list of peer profiles. When you audit counterparty transaction chains, you can also collect more contacts for your peers list.
Update: Similar to a vouch, but used to publish updates to peer profiles (IP address, contact info, etc.) without communicating that you are vouching for the person whose chain you are publishing the update to.
Denounce: If your app encounters a situation where you have a signed transaction in your chain but it is missing from the transaction chain of the counterparty, it warns you of the fraudulent behavior, stops the current transaction and generates a denounce transaction. Denounce publishes the fraud by putting the transaction ID in the Reference Data field. Then when you send it to another hawaladar, their app finds the referenced transaction in your chain and confirms the signatures, then checks the counterparty’s chain and if it is missing from that chain, they can sign a denunciation into their own chain. Once denounced, a hawaladar gets added to a node’s routing blacklist and no more transactions will route to them. (Note: The vulnerability that makes the missing transaction possible is addressed in the next section.)
I picked the hawala network as a use case for implementation of a simple distributed cryptocurrency for a few important reasons:
... The hawala system operates across national boundaries, currencies, and jurisdictions.
... It is a distributed network of mutual trust, people who would not likely trust a central authority like a government, bank, or company to control their records.
... In the hawala system, everyone already keeps and trusts their own separate records.
... Hawaladars are not anonymous. In fact their identity is crucial, since direct relationship is at the heart each transaction.
... They already extend credit to each other, so their thinking is readily compatible with mutual credit issuance.
... To illustrate how multiple types of currencies and different types of balances could be calculated and maintained.
... To illustrate how non-monetary transactions (updates to the peers list instead of updates to account balances) can be usefully integrated in transaction chains
... To keep the implementation simple because hawaladars have long-term relationships, so we don’t have to make the system absolutely invulnerable to short-term cheats which leave long-term evidence and get you blacklisted from the network.
More Scalable Security: Notaries + DHT
Since some communities don’t have much social accountability, relationship, or clear personal identity and reputation, the minimal implementation above may not quite be enough. It has a vulnerability which is why I added a “denounce” transaction above to blacklist cheaters. It would be possible for someone to hack the code on their node to “forget” their most recent transaction (drop the head of their chain), and go back to their previous version of the chain before that transaction. Then they could append a new transaction, drop it, and append again.
For example, suppose my chain shows I have a balance of 1,200 credits, I could do a transaction spending 800 of them, then use my hacked code to go back to the prior valid state (1,200), and spend 900 with someone else, and keep doing that. This is the distributed accounting analog to “double-spending” on a blockchain. However, each time I do this, I leave a copy of the transaction signed by me in the counterparty’s chain which my chain pretends I never did. So I’m leaving signed evidence of my fraudulent behavior all over the place. In a small community where I care about my relationships this is very unlikely to happen in the first place, and if it does, it would get caught quickly and have serious social consequences. In a large community, or one with looser social ties, it could take a while to be detected making it more likely for people to try it. So, next I’ll illustrate a nice way to remove this vulnerability.
After both parties have signed the agreed upon transaction, each party submits the transaction to separate notaries. Notaries are a special class of participant who validate transactions (auditing each chain, ensuring nobody passes through an invalid state), and then they sign an outer envelope which includes the signatures of the two parties. Notaries agree to run high-availability servers which collectively manage a Distributed Hash Table (DHT) servicing requests for transaction information. As their incentive for providing this infrastructure, notaries get a small transaction fee.
This DHT can also be used to manage public key infrastructure so that people can have persistent addresses distinct from their public key. This can allow keys to be revoked and updated without compromising ownership of a transaction history. Not only do notaries add transactions to the DHT, but they update each party’s PKI record with the hash for new head of their chain. Both countersign an outer envelope to their respective chains after an adequate threshold of peers showing this updated hash (M of N saturation of peers in the neighborhood of the hash of the PKI record). The nodes cannot complete their next transaction (append to their own chain) until their last transaction is notarized. This prevents removing the most recent link in the chain because your counterparty will reject your transaction if the head hash doesn’t match the one found upon lookup of your public-key.
This approach introduces a few more steps and delays to the transaction process, but because it operates on independent parallel chains, it is still orders of magnitude more efficient and decentralized than reaching consensus on entries in a global ledger. Any transaction should still be able to be completed within seconds, even on smartphone hardware. Meanwhile millions of simultaneous transactions could be getting processed by other parties and notaries with no bottlenecks.
There are other solutions to prevent nodes from dropping the head of their transaction chain, but the approach of having notaries serve out a DHT solves a number of common objections to completely distributed accounting. Having access to reliable lookups in a DHT provides a similar big picture view that you get from a global ledger. For example, you may want a way to look up transactions even when the parties to that transaction are offline, or to be able to see the net system balance at a particular moment in time, or identify patterns of activity in the larger system without having to collect data from everyone individually.
Conclusions
By leveraging Intrinsic Data Integrity to run numerous parallel tamper-proof chains you can enable nodes to do various P2P transactions which don’t actually require group consensus. Mutual credit is a great way to implement cryptocurrencies to run in this peered manner. Basic PKI with a DHT is enough additional infrastructure to address main vulnerabilities. You can optimize your solution architecture by reserving reserve consensus work for tasks which need to guarantee uniqueness or actually involve large scale agreement by humans or automated contracts.
It is not only possible, but far more scalable to build cryptocurrencies without a global ledger consensus approach or cryptographic tokens. This article should have provided enough of a framework for people who understand cryptographic tokens to build a tokenless cryptocurrency. In an effort to keep this post short, I’ll cover issues of vulnerabilities to the typical crypto attack vectors in a later post.
We should probably have a name for this type of architecture to distinguish it from blockchain. Multichains sounds like multiple blockchains (main with sidechains as already being used). Parachains for parallel chains? Indiechains for independent chains? Who’s got some good naming ideas?
If you want to jump into building one of these. You might want to leverage S/Kademlia to build a backbone for the DHT and PKI. Use an efficient elliptical curve cryptographic library for signing and building the hash-chains. You’d need to come up with a nice decentralized way to distribute self-signed versions of your code.
Great! Then you’d have ONE. One version. A currency deployed to run as a decentralized architecture, but created via a centralized group controlling the design and future features. So just like with bitcoin, although the blockchain may run in a decentralized manner, it turns out that what is centralized are decisions about updates, protocols, changes, new versions, and so on. Bitcoin’s ability to adapt, evolve, and meet changing needs has fallen prey to a small group holding sway over mining and evolution of the code, block size, and standards for the next release.
This exposes an important thing missing in the criteria for a cryptocurrency in the first section of the article. Item #3, about decentralization, needs to not only include decentralized issuance, operation, and accounting, but also the means to decentralize decision making about the ongoing evolution of the code itself. I wanted to put that in there at the beginning, but I don’t think there is enough shared knowledge or agreement about this fact yet. Which of course means, there are actually NO decentralized cryptocurrencies in existence, because none of them have effectively decentralized decisions about the evolution of their code yet.
So, that brings us to what we’re really building in Ceptr at the MetaCurrency Project…
We are not building a currency. We ARE building a platform for the decentralized evolution, deployment, and operation of many currencies and other distributed applications. We’re lowering the barriers to entry for groups and communities to create new distributed commons for sharing resources (think Uber, Lyft, CouchSurfing.com, AirBnB, Craigslist, Freecycling, etc) without a central corporation in the middle — able to be launched, hosted, and maintained by its participants — we call this a Sovereign Accountable Commons.
To achieve this, every one of those new commons will need multiple decentralized currencies embedded in the management and metrics of the system. Most will be non-monetary currencies, tracking ratings, feedback, reliability, timeliness, or other dimensions of reputation. Some will be monetary tokens for exchange of value. All need an infrastructure that doesn’t require a mountain of venture capital to launch and an army of geeks to maintain.
We believe this is the foundation of the next networked economy. And we want to ensure we’re not carrying over the same broken assumptions and patterns in the currency that perpetuate structural problems of inherent inequity. We can’t just replace the banking elite with a geek elite. We need to be able to build using the same organizational patterns as living systems.
So…. who wants build with us?
|
