zoukankan      html  css  js  c++  java
  • 论社会信任网络中货币的债权属性和关于去中心化货币网络协议的建议

    I. 论社会信任网络中货币的债权属性

    货币的债权属性

    我可以用借据来支付,不过有下面三个限制条件:

    1. 只有信任我的朋友才会接受我的借据,陌生人不会。
    2. 我的朋友每人只会接受一定金额的借据,这取决于他们各自对我的信任程度(由他们各自愿意借给我的金额来衡量)。
    3. 如果我的朋友接受了我的借据,只能在我那帮值得信赖的朋友之间当作货币使用。

    上述都是很严格的限制条件。不过设想一下:

    • 各国纸币从本质上来说都是由各国政府开具的借据,可以用来交税。
    • 每个人都会近乎无限量地接受政府借据,如果我们把政府看作一个人的话,这就意味着我们对他的信任度很高,因为我们愿意无限量地借款给他。
    • 银行账户就是银行开具的借据,承诺会用一定金额的政府借据即时偿付。
    • 银行贷款就是根据银行接受的贷款协议用个人借据有偿交换银行借据。贷款是创造银行借据的机制。
    • 我们需要银行借据和政府借据,用以支付给交易对象,因为我们不相信彼此的借据。
    • 因为得到了公众的普遍信任,政府借据和银行借据具备了价值。

    因此,如果我想付款给你,我会给你政府借据(现金)或银行借据(支票)而非自己的借据。银行借据远远超过了货币供应量的 90% 以上,是银行通过为某人的个人借据提供担保(即提供贷款)而凭空创造出来的。

    可信中介:银行和政府

    一种理解方式是,就现金付款而言,银行或政府起到了可信中介的作用。我用自己的借据交换银行借据,再用银行借据付款给你。详情见下方图解,其中箭头代表了借贷关系。

    首先,我以 5% 的单利从银行贷款 100 美元,这意味着我欠银行 105 美元。(我的银行账户里或许有余款可以付给你,但是由于 90% 的钱都在流通,不得不先创造出这笔钱。)

    接下来,我已经将 100 美元的银行借据付给了你。要注意的是我们之前已经两清了,欠你钱的就成了银行。这对银行来说没什么,因为我欠了它同等金额(外加 5% 的单利),而它也已经决定要相信我的借据,因为我的信用评级良好或是提供了抵押物。

    另一种可信中介

    找到一个除银行之外信任我,又得到你的信任还不收中介费的人岂不是更好?或许我们聊一聊,会发现彼此都是 Sally 的朋友,她就可以充当我们之间交易的可信中介。

    我给了 Sally 一张 100 美元的借据来交换她的借据,然后把她的借据支付给你。问题在于 Sally 的借据不如银行借据值钱,因为你只能将它付给相信 Sally 或者欠她钱的人,比如我。

    然而,如果我的借据可以通过一个可信中介支付给陌生人,那么 Sally 的借据也可以。假设你需要付给 Bob 50 美元,你又发现 Bob 认识且信任我,你就可以从 Sally 的借据中拨出 50 美元给 Bob,Bob 可以用这笔钱交换我的借据,这样我欠 Sally 的债务中有 50 美元就结清了:

    要注意的是我依然负债 100 美元,Sally 也是,箭头之所以发生了变化是因为你用自己一半的债权支付给了 Bob, 而 Bob 得到了 50 美元的债权。

    只要你能找到一条连接你和收款方的可信中介链,且这些中介之间的债务额不低于你的付款金额的话,你就可以通过上述方式向任何人付款。

    一般而言,如果人人的债务额相等,A 就可以通过 B、C、D 这些可信中介向 E 支付 10 美元。

    依照上图所示,人们无需接受自己不信任的人的借据。问题在于如何为每笔交易找到一条可信中介链。

    II. 关于去中心化货币网络协议的建议

    为了促进经由非银行和非政府中介实现的去中心化支付,我们需要维持一个通过提供借贷联系各方的社交网络。计算机会通过该网络找出可用借据付款的路径。

    要解释如何在该网络中通过借据付款,需要回答下列问题,我给出了一些初步解答。

    问题

    1.该社交网络应该依靠单台服务器维护,还是分布在多台服务器上?

    将一个分散支付中介的系统存储在所有想要参与该系统的服务器上是有意义的。因此需要制定服务器之间的交流协议。单台服务器可以存储任意数量的账户——很可能只有一个。

    2.该社交网络应该流通一种还是多种货币?

    对于多个相互之间存在借贷关系的网络来说,涉及债务额不同的网络按理来说是可以在相同的服务器上同时运行的。但是,只有找到一条涉及等量债务额的贷款路径才能进行支付。将一定面额的借据转化为另一个面额这样的货币交换也是可能的。

    3.是否应该将一个账户(社交网络中的节点)存储在单台服务器上并且只允许这台服务器访问?或者能否将一个账户作为一个更模糊的实体存储在计算机网络中的多台服务器上,并且允许任意一台服务器访问?或者将上述两种方式合二为一?

    出于隐私性和安全性的考虑,一个账户只能存储在一台服务器上,即“主”服务器。不管怎样,全网都可以访问这台服务器。任意一台服务器都可以在内部实行数据冗余方案。

    4.如果账户只存储在单台服务器上,这些服务器应该分享关于其内部节点的连接信息吗?或者它们之间能否盲目进行交流与协作?

    为了保护隐私,服务器之间应该分享尽可能少的账户信息。服务器也许只需要分享它们管理的账户的节点 ID 就能相互操作。

    5.如果账户重复地分布在计算机网络中,如何保持数据一致性?

    6.服务器需要如何通过协作在社交网络中找到支付路径?

    两台服务器上都会存储关于账户节点之间联系的完整信息,包括可获得的贷款额。如果不同服务器上的节点之间要进行付款,每台服务器必须找到一条或多条路径,可从付款来源/收款方处获得足够贷款支付给另一台服务器,之后再协调这些路径的匹配过程。

    如果服务器上互无联系的账户之间要进行付款, 必须通过一个或多个中介服务器。

    7.安全性如何?

    公钥加密可用于安全通信,数字签名可用于验证。支付协议必须经过缜密设计以防滥用,尤其是防止被中介服务器滥用。为了杜绝滥用,应该公开这样一个事实:一切借贷行为只能在相互信任的私人团体内进行。

    8.私密性如何?

    假设只在你使用或相信的服务器之间建立社交网络联系,任何向你付款的人都可以知道你的账户存储在哪台服务器上。服务器可能只允许通过社交网络上的节点 ID 识别匿名账户,也可能是通过昵称标识符,很像是 之类的邮件地址。

    9.应该允许服务器收取服务费吗?

    为什么不呢?但是,如果有可能的话,为了防止一台或两台服务器不与其它服务器协作提供支付中介,反而试图垄断所有账户的行为,应该从协议设计上加以避免。如果有服务器要将其它服务器上的节点作为收款方或是付款中介,后者可能会决定向前者收费(后者可指定任意货币),成本会转移到用户头上。然而,收费制应该不会成功,就像电子邮件供应商尝试针对其它向其用户发送电子邮件的服务器那样。

    10.如果每个账户仅存储在一台服务器上,应该允许账户转移吗?

    该协议应该包括可扩展标志语言或是其它账户数据标准,这样很容易就能将账户从一台服务器转移到另一台上了。

    11.贷方如何接受这类付款?

    贷方可能会授信给人脉广泛的中介,中介可能会像银行那样收取服务费,客户必须从这个中介的关系网中找到一条支付路径。一家企业也可以向其所有人提供无限额的贷款,这些所有人会成为主要的支付中介。

    可以使用智能卡等技术,或是改进面对面支付的新技术。

    12.从另一个账户获得贷款的规则是什么?

    没有规则。两个用户之间可能达成任何一种贷款协议,包括收取利息、需要抵押物或是用法币还款。他们之间的贷款协议可以是书面的、口头的或是默示的。该协议至少要写明票据面额。通常还会在最后注明贷款额度。货币协议可能包含对标准基础贷款协议的要求(贷款面额和额度)和对不同服务器上的节点之间的自定义贷款协议的要求。

    服务器无疑会提供能够在各节点之间达成各种贷款协议的客户端软件。服务器虽然能够限制软件可达成的协议类型,但是它们很难,甚至是无法限制两个用户之间可能达成的协议。然而,在软件内达成某几类协议会让系统变得更加灵活友好。

    一类可能有用的贷款协议是由人脉广泛的节点按比例收取一定的中介费,类似银行利息。如果支付协议发现了这类贷款协议,额外的收费可以自动返还给原付款人。付款人有需要的话可以指示网络避免中介费,但是可能会降低交易速度。

    服务器为了加快交易速度,可能会选择包含收费中介的支付路径。如果服务器 A 彻底拒绝无偿交易,其它服务器可能会拒绝来自 A 的交易,导致 A 的收费中介效用降低,导致这些中介被迫更换服务器。更糟糕的是,一些服务器彻底拒绝付费交易,并创造出了两种面额相等的独立货币,一种允许付费交易,另一种只接受无偿交易。

    在任何情况下,贷款协议应该有足够的灵活性,允许每个用户和服务器能独立决定是否收取利息和费用之类的原则性问题。结果如何,没人能预测。

    13.交易速度会变得足够快吗?

    很有可能。允许人脉广泛的中介收费可能有助于加快那些愿意付费的用户的交易速度,同时也有可能允许那些愿意延长交易时间的用户进行无偿交易。


    链接: http://archive.ripple-project.org/decentralizedcurrency.pdf

  • 相关阅读:
    eclipse rcp 获取工程项目路径
    Eclipse RCP中添加第三方jar包的办法
    eclipse content assist 代码提示功能失效解决办法
    lwuit更改字体大小
    lwuit调整滚动条灵敏度值
    AWTEvent
    IE7 IE6去掉关闭提示框的解决方案
    jQuery多库共存最优解决方案
    电子商务网站 数据库产品表设计方案
    javascript操作cookie
  • 原文地址:https://www.cnblogs.com/hzcya1995/p/13312928.html
Copyright © 2011-2022 走看看