Topic: Building a World Reserve Currency (Read 206 times)
Bump
Hello everyone, this is my first time posting on bitcointalk, so if I break any informal rules or conventions of the forum I do apologize, please let me know and I will try to correct myself.
For the past year or so, I've been working on building a cryptocurrency that could, in theory, replace the US Dollar as a world reserve currency. This will never happen in practice, but I do believe the existence of a cryptocurrency like this would be economically beneficial to many people. If you'd like to read more about why, our website is here: https://www.commoncurrency.io/
I'd like to (as briefly as possible) summarize the feature set we're going for and why. We call the test we used to build this list "the Grocery Scenario", where the features of the cryptocurrency have to allow someone to theoretically use it at checkout at a grocery store. Bitcoin would fail this test, for example, due to the 10 minute / 1 hour confirmation time. The idea here is to come up with a feature set that makes it seamless and practical for everyday use. Our list (in no particular order):
So at this point, you're probably thinking two things; "ok, no shit, a network with all of these properties would be totally fantastic, how are you gonna do it?" or, optimistically, "I love the idea here, but so far you haven't shown any technical evidence that you can do it."
The website doesn't go into much technical detail, so I'll get into that now. The data structure we are building is called The Quantagraph. Many of these components interlace with each other to accomplish our big-picture goals, so this may seem disjointed, but this is just a high-level overview. You can think of it as a beta abstract to our whitepaper. Without further ado:
Privacy Architecture: Instead of using a balance / UXTO model, we opted to use an ownership-type model, where each object (called Quanta) represents some amount of currency. Each Quanta is contained within a parent container (we call them Blocks) and each Block has its own public-private key pair. A transaction in the network consists of updating the ownership of a Block, which can only be done by the current owner of the block. In order to obscure who actually owns a block, we can use a cryptographic mechanism that combines the public key of the owner with the public key of the Block itself, meaning there is no way to associate ownership with a particular block. Using some interesting threshold-cryptography + homomorphic key properties, this creates a network where transactions and balances for accounts are hidden. The architecture creates some interesting dilemmas, but so far we've come up with good solutions to them, and we think we've got this piece of the puzzle mostly figured out.
Coin Minting: Couple of key ideas here; we want the mint rate to be fixed from the start of the network, and we also want to incentivize and reward nodes running the network with new coins without encouraging spam. This is very hard to accomplish, but I think we've got it mostly down. When the network is started, it is seeded with some random hash; this hash is feed into a VDF (verifiable delay function) running on an ASIC. Knowing how long an iteration takes (for example, 1T iterations might take a week), we can set inflation windows based on iteration (we call these Minting Rounds). Basically, every 1T iterations (or about every week), the hash will be published to the network, and the Minting round ends. With each Mint block, accounts can stake their coins are receive new ones. Every transaction that is made by a Node gives that node a chance to get to stake the coins from that transaction during that Minting Round. Hence, the more transactions (and higher value transactions) your node processes, the more you can potentially stake, the more minted coins you will receive. There is crazy depth to go into here, but this is the high-level gist of it. We've got a lot of technical details to work out here, but we're comfortable in the general approach. We call these mechanisms the Atomic Inflation Clock (AIC) and Mint by Stake.
Consensus: The fun one. We are working on a variant of Federated Byzantine Agreement, specifically the Stellar Consensus Protocol designed by David Mazieres. In FBA / SCP, consensus is dictated by groups called Quorums, chosen by Nodes. In our approach, instead of Nodes choosing their Quorums, Quorums are decided dynamically and encoded into a transaction by the client themselves. Along with their public key, a user provides a list of servers / public keys that will form the Quorum, giving each user the power to choose which servers they trust. Our models so far show this approach has low-latency, is highly decentralized, sharded, and linearly scalable for high throughput. It allows for an optimization called Ledger Localization, where latency can be lowered by only using servers physically close to you while maintaining high security and consensus. This mechanism is called Embedded Quorum Encoding (EQE), and allows low-latency, high-throughput, secure transactions for public, permissionless networks. We still have some way to go with this one; our work right now includes building simulations of the protocol and using adversarial AI to attack and then improve the network, letting us analyze it at every possible angle.
That's where we're at so far. We are currently looking for highly-skilled technical help to continue our progress, and we are also looking for potential sources of funding (we are entirely self-funded right now). Please feel free to share this elsewhere and discuss any portion of this on the thread; if you want to contact us directly, DM or email at [email protected]. Happy new year!
For the past year or so, I've been working on building a cryptocurrency that could, in theory, replace the US Dollar as a world reserve currency. This will never happen in practice, but I do believe the existence of a cryptocurrency like this would be economically beneficial to many people. If you'd like to read more about why, our website is here: https://www.commoncurrency.io/
I'd like to (as briefly as possible) summarize the feature set we're going for and why. We call the test we used to build this list "the Grocery Scenario", where the features of the cryptocurrency have to allow someone to theoretically use it at checkout at a grocery store. Bitcoin would fail this test, for example, due to the 10 minute / 1 hour confirmation time. The idea here is to come up with a feature set that makes it seamless and practical for everyday use. Our list (in no particular order):
- Low Latency (< ~7s) / "Unlimited" TPS: The network should be able to consistently confirm transactions as fast as Visa (7s), and should be able to scale to accommodate a huge number of simultaneous users without major slowdowns.
- Strong Privacy: Transactions and account balances need to be obfuscated or hidden. If you are an employee being paid in our currency, your neighbor, knowing your public key, should not be able to see how much money you make or where you spend it.
- No Fees: There should never be any fees to move funds across the network. We have become accustomed to sending money over Venmo or Zelle without fees, and we need to maintain this convenience (this also eliminates the 2.9% fee for retailers, but this is a different conversation).
- Unconditional Security: If this network is to be used at a massive scale, it needs to be practically impossible to manipulate. This includes proofing against future hypothetical attacks (e.g. Quantum Computers).
- Open and Decentralized: Network participation should be as open as possible. This initially seems obvious, but it comes with a lot of technical difficultly; if anyone with an average machine and no specialized hardware can participate, the ledger needs to be sharded, work without ASICs, and not use an absurd amount of bandwidth.
- Controlled Supply and Distribution: Without getting into economics too much, the cryptocurrency should have a slowly increasing supply over time, or a consistent inflation rate per year. It's important that this rate is fixed from the start of the network (read more at https://www.commoncurrency.io/learn/better-world).
So at this point, you're probably thinking two things; "ok, no shit, a network with all of these properties would be totally fantastic, how are you gonna do it?" or, optimistically, "I love the idea here, but so far you haven't shown any technical evidence that you can do it."
The website doesn't go into much technical detail, so I'll get into that now. The data structure we are building is called The Quantagraph. Many of these components interlace with each other to accomplish our big-picture goals, so this may seem disjointed, but this is just a high-level overview. You can think of it as a beta abstract to our whitepaper. Without further ado:
Privacy Architecture: Instead of using a balance / UXTO model, we opted to use an ownership-type model, where each object (called Quanta) represents some amount of currency. Each Quanta is contained within a parent container (we call them Blocks) and each Block has its own public-private key pair. A transaction in the network consists of updating the ownership of a Block, which can only be done by the current owner of the block. In order to obscure who actually owns a block, we can use a cryptographic mechanism that combines the public key of the owner with the public key of the Block itself, meaning there is no way to associate ownership with a particular block. Using some interesting threshold-cryptography + homomorphic key properties, this creates a network where transactions and balances for accounts are hidden. The architecture creates some interesting dilemmas, but so far we've come up with good solutions to them, and we think we've got this piece of the puzzle mostly figured out.
Coin Minting: Couple of key ideas here; we want the mint rate to be fixed from the start of the network, and we also want to incentivize and reward nodes running the network with new coins without encouraging spam. This is very hard to accomplish, but I think we've got it mostly down. When the network is started, it is seeded with some random hash; this hash is feed into a VDF (verifiable delay function) running on an ASIC. Knowing how long an iteration takes (for example, 1T iterations might take a week), we can set inflation windows based on iteration (we call these Minting Rounds). Basically, every 1T iterations (or about every week), the hash will be published to the network, and the Minting round ends. With each Mint block, accounts can stake their coins are receive new ones. Every transaction that is made by a Node gives that node a chance to get to stake the coins from that transaction during that Minting Round. Hence, the more transactions (and higher value transactions) your node processes, the more you can potentially stake, the more minted coins you will receive. There is crazy depth to go into here, but this is the high-level gist of it. We've got a lot of technical details to work out here, but we're comfortable in the general approach. We call these mechanisms the Atomic Inflation Clock (AIC) and Mint by Stake.
Consensus: The fun one. We are working on a variant of Federated Byzantine Agreement, specifically the Stellar Consensus Protocol designed by David Mazieres. In FBA / SCP, consensus is dictated by groups called Quorums, chosen by Nodes. In our approach, instead of Nodes choosing their Quorums, Quorums are decided dynamically and encoded into a transaction by the client themselves. Along with their public key, a user provides a list of servers / public keys that will form the Quorum, giving each user the power to choose which servers they trust. Our models so far show this approach has low-latency, is highly decentralized, sharded, and linearly scalable for high throughput. It allows for an optimization called Ledger Localization, where latency can be lowered by only using servers physically close to you while maintaining high security and consensus. This mechanism is called Embedded Quorum Encoding (EQE), and allows low-latency, high-throughput, secure transactions for public, permissionless networks. We still have some way to go with this one; our work right now includes building simulations of the protocol and using adversarial AI to attack and then improve the network, letting us analyze it at every possible angle.
That's where we're at so far. We are currently looking for highly-skilled technical help to continue our progress, and we are also looking for potential sources of funding (we are entirely self-funded right now). Please feel free to share this elsewhere and discuss any portion of this on the thread; if you want to contact us directly, DM or email at [email protected]. Happy new year!
Jump to: