An Internet Architecture for Currency

This paper is translated from Meher Roy's Google Docs

Written by: Meher Roy (The author is one of the developers of HyperLedger and can be found on Quora)

Translation & Proofreading: Chu Xia Hu, Shen Zhihui, Chen Hao

1. introduce

Satoshi Nakamoto’s greatest invention, Bitcoin, can be credited for two distinct features:

1. Bitcoin is a public, decentralized, cryptographic ledger that also has basic ledger capabilities.

2. A cryptographic ledger tracks new bitcoin balances.

Parallel financial systems based on Bitcoin are being built. Crypto ledgers have many advantages in flexibility. For example, multi-signature accounts, decentralized exchange, and new applications for machine-to-machine transactions have become the driving force for development. This paper analyzes the application of crypto ledgers in the current financial system and promotes the following discussion: If financial institutions use public crypto decentralized ledgers and have basic ledger capabilities, what speed, cost, and flexibility advantages can be achieved when they check the balance of assets and liabilities?

These ledgers enable new ways to build real-time gross settlement systems such as CHAPS and FedWire, as well as deferred net settlement systems such as ACH, Bacs and corresponding banks, foreign exchange markets, stock exchanges and other pillars of the financial system. This article compresses these decentralized elements into a layered continuous framework and calls it: An Internet of Money Architecture

The perceived benefits of an Internet of Money architecture will be enumerated along with the introduction of the system. These benefits are the motivation for the invitation.

1. Abbreviations and definitions

• ACH: Automated Clearing House, a system that ensures the viability of the retail payment process in the United States on a delayed net settlement basis.

• Bacs: A system to ensure that retail payments on a deferred netting basis are viable in the UK

• CHAPS: The UK's basic gross settlement fund trading system for high value transactions

• Consensus Pool: A group of servers, with a given master, that use a fault-tolerant algorithm to continuously reach a consensus state of the ledger. A healthy consensus pool is generally controlled by different counterparties.

• DApp: Decentralized Application

• DE: Decentralized Exchange

• DEP: Decentralized Transaction Protocol, described in section 7a

• DNS: Delayed Netting

• DNSP: Deferred Netting Protocol, described in Section 7d

• FedWire: The fundamental gross settlement fund trading system used by the United States to conduct high-value transactions

• Issuer: The counterparty that issues property on the cryptographic ledger. This counterparty can be a bank, company, decentralized anonymous organization, government or private individual. Property can be commodity security tokens, currency, intelligence goods, company internal equity, tokens representing airline miles.

• Ledger contracting: Please find the explanation in sections 3 and 4.

• ODFI: Initial Depository Financial Institution, a bank that creates an automatically clearing loan.

• OFI: Original Financial Institution, a bank that originates a FedWire loan.

• RDFI: Depository Accepting Financial Institution, a bank that closes an ACH loan.

• RFI: Receiving Financial Institution, a bank that closes a FedWire loan.

• RTGS: Real Time Gross Settlement System.

• GTGSP: Real-time Gross Settlement System Protocol, described in 7c.

• SIPS: Significant Payment System.

• SL3P: Static Liquidity Payment Process Protocol, described in 7b

• Tx: Transaction

1. frame

Inspired by the OSI layer model, the currency Internet architecture is as shown in Figure 1:

The following sections detail the requirements and capabilities of each layer, and the paper is divided into the following sections:

• Sections 4 and 5 describe the ledger protocol, an innovation driven by the conceptual evolution of the Bitcoin and Ethereum projects. The ledger protocol provides the foundation for many of the components of this paper. The description of Bitcoin in Section 4, while correct in the abstract, deviates from current implementations.

• Sections 6, 12, and 13 discuss the general ledger layer. Section 6 makes an overall assumption and omits the reasoning. The reasoning and details are in Section 12. The purpose of Section 13 is written in Section 5.

• 7a, 7b, 7c, and 7d describe DEP, SL3P, RTGSP, and DNSP. This section describes the potential core innovations of the Internet of Money.

• Section 8 shows that the protocol in Section 7 can be unified into two basic ledger operations. This union makes the implementation tractable.

• Sections 9, 10 and 11 introduce the target, protocol and program layers respectively.

• Section 14 presents important observations and development questions.

• References are in Section 15 and author details are in Section 16.

Finally, the color coding of the sticky notes (this article is a translation and is not referenced below):

• Dark blue bold font is used for section titles.

• Sky blue bold font is used for section headings.

• Green bold font demarate multi-phase payment and exchange protocol stage.

• Gray bold font marks important definitions, opinions or paragraphs.

• The article details other color and shape conventions in case you need them.

1. Bitcoin ledger contract

Ledger protocols are protocols that track accounts with value balances. They allow a customer to deduct X units from their account and simultaneously credit another account with X units. In order for a significant operation to work, the customer's account must have a balance greater than X. Figure 1 visualizes two Citibank customers, Alice and Bob. Alice initiates this payment.

In the operation of the above diagram, Bitcoin increases wealth through the ledger protocol. The ledger protocol is an account that maintains balances and operates under predetermined rules. Entities outside of Bitcoin, like Alice and Bob, cannot use the ledger protocol to enter into contracts before the rule sets are completed. This implementation is rejected by Bitcoin nodes because it violates the protocol rules.

For example, Alice wants to transfer bitcoins to Bob, and Bob can only use bitcoins after December 31, 2015. This can be done by creating a ledger contract that keeps a temporary balance of bitcoins. For Bob's transfer, the bitcoins can only be obtained after a given date is set in the ledger contract. Figure 3 shows this process:

The ledger protocol can be thought of as a neutral, automated third party that mediates the transfers between Alice and Bob. Readers need to be aware that the above diagram is an abstract concept, and Bitcoin can implement transactions in different ways.

Figure 4 provides the second illustration. Alice is a buyer and Bob is a seller. The goods transaction has a long shipping time. Trent is a third party trusted by both Alice and Bob. In this transaction, Alice deposits the purchase value in the general ledger agreement according to the following terms:

• Any two of the three parties must sign a guarantee agreement to ensure that the funds cannot be moved.

• If the goods are received in error, Alice and Trent can return the funds to Alice.

• The sale is successfully completed, and Bob and Trent give the payment to Bob.

Figure 4 shows the transaction flow when a successful sale is delivered. The general ledger protocol acts as a neutral automated third party mediating the direct transaction relationship between Alice, Bob, and Trent.

The Bitcoin ledger protocol is programmed in a stack-based bytecode language, which we call "Bitcoin script". Each ledger protocol has code and cache data structures.

The Bitcoin protocol has two important limitations:

• Value-blindness: The protocol cannot execute transactions with a lower amount than the total amount of funds stored. This means that the user must withdraw all funds at once within the retrieval time.

• Lack of persistent storage/state: The protocol cannot store data, which limits the application users from doing decentralized transactions.

Figure 5 shows a hypothetical situation that emphasizes the restrictions. Alice wants to use the ledger protocol to exchange Bitcoin for Dogecoin. She sets up a ledger protocol and stipulates that the transaction should be made in Bitcoin. The agreement is: when the other party provides Alice's address with a Dogecoin payment proof, the protocol will give the Bitcoin to the address specified by the other party.

The value blind limit means that Bob, as the other party, must trade the amount that Alice actually specified in the agreement. The other party may want to trade a smaller amount and then get the corresponding part of the funds in the general ledger agreement. This operation cannot be performed in the single bitcoin general ledger agreement.

Assuming that some transactions are possible, the Bitcoin ledger protocol must store payment credentials that can be used. When this storage is lost, the other party can repeatedly provide the same credentials and unfairly withdraw funds. The inability to store and the value blind spot limit programs such as decentralized exchanges.

The current example is only to highlight the limitations. It has other flaws that have not been mentioned. Decentralized trading Bitcoin can be better implemented in another structure - Atomic Cross Chain Trrade. Although it also has value blind area limitations.

The next section emphasizes the Ethereum approach, laying the foundation for the protocol described here.

1. Ledger contract containing Ethereum

The Ethereum project contains many innovations, the following are important for this article:

1. The ledger protocol is value-aware and has persistent storage capabilities.

2. The ledger agreement can deposit/withdraw (loaded/unloaded) funds when needed. The deposit/withdrawal conditions are implemented by the agreement code (contract code).

3. Messages with data can be sent to the ledger protocol. The protocol can reply with data, passing the value to the input.

Section 7 demonstrates the above usage. Therefore, examples are omitted here. Other Ethereum innovations are secondary to our discussion and will be mentioned in Section 12.

1. The ledger protocol can enter some random data. The purpose is to provide an entropy source for speculative applications.

2. The adapted language used to create the ledger protocol is Turing complete.

3. A ledger protocol can create another ledger protocol. Therefore, it has the same rights as an outsider controlling an account. This is referred to as "contract first class citizen property"

The connection between points b and c means that infinite loops may occur when upgrading the Ethereum ledger. The Halting problem provides a limitation when estimating that any script will terminate within a limited time or prevent network nodes from rejecting transactions and causing infinite loops. When a program falls into an infinite loop to prevent nodes from rejecting transactions, the Halting problem judges this and then causes two risks of innovation:

1. The transaction fee approach to preventing infinite loops is flawed in some unknown circumstances.

2. Explicitly designed malicious protocol code can escape from the Ethereum Virtual Machine and cause damage to network nodes.

Section 12 discusses ways to mitigate risk while still gaining some of the benefits of Ethereum. The driving force is to avoid risk and complexity during the incubation period of the invitation implementation.

Sections 6-10 assume that the full set of Ethereum ledger protocol capabilities is available.

1. General ledger layer

The ledger layer is created with a protocol that allows a single or a group of counterparties to build ledgers and simultaneously release required assets. Each ledger has an asset issuer, a group of ledger identities and asset issuance identities.

The minimum criteria for the general ledger are:

1. The asset issuers of each ledger must be different entities in order to maintain the ledger.

2. The ledger is maintained by a decentralized consensus process. The set of nodes participating in the consensus process is called a consensus pool.

3. Ledger account balances, agreements, and transactions are public.

4. Transactions are initially created through the use of digital signatures.

5. Multi-signature accounts are a basic requirement.

6. Basic ledger protocol capabilities are required in every ledger. The minimum set of capabilities is described in detail in Section 12.

7. Fast ledger transactions are best completed within two seconds. This is possible for a decentralized ledger when the identities of the consensus pool nodes are known. We assume the same is true for the following description.

8. There will be an alignment mechanism between the consensus pool and the joint ledger.

The rationale for the above features is provided in Section 11. Hyperledger establishes a Practical Byzantine Fault Tolerance consensus algorithm to maintain the ledger and is an example of a ledger layer protocol.

The Bitcoin and Ethereum projects assume that network nodes are anonymous. Here, we assume that the identity of the consensus pool nodes is knowable. This is one of the main divergences from other cryptocurrency projects. In addition, the focus is on the coordination of financial systems with commodity-backed currencies, information commodities like Bitcoin, equity and other assets. Ultimately, the proposed system does not necessarily create any new currency or assets.

Figure 6 shows part of the ledger layer. Ledgers with the same asset type have the same color. A black dot inside a colored circle represents an account. The issuer of the asset corresponding to the account is known. The issuer's name is chosen for ease of visualization. Big banks and corporations, naturally and appropriately conservative writers, are not the first customers of the technology described here.

If carol has assets in ledger 4, we assume she has a trusted relationship with the issuer of ledger 4.

In Alice’s case, she has USD in ledger 1 and wants to transfer USD to Bob, a client with the same issuer in the same ledger. In other words, intra-ledger transfers are simpler to process. The next section will cover intra-ledger transfers.

1. Payment and transaction layer

This layer is assigned to solve two cases in Alice and Bob's case:

• Scenario 1: Alice has V dollars issued by Citibank in ledger 1, and she wants to exchange them for W euros held by Bob in ledger 2. Fidor Bank is the issuer of the euros. 7a describes this scenario.

• Scenario 2: Alice has V dollars issued by Citibank in ledger 1 and wants to pay Bob. Bob is a customer of Wells Fargo in ledger 2. 7b, 7c, and 7d show the resolution.

This layer plays a role in carrying out one of the four protocols. 7a is related to DEP, 7b is related to SL3P, 7c is related to RTGSP, and 7d is related to DNSP. Micro-transaction payments are described in Appendix A.

7a.DEP

Decentralized transactions can be implemented as two inter-chain ledger contracts that mediate the transaction relationship. This is visualized in Figures 7a, 7b, 7c, and 7d. For convenience, we name the two contracts the dispensing contract and the accepting contract. The protocol has four phases. Assume that Alice creates an invitation for Bob to accept as a trading party:

Phase 1: Alice establishes a publishing agreement and an acceptance agreement on two ledgers

1. Figure 7a represents stage 1

2. Alice establishes an acceptance agreement on ledger 2 and a publishing agreement on ledger 1

3. The link between publishing and accepting agreements constitutes Alice's transaction invitation (offer). The pricing information is set as the storage entry of the two agreements.

4. Alice's protocol for publishing value V

5. The contents of the acceptance and release agreement are shown in the figure below.

Stage 2: Bob believes in the agreement and then asks the publisher for money

1. Figure 7b visualizes stage 2

2. Bob confirms that the posting and acceptance of the agreement constitutes an acceptable offer and is correctly structured.

3. Accepting that the protocol holds the funds in a state where Alice needs the declaration message from phase 3c to withdraw them.

4. Bob provides the payment certificate for the current publishing agreement on ledger 1

Phase 3: Publish the agreement to lend money to Bob and send a statement to Alice

1. Figure 7c shows the situation in stage 3

2. Publish the agreement to confirm the payment voucher and ensure that the voucher has not been used before. After completion, transfer V to Bob in general ledger 1 and add the payment voucher to the agreement memory.

3. The release agreement sends a claim message to Alice in ledger 1. Alice can withdraw money from the receiving agreement at her convenience or immediately.

Phase 4: Alice withdraws funds from the receiving protocol using a declaration message

1. Figure 7d represents stage 4

2. Alice adds a statement message in the receiving protocol

3. The receiving protocol verifies the announcement message and ensures that the announcement message has not been used before.

4. If the declaration message is valid, the receiving protocol releases the money to Alice on ledger 2 and adds the data of the declaration message to storage.

Ability to receive and publish protocols

1. The issuing agreement must be in the hands of a third party holding V and able to verify the payment credentials of Ledger 2. To prevent duplicate use, usage information needs to be stored.

2. The receiving protocol must place W in a third party that is able to verify the declaration message of ledger 1. To prevent reuse, the used declaration message needs to be written to the contract memory.

The above process assumes that the transaction is automatic, that is, V in the release protocol is only declared in one transaction. If Bob wants to change the transaction amount to X, which is less than W, in phase 2, it is also possible.

Additionally, there are two edge cases to consider:

1. 1. Release Agreement Balance: Because there is no limit on the number of participants when transferring assets to the Acceptance Agreement in Phase 2, it is possible that Bob does not meet the Release Agreement Balance conditions when he asks for money. In order to prevent Bob from losing money, an additional function needs to be added to send a message "Transaction Rejected" to Bob on Ledger 1. Bob can use the rejection letter to withdraw money on Ledger 2. Alice will not receive a rejection letter, so she cannot unlock the assets in Ledger 2.

2. 2. Alice cancels the order: Alice must have the ability to withdraw and add funds to the published agreement, and can also cancel the order. This ability cannot be connected to the transaction process mentioned above. The non-balance caused by withdrawal can be handled with the rejection letter mentioned above.

Although DEP is unreliable and P2P, there is still a market for information service providers to track transaction commands of different ledgers. Service providers can ask consensus pool nodes to provide commands to verify the rationality of the ledger agreement. Participants will pay service providers to obtain updated information. Pure information services are the monetary Internet equivalent to commands.

The power of DEP is that it eliminates the need to mediate currency and equity transactions between different counterparties. Figure 8a shows the relationship between counterparties and equity transactions between Alice and Bob. Figure 8b, SEP, is compared with 8a, highlighting the potential low-cost transactions. A similar parallel situation exists when trading currency.

The role of central depositories and custodians is replaced by a public encrypted ledger. Brokers and stock exchanges are replaced by information services that track the orders of the ledger. When Alice and Bob cannot tolerate each other's risk, clearing houses are no longer needed. The protocol execution took Bob only 4 seconds.

Ultimately, DEP acts as a bridge between currencies and information commodities such as Ethereum and Bitcoin.

7b.SL3P

Unlike decentralized exchanges, which are an evolutionary improvement over current systems, SL3P is a new payment process.

Imagine the situation in Figure 9a, Alice has V dollars issued by Citibank on ledger 1, and she wants to give these dollars to Bob. Bob is a customer of Wells Fargo on ledger 2. There is another counterparty named Carol who is related to Alice and Bob and maintains balances in both ledgers. Carol:

1. Trust the two issuers, Citigroup and Wells Fargo.

2. Remain neutral with respect to the respective balances of the two ledgers, as long as the total amount remains constant.

3. Holds assets exceeding $V at Wells Fargo Bank

4. There is no need to make transactions between the two ledgers immediately, that is, her balance is static liquidity

According to the transaction set, the protocol described in Figure 9b resolves the payment:

1. Alice gives Carol V dollars on ledger 1

2. Carol gives Bob V dollars in Ledger 2

SL3P uses two ledger protocols to ensure multiple features that need to satisfy transaction logic:

1. Alice sends Carol a ledger agreement that ensures that she pays Bob on ledger 2, or she gets her money back on ledger 1.

2. The general ledger agreement can be maintained, that is, Carol constructs the agreement once, and then the agreement automatically makes payments to different counterparties.

3. Carol can charge a fee at the time of payment in order to ensure static cash liquidity.

The protocol requires four phases:

Phase 1: Carol opens a SL3P channel by creating a protocol on two ledgers.

1. Figure 10a represents stage 1

2. Carol creates SL3P protocol 1 on ledger 1 and SL3P protocol 2 on ledger 2.

3. The connection of symmetric SL3P protocol 1 and SL3P protocol 2 is called SL3P channel. The protocol stores the charge of each transaction as data entry.

4. Carol now has protocol 1 worth X and protocol 2 worth Y

5. The capabilities of the SL3P protocol are as follows

Stage 2: Alice believes in SL3P protocol 1 and asks Bob for money in SL3P protocol 2

1. Figure 10b shows the second phase

2. Alice wants to pay Bob V and verifies that SL3P protocol 2 has a balance greater than V. If so, she proceeds to the next step

3. Alice transfers V dollars to SL3P protocol 1

4. SL3P protocol 1 holds the funds in a special state. These funds can only be withdrawn after phase 4, or SL3P protocol 2 does not give Bob the money in phase 3d.

5. Alice provides proof of the above situation to SL3P protocol 2 and creates a transfer to Bob’s account on ledger 2.

Phase 3: SL3P Protocol 2 verifies the statement and sends money to Bob

1. Figure 10c depicts stage 3

2. SL3P protocol 2 verifies the payment proof and then checks if it has been used before. Once verified, it transfers V to Bob and sends a state change message to Carol on ledger 2. The payment proof data is added to the protocol storage.

3. Carol can use state change messages to store the funds in SL3P protocol 1 in phase 2c, which she can withdraw at any time.

4. If the balance is not satisfied, the protocol sends a "reject payment" message to Alice in ledger 2. Alice can then withdraw money from SL3P protocol 1.

5. In the protocol, Bob only needs to verify the successful transfer

Stage 4: Carol withdraws money using status messages

1. Carol takes the state change message from the previous SL3P protocol 1

2. SL3P protocol 1 verifies the state change message, stores the message in a previously reused memory, and then makes V available to Carol later.

3. Only the money that Carol can withdraw from SL3P later can participate. Carol can delegate Phase 3 to a third party. The third party monitors the SL3P protocol and ensures that they have sufficient participation in static cash liquidity.

Capabilities of the SL3P protocol

1. The SL3P protocol needs to maintain balances in a third party, while being able to verify payment credentials and status change messages. Already used credentials and schools need to be saved in memory storage to prevent reuse.

2. In the case of a SL3P payment with no balance, the target protocol must issue a "payment rejected" message to the originator. The payment rejected message allows another protocol to withdraw the funds.

3. The SL3P protocol must allow Carol to deposit and withdraw funds without violating the terms of the protocol. Carol has reached a balance in both protocols, all the money has been withdrawn, and the channel is closed.

Protocol reversal is also possible. Because the SL3P protocol is symmetric, Dave can create a payment from ledger 2 to ledger 1.

The payment process has been modified to a P2P model, providing a basis for a competitive market. The protocol is a link between two transfer protocol calculations, so it can be completed within 4 seconds.

The domestic counterpart bank can be visualized as Carol, as one of the two access issuers. For example, suppose the issuer of Ledger 1 is Issuer 1. If Issuer 1 opens a deposit in SL3P channel Ledger 2, it results in a relationship with the domestic counterpart bank. The reader should be able to remember that the domestic counterpart bank is constantly accelerating the resolution of anachronisms.

SL3P improves Deferred Net Settlements because issuers do not assume trust risk in the payment process. In order to mitigate the trust risk in deferred net settlement, issuers need to provide collateral to the clearing house. SL3P proposes that this is not necessary.

Another key benefit is the creation of a new liquidity pool for payments. Liquidity costs are a key factor in pricing RTGS payments. A core assumption in the current system is that liquidity requirements for payments are provided by issuers. SL3P is able to break this assumption, creating a larger liquidity pool and therefore more affordable payments.

7C. Real-time Gross Settlement Protocol (RTGSP)

Similar to SL3P, RTGSP solves this problem: Alice has V dollars from Citibank in ledger 1 and wants to transfer these dollars to Bob, who is a customer of Wells Fargo Bank in ledger 2.

RTGSP is a solicitation consensus between the FedWire system used by the United States for high value transfers. It allows the involved issuers to set up liability accounts in internal banks from the FR ledger payment. Figure 11 shows the FedWire transaction flow.

Alice creates a FedWire loan with Citibank as the OFI and Wells Fargo as the RFI. Citibank debits Alice's account immediately, and Wells Fargo confirms Bob's account a few minutes later.

Internally, Citibank submitted a credit request to FR, which was then given to Wells Fargo. FR settles the transaction, transferring money from Citibank to Wells Fargo on FR's ledger. When the transaction is actually carried out, the settlement amount is transferred, a form of payment process called real-time gross settlement (RTGS). It is assumed that Citibank and Wells Fargo have no credit risk.

Expanding on this point, we consider Citibank as Issuer 1 and Wells Fargo as Issuer 2. The goal is to demonstrate a protocol that uses Citibank, Wells Fargo, and FR as a cryptographic ledger.

SL3P provides a path as depicted in Figure 12. The Issuer opens a unidirectional SL3P channel between the FR Ledger and the Tracking Assets Ledger. An SL3P channel maintained by Issuer 2 is shown in Figure 12. On Ledger 2, Issuer 2 creates assets and liabilities at one end of the channel. Marked in dark pink.

The unidirectional SL3P channel refers to an improved structure where the payment direction is unidirectional. In Section 7b, this is a simple fix.

Alice creates a transaction to transfer V to Publisher 1. The transaction contains data describing the final ledger and Bob's account. This effectively destroys Alice's possession of the property published by Publisher 1.

Assuming Citibank has the necessary liquidity, it transfers V to the SL3P protocol maintained by Publisher 2 of the FR ledger. It then gives the payment voucher to the other party on ledger 2 and makes the transfer to Bob’s account.

Assuming there is sufficient protocol balance, Ledger 2 SL3P protocol verifies the payment certificate to complete the transfer. Publisher 2 periodically downloads funds to the protocol to keep the RTGSP transfer flowing. When the protocol balance is not reached, Publisher 1 can retry or request the funds back from the other end of the channel.

Although RTGSP has been proven to be feasible, it does not address the core challenge of RTGS systems: liquidity management. Appendix B will address this issue.

RTGSP ensures the automation of FedWire and other gross clearing systems. FR's role is limited to being a pure publisher. As long as the FR ledger consensus pool can be reached, the system will be able to operate. Currently, the role of the US FedWire system is limited to 09:00 to 18:00 ET.

The decentralization of the FR ledger and RTGS system can serve as a superior operational risk control and business sustainability policy. Nodes can be geographically decentralized, making different kinetic systems independent of each other and establishing data backup. In general, all systemically important payment systems clearly benefit from the decentralization brought about by operational risk control.

7D. Deferred Net Settlement Protocol (DNSP)

DNSP solves the same problem as SL3P and RTGSP: Alice has V dollars in Citibank's ledger 1, and she wants to transfer the money to Bob, who is a customer of Wells Fargo Bank in ledger 2.

Instead of clearing payments, like RTGSP, settlement is a transfer on the FR ledger; DNSP ultimately creates a debt of Citi to National Wealth. Multiple debts can be aggregated. Net amounts are transferred between publishers as long as both parties agree on the FR ledger. Clearing payments are created between publishers regarding debt relationships, and payment relationships are transferred on the FR ledger. DNSP defers payment until after clearing payments. The protocol requires trust between publishers.

The combination of DEP, SL3P and RTGSP can handle a large part of banking transactions. DNSP is covered for integrity. It is equivalent to the ACH system in the United States.

Traversal transactions, pioneered by Ryan Fugger and the Ripple project, form the core of DNSP. A lateral ledger enables traversal transactions with features beyond those previously thought of:

1. Accounts can establish trusted relationships with other accounts. A trusted relationship is the approval of the account holder in the consensus pool, allowing the pool to change the account balance according to the value and party specified in the trusted relationship.

2. The consensus pool can convert payments from one account to another into balances of other accounts, subject to the constraints set by the trust connection.

Figure 13 introduces a horizontal USD ledger with four participants: Eve, Frank, Gary, and Harry. The left side of Figure 13a shows the trust relationship. A line from Frank to Eve is worth M dollars. This means that Frank agrees that Eve owes him no more than M dollars. Participants can change trust relationships dynamically.

The right side of Figure 13b shows a horizontal transaction payment of W dollars between Eve and Harry. Before the payment, we assume that none of the participants have a debt relationship with each other. After the transaction, Eve owes Frank W dollars, Frank owes Gary W dollars, and Gary owes Harry W dollars. Harry has accepted this payment of W dollars.

The net balance of each account is equal to the claims held by the participants minus the liabilities held. Frank and Gary's net balance remains unchanged after the transaction. Gary and Frank did not actively participate in the transaction. Harry's role is to verify the payment.

Because the general ledger may have more participants; the optimal payment path of the consensus pool technology is represented by the red arrow in 13b, and the balance is automatically adjusted.

For DNSP, we assume that multiple publishers are part of a domestic horizontal ledger. The horizontal ledger becomes a payment settlement mechanism, and the trust relationship is negotiated by two publishers. DNSP has two phases, depicted in Figures 14a and 14b.

Phase 1: Alice creates a payment, publisher 1 gives publisher 2 property

1. The publisher creates a third-party contract on the ledger, tracks the assets, and downloads the assets to the contract. The capabilities of the third-party contract will be explained later.

2. Alice V transfers wealth to publisher 1 on ledger 1. The transaction contains the final ledger and Bob's metadata address.

3. Publisher 1 and Publisher 2 make a horizontal transaction worth W in the domestic clearing ledger. W is less than V and is between 0 and 5 USD.

4. Publisher 1 gives the above payment proof to the third-party protocol of general ledger 2, requiring the protocol to give V

5. The third party agreement verifies the payment certificate, and the next step assumes that the certificate is correct

6. If there are funds above V, it is transferred to V at time T. Between time 0 and T, V can only be transferred to Bob when publisher 1 completes phase 2. T is about one minute.

7. If the protocol does not complete the transfer of funds, it transfers W to Bob and sends a "reservation rejected" message to publisher 2.

Phase 2: Publisher 1 transfers the property (VW) to the clearing ledger and asks Bob to pay

1. Assuming the reservation is successful, publisher 1 transfers money (VW) from the clearing account to publisher 2

2. Publisher 1 gives the payment voucher to the third-party protocol of Ledger 2 and asks Bob for V

3. The third-party agreement verifies the payment voucher and, if correct, transfers the retained funds to Bob in ledger 2.

4. When publisher 1 fails to complete phase 2 within time T, publisher 1 can request a transfer of W to Bob. The third party can initiate a penalty X in this case (X<W)

In its current state, DNSP has a flaw. In phase 1, the third-party protocol may be exhausted and have assets less than W. This will cause publisher 1 to suffer a loss of W. This flaw can be tolerated for the following reasons:

1. The amount of assets at risk is low. W is about $5, a small amount compared to physical payment systems.

2. If the third-party protocol runs out, all DNSP payments on Ledger 2 will stop, and since Ledger 2 is public, the problem will escalate. Publisher 2's reputation will suffer during the period when the DNSP is down.

The debt relationship between publishers to write off DNSP is established on the FR ledger after the consent of both parties. The settlement is just a simple transfer between two publishers on the FR ledger, so it is not annotated.

DNSP separates the clearing and settlement processes, resulting in fast transfers to Bob (less than 10 seconds). Many current systems, such as ACH in the US and Bacs in the UK, only clear and settle transfers once a day. Therefore DNSP is able to provide an improvement. In addition, the trust relationship design in the clearing ledger removes the current two-tier arrangement of centrally controlled membership systems. Any publisher can participate in clearing as long as it ensures a trust relationship with other publishers.

For symmetric systemically important payment systems, a decentralized clearing ledger reduces operational risk and is a means of ensuring business continuity.

1. joint

The previous sections have explained each feature of the protocol in detail, which is a bit frustrating in terms of implementation. These apparent complexities arise from the interactions in real systems, and can also be simplified to a simple and elegant level in implementation.

A key observation is that the ledger protocol that leverages DEP and RTGSP is a derivative of SL3P. Figure 15 illustrates this conclusion.

Perhaps the challenge with the above is to visualize that the Publish and Receive protocol is a derivative of the SL3P protocol. Refer to 7b and replace Alice with Carol; Alice and Bob with Bob. Also, instead of the ledger handling only a single currency, they handle different currencies. These replaced transactions are currency transactions.

We can stop referring to the protocols by different names, although the author information will help to distinguish them.

1. Extension (pathfinding) level

At the extended level, the protocols described above are automatically considered to fall into five categories:

1. Direct transfer of assets between two accounts. Assume the execution time is less than 2 seconds.

2. Two ledgers tracking different or same asset classes through DEP. Assuming execution time is less than 4 seconds.

3. Two ledgers tracking the same currency via SL3P. Assume execution time is less than 4 seconds.

4. Two ledgers tracking the same currency via RTGSP. Assume execution time is less than 6 seconds.

5. Two ledgers tracking the same currency via DNSP. Assume execution time is less than 10 seconds.

Any global payment, remittance, asset acquisition or transaction originating from one encrypted ledger and ending with another ledger can be divided into the five types of automated operations mentioned above. The task of the expansion level is to settle the optimal set of automated operations to execute the required property transfer or transaction.

Small world networks are social networks, connected by short distance dual nodes. We assume, without proof, that the financial Internet of Money is also a small world network. In practice, this means that any global money transfer/transaction can be performed in no more than 5-7 automated operations. A global maximum transfer time of one minute seems acceptable with such connections.

The raw data of the extended algorithm are as follows:

1. Real-time DEP databases on different ledgers

2. A set of SL3P channels operating between ledgers

3. A set of globally recognized RTGSP networks

4. Several groups of publishers participating in the RTGSP network

5. A set of globally recognized DNSP networks

6. Publishers who engage their audience in the DNSP network

7. The monetary cost of the cost function data to perform the automated steps

Similar challenges on the Internet are pathway protocols such as RIP, OSPF and BGP. The communication path through the Internet requires routers and nodes to continuously broadcast reachable information. As a quasi-distribution algorithm across multiple routes/nodes is visual.

On the Internet of currency, path requirements can be sent in centralized services, and the optimal path received is reasonable. Data collection and calculation outsourcing to these service providers to reduce the workload of customers. The actual calculation optimal path force algorithm will be left to future articles for discussion.

Once the customer has obtained the optimal path, the path performs global value transfer and automatic operation of transactions.

Figure 15 shows the expansion. Alice has Swiss Franc assets on the US general ledger and she wants to buy Apple's equity. She initiated a path demand for the expansion server. The expansion server has a database of RTGSP network, a DNSP network and protocols for different ledgers. It evaluates 3 optional paths, including the number Alice can take. It points out Alice's optimal path and explains payment and transaction fees.

Alice's client has a protocol software to perform actions that require automatic operation. She also gets the desired equity in this way.

1. Protocol Layer

The protocol layer allows cross-value and arbitrary code running to change the value balance. This can be achieved by implementing programmable orcles projects of codius and gavin andresen.

The advantage of the protocol layer is to have the lower level as a single global ledger. This abstract ledger can maintain balance and transfer property within one minute.

The funds in the Smart Protocol, controlled by a group of special entities, become M multiple signature accounts in N. The protocol code is sent to each entity at the same time. Each time the protocol agency wants to send a message to the contract, they give the message to the oracles. The arbitration runs the code to calculate the balance of the participants. If the encoding causes the agreement to withdraw money to a specified address to perform operations, the arbitration cycle transfers the funds and signs. The funds transfer is processed by the lower layer of the currency's Internet. Figure 17 shows this protocol layer.

Section 12 quantifies the differences between the General Ledger protocol and the protocol layer. In general, the General Ledger protocol is used to build payment and transaction protocols. Other use case intelligent protocols are implemented at the protocol layer.

For example, there is a crude oil futures agreement between Alice and Bob in Brut, London. The agreement is represented by a computer code, and the arbitration is executed; the execution entity retrieves external data for Alice and Bob to calculate the new balance at settlement. After the encoding is executed, the balance between Alice and Bob is reached again through the lower currency Internet layer.

Another example is the mediation of professional buyers and sellers, which can be seen in Figure 4. Alice is the buyer and Bob is the seller. They want to define the payment amount based on the time of successful delivery. Bob will pay a fine in the case of long-term delivery. Alice will issue the payment after the agreement is established. The service of the agreement verifies the delivery of the goods and pays Bob accordingly.

The third example is digital asset auction. Establish an agreement to implement the rules of auction. If the digital asset owner is delivered to project arbitration, the rules are implemented.

1. Application Layer

Similar to the TCP-IP protocol group, this layer includes communication between applications and users. In particular, the following content is particularly important in business.

• Debit and loan-based payment network

Although the currency Internet is foreseeable and at the same time increasing the speed of value transfer globally, some use cases require payment networks, such as Visa and Mastercard. There are cases below:

1. Transfer certification requires bursts, such as store purchases.

2. The operational requirements of multiple automatic transfers and transactions make the own keys necessary to be used multiple times. A payment network will require additional security.

3. Payment networks facilitate arbitration between buyers and sellers.

The settlement risk can be effectively reduced through the payment network. It reduces payment and transaction time through technology. Visa's settlement amount on September 30, 2013 was reported to be 53.8 million US dollars.

Ultimately, the protocol layer can make some new arbitration methods such as double deposit escrow feasible.

• Futures, options, derivatives, predictions and other markets

One of the core concepts of this article is the classification principle: the characteristics of each currency Internet are operated by different entities. For example, the consensus pool is maintained by the general ledger, banks do asset issuance and compliance, expansion services are done by expansion, and other enterprises do agreement applications.

The agreement and application layer ensures the development of futures, options, derivatives, and arbitration markets. Different services can segment the market.

• Hazard's game about smart protocols

As an example, this game can be viewed as a protocol with the following rules:

1. Roulette wheel rotation is a model source of entropy

2. The input of generalized entropy is used as the change in participant balance.

3. The transfer and transaction of value are carried out through the lower currency Internet layer

We claim that there is no proof, so the game including poker, blackjack is implemented with smart protocols.

• Decentralized Applications

Abstract general ledger is a powerful cornerstone of the decentralized application of resumes. Currently, the following methods include building new ghostwriters when contacting services, such as decentralized storage, mesh network and reputation system. The currency Internet provides ways to build tokens. For example, a DApp that shares hard disk space is mentioned in Appendix C.

1. Look at the general ledger

This subsection will gain a better understanding of the minimum requirements of the general ledger by thinking about some issues (Subsection 6):

• Why can't the general ledger be controlled by developers?

When the payment and transaction protocol is built, entities other than the developer execute transactions on the ledger. For example, RTGSP: Publisher 1 sends payments to Bob on the ledger, and Publisher 2 does not participate. Now assume that the server of Publisher 2 is the only node in the consensus pool that maintains 2.

Publisher 2 can create a new general ledger history, which does not agree with past records, claiming that Publisher 1 never completed the payment to Bob. If Alice and Publisher 1 cannot get the time of the old history, it will not be possible to discuss the new history well. The legal cost will be greater than expected when arguing.

The hypothetical solution is that multiple opponents maintain the ledger through a decentralized consensus process. Through decentralization, publishers and customers can ensure fairness of the ledger. Therefore:

Decentralized services can improve the confidence of fairness of the general ledger. The more diverse the nodes involved in the consensus pool, the stronger the guarantee for fairness.

Trade-offs are effective for decentralization. Nodes need to prove their processes to each other and communicate to reach consensus. This is better than the same centralized ledger.

A strategy advocated by PhD for decentralization. The view in this article is:

The decentralization level of a certain use case is a question of optimality

Factors that affect validity, defined as transaction processing of each NPV dollar in the investment node is:

1. Choosing the consensus process

2. Node identity hypothesis. Validity increases dramatically when node identity is known. Bitcoin nodes are anonymous and the network will suffer high costs, $0-500 million to maintain consensus every year.

3. Node Amount. In general, the larger the consensus pool, the lower the effectiveness.

Factors that affect fair belief in the general ledger:

1. Consensus pool composition. When a reputable company like Google has nodes in the pool, it will drive the confidence of the pool. Malicious behavior of all nodes of Google can damage its market reputation. Google's goodwill may be worth millions of dollars in life and death.

2. The choice of consensus process. For example, the actual Byzantine fault tolerance can accommodate up to 33% of malicious nodes in the pool.

3. The amount of different entities that control nodes in the consensus pool. The higher the amount, the more trustworthy it is.

The credibility of the general ledger is based on the value of the risk. The recommended strategies are:

The goal is to keep the balance between the assets at risk or the general ledger valid and trustworthy.

For example, the higher the homogeneous pool may track the faithful points of two grocery chains. The Citibank general ledger will benefit from high trust/decentralization.

Optimal general ledger protocol

Because each use case has a different optimal pool composition and node number, the total ledger protocol needs to be very flexible. There is no limit to the use of the protocol, developmentality and development. The consensus process should have the best effectiveness in cross-division situations.

The hyper ledger project is a pioneer in this direction. Hopefully, projects with other system goals are following up.

• Why is the general ledger public?

All payment and transaction agreements mentioned here are based on public ledgers. The other party cannot view invitations or verify payments on private ledgers.

If the application assumes value, balanced privacy enhances the technology that needs to be developed. Similarly, payments require monitoring of financial transactions. Investment in the monetary Internet can be seen when the cost of ensuring financial privacy does not exceed the profits made by customers from applications such as decentralized transactions.

As the privacy issue was resolved, the author expressed excitement of the improvement of economic theory and crisis management brought about by the disclosure of potential global transaction data acquisition.

• About Multi-Signature Account

In addition to enhancing customer security, the protocol layer also needs trustworthy execution. Smart protocols need to be verified, and the arbitration pool needs to be connected multi-signature accounts for daily operations.

• About the time arrangement mechanism of consensus pool

The time arrangement mechanism provides a method for time calibration of pool nodes. Good design originates from establishing an effective minimum composition. This paper uses time-based transactions for DNSP and MTXP (Appendix A). The way to remove the time arrangement mechanism and save functions also need to be discovered.

1. Reduce risks and complexity in the budding stage

1. Opinions and open issues

Basic advantages of encrypted ledger

This article assumes that the construction of the encryption protocol utilizes the encrypted general ledger, thereby establishing a low-trust financial relationship between the participating publishers and guests. A low-trust relationship reduces transaction costs and is a net income for guests.

Scalability analysis and pull-based payments

The use of electronic signatures makes all encrypted general ledger systems push-based. The current implementation of ACH enables pull-based ACH debits to be implemented, which have multiple applications such as insurance payments, loan installment repayments and public facility payments.

These applications can be built on a mechanism at the agreement/application layer. When Alice is a guest of Bob, there is a utility. Alice and Bob establish a smart agreement held by a mutually trusted arbitration. Alice injects money into the contract as a monthly payment. The agreement contains a treaty that allows Bob to withdraw monthly.

Implementation of Identity Authentication and Anonymity Layers

Obeying the rules also creates a problem: the identity behind the public key must be contacted by an organization (such as the issuer) to resist some problems such as taint analysis. There is also a method to verify the issuer and the general ledger.

1. Reference

1. https://bitcoin.org/bitcoin.pdf

2. https://en.bitcoin.it/wiki/Script

3. Pages 20-28, in TCP-IP protocol stack, 4th edition, Beloz A. Forouzan

4. http://hyperledger.com/

5. https://www.regaltek.com/docs/understanding-ach-network.pdf

6. https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki

7. https://github.com/petertodd/bips/blob/checklocktimeverify/bip-checklocktimeverify.mediawiki

8. http://gendal.wordpress.com/2014/01/05/a-simple-explanation-of-how-shares-move-around-the-securities-settlement-system/

9. Page 323-374, in TCP-IP protocol stack, 4th edition, Beloz A. Forouzan

10. https://github.com/codius/codius/wiki/Smart-Oracles:-A-Simple,-Powerful-Approach-to-Smart-Contracts

11. http://gavintech.blogspot.ch/2014/06/bit-thereum.html

12. http://www.sec.gov/Archives/edgar/data/1403161/000140316113000011/R19.htm

13. http://bithalo.org/wp-content/uploads/2014/06/whitepaper_twosided.pdf

14. https://www.ethereum.org/pdfs/EthereumWhitePaper.pdf

1. About the Author

Author Meher Roy Contact:

Email 1: [email protected]

Email 2: [email protected]

LinkedIn：https://www.linkedin.com/pub/meher-roy/43/969/254

Weibo: https://twitter.com/MeherRoy

Special thanks to Tim for pointing out the error to Macarios and suggesting that it is responsible for crossing the transaction agreement.

Possible updates for version 0.4

Align with Hyperledger white paper

Hyperledger is the best example of a general ledger protocol, with the goal being a one-to-two-compatible file (Hyperledger white paper + current document).

Consider a responsible cross-trade agreement as a better DNSP

For details, please log in:

http://ideophilus.wordpress.com/2014/11/05/a-responsible-transitive-transactions-protocol/

Completion of Appendix A, B and C

Appendix A: Microtransaction Protocol (MTXP)

Appendix B: Methods RTGSP liquidity management

Appendix C: Decentralized Application Architecture (DApps)

—-