An architecture for the Internet of Money
- by Meher Roy.
Satoshi Nakamoto’s great invention of Bitcoin can be appreciated as having 2 distinguishing features:
Effort has been directed towards architecting a parallel financial system with bitcoin the currency as a base layer. The driving force are flexibility benefits of cryptographic ledgers enabling new use cases like Multi-signature accounts, Decentralized exchange, Machine to machine transactions etc. This paper analyzes applications of cryptographic ledgers in the current financial system and aims to stimulate the discussion:
What are the speed, cost and flexibility advantages that can be realized if financial institutions tracked asset and liability balances utilizing public decentralized cryptographic ledgers with basic ledger contracting capabilities?
Such ledgers enable new ways to build Real Time Gross Settlement systems like CHAPS and FedWire; Deferred Net Settlement systems resembling ACH, Bacs and correspondent banking; foreign exchange markets; stock exchanges and other pillars of the financial system. This article encapsulates these disparate elements into a coherent layer based framework christened “The Internet of Money”.
Perceived benefits from the Internet of Money will be enumerated along with system descriptions. These benefits form the motive for the proposal.
Inspired by the OSI layer model, a framework for the Internet of Money follows in Figure 1.
Subsequent sections detail requirements and capabilities at each layer. The paper can be broken down into following segments:
Finally, notes on color coding:
Conventional ledgers are databases that track value balances corresponding to accounts. They permit clients to initiate operations subtracting X units from own account and crediting the same to a different account. To be a valid operation, the client’s account must possess a balance greater than X. Figure 1 is a visualization for 2 Citibank clients, Alice and Bob. Alice initiates the payment.
To above operation set, Bitcoin adds richness through ledger contracting. Ledger contracts are accounts that hold balances and operate with predefined rules. Entities external to Bitcoin, like Alice and Bob, cannot manipulate ledger contracts without fulfilling rules set during contract creation. This is implemented by having Bitcoin nodes reject transactions violating contract rules.
For instance, consider a scenario where Alice wants to transfer bitcoin to Bob with the proviso that Bob can spend the funds only after 31 Dec 2015. This is implementable by creating a ledger contract that holds the bitcoin balance temporarily. A transaction from Bob, claiming held bitcoins will succeed only after the date set in the ledger contract. Figure 3 plots such a transaction flow.
The ledger contract should be imagined as a neutral automated third party mediating a transactional relationship between Alice and Bob. Readers must bear in mind that above diagram is an abstraction, and Bitcoin is implemented differently.
Figure 4 provides a second illustration. Alice is a buyer and Bob is a seller; goods traded have a long delivery time. Trent is a third party trusted by both Alice and Bob. At purchase, Alice stores purchase value in a ledger contract, with the condition that:
Figure 4 shows transaction flow during successful sale and delivery. The ledger contract acts as neutral automated third party mediating a transactional relationship between Alice, Bob and Trent.
Bitcoin ledger contracts are coded using a stack-based bytecode language called ‘Bitcoin script’. Each ledger contract has code and a temporary data structure (stack) associated with it.
The Bitcoin contracting system has 2 significant limitations:
Figure 5 plots a hypothetical scenario highlighting limitations. Alice wants to leverage a ledger contract to exchange Bitcoin for Dogecoin. She creates a ledger contract, and loads it with bitcoins desired for exchange. The contract is coded such that, when a counterparty furnishes Proof of Dogecoin payment to Alice’s address; the contract releases bitcoins to an address chosen by the counterparty.
The value-blindness limitation implies that Bob, a counterparty, must exchange exactly the amount Alice loaded in the contract. Counterparties could desire a smaller exchange size, and therefore prefer to retrieve a fraction of funds embedded in the ledger contract. This operation is not possible with a single Bitcoin ledger contract.
Assuming fractional exchanges are possible, the Bitcoin ledger contract must store proofs of payment that have been utilized. If such storage is absent, the counterparty can furnish the same proof of payment repeatedly to drain the contract unfairly. Lack of storage and value-blindness constrains applications such as decentralized exchange.
The previous example is solely intended to highlight limitations. It has other unstated flaws. Decentralized exchange with bitcoin would be better implemented through a different construct called Atomic Cross Chain Trades. It suffers from the same value-blindness limitation.
Next section highlights the elegant Ethereum approach, and forms the basis for protocols described herein.
The Ethereum project introduces many innovations, of which the following are important for this proposal:
Utility of the above is demonstrated in Section 7. Hence examples are avoided here.
Other Ethereum innovations, being peripheral to our discussion, will be engineered away in section 12:
The combination of points b. and c. mean that infinite loops can potentially be triggered while updating the Ethereum ledger. The Halting problem places a limitation on evaluating whether an arbitrary script will terminate in finite time and prevents network nodes from rejecting transactions resulting in infinite loops. Ethereum uses its transaction fee structure to prevent and incentivize participants from submitting transactions triggering infinite loops.
The risk introduced by latter innovations is two-fold:
Section 12 deals with an approach to remove risk while enjoying certain benefits from Ethereum’s architecture. The driving force is to reduce risk and complexity at seed stages of proposal implementation.
Sections 6-10 assume complete set of Ethereum ledger contracting abilities are valid.
The ledger layer is built using a protocol that enables a single party or group of parties to create ledgers and issue assets as required. Each ledger has an issuer of asset, a number for ledger identification, and an identification for the asset issued.
Minimal properties for ledgers are:
Section 11 provides justifications for aforementioned properties. Hyperledger enables maintenance of ledgers through the Practical Byzantine Fault Tolerance consensus algorithm, and is an example of a ledger layer protocol.
Bitcoin and Ethereum projects assume that network nodes are anonymous. Here, we assume that identity of consensus pool nodes is known, and this is a major point of divergence from other cryptocurrency projects. In addition, the focus is to propose a financial system interoperable with commodity backed currencies, informational commodities like bitcoin, fiat money, shares and other assets. Finally, the proposed system does not necessitate creation of any new currency or asset.
Figure 6 visualizes a section of the ledger layer. Ledgers with the same asset type possess the same color. A black dot inside a colored circle stands for an account. Accounts corresponding to asset issuers are shown. Issuer names have been chosen to aid with visualization. Large banks and firms, being naturally and rightly conservative, are not initial customers for technology described herein.
If Carol holds assets on ledger 4, we assume that a trust relationship exists between her and the issuer of ledger 4 (Wells Fargo).
The case of Alice, holding USD assets on ledger 1 and wanting to transfer them to Bob, a customer of the same issuer on the same ledger, i.e intra-ledger transfer, is trivially resolved. Next section will consider inter-ledger transfers.
This layer is tasked with resolving two situations faced by Alice and Bob:
Situation 1: Alice possesses V USD issued by Citibank on ledger 1, and wants to exchange them for W Euros held by Bob on ledger 2. Fidor bank is the issuer of Euros. Section 7a tackles this scenario.
Situation 2: Alice holds V USD issued by Citibank on ledger 1, and wants to make a payment to Bob. Bob is a USD Wells Fargo customer on ledger 2. Sections 7b, 7c and 7d present resolutions.
The layer works by deploying one of four protocols. Section 7a deals with Decentralized Exchange Protocol (DEP), 7b with Static Liquidity Payment Processing Protocol (SL3P), 7c with Real Time Gross Settlement Protocol (RTGSP) and 7d with Deferred Net Settlement Protocol (DNSP). Micro-transaction payments are considered in Appendix A.
7a. Decentralized Exchange Protocol (DEP)
Decentralized Exchange can be implemented as two interlocking ledger contracts created to mediate an exchange relationship. Figures 7a, 7b, 7c and 7d provide a visualization. For convenience, we name the two contracts as Dispensing contract and Accepting contract. The protocol proceeds in four phases and assumes Alice creates an offer accepted by Bob as a counterparty:
Phase I: Alice creates Accepting and Dispensing contracts on the two ledgers
Phase II: Bob credits Accepting contract and claims value from Dispensing contract
Phase III: Dispensing Contract releases funds to Bob and sends claim message to Alice
Phase IV: Alice uses claim message to extract funds from Accepting contract
Capabilities of Dispensing and Accepting contracts
Aforedescribed flow assumes that the exchange is atomic i.e. value V in Dispensing contract is claimed in a single transaction. This is modifiable to include scenarios with Bob claiming a fraction of the offer by transferring value X (X<W) to Accepting contract in phase II.
Additionally, there are two edge cases to be considered:
Although DEP is trustless and peer-to-peer, there exists a niche for information services tracking exchange offers on different ledgers. Services can query consensus pool nodes for offers and verify that ledger contracts are structured correctly. Counterparties can remunerate services to access updated information. Purely informational services are the Internet of Money equivalent for order books.
DEP is powerful as it eliminates the need for mediating parties in currency and share exchanges. Figure 8a plots parties and relationships required in conventional share exchanges between Alice and Bob. Figure 8b with DEP delivers a contrast to 8a, and underscores the potential for low cost exchanges. A similar parallel exists for currency exchanges.
The role of the Central Securities Depository and Custodians is replaced by the public Apple shares cryptographic ledger. Brokers and Stock exchanges are replaced by information services tracking offers on ledgers. There is no requirement for a Clearing House as Alice and Bob bear no counterparty risk and protocol execution takes ~4 seconds for Bob.
Finally, DEP serves as a bridge connecting fiat currencies and informational commodities such as ether and bitcoin.
7b. Static Liquidity Payment Processing Protocol (SL3P)
Unlike Decentralized Exchange, which is an evolutionary improvement over the current system, SL3P is a new modality of payment processing.
Consider the situation in Figure 9a. Alice possesses V USD issued by Citibank on ledger 1, and wants to make a payment of the same value to Bob. Bob is a USD Wells Fargo customer on ledger 2. There also exists Carol, a party unrelated to Alice and Bob, holding balances on both ledgers. Carol:
Following transaction set, pictorially depicted in Figure 9b, resolves the payment:
SL3P leverages two ledger contracts to enable multiple desirable properties with above transaction logic:
The protocol proceeds in four phases:
Phase I: Carol opens an SL3P channel by creating contracts on both ledgers
Phase II: Alice credits SL3P contract 1 and claims a payment to Bob from SL3P contract 2
Phase III: SL3P contract 2 verifies claim and makes a payment to Bob
Phase IV: Carol uses state change message to render funds withdrawable by her
Capabilities of SL3P contracts
The protocol can also work in the reverse direction. Because SL3P contracts are symmetric, Dave can initiate a payment from Ledger 2 with the destination being Eve on Ledger 1.
Payment processing is converted to a peer-to-peer format paving the way to a competitive market. The protocol is a combination of 2 transfers and contract computation, and therefore can be executed in ~4 seconds.
Domestic correspondent banking can be visualized by assuming Carol as one of the 2 interacting issuers. For instance, assume issuer for ledger 1 is Issuer 1. If Issuer 1 opens an SL3P channel with deposits on ledger 2, resulting structure is the equivalent of a domestic correspondent banking relationship. Readers should bear in mind that domestic corresponding banking is increasingly an anachronistic solution.
SL3P improves over Deferred Net Settlements because issuers do not assume credit risk for payment processing. To mitigate against credit risk in Deferred Net Settlements, issuers are required pledge collateral with the national clearing house. SL3P introduces no such necessity.
Another key advantage is the creation of new pools of liquidity for payment processing. Liquidity cost is the determining factor for pricing of RTGS payments. A core assumption in the current system is that liquidity needed for payment processing is furnished by issuers. SL3P can break this assumption, build a larger liquidity pool and therefore result in cheaper payments.
7c. Real Time Gross Settlement Protocol (RTGSP)
Similar to SL3P, RTGSP solves the problem: Alice possesses V USD issued by Citibank on ledger 1, and wants to make a payment of the same value to Bob. Bob is a USD Wells Fargo customer on ledger 2.
RTGSP is the proposal’s equivalent of the FedWire system used for high value transfers in the United States. It allows interacting issuers to settle inter-bank liabilities accruing from payments on the FR ledger. Figure 11 plots the FedWire transaction flow.
Alice initiates a FedWire credit, with Citibank acting as the OFI and Wells Fargo as the RFI. Citibank debits Alice’s account immediately and Wells Fargo credits Bob’s account after a few minutes.
Internally, Citibank submits a credit request to the FR, which then forwards it to Wells Fargo. The FR processes a settlement transaction sending money from Citibank to Wells Fargo on the FR ledger. As the transaction happens in real time and the complete settlement amount is transferred in gross, this modality of payment processing is called a Real Time Gross Settlement (RTGS). Citibank and Wells Fargo assume no credit risk.
This point onward, we refer to Citibank as Issuer 1, and Wells Fargo as Issuer 2. The objective is to demonstrate a payment protocol assuming Citibank, Wells Fargo and the FR operate cryptographic ledgers.
SL3P provides a route as sketched in Figure 12. Issuers open one-way SL3P channels between the FR ledger and ledgers tracking their own assets. An SL3P channel maintained by Issuer 2 is plotted in Figure 12. On ledger 2, Issuer 2 creates assets and loads one end of the channel, sketched in dark pink.
‘One-way SL3P channel’ refers to a modified construction where payments flow only in one direction. This is a simple modification of ledger contracts from section 7b.
Alice initiates the transaction by transferring value V to Issuer 1. The transaction contains data specifying destination ledger and Bob’s account. This effectively destroys assets held by Alice and issued by Issuer 1.
Assuming Citibank has requisite liquidity, it transfers value V to SL3P contract maintained by Issuer 2 on the FR ledger. Next, it pushes a proof of payment to other side of the channel on ledger 2, and claims a transfer to Bob’s account.
Assuming sufficient contract balance, ledger 2 SL3P contract verifies proof of payment and completes the transfer. Issuer 2 keeps loading funds periodically into the contract to keep RTGSP transfers flowing. In case of insufficient contract balance, Issuer 1 can re-try or claim back funds from the other end of the channel.
Although the previous set demonstrates that RTGSP is feasible, it does not tackle the central challenge of an RTGS system: liquidity management. Appendix B considers methods for the same.
RTGSP could enable automation of FedWire and other Gross settlement systems, with the role of the FR reduced to being a pure issuer. The system can stay operational as long as Consensus Pool for the FR ledger is reachable. Currently, use of the FedWire system is restricted to between 09:00 and 18:00 ET in the United States.
Decentralization of the FR ledger and RTGS system can be a good operational risk reduction and business continuity policy. Nodes can be distributed geographically, made dependent on different power systems, and data redundancies / backups created. In general, all Systemically Important Payment Systems tangibly benefit from decentralization through operational risk reduction.
7d. Deferred Net Settlement Protocol (DNSP)
DNSP solves the same problem as SL3P and RTGSP: Alice possesses V USD issued by Citibank on ledger 1, and wants to make a payment of the same value to Bob. Bob is a USD Wells Fargo customer on ledger 2.
Instead of payment clearing and settlement being a transfer on the FR ledger like RTGSP; DNSP results in the creation of a debt obligation from Citibank to Wells Fargo. Multiple obligations are aggregated, and net amounts are transferred between issuers as bilaterally agreed on the FR ledger. Payment clearing is the creation of inter-issuer debt obligation and payment settlement is the transfer on the FR ledger. DNSP defers payment settlement to a timepoint after payment clearing. The protocol has a requirement for inter-issuer trust unlike the others.
A combination of DEP, SL3P and RTGSP can be sufficient to handle a large part of banking transactions. DNSP is included for the sake of completeness. It is the equivalent of the ACH system in the United States.
Central to DNSP is the construct of traversal transactions pioneered by Ryan Fugger and the Ripple project. A traversal ledger, which enables traversal transactions, has following properties in addition to ledgers hitherto considered:
Figure 13 considers a US dollar traversal ledger, with 4 participants: Eve, Frank, Gary and Harry. Figure 13a, on the left, shows the current status of trust lines. A line originating at Frank and terminating at Eve with value M USD signifies Frank’s approval to have Eve owe him a maximum of M USD. Participants can alter trust line values dynamically.
Figure 13b, on the right, shows a traversal transaction payment from Eve to Harry worth W USD. Before payment, we assume none of the participants owe each other any money. After the transaction, Eve owes Frank W USD, Frank owes Gary W USD and Gary owes Harry W USD. Harry accepts this as a payment of W USD.
Net balance for each account equals funds owed to participant minus funds owed by participant. Net balance for Frank and Gary remain unchanged by the transaction. Gary and Frank do not actively participant in the transaction. Harry’s role is to verify the payment.
Because the ledger may contain more participants; the consensus pool computes the optimal payment path, sketched through red arrows in 13b, and adjusts balances autonomously.
For DNSP, we assume multiple issuers are part of a domestic traversal ledger. Traversal ledger becomes a payment clearing mechanism, with trust lines negotiated between pairs of issuers. DNSP proceeds in 2 phases, sketched in Figure 14a and 14b.
Phase I: Alice initiates payment and Issuer 1 reserves value V on ledger 2
Phase II: Issuer 1 transfers value (V - W) on clearing ledger and claims payment to Bob
In its current state, DNSP suffers from one deficiency. During Phase I, escrow contract may be depleted and contain value less than W. This can lead to Issuer 1 suffering a loss of W. Deficiency can be tolerable due to following reasons:
Debt obligations between issuers arising out of DNSP are settled on the FR ledger as bilaterally agreed. Settlement is a simple transfer from one issuer to another on the FR ledger, and is therefore not illustrated.
DNSP separates the clearing and settlement processes, resulting in a speedy transfer (~10 seconds) to Bob’s account. Many current systems, like ACH in the United States and Bacs in the United Kingdom, clear and settle transfers once a day. Hence, DNSP could be an improvement. Additionally, the ‘trust line design’ of clearing ledger removes the 2-tiered centrally operated membership systems present today. Any issuer can take part in clearing as long as it is able to obtain a trust line from another issuer.
Being a Systemically Important Payment System, decentralization of the Clearing ledger reduces operational risk and can be a good business continuity approach.
Previous section with its characteristic proliferation of protocols can appear daunting from the perspective of implementation. This apparent complexity is a result of interactions in the fiat system, and can be reduced to an elegant simplicity at the implementation level.
A key observation is that ledger contracts utilized for DEP and RTGSP are derivatives of SL3P. Figure 15 expresses the statement.
For the above statement; perhaps the challenge is to visualize how Dispensing and Accepting contracts are derivatives of the SL3P contract. Please refer to Section 7b and replace Carol with Alice; Alice and Bob with Bob. In addition, instead of the ledger dealing with a single currency, have them deal with different currencies. Transaction flow resulting from these substitutions is a currency exchange.
We can elect to stop referring the protocols by different names, although the author believes it is helpful to differentiate.
At the pathfinding layer, protocols described previously are treated as atomic operations of 5 types:
Any global payment, remittance, asset purchase or exchange originating at one cryptographic ledger and ending at another can be broken down into atomic operations of the 5 types mentioned above. The pathfinding layer is tasked with calculating the optimal set of atomic operations to be executed for the desired value transfer or exchange.
Small world networks such as social networks provide short connecting distances between any 2 nodes. We suppose, without proof, that the Internet of Money financial network will also be a small world network. Practically, this means that any global transfer / exchange of value can be executed in maximum 5-7 atomic operations. A maximum transfer time of 1 minute globally looks acceptable at this juncture.
The raw data for the pathfinding algorithm is of following types:
The analogue for the pathfinding layer in the architecture of the Internet are routing protocols such as RIP, OSPF and BGP. Communication routing through the internet requires routers and nodes to broadcast reachability information continuously; and can be visualized as a quasi-distributed algorithm across multiple routers / nodes.
In the Internet of Money, centralized services where a routing query can be sent and an optimal path received look feasible. Data gathering and computation are outsourced to these services relieving the clients from workload. Consideration of exact algorithm to calculate optimal paths from raw data is left for a future article.
Once optimal paths are received by the client, it proceeds to execute the atomic operations resulting in global value transfer and exchange.
Figure 15 is a visual representation of pathfinding. Alice owns Swiss Franc assets on the UBS ledger and wants to purchase Apple shares. She issues a routing query to pathfinding server. Pathfinding server has a database of RTGSP networks, DNSP networks and contracts on different ledgers. It evaluates 3 alternative paths, indicated in the figure, that Alice could take. It forwards the optimal path to Alice after accounting for payment and exchange fees.
Alice’s client has protocol software to execute actions required for atomic operations. She does the same and achieves the desired asset purchase.
The contract layer enables the intersection of value and arbitrary code running to alter value balances. This would be implemented through the construct of programmable oracles conceived by the Codius project and Gavin Andresen.
From the vantage point of the contract layer, lower layers act as a singular global ledger. This abstract ledger can hold balances and move any assets in under 1 minute.
Funds intended for a smart contract are channelled into an M-of-N multi-signature account controlled by a set of specialized entities (programmable oracles) and the contract code is simultaneously sent to all of these entities. Every time contracting parties wish to send a message to the contract, they direct the message to the oracles. The oracles run the code to compute participant balances. If code execution leads to withdrawal of funds from the contract to some particular address, then the oracles circulate a transaction transferring the funds and sign it. Fund transfers are handled by the lower layers of the Internet of Money. Figure 17 visualizes the contract layer.
Section 12 deals with quantifying differences between ledger contracting and the contract layer. In general, ledger contracting is used to build Payment and Exchange protocols. Other smart contract use cases are implemented at the Contract Layer.
As an example, an application is a London brent crude oil futures contract between Alice and Bob. The contract is represented by computer code executed by the oracles; these entities fetch external data to compute new balances for Alice and Bob at settlement time. After code execution, balances are credited back to Alice and Bob using lower layers of the Internet of Money.
A second example is sophisticated buyer and seller intermediation of the type sketched in Figure 4. Alice, the buyer, and Bob, the seller, would like payment amount to depend on time taken for successful delivery. Bob needs to be penalized for longer delivery times. A contract is created and Alice loads funds. Contracting service verifies proof of goods delivery and pays Bob accordingly.
A third example is an auction for digital assets. Contracts can be structured to carry out rules for an auction if ownership of digital asset or title are handed over to the programmable oracles.
Parallel to the TCP-IP protocol suite, this layer houses applications and user interfaces for consumers. In particular, the following appear commercially significant:
Debit and credit based payment networks
Although the Internet of Money is foreseen to deliver an order of magnitude improvement in speed of value transfer globally, some use cases require payment networks like Visa and Mastercard. Such cases are:
It is feasible to reduce settlement risk borne by payment networks as a result of fast payment and exchange times facilitated by this technology. Visa’s estimated settlement exposure stood at $53.8 billion on September 30, 2013.
Finally, the contract layer enables new methods of arbitration like double deposit escrow.
Futures, options, derivatives, prediction and other markets
One key design principle behind this article is the principle of unbundling: Each function for the Internet of Money is operated by distinct specialized entities. For example, consensus pools specialize in ledger maintenance, banks in asset issuance and regulations, pathfinding services in pathfinding, and other firms in contracting and applications.
The contract and application layers enable competitive markets for development of futures, options, derivative and prediction markets. Different services can specialize in slices of these markets.
Games of Hazard as smart contracts
As a demonstration, the game of Roulette can be visualized as a contract with the following logic:
We state, without proof, that all games of hazard including poker, blackjack are implementable as smart contracts.
The abstract ledger is a strong foundation to build Decentralized Applications. Current approaches have relied on creating new tokens for accessing services such as decentralized storage, mesh networking and reputation systems. The Internet of money provides an alternative to build token-less DApss. As an example, a design outline for a hard disk space sharing DApp is considered in Appendix C.
This section will consider some issues to develop a better understanding of minimal requirements at the ledger layer (Section 6):
Why can’t ledgers be controlled by issuers?
Payment and Exchange protocols are structured such that entities different from the issuer execute transactions on a ledger. An example is RTGSP: Issuer 1 is routing a payment to Bob on ledger 2 without involvement from Issuer 2. Now assume that a server belonging to Issuer 2 is the only node in consensus pool maintaining ledger 2.
Issue with the above is that Issuer 2 can possibly create a new ledger history, inconsistent with the previous history, claiming that Issuer 1 never completed the payment to Bob. If old history data is unavailable to Alice and Issuer 1, there may not be a good way to dispute the new history. The legal cost of disputing could be larger than expected reparations.
Solution posited is to have multiple parties maintain ledgers through a decentralized consensus process. Through decentralization, issuers and consumers can be assured of impartial ledgers. Hence:
Decentralization serves to increase confidence in the impartiality of ledgers. The more diverse and numerous the composition of nodes in consensus pool maintaining a ledger, stronger is the guarantee of impartialness.
Tradeoff inherent with decentralization is efficiency. Nodes need to verify each other’s processing and communicate to arrive at consensus. This necessitates higher computation and bandwidth than an equivalent centralized ledger.
Decentralization for decentralization’s sake is not a strategy to be advocated. The article’s perspective is:
Extent of decentralization required for a particular use case is an optimization problem
Factors impacting efficiency, defined as transactions processed per NPV dollar of investment in nodes, are:
Factors affecting confidence in impartiality of ledgers:
Amount of confidence required for a ledger depends on the value at risk. The strategy advocated is to:
Aim for an optimal balance between value at risk, efficiency and confidence in ledgers.
For instance, a small homogenous pool may be suitable for tracking loyalty points scheme of a 2-store grocery chain. Citibank’s ledger will benefit from a high degree of confidence / decentralization.
The optimal ledger layer protocol
Because each use case has a different optima for pool composition, number of nodes etc., the ledger layer protocol needs to be extremely flexible. There should not be restrictions on usage, openness and development of the protocol. Consensus process should deliver best feasible efficiency in a large cross-section of scenarios.
The Hyperledger project is a pioneer in this direction. Hopefully, other projects with similar objectives will follow.
Why should ledgers be public?
All payment and exchange protocols described herein depend on ledgers being public. Counterparties cannot view offers or verify payments on private ledgers.
If applications posited are valuable, counterbalancing privacy enhancing technologies need to be developed. In parallel, Governments need a method to monitor financial transactions. Investments in the Internet of Money can be viewed as bets that the cost of ensuring financial privacy will not exceed consumer benefits accruing from applications such as decentralized exchange.
Provided the privacy aspect can be resolved, the author is excited about potential advancements to theories of economics and crises management resulting from open access to transaction data globally.
On multi-signature accounts
In addition to the consumer security enhancing benefits of multi-signature accounts, recall that the contract layer requires the same to assure trustworthy execution. Smart contracts should ideally be verified and executed by multiple distinct programmable oracles. A pool of oracles needs to own joint multi-signature accounts for daily operation.
On time-alignment mechanism for a consensus pool
A time-alignment mechanism provides a method for pool nodes to consistently agree on the same clock time with an acceptable skew tolerance (up to 1 sec is admissible). Good design emanates from the desire to create powerful systems with minimal components. This paper has utilized time based transactions for DNSP and MTXP (Appendix A). Methods to do away with building a time alignment mechanism while retaining functionality need to be discovered.
The fundamental advantage of cryptographic ledgers
This paper posits that cryptographic protocols built utilizing cryptographic ledgers enable the formation of low trust financial relationships between participating issuers and consumers. Low trust relationships serve to reduce transactional and exchange costs, which can be passed down to consumers as a net saving.
Implementation of pull based payments
The use of digital signatures lead all cryptographic ledger systems to be push based. Current implementation of ACH enables pull based ACH debits, and it has multiple applications like insurance payments, loan installments, utility payments etc.
A mechanism to enable such applications can be built at the contract / application layers. Consider the situation of Alice, a customer to Bob, a utility company. Alice and Bob create a smart contract hosted by mutually trusted oracles; and Alice loads the contract with funds intended for monthly utility payments. The contract contains rules letting Bob withdraw upto a certain amount every month.
Implementation of an Identity and Anonymity layer
Compliance with regulations creates a problem of duality: Identities behind public keys must be accessible to certain organizations (issuers for example) yet should resist unmasking methods such as taint analysis. A consistent method of verifying issuers and ledgers is also a prerequisite.
The author Meher Roy can be reached at:
Email 1: firstname.lastname@example.org
Email 2: email@example.com
Special thanks to Tim Makarios for pointing out errors, and suggestions regarding Responsible Traversal Transaction Protocol.
Possible updates for version 0.4
Alignment with Hyperledger whitepaper
Hyperledger is the best example of a ledger layer protocol and the aim is a pair of 2 compatible papers (Hyperledger white paper + the current document).
Consideration of Responsible Traversal Transactions Protocol as a better DNSP
Details can be found at:
Completion of appendices A, B and C
Appendix A: Microtransaction Protocol (MTXP)
Appendix B: Methods for RTGSP Liquidity Management
Appendix C: An architecture for Decentralization Applications (DApps)