an architecture for the internet of money

Upload: meher-roy

Post on 09-Oct-2015

246 views

Category:

Documents


0 download

DESCRIPTION

A paper describing a method for building a Ripple-like system that enables global value transfer, exchange and settlement.

TRANSCRIPT

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    AnarchitecturefortheInternetofMoneyv0.2.9

    AnarchitecturefortheInternetofMoneyversion0.2.9

    1.Introduction

    SatoshiNakamotosgreatinventionofBitcoincanbeappreciatedashaving2distinguishingfeatures:

    a.Bitcoinisapublicdecentralizedcryptographicledgerwithbasicledgercontractingcapabilities.

    b.Thecryptographicledgertracksbalancesofanewcurrencybitcoin.

    Efforthasbeendirectedtowardsarchitectingaparallelfinancialsystemwithbitcointhecurrencyasabaselayer.The driving force are flexibility benefits of cryptographic ledgers enabling new use cases likeMultisignatureaccounts, Decentralized exchange, Machine to machine transactions etc. This paper analyzes applications ofcryptographicledgersinthecurrentfinancialsystemandaimstostimulatethediscussion:

    What are the speed, cost and flexibility advantages that can be realized if financial institutions trackedasset and liability balances utilizing public decentralized cryptographic ledgers with basic ledgercontractingcapabilities?

    SuchledgersenablenewwaystobuildRealTimeGrossSettlementsystemslikeCHAPSandFedWireDeferredNet Settlement systems resembling ACH, Bacs and correspondent banking foreign exchange markets stockexchanges and other pillars of the financial system. This article encapsulates these disparate elements into acoherentlayerbasedframeworkchristenedTheInternetofMoney.

    PerceivedbenefitsfromtheInternetofMoneywillbeenumeratedalongwithsystemdescriptions.Thesebenefitsformthemotivefortheproposal.

    2.AbbreviationsandDefinitions

    ACH:Automated Clearing House, a system enabling Deferred Net Settlement basis retail paymentprocessingintheUnitedStates.Bacs: A system enabling Deferred Net Settlement basis retail payment processing in the UnitedKingdom.CHAPS: The primary Real Time Gross Settlement funds transfer system utilized for highvaluetransfersintheUnitedKingdom.ConsensusPool:Aset of servers,with definedowners, that continuously arrive at consensus on thestate of a ledger using a fault tolerant algorithm.Healthy consensus pools are characterized by severalserverscontrolledbydifferentparties.DApp:DecentralizedApplication.DE:DecentralizedExchange.DEP:DecentralizedExchangeProtocol,describedinsection7a.DNS:DeferredNetSettlement.DNSP:DeferredNetSettlementProtocol,describedinsection7d. FedWire: The primary Real Time Gross Settlement funds transfer system utilized for highvaluetransfersintheUnitedStates.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 acommodity backed token, currency, informational commodity, share in a company, token representingairlinemilesetc.Ledgercontracting:Pleaserefertosections3and4foranexplanation.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    ODFI:OriginatingDepositoryFinancialInstitution,thebankthatinitiatesanACHcredit.OFI:OriginatingFinancialInstitution,thebankthatinitiatesaFedWirecredit.RDFI:ReceivingDepositoryFinancialInstitution,thedestinationbankforanACHcredit.RFI:ReceivingFinancialInstitution,thedestinationbankforaFedWirecredit.RTGS:RealTimeGrossSettlement.RTGSP:RealTimeGrossSettlementProtocol,describedinsection7c.SIPS:SystemicallyImportantPaymentSystemSL3P:StaticLiquidityPaymentProcessingProtocol,describedinsection7b.Tx:Transaction.

    3.Framework

    InspiredbytheOSIlayermodel,aframeworkfortheInternetofMoneyfollowsinFigure1.

    Subsequent sections detail requirements and capabilities at each layer. The paper can be broken down intofollowingsegments:

    Sections 4 and 5 describe ledger contracting, an innovation pioneered by Bitcoin and conceptuallyupgraded by the Ethereum project. Ledger contracting forms the basis for multiple components in thearticle. Descriptions of Bitcoin in section 4, while correct from an abstract vantage point, divergesignificantlyfromthecurrentimplementation. Sections 6, 12 and 13 deal with the ledger layer. Section 6 makes gross assumptions and omitsjustification. Justificationsanddetailing follow insection12.Purposeofsection13willbeexpressed insection5.Sections7a,7b,7cand7ddealwithDecentralizedExchangeProtocol(DEP),StaticLiquidityPaymentProcessingProtocol(SL3P),RealTimeGrossSettlementProtocol(RTGSP)andDeferredNetSettlementProtocol (DNSP) respectively. This segment elucidates the core innovation underlying the Internet ofMoney.Section 8 shows protocols from section 7 can be unified to 2 fundamental ledger operations. Thisunificationmakesimplementationtractable.Sections9,10and11respectivelycharacterizethePathfinding,ContractandApplicationlayers.Section14postsimportantobservationsandopenproblems.Referencesfollowinsection15,andauthordetailsinsection16.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    Finally,notesoncolorcoding:

    Darkblueboldfontsareusedforsectiontitles.Skyblueboldfontsareusedforsubsectiontitles.GreenboldfontsdemaratePhasesinmultiphasepaymentandexchangeprotocols.Greyboldfontsmarkimportantdefinitions,observationsorparagraphs.Articledetailsothercolorandshapeconventionsasandwhennecessary.

    4.LedgercontractingwithBitcoin

    Conventional ledgers are databases that track value balances corresponding to accounts. They permit clients toinitiateoperations subtractingXunits fromownaccount and crediting the same to adifferent account.Tobe avalid operation, the clients account must possess a balance greater than X. Figure 1 is a visualization for 2Citibankclients,AliceandBob.Aliceinitiatesthepayment.

    Toaboveoperationset,Bitcoinaddsrichnessthroughledgercontracting.Ledgercontractsareaccountsthatholdbalances andoperatewith predefined rules.Entities external toBitcoin, likeAlice andBob, cannotmanipulateledgercontractswithoutfulfillingrulessetduringcontractcreation.ThisisimplementedbyhavingBitcoinnodesrejecttransactionsviolatingcontractrules.

    Forinstance,considerascenariowhereAlicewantstotransferbitcointoBobwiththeprovisothatBobcanspendthe funds only after 31 Dec 2015. This is implementable by creating a ledger contract that holds the bitcoinbalance temporarily.A transaction fromBob, claiming held bitcoinswill succeed only after the date set in theledgercontract.Figure3plotssuchatransactionflow.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    The ledgercontract shouldbe imaginedasaneutralautomated thirdpartymediatinga transactional relationshipbetween Alice and Bob. Readers must bear in mind that above diagram is an abstraction, and Bitcoin isimplementeddifferently.

    Figure4 provides a second illustration.Alice is a buyer andBob is a seller goods tradedhave a longdeliverytime.Trent isa thirdparty trustedbybothAliceandBob.Atpurchase,Alicestorespurchasevalue ina ledgercontract,withtheconditionthat:

    Twopartiesoutofthe3involvedmustsigntransactionsattemptingtounlockcontractfunds.Ifgoodsreceivedarefaulty,AliceandTrentcanroutefundsbacktoAlice.Ifandwhensaleconcludessuccessfully,BobandTrentcompletethepaymenttoBob.

    Figure4showstransactionflowduringsuccessfulsaleanddelivery.TheledgercontractactsasneutralautomatedthirdpartymediatingatransactionalrelationshipbetweenAlice,BobandTrent.

    Bitcoin ledger contracts are coded using a stackbased bytecode language called Bitcoin script. Each ledgercontracthascodeandatemporarydatastructure(stack)associatedwithit.

    TheBitcoincontractingsystemhas2significantlimitations:

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

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

    Figure 5 plots a hypothetical scenario highlighting limitations. Alice wants to leverage a ledger contract toexchangeBitcoinforDogecoin.Shecreatesaledgercontract,andloadsitwithbitcoinsdesiredforexchange.Thecontract is coded such that, when a counterparty furnishes Proof ofDogecoin payment toAlices address thecontractreleasesbitcoinstoanaddresschosenbythecounterparty.

    ThevalueblindnesslimitationimpliesthatBob,acounterparty,mustexchangeexactlytheamountAliceloadedinthe contract.Counterparties coulddesire a smaller exchange size, and therefore prefer to retrieve a fractionoffundsembeddedintheledgercontract.ThisoperationisnotpossiblewithasingleBitcoinledgercontract.

    Assuming fractional exchangesarepossible, theBitcoin ledgercontractmust storeproofsofpayment thathavebeenutilized.Ifsuchstorageisabsent,thecounterpartycanfurnishthesameproofofpaymentrepeatedlytodrainthecontractunfairly.Lackofstorageandvalueblindnessconstrainsapplicationssuchasdecentralizedexchange.

    The previous example is solely intended to highlight limitations. It has other unstated flaws. Decentralizedexchange with bitcoin would be better implemented through a different construct called Atomic Cross ChainTrades.Itsuffersfromthesamevalueblindnesslimitation.

    NextsectionhighlightstheelegantEthereumapproach,andformsthebasisforprotocolsdescribedherein.

    5.LedgercontractingwithEthereum

    TheEthereumprojectintroducesmanyinnovations,ofwhichthefollowingareimportantforthisproposal:

    a.Ledgercontractsarevalueawareandpossessapersistentstoragecapacity.b.Ledgercontractscanbeloaded/unloadedwithfundswhenrequired.Conditionsforloading/unloadingcanbemandatedbycontractcode.c.Messagescontainingdatacanbesenttoledgercontracts.Contractscanrespondwithdatarepliesandvaluetransferstoinputs.

    UtilityoftheaboveisdemonstratedinSection7.Henceexamplesareavoidedhere.

    OtherEthereuminnovations,beingperipheraltoourdiscussion,willbeengineeredawayinsection12:

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    a.Ledger contracts have access to certain types of random data. The intent is to provide an entropysourceforgamblingapplications.b.ScriptinglanguageusedtocreateledgercontractsisTuringcomplete,enablingcontractlogictocontainloops.c.Ledger contracts can create other ledger contracts, and hence have the same power as an externalaccountcontrolledbyahuman.ThisisreferredtoastheContractfirstclasscitizenproperty.

    The combination of points b. and c. mean that infinite loops can potentially be triggered while updating theEthereumledger.TheHaltingproblemplacesalimitationonevaluatingwhetheranarbitraryscriptwillterminateinfinitetimeandpreventsnetworknodesfromrejectingtransactionsresultingininfiniteloops.Ethereumusesitstransaction fee structure to prevent and incentivize participants from submitting transactions triggering infiniteloops.

    Theriskintroducedbylatterinnovationsistwofold:

    a.The transactionfeemethodofpreventing infinite loopswillprovedeficient insome,asyetunknown,way.b.Cleverly designed malicious contract code could escape the Ethereum Virtual Machine and causedamagetonetworknodes.

    Section12dealswithanapproach to remove riskwhileenjoyingcertainbenefits fromEthereumsarchitecture.Thedrivingforceistoreduceriskandcomplexityatseedstagesofproposalimplementation.

    Sections610assumecompletesetofEthereumledgercontractingabilitiesarevalid.

    6.Ledgerlayer

    Theledgerlayerisbuiltusingaprotocolthatenablesasinglepartyorgroupofpartiestocreateledgersandissueassetsasrequired.Eachledgerhasanissuerofasset,anumberforledgeridentification,andanidentificationfortheassetissued.

    Minimalpropertiesforledgersare:

    a.Issuerofassetforeachledgerisdifferentfromentitiesmaintainingtheledger.b.Ledgersaremaintainedthroughadecentralizedconsensusprocess.ThesetofnodesparticipatingintheconsensusprocessiscalledaConsensusPool.c.Ledgeraccountbalances,contractsandtransactionsarepublic.d.Transactionsareinitiatedthroughtheuseofdigitalsignatures.e.Multisignatureaccountsareafundamentalrequirement.f.Basicledgercontractingcapabilitiesarerequiredateachledger.Setofminimalcapabilitiesisdetailedinsection12.g.Fastledgertransactiontimes,preferablylessthantwosecondsforfullconfirmation.Thisisachievablefor decentralized ledgers if identity of consensus pool nodes is known. We assume the same in thesubsequentexposition.h.Atimealignmentmechanismforconsensuspoolsandassociatedledgers.

    Section 11 provides justifications for aforementioned properties. Hyperledger enables maintenance of ledgersthrough the Practical Byzantine Fault Tolerance consensus algorithm, and is an example of a ledger layerprotocol.

    Bitcoin and Ethereum projects assume that network nodes are anonymous. Here, we assume that identity ofconsensus pool nodes is known, and this is amajor point of divergence from other cryptocurrency projects. Inaddition,thefocusistoproposeafinancialsysteminteroperablewithcommoditybackedcurrencies,informationalcommodities likebitcoin, fiatmoney, sharesandotherassets.Finally, theproposed systemdoesnotnecessitatecreationofanynewcurrencyorasset.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    Figure 6 visualizes a section of the ledger layer. Ledgerswith the same asset type possess the same color.Ablackdotinsideacoloredcirclestandsforanaccount.Accountscorrespondingtoassetissuersareshown.Issuernameshavebeenchosentoaidwithvisualization.Largebanksandfirms,beingnaturallyandrightlyconservative,arenotinitialcustomersfortechnologydescribedherein.

    IfCarolholdsassetsonledger4,weassumethatatrustrelationshipexistsbetweenherandtheissuerofledger4(WellsFargo).

    ThecaseofAlice,holdingUSDassetsonledger1andwantingtotransferthemtoBob,acustomerofthesameissuer on the same ledger, i.e intraledger transfer, is trivially resolved.Next sectionwill consider interledgertransfers.

    7.PaymentandExchangeLayer

    ThislayeristaskedwithresolvingtwosituationsfacedbyAliceandBob:

    Situation1:AlicepossessesVUSD issuedbyCitibankon ledger1, andwants toexchange themforWEurosheldbyBobonledger2.FidorbankistheissuerofEuros.Section7atacklesthisscenario.

    Situation2:AliceholdsVUSDissuedbyCitibankonledger1,andwants tomakeapayment toBob.BobisaUSDWellsFargocustomeronledger2.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 SettlementProtocol (RTGSP) and 7d with Deferred Net Settlement Protocol (DNSP). Microtransaction payments areconsideredinAppendixA.

    7a.DecentralizedExchangeProtocol(DEP)

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    DecentralizedExchangecanbeimplementedastwointerlockingledgercontractscreatedtomediateanexchangerelationship.Figures 7a, 7b, 7c and7dprovide a visualization.For convenience,wename the two contracts asDispensingcontractandAcceptingcontract.TheprotocolproceedsinfourphasesandassumesAlicecreatesanofferacceptedbyBobasacounterparty:

    PhaseI:AlicecreatesAcceptingandDispensingcontractsonthetwoledgers

    a.Figure7aisarepresentationofphaseI.b.AlicecreatesAcceptingcontractonLedger2andDispensingcontractonledger1.c.Combination of Accepting and Dispensing contracts constitute Alices offer for exchange. Pricinginformationisheldasastorageentryinbothcontracts.d.AliceloadsDispensingcontractwithvalueV.e.CapabilitiesofAcceptingandDispensingcontractsareelaboratedinthetexttofollow.

    PhaseII:BobcreditsAcceptingcontractandclaimsvaluefromDispensingcontract

    a.Figure7bvisualizesphaseII.b.BobverifiesthatAcceptingandDispensingcontractsconstituteanacceptableofferandarestructuredcorrectly.c.BobcreditsAcceptingcontractwithvalueW.d.AcceptingcontractholdsfundsinastatethatAliceneedsclaimmessagefromphaseIIIctowithdrawthem.e.BobfurnishesproofofpaymentfromprevioussteptoDispensingcontractonledger1.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    PhaseIII:DispensingContractreleasesfundstoBobandsendsclaimmessagetoAlice

    a.Figure7csketchesstepsforphaseIII.b.Dispensing contract verifies proof of payment and checks whether the same has not been usedpreviously.WhenvalidittransfersvalueVtoBobonledger1,andaddsproofofpaymentdatatocontractstorage.c.DispensingcontractsendsaclaimmessagetoAliceonledger1.ThiscanbeusedtoclaimfundsfromAcceptingcontractimmediatelyorperAlicesconvenience.

    PhaseIV:AliceusesclaimmessagetoextractfundsfromAcceptingcontract

    a.Figure7disarepresentationofphaseIV.b.AlicesendsclaimmessagetotheAcceptingcontract.c.Acceptingcontractverifiesveracityofclaimmessage,andcheckswhetherthesamehasnotbeenusedinthepast.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    d.If claimmessage isvalid,Acceptingcontract releases funds toAliceon ledger2. It addsdataaboutclaimmessagetostorage.

    CapabilitiesofDispensingandAcceptingcontracts

    a.DispensingcontractmustholdvalueVinescrow,andbecapableofverifyingproofofpaymentfromledger2.Usedproofsneedtobestoredinmemorytopreventreuse.b.AcceptingcontractmustholdvalueWinescrow,andbeabletoverifyclaimmessagesfromledger1.Claimmessagesalreadyutilizedmustbewrittentocontractstorageforpreventingreuse.

    Aforedescribed flow assumes that the exchange is atomic i.e. value V in Dispensing contract is claimed in asingletransaction.ThisismodifiabletoincludescenarioswithBobclaimingafractionoftheofferbytransferringvalueX(X

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    delivers a contrast to 8a, and underscores the potential for low cost exchanges. A similar parallel exists forcurrencyexchanges.

    TheroleoftheCentralSecuritiesDepositoryandCustodiansisreplacedbythepublicApplesharescryptographicledger.BrokersandStockexchangesarereplacedbyinformationservicestrackingoffersonledgers.Thereisnorequirement for aClearingHouse asAlice andBob bear no counterparty risk and protocol execution takes ~4secondsforBob.

    Finally,DEPservesasabridgeconnectingfiatcurrenciesandinformationalcommoditiessuchasetherandbitcoin.7b.StaticLiquidityPaymentProcessingProtocol(SL3P)

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    UnlikeDecentralizedExchange,which is anevolutionary improvementover thecurrent system,SL3P is anewmodalityofpaymentprocessing.

    ConsiderthesituationinFigure9a.AlicepossessesVUSDissuedbyCitibankonledger1,andwantstomakeapaymentof thesamevalue toBob.BobisaUSDWellsFargocustomeronledger2.TherealsoexistsCarol,apartyunrelatedtoAliceandBob,holdingbalancesonbothledgers.Carol:

    a.TrustsbothCitibankandWellsFargoasIssuers.b.Isindifferenttothemagnitudeofindividualbalancesheldatbothledgers,aslongastheirtotalremainsconstant.c.HoldsgreaterthanVUSDwithWellsFargo.d.Has no immediate need to transact with balances held at both ledgers i.e. her balance is StaticLiquidity.

    Followingtransactionset,pictoriallydepictedinFigure9b,resolvesthepayment:

    a.AlicepaysCarolVUSDonledger1.b.CarolpaysBobVUSDonledger2.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    SL3Pleveragestwoledgercontractstoenablemultipledesirablepropertieswithabovetransactionlogic:

    a.LedgercontractsassureAlicethatCarolwillpayBobonledger2,orshewillreceivehermoneybackonledger1.b.Ledger contract can be persistent i.e.Carol structures contracts once and contracts processmultiplepaymentsbetweendifferentpartiesautonomously.c.CarolcanchargeprocessingfeesforpaymentsenabledbyherStaticLiquidity.

    Theprotocolproceedsinfourphases:

    PhaseI:CarolopensanSL3Pchannelbycreatingcontractsonbothledgers

    a.Figure10aisarepresentationofphaseI.b.CarolcreatesSL3Pcontract1onledger1andSL3Pcontract2onledger2.c. Combination of symmetric SL3P contracts 1 and 2 is called an SL3P channel. Contracts storemagnitudeoffeeschargedpertransactionasdataentries.d.Carolloadscontract1withvalueX,andcontract2withvalueY.e.CapabilitiesofSL3Pcontractsareelaboratedinthetexttofollow.

    PhaseII:AlicecreditsSL3Pcontract1andclaimsapaymenttoBobfromSL3Pcontract2

    a.Figure10bvisualizesphaseII.b.AlicewantstopayBobvalueVandverifiesthatSL3Pcontract2containsabalancelargerthanV.Ifyes,sheproceedstonextstep.c.AlicetransfersVUSDtoSL3Pcontract1.d.SL3Pcontract1holdsfundsinaspecialstate.ThesefundscanbewithdrawnonlyafterphaseIV,orifSL3Pcontract2failstopayBobinphaseIIId.e.Alicepushesproofofabovepayment toSL3Pcontract2,andinitiatesa transfer toBobsaccountonledger2.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    PhaseIII:SL3Pcontract2verifiesclaimandmakesapaymenttoBob

    a.Figure10csketchesstepsforphaseIII.b.SL3Pcontract2verifiesproofofpaymentandcheckswhetherthesamehasnotbeenusedpreviously.When valid, it transfers value V to Bob and State change message to Carol on ledger 2. Proof ofpaymentdataisaddedtocontractstorage.c.State changemessage can be used by Carol to make SL3P contract 1 funds deposited in phase IIcwithdrawablebyher.d.Ifbalance is insufficient, contract sendsa Payment rejectmessage toAliceon ledger2.AlicecanusetherejectmessagetoclaimfundsfromSL3Pcontract1.e.ThereisnoroleforBobintheprotocolexcepttoverifyforsuccessfultransfer.

    PhaseIV:Carolusesstatechangemessagetorenderfundswithdrawablebyher

    a.CarolpushesstatechangemessagefrompreviousphasetoSL3Pcontract1.b.SL3P contract 1 verifies state change message, stores message in memory to prevent reuse, andconvertsvalueVtobewithdrawablebyCarolinthefuture.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    c.Only funds that arewithdrawable byCarol participate in future SL3P payments. Carol can delegatephase IV to a third party. Third party monitors SL3P contracts and ensures they have sufficientparticipatingstaticliquidity.

    CapabilitiesofSL3Pcontracts

    a.SL3Pcontractsmustholdbalancesinescrowandbecapableofverifyingproofsofpaymentandstatechangemessages.Usedproofsandmessagesneedtobestoredinmemorytopreventreuse.b. In case of insufficient balance to complete an SL3P payment, destination contract must issue aPayment rejectedmessage to the initiator.Payment rejectedmessages should enable value reclaimingfromtheotherpairedcontract.c.SL3PcontractsmustallowCaroltomakedepositsorwithdrawalsprovidedsuchactionsdonotviolatecontract conditions. Channel termination is a complete withdrawal of balances from both contracts byCarolfollowedbyresolutionofalloutstandingpayments.

    Theprotocolcanalsoworkinthereversedirection.BecauseSL3Pcontractsaresymmetric,DavecaninitiateapaymentfromLedger2withthedestinationbeingEveonLedger1.

    Paymentprocessingisconvertedtoapeertopeerformatpavingthewaytoacompetitivemarket.Theprotocolisacombinationof2transfersandcontractcomputation,andthereforecanbeexecutedin~4seconds.

    Domestic correspondent banking can be visualized by assuming Carol as one of the 2 interacting issuers. Forinstance, assume issuer for ledger 1 is Issuer 1. If Issuer 1 opens an SL3P channelwith deposits on ledger 2,resultingstructureistheequivalentofadomesticcorrespondentbankingrelationship.Readersshouldbearinmindthatdomesticcorrespondingbankingisincreasinglyananachronisticsolution.

    SL3PimprovesoverDeferredNetSettlementsbecauseissuersdonotassumecreditriskforpaymentprocessing.TomitigateagainstcreditriskinDeferredNetSettlements,issuersarerequiredpledgecollateralwiththenationalclearinghouse.SL3Pintroducesnosuchnecessity.

    Another key advantage is the creation of new pools of liquidity for payment processing. Liquidity cost is thedeterminingfactorforpricingofRTGSpayments.Acoreassumptioninthecurrentsystemisthatliquidityneededforpaymentprocessingisfurnishedbyissuers.SL3Pcanbreakthisassumption,builda larger liquiditypoolandthereforeresultincheaperpayments.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    7c.RealTimeGrossSettlementProtocol(RTGSP)

    SimilartoSL3P,RTGSPsolvestheproblem:AlicepossessesVUSDissuedbyCitibankonledger1,andwantstomakeapaymentofthesamevaluetoBob.BobisaUSDWellsFargocustomeronledger2.

    RTGSPis theproposalsequivalentof theFedWiresystemusedforhighvalue transfers in theUnitedStates. ItallowsinteractingissuerstosettleinterbankliabilitiesaccruingfrompaymentsontheFRledger.Figure11plotstheFedWiretransactionflow.

    Alice initiates a FedWire credit,withCitibank acting as theOFI andWells Fargo as theRFI.Citibank debitsAlicesaccountimmediatelyandWellsFargocreditsBobsaccountafterafewminutes.

    Internally,CitibanksubmitsacreditrequesttotheFR,whichthenforwardsittoWellsFargo.TheFRprocessesasettlementtransactionsendingmoneyfromCitibanktoWellsFargoontheFRledger.Asthetransactionhappensin real time and the complete settlement amount is transferred in gross, thismodality of payment processing iscalledaRealTimeGrossSettlement(RTGS).CitibankandWellsFargoassumenocreditrisk.

    Thispointonward,werefertoCitibankasIssuer1,andWellsFargoasIssuer2.TheobjectiveistodemonstrateapaymentprotocolassumingCitibank,WellsFargoandtheFRoperatecryptographicledgers.

    SL3PprovidesarouteassketchedinFigure12.IssuersopenonewaySL3PchannelsbetweentheFRledgerandledgers tracking theirownassets.AnSL3PchannelmaintainedbyIssuer2 isplotted inFigure12.Onledger2,Issuer2createsassetsandloadsoneendofthechannel,sketchedindarkpink.

    OnewaySL3Pchannelrefers toamodifiedconstructionwherepaymentsflowonlyinonedirection.This isasimplemodificationofledgercontractsfromsection7b.

    Alice initiates the transaction by transferring value V to Issuer 1. The transaction contains data specifyingdestinationledgerandBobsaccount.ThiseffectivelydestroysassetsheldbyBobandissuedbyIssuer1.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    AssumingCitibankhasrequisiteliquidity,ittransfersvalueVtoSL3PcontractmaintainedbyIssuer2ontheFRledger.Next,itpushesaproofofpaymenttoothersideofthechannelonledger2,andclaimsatransfertoBobsaccount.

    Assuming sufficient contract balance, ledger 2 SL3P contract verifies proof of payment and completes thetransfer.Issuer2keepsloadingfundsperiodicallyintothecontract tokeepRTGSPtransfersflowing.Incaseofinsufficientcontractbalance,Issuer1canretryorclaimbackfundsfromtheotherendofthechannel.

    Although the previous set demonstrates that RTGSP is feasible, it does not tackle the central challenge of anRTGSsystem:liquiditymanagement.AppendixBconsidersmethodsforthesame.

    RTGSPcouldenableautomationofFedWireandotherGrosssettlementsystems,withtheroleoftheFRreducedtobeingapureissuer.ThesystemcanstayoperationalaslongasConsensusPoolfortheFRledgerisreachable.Currently,useoftheFedWiresystemisrestrictedtobetween09:00and18:00ETintheUnitedStates.

    Decentralization of the FR ledger and RTGS system can be a good operational risk reduction and businesscontinuitypolicy.Nodescanbedistributedgeographically,madedependentondifferentpowersystems,anddataredundancies / backups created. In general, all Systemically Important Payment Systems tangibly benefit fromdecentralizationthroughoperationalriskreduction.

    7d.DeferredNetSettlementProtocol(DNSP)

    DNSPsolvesthesameproblemasSL3PandRTGSP:AlicepossessesVUSDissuedbyCitibankonledger1,andwantstomakeapaymentofthesamevaluetoBob.BobisaUSDWellsFargocustomeronledger2.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    Insteadofpaymentclearingand settlementbeinga transferon theFR ledger likeRTGSPDNSP results in thecreationofadebtobligationfromCitibanktoWellsFargo.Multipleobligationsareaggregated,andnetamountsaretransferredbetweenissuersasbilaterallyagreedontheFRledger.PaymentclearingisthecreationofinterissuerdebtobligationandpaymentsettlementisthetransferontheFRledger.DNSPdeferspaymentsettlement toatimepointafterpaymentclearing.Theprotocolhasarequirementforinterissuertrustunliketheothers.

    AcombinationofDEP,SL3PandRTGSPcanbesufficienttohandlealargepartofbankingtransactions.DNSPisincludedforthesakeofcompleteness.ItistheequivalentoftheACHsystemintheUnitedStates.

    Central toDNSP is the construct of traversal transactionspioneeredbyRyanFugger and theRippleproject.Atraversal ledger, which enables traversal transactions, has following properties in addition to ledgers hithertoconsidered:

    a.The ability of accounts to create trust lines to other accounts. A trust line is an approval from an account holder to the consensuspool, allowing thepool to change account balances pursuant to valuesandpartiesspecifiedinthetrustline.b.Theabilityofconsensuspooltorouteapaymentfromoneaccounttoanotherbychangingbalancesinotheraccounts,subjecttolimitationsimposedbytrustlines.

    Figure13considersaUSdollartraversalledger,with4participants:Eve,Frank,GaryandHarry.Figure13a,onthe left, shows thecurrent statusof trust lines.A lineoriginatingatFrankand terminatingatEvewithvalueMUSD signifies Franks approval to have Eve owe him amaximum ofMUSD. Participants can alter trust linevaluesdynamically.

    Figure 13b, on the right, shows a traversal transaction payment from Eve to Harry worth W USD. Beforepayment,weassumenoneoftheparticipantsoweeachotheranymoney.Afterthetransaction,EveowesFrankWUSD,FrankowesGaryWUSDandGaryowesHarryWUSD.HarryacceptsthisasapaymentofWUSD.

    Netbalanceforeachaccountequalsfundsowedtoparticipantminusfundsowedbyparticipant.NetbalanceforFrank and Gary remain unchanged by the transaction. Gary and Frank do not actively participant in thetransaction.Harrysroleistoverifythepayment.

    Because the ledger may contain more participants the consensus pool computes the optimal payment path,sketchedthroughredarrowsin13b,andadjustsbalancesautonomously.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    For DNSP, we assume multiple issuers are part of a domestic traversal ledger. Traversal ledger becomes apayment clearingmechanism,with trust linesnegotiatedbetweenpairs of issuers.DNSPproceeds in2phases,sketchedinFigure14aand14b.

    PhaseI:AliceinitiatespaymentandIssuer1reservesvalueVonledger2

    a.Issuerscreateanescrowcontractonledgerstrackingtheirassets,andloaditwithfunds.Capabilitiesofescrowcontractareexplainedlater.b.Alice transfers value V to Issuer 1 on ledger 1. Transaction contains destination ledger and Bobsaddressasmetadata.c.Issuer 1makes a traversal transaction paymentworth valueW to Issuer 2 on the domestic clearingledger.WissmallerthanVandcanbe~5USD.d.Issuer1pushesproofofabovepaymenttoescrowcontractonledger2,requestingcontracttoreservevalueV.e.Escrowcontractverifiesproofofpayment.Nextstepsassumeavalidproof.f.IfcontractpossessesfundsgreaterthanV,itreservesVfortimeT.Duringperiodbetween0andT,VcanbetransferredonlytoBobwhenIssuer1completesPhaseII.Tcanbeapproximately1minute.g. If contract does not possess requisite funds to complete the reservation, it transfersW to Bob, andsendsIssuer2aReservationrejectedmessage.

    PhaseII:Issuer1transfersvalue(VW)onclearingledgerandclaimspaymenttoBob

    a.Assumingreservationhassucceeded,Issuer1transfersvalue(VW)toIssuer2ontheclearingledger.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    b.Issuer1pushesproofofabovepaymenttoescrowcontractonledger2,andclaimsapaymentofvalueVtoBob.c.Escrowcontractverifiesproofofpayment,andifvalid,transfersreservedfundstoBobonledger2.d.Incase Issuer 1 is unable to complete phase IIwithin time T forwhich fundswere reserved, it canclaimatransferworthvalueWtoBob.TherecanbeapenaltyvalueX(X

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    BeingaSystemicallyImportantPaymentSystem,decentralizationoftheClearingledgerreducesoperationalriskandcanbeagoodbusinesscontinuityapproach.

    8.Unification

    Previous section with its characteristic proliferation of protocols can appear daunting from the perspective ofimplementation.Thisapparentcomplexity isaresultof interactions in thefiatsystem,andcanbereducedtoanelegantsimplicityattheimplementationlevel.

    A key observation is that ledger contracts utilized for DEP and RTGSP are derivatives of SL3P. Figure 15expressesthestatement.

    For the above statement perhaps the challenge is to visualize how Dispensing and Accepting contracts arederivatives of theSL3P contract. Please refer toSection 7b and replaceCarolwithAliceAlice andBobwithBob. Inaddition, insteadof the ledgerdealingwitha singlecurrency,have themdealwithdifferentcurrencies.Transactionflowresultingfromthesesubstitutionsisacurrencyexchange.

    We can elect to stop referring the protocols by different names, although the author believes it is helpful todifferentiate.

    9.PathfindingLayer

    Atthepathfindinglayer,protocolsdescribedpreviouslyaretreatedasatomicoperationsof5types:

    a.Valuetransfersbetween2accountsononeledger.Executiontimeisassumedtobe~2seconds.b.Valueexchangesbetween2ledgerstrackingthesameordifferentassettypesthroughDEP.Executiontimecanbeassumedtobe~4seconds.c.Valuetransfersbetween2ledgers trackingthesamecurrencytypethroughSL3P.Executiontimecanbeassumedtobe~4seconds.d.Value transfers between 2 ledgers tracking the same currency type throughRTGSP. Execution timecanbeassumedtobe~6seconds.e.Valuetransfersbetween2ledgerstrackingthesamecurrencytypethroughDNSP.Executiontimecanbeassumedtobe~10seconds.

    Anyglobalpayment,remittance,assetpurchaseorexchangeoriginatingatonecryptographicledgerandendingatanothercanbebrokendownintoatomicoperationsofthe5typesmentionedabove.Thepathfindinglayeristaskedwithcalculatingtheoptimalsetofatomicoperationstobeexecutedforthedesiredvaluetransferorexchange.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    Small world networks such as social networks provide short connecting distances between any 2 nodes. Wesuppose, 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 atomicoperations.Amaximumtransfertimeof1minutegloballylooksacceptableatthisjuncture.

    Therawdataforthepathfindingalgorithmisoffollowingtypes:

    a.RealtimedatabaseofDEPoffersondifferentledgers.b.AsetofSL3Pchannelsoperatingbetweenledgers.c.AsetofgloballyrecognizedRTGSPnetworks.d.SetsofissuersthatparticipateinRTGSPnetworks.e.AsetofgloballyaccreditedDNSPnetworks.f.SetsofissuersthatparticipateinDNSPnetworks.g.Costfunctiondataformonetarycoststowardsexecutingatomicsteps.

    TheanalogueforthepathfindinglayerinthearchitectureoftheInternetareroutingprotocolssuchasRIP,OSPFand BGP. Communication routing through the internet requires routers and nodes to broadcast reachabilityinformationcontinuouslyandcanbevisualizedasaquasidistributedalgorithmacrossmultiplerouters/nodes.

    IntheInternetofMoney,centralizedserviceswherearoutingquerycanbesentandanoptimalpathreceivedlookfeasible. Data gathering and computation are outsourced to these services relieving the clients fromworkload.Considerationofexactalgorithmtocalculateoptimalpathsfromrawdataisleftforafuturearticle.

    Once optimal paths are received by the client, it proceeds to execute the atomic operations resulting in globalvaluetransferandexchange.

    Figure15isavisualrepresentationofpathfinding.AliceownsSwissFrancassetsontheUBSledgerandwantstopurchase Apple shares. She issues a routing query to pathfinding server. Pathfinding server has a database ofRTGSPnetworks,DNSPnetworksandcontractsondifferentledgers.Itevaluates3alternativepaths,indicatedinthefigure,thatAlicecouldtake.ItforwardstheoptimalpathtoAliceafteraccountingforpaymentandexchangefees.

    Alices client has protocol software to execute actions required for atomic operations. She does the same andachievesthedesiredassetpurchase.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    10.ContractLayer

    Thecontractlayerenablestheintersectionofvalueandarbitrarycoderunningtoaltervaluebalances.Thiswouldbe implemented through the construct of programmable oracles conceived by the Codius project and GavinAndresen.

    Fromthevantagepointofthecontractlayer,lowerlayersactasasingulargloballedger.Thisabstractledgercanholdbalancesandmoveanyassetsinunder1minute.

    FundsintendedforasmartcontractarechannelledintoanMofNmultisignatureaccountcontrolledbyasetofspecializedentities (programmableoracles) and thecontract code is simultaneously sent toallof theseentities.Everytimecontractingpartieswishtosendamessagetothecontract,theydirectthemessagetotheoracles.Theoracles run the code to compute participant balances. If code execution leads towithdrawal of funds from thecontracttosomeparticularaddress,thentheoraclescirculateatransactiontransferringthefundsandsignit.FundtransfersarehandledbythelowerlayersoftheInternetofMoney.Figure17visualizesthecontractlayer.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    Section12dealswithquantifyingdifferencesbetweenledgercontractingandthecontractlayer.Ingeneral,ledgercontractingisusedtobuildPaymentandExchangeprotocols.OthersmartcontractusecasesareimplementedattheContractLayer.

    Asanexample,anapplicationisaLondonbrentcrudeoilfuturescontractbetweenAliceandBob.ThecontractisrepresentedbycomputercodeexecutedbytheoraclestheseentitiesfetchexternaldatatocomputenewbalancesforAliceandBobat settlement time.After codeexecution,balancesarecreditedback toAliceandBobusinglowerlayersoftheInternetofMoney.

    A second example is sophisticated buyer and seller intermediation of the type sketched in Figure 4.Alice, thebuyer,andBob,theseller,wouldlikepaymentamounttodependontimetakenforsuccessfuldelivery.Bobneedstobepenalizedforlongerdeliverytimes.AcontractiscreatedandAliceloadsfunds.ContractingserviceverifiesproofofgoodsdeliveryandpaysBobaccordingly.

    A third example is an auction fordigital assets.Contracts canbe structured to carryout rules for an auction ifownershipofdigitalassetortitlearehandedovertotheprogrammableoracles.

    11.ApplicationLayer

    Parallel to the TCPIP protocol suite, this layer houses applications and user interfaces for consumers. Inparticular,thefollowingappearcommerciallysignificant:

    Debitandcreditbasedpaymentnetworks

    Although the Internet of Money is foreseen to deliver an order of magnitude improvement in speed of valuetransferglobally,someusecasesrequirepaymentnetworkslikeVisaandMastercard.Suchcasesare:

    a.Situationswheretransferconfirmationneedstobeinstantaneouslikeinstorepurchases.b.The requirement formultipleatomic transferandexchangeoperationsnecessitatesprivatekeys tobeusedmultipletimes.Adedicatedpaymentnetworkcoulddeliveradditionalsecurity.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    c.Paymentnetworkscouldfacilitatearbitrationbetweenbuyersandsellers.

    Itisfeasibletoreducesettlementriskbornebypaymentnetworksasaresultoffastpaymentandexchangetimesfacilitatedbythistechnology.Visasestimatedsettlementexposurestoodat$53.8billiononSeptember30,2013.

    Finally,thecontractlayerenablesnewmethodsofarbitrationlikedoubledepositescrow.

    Futures,options,derivatives,predictionandothermarkets

    Onekeydesignprinciplebehindthisarticleistheprincipleofunbundling:EachfunctionfortheInternetofMoneyisoperatedbydistinctspecializedentities.Forexample,consensuspoolsspecializeinledgermaintenance,banksin asset issuance and regulations, pathfinding services in pathfinding, and other firms in contracting andapplications.

    Thecontractandapplicationlayersenablecompetitivemarketsfordevelopmentoffutures,options,derivativeandpredictionmarkets.Differentservicescanspecializeinslicesofthesemarkets.

    GamesofHazardassmartcontracts

    Asademonstration,thegameofRoulettecanbevisualizedasacontractwiththefollowinglogic:

    a.SpinningoftheRoulettewheelisemulatedbyasourceofentropy.b.Alterationofplayerbalancesisrepresentedbycodewiththegeneratedentropyasinput.c.ValuetransfersandexchangesoccurthroughlowerlayersoftheInternetofMoney.

    Westate,withoutproof,thatallgamesofhazardincludingpoker,blackjackareimplementableassmartcontracts.

    DecentralizedApplications

    TheabstractledgerisastrongfoundationtobuildDecentralizedApplications.Currentapproacheshavereliedoncreating new tokens for accessing services such as decentralized storage, mesh networking and reputationsystems.TheInternetofmoneyprovidesanalternativetobuildtokenlessDApss.Asanexample,adesignoutlineforaharddiskspacesharingDAppisconsideredinAppendixC.

    12.RevisitingtheLedgerlayer

    This sectionwill consider some issues to develop a better understanding ofminimal requirements at the ledgerlayer(Section6):

    Whycantledgersbecontrolledbyissuers?

    PaymentandExchangeprotocolsarestructuredsuchthatentitiesdifferentfromtheissuerexecutetransactionsonaledger.AnexampleisRTGSP:Issuer1isroutingapaymenttoBobonledger2withoutinvolvementfromIssuer2.NowassumethataserverbelongingtoIssuer2istheonlynodeinconsensuspoolmaintainingledger2.

    Issue with the above is that Issuer 2 can possibly create a new ledger history, inconsistent with the previoushistory,claimingthatIssuer1nevercompletedthepaymenttoBob.IfoldhistorydataisunavailabletoAliceandIssuer1,theremaynotbeagoodwaytodisputethenewhistory.Thelegalcostofdisputingcouldbelargerthanexpectedreparations.

    Solutionposited is tohavemultiplepartiesmaintain ledgers throughadecentralizedconsensusprocess.Throughdecentralization,issuersandconsumerscanbeassuredofimpartialledgers.Hence:

    Decentralization serves to increase confidence in the impartiality of ledgers. The more diverse andnumerous thecompositionofnodes inconsensuspoolmaintaininga ledger, stronger is theguaranteeofimpartialness.

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    Tradeoff inherent with decentralization is efficiency. Nodes need to verify each others processing andcommunicate to arrive at consensus. This necessitates higher computation and bandwidth than an equivalentcentralizedledger.

    Decentralizationfordecentralizationssakeisnotastrategytobeadvocated.Thearticlesperspectiveis:

    Extentofdecentralizationrequiredforaparticularusecaseisanoptimizationproblem

    Factorsimpactingefficiency,definedastransactionsprocessedperNPVdollarofinvestmentinnodes,are:

    a.Choiceofconsensusprocess.b.Nodeidentityassumptions.Efficiencyimprovesdramaticallywhenidentityofnodesisknown.Bitcoinnodesareanonymousandnetworkincursahighcost,~$500millionperyear,toarriveatconsensus.c.Numberofnodes.Generallythelargeraconsensuspool,lowertheefficiency.

    Factorsaffectingconfidenceinimpartialityofledgers:

    a.Consensus pool composition. When a reputable firm like Google owns nodes in a pool, it boostsconfidence in the pool.Malicious act originating from aGoogleowned nodewill damage its hardwonmarketreputation.AtstakearerealgoodwillassetsofGooglewhicharguablytotaloverabilliondollars.b.ChoiceofConsensusprocess.Forinstance,PracticalByzantineFaultTolerancecantolerateupto33%maliciousnodesinapool.c.Number of different entities controlling nodes in a consensus pool. Higher the number, more theconfidence.

    Amountofconfidencerequiredforaledgerdependsonthevalueatrisk.Thestrategyadvocatedisto:

    Aimforanoptimalbalancebetweenvalueatrisk,efficiencyandconfidenceinledgers.

    For instance, a small homogenous poolmay be suitable for tracking loyalty points scheme of a 2store grocerychain.Citibanksledgerwillbenefitfromahighdegreeofconfidence/decentralization.

    Theoptimalledgerlayerprotocol

    Because each use case has a different optima for pool composition, number of nodes etc., the ledger layerprotocolneeds tobeextremelyflexible.Thereshouldnotberestrictionsonusage,opennessanddevelopmentoftheprotocol.Consensusprocessshoulddeliverbestfeasibleefficiencyinalargecrosssectionofscenarios.

    The Hyperledger project is a pioneer in this direction. Hopefully, other projects with similar objectives willfollow.

    Whyshouldledgersbepublic?

    Allpaymentandexchangeprotocolsdescribedhereindependonledgersbeingpublic.Counterpartiescannotviewoffersorverifypaymentsonprivateledgers.

    If applications posited are valuable, counterbalancing privacy enhancing technologies need to be developed. Inparallel,Governmentsneedamethodtomonitorfinancialtransactions.InvestmentsintheInternetofMoneycanbe viewed as bets that the cost of ensuring financial privacywill not exceed consumer benefits accruing fromapplicationssuchasdecentralizedexchange.

    Provided the privacy aspect can be resolved, the author is excited about potential advancements to theories ofeconomicsandcrisesmanagementresultingfromopenaccesstotransactiondataglobally.

    Onmultisignatureaccounts

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    Inadditiontotheconsumersecurityenhancingbenefitsofmultisignatureaccounts,recallthatthecontractlayerrequires the same to assure trustworthy execution. Smart contracts should ideally be verified and executed bymultiple distinct programmable oracles.A pool of oracles needs to own jointmultisignature accounts for dailyoperation.

    Ontimealignmentmechanismforaconsensuspool

    Atimealignmentmechanismprovidesamethodforpoolnodestoconsistentlyagreeonthesameclocktimewithan acceptable skew tolerance (up to 1 sec is admissible). Good design emanates from the desire to createpowerfulsystemswithminimalcomponents.ThispaperhasutilizedtimebasedtransactionsforDNSPandMTXP(AppendixA).Methodstodoawaywithbuildingatimealignmentmechanismwhileretainingfunctionalityneedtobediscovered.

    13.Reducingriskandcomplexityatseedstage

    14.Observationsandopenproblems

    Thefundamentaladvantageofcryptographicledgers

    This paper posits that cryptographic protocols built utilizing cryptographic ledgers enable the formation of lowtrustfinancialrelationshipsbetweenparticipatingissuersandconsumers.Lowtrustrelationshipsservetoreducetransactionalandexchangecosts,whichcanbepasseddowntoconsumersasanetsaving.

    ScalabilityAnalysis

    Implementationofpullbasedpayments

    Theuseofdigital signatures leadall cryptographic ledger systems tobepushbased.Current implementationofACHenablespullbasedACHdebits,andithasmultipleapplicationslikeinsurancepayments,loaninstallments,utilitypaymentsetc.

    Amechanismtoenablesuchapplicationscanbebuiltatthecontract/applicationlayers.ConsiderthesituationofAlice, a customer toBob, a utility company.Alice andBob create a smart contract hosted bymutually trustedoraclesandAliceloadsthecontractwithfundsintendedformonthlyutilitypayments.ThecontractcontainsruleslettingBobwithdrawuptoacertainamounteverymonth.

    ImplementationofanIdentityandAnonymitylayer

    Compliance with regulations creates a problem of duality: Identities behind public keys must be accessible tocertain organizations (issuers for example) yet should resist unmasking methods such as taint analysis. Aconsistentmethodofverifyingissuersandledgersisalsoaprerequisite.

    15.References

    1.https://bitcoin.org/bitcoin.pdf2.https://en.bitcoin.it/wiki/Script3.Pages2028,TheTCPIPProtocolSuite,4thEdition,BehrouzA.Forouzan4.http://hyperledger.com/5.https://www.regaltek.com/docs/understandingachnetwork.pdf6.https://github.com/TierNolan/bips/blob/bip4x/bipatom.mediawiki7.https://github.com/petertodd/bips/blob/checklocktimeverify/bipchecklocktimeverify.mediawiki8. http://gendal.wordpress.com/2014/01/05/asimpleexplanationofhowsharesmovearoundthesecuritiessettlementsystem/

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    9.Pages323374,TheTCPIPProtocolSuite,4thEdition,BehrouzA.Forouzan10. https://github.com/codius/codius/wiki/SmartOracles:ASimple,PowerfulApproachtoSmartContracts11.http://gavintech.blogspot.ch/2014/06/bitthereum.html12.http://www.sec.gov/Archives/edgar/data/1403161/000140316113000011/R19.htm13.http://bithalo.org/wpcontent/uploads/2014/06/whitepaper_twosided.pdf14.https://www.ethereum.org/pdfs/EthereumWhitePaper.pdf

    16.Authorshipandacknowledgements

    TheauthorMeherRoycanbereachedat:

    Email1:[email protected]:[email protected]:https://www.linkedin.com/pub/meherroy/43/969/254Twitter:https://twitter.com/MeherRoy

    Special thanks to Tim Makarios for pointing out errors, and suggestions regarding Responsible TraversalTransactionProtocol.

    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)

  • 11/26/2014 AnarchitecturefortheInternetofMoneyv0.2.9

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

    PublishedbyGoogleDrive ReportAbuse Updatedautomaticallyevery5minutes