Buzzword Bingo
Assign Onward (Ⓐ) endeavors to maximize value delivered to individuals. The Ⓐ ecosystem is*envisioned to become
a mesh of millions of small, open, public value store blockchain issues. Ⓐ enables anyone, anywhere to establish their own blockchain issue(s). Individuals are able to operate, control and understand their own blockchain(s). Direct proof of stake exchange*secure atomic exchanges recorded on one, two or more blockchains
between Ⓐ participants allows efficient*Due to redundancy, transparency, and communication among recorders, reliable blockchain recording is ten to 100x or more costly as compared to simple single point of failure transaction recording, even when using proof of stake. By controlling their own blockchain individuals control these costs keeping them appropriate for their individual use cases.
exchanges of value. Bridges to cryptocurrencies outside the Ⓐ ecosystem provide easy access to those asset pools.*Unfortunately, traditional cryptocurrency transactions incur traditional fees and delays. The Bitcoin transaction and Ethereum gas fee spikes of 2018 and 2021 underscore the importance of independence. US$150 to $300 to setup a single Ethereum NFT transaction? $2 to $50 for a single BTC transaction? Unacceptable.
Fine Words
But how? Trust. A newly minted open public value store blockchain has zero intrinsic value*Actually, negative value when you consider the costs of operation. This is one of many important reasons to abandon proof of work as a mechanism to establish trust.
. People buy intangible assets to exchange them for something of value in the future. How can you trust that an unknown asset will be valuable in the future? You can't. Past performance is no guarantee of future returns. No algorithm will protect an unsecured*and security comes at a high price: legal agreements, taxes to support the courts and police who enforce their judgements, assessment and insurance of collateral. Unsecured, and under-secured investments have a significant advantage - it's no wonder their average returns are so much higher than "safe" investments that may not even keep pace with inflation.
investment from the next flash crash. But, there are many transactions you trust on a daily basis. When blockchains go grassroots, they enter this realm of local trust.
Zero Investment
Zero investment transactions are one realm of safe and easy trust. When you are buying a sandwich anyway, you have nothing to lose by accepting a free loyalty card. There is value in the loyalty card, when it has enough credits accrued it is "worth" one free sandwich. Loyalty points issued as transferable tokens are exchangeable for all kinds of value.Immediate Payoff
Another easy trust transaction is one with immediate payoff. If a merchant accepts a token as payment immediately after you buy it, there's zero holding time. Zero holding time = immediate gratification = zero risk. If the merchant is well known to you, you may trust that they will also accept tokens in the future. With this confidence, you may hold their tokens as a store of value for longer. You may also sell these tokens you hold long term to others who might turn around and use them immediately. If you have obtained the tokens at a discount, you can realize a profit while still passing some of that discount on to the zero hold time purchaser.Transparency
Transparency is important. A merchant might "float" too many tokens on the market relative to their business turnover. Transparency in accounting should reveal an over-leveraged business before it has a problem. Tokens of over-leveraged businesses should lose value on the open market. Tokens of businesses with insufficient transparency should lose value due to that lack.Trust Locally - Trade Globally
Even though you can't sue the neighbor's 14 year old in small claims court, you still might trust them to mow your lawn. You might even trust them enough to give them an advance payment to buy some equipment. In the Ⓐ ecosystem, they might give you tokens in exchange, each good for one lawn mowing. Some 14 year olds end up behaving unreliably*this unreliable behavior may, or may not, be the child's fault. Things beyond their control, things they did not even know were beyond their control, can and do cause failure to deliver on promises for people of all ages.
, and may want to start over with a new trading identity later. More reliable*and/or lucky
14 year olds can leverage their history of reliable dealing in the future. An established history of reliable dealing has value to the owner of that history. Strangers could blindly trust an unknown identity for a small fraction of its value. Using trading histories, actuarial tables could characterize the risk of trusting unknown identities based on their trading histories.*One, of many, examples of how an actuarial table might be fooled would be a wealthy parent buying an existing trading identity for their untrustworthy child. The child might then turn around and squander the value of that identity by failing to deliver promised value for tokens they sell. Fortunately, out of character behavior for an identity should be easy to spot and the value of a trustworthy identity is quickly destroyed by bad transactions. This is why it is important to only trust an identity with a small fraction of its value in any given transaction.
For another example, take the classic lemonade stand. A young entrepreneur might pre-sell tokens for glasses of lemonade to friends for $0.50 each. Funds from these pre-sales buy the lemonade making supplies. At the retail sales point, tokens are for sale for $1.00 each.
*Although the retail sales point might accept cash or other tokens of value directly in exchange for the lemonade, exclusively exchanging lemonade tokens for lemonade sold provides a more clear accounting for current and future investors. Devious lemonade entreprenuers might inflate their lemonade sales figures through "sham purchase records" in hopes of boosting future investor confidence. Just like real world accounting fraud, this runs the risk of massively de-valuing identites associated with the fraud.
Unknown customers buy tokens on the open market. Anyone holding pre-sold tokens might redeem them for lemonade at the stand or sell them for a profit. Wizards of arbitrage might buy open market tokens early in the sales day for $0.75, reselling them later for $0.95. When the sale is over, the lemonade token issuer might repurchase outstanding tokens for $0.55.
Distributed Validation
In some instances, a blockchain owner might choose to process all transactions themselves. Disadvantages of this approach include:- Vulnerabiliy to deliberate attacks:
- Denial of service
- Network based server hacking
- Physical attack on the system hardware
- Attack or coersion of the people running the system
- Vulnerability to unintended faults:
- Local infrastructure failure, power or network
- Physical hardware failure
- Software / operating system based data corruption
- Natural events like lightning strike, flood, earthquake, tornado, etc.
- Administrative failures:
- Improper system configuration leading to data corruption/loss
- Inadequate backups to recover from other system faults
- Extended downtime due to poor maintenance planning
- Deliberate failures which may result in users' loss of value
Share the load
Many issues are addressable by eliminating single points of failure with multiple servers. Wide geographic distribution of the hardware helps. Heterogenous hardware / software stacks help prevent single cause system-wide failure.*When run by a single operator, heterogeneous hardware/software stacks can make things worse by "shallowing" the operator's depth of knowledge about each stack. Sharing the load across multiple operators enables each to have deep knowledge about the stack they use while allowing the system to benefit from diversity of stacks.
Of course, excellent administrative knowledge and integrity is valuable. In low transaction volume blockchains, all this redundancy means the hardware is underutilized. Hundreds of server operators can be more efficient serving hundreds of blockchains cooperatively.
Delegated Proof of Stake
Ideally, a pool of a hundred different blockchain operators who trust each other implicitly would share the load of processing and recording each other's transactions. The costs of operation could be shared according to traffic served, or perhaps just ignored to save the cost of accounting which might be more than any differential costs between chains of varying traffic loads. Not everyone will be fortunate enough to have a large pool of people they can trust like this.Some load sharing can be achieved on the "I trust two friends, and they each trust two different friends, who then trust two more unique friends each" model. The blockchain owner retains long term control of over 50% of the chain shares (probably closer to 75%), but temporarily delegates at least 50% of the chain shares to trusted cooperating transaction validators such that no single, or possibly double, loss of availability results in less than 50% of shares being available to validate new records
*For example, if 70.07% of shares are distributed evenly among 7 validators, then any 5 or more would have enough shares to meet a >50% signed validation requirement. On a larger scale, the same 70.07% of shares might be distributed evenly among 70 validators, any 50 or more of which can successfully validate transactions.
. When some shares are assigned to a validator who is less than 100% trusted, risk can be mitigated to a degree by making the assignment for a shorter time period. If the less trustworthy validator "flakes out," their shares automatically revert up the trust chain toward the blockchain owner who ultimately owns them and can reassign them to alternate validators with better availability.When transaction volumes are low, perhaps one per minute to one per week, large pools of validators can serve even larger pools of these low volume chains. Say: 600 blockchains which average one transaction per hour each might share a pool of 70 validators, any 50 of which are sufficient to validate each transaction
*While corrupt processors executing non-compliant processing software, processing double spends and other forms of improper dealing are a concern to constantly guard against, I anticipate "ghosting" where a transaction processor simply disappears without warning will be a much more common problem.
. The validators would be called on to handle one transaction per 6 seconds on average and might handle peak loads of 100x that volume. This would provide 70x redundant backup of all the blockchain's transaction histories and broad diversity of processing systems, geographic locations, operator knowledge, etc. If each transaction averages 3kbytes, 600 per hour would be creating 43 megabytes of transaction history data per day, about 16GB per year for all 600 low volume chains.Rather than siloed groups of 600 chains served by 70 validators, a more robust arrangement would be 60,000 chains served by a pool of 7000 validators, with each chain utilizing 70 of the 7000 validators. In this situation, most chain operators would not know most validators. A chain operator might utilize a mix of validators they personally know plus "professional" validator services which comptitively bid for the validation work, not only by price but also by reputation for reliable accurate service.
Expiring Value
In the above example, a typical validator serving 600 low volume blockchains might accumulate 16GB per year in transaction data. Archiving servers will keep all transaction records forever, but the concept of expiring shares*In brief: expiring shares may be exchanged for "fresh" shares for the cost of a simple transfer transaction, but will lose all value if left inactive for longer than the expiration period. Share owners who have "lost the private keys" to their shares lose all opportunity to retrieve the shares after the expiration period passes.
means that transaction processing servers never have to keep records beyond the expiration period speficied in the protocol. For a "typical" seven year expiration period, this might translate to less than 100GB in transactions that have to be referenced by a transaction processor for 600 chains. Fast response / high load capable transaction processors might be able to keep all records in RAM for fast access while archivers store them in flash. Chains which operate shorter expiration periods might be processed for lower fees due to their reduced storage requirements, although at some point the constant refresh transactions by share holders would increase traffic to an overall higher processing cost.
Zero Trust
As buzzwords go, Zero Trust is among the hottest of the current moment. While the level of trust between parties is somewhat defined by the protocol in use, most protocols used on the open internet should be designed to require as much cryptographically secure identification as needed to be at least 99.9999999999% certain that the transaction is being requested by the holder(s) of the private key(s) associated with the public keys involved in the transaction. When a message is returned from a server, it should similarly be signed to assure that the message is coming from the same server it was requested of*In some use cases encrypted communications are undesirable. However, for transactions of value, encrypting the request messages so they may only be read by the intended server(s) is another way to prevent attackers from being able to formulate bogus responses that fool the recipient into thinking they have received a response from the server they thought they were communicating with.
. Servers and clients should ignore any messages which do not carry proper identification of their communicating partner*Note that proper identification isn't (usually) a full name with government issued photo id or anything of that sort. Proper identification is a valid cryptographic signature corresponding to a public key identifier of some entity which is expected to be conducting transactions on the blockchain. In the case of open blockchains, this can include new / previously unknown identities for certain transactions, though most transactions will be referring to identities already established on the chains.
.Assign Onward
7 November 2021
MIT License
Copyright (c) 2021 Assign Onward
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Copyright (c) 2021 Assign Onward
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.