Vous êtes sur la page 1sur 29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

AnarchitecturefortheInternetofMoneyv0.2.9
AnarchitecturefortheInternetofMoney
version0.2.9

1.Introduction
SatoshiNakamotosgreatinventionofBitcoincanbeappreciatedashaving2distinguishingfeatures:
a.Bitcoinisapublicdecentralizedcryptographicledgerwithbasicledgercontractingcapabilities.
b.Thecryptographicledgertracksbalancesofanewcurrencybitcoin.
Efforthasbeendirectedtowardsarchitectingaparallelfinancialsystemwithbitcointhecurrencyasabaselayer.
The driving force are flexibility benefits of cryptographic ledgers enabling new use cases like Multisignature
accounts, Decentralized exchange, Machine to machine transactions etc. This paper analyzes applications of
cryptographicledgersinthecurrentfinancialsystemandaimstostimulatethediscussion:
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
contractingcapabilities?
SuchledgersenablenewwaystobuildRealTimeGrossSettlementsystemslikeCHAPSandFedWireDeferred
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
coherentlayerbasedframeworkchristenedTheInternetofMoney.
PerceivedbenefitsfromtheInternetofMoneywillbeenumeratedalongwithsystemdescriptions.Thesebenefits
formthemotivefortheproposal.
2.AbbreviationsandDefinitions
ACH: Automated Clearing House, a system enabling Deferred Net Settlement basis retail payment
processingintheUnitedStates.
Bacs: A system enabling Deferred Net Settlement basis retail payment processing in the United
Kingdom.
CHAPS: The primary Real Time Gross Settlement funds transfer system utilized for highvalue
transfersintheUnitedKingdom.
ConsensusPool:A set of servers, with defined owners, that continuously arrive at consensus on the
state of a ledger using a fault tolerant algorithm. Healthy consensus pools are characterized by several
serverscontrolledbydifferentparties.
DApp:DecentralizedApplication.
DE:DecentralizedExchange.
DEP:DecentralizedExchangeProtocol,describedinsection7a.
DNS:DeferredNetSettlement.
DNSP:DeferredNetSettlementProtocol,describedinsection7d.
FedWire: The primary Real Time Gross Settlement funds transfer system utilized for highvalue
transfersintheUnitedStates.
FR:FederalReserveoftheUnitedStates.
Issuer: A party that issues assets on a cryptographic ledger. The party can be a Bank, Company,
Decentralized Autonomous Organization, Government or Private individual. The asset could be a
commodity backed token, currency, informational commodity, share in a company, token representing
airlinemilesetc.
Ledgercontracting:Pleaserefertosections3and4foranexplanation.
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

1/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

ODFI:OriginatingDepositoryFinancialInstitution,thebankthatinitiatesanACHcredit.
OFI:OriginatingFinancialInstitution,thebankthatinitiatesaFedWirecredit.
RDFI:ReceivingDepositoryFinancialInstitution,thedestinationbankforanACHcredit.
RFI:ReceivingFinancialInstitution,thedestinationbankforaFedWirecredit.
RTGS:RealTimeGrossSettlement.
RTGSP:RealTimeGrossSettlementProtocol,describedinsection7c.
SIPS:SystemicallyImportantPaymentSystem
SL3P:StaticLiquidityPaymentProcessingProtocol,describedinsection7b.
Tx:Transaction.
3.Framework
InspiredbytheOSIlayermodel,aframeworkfortheInternetofMoneyfollowsinFigure1.

Subsequent sections detail requirements and capabilities at each layer. The paper can be broken down into
followingsegments:
Sections 4 and 5 describe ledger contracting, an innovation pioneered by Bitcoin and conceptually
upgraded by the Ethereum project. Ledger contracting forms the basis for multiple components in the
article. Descriptions of Bitcoin in section 4, while correct from an abstract vantage point, diverge
significantlyfromthecurrentimplementation.
Sections 6, 12 and 13 deal with the ledger layer. Section 6 makes gross assumptions and omits
justification. Justifications and detailing follow in section 12. Purpose of section 13 will be expressed in
section5.
Sections7a,7b,7cand7ddealwithDecentralizedExchangeProtocol(DEP),StaticLiquidityPayment
ProcessingProtocol(SL3P),RealTimeGrossSettlementProtocol(RTGSP)andDeferredNetSettlement
Protocol (DNSP) respectively. This segment elucidates the core innovation underlying the Internet of
Money.
Section 8 shows protocols from section 7 can be unified to 2 fundamental ledger operations. This
unificationmakesimplementationtractable.
Sections9,10and11respectivelycharacterizethePathfinding,ContractandApplicationlayers.
Section14postsimportantobservationsandopenproblems.
Referencesfollowinsection15,andauthordetailsinsection16.
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

2/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

Finally,notesoncolorcoding:

Darkblueboldfontsareusedforsectiontitles.
Skyblueboldfontsareusedforsubsectiontitles.
GreenboldfontsdemaratePhasesinmultiphasepaymentandexchangeprotocols.
Greyboldfontsmarkimportantdefinitions,observationsorparagraphs.
Articledetailsothercolorandshapeconventionsasandwhennecessary.
4.LedgercontractingwithBitcoin
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 clients account must possess a balance greater than X. Figure 1 is a visualization for 2
Citibankclients,AliceandBob.Aliceinitiatesthepayment.

Toaboveoperationset,Bitcoinaddsrichnessthroughledgercontracting.Ledgercontractsareaccountsthathold
balances and operate with predefined rules. Entities external to Bitcoin, like Alice and Bob, cannot manipulate
ledgercontractswithoutfulfillingrulessetduringcontractcreation.ThisisimplementedbyhavingBitcoinnodes
rejecttransactionsviolatingcontractrules.
Forinstance,considerascenariowhereAlicewantstotransferbitcointoBobwiththeprovisothatBobcanspend
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
ledgercontract.Figure3plotssuchatransactionflow.

https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

3/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

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
implementeddifferently.

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,withtheconditionthat:
Twopartiesoutofthe3involvedmustsigntransactionsattemptingtounlockcontractfunds.
Ifgoodsreceivedarefaulty,AliceandTrentcanroutefundsbacktoAlice.
Ifandwhensaleconcludessuccessfully,BobandTrentcompletethepaymenttoBob.
Figure4showstransactionflowduringsuccessfulsaleanddelivery.Theledgercontractactsasneutralautomated
thirdpartymediatingatransactionalrelationshipbetweenAlice,BobandTrent.
Bitcoin ledger contracts are coded using a stackbased bytecode language called Bitcoin script. Each ledger
contracthascodeandatemporarydatastructure(stack)associatedwithit.
TheBitcoincontractingsystemhas2significantlimitations:
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

4/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

Valueblindness: Contracts cannot dispense value lower than the total funds stored inside them. In
otherwords,atretrievaltime,claimantmustwithdrawallofthefundsinoneoperation.
Lack of persistent storage / state: Contracts cannot store data, and this limits applications such as
DecentralizedExchange.

Figure 5 plots a hypothetical scenario highlighting limitations. Alice wants to leverage a ledger contract to
exchangeBitcoinforDogecoin.Shecreatesaledgercontract,andloadsitwithbitcoinsdesiredforexchange.The
contract is coded such that, when a counterparty furnishes Proof of Dogecoin payment to Alices address the
contractreleasesbitcoinstoanaddresschosenbythecounterparty.
ThevalueblindnesslimitationimpliesthatBob,acounterparty,mustexchangeexactlytheamountAliceloadedin
the contract. Counterparties could desire a smaller exchange size, and therefore prefer to retrieve a fraction of
fundsembeddedintheledgercontract.ThisoperationisnotpossiblewithasingleBitcoinledgercontract.
Assuming fractional exchanges are possible, the Bitcoin ledger contract must store proofs of payment that have
beenutilized.Ifsuchstorageisabsent,thecounterpartycanfurnishthesameproofofpaymentrepeatedlytodrain
thecontractunfairly.Lackofstorageandvalueblindnessconstrainsapplicationssuchasdecentralizedexchange.
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.Itsuffersfromthesamevalueblindnesslimitation.
NextsectionhighlightstheelegantEthereumapproach,andformsthebasisforprotocolsdescribedherein.
5.LedgercontractingwithEthereum
TheEthereumprojectintroducesmanyinnovations,ofwhichthefollowingareimportantforthisproposal:
a.Ledgercontractsarevalueawareandpossessapersistentstoragecapacity.
b.Ledgercontractscanbeloaded/unloadedwithfundswhenrequired.Conditionsforloading/unloading
canbemandatedbycontractcode.
c.Messagescontainingdatacanbesenttoledgercontracts.Contractscanrespondwithdatarepliesand
valuetransferstoinputs.
UtilityoftheaboveisdemonstratedinSection7.Henceexamplesareavoidedhere.
OtherEthereuminnovations,beingperipheraltoourdiscussion,willbeengineeredawayinsection12:
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

5/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

a. Ledger contracts have access to certain types of random data. The intent is to provide an entropy
sourceforgamblingapplications.
b.ScriptinglanguageusedtocreateledgercontractsisTuringcomplete,enablingcontractlogictocontain
loops.
c. Ledger contracts can create other ledger contracts, and hence have the same power as an external
accountcontrolledbyahuman.ThisisreferredtoastheContractfirstclasscitizenproperty.
The combination of points b. and c. mean that infinite loops can potentially be triggered while updating the
Ethereumledger.TheHaltingproblemplacesalimitationonevaluatingwhetheranarbitraryscriptwillterminate
infinitetimeandpreventsnetworknodesfromrejectingtransactionsresultingininfiniteloops.Ethereumusesits
transaction fee structure to prevent and incentivize participants from submitting transactions triggering infinite
loops.
Theriskintroducedbylatterinnovationsistwofold:
a.The transaction fee method of preventing infinite loops will prove deficient in some, as yet unknown,
way.
b. Cleverly designed malicious contract code could escape the Ethereum Virtual Machine and cause
damagetonetworknodes.
Section 12 deals with an approach to remove risk while enjoying certain benefits from Ethereums architecture.
Thedrivingforceistoreduceriskandcomplexityatseedstagesofproposalimplementation.
Sections610assumecompletesetofEthereumledgercontractingabilitiesarevalid.
6.Ledgerlayer
Theledgerlayerisbuiltusingaprotocolthatenablesasinglepartyorgroupofpartiestocreateledgersandissue
assetsasrequired.Eachledgerhasanissuerofasset,anumberforledgeridentification,andanidentificationfor
theassetissued.
Minimalpropertiesforledgersare:
a.Issuerofassetforeachledgerisdifferentfromentitiesmaintainingtheledger.
b.Ledgersaremaintainedthroughadecentralizedconsensusprocess.Thesetofnodesparticipatinginthe
consensusprocessiscalledaConsensusPool.
c.Ledgeraccountbalances,contractsandtransactionsarepublic.
d.Transactionsareinitiatedthroughtheuseofdigitalsignatures.
e.Multisignatureaccountsareafundamentalrequirement.
f.Basicledgercontractingcapabilitiesarerequiredateachledger.Setofminimalcapabilitiesisdetailed
insection12.
g.Fastledgertransactiontimes,preferablylessthantwosecondsforfullconfirmation.Thisisachievable
for decentralized ledgers if identity of consensus pool nodes is known. We assume the same in the
subsequentexposition.
h.Atimealignmentmechanismforconsensuspoolsandassociatedledgers.
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,thefocusistoproposeafinancialsysteminteroperablewithcommoditybackedcurrencies,informational
commodities like bitcoin, fiat money, shares and other assets. Finally, the proposed system does not necessitate
creationofanynewcurrencyorasset.
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

6/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

Figure 6 visualizes a section of the ledger layer. Ledgers with the same asset type possess the same color. A
blackdotinsideacoloredcirclestandsforanaccount.Accountscorrespondingtoassetissuersareshown.Issuer
nameshavebeenchosentoaidwithvisualization.Largebanksandfirms,beingnaturallyandrightlyconservative,
arenotinitialcustomersfortechnologydescribedherein.

IfCarolholdsassetsonledger4,weassumethatatrustrelationshipexistsbetweenherandtheissuerofledger4
(WellsFargo).
ThecaseofAlice,holdingUSDassetsonledger1andwantingtotransferthemtoBob,acustomerofthesame
issuer on the same ledger, i.e intraledger transfer, is trivially resolved. Next section will consider interledger
transfers.
7.PaymentandExchangeLayer
ThislayeristaskedwithresolvingtwosituationsfacedbyAliceandBob:
Situation1: Alice possesses V USD issued by Citibank on ledger 1, and wants to exchange them for W Euros
heldbyBobonledger2.FidorbankistheissuerofEuros.Section7atacklesthisscenario.
Situation2:AliceholdsVUSDissuedbyCitibankonledger1,andwantstomakeapaymenttoBob.Bobisa
USDWellsFargocustomeronledger2.Sections7b,7cand7dpresentresolutions.
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). Microtransaction payments are
consideredinAppendixA.
7a.DecentralizedExchangeProtocol(DEP)
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

7/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

DecentralizedExchangecanbeimplementedastwointerlockingledgercontractscreatedtomediateanexchange
relationship. Figures 7a, 7b, 7c and 7d provide a visualization. For convenience, we name the two contracts as
DispensingcontractandAcceptingcontract.TheprotocolproceedsinfourphasesandassumesAlicecreatesan
offeracceptedbyBobasacounterparty:
PhaseI:AlicecreatesAcceptingandDispensingcontractsonthetwoledgers
a.Figure7aisarepresentationofphaseI.
b.AlicecreatesAcceptingcontractonLedger2andDispensingcontractonledger1.
c. Combination of Accepting and Dispensing contracts constitute Alices offer for exchange. Pricing
informationisheldasastorageentryinbothcontracts.
d.AliceloadsDispensingcontractwithvalueV.
e.CapabilitiesofAcceptingandDispensingcontractsareelaboratedinthetexttofollow.

PhaseII:BobcreditsAcceptingcontractandclaimsvaluefromDispensingcontract
a.Figure7bvisualizesphaseII.
b.BobverifiesthatAcceptingandDispensingcontractsconstituteanacceptableofferandarestructured
correctly.
c.BobcreditsAcceptingcontractwithvalueW.
d.AcceptingcontractholdsfundsinastatethatAliceneedsclaimmessagefromphaseIIIctowithdraw
them.
e.BobfurnishesproofofpaymentfromprevioussteptoDispensingcontractonledger1.

https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

8/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

PhaseIII:DispensingContractreleasesfundstoBobandsendsclaimmessagetoAlice
a.Figure7csketchesstepsforphaseIII.
b. Dispensing contract verifies proof of payment and checks whether the same has not been used
previously.WhenvalidittransfersvalueVtoBobonledger1,andaddsproofofpaymentdatatocontract
storage.
c.DispensingcontractsendsaclaimmessagetoAliceonledger1.Thiscanbeusedtoclaimfundsfrom
AcceptingcontractimmediatelyorperAlicesconvenience.

PhaseIV:AliceusesclaimmessagetoextractfundsfromAcceptingcontract
a.Figure7disarepresentationofphaseIV.
b.AlicesendsclaimmessagetotheAcceptingcontract.
c.Acceptingcontractverifiesveracityofclaimmessage,andcheckswhetherthesamehasnotbeenused
inthepast.
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

9/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

d.If claim message is valid, Accepting contract releases funds to Alice on ledger 2. It adds data about
claimmessagetostorage.

CapabilitiesofDispensingandAcceptingcontracts
a.DispensingcontractmustholdvalueVinescrow,andbecapableofverifyingproofofpaymentfrom
ledger2.Usedproofsneedtobestoredinmemorytopreventreuse.
b.AcceptingcontractmustholdvalueWinescrow,andbeabletoverifyclaimmessagesfromledger1.
Claimmessagesalreadyutilizedmustbewrittentocontractstorageforpreventingreuse.
Aforedescribed flow assumes that the exchange is atomic i.e. value V in Dispensing contract is claimed in a
singletransaction.ThisismodifiabletoincludescenarioswithBobclaimingafractionoftheofferbytransferring
valueX(X<W)toAcceptingcontractinphaseII.
Additionally,therearetwoedgecasestobeconsidered:
a.InsufficientbalanceattheDispensingcontract:Becausetheremaybenorestrictiononthenumberof
counterparties transferring funds to the Accepting contract in phase II, it can transpire that there exists
insufficient balance at the Dispensing contract for Bob to claim his funds. To prevent loss of funds for
Bob, an additional functionality must exist enabling Dispensing contracts to send Exchange rejected
message to Bob on ledger 1. Reject message can be utilized by Bob to reclaim funds on ledger 2. No
claimmessageissenttoAlice,andhenceshecannotunlockfundsonledger2.
b.OrdercancellationforAlice:AlicemustpossesanabilitytowithdraworaddfundstotheDispensing
contract,withacompletewithdrawalsignifyingordercancellation.Suchanabilitydoesnotinterferewith
thetransactionflowdescribedpreviously.Insufficientbalanceresultingfromwithdrawalscanbehandled
bytheRejectmessageflowdescribedinthepreviouspoint.
AlthoughDEPistrustlessandpeertopeer,thereexistsanicheforinformationservicestrackingexchangeoffers
on different ledgers. Services can query consensus pool nodes for offers and verify that ledger contracts are
structuredcorrectly.Counterpartiescanremunerateservicestoaccessupdatedinformation.Purelyinformational
servicesaretheInternetofMoneyequivalentfororderbooks.
DEPispowerfulasiteliminatestheneedformediatingpartiesincurrencyandshareexchanges.Figure8aplots
parties and relationships required in conventional share exchanges between Alice and Bob. Figure 8b with DEP
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

10/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

delivers a contrast to 8a, and underscores the potential for low cost exchanges. A similar parallel exists for
currencyexchanges.
TheroleoftheCentralSecuritiesDepositoryandCustodiansisreplacedbythepublicApplesharescryptographic
ledger.BrokersandStockexchangesarereplacedbyinformationservicestrackingoffersonledgers.Thereisno
requirement for a Clearing House as Alice and Bob bear no counterparty risk and protocol execution takes ~4
secondsforBob.

Finally,DEPservesasabridgeconnectingfiatcurrenciesandinformationalcommoditiessuchasetherand
bitcoin.

7b.StaticLiquidityPaymentProcessingProtocol(SL3P)

https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

11/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

Unlike Decentralized Exchange, which is an evolutionary improvement over the current system, SL3P is a new
modalityofpaymentprocessing.
ConsiderthesituationinFigure9a.AlicepossessesVUSDissuedbyCitibankonledger1,andwantstomakea
paymentofthesamevaluetoBob.BobisaUSDWellsFargocustomeronledger2.TherealsoexistsCarol,a
partyunrelatedtoAliceandBob,holdingbalancesonbothledgers.Carol:
a.TrustsbothCitibankandWellsFargoasIssuers.
b.Isindifferenttothemagnitudeofindividualbalancesheldatbothledgers,aslongastheirtotalremains
constant.
c.HoldsgreaterthanVUSDwithWellsFargo.
d. Has no immediate need to transact with balances held at both ledgers i.e. her balance is Static
Liquidity.

Followingtransactionset,pictoriallydepictedinFigure9b,resolvesthepayment:
a.AlicepaysCarolVUSDonledger1.
b.CarolpaysBobVUSDonledger2.

https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

12/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

SL3Pleveragestwoledgercontractstoenablemultipledesirablepropertieswithabovetransactionlogic:
a.LedgercontractsassureAlicethatCarolwillpayBobonledger2,orshewillreceivehermoneyback
onledger1.
b.Ledger contract can be persistent i.e. Carol structures contracts once and contracts process multiple
paymentsbetweendifferentpartiesautonomously.
c.CarolcanchargeprocessingfeesforpaymentsenabledbyherStaticLiquidity.
Theprotocolproceedsinfourphases:
PhaseI:CarolopensanSL3Pchannelbycreatingcontractsonbothledgers
a.Figure10aisarepresentationofphaseI.
b.CarolcreatesSL3Pcontract1onledger1andSL3Pcontract2onledger2.
c. Combination of symmetric SL3P contracts 1 and 2 is called an SL3P channel. Contracts store
magnitudeoffeeschargedpertransactionasdataentries.
d.Carolloadscontract1withvalueX,andcontract2withvalueY.
e.CapabilitiesofSL3Pcontractsareelaboratedinthetexttofollow.

PhaseII:AlicecreditsSL3Pcontract1andclaimsapaymenttoBobfromSL3Pcontract2
a.Figure10bvisualizesphaseII.
b.AlicewantstopayBobvalueVandverifiesthatSL3Pcontract2containsabalancelargerthanV.If
yes,sheproceedstonextstep.
c.AlicetransfersVUSDtoSL3Pcontract1.
d.SL3Pcontract1holdsfundsinaspecialstate.ThesefundscanbewithdrawnonlyafterphaseIV,orif
SL3Pcontract2failstopayBobinphaseIIId.
e.AlicepushesproofofabovepaymenttoSL3Pcontract2,andinitiatesatransfertoBobsaccounton
ledger2.

https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

13/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

PhaseIII:SL3Pcontract2verifiesclaimandmakesapaymenttoBob
a.Figure10csketchesstepsforphaseIII.
b.SL3Pcontract2verifiesproofofpaymentandcheckswhetherthesamehasnotbeenusedpreviously.
When valid, it transfers value V to Bob and State change message to Carol on ledger 2. Proof of
paymentdataisaddedtocontractstorage.
c. State change message can be used by Carol to make SL3P contract 1 funds deposited in phase IIc
withdrawablebyher.
d.If balance is insufficient, contract sends a Payment reject message to Alice on ledger 2. Alice can
usetherejectmessagetoclaimfundsfromSL3Pcontract1.
e.ThereisnoroleforBobintheprotocolexcepttoverifyforsuccessfultransfer.

PhaseIV:Carolusesstatechangemessagetorenderfundswithdrawablebyher
a.CarolpushesstatechangemessagefrompreviousphasetoSL3Pcontract1.
b. SL3P contract 1 verifies state change message, stores message in memory to prevent reuse, and
convertsvalueVtobewithdrawablebyCarolinthefuture.
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

14/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

c.Only funds that are withdrawable by Carol participate in future SL3P payments. Carol can delegate
phase IV to a third party. Third party monitors SL3P contracts and ensures they have sufficient
participatingstaticliquidity.

CapabilitiesofSL3Pcontracts
a.SL3Pcontractsmustholdbalancesinescrowandbecapableofverifyingproofsofpaymentandstate
changemessages.Usedproofsandmessagesneedtobestoredinmemorytopreventreuse.
b. In case of insufficient balance to complete an SL3P payment, destination contract must issue a
Payment rejected message to the initiator. Payment rejected messages should enable value reclaiming
fromtheotherpairedcontract.
c.SL3PcontractsmustallowCaroltomakedepositsorwithdrawalsprovidedsuchactionsdonotviolate
contract conditions. Channel termination is a complete withdrawal of balances from both contracts by
Carolfollowedbyresolutionofalloutstandingpayments.
Theprotocolcanalsoworkinthereversedirection.BecauseSL3Pcontractsaresymmetric,Davecaninitiatea
paymentfromLedger2withthedestinationbeingEveonLedger1.
Paymentprocessingisconvertedtoapeertopeerformatpavingthewaytoacompetitivemarket.Theprotocolis
acombinationof2transfersandcontractcomputation,andthereforecanbeexecutedin~4seconds.
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,
resultingstructureistheequivalentofadomesticcorrespondentbankingrelationship.Readersshouldbearinmind
thatdomesticcorrespondingbankingisincreasinglyananachronisticsolution.
SL3PimprovesoverDeferredNetSettlementsbecauseissuersdonotassumecreditriskforpaymentprocessing.
TomitigateagainstcreditriskinDeferredNetSettlements,issuersarerequiredpledgecollateralwiththenational
clearinghouse.SL3Pintroducesnosuchnecessity.
Another key advantage is the creation of new pools of liquidity for payment processing. Liquidity cost is the
determiningfactorforpricingofRTGSpayments.Acoreassumptioninthecurrentsystemisthatliquidityneeded
forpaymentprocessingisfurnishedbyissuers.SL3Pcanbreakthisassumption,buildalargerliquiditypooland
thereforeresultincheaperpayments.
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

15/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

7c.RealTimeGrossSettlementProtocol(RTGSP)
SimilartoSL3P,RTGSPsolvestheproblem:AlicepossessesVUSDissuedbyCitibankonledger1,andwantsto
makeapaymentofthesamevaluetoBob.BobisaUSDWellsFargocustomeronledger2.
RTGSPistheproposalsequivalentoftheFedWiresystemusedforhighvaluetransfersintheUnitedStates.It
allowsinteractingissuerstosettleinterbankliabilitiesaccruingfrompaymentsontheFRledger.Figure11plots
theFedWiretransactionflow.
Alice initiates a FedWire credit, with Citibank acting as the OFI and Wells Fargo as the RFI. Citibank debits
AlicesaccountimmediatelyandWellsFargocreditsBobsaccountafterafewminutes.
Internally,CitibanksubmitsacreditrequesttotheFR,whichthenforwardsittoWellsFargo.TheFRprocessesa
settlementtransactionsendingmoneyfromCitibanktoWellsFargoontheFRledger.Asthetransactionhappens
in real time and the complete settlement amount is transferred in gross, this modality of payment processing is
calledaRealTimeGrossSettlement(RTGS).CitibankandWellsFargoassumenocreditrisk.
Thispointonward,werefertoCitibankasIssuer1,andWellsFargoasIssuer2.Theobjectiveistodemonstrate
apaymentprotocolassumingCitibank,WellsFargoandtheFRoperatecryptographicledgers.

SL3PprovidesarouteassketchedinFigure12.IssuersopenonewaySL3PchannelsbetweentheFRledgerand
ledgerstrackingtheirownassets.AnSL3PchannelmaintainedbyIssuer2isplottedinFigure12.Onledger2,
Issuer2createsassetsandloadsoneendofthechannel,sketchedindarkpink.
OnewaySL3Pchannelreferstoamodifiedconstructionwherepaymentsflowonlyinonedirection.Thisisa
simplemodificationofledgercontractsfromsection7b.
Alice initiates the transaction by transferring value V to Issuer 1. The transaction contains data specifying
destinationledgerandBobsaccount.ThiseffectivelydestroysassetsheldbyBobandissuedbyIssuer1.
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

16/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

AssumingCitibankhasrequisiteliquidity,ittransfersvalueVtoSL3PcontractmaintainedbyIssuer2ontheFR
ledger.Next,itpushesaproofofpaymenttoothersideofthechannelonledger2,andclaimsatransfertoBobs
account.
Assuming sufficient contract balance, ledger 2 SL3P contract verifies proof of payment and completes the
transfer.Issuer2keepsloadingfundsperiodicallyintothecontracttokeepRTGSPtransfersflowing.Incaseof
insufficientcontractbalance,Issuer1canretryorclaimbackfundsfromtheotherendofthechannel.

Although the previous set demonstrates that RTGSP is feasible, it does not tackle the central challenge of an
RTGSsystem:liquiditymanagement.AppendixBconsidersmethodsforthesame.
RTGSPcouldenableautomationofFedWireandotherGrosssettlementsystems,withtheroleoftheFRreduced
tobeingapureissuer.ThesystemcanstayoperationalaslongasConsensusPoolfortheFRledgerisreachable.
Currently,useoftheFedWiresystemisrestrictedtobetween09:00and18:00ETintheUnitedStates.
Decentralization of the FR ledger and RTGS system can be a good operational risk reduction and business
continuitypolicy.Nodescanbedistributedgeographically,madedependentondifferentpowersystems,anddata
redundancies / backups created. In general, all Systemically Important Payment Systems tangibly benefit from
decentralizationthroughoperationalriskreduction.
7d.DeferredNetSettlementProtocol(DNSP)
DNSPsolvesthesameproblemasSL3PandRTGSP:AlicepossessesVUSDissuedbyCitibankonledger1,and
wantstomakeapaymentofthesamevaluetoBob.BobisaUSDWellsFargocustomeronledger2.

https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

17/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

Instead of payment clearing and settlement being a transfer on the FR ledger like RTGSP DNSP results in the
creationofadebtobligationfromCitibanktoWellsFargo.Multipleobligationsareaggregated,andnetamounts
aretransferredbetweenissuersasbilaterallyagreedontheFRledger.Paymentclearingisthecreationofinter
issuerdebtobligationandpaymentsettlementisthetransferontheFRledger.DNSPdeferspaymentsettlementto
atimepointafterpaymentclearing.Theprotocolhasarequirementforinterissuertrustunliketheothers.
AcombinationofDEP,SL3PandRTGSPcanbesufficienttohandlealargepartofbankingtransactions.DNSP
isincludedforthesakeofcompleteness.ItistheequivalentoftheACHsystemintheUnitedStates.
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:
a. The ability of accounts to create trust lines to other accounts. A trust line is an approval from an
account holder to the consensus pool, allowing the pool to change account balances pursuant to values
andpartiesspecifiedinthetrustline.
b.Theabilityofconsensuspooltorouteapaymentfromoneaccounttoanotherbychangingbalancesin
otheraccounts,subjecttolimitationsimposedbytrustlines.
Figure13considersaUSdollartraversalledger,with4participants:Eve,Frank,GaryandHarry.Figure13a,on
the left, shows the current status of trust lines. A line originating at Frank and terminating at Eve with value M
USD signifies Franks approval to have Eve owe him a maximum of M USD. Participants can alter trust line
valuesdynamically.
Figure 13b, on the right, shows a traversal transaction payment from Eve to Harry worth W USD. Before
payment,weassumenoneoftheparticipantsoweeachotheranymoney.Afterthetransaction,EveowesFrank
WUSD,FrankowesGaryWUSDandGaryowesHarryWUSD.HarryacceptsthisasapaymentofWUSD.
Netbalanceforeachaccountequalsfundsowedtoparticipantminusfundsowedbyparticipant.Netbalancefor
Frank and Gary remain unchanged by the transaction. Gary and Frank do not actively participant in the
transaction.Harrysroleistoverifythepayment.
Because the ledger may contain more participants the consensus pool computes the optimal payment path,
sketchedthroughredarrowsin13b,andadjustsbalancesautonomously.

https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

18/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

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,
sketchedinFigure14aand14b.
PhaseI:AliceinitiatespaymentandIssuer1reservesvalueVonledger2
a.Issuerscreateanescrowcontractonledgerstrackingtheirassets,andloaditwithfunds.Capabilities
ofescrowcontractareexplainedlater.
b. Alice transfers value V to Issuer 1 on ledger 1. Transaction contains destination ledger and Bobs
addressasmetadata.
c.Issuer 1 makes a traversal transaction payment worth value W to Issuer 2 on the domestic clearing
ledger.WissmallerthanVandcanbe~5USD.
d.Issuer1pushesproofofabovepaymenttoescrowcontractonledger2,requestingcontracttoreserve
valueV.
e.Escrowcontractverifiesproofofpayment.Nextstepsassumeavalidproof.
f.IfcontractpossessesfundsgreaterthanV,itreservesVfortimeT.Duringperiodbetween0andT,V
canbetransferredonlytoBobwhenIssuer1completesPhaseII.Tcanbeapproximately1minute.
g. If contract does not possess requisite funds to complete the reservation, it transfers W to Bob, and
sendsIssuer2aReservationrejectedmessage.

PhaseII:Issuer1transfersvalue(VW)onclearingledgerandclaimspaymenttoBob
a.Assumingreservationhassucceeded,Issuer1transfersvalue(VW)toIssuer2ontheclearingledger.
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

19/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

b.Issuer1pushesproofofabovepaymenttoescrowcontractonledger2,andclaimsapaymentofvalue
VtoBob.
c.Escrowcontractverifiesproofofpayment,andifvalid,transfersreservedfundstoBobonledger2.
d.Incase Issuer 1 is unable to complete phase II within time T for which funds were reserved, it can
claimatransferworthvalueWtoBob.TherecanbeapenaltyvalueX(X<W)leviedbyescrowcontract
forsuchscenarii.

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
followingreasons:
a. Value at risk is low. W can be approximately 5 USD and is small in scale compared to payments
handledbythefiatsystem.
b.Ifescrowcontractisdepleted,allDNSPpaymentsonledger2arestoppedandproblemisescalatedas
ledger2ispublic.ReputationofIssuer2willbedamagedthroughperiodsofDNSPshutdown.
Debt obligations between issuers arising out of DNSP are settled on the FR ledger as bilaterally agreed.
SettlementisasimpletransferfromoneissuertoanotherontheFRledger,andisthereforenotillustrated.
DNSP separates the clearing and settlement processes, resulting in a speedy transfer (~10 seconds) to Bobs
account.Manycurrentsystems,likeACHintheUnitedStatesandBacsintheUnitedKingdom,clearandsettle
transfers once a day. Hence, DNSP could be an improvement. Additionally, the trust line design of clearing
ledger removes the 2tiered centrally operated membership systems present today. Any issuer can take part in
clearingaslongasitisabletoobtainatrustlinefromanotherissuer.

https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

20/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

BeingaSystemicallyImportantPaymentSystem,decentralizationoftheClearingledgerreducesoperationalrisk
andcanbeagoodbusinesscontinuityapproach.
8.Unification
Previous section with its characteristic proliferation of protocols can appear daunting from the perspective of
implementation.Thisapparentcomplexityisaresultofinteractionsinthefiatsystem,andcanbereducedtoan
elegantsimplicityattheimplementationlevel.
A key observation is that ledger contracts utilized for DEP and RTGSP are derivatives of SL3P. Figure 15
expressesthestatement.

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.
Transactionflowresultingfromthesesubstitutionsisacurrencyexchange.
We can elect to stop referring the protocols by different names, although the author believes it is helpful to
differentiate.
9.PathfindingLayer
Atthepathfindinglayer,protocolsdescribedpreviouslyaretreatedasatomicoperationsof5types:
a.Valuetransfersbetween2accountsononeledger.Executiontimeisassumedtobe~2seconds.
b.Valueexchangesbetween2ledgerstrackingthesameordifferentassettypesthroughDEP.Execution
timecanbeassumedtobe~4seconds.
c.Valuetransfersbetween2ledgerstrackingthesamecurrencytypethroughSL3P.Executiontimecan
beassumedtobe~4seconds.
d.Value transfers between 2 ledgers tracking the same currency type through RTGSP. Execution time
canbeassumedtobe~6seconds.
e.Valuetransfersbetween2ledgerstrackingthesamecurrencytypethroughDNSP.Executiontimecan
beassumedtobe~10seconds.
Anyglobalpayment,remittance,assetpurchaseorexchangeoriginatingatonecryptographicledgerandendingat
anothercanbebrokendownintoatomicoperationsofthe5typesmentionedabove.Thepathfindinglayeristasked
withcalculatingtheoptimalsetofatomicoperationstobeexecutedforthedesiredvaluetransferorexchange.
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

21/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

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 57 atomic
operations.Amaximumtransfertimeof1minutegloballylooksacceptableatthisjuncture.
Therawdataforthepathfindingalgorithmisoffollowingtypes:
a.RealtimedatabaseofDEPoffersondifferentledgers.
b.AsetofSL3Pchannelsoperatingbetweenledgers.
c.AsetofgloballyrecognizedRTGSPnetworks.
d.SetsofissuersthatparticipateinRTGSPnetworks.
e.AsetofgloballyaccreditedDNSPnetworks.
f.SetsofissuersthatparticipateinDNSPnetworks.
g.Costfunctiondataformonetarycoststowardsexecutingatomicsteps.
TheanalogueforthepathfindinglayerinthearchitectureoftheInternetareroutingprotocolssuchasRIP,OSPF
and BGP. Communication routing through the internet requires routers and nodes to broadcast reachability
informationcontinuouslyandcanbevisualizedasaquasidistributedalgorithmacrossmultiplerouters/nodes.
IntheInternetofMoney,centralizedserviceswherearoutingquerycanbesentandanoptimalpathreceivedlook
feasible. Data gathering and computation are outsourced to these services relieving the clients from workload.
Considerationofexactalgorithmtocalculateoptimalpathsfromrawdataisleftforafuturearticle.
Once optimal paths are received by the client, it proceeds to execute the atomic operations resulting in global
valuetransferandexchange.
Figure15isavisualrepresentationofpathfinding.AliceownsSwissFrancassetsontheUBSledgerandwantsto
purchase Apple shares. She issues a routing query to pathfinding server. Pathfinding server has a database of
RTGSPnetworks,DNSPnetworksandcontractsondifferentledgers.Itevaluates3alternativepaths,indicatedin
thefigure,thatAlicecouldtake.ItforwardstheoptimalpathtoAliceafteraccountingforpaymentandexchange
fees.
Alices client has protocol software to execute actions required for atomic operations. She does the same and
achievesthedesiredassetpurchase.

https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

22/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

10.ContractLayer
Thecontractlayerenablestheintersectionofvalueandarbitrarycoderunningtoaltervaluebalances.Thiswould
be implemented through the construct of programmable oracles conceived by the Codius project and Gavin
Andresen.
Fromthevantagepointofthecontractlayer,lowerlayersactasasingulargloballedger.Thisabstractledgercan
holdbalancesandmoveanyassetsinunder1minute.
FundsintendedforasmartcontractarechannelledintoanMofNmultisignatureaccountcontrolledbyasetof
specialized entities (programmable oracles) and the contract code is simultaneously sent to all of these entities.
Everytimecontractingpartieswishtosendamessagetothecontract,theydirectthemessagetotheoracles.The
oracles run the code to compute participant balances. If code execution leads to withdrawal of funds from the
contracttosomeparticularaddress,thentheoraclescirculateatransactiontransferringthefundsandsignit.Fund
transfersarehandledbythelowerlayersoftheInternetofMoney.Figure17visualizesthecontractlayer.

https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

23/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

Section12dealswithquantifyingdifferencesbetweenledgercontractingandthecontractlayer.Ingeneral,ledger
contractingisusedtobuildPaymentandExchangeprotocols.Othersmartcontractusecasesareimplementedat
theContractLayer.
Asanexample,anapplicationisaLondonbrentcrudeoilfuturescontractbetweenAliceandBob.Thecontractis
representedbycomputercodeexecutedbytheoraclestheseentitiesfetchexternaldatatocomputenewbalances
for Alice and Bob at settlement time. After code execution, balances are credited back to Alice and Bob using
lowerlayersoftheInternetofMoney.
A second example is sophisticated buyer and seller intermediation of the type sketched in Figure 4. Alice, the
buyer,andBob,theseller,wouldlikepaymentamounttodependontimetakenforsuccessfuldelivery.Bobneeds
tobepenalizedforlongerdeliverytimes.AcontractiscreatedandAliceloadsfunds.Contractingserviceverifies
proofofgoodsdeliveryandpaysBobaccordingly.
A third example is an auction for digital assets. Contracts can be structured to carry out rules for an auction if
ownershipofdigitalassetortitlearehandedovertotheprogrammableoracles.
11.ApplicationLayer
Parallel to the TCPIP protocol suite, this layer houses applications and user interfaces for consumers. In
particular,thefollowingappearcommerciallysignificant:
Debitandcreditbasedpaymentnetworks
Although the Internet of Money is foreseen to deliver an order of magnitude improvement in speed of value
transferglobally,someusecasesrequirepaymentnetworkslikeVisaandMastercard.Suchcasesare:
a.Situationswheretransferconfirmationneedstobeinstantaneouslikeinstorepurchases.
b.The requirement for multiple atomic transfer and exchange operations necessitates private keys to be
usedmultipletimes.Adedicatedpaymentnetworkcoulddeliveradditionalsecurity.
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

24/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

c.Paymentnetworkscouldfacilitatearbitrationbetweenbuyersandsellers.
Itisfeasibletoreducesettlementriskbornebypaymentnetworksasaresultoffastpaymentandexchangetimes
facilitatedbythistechnology.Visasestimatedsettlementexposurestoodat$53.8billiononSeptember30,2013.
Finally,thecontractlayerenablesnewmethodsofarbitrationlikedoubledepositescrow.
Futures,options,derivatives,predictionandothermarkets
Onekeydesignprinciplebehindthisarticleistheprincipleofunbundling:EachfunctionfortheInternetofMoney
isoperatedbydistinctspecializedentities.Forexample,consensuspoolsspecializeinledgermaintenance,banks
in asset issuance and regulations, pathfinding services in pathfinding, and other firms in contracting and
applications.
Thecontractandapplicationlayersenablecompetitivemarketsfordevelopmentoffutures,options,derivativeand
predictionmarkets.Differentservicescanspecializeinslicesofthesemarkets.
GamesofHazardassmartcontracts
Asademonstration,thegameofRoulettecanbevisualizedasacontractwiththefollowinglogic:
a.SpinningoftheRoulettewheelisemulatedbyasourceofentropy.
b.Alterationofplayerbalancesisrepresentedbycodewiththegeneratedentropyasinput.
c.ValuetransfersandexchangesoccurthroughlowerlayersoftheInternetofMoney.
Westate,withoutproof,thatallgamesofhazardincludingpoker,blackjackareimplementableassmartcontracts.
DecentralizedApplications
TheabstractledgerisastrongfoundationtobuildDecentralizedApplications.Currentapproacheshavereliedon
creating new tokens for accessing services such as decentralized storage, mesh networking and reputation
systems.TheInternetofmoneyprovidesanalternativetobuildtokenlessDApss.Asanexample,adesignoutline
foraharddiskspacesharingDAppisconsideredinAppendixC.
12.RevisitingtheLedgerlayer
This section will consider some issues to develop a better understanding of minimal requirements at the ledger
layer(Section6):
Whycantledgersbecontrolledbyissuers?
PaymentandExchangeprotocolsarestructuredsuchthatentitiesdifferentfromtheissuerexecutetransactionson
aledger.AnexampleisRTGSP:Issuer1isroutingapaymenttoBobonledger2withoutinvolvementfromIssuer
2.NowassumethataserverbelongingtoIssuer2istheonlynodeinconsensuspoolmaintainingledger2.
Issue with the above is that Issuer 2 can possibly create a new ledger history, inconsistent with the previous
history,claimingthatIssuer1nevercompletedthepaymenttoBob.IfoldhistorydataisunavailabletoAliceand
Issuer1,theremaynotbeagoodwaytodisputethenewhistory.Thelegalcostofdisputingcouldbelargerthan
expectedreparations.
Solutionpositedistohavemultiplepartiesmaintainledgersthroughadecentralizedconsensusprocess.Through
decentralization,issuersandconsumerscanbeassuredofimpartialledgers.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.
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

25/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

Tradeoff inherent with decentralization is efficiency. Nodes need to verify each others processing and
communicate to arrive at consensus. This necessitates higher computation and bandwidth than an equivalent
centralizedledger.
Decentralizationfordecentralizationssakeisnotastrategytobeadvocated.Thearticlesperspectiveis:
Extentofdecentralizationrequiredforaparticularusecaseisanoptimizationproblem
Factorsimpactingefficiency,definedastransactionsprocessedperNPVdollarofinvestmentinnodes,are:
a.Choiceofconsensusprocess.
b.Nodeidentityassumptions.Efficiencyimprovesdramaticallywhenidentityofnodesisknown.Bitcoin
nodesareanonymousandnetworkincursahighcost,~$500millionperyear,toarriveatconsensus.
c.Numberofnodes.Generallythelargeraconsensuspool,lowertheefficiency.
Factorsaffectingconfidenceinimpartialityofledgers:
a. Consensus pool composition. When a reputable firm like Google owns nodes in a pool, it boosts
confidence in the pool. Malicious act originating from a Googleowned node will damage its hard won
marketreputation.AtstakearerealgoodwillassetsofGooglewhicharguablytotaloverabilliondollars.
b.ChoiceofConsensusprocess.Forinstance,PracticalByzantineFaultTolerancecantolerateupto33%
maliciousnodesinapool.
c. Number of different entities controlling nodes in a consensus pool. Higher the number, more the
confidence.
Amountofconfidencerequiredforaledgerdependsonthevalueatrisk.Thestrategyadvocatedisto:
Aimforanoptimalbalancebetweenvalueatrisk,efficiencyandconfidenceinledgers.
For instance, a small homogenous pool may be suitable for tracking loyalty points scheme of a 2store grocery
chain.Citibanksledgerwillbenefitfromahighdegreeofconfidence/decentralization.
Theoptimalledgerlayerprotocol
Because each use case has a different optima for pool composition, number of nodes etc., the ledger layer
protocolneedstobeextremelyflexible.Thereshouldnotberestrictionsonusage,opennessanddevelopmentof
theprotocol.Consensusprocessshoulddeliverbestfeasibleefficiencyinalargecrosssectionofscenarios.
The Hyperledger project is a pioneer in this direction. Hopefully, other projects with similar objectives will
follow.
Whyshouldledgersbepublic?
Allpaymentandexchangeprotocolsdescribedhereindependonledgersbeingpublic.Counterpartiescannotview
offersorverifypaymentsonprivateledgers.
If applications posited are valuable, counterbalancing privacy enhancing technologies need to be developed. In
parallel,Governmentsneedamethodtomonitorfinancialtransactions.InvestmentsintheInternetofMoneycan
be viewed as bets that the cost of ensuring financial privacy will not exceed consumer benefits accruing from
applicationssuchasdecentralizedexchange.
Provided the privacy aspect can be resolved, the author is excited about potential advancements to theories of
economicsandcrisesmanagementresultingfromopenaccesstotransactiondataglobally.
Onmultisignatureaccounts
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

26/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

Inadditiontotheconsumersecurityenhancingbenefitsofmultisignatureaccounts,recallthatthecontractlayer
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 multisignature accounts for daily
operation.
Ontimealignmentmechanismforaconsensuspool
Atimealignmentmechanismprovidesamethodforpoolnodestoconsistentlyagreeonthesameclocktimewith
an acceptable skew tolerance (up to 1 sec is admissible). Good design emanates from the desire to create
powerfulsystemswithminimalcomponents.ThispaperhasutilizedtimebasedtransactionsforDNSPandMTXP
(AppendixA).Methodstodoawaywithbuildingatimealignmentmechanismwhileretainingfunctionalityneed
tobediscovered.
13.Reducingriskandcomplexityatseedstage

14.Observationsandopenproblems
Thefundamentaladvantageofcryptographicledgers
This paper posits that cryptographic protocols built utilizing cryptographic ledgers enable the formation of low
trustfinancialrelationshipsbetweenparticipatingissuersandconsumers.Lowtrustrelationshipsservetoreduce
transactionalandexchangecosts,whichcanbepasseddowntoconsumersasanetsaving.
ScalabilityAnalysis
Implementationofpullbasedpayments
The use of digital signatures lead all cryptographic ledger systems to be push based. Current implementation of
ACHenablespullbasedACHdebits,andithasmultipleapplicationslikeinsurancepayments,loaninstallments,
utilitypaymentsetc.
Amechanismtoenablesuchapplicationscanbebuiltatthecontract/applicationlayers.Considerthesituationof
Alice, a customer to Bob, a utility company. Alice and Bob create a smart contract hosted by mutually trusted
oraclesandAliceloadsthecontractwithfundsintendedformonthlyutilitypayments.Thecontractcontainsrules
lettingBobwithdrawuptoacertainamounteverymonth.
ImplementationofanIdentityandAnonymitylayer
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
consistentmethodofverifyingissuersandledgersisalsoaprerequisite.
15.References
1.https://bitcoin.org/bitcoin.pdf
2.https://en.bitcoin.it/wiki/Script
3.Pages2028,TheTCPIPProtocolSuite,4thEdition,BehrouzA.Forouzan
4.http://hyperledger.com/
5.https://www.regaltek.com/docs/understandingachnetwork.pdf
6.https://github.com/TierNolan/bips/blob/bip4x/bipatom.mediawiki
7.https://github.com/petertodd/bips/blob/checklocktimeverify/bipchecklocktimeverify.mediawiki
8.
http://gendal.wordpress.com/2014/01/05/asimpleexplanationofhowsharesmovearoundthe
securitiessettlementsystem/
https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

27/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

9.Pages323374,TheTCPIPProtocolSuite,4thEdition,BehrouzA.Forouzan
10.
https://github.com/codius/codius/wiki/SmartOracles:ASimple,PowerfulApproachtoSmart
Contracts
11.http://gavintech.blogspot.ch/2014/06/bitthereum.html
12.http://www.sec.gov/Archives/edgar/data/1403161/000140316113000011/R19.htm
13.http://bithalo.org/wpcontent/uploads/2014/06/whitepaper_twosided.pdf
14.https://www.ethereum.org/pdfs/EthereumWhitePaper.pdf
16.Authorshipandacknowledgements
TheauthorMeherRoycanbereachedat:
Email1:meher.roychowdhury@gmail.com
Email2:mr@hyperledger.com
LinkedIn:https://www.linkedin.com/pub/meherroy/43/969/254
Twitter:https://twitter.com/MeherRoy
Special thanks to Tim Makarios for pointing out errors, and suggestions regarding Responsible Traversal
TransactionProtocol.
Possibleupdatesforversion0.4
AlignmentwithHyperledgerwhitepaper
Hyperledger is the best example of a ledger layer protocol and the aim is a pair of 2 compatible papers
(Hyperledgerwhitepaper+thecurrentdocument).
ConsiderationofResponsibleTraversalTransactionsProtocolasabetterDNSP
Detailscanbefoundat:
http://ideophilus.wordpress.com/2014/11/05/aresponsibletransitivetransactionsprotocol/
CompletionofappendicesA,BandC
AppendixA:MicrotransactionProtocol(MTXP)
AppendixB:MethodsforRTGSPLiquidityManagement
AppendixC:AnarchitectureforDecentralizationApplications(DApps)

https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

28/29

11/26/2014

AnarchitecturefortheInternetofMoneyv0.2.9

PublishedbyGoogleDrive ReportAbuse Updatedautomaticallyevery5minutes

https://docs.google.com/document/d/1BckZXROTeMzG6AvH7rrTrUy24UwHoEcgiL7ALHMO0A/pub

29/29