Vena Network

洛书协议——资产融通代币化的开放协议

摘要

  我们描述了一种基于区块链的开放性协议,协议用户可在其高度通用性的架构中通过编写条款合约定义一系列去中心化的有关资产的发行,借贷与交易等金融活动规则集并保留著作权,由此可衍生出洛书生态的合约模板交易市场。洛书协议保证了可在底层接口实现自由定义的同时,提供了债务类(债务融资、信贷、抵押贷)及交易类等合约标准库,旨在帮助用户快速,便捷,安全地构建交互式的金融类DApp(去中心化应用程序)。协议本身是一套设计与描述规范,可兼容部署于任何支持智能合约平台的区块链网络,并通过跨链技术破局数据的“孤岛困境”,进而全面繁荣协议生态。洛书在设计之初,充分吸收了市场竞争,资源组合与分配的思想,如网络中不同角色的费用补偿和NFT(非同质化代币)资产组合的增值抵押等,都为构建于该协议之上的借贷与交易活动增强了可操作性。同时,法币与数字货币兑换通道的建立,催生了一个用于仲裁链下交易纠纷的分散式陪审员网络,并以具备效用的协议代币VENA作为经济激励来保证网络的公正性。洛书协议本身不收取任何费用且保证了不偏袒任何一方协议参与者,一个去中心化自治组织(DAO)将负责管理协议的升级并确保协议的安全性和兼容性,而ENS到合约地址的映射将使得对协议合约的访问和升级变得更加友好。最后,我们相信洛书协议会成为构建一个全球性的数字资产融通网络的开放标准和基石。

1. Vena Network简介

1.1. 背景介绍

  数字经济正在快速增长。2012年,波士顿咨询集团评估仅G20国家数字经济的潜力为4.2万亿美元。此外,2015年牛津大学经济学系与埃森哲的联合研究得出结论,到2020年,数字经济将为全球国内生产总值贡献1.36万亿美元。数字经济的快速增长增加了对在线支付的需求,而加密货币正在成为日益流行的满足数字经济要求的支付解决方案。
  区块链代表着由去中心化、不可篡改、无需信任等一系列特性所构建的价值传输网络。区块链技术能够在网络中建立点对点之间的可靠信任,使得价值传递过程脱离对中介的依赖,既公开信息又保护隐私,既共同决策又保护个体权益,这种机制提高了价值交互的效率并降低了交易成本。
  今天,世界上已经有数千种加密货币,任何人都可以安全地持有加密货币。但是,在世界的很多地方,加密货币与法币之间的交易依然困难并且成本高昂,这阻碍了加密货币的普及并扭曲了交易价格。目前,加密货币与法币的交易主要通过中心化的OTC交易平台进行。大多数国家缺乏加密货币立法,这意味着此类交易平台不需要获得许可证,也不受监管。因此,用户在此类平台进行交易往往承受了较高的资金安全与隐私泄露风险,与此同时,交易平台有可能操纵交易价格以获取超额利润。
  在Poloniex, Bitfinex等中心化的加密货币交易所,USDT被当作USD的数字替代品进行交易。然而,USDT作为由Tether公司发行的一种中心化的锚定美元的数字货币,长期以来存在诸多严重问题,主要包括:

  1. Tether公司可能破产
  2. Tether公司开设账户的银行可能破产
  3. 银行可能冻结Tether公司的资金
  4. Tether公司可能超发USDT
  5. 手续费贵,到账速度慢,提现困难
  6. Tether公司曾爆出账户被盗的安全问题

  显而易见的是,如果用户能够安全方便地进行加密货币和法币之间的交易,对USDT类的法币的数字替代品的需求将会显著下降。
  加密货币领域另一个显著的问题是没有一个去中心化的服务可以让加密货币持有者安全地通过抵押加密货币借入法币,而这已经成为一个显著的需求,特别是对于持有大量加密货币并对加密货币价格看涨的用户。而全球的法币投资者也在寻找低风险,高收益的投资渠道,他们向来非常青睐有抵押的借贷市场。中心化的抵押贷款服务商经常利用自己的垄断优势获取超额利润,也更容易受到来自市场价格波动,经营管理不善,内部人员贪腐,监管政策变化等因素的影响。此外,对于隐私泄露风险的忧虑也将促使用户向去中心化的服务转移。
  我们再把目光聚焦至ICO(首次代币发行),以太坊区块链在ERC20代币标准之下以无需许可和可互操作的方式构建了多样化的加密货币二级市场生态体系,加密货币在二级市场的高流动性吸引了无数投资者的涌入,从而引爆了ICO狂潮,这实际上是对传统股权融资现状的改善。然而,债务融资与传统股权融资有着相似的痛点,在公开发行或私人投资者中进行债务融资,就像执行股权融资一样,是定制而低效的,也就说明债务市场仍然是不透明且专有的。
  在Vena Network,我们相信资产交易应该直接在有关各方之间进行,而不需要使用中介,人们应该可以自由地管理自己的资产,而不受第三方的干扰。而债务资产可映射成通用的代币后公开发行,任何投资者都能参与其中,让因垄断而形成的专有市场走向公众市场,从流动性和透明度的角度来看,这将会是一种超越现状的逐步改善。洛书协议实现了代币化的资产发行及所发行的代币与其他各类资产闭环流通的想法,通过洛书协议机构可进行债务融资,个人可进行小额贷款(信贷,抵押贷等),同时可在无需信任第三方的情况下进行NFT代表的质押权转移及其他各类资产之间兑换,如加密货币和法币的交易等。Vena Network白皮书详细描述了该协议的技术细节,以及我们的后续开发计划。

1.2. 什么是 Vena Network

  Vena Network项目的目标是通过洛书协议创建一个去中心化的数字资产融通网络。洛书协议分为两层:1)基础协议层,主要是对上层的金融类业务抽象后的注册、配置、路由、管理等。2)资产协议层,以资产为本位,通过实现条款合约接口来完成用户自定义的金融业务。例如,可编写抵押条款合约和还款条款合约实现抵押贷;继承ERC721标准实现资产组合的增值抵押;建立个人信用合约模型并注入链上链下数据来实现公开透明化的信贷等。在洛书生态中,我们通过区块链实现了从代币化的资产发行到资产点对点的借贷或交易的流通闭环,即数字资产发行之后可直接通过洛书协议进行点对点交易,也可在抵押数字资产之后进行抵押转移和质押物(仅支持稳定加密货币)流通。所有的操作有由智能合约代码控制,无法人为干预,从而防止了欺诈行为。加入Vena Network的用户可以从加密货币市场的发展中受益,以低成本、安全、高效的方式实现资产融通,同时还能缓解由加密货币价格波动,不诚实的金融中介等因素带来的风险。
  Vena Network项目的关键要素是洛书节点。洛书协议预设置了两种角色担保人和中继者,洛书节点的构成可以是其中单一角色,也可是两者的叠加,亦可是从洛书市场竞争中催生的各类服务商的整合。在预定义角色中,担保人在债务发行的业务场景中是可信发起人和债务人违约风险的评估人,而中继者是以无需信任第三方的方式促进洛书网络中的所有债务订单和交易订单能够快速成交。它们都可以根据历史资产表现进行实证评估,因此,市场有清晰的信号来评估任何特定担保人或中继者所维护的有关于用户的债务违约风险指数,交易纠纷率等信用指标。洛书协议使用一种我们称之为“链下订单中继链上结算”的混合技术实现了债务发行与资产交易在效率与安全上的平衡。在这种方法中,带加密签名的债务订单和交易订单都是通过链下通道发送的,感兴趣的对手方可以将一个或多个订单注入到相应的智能合约中,然后按照合约既定的逻辑自动完成。洛书协议显著降低了做市商的交易摩擦成本,因为交易意图可以通过链下发送,而链上交易只有在价值转移时才会发生。我们通过开放洛书节点申请、提供模板合约交易市场服务及将洛书协议设计为应用程序无关等多种方式来扩展Vena Network。
  Vena Network为洛书节点和用户提供了显著的优势。洛书协议利用洛书生态中多种角色在不同的市场竞争中的费用补偿等经济激励方式为用户提供准确的市场数据,真实的信用数据,以及公平,透明,安全和场景丰富的数字资产发行,借贷,交易和管理服务。每个洛书节点代表一个独立的商业机构,并将从其提供的各种金融服务中获得收入。我们的使命是促进加密货币社区的健康发展。

1.3. Vena Network的主要特点

  • 使用代币经济模型构建分布式商业网络。
  • 用户必须通过去中心化的身份认证才能进行信贷及与法币相关的交易与借贷。
  • 层次分明的协议设计。基础协议层高度抽象来提高二次开发的自由度,用更多的创新场景带入更多的生态角色;资产协议层内生支持债务类(债务融资、信贷、抵押贷)和交易类等合约标准库,并以此为业务先导来构建资产融通生态。
  • 实现了数字资产从发行到二级市场交易的流通闭环,可直接在洛书协议生态内完成现货交易,抵押转移和质押物(仅支持稳定加密货币)的流通等。
  • 支持NFT(非同质化代币)标准,可通过自定义条款合约实现资产组合的增值抵押。
  • 第三方在资产协议层实现的模板合约库将保留著作权,由此建立模板合约交易与服务市场,作者可向用户收取服务费。
  • 协议生态中的角色在不同的市场竞争中都有费用补偿,如担保人可利用自己特有的数据模型向用户提供优质的信用评估服务来实现盈利。
  • 支持ETH,ERC20,BTC,EOS,BCH,未来计划支持更多种加密货币。
  • 建立了加密货币与法币的兑换通道,即支持加密货币与法币的交易和借贷等。
  • 通过带时间锁定的智能合约(Timelock Contract)解决交易对手恶意退出风险。
  • 仅支持不可逆转的法币转账方式,以最大限度的降低退款风险(参见https://en.bitcoin.it/wiki/Payment_methods)。
  • 分散的陪审员网络作为加密货币与法币交易时的主要保护机制。
  • 涉及与法币的兑换时,限制交易金额(50ETH)以降低整体风险敞口。
  • 智能合约持有所有交易详情,并由交易双方签名,如有争议,将用作证据。
  • 通过不同链上的时钟(如以太坊的ethereum-alarm-clock)定时调用价格预言机合约,从可信预言机集合(trusted-oracles-set)获取抵押代币实时价格。
  • 通过强制清算机制解决抵押物价格下跌的风险。
  • 通过协议代币增发机制解决抵押物价格快速跌破债务金额(来不及强制清算)的风险。
  • 使用Aragon软件进行去中心化治理。
  • 使用Zeppelin_OS安全地构建和管理智能合约。
  • 使用开源许可证(AGPL)发布源代码。

1.4. Vena Network的商业模式

  Vena Network不是一家公司,而是一个旨在填补加密货币生态系统缺口的开源项目。洛书基金会是由洛书团队在新加坡成立的非盈利机构。设立洛书基金会的目的是保证洛书协议项目的可持续性,去中心化治理的有效性,募集资金的安全性和透明性,以及协助创业公司在洛书协议上进行开发与商业创新。
  洛书基金会建立了完善的激励机制来推动Vena Network的健康发展,主要包括:

  • 扮演担保人或中继者角色的洛书节点需要通过审核并向洛书基金会抵押一定数量的VENA Token作为保证金,节点可以通过收取手续费获利。
  • 陪审员节点需要通过审核并向洛书基金会抵押一定数量的VENA Token。Token作为保证金。每次仲裁结束,裁决结果合理的陪审员会获得代币奖励,裁决结果不合理的陪审员会遭受代币损失(详见5.2.3)。
  • 用户使用VENA Token支付各类订单的手续费可以享受50%折扣优惠。
  • 用户使用VENA Token抵押或质押时,可获得更高的抵押率和更低的清算线。
  • 在跨链资产转移时,中继节点交叉同步区块头数据将获得VENA Token奖励,被选举进入“象限层”的陪审团做智能合约计算验证的矿工也可获得VENA Token奖励。
  • VENA Token持有者可以参与洛书协议治理,对协议开发者提出的协议改进提案进行投票。



2. 场景分析与洛书协议在应用场景中的优势

  基于洛书协议可以构建丰富的金融场景,主要且常见的有债务融资,信贷,抵押贷,OTC交易等,除了可以直接在基础协议层二次开发完成场景创新之外,我们同样也在所述场景的标准合约库中给用户提供了极高的自由度。由于洛书官方主要提供债务类和交易类合约标准库,因此在本节我们将针对此类场景的现有方案所存在的问题做简要分析。

2.1. 线下交易

  交易双方通过Facebook,Telegram,微信,QQ等软件约定交易数量,交易价格,交易时间地点,交易没有第三方参与。这种方法一般适用于同城交易,且具有较高的资金安全风险,甚至存在人身安全风险。由于加密货币的匿名性,一旦一方违约,另一方的权益很难得到保障,事后取证和举证更是困难重重。除了个别国家以发放牌照的方式将加密货币交易纳入监管框架,多数国家和地区的加密货币交易都没有法律保护,这也提高了交易者遭遇欺诈风险的概率。

2.2. 中心化的OTC交易所

  Localbitcoins,otcbtc,huobi等OTC交易平台向用户提供C2C模式的加密货币/法币交易服务。这是一种类似于Ebay和Taobao的担保交易模式。加密货币出售方在平台上发布出售广告,并将相应数量的加密货币转入交易平台提供的地址。购买方填写并提交购买订单后,需要将法币转入出售方指定的账户。待出售方确认法币到账以后,交易平台将加密货币转入购买方地址。如果交易过程中出现纠纷,由交易平台进行仲裁。
  这种交易方式依赖于对中心化交易平台的信任,而这种模型的脆弱性已经被反复证明(Mt.Gox,CoinCheck,Bithumb等知名交易所均曾被黑客入侵)。具体而言,中心化交易平台对用户存在如下风险:

  1. 交易平台破产。
  2. 交易平台挪用用户资金。
  3. 交易平台遭受黑客攻击。
  4. 合规/监管风险。
  5. 交易平台操纵价格。
  6. 交易平台垄断市场,收取高额手续费。

2.3. 中心化的抵押贷款机构

  中心化的抵押贷款机构通常只能服务于特定的地区和人群。在银行等传统机构办理抵押贷款通常流程繁琐,成本高昂,并且充满了不公平和不透明的条款。目前,世界上绝大部分贷款机构还不能接受加密货币作为抵押物。我们希望加密货币持有者能从世界的任何地方获得贷款,而不依赖于当地的银行和抵押贷款机构。
  今天,不平等影响了全球抵押贷款市场,贷款市场受政府货币政策控制,不同的风险水平和法币通胀率造成了国家和地区之间的利率差异。例如,巴西的房地产抵押贷款可能会有32%的年利率(通胀调整),而欧洲的类似贷款可能会有0.5%~5%的年利率。另一方面,通过设置准入门槛和对资金,征信数据,市场渠道等资源的垄断,银行和抵押贷款机构通常在存款人和借款人之间收取高额的利差(中国的信用卡年化利率在20%左右,而同期一年定期存款的利率仅为1.75%)。当区块链技术和抵押贷款市场结合时,真正的革命可能发生。借助Vena Network,抵押贷款市场将对所有贷款人和借款人开放,贷款将不受国界,司法管辖区和银行系统的限制。法币持有者可以安全地向任何人贷款,并获得他们满意的利率。加密货币持有者可以在世界的任何地方方便地获得贷款,并且只需承担低于银行等传统金融机构给出的利率。由于加密货币不受某个国家或地区货币政策的控制,当越来越多的人开始使用Vena Network,越来越多的流动性被注入市场。由于竞争更加激烈,在中国或者欧洲或者非洲,抵押贷款市场都具有相同的流动性,国家和地区之间的利率差异将会消失。

2.4. 信贷

  传统的信用贷款具有和抵押借贷相似的局限性,如贷款流程繁琐,成本高昂,充斥着不公平和不透明的条款等。然而,信贷较为突出的问题是在风险控制,如信用评估的真实性和借款人的个人隐私保护等。在当下的信贷市场中,尽管各个信贷机构能够有丰富的数据源获取用户的信用数据并且也通过大数据,人工智能等技术手段建立了成熟的信用评估模型,但依然会存在以下问题:

  1. 财务数据的不完整性。
  2. 数据源恶意造假和篡改数据。
  3. 借款人的隐私泄漏。
  4. 数据孤岛和地域限制导致无法跨境信贷。
  5. 中小机构因运营成本过高(早期软硬件条件不完善,运营商因权利不对等无法获取数据授权等多种因素)被市场出局,最后形成垄断市场。

如果信用贷平台或机构成为洛书节点,将极大地降低了开发,安全,运营的成本并且对于整合贷款人的非财务信息进行信用评估的能力不足的机构可通过洛书协议直接获取贷款人在区块链中真实完整的历史资产表现来完成违约风险评估。对终端用户而言,在Vena Network中借贷需要进行去中心化的身份认证,而洛书协议设计的DID文档能够最大限度地保护用户隐私。此外,由区块链本身全球性网络的特性所决定的,用户可以突破国家与地域限制来信用贷款,洛书节点不需要费尽心思跨越各类网关去用户常住地获取财务信息就能提供数据支撑,这对用户在境外的事务性处理和应急处理等将有着深远的影响。

2.5. 债务融资

  投资者投后退出难,锁定期过长,是创投市场僵化、创新企业直接融资难、融资贵的根源,也是股权众筹的第一大痛点,而ICO的出现让比特币、以太坊成为了“新生数字资产、区块链技术”的融资工具,并且融资效率极其高效,普惠性直接网络化参与,积少成多,扭转了传统金融融资效率低、时间长,并且只面向少数有资产、高净值的机构客户的局面。然而,在传统金融体系中,债务资产是比股票在数额上更大的资产类别,可是其市场也在日益僵化,受众范围、投资者便利性,市场透明性也都常常被人诟病。显然,如果将债务资产代币化就有可能极大的改善债务市场的现状。并且,债务资产代币化后会需要有相应的二级市场出现,而投资者也需要一种标准化的定价机制来计算债务资产的价格。我们知道,股票映射的代币价值是与品牌协议、项目质量或底层实体绑定在一起的,而债务资产映射的代币则在价值上通常是与匿名的对手方的历史财务活动相关联。因此,洛书协议在债务类合约标准库中提供涵盖债务资产的强制性语义支持,让债务资产的发行,管理,流通可以解除对单一中心数据的依赖,真实地改善整个庞大的债务市场。

2.6. 洛书协议的生态优势

  我们瞄准了区块链领域的协议层来构建生态,其吸引力和优势在于,它在协议的垂直领域不试图迎合所有该垂直领域的所有市场及市场细节,而是激励生态中的不同角色个体去寻找和服务多个市场,通过提供基础设施给予这些个体帮助,从而创造巨大价值,这是在很多行业中可观察到的趋势。因此我们以分层的设计思路抽象了金融系统运行的底层规则,并在洛书官方团队以债务类和交易类场景作为业务先导的策略下逐步催生基于洛书协议的新兴市场和生态角色。以债务类场景为例,我们并不通过建立和优化一套针对特定贷款类别的一次性系统去解决问题,无论是点对点消费者的小额贷款网络或者分散式保证金贷款协议,因为此类解决方案会有一个共同的缺点——它们针对特定类别的债务而狭隘定制,而债务所涵盖的资产类别非常广泛,具有从应收账款保理到主权债券等各种化身,为每个用例构建安全,定制的协议机制是非常低效和多余的。因此,在明确了此类问题的情况下,就有了我们的解决方案,而且基于此方案在未来将会形成多的小生态叠加的格局,每个小生态业务明朗而开放,生态也会因不同的市场竞争逐渐完善和走向繁荣。
  洛书协议构建的是一个费用补偿性的市场,市场中的角色种类丰富并且任意个体都能够依靠自身的竞争力给网络提供增值服务来获利。接下来我们会针对洛书协议预定义的角色和洛书团队协助支持模板合约市场做简要介绍:

  • 中继者:中继者是托管和维护订单簿的实体,它能通过提供选择性丰富的订单排序方式,友好的交互界面等优质服务形成自身竞争力来聚集用户,高效促成订单成交后从中获利。关于执行的更详细描述可能是,中继者聚合已签名的各类订单消息,以获得事先约定的费用,然后它将消息集中在一个订单簿上给终端用户提供其所需要的撮合选择服务。中继者无需持有任何代币——它们只是提供了一个机制,让终端用户可以浏览聚合起来的已被签名的各类订单消息。终端用户可以使用该机制来无需信任地发行,借贷,交易各类数字资产以及完成加密货币与法币之间的兑换,以上操作只需通过客户端与合约简单交互便可进行。
  • 担保人:担保人是在需要对外界信息进行整合来提供服务的市场中的一类角色设置。在这里我们以债务市场为例,在传统的债务市场中,担保人是通过管理公共发行的债券和定价,评估借款人违约风险而收取费用的实体。在洛书协议中,这个定义被扩展和形式化为:一个受到信任的实体,它为履行以下职能收取由市场确定的费用:

    • 利用擅长的技术或手段(大数据,人工智能)整合借款人的财务类或非财务类信息进行违约风险评估。
    • 帮助借款人起草债务订单。
    • 与潜在债务人确定并协商债务条款(即期限、利息、摊销)。
    • 加密地记录某项发生在洛书网络中的具体债务关系作为未来信用评估的素材与存证。
    • 管理债务订单,并将其转寄给任意数量的中继者节点。
    • 在其签过名的债务订单中债务人违约或拖欠情况下,中继者有义务通过法律机制收集抵押品(若债务被担保)或个人资产,并将所得收益转给债权人。

    这其实与大多数在线贷款机构在日常借款受理和偿还业务中所做的事情并无二致,但洛书协议将给在线借贷平台提供另一种更廉价的途径,来促进他们的业务,并获得类似的利润。他们在洛书协议既定的机制下开展原有的业务将不再需要担心资产负债表风险。同时也节省了开展业务之前,从传统投资者那里筹集必要的债务工具,所带来的时间和资金成本。

  • 合约著作者:为了支持更加广阔的金融服务范围,我们在洛书的基础协议层对外提供了一系列通用接口,而在内部是对实现了通用接口的业务合约进行注册,配置,路由和管理等。值得注意的是,任何编写合约的作者都可以保留其著作权,由此可衍生出一个模板合约交易市场,合约作者可向合约用户通过VENA结算的方式来收取费用。在区块链社区,我们都秉承着代码开源的文化,因此每个人都可以对合约代码进行审查也可以将合约在主网中以低成本的方式重新部署,但我们坚持认为合约安全是一件很严肃的事情,对合约进行复制重新部署后的合约将不会得到原作者的维护与升级,资金安全无法得到应有的保证,据此我们认为模板合约市场最终在洛书网络中将会是一种合理的存在。下面我们介绍合约著作者设计特定的场景可能需要的功能接口,值得注意的是,此处只做可能性的描述,具体的接口标准请参照实际开发工作中的说明文档。
pragma solidity 0.4.18;


interface TermsContract {
     /// When called, the registerTermStart function registers the fact that
     ///    the debt agreement has begun.  This method is called as a hook by the
     ///    DebtKernel when a debt order associated with `agreementId` is filled.
     ///    Method is not required to make any sort of internal state change
     ///    upon the debt agreement's start, but MUST return `true` in order to
     ///    acknowledge receipt of the transaction.  If, for any reason, the
     ///    debt agreement stored at `agreementId` is incompatible with this contract,
     ///    MUST return `false`, which will cause the pertinent order fill to fail.
     ///    If this method is called for a debt agreement whose term has already begun,
     ///    must THROW.  Similarly, if this method is called by any contract other
     ///    than the current DebtKernel, must THROW.
     /// @param  agreementId bytes32. The agreement id (issuance hash) of the debt agreement to which this pertains.
     /// @param  debtor address. The debtor in this particular issuance.
     /// @return _success bool. Acknowledgment of whether
    function registerTermStart(
        bytes32 agreementId,
        address debtor
    ) public returns (bool _success);

     /// When called, the registerRepayment function records the debtor's
     ///  repayment, as well as any auxiliary metadata needed by the contract
     ///  to determine ex post facto the value repaid (e.g. current USD
     ///  exchange rate)
     /// @param  agreementId bytes32. The agreement id (issuance hash) of the debt agreement to which this pertains.
     /// @param  payer address. The address of the payer.
     /// @param  beneficiary address. The address of the payment's beneficiary.
     /// @param  unitsOfRepayment uint. The units-of-value repaid in the transaction.
     /// @param  tokenAddress address. The address of the token with which the repayment transaction was executed.
    function registerRepayment(
        bytes32 agreementId,
        address payer,
        address beneficiary,
        uint256 unitsOfRepayment,
        address tokenAddress
    ) public returns (bool _success);

     /// Returns the cumulative units-of-value expected to be repaid by a given block timestamp.
     ///  Note this is not a constant function -- this value can vary on basis of any number of
     ///  conditions (e.g. interest rates can be renegotiated if repayments are delinquent).
     /// @param  agreementId bytes32. The agreement id (issuance hash) of the debt agreement to which this pertains.
     /// @param  timestamp uint. The timestamp of the block for which repayment expectation is being queried.
     /// @return uint256 The cumulative units-of-value expected to be repaid by the time the given timestamp lapses.
    function getExpectedRepaymentValue(
        bytes32 agreementId,
        uint256 timestamp
    ) public view returns (uint256);

     /// Returns the cumulative units-of-value repaid by the point at which this method is called.
     /// @param  agreementId bytes32. The agreement id (issuance hash) of the debt agreement to which this pertains.
     /// @return uint256 The cumulative units-of-value repaid up until now.
    function getValueRepaidToDate(
        bytes32 agreementId
    ) public view returns (uint256);

    /**
     * A method that returns a Unix timestamp representing the end of the debt agreement's term.
     * contract.
     */
    function getTermEndTimestamp(
        bytes32 _agreementId
    ) public view returns (uint);
}

  前文我们对部分角色做了必要的描述,而更多角色的竞争优势如下:

角色 优势
OTC交易者 随时随地与任何交易对手进行方便,安全,快速,低费用的OTC交易
借款人 通过抵押数字货币,获得低利率的法币贷款
放贷人 获得安全且收益率高于银行利率的法币投资渠道
合约著作者 通过编写通用或特定的条款合约投放于市场,合约用户需要向著作者付费使用
中继者 维护一个订单簿,通过自定义有竞争力的策略和服务(如,订单排序和其他增值服务)来促成交易收取手续费获利
担保人 通过在市场中提供债务条款指导,数据整合,信用评估模型等竞争服务获利
陪审员 通过仲裁智能合约无法判断的争议获取代币奖励

2.7. 竞品分析

Vena Network ETHlend SALT Everex Libra Coinloan
项目类型 协议型(P2P交易协议) 平台型(P2P交易平台) 平台型(P2P交易平台) 应用型(去中心化抵押贷款机构) 应用型(去中心化抵押贷款机构) 平台型(P2P交易平台)
去中心化程度 完全 中等 中等 中等
安全性 高(智能合约保证) 高(智能合约保证) 中等(需要信任平台) 中等(需要信任机构) 中等(需要信任机构) 中等(需要信任平台)
生态扩张能力 强(利润分配广泛,可自定义场景) 中等 中等 中等 中等
发行,抵押,交易全生态的流通闭环 支持 不支持 不支持 不支持 不支持 不支持
链下争议解决方案 分散的陪审员网络 精简仲裁
跨链技术方案 双向挂钩,闪电原子交换 无明确说明 无明确说明 无明确说明 无明确说明 无明确说明
用户隐私保护 去中心化身份认证 无明确说明 授权获取用户数据,分布式存储 授权获取用户数据 无明确说明 无明确说明
Token升值逻辑 服务购买,抵押,保证金,出借抵押权等需求 抵押需求 抵押需求 抵押需求 抵押需求 抵押需求



3. 洛书协议详述

3.1. 协议流程

3.1.1. 握手协议

3.1.1.1. 交易握手

A. 意图用法币主动购买加密货币的交易场景的握手

img

  1. 意图用法币购买加密货币的订单生产者可以从任意可信的担保人处请求担保服务。
  2. 担保人收集该订单生产者的信息并对其进行信用和历史成交率评估,构建担保人承诺(含担保人地址,服务费等关键信息),用ECDSA算法对担保人承诺哈希进行签名,并将担保人承诺和ECDSA签名发送给订单生产者。
  3. 订单生产者审核担保人反馈的评估结果和服务费。若符合期望,订单生产者凭担保人承诺去任意中继者处构建订单并委托其推广;否则,可能的情况是:1)握手终止;2)订单生产者与担保人再次进行洽谈,并重复至步骤2;3)订单生产者寻求新的担保人进行服务委托,即跳转至步骤1。
  4. 中继者向订单生产者发送订单管理及推广等服务的报价。
  5. 订单生产者查收中继者反馈的服务报价,若符合期望,订单生产者具备条件来构建交易订单,订单构建完成后由中继者进行订单推广,中继者将订单生产者的交易订单更新至订单簿上进行推广。注意,中继者对订单进行展示和推广就已默认表明其接受订单上的所有参数,因此中继者不需要对该订单进行签名;若不符合期望,则可能的情况是:1)握手终止;2)订单生产者将订单发送至中继者并请求再次提供折扣报价,并重复至步骤4;3)订单生产者寻找新的中继者进行服务委托,并重复至步骤4。
  6. 订单消费者主动去中继者的订单簿挑选感兴趣的交易订单并进行填单。

B. 意图主动出售加密货币换取法币的交易场景的握手

img

  1. 意图主动出售加密货币的订单生产者与中继者就交易订单管理及推广的服务费等相关事宜进行洽谈。
  2. 中继者向订单生产者发送订单管理及推广等服务的报价。
  3. 订单生产者查收中继者反馈的服务报价。若符合期望,订单生产者构建交易订单并委托中继者推广订单,中继者将订单生产者的交易订单更新至订单簿上进行推广。注意,中继者对订单进行展示和推广就已默认表明其接受订单上的所有参数,因此中继者不需要对该订单进行签名;若不符合期望,则可能的情况是:1)握手终止;2)订单生产者将订单发送至中继者并请求再次提供折扣报价,并重复至步骤2;3)订单生产者寻找新的中继者进行服务委托,即跳转至步骤1。
  4. 订单者消费者可以从任意可信的担保人处请求担保服务。
  5. 担保人收集该订单消费者的信息并对其进行信用和历史成交率评估,构建担保人承诺(含担保人地址,服务费等关键信息),用ECDSA算法对担保人承诺哈希进行签名,并将担保人承诺和ECDSA签名发送给订单消费者。
  6. 订单消费者审核担保人反馈的评估结果和服务费。若符合期望,订单消费者从中继者的订单簿挑选感兴趣的交易订单并凭担保人评估进行填单;否则,可能的情况是:1)握手终止;2)订单消费者与担保人再次进行洽谈,并重复至步骤5;3)订单生产者寻求新的担保人进行服务委托,即跳转至步骤4。
  7. 订单消费者填单完成,由中继者将订单发送给订单生产者进行最后的审核。

C. 加密货币与加密货币兑换的交易场景的握手

img

  1. 无论是意图主动购买或出售加密货币的订单生产者与任意中继者就交易订单管理及推广的服务费等相关事宜进行洽谈。
  2. 中继者向订单生产者发送订单管理及推广等服务的报价。
  3. 订单生产者查收中继者反馈的服务报价。若符合期望,订单生产者构建交易订单,授权洛书代币转移代理合约使用其地址中的准备换手的代币,并委托中继者推广订单,中继者将订单生产者的交易订单更新至订单簿上进行推广。注意,中继者对订单进行展示和推广就已默认表明其接受订单上的所有参数,因此中继者不需要对该订单进行签名;若不符合期望,则可能的情况是:1)握手终止;2)订单生产者将订单发送至中继者并请求再次提供折扣报价,并重复至步骤1;3)订单生产者寻找新的中继者进行服务委托,即跳转至步骤1。
  4. 订单消费者主动去中继者的订单簿挑选感兴趣的交易订单并进行填单。

3.1.1.2. 借贷握手

A. 债务人发起借款订单

img

  1. 债务人可以从任意可信的担保人处请求债务服务,填写债务类型和借款条款。
  2. 担保人收集债务人的信息并对其进行信用评估,构建担保人承诺(含担保人地址,服务费等关键信息)和债务发行承诺,用ECDSA算法对担保人承诺哈希进行签名,并将债务发行承诺、担保人承诺和ECDSA签名发送给债务人。
  3. 债务人审核担保人反馈的信用评估和构建债务订单的模版及服务费。若符合期望,债务人根据模板构建债务订单并就委托中继者推广和管理订单的服务费等相关事宜进行洽谈;否则,可能的情况是:1)握手终止;2)债务人与担保人再次进行洽谈,并重复至步骤2;3)债务人寻求新的担保人进行服务委托,即跳转至步骤1。
  4. 中继者向债务人发送订单管理及推广等服务的报价。
  5. 债务人查收中继者反馈的服务报价。若符合期望,债务人用三方洽谈结果形成的参数来完善债务订单,并由中继者将债务订单进行推广,中继者将债务人的债务订单更新至订单簿上进行推广。注意,中继者对订单进行展示和推广就已默认表明其接受订单上的所有参数,因此中继者不需要对该订单进行签名;若不符合期望,则可能的情况是:1)握手终止;2)债务人将订单发送至中继者并请求再次提供折扣报价,并重复至步骤4;3)债务人寻找新的中继者进行服务委托,并重复至步骤4。
  6. 债权人主动去中继者的债务订单簿挑选感兴趣的债务订单并进行填单。
  7. 债务人在创建债务订单会对“了解我的债权人”这一栏目进行填充,若表示肯定,则债权人有义务将债务订单发送至债务人并由债务人将订单提交至洛书债务内核合约;若表示否定,则债权人可直接向洛书债务内核合约进行订单提交。值得注意的是,在债务人对“了解我的债权人”栏目表示肯定的情况下,洛书债务内核合约会校验提交者地址是否是债务人地址,若不是将被洛书债务内核合约拒绝。

B. 债权人发起放贷订单

img

  1. 债权人可以从任意可信的担保人处请求债务服务,填写债务类型和放贷条款。
  2. 担保人向债权人反馈所能提供的服务和创建债务订单的模版或工具,担保人地址以及需要支付的服务费等关键信息。
  3. 债权人审核担保人反馈的债务订单模板及服务费。若符合期望,债权人根据担保人提供的债务订单模版创建债务订单,然后将债务发送至中继者并就委托中继者推广和管理订单的服务费等相关事宜进行洽谈;若不符合期望,则可能的情况是:1)握手中止;2)债权人与担保人再次进行洽谈,并重复至步骤2;3)债权人寻找新的担保人进行服务委托,即跳转至步骤1。
  4. 中继者向债权人发送订单管理及推广等服务的报价。
  5. 债权人查收中继者反馈的服务报价,若符合期望,则回复中继者表示委托成立,中继者开始对债务订单进行推广,中继者将债务人的债务订单更新至订单簿上进行推广。注意,中继者对订单进行展示和推广就已默认表明其接受订单上的所有参数,因此中继者不需要对该订单进行签名;若不符合期望,则可能的情况是:1)握手中止;2)债权人将订单发送至中继者并请求再次提供折扣报价,并重复至步骤4;3)债权人寻找新的中继者进行服务委托,并重复步骤4。
  6. 债务人主动去中继者的债务订单簿挑选感兴趣的债务订单(包括对担保人和中继者的服务费审查)并进行填单。
  7. 债务人将订单反馈给债务订单中填充的担保人。债务人可根据担保人通信地址直接反馈或经中继者反馈。
  8. 担保人收集债务人的信息并对其进行信用评估,构建担保人承诺(含担保人地址,服务费等关键信息)和债务发行承诺,用ECDSA算法对担保人承诺哈希进行签名,并将债务发行承诺、担保人承诺和ECDSA签名发送给债务人。
  9. 债务人审核担保人反馈的信用评估。若符合期望,债务人对该债务订单进行签名后发送给债权人;否则,可能的情况是:1)握手终止;2)债务人与担保人再次进行洽谈,并重复至步骤8。

3.1.2. 交易类协议

3.1.2.1. 法币与加密货币的兑换

  在详述协议之前,我们将相关术语根据其上下文的语义进行简约规范与说明:

  1. 订单生产者与订单消费者之间的交易标的物为加密货币Token A和法币Fiat B。
  2. 出售加密货币换取法币的用户统称为加密货币用户。
  3. 通过法币购买加密货币的用户统称为法币用户。
  4. 加密货币用户和法币用户都有可能扮演订单生产者或订单消费者的角色。

  协议流程如下:

  1. 订单生产者、订单消费者、担保人、中继者之间完成交易握手。
  2. 加密货币用户授权洛书代币转移代理合约使用其地址中的Token A。
  3. 加密货币用户将订单提交至洛书内核合约。
  4. 交易订单被洛书内核合约校验通过后,订单中的Token A将被合约锁定,等待法币用户付款。
  5. 法币用户在指定的时间范围内向加密货币用户的法币账户转入Fiat B。
  6. 加密货币用户收到法币后,在指定的时间内向洛书路由合约发起法币收款确认交易,收款确认交易应当被填充了实际收款金额。
  7. 洛书路由合约验证订单是否过期,是否已经完全成交,金额是否匹配等,校验成功后将既定数量的Token A通过洛书代币转移代理合约自动转入法币用户的地址。

  需要特别说明的是,在法币与加密货币的兑换场景中,理论上任何能够支付gas的用户都能够向洛书内核合约提交该笔交易订单,实际上由加密货币用户完成提交会更加符合现实需求。

3.1.2.2. 加密货币与加密货币的兑换
  1. 订单生产者、订单消费者、中继者之间完成交易握手。
  2. 订单消费者授权洛书代币转移代理合约使用其地址中的准备换手的代币。
  3. 订单消费者将订单提交至洛书内核合约。
  4. 洛书内核合约验证签名,订单是否过期,是否已经完全成交,校验成功后以从指定的汇率通过洛书代币转移代理合约自动在双方之间转移代币。

3.1.3. 债务类协议

  债务发行的场景丰富且债务条款细节十分繁杂,因此洛书协议以通用性的架构来满足实际应用场景中的各类需求,即各类债务活动都可以通过编写场景插件合约(即条款合约)的方式来实现。然而,洛书官方会率先针对抵押贷和信用贷做主要的协议描述,并最终将其封装成为场景插件合约标准库。

3.1.3.1. 抵押借贷

A. 抵押数字资产借入法币

借款:
  在详述协议之前,我们将相关术语根据其上下文的语义进行简约规范与说明:债务人与债权人之间的抵押借贷标的物分别为数字资产Token A/NFT和法币Fiat B。

  1. 债务人、债权人、担保人、中继者之间完成借贷握手。
  2. 在债务订单提交至洛书内核合约之前,债务人应当已经授权洛书代币转移代理合约使用其地址中的准备抵押的加密货币Token A/NFT。
  3. 债务订单被提交至洛书内核合约,校验通过后洛书内核合约通过Oracle获取Token A与Fiat B的市场汇率(如果债务人抵押标的物为NFT,则洛书内核合约从提交的债务订单中获取NFT的协商估值),并根据设定的借贷模型进行参数计算。计算完成后将有两种情况:1)如果握手流程是以债务人主动发起借款订单的方式进行,洛书内核合约校验债务人地址中的Token A余额/NFT是否存在,若Token A余额不足/NFT不存在,则借款失败,订单取消;若Token A的余额/NFT存在且NFT的协商估值满足抵押标的额与债务订单中的担保人服务费,中继者服务费的总额,则从计算结果中获取债权人应付本金,将抵押物Token A/NFT锁定至合约中并等待债权人向债务人的法币账户转账计算值数额的本金。2)如果握手流程是以债权人主动发起放贷订单的方式进行,则从计算结果中获取债务人实际应该抵押Token A的数额(如果债务订单中抵押标的物为NFT,在握手过程中应当已经就NFT的协商估值达成共识,在此处洛书内核合约依然会依据债权人主动放贷额,NFT的协商估值,抵押模型参数进行计算验证),洛书内核合约校验债务人地址中的Token A余额/NFT是否存在,若余额不足/NFT不存在,则放贷失败,订单取消;若Token A的余额满足应该抵押Token A的计算值,债务订单中的担保人服务费,中继者服务费的总额/NFT存在且NFT的协商估值满足[抵押率 * Amount(Fiat B)],债务订单中的担保人服务费,中继者的服务费的总额,则将抵押物Token A/NFT锁定至合约中并等待债权人向债务人的法币账户转账放贷标的额的本金。
  4. 债权人在指定的时间范围内向债务人指定的法币账户转入应转本金。
  5. 债务人收到法币后,在指定的时间内向洛书路由合约发起法币收款确认交易,收款确认交易应当被填充了实际收款金额。
  6. 洛书路由合约验证订单是否过期,是否已经成交,金额是否匹配,校验成功后将既定数额的担保人服务费,中继者服务费通过洛书代币转移代理合约分别划转到对应的地址。

全额还款:

  1. 抵押贷款到期后,洛书内核合约通知债务人还款。
  2. 债务人在指定的时间内向债权人的法币账户转入应还的全期本息总额。
  3. 债权人收到法币后,在指定的时间内向洛书路由合约发起法币收款确认交易,收款确认交易应当被填充了实际收款金额。
  4. 洛书路由合约验证债权人签名,订单是否存在,金额是否匹配等,校验成功后将锁定的抵押物Token A/NFT转入债务人的地址,并登记该笔还款。

分期还款:

  1. 在抵押期内,债务人向债权人的法币账户转入参数确定的所需还款金额。
  2. 债权人收到法币后,在指定的时间内向洛书路由合约发起法币收款确认交易,收款确认交易应当被填充了实际收款金额。
  3. 洛书路由合约验证债权人签名,订单是否存在,金额是否匹配等,校验成功后洛书内核合约通过Oracle获取Token A与Fiat B的市场汇率(如果债务人抵押标的物为NFT,分期还款在未完成全额还本付息之前将无法赎回NFT),并根据设定的借贷模型进行参数计算获取应赎回的Token A的数量,然后通过洛书代币转移代理合约将计算值对应数额的Token A转移至债务人的地址,并登记该笔还款。

B. 抵押数字资产借入数字资产

借款:
  抵押数字资产借入数字资产更多的应用会是在以NFT为抵押标的物的场景中,而主流加密货币因具备较高的市场流动性导致抵押需求减少,市场流动性不高的加密货币因风险指数较高将会增加系统性的风险。因此,我们以抵押NFT借入主流加密货币为例做协议详述:

  1. 债务人、债权人、担保人、中继者之间完成借贷握手。
  2. 在债务订单提交至洛书内核合约之前,债务人应当已经授权洛书代币转移代理合约使用其地址中的抵押标的物的NFT资产,债权人应当已经授权洛书代币转移代理合约使用其地址中的准备放贷的主流加密货币Token X。
  3. 债务订单被提交至洛书内核合约,校验通过后洛书内核合约通过Oracle获取Token X的实时市场价格,并根据设定的借贷模型和NFT的协商估值(该值在订单创建时被填写)进行参数计算获取债权人应放贷Token X的数额,洛书内核合约校验债权人的地址中Token X的余额,若NFT不存在,则借贷失败,订单取消;若NFT存在且NFT的协商估值满足债权人应放贷Token X的数额,债务订单中担保人服务费,中继者服务费的总额,则通过洛书代币转移代理合约将抵押物NFT锁定至合约,应放贷的Token X,既定数额的担保人服务费,中继者服务费分别划转至对应的地址。

还款:

  1. 分期还款或到期还款,债务人应当授权洛书代币转移代理合约转账限额的Token X,其数额大于或等于所期望的本息总额。
  2. 债务人向洛书路由合约发起还款交易,还款交易应当填充了参数确定的所需还款金额。然后,洛书路由合约将获取该笔债务的当前受益人地址(如果抵押期间未发生质押权转移,则洛书路由合约获取该笔债务的最初债权人地址)并将所期望的还款金额从债务人的地址转移到当前受益人的地址上,并登记该笔还款。
  3. 若债务人的本息全部还清,则自动触发洛书代币转移代理合约将NFT转移至债务人的地址。
3.1.3.2. 债务融资/个人信用借贷

A. 融资标的物为法币

借款:

  1. 债务人、债权人、担保人、中继者之间完成借贷握手。
  2. 在债务订单被提交至洛书内核合约,校验通过后洛书内核合约通知债权人向债务人的法币账户转入融资标的额的法币。
  3. 债权人在指定的时间范围内向债务人指定的法币账户转账应转本金。
  4. 债务人收到法币后,在指定的时间内向洛书路由合约发起法币收款确认交易,收款确认交易应该被填充了实际收款金额。
  5. 洛书路由合约验证订单是否过期,是否已经成交,金额是否匹配校验成功后将铸造一枚承载信誉证明的NFT。铸造的信誉证明NFT,既定数额的担保人服务费,中继者服务费通过洛书代币转移代理合约分别划转至债权人,担保人,中继者的地址。

全额还款:

  1. 贷款到期后,洛书内核合约通知债务人还款。
  2. 债务人在指定的时间内向债权人的法币账户转入应还的全期本息总额或剩余本息总额。
  3. 债权人收到法币后,在指定的时间内需要授权洛书代币转移代理合约使用其地址的信誉证明NFT并向洛书路由合约发起法币收款确认交易,收款确认交易应当被填充了实际收款金额。
  4. 洛书路由合约验证债权人签名,订单是否存在,金额是否匹配,校验成功后债权人地址中的信誉证明NFT通过洛书代币转移代理合约自动转移至债务人的地址,登记该笔还款。

分期还款:

  1. 在贷款期内,债务人向债权人的法币账户转入参数确定的所需还款金额。
  2. 债权人收到法币后,在指定的时间内向洛书路由合约发起法币收款确认交易,收款确认交易应当被填充了实际收款金额。
  3. 洛书路由合约验证债权人签名,订单是否存在,金额是否匹配等,校验成功后登记该笔还款。

B. 融资标的物为加密货币

借款:

  1. 债务人、债权人、担保人、中继者之间完成借贷握手。
  2. 在债务订单被提交至洛书内核合约之前,债权人应当已经授权洛书代币转移代理合约使用其地址中的准备放贷的主流加密货币Token X。
  3. 债务订单被提交至洛书内核合约,校验通过后洛书内核合约获取债务订单中的融资标的额并查询债权人地址中Token X的余额,若余额不足,则融资失败,订单取消。若Token X的余额满足融资标的额,债务订单中的担保人服务费,中继者服务费的总额,则铸造一枚承载信誉证明的NFT。铸造的信誉证明NFT,标的额数量的Token X,既定数额的担保人服务费,中继者服务费通过洛书代币转移代理合约分别划转至债权人,债务人,担保人,中继者的地址。

还款:

  1. 分期还款或者到期还款,债务人应当授权洛书代币转移代理合约转账转账限额的Token X,其数额大于或等于所期望的本息总额。
  2. 债务人向洛书路由合约发起还款交易,还款交易应当填充了参数确定的所需还款金额。然后,洛书路由合约将获取该笔债务的当前受益人地址(如果在贷款期内未发生信誉证明NFT质押转移,则洛书路由合约获取该笔债务的最初债权人地址)并将所期望的还款金额从债务人的地址转移到当前受益人的地址上,并登记该笔还款。若该笔还款为债务的剩余还款,则债权人应当已经授权洛书代币转移代理合约使用其地址中的信誉证明NFT,并在债务还清的同时通过洛书代币转移代理将信誉证明NFT从债权人的地址转移至债务人的地址。

3.2. 订单格式

  对应于上述的两种协议, 我们分别设计了两类订单:交易类订单和借贷类订单。订单设计上,简单,灵活性,可扩展是我们的设计出发点。同时,我们的订单格式也支持交易双方的双向挂单,和订单拆分。
  每个订单都是一个包含该订单类型固定格式的参数和相关签名的数据包。订单参数按key升序排列连接并通过Keccak SHA3函数散列为32个字节。订单发布者使用他们的私钥签署订单参数散列以产生ECDSA签名。
  Vena Network中的中继者仅负责保存和传播一个订单簿来促进对手双方的信息流动,并从中收取少量手续费(手续费数额由洛书节点、对手方等多方共同决定)。和中心化的机构不同,洛书节点不托管用户的加密货币,也不代表借贷或交易双方成交订单,这意味着对手双方不需要信任洛书节点的运营者。
  中继者可以选择是否将订单放入共享流动性池中。如果订单被放入共享流动性池中并在其他的中继者处成交,那么手续费将由两个中继者按订单成交前预设的比例进行利润分成。

3.2.1. 交易类订单格式

  从命名上就可以看出,我们用Intent来表示填单之前的链下传递的订单,用Fill表示填单之后链上结算的订单记录。 一个Intent可能对应一个或者Fill,因为一笔链下的订单可以被多次填单,以实现订单拆分。下面的表格详细订单结构:

Name Data Type Description
kernelVersion address Address of the vena kernel contract. When protocol upgrades occur, this address will be updated.
orderType string Order types.
producer address Address of the order producer.
relayer address Address of the relayer.
appraiser address Address of the appraiser wishing to attest to the rating of this debt asset.
appraiserRiskRating uint32 The appraiser's assessment of the average likelihood that any given unit-of-value the debtor is expected to pay will actually be repaid. Must be a value between 0 and 1, encoded as an unsigned integer understood to have 9 decimal points (i.e. a 50% likelihood would be represented as 500000000)
relayerFee uint Fee charged by relayer, cleared from VENA token.
producerFee uint Total fee need to be payed by producer after this intent being filled, cleared by VENA token.
consumerFee uint Total fee need to be payed by consumer after this intent being filled, cleared by VENA token.
appraiserFee uint Fee charged by appraiser, cleared from VENA token.
producerSymbol string The type of asset the order producer wants to send.
producerAmount uint256 The number of assets the order producer wants to send.
producerChannel string The payment method selected by the order producer.
consumerSymbol string The type of asset the order consumer wants to send.
consumerAmount uint256 The number of assets the order consumer wants to send.
minAmount uint The minimum amount of principle that this intent is expected to be partial filled.
expirationTimestamp uint256 Unix timestamp of the time at which this order will no longer be valid if unfilled.
salt uint A pseudo-random salt value used ot differentiate the hashes of debt orders with identical parameters.
intentId byte32 The hash of the whole intent.

  当订单消费者完成填单并提交到链上时,用Fill来记录这笔订单。

intentId byte32 The related intent id.
consumer address The address of consumer who fill the intent with intentId above.
fillAmount uint The amount of asset which creditor willing to lend.
salt uint A pseudo-random salt value used ot differentiate the hashes of debt orders with identical parameters.
fillId byte32 The hash of the whole fill.

3.2.2. 债务类订单格式

  和交易类订单略有不同的是,借贷类订单主要添加了 loanContractloanContractParameters 两个字段。loanContract定义标准接口, 以抽取抵押和还款逻辑。填单人可以在填单之前查看已部署的loanContract合约以了解详细的还款和抵押方式。VENA提供一套参考的借贷合约,包括抵押借贷,信用借贷,分期借贷等等。同时,任何人都可以定义自己的借贷合约,只要合约符合loanContract标准接口即可。在抵押借贷中,债务人和债权人权责不同,故我们设计了以下四种订单定义,分别用于双方的发单和填单:

  • Debtor Intent: 债务人发起的待填订单。
  • Creditor Fill: 债权人填写后的已填订单。
  • Creditor Intent: 债权人发起的待填订单。
  • Debtor Fill: 债务人填写后的已填订单。

  下面我们以 Debtor IntentCreditor Fill 为例列举订单格式,后两者只是债务人债权人的位置对换,不再赘述。

Name Data Type Description
kernelVersion address Address of the vena kernel contract. When protocol upgrades occur, this address will be updated.
orderType string Order types.
debtor address Address of the debtor.
relayer address Address of the relayer.
appraiser address Address of the appraiser wishing to attest to the rating of this debt asset.
appraiserRiskRating uint32 The appraiser's assessment of the average likelihood that any given unit-of-value the debtor is expected to pay will actually be repaid. Must be a value between 0 and 1, encoded as an unsigned integer understood to have 9 decimal points (i.e. a 50% likelihood would be represented as 500000000)
relayerFee uint Fee charged by relayer, cleared from VENA token.
debtorFee uint Total fee need to be payed by debtor after this intent being filled, cleared by VENA token.
creditorFee uint Total fee need to be payed by creditor after this intent being filled, cleared by VENA token.
appraiserFee uint Fee charged by appraiser, cleared from VENA token.
principalToken string The kind of asset for principle, which can be "BTC", "CNY", "USD", "USDT", etc.
principalAmount uint The amount of principle.
principleChannel string The payment method selected by the debtor.
minAmount uint The minimum amount of principle that this intent is expected to be partial filled.
loanContract address Address of the Loan Contract Interface adherent smart contract that defines: 1.the repayment terms of the debt. 2. If the loan have collateral, this contract can determine the collateral detail.
loanContractParameters bytes32 Data packet of parameters ingested by the Terms Contract to commit to specific values relevant to the repayment terms (e.g. principal, interest rate, etc.)
payload string The additional information for this intent.
expirationTimestamp uint256 Unix timestamp of the time at which this order will no longer be valid if unfilled.
salt uint A pseudo-random salt value used ot differentiate the hashes of debt orders with identical parameters.
intentId byte32 The hash of the whole intent.

当债权人填单后,Creditor Fill 被记录上链:

intentId byte32 The related debt intent id.
creditor address The address of creditor who fill the intent with intentId above.
fillAmount uint The amount of asset which creditor willing to lend.
salt uint A pseudo-random salt value used ot differentiate the hashes of debt orders with identical parameters.
fillId byte32 The hash of the whole fill.

3.3. 价格、利率、清算与保护机制

  洛书节点不能决定交易类订单的价格,而只能向交易双方推荐一个当前市场的公允价格,具体成交价格由交易双方共同决定。为了促进流动性,洛书节点内的交易订单列表默认按照价格由低到高的顺序排列,但每个节点有权选择更优排序策略并收取相应的增值服务费,该行为受市场竞争制约。洛书节点也不能决定借贷利率,利率由借入方自行设定。如果出借方对于借入方给出的利率满意,那么双方将通过智能合约完成交易。通过洛书官方团队提供的借贷类合约标准库完成的借贷订单会享受较优的风控策略,因此包括但不限于的风控参数,如可抵押代币种类,抵押率,强制清算线等均由洛书协议开发组统一设置。这些全局设置将保存在一个由洛书基金会部署的以太坊智能合约中,任何一个设置参数的修改均需要DAO投票通过。为了应对突发情况,洛书基金会可选出若干成员组成Vena DAO委员会,委员会中的多数成员确认即可执行某项修改操作。
  在抵押贷的场景中,如果在借款期内,系统将使用区块链的时钟或调度系统(如以太坊的ethereum-alarm-clock)定时调用价格预言机合约,从可信预言机集合(trusted-oracles-set)获取抵押代币实时价格,并通知洛书内核合约。洛书内核合约收到价格通知以后,计算本合约内所有抵押贷款订单的抵押物价值是否低于清算线。如果发现抵押物价值低于清算线,则立即向借款方发送通知,要求其在指定时间内补充抵押物至安全水平。指定时间过后洛书内核合约再次计算抵押物价值,如果仍低于清算线则立即自动执行强制清算。清算方法为:计算实时应还的本息总额,将价值等于本息总额105%(至多)的代币转入出借方地址,剩余代币转入借入方地址。
  为了防止多种欺诈和攻击情况,我们使用(不限于)如下的保护机制:

  • 用户 - 必须通过KYC才能进行交易
  • 洛书节点 - 必须通过洛书基金会认证,必须抵押保证金
  • 陪审员 - 必须通过洛书基金会认证,必须抵押保证金,匿名并随机分配仲裁
  • 数字签名订单 - 借贷或交易细节不可伪造的证据
  • PageSigner证据 - 法币转账不可伪造的证据
  • 加密货币与法币兑换或现金贷有金额限制 - 限制最大金额(50ETH)以减少欺诈的潜在收益
  • 时间锁定智能合约(Timelock Contract)- 解决交易对手恶意退出风险
  • 仅支持不可逆转的法币转账方式,以最大限度的降低退款风险(参见https://en.bitcoin.it/wiki/Payment_methods
  • 价格观察机制 - 通过区块链时钟(如以太坊的ethereum-alarm-clock)定时调用价格预言机合约,从可信预言机集合(trusted-oracles-set)获取抵押代币实时价格
  • 可信预言机集合 - DAO有权投票决定一组可信的预言机节点,突发情况下,DAO委员会中多数成员确认即可增加或删除若干预言机节点
  • 强制清算机制 - 解决抵押物价格下跌的风险
  • 不得在加密货币交易非法的司法管辖区使用洛书协议

3.4. 黑天鹅事件

  黑天鹅事件是指非常难以预测,且不寻常的事件,通常会引起市场连锁负面反应甚至颠覆。加密货币市场具有很大的波动性,因此我们必须考虑一种极端情况:某种抵押代币的价格在短时间内快速下跌,系统还来不及执行强制清算,抵押物价格就已经跌破了债务金额。在这种情况下,为了防止风险敞口扩大,系统会立即自动执行强制清算,并请求洛书ERC20 Contract根据VENA Token的市场价格每年增发不超过总量3%的VENA Token给出借方以补偿抵押物价值与债务金额之差。这种增发机制虽然会对VENA Token造成一定程度的价值稀释,但是与大规模债务违约对Vena Network造成的伤害相比较,这种价值稀释是温和并且可控的,也符合绝大多数VENA Token持有者的长期利益。
  如果加密货币市场价格大幅波动,那么Vena DAO委员会有权决定将某些种类的加密货币移出可抵押代币范围,甚至暂时关闭全网抵押贷款业务。由于Vena Network的主要业务体系完全建立在以太坊,比特币和EOS(未来扩展至其他主流的公链)生态系统之上,因此Vena Network的安全性和实用性以及VENA Token的价格都会在很大程度上取决于以太坊,比特币和EOS生态系统的健康程度。从长远来看,洛书团队将持续密切关注区块链底层技术的发展方向,Vena Network也将因此受益于整个加密货币生态的繁荣而获得持续的健康发展。

3.5. 智能合约技术

  洛书协议通过一组部署在区块链上的智能合约完成了一个标准实现。该组合约代码是开源的(使用AGPL协议发布源代码)并可以免费使用(仅需要标准gas消耗)。洛书团队采用开发生态完善且安全性高的智能合约语言编写,提供借贷类和交易类合约标准库。

3.5.1. 签名认证

  洛书内核合约能够使用ecrecover函数认证参与订单构建的角色的签名,以防止提交伪造或篡改的订单来进行欺诈。该函数将哈希和签名哈希作为参数,返回生成签名的公钥地址。如果ecrecover返回的公钥地址等于签名者的地址,则该签名是真实的。

address publicKeyAddr = ecrecover(hash, signature(hash));
if(publicKeyAddr != signerAddr) throw;

3.5.2. 时间锁定

  时间锁定在洛书协议中主要的用途之一是解决链下法币转移时,可能出现的人工确认超时,恶意欺诈等问题。我们简单列举几项具体的应用场景,在此之前将相关术语根据其上下文的语义进行简约规范与说明:

  1. 出售加密货币换取法币的卖家,出借加密货币的债权人,借入加密货币的债务人,还款加密货币的债务人等以加密货币作为转出物的用户在当前上下文中统称为加密货币用户。
  2. 通过法币购买加密货币的买家,出借法币的债权人,借入法币的债务人,还款法币的债务人等以法币作为转出物的用户在当前上下文中统称为法币用户。

  3. 在有法币用户参与的交易场景中,订单被提交后,法币用户必须在30分钟内完成法币转账并点击“已转账”按钮,否则视为放弃交易,洛书内核合约将锁定的Token/NFT退还至对应的加密货币用户的地址。

  4. 在有法币用户参与的交易场景中,法币用户点击“已转账”按钮后,会立即收到通知。此后加密货币用户必须在1小时内点击“确认收款”或者“申请仲裁”,否则视为恶意退出交易,洛书内核合约将锁定的Token转入法币用户的地址。
  5. 在法币用户是债务人,加密货币用户是债权人的抵押贷场景中,抵押贷款到期后,洛书内核合约向债务人发出还款通知,债务人必须在24小时内完成法币还款并点击“已还款”按钮,否则视为还款逾期,洛书内核合约将立即执行强制清算。
  6. 在法币用户是债务人,加密货币用户是债权人的抵押贷场景中,抵押贷款到期后,债务人点击“已还款”后,债权人必须在24小时内点击“确认收款”或者“申请仲裁”,否则视为恶意退出交易,洛书内核合约将锁定的Token退还债务人的地址。
  7. 任意一方申请仲裁后,交易双方必须在24小时内按照系统要求提交证据,此后进入陪审员仲裁阶段,未提交证据方将没有机会再次提交证据。

3.5.3. 填充和部分填充订单

  洛书内核合约存储了每个先前提交的订单。每个订单由一个结构体(struct)构成。订单列表被存储在一个mapping(一种类似于哈希表的solidity数据结构)中。这个mapping将32字节的数据块映射到订单结构体。将订单参数传递到Keccak SHA3函数中会生成一个唯一的32字节散列,用于唯一标识该订单(哈希碰撞的几率实际上为零)。在订单结构体中有一个成员ValueFill,用于表示该订单被填充的数量。每次订单被填充时,mapping都会更新订单填充数量的累计值。

struct Order {
  ...
  uint256 valueFill;
}
mapping(bytes32 => Order) internal OrderList

  在填充OTC交易订单和抵押贷款订单时,订单消费者可以通过指定附加参数valueFill来部分填充订单。只要部分填充的总和不超过订单总额,就可以对单个订单执行多次部分填充。

Name Data Type Description
valueFill uint256 Total units of token or fiat to be filled (valueFill ≤ valueA or valueB).

  在填充抵押贷款订单时,债权人需要指定附加参数creditorRealName, paybackChannel, paybackDetail来指定法币还款方式。

Name Data Type Description
creditorRealName string Real name of Creditor
paybackChannel bytes Fiat payback channel (eg. paypal, alipay)
paybackDetail string Details of payment

3.5.4. 过期时间

  订单的过期时间由订单生产者指定。过期时间是一个无符号整数值,表示一个UNIX时间戳。该值一旦被签名就无法更改。
  我们举例以太坊来说明过期时间的确认。在以太坊虚拟机中的时间由每次挖出新区块时设置的块时间戳给出。因此,判断订单是否过期并不取决于订单提交的时间,而是取决于矿工在EVM中执行填充功能的时间。矿工无法将当前区块的时间戳设置为早于前一个区块的时间戳。

3.5.5. 取消订单

  在订单被提交给洛书内核合约之前,订单生产者可以随时向中继者请求取消订单。在订单被提交给洛书内核合约后,订单生产者可以通过洛书内核合约的取消功能取消未填充且未过期的订单部分。该功能将订单的valueFill更改到最大值以防止后续填充。通过洛书内核合约取消订单会产生费用,因此该功能仅用作回退机制。通常情况下,订单生产者可以通过将订单过期时间设置为与他们打算更新订单的时间相匹配来避免链上取消订单交易。
  这种方法存在的一个问题是它可能会造成一种情况:订单生产者在试图取消订单的同时,订单消费者试图填充同一订单。这会导致两笔交易中的一笔失败,并浪费gas。交易开采顺序的不确定性有时会导致非预期的结果,如果区块链上待处理的交易大量积压,这种不确定性可能会增加。

3.6. 多链资产与洛书调度

  洛书协议是一套设计与描述规范,可兼容部署于任何支持智能合约平台的区块链网络。由于各条公有链之间是异构的,差异化特征明显,因此洛书协议会在保持协议本身统一规范的原则下针对特定的公有链做更多的适配性与性能上的优化,最大限度与该链契合。未来,当更多的公有链成为洛书协议的生长土壤时,我们会在协议上层实现洛书业务调度系统,即在已经部署洛书协议的公有链上进行业务流量探针埋点,然后根据流量的分布情况进行统一调度,从而缓解区块链网络交易拥堵的窘况。
  洛书协议的多链兼容部署是对多链资产的支持,而资产的跨链流通是协议生态走向繁荣的必经之路。为了实现这一目标,我们需要依靠允许这些加密货币网络之间相互通信的技术和协议。我们很高兴地看到许多优秀的团队 — — 比如,Polkadot和Cosmos — — 正在着手解决这一问题。遗憾的是,这些项目现今仍处于紧张的开发阶段 — — 有的要么尚未公布具体的发布日期(例如Polkadot),要么仅仅适用于基于权益证明(PoS)机制的区块链(例如Cosmos)。因此,现有区块链间的跨链通信的实际解决方案依然有待探索。在综合比较了多种跨链技术方案以后,洛书团队审视项目定位,选择了走复用现有已被验证可行方案的路线,并对已选方案组合实施来优势互补。此外,洛书团队也积极从链之上的第二层去设计与探索通用性协议。比如,已经被提出的一种轻量级的多利益关联方的共识协议,这种协议和体系不对底层链进行完全复制,不产生独立的链,而是采用参与者机制,如陪审团制度随机选取陪审员,所有的陪审员节点再与各底层链交互实现存证,这样可最大化利用现有的区块链和各类资源。在这种设计中,所有的链都可以是参与方,不需要“链与链”之间的锚定,而是通过在各个区块链之上构建一个可扩展的,通用的“象限层”,并在“象限层”中实现“互操作”,因此“象限层”可视作是互链层的一种类IP协议。当各个链之间需要跨链状态转移时,触发选举合约选举若干节点组建一个陪审团(陪审团是由相互之间有状态转移的各条链自身的网络中的矿工组成,我们从“象限层”的统一接口表中抽象出通用选举合约并部署在各条公有链上,然后从“象限层”向各条链发起陪审团选举,被选中的矿工节点最终组成陪审团),陪审团将验证交互链的状态映射到“象限层”之后执行状态转移的真实性。在“象限层”的状态转换T(S, c1, c2, c3, ...) -> S'的转换逻辑受智能合约控制,因为“象限层”也搭建了智能合约的执行环境。据此可知,陪审团的工作实际上是验证“象限层”的智能合约的执行。在通过“象限层”来进行跨链状态转移的过程中,伴随奖惩机制,比如以VENA Token作为陪审团验证合约执行的奖励;普通矿工节点想要注册成为陪审团的候选人,需要进行抵押若干VENA Token;陪审团成员的矿工节点作恶一旦被发现,其抵押的VENA Token将会被没收。值得注意的是,此处描述的跨链验证的陪审团与(5.5章节)描述的用于解决链下法币转移纠纷陪审员网络并非同一个对象,但是对于参与到洛书协议生态的运营实体而言,两者可统一合并。

3.6.1. 区块链的基础货币与链之上的应用代币的兼容性

  在解决跨链资产转移与交换之前,我们更应该关注的是区块链的基础货币与在它之上发布的应用代币之间的兼容性问题,它是实现全生态多资产流通闭环进程中非常重要的一环。以Ethereum举例,WETH合约在主网部署之后就解决了ETH与VENA等ERC20标准的Token之间的链上兑换问题。首先,ERC20为以太坊Token建立了一个标准接口,以允许以太坊智能合约与任何符合标准的Token进行交互。ETH是以太坊的基础货币,不符合ERC20 Token标准。然而,许多DApp开发者发现,编写智能合约将ETH抽象为兼容ERC20的Token可以实现ETH与ERC20 Token之间的无缝兑换,免除了需要通过编写业务逻辑代码来实现转换的繁文缛节。
  当洛书协议部署在以太坊上,我们使用由Makerdao团队部署的WETH合约来实现上述功能,而在其他的区块链网络进行洛书协议的部署时,洛书团队会编写类似的智能合约来解决基础货币与应用代币的兼容性问题。
合约部署地址:

3.6.2. 双向挂钩(2-way peg)技术

  以下是关于双向挂钩的一般性描述:我们把以太坊上的比特币代理币称为E-BTC。当一个用户“存放”BTC时,这些BTC在比特币区块链上被锁定。这些BTC的交易证明被发送到一个以太坊合约中,该合约被称为PegContract。PegContract验证这笔交易,并发行E-BTC到用户的以太坊地址。比特币系统中的1BTC等价于以太坊系统中的1E-BTC。之后,当用户想把E-BTC换回到BTC时,只要燃烧掉E-BTC,再提供一个烧毁证明给比特币区块链。比特币区块链验证这些E-BTC已经烧毁后,解锁原始的BTC。
  这种PegContract现在就能在以太坊上实现,并且能够无需信任地完成所有工作:它能够验证BTC已经被发送到某个地址并且锁定了;它能够发行E-BTC;它能够燃烧E-BTC并提供烧毁证明。BTC-Relay就是这样一种合约,BTC-Relay实现了比特币简化支付证明(SPV),从而能够验证一笔交易是否已经在比特币区块链上被确认(需要向中继者支付验证手续费以激励中继者持续向BTC-Relay合约提交比特币区块头)。因此在比特币系统中的任何交易,从支付到BTC的锁定,都可以被以太坊合约验证。同理我们可以实现用以太坊合约验证比特币现金(BCH)区块链上的交易。
  双向挂钩存在的问题是,我们无法在比特币区块链上部署ETH-Relay或者任何锁定合约。我们可以等到RootStock发布以后,在ETH和RootStock之间建立一个双向挂钩,以实现比特币和以太坊之间的交互。另一个实际的解决方案是,将用户的BTC锁定在多重签名地址中,其中每个签名者必须在以太坊PegContract中存入ETH。当BTC被锁定时,PegContract将照常发行E-BTC。当E-BTC被发回PegContract时,它们将被烧毁并由PegContract生成证明。同时PegContract开始倒计时,为签名者提供足够的时间来验证烧毁证明并解锁BTC。如果任何签名者不签署多重签名,他存放在PegContract中的ETH会被转入用户的以太坊地址。为了使赎回过程更加顺利,签名者可以从每次存入/赎回过程中获得手续费奖励。具体原理如下图所示:

img

3.6.3. 闪电原子交换(Lighting atomic swap)技术

  为了确保跨链交易的安全性,双向挂钩技术的交易速度必须满足以下不等式:

                    

v表示跨链安全交易速度;v1、v2分别表示两条区块链单独的安全交易速度。从上式可以看出,跨链安全交易的速度比任意一条区块链上的安全交易速度更慢。对于比特币区块链,安全的交易确认时间可能需要30分钟甚至更久。另一方面,由于需要在两条区块链上各上链一笔交易并且支付一笔SPV验证的gas费用和一笔中继者手续费,所以使用双向挂钩技术实现跨链交易是比较昂贵的。
  闪电原子交换是一种结合了闪电网络和原子交换两种技术的即时跨链交易技术。闪电网络是一种协议,它通过在不同的交易者之间创建链下支付通道来工作,只有在打开和关闭支付通道时才需要上链交易。这有三大好处:第一,加快交易速度;第二,降低交易费用;第三,提高交易容量。原子交换是另一种协议,它能够让交易双方无需信任地进行跨链交易。原子交换的执行只有两种结果,要么双方成功完成数字货币交换,要么什么都没有发生。最重要的是,因为交易无需信任任何第三方,也就避免了欺诈。
  单独使用原子交换需要很长的等待时间来确保安全,并且需要上链至少四笔交易。而在两条区块链均存在支付通道的情况下,使用闪电原子交换可以大大缩短等待时间,并且不需要上链任何一笔交易。Lightning实验室已经于2017年11月16日确认完成了全球首次基于比特币-莱特币区块链的闪电原子交换。具体的技术原理如下图所示:

img

截至本文写作时,比特币闪电网络已经在比特币主网成功发布,以太坊上的闪电网络——雷电网络(Raiden Network)正在密集研发中。我们将持续关注相关项目的进展并在合适的时间(待相关技术的可靠性得到验证)将闪电原子交换技术引入Vena Network。



4. 洛书协议代币

  为了促进Vena Network的发展并让更多人能够参与洛书生态建设,分享洛书生态收益,在Vena Network上建立分散的协同决策机制。洛书团队将发行基于以太坊区块链的ERC20代币VENA Token。VENA Token将主要用于在洛书生态内部流通,并激励洛书用户建设、使用和维护Vena Network。VENA Token将成为Vena Network稳定运转的润滑剂。

4.1. VENA代币经济模型

  协议代币的价值储存功能和流通功能是代币经济模型设计中的一对矛盾。如果代币经济模型设计偏向于价值储存功能,由于存在价格上涨预期,代币拥有者倾向于持有而非使用代币,这又进一步导致了流动性减弱。这种自我强化的正反馈导致新用户进入门槛过高,协议使用范围的扩大受到阻碍。这种情况已经在比特币系统中得到了验证。可以预见,当这种自我强化达到极限,市场上已经没有人再使用这种代币,也没有新用户进入,那么整个代币经济模型就接近了崩溃边缘。代币交易完全由投机需求驱动,代币价格随时可能在最高点突然崩盘。如果代币经济模型设计偏向于流通功能,那么用户就没有动力持有代币,而是选择尽快交易,尤其是当协议代币价格上升预期低于其他具有价值储存功能的代币的时候。这种情况下,用户持有协议代币的平均时间取决于对代币价格的预期,代币的使用价值和使用频率,代币与其他货币的交易成本。任何一个因素的下降都会导致用户倾向于交易而非持有代币,这又进一步导致了代币价格的下跌预期。这种逆向的正反馈会导致协议代币价格崩溃,甚至整个协议生态的死亡。
  通过上面的分析我们得出结论,一种协议代币只有同时具备价值储存和流通功能并维持两者之间的平衡,才能保持相对稳定的价格。Vitalik Buterin在2017年的一篇博客中对这一问题进行了论述,并提出了一个评估代币价格的公式:

MC = TH

  • M表示代币供应总量
  • C表示代币价格
  • T表示代币交易量
  • H表示用户持有代币的平均时间

我们对VENA代币经济模型的设计目标是使代币价格C保持一个相对平稳的长期增长率,同时尽可能做大代币总市值MC/TH。这要求我们关注两个方面:第一,尽可能扩大代币交易量T并提高用户持有代币的平均时间H;第二,保持代币供应总量的增长率低于TH的增长率。在用户量快速增长阶段,代币交易量T同步增长,TH的增长主要由新增用户的T驱动;当用户量增长放缓甚至停滞,T和H开始呈现负相关关系,TH存在一个极大值。因此,在Vena Network的发展早期,做大VENA Token总市值最有效的方法是尽可能吸引更多新用户加入Vena Network,并鼓励用户持有更多VENA Token。只有当Vena Network发展到覆盖了大部分加密货币用户,并且整个加密货币生态的用户总数增长放缓,我们才需要考虑通过提高系统内部的流动性使TH向极大值靠拢。
  在充分考虑了以上因素后,结合Vena Network的使用场景,我们为洛书协议设计了非常巧妙并且独一无二的代币经济模型。在洛书协议设计中,存在一种特殊类型的代币交易——代币抵押。在VENA代币抵押过程中,我们仍可以将这些代币视为处于用户持有状态,因为市场上的流动性并没有增加。通过鼓励用户抵押VENA代币,我们提升了用户对VENA代币的需求,同时延长了用户持有代币的时间。我们将这种模型称为“使用即持有”的代币经济模型。显而易见的是,这种模型将极大地刺激VENA代币价格上涨,因此,我们需要设计一种代币增发机制以将VENA代币的价格上涨速度控制在一个合理的范围内。幸运的是,在洛书协议生态内部有丰富的场景让我们可以通过增发VENA代币来激励用户共同建设和维护Vena Network。4.2、4.3两小节列举了一些VENA Token的具体用例和增发场景。
  除此以外,我们还基于VENA Token模型设计了一个额外的生态激励机制。通过成立洛书投资基金,我们将投资于洛书协议生态内的企业和DAO,并将部分投资收益通过举办包括但不限于黑客马拉松等活动来回馈社区(详见4.6)。

4.2. VENA代币用例

  • 建立洛书认证洛书节点需要在洛书基金会抵押一定数量的VENA Token
  • 担任洛书认证陪审员需要在洛书基金会抵押一定数量的VENA Token
  • 用户使用VENA Token支付OTC交易手续费可以享受50%折扣优惠
  • 用户使用VENA Token作为抵押物借款可以享受50%的手续费优惠,并且获得更高的抵押率和更低的清算线
  • 使用VENA Token作为抵押物的借款订单将被高亮显示
  • VENA Token持有者可以参加Vena DAO投票,成为协议治理决策层的一员

4.3. VENA代币增发与奖励池

  VENA代币初始发行量为10亿枚,同时设立奖励池,初始奖励池由基金会出资成立。此后每年都会有一定数量的增发,用以补充奖励池的不足,VENA代币增发量与Vena Network的运行状况密切相关,目前已经确定以下的增发场景:

  • 洛书陪审员做出恰当的仲裁将获得VENA Token奖励,奖励部分由奖励池发放,不足的由增发产生。若陪审员作恶将惩罚代币计入奖励池。
  • 黑天鹅事件发生时,立即执行强制清算并增发VENA Token补偿出借方以避免债务违约,增发的VENA将通过DAO组织统一确定,在不超过3个工作日内补偿给抵押方。
  • 如果未来需要增加任何VENA Token增发场景,需要向Vena DAO提交提案并通过DAO投票表决。增发行为将在该年度增发超过当年代币总量3%的情况下停止。

如果未来需要增加任何VENA Token增发场景,需要向Vena DAO提交提案并通过DAO投票表决。

4.4. Aragon DAO治理

  Aragon于2017年发布,是一款去中心化自治组织的操作系统。在Aragon上可以方便地实现一套简单易用的去中心化自治组织的基本管理组件。这些组件包括:代币分配管理,组织成员管理,⻆⾊权限管理,投票管理,众筹管理以及财务管理等。Aragon组织的行为很容易通过更改章程来定制。此外,Aragon组织可通过与组织合约交互的第三方模块进行扩展。

img

  VENA Token持有者可以通过Aragon软件的投票模块对洛书协议的各方面提案进行投票表决,这些方面包括但不限于:

  • 洛书协议升级提案
  • VENA Token增发提案
  • Vena DAO委员会选举
  • 可信预言机集合修改提案
  • Vena Network全局参数(可抵押代币范围,抵押率,强制清算线,手续费率,可用法币转账渠道等)修改提案
  • Vena Network临时关闭和开启提案

  Vena Network最终能否被大众认可在很大程度上取决于能否在一个健全的去中心化生态系统中提高流动性。参与生态建设的角色不局限于VENA Token持有者,还可以是开发者,终端用户等。为了高效的广泛采纳建议,我们遵循分布式治理的理念建立一套标准决策流程托管至Aragon中,其中涉及到用Aragon Group进行成员和权限管理,用Aragon Finance进行财务管理以及其他的管理模块。
  随着AragonOS release 3.0的发布,投票管理成为了DAO治理更加灵活的入口,我们可以在ACL自定义参数化规则来处理不同的投票场景,也可以使用Forwarders将投票结果轻而易举地转发至不同的DAO管理应用程序。以下是一个自定义参数规则验证的程序示例:

function verifyCombinatedParams() {
    Param[] memory params = new Param[](7);
    params[0] = Param(LOGIC_OP_PARAM_ID, uint8(Op.IF_ELSE), encodeIfElse(1, 4, 6));
    params[1] = Param(LOGIC_OP_PARAM_ID, uint8(Op.AND), encodeOperator(2, 3));
    params[2] = Param(ORACLE_PARAM_ID, uint8(Op.EQ), uint240(new AcceptOracle()));
    params[3] = Param(BLOCK_NUMBER_PARAM_ID, uint8(Op.GT), uint240(block.number - 1));
    params[4] = Param(LOGIC_OP_PARAM_ID, uint8(Op.OR), encodeOperator(5, 2));
    params[5] = Param(0, uint8(Op.LT), uint240(10));
    params[6] = Param(PARAM_VALUE_PRARM_ID, uint8(Op.RET),0);

    assertEval(params, arr(uint256(10)), true);
}

  DAO的治理模型是多样化且动态调整的,AragonOS给我们提供了便利也给予了一定的安全保证。

4.5. 代币分配计划

  VENA Token发行总量为10亿,团队、顾问、私募、众筹销售、基金会和激励池等各部分的代币将由智能合约分配如下:

img

  • 团队和顾问:该部分占的VENA总发行量的15%,当VENA Token发行后有1/4立即释放;剩余的3/4份额将冻结1年,解冻之后的分配方式:1)顾问的剩余部分立即全部释放;2)团队部分的1/4一次性释放,剩余代币分12个月平均释放。
  • 私募:私募销售的VENA Token将分为两部分:1)未参与锁定计划的部分将在上市前2天内分发到参与者的钱包中;2)参与锁定计划的部分将在上市后被锁定在智能合约中,再根据既定规则分期解锁分发至参与者钱包中。
  • 公募:该部分将在公开销售结束后,上市前2天内分发到参与者的钱包中。
  • 基金会:该部分的VENA Token将由智能合约托管并在2年内分月解锁,解锁资金的使用需要经过Vena DAO同意并在使用过程中进行细节披露。
  • 激励池:每年将从激励池中固定拿出1%份额的VENA Token奖励团队和社区开发者,持续奖励10年;剩余的5%份额将用于重要资源引入,包括但不限于人才,战略合作伙伴等。
  • 预留:在团队缺乏资金时通过DAO从预留份额中进行募资,或将预留份额划转至基金会的资金池来促进生态发展。

4.6. 洛书投资基金

  Vena Network的募资工作完成后,洛书基金会将从募集到的资金和基金会中的资金池分别抽资成立洛书投资基金,专门用于投资孵化洛书协议生态内的企业和DAO。投资的方向主要包括区块链底层技术,区块链协议与应用,洛书协议扩展等。洛书投资基金由Vena DAO委员会直接管理并配置专业的投研团队和投后管理团队。基金的部分投资收益通过举办包括但不限于黑客马拉松等活动来回馈社区,剩余收益将用于持续滚动投资。



5. 洛书协议生态

5.1. Vena Network整体架构

img

5.2. 陪审员网络

  智能合约可以通过控制链上交易来解决争端,但是无法控制链下交易。陪审员网络用于处理智能合约无法判断的情况,并将处理结果提交给智能合约。当用户在借贷或交易过程中申请仲裁时,陪审员网络将介入处理。陪审员网络的设计目标是通过经济激励建立一个分散的争议解决机制,这种机制避免了对单一仲裁机构的绝对信任,因此具有更高的安全性。整套仲裁软件运行在由以太坊和IPFS构建的基础设施之上。通过一个简单的用户界面,陪审员可以方便地接收争议双方提交的证据并做出仲裁。所有的仲裁记录都会被永久保存在以太坊区块链上,所有不可篡改的加密证据(由PageSigner生成)都由IPFS网络中的节点进行永久存储。

5.2.1. 陪审员申请

  要加入洛书陪审员网络需要首先向Vena DAO提交申请并提供身份证明材料,审核通过后需要参加洛书陪审员在线培训和考核。考核通过后需要与洛书基金会在线签约并购买一定数量的VENA Token抵押给洛书基金会。签约期内陪审员不得动用抵押代币。签约期满后若不再续约,洛书基金会将把抵押代币退还陪审员。

5.2.2. 仲裁流程

  • Phase1:用户发起仲裁申请,仲裁软件会向争议双方发出通知,要求双方在24小时内按照规定格式各提交一份加密证据(使用PageSigner,一个允许用户生成不可篡改的网页证据的Firefox/Chrome插件)以及其他补充证据(文字,图片,语音,视频等)。所有证据文件会被打包并签名后上传至IPFS网络中的节点存储。与此同时,仲裁软件会从签约陪审员中随机选取三名陪审员并通知他们进入仲裁准备状态(通过KYC信息校验排除陪审员自己仲裁自己的可能性)。陪审员必须在8小时内应答,如果超时不应答会被罚款X(抵押代币),仲裁软件会重新选择陪审员。整个流程必须在24小时内完成。
  • Phase2:陪审员接受争议双方提交的证据文件,校验签名后进行审查。陪审员还可以请求审查争议双方的KYC资料。为了避免共谋欺诈,陪审员之间不能够互相沟通,也不能与争议双方直接沟通。陪审员必须在8小时内完成审查并独立作出裁决(裁决可以是支持争议的一方或者无法判定)。如果陪审员超时未做出裁决会被罚款。裁决完成后仲裁软件会按照如下方式评判仲裁结果:
    • 如果三名陪审员支持同一方,则该方胜诉,仲裁结束。仲裁软件通知洛书内核合约仲裁结果。
    • 其他情况仲裁将进入Phase3阶段。
  • Phase3:如果仲裁在Phase2没有结束,那么争议双方提交的证据文件和三名陪审员的裁决结果将被提交给Vena DAO委员会进行最后裁决。Vena DAO委员会可能会要求争议双方提交补充证据,在必要时甚至可能要求与争议双方进行视频通话或者屏幕共享以确保裁决的正确性。所有的证据文件和视频材料都会被上传至IPFS。Phase3阶段没有固定时间限制,仲裁将持续至Vena DAO委员会做出最终裁决。

5.2.3. 经济激励与保证金

  为了激励陪审员正确行使陪审权力,陪审员需要在Vena DAO抵押一定数量VENA Token作为保证金。每次仲裁结束后,仲裁系统会根据每名陪审员的裁决和最终仲裁结果R对三名陪审员(A、B、C)分别进行代币奖励或惩罚,具体规则如下(+X表示奖励X,-X表示罚款X,0表示无奖惩):

裁决 奖惩
A B C A B C
R R R +X +X +X
R R ¬R +X +X -X
R R 无法判定 +X +X 0
R R 超时 +X +X -2X
R ¬R ¬R +X 0 0
R ¬R 无法判定 +X -X 0
R ¬R 超时 +X -X -2X
R 无法判定 无法判定 +X 0 0
R 无法判定 超时 +X 0 -2X
R 超时 超时 +X -2X -2X
¬R ¬R 无法判定 0 0 +X
¬R ¬R 超时 0 0 -2X
¬R 无法判定 无法判定 -X +X/2 +X/2
¬R 无法判定 超时 -X +X/2 -2X
¬R 超时 超时 0 -2X -2X
无法判定 无法判定 无法判定 +X/2 +X/2 +X/2
无法判定 无法判定 超时 +X/2 +X/2 -2X
无法判定 超时 超时 0 -2X -2X
超时 超时 超时 -2X -2X -2X

因A、B、C顺序无关,以上表格已经包含了三名陪审员所有可能的裁决结果组合。陪审员超时未裁决的情况事实上较少发生,因为这会导致该陪审员遭受双倍的代币罚款。

5.2.4. 退出机制

  陪审员在签约期内如果发生以下情况,将启动退出机制。

  • 陪审员主动申请退出:陪审员不在任何仲裁期内,可向Vena DAO提出退出申请。Vena DAO委员会经过审查后,如果确认该陪审员无任何不当行为,则通过申请并退还剩余的抵押代币和奖励代币。
  • 签约期内被罚款超过5次:将启动强制退出流程。经Vena DAO委员会审查后,如果确认该陪审员无其他不当行为,则强制该陪审员退网并退还剩余的抵押代币和奖励代币。
  • Vena DAO委员会认定该陪审员有明显的不当行为(如共谋欺诈):扣除所有抵押代币和奖励代币并强制退网,Vena DAO保留对该陪审员进一步追究责任的权利。

5.3. 洛书节点网络

  洛书节点网络的主要作用是促进Vena Network的流动性和提高全网的健康程度,并为用户提供全面的借贷与交易服务。洛书节点可以通过部署洛书协议开源软件或者自主开发洛书协议(基于洛书协议进行二次开发)实现来建立洛书所(洛书所是指能够通过洛书协议对外提供包括但不限于借贷、资产交易、信用评估、合约插件交易等服务的线上站点)并通过收取服务费获利。申请成为洛书认证洛书节点需要满足以下条件:

  • 认证洛书节点需要有经营所在地的数字资产交易或小额借贷运营资质,有公司实体和固定办公场地,有数字资产交易或小额借贷行业运营经验。洛书官方提供全套开源软件和二次开发技术支持(免费技术培训,工程师7*24远程技术支持)。首次签约三年。
  • 认证洛书节点需要按照 1ETH = 10000VENA 的价格购买 1000000VENA(首批,未来会随VENA价格的变化调整购买价格和购买数量),并抵押在洛书基金会中。签约期内洛书节点不可动用该笔保证金,签约期满后若不再续约,洛书基金会将保证金退还洛书节点。
  • 认证洛书节点需遵守经营所在地的法律法规和政策。如洛书节点出现违法违规行为,Vena DAO委员会有权对洛书节点进行罚款直至取消认证洛书节点资格。
  • 认证洛书节点需要确保交易软件完整实现洛书协议的所有规定并严格执行。任何不遵守洛书协议的洛书节点将会被罚款直至取消认证洛书节点资格。
  • 签约期内认证洛书节点不得申请退出。

5.4. 去中心化身份认证

  为了保证交易安全,用户使用Vena Network之前需要完成身份认证。传统的KYC/AML系统将用户身份数据保存在中心化的服务器上,这导致了严重的用户隐私泄露风险,并加剧了用户和服务商之间权利的不平等。我们希望将Vena Network用户数据的所有权归还给用户本人。为了达到这个目标,我们为Vena Network设计了一套去中心化的身份认证协议。用户可以在Vena Network上注册自己的身份,请求和发送证明凭证,安全地管理他们的密钥和隐私数据。

5.4.1. DID与DID文档

  我们的身份认证协议设计参考了W3C Credentials Community Group关于Decentralized Identifiers和Identity Credentials的工作 (参见https://w3c-ccg.github.io/did-spec/, https://opencreds.org/specs/source/identity-credentials/) 。身份由分散标识符(DID)标识,并指向一个DID文档。DID及其关联的DID文档的组合形成分散标识符的根记录。
  Vena Network目前支持的DID生成方法如下所示:

vena-did = "did:vena:"vena-specific-idstring
vena-specific-idstring = network":"address
network = "mainnet"/"ropsten"/"rinkeby"/"kovan"
address = 40*HEXDIG
  • network将首先支持以太坊的"mainnet", "ropsten", "rinkeby"和"kovan",但可以在未来扩展以支持任意以太坊实例(包括私有实例)以及其他区块链网络实例。
  • address为HEX编码的区块链网络中的用户地址(不带0x前缀)。

  DID文档必须是单个JSON对象,此JSON对象的格式是在JSON-LD中指定的。JSON-LD是一种用于将JSON数据映射到[JSON-LD]定义的RDF语义图模型的格式。一个基本的DID文档示例如下所示:

{
  "@context": "https://github.com/venanetwork/vena-connect/vena-did-v1.jsonld",
  "@id": "did:vena:mainnet:d278018404b0889326f1799beecf8724b61d691e",
  "@type": "Person",
  "name": "Bob",
  "email": "bob@vena.network",
  "born": "1990-01-01",
  "credential": [{
    "@graph": {
      "@context": "https://w3id.org/identity/v1",
      "@id": "http://example.gov/credentials/3732",
      "@type": ["Credential", "PassportCredential"],
      "name": "Passport",
      "issuer": "https://example.gov",
      "issued": "2010-01-01",
      "claim": {
        "@id": "did:ebfeb1f712ebc6f1c276e12ec21",
        "name": "Alice Bobman",
        "birthDate": "1985-12-14",
        "gender": "female",
        "nationality": {
          "name": "United States"
        },
        "address": {
          "@type": "PostalAddress",
          "addressStreet": "372 Sumter Lane",
          "addressLocality": "Blackrock",
          "addressRegion": "Nevada",
          "postalCode": "237842",
          "addressCountry": "US"
        },
        "passport": {
          "@type": "Passport",
          "name": "United States Passport",
          "documentId": "123-45-6789",
          "issuer": "https://example.gov",
          "issued": "2010-01-07T01:02:03Z",
          "expires": "2020-01-07T01:02:03Z"
        }
      },
      "signature": {
        "@type": "LinkedDataSignature2015",
        "creator": "https://example.gov/keys/27",
        "signature": "3780eyfh3q0fhhfiq3q9f8ahsidfhf29rhaish"
      }
    }
  }],
  "signature": {
    "@type": "EcdsaKoblitzSignature2016",
    "created": "2016-10-23T05:50:16Z",
    "creator": "ecdsa-koblitz-pubkey:020d79074ef137d4f338c2e6bef2a49c618109eccf1cd01ccc3286634789baef4b",
    "signatureValue": "..."
  }
}

  DID文档使用SHA256哈希值作为文件名,公钥加密后存储至IPFS网络中的节点。DID和DID文档的映射关系存储在由洛书认证的节点所维护的etcd集群中(将此映射关系存储在智能合约中会产生区块链网络交易费,考虑到初次创建身份的洛书用户大多并未持有以太币,这将显著提高用户使用Vena Network的门槛)。用户可以通过Vena DApp(WEB/Mobile)创建身份(DID文档)并与一个区块链网络的用户地址(DID)绑定,比如DID文档与以太坊地址"0xCA8222faf9169A41fc506b8517C495363D804b80"的绑定。身份创建成功后,用户可以授权某个洛书所访问他们的身份数据以完成KYC。身份认证成功后,洛书所将会向用户颁发数字证书。用户将该数字证书存储在DID文档中,并可在未来用于身份证明。

5.4.2. Vena Connect

  我们计划在未来(2019~2020)将洛书的去中心化身份认证协议升级为Vena Connect,比如一个允许用户可以使用唯一的DID登录所有的以太坊DApp,注册自己的身份,请求和发送身份证明凭证,发送以太坊交易,与任何他们信任的人分享数据,安全地管理他们的密钥和隐私数据的以太坊身份管理基础设施。一些其他项目,比如uport和kyc.legal也在进行类似的尝试,然而我们认为缺乏使用场景和用户规模基础的去中心化身份认证项目很难获得成功。而Vena Connect的发展将依托于Vena Network项目庞大的生态网络和严格的KYC要求。随着Vena Network用户规模的扩大,Vena Connect必将在金融,保险,招聘,电商,征信等领域获得广泛的应用。

5.5. 共享流动性池

  流动性(liquidity)是任何一个市场的“灵魂”,用户在有活力的市场中能够获得极佳的借贷或交易体验。因此,我们提供了一个共享流动性池来保持Vena Network中交易的流动性。共享流动性池主要有以下适用场景:

  • 如果一个洛书节点的流动性不足,他可以把自建节点上的挂单放到共享流动性池中,而其他的洛书节点可以把共享流动性池中的订单挑选至自建节点进行展示。如果订单成交,则俩节点将根据订单属性marginSplitPercentage的值按比例获取该笔订单的服务佣金。
  • 用户想在某洛书节点借贷非所在地流通的法币,该洛书节点可提供一种直接将订单转发至共享流动性池中的通道,促使该笔订单在其他符合条件的洛书节点处快速成交以提升用户体验。服务佣金依然由俩洛书节点根据订单属性marginSplitPercentage的值按比例收取。

5.5.1. 共享订单

  我们称洛书节点想要投放至共享流动性池中的订单为共享订单,其格式如下:

message sharedOrder {
  string originExAddr/DID;
  bytes rawOrder;
  uint8 marginSplitPercentage; // [1-100]; we will set a default value:3;
  uint8 v;
  bytes r;
  bytes s;
  uint256 nonce;
}

5.5.2. 微服务与集群

  在Vena Network中,共享流动性池以服务组织的形式存在。为了未来能够更好地拓展与升级服务,我们采用了微服务的架构设计。参与维护共享流动性池的节点需要抵押保证金并向洛书基金会提交服务器参数配置等相关材料,认证通过后方可加入服务集群。对于长期稳定提供服务的诚实节点,我们通过服务质量加权计费或按时计费等方式用VENA Token进行结算。
  从简单和安全的角度出发,为支持RESTful API访问和可选的SSL客户端证书认证,我们以etcd作为共享流动性池的主要技术实现。etcd是一个高可用的KV存储系统,可用于共享配置和服务发现。在其持久化层,主要维护的是服务列表和订单列表,服务列表用于洛书节点消费数据时进行服务查找,如洛书节点主动选单,热点账户配置等;订单列表是洛书节点向共享流动性池投放的订单集合,为了保证订单来源,订单列表中的每一笔订单都是用源洛书节点的私钥对除字段originExAddr以外的参数哈希进行签名得到。因此,挑选该订单的洛书节点也需要对其进行验签,如果验签不通过则反馈订单无效,集群服务会在订单列表中进行状态更新。在服务层,一般情况下是使用Pub-Sub模式广播Topic全局版本号的变动。所谓Topic全局版本号更新就是Topic指向的任意服务列表或者Topic指向的订单列表发生了变动,这个Topic版本号都会递增。接收到所订阅Topic版本号变动的洛书节点可向目标服务器请求服务。

var pubsub = new PubSub(),
    grab = function(shareOrder) {
        // do something
        putToEx(sharedOrder)
        ...
    };

pubsub.on('orderList', grab);
pubsub.emit('orderList', newOrders);

当共享订单数过高时,由于服务集群会长期追踪各个洛书节点的数据并对日志数据进行分析,因此我们可根据结论在集群中设置高性能节点以主动推送订单给流动性高的洛书节点的方式来提升撮合效率。

img

5.6. 可信预言机集合

  由于部署在区块链网络中的智能合约的主观性体现在对链内数据的访问,而对于链外数据只能被动接受。因此,我们需要一个可信任的实体——预言机(Oracle)来完成诚实数据的输入。预言机是区块链世界与现实世界沟通的桥梁,它提供了一个权威准确、不可篡改、稳定、并可接受审计的数据查询接口。在区块链系统中获取链外数据的一般性流程:智能合约会在预定的时间或通过事件触发让Oracle从链外的数据源获取数据并输入,然后智能合约按照获取的数据采取预设的行动。然而该过程的实现,我们要解决两个关键问题:1)共识;2)受信方。
  Vena Network采用声誉系统和流动服务机制来解决以上问题。首先,我们选取N个预言机组成混合网络,并让网络中单一预言机与数据源之间建立1:M的关系。其次,在数据源和预言机上分别设有声誉系统,对可信输入形成双层保障机制。最后,根据数据源和预言机的多次工作流的信用积累实行流动服务,以此形成正向反馈来提高数据查询与数据写入的效率。

img

  预言机网络和数据源都是动态的,它是实现流动服务的基础。每一个Oracle合约实例都需要在Vena Network中进行注册,并填充目标数据关键字,费用,保证金阈值,参与门槛等内容。在需要获取链外数据时,Vena Network会根据合约实例内容撮合需求方和Oracle,匹配成功后Oracle抵押VENA Token正式组成预言机网络。在共识阶段,先检查达成共识的Oracle数是否符合Oracle合约实例中的预设值,若符合,则进行Data Feed及分发奖励金;若不符合,则阻塞Data Feed进程且所有Oracle重试不超过有限K次向数据源获取数据并进行共识的过程,在重试的过程中,Oracle有权更新数据源并应该自身维护一个对数据源信用积分更新的列表来提高查询效率。若有限K次重试后仍然无法达成共识,则分以下几种情况处理:
  前置条件,预言机网络节点数N,共识节点数预设值C,其中C满足:

                    

  1. 当实际共识节点数N/2
  2. 当实际共识节点数N/3≦C'≦N/2时,所有预言机网络节点失去声誉点,并应主动更新自身所维护的数据源信用积分列表。
  3. 当实际共识节点数C'

img

  以下我们描述了Oracle合约需具备但不限于所列出的属性:

Field Type Description
charge uint64 Service charge, bounty.
deposit uint64 Prevent Oracle Nodes from doing evil.
reputation uint32 The credit threshold for participating in Oracles network.
sourceType string Keywords for reducing search scope and improving query efficiency.eg:"chaindata,UML".
oracleCount uint8 Expected number of Oracle.
agreeCount uint8 The number of Oracle reaching a consensus.
threshold uint32 Comprehensive assessment of Oracle and the list of data sources it maintains.

5.7. 洛书协议开源软件

  洛书团队将在未来提供以下(不限于)的开源软件:

  • 洛书节点SDK
  • 借贷与交易市场DApp
  • 借贷与交易市场H5插件
  • 陪审员仲裁软件
  • 场景插件合约交易软件



6. 协议安全分析

6.1. 法币转移风险

  Vena Network中的资产交易与借贷都实现了数字资产与法币之间的兑换。因此,在交易或借贷时,我们要考虑经常会出现的问题是区块链加密货币转移的不可回退性与许多法币支付方式可回退性之间的不匹配。常见的支付方式及其资金转移的回退性如下:

Payment Method Currencies Reversibility of Transactions
PayPal - regular Most world currencies Extremely easy to charge back. Also, since trading bitcoin is against their ToS, good luck disputing the charvenaack.
Paypal - personal Most world currencies If funded via bank, requires person to dispute the ACH, which may be more arduous. If funded via credit card, requires person to dispute the CC charge, which is pretty easy. Since there's no way to tell what the funding source was... it's a gamble. Also, if paypal account is reported stolen, paypal will probably attempt to claw back the money.
AliPay / Wechat Pay CNY There are reports of reversed AliPay payments can be found on the Internet.
Dwolla USD Since Dwolla amounts are funded via ACH, Dwolla will now reverse payments if the funds were the result of fraud. Additionally, Dwolla's Terms and Conditions now state that peyments received are subject to charvenaacks as the result of their internal dispute resolution process.
Credit / Debit card Any currency Extremely easy to charge back.

  针对这种不匹配性矛盾,洛书基金会将对认证的洛书节点所支持的法币支付方式做相关要求,必须选择符合地区法律监管,资金转移不可回退的支付方式(如Bank wire,MoneyPak,Webmoney,LavaPay,OKPay等)以匹配区块链资产转移的特性,从而实现广义程度上的交易原子性,防范欺诈等风险。

6.2. 预言机攻击

  洛书协议下的有效合约操作都映射到区块链全局状态的更改,即APPLY(S,TX) -> S'。而协议簇是由一组或多组有状态的合约构成,一个非正确性(虚假数据,乱序等)的输入就会使得非预期性结果永久被写入账本。有前后状态依赖的输入输出意味着具备有序性与逻辑性,这就对合约程序的鲁棒性和输入的正确性都提出了很高的要求。合约编写需要我们缜密的思考,良好的编码习惯及细致的审计工作。数据的输入需要保证数据源的可靠,在Vena Network中对于数据源的接入以及防止Oracle节点联合作恶,我们设置了应用层共识,声誉系统、抵押保证金、流动性服务等机制。在匹配需求是从外部行情市场进行喂价时,要考虑价格的波动和成交的及时性,Oracle之间未达成共识时的有限K次重试就可能会成为攻击点,我们会在保证系统安全的情况下根据流量监控等多重因素,设计出K值的动态调整策略以尽量减少K值并结合对数据进行剔除最值再取均值的处理方式来完成喂价。此外,针对特定的外部数据输入我们还设立了加解密预言机来保护数据和提升系统的安全性。

6.3. 中间人攻击

  中间人攻击主要发生在用户与服务器通信的过程中。在Vena Network中设有共享流动性池分布式集群服务和分散的陪审员网络。在共享流动性池集群中,洛书节点需要与服务节点直接通信,正常情况下两者在TLS连接下内容是加密的,第三方即使可以嗅探到所有的数据,也不能解密。但第三方即中间人可以与洛书节点建立连接,然后中间人再与服务节点建立连接,转发他们之间的内容,这时候中间人就能解密获取明文信息并进行修改。如果中间人截获洛书节点发出的共享订单,经篡改后转发至服务节点则导致大量垃圾交易被填充在共享流动性池中,进而使得其他洛书节点可能获取的是大量的无效共享订单。因此,洛书基金会将通过DAO给已认证的集群节点根据其DID颁发证书来防范此类攻击。在陪审员网络中,我们采用了内容推拉分离式设计使得用户与陪审员网络不直接交互,而是通过PageSigner等方式将证据的内容哈希上链存储,而陪审员主动提审证据,从而防范了中间人攻击。

6.4. 女巫攻击或拒绝服务攻击

  伪装成多个节点执行恶意行为称为Sybil攻击,它致使被攻击者承受多方伪装节点的虚假数据。而拒绝服务攻击即是攻击者想办法让目标机器停止提供服务。Sybil和DOS两种攻击模型经常能够组合出现,比如只需要20个女巫节点,DOS就能完全可以泛滥式攻击某P2P网络的数据库使其脱机,还能对网络上的所有流量进行归档。Vena Network 与以太坊、EOS等区块链平台存在安全性的从属依赖关系,比如在以太坊中工作量证明的目的之一就是使区块的创建变得困难,从而阻止女巫攻击者恶意重新生成区块链。在洛书协议生态中,陪审员、洛书节点、共享流动性池集群节点都经过去中心化身份认证,不存在攻击者可以通过只部署一个实体,向网络中广播多个身份ID,来充当多个不同的节点。此外,有关对共享流动性池的DDOS攻击可选用如蜘蛛系统等解决方案进行防御。
  还有值得我们注意的是,在抵押借贷的背景下,由于抵押率的存在且是浮动的,女巫攻击者的角色有可能是由借贷者扮演。攻击者的意图是根据抵押率以及对市场行情的分析,在适时使用大量欺诈身份发起借贷订单,待成交之后全部违约或故意逾期来获利。然而,现阶段洛书协议被设计成有担保债务,即使攻击成功也收益甚微,况且我们的要求是所有的债务/债权人都需要进行去中心化身份认证,所以不具备条件来发起女巫攻击。

6.5. Penny-Spend 攻击

  Penny-Spend 攻击是指攻击者通过发送大量微小金额的订单来浪费节点的存储资源或作为套利手段骗取VENA Token。洛书协议设计成“链下订单中继链上结算”的模式,那么在订单成交结算之前的订单合并是防范由于零成本的订单委托容易成为攻击切入口的有效措施(实际上,此为传统中心化交易所常见的业务模式)。但是,洛书节点本身可能会想通过发送大量垃圾共享订单来污染共享流动性池,关于此种做法,我们能够根据共享订单中的DID/originExAddr来追踪共享订单来源,在集群服务中对恶意行为进行监控,如有发现作恶则提交至DAO来取消该洛书节点的认证资格和没收保证金。此外,关于洛书节点通过刷量交易或借贷订单获取VENA Token的情形,由于洛书节点收取服务佣金是在上链结算之后,区块链网络交易的合法性也会经以太坊矿工验证,因此可以杜绝此类现象。

6.6. 信心攻击

  信心攻击是指攻击者利用典型的人类特征,如贪婪,不诚实,虚荣,机会主义,欲望,同情,轻信,不负责任,绝望和天真等对目标者实施诈骗。然而,信心攻击在Vena Network中的体现主要在于攻击者已经获取对手方的相关信息,并且分析数据来了解其弱点先行进行信任骗取(攻击者为了实行攻击,通常建立了样本库并进行过聚类分析,获取信息后只需与数据库进行匹配就可快速采取相应的攻击手段),再通过引导的方式让双方的交易在脱离洛书协议的场景下完成。为防范此类攻击,我们要求洛书节点在所提供的借贷或交易工具上呈现醒目的类似“请勿转移至Vena Network之外的环境执行交易或借贷”等风险提示。此外,就系统本身而言,我们设计了去中心化身份认证机制,具有高度的隐私保护性,攻击者想在Vena Network中获取目标隐私数据是困难的。同时,我们也倡议用户注意合理维护自身资金账户地址与社交属性App之间的弱相关性,提升自我隐私保护意识。

6.7. 智能合约代码审核

  回顾2016年6月17日The DAO事件,2017年11月6日Parity多重签名合约漏洞事件,以及最近的SMT、BEC合约的整数溢出漏洞事件等均造成了资金上的巨大损失。若不做好严格的代码审计和安全防护,生态建设就成为了一纸空文。因此,Vena Network的所有合约代码均会经专业的智能合约安全审计机构进行审阅和充分测试,届时还会提交测试报告及相关材料。
  考虑到协议的升级,Vena Network的部分组件有可能建立在Zeppelin_OS之上。Zeppelin_OS是用以安全地构建和管理EVM生态的智能合约应用的去中心化平台。它设有担保机制实现合约代码的管理与升级,同时还提供了一个用于攻击响应的工具箱来预防攻击,当遭遇黑客攻击时,Zeppelin_OS将被触发紧急暂停,恢复到之前未受影响的状态。
  我们相信,一系列严谨细致的研发工作将能为 Vena Network 的生态建设之路保驾护航。



7. 市场分析

7.1. 加密货币市场现状

  根据CoinMarketCap的研究,在2017年9月,加密货币的平均日交易量已经超过了40亿美元,加密货币市场的总市值已经超过了130亿美元。然而,与全球法定货币的交易相比,加密货币市场仍然很小。例如,国际清算银行评估的全球外汇市场日交易量为5.1万亿美元,根据加密货币目前的增长率,很可能在未来3年内就能达到与外汇市场相似的交易量。因为我们很快就会生活在一个以数字货币为主导的现实中。
  从市场反应和数据上看,2017年加密货币市场已经达到了政府无法忽视的规模,因此,越来越多的国家将会认可加密货币,并对其进行相关规范和立法,可见加密货币未来巨大的发展潜力。

7.2. 世界各国对区块链的态度

  总的来说,大多数国家对于加密货币和区块链技术的都持欢迎的态度,并且已经开始尝试推动加密货币的应用落地以及在技术上进行探索与创新:

  • 中国:虽然中国目前对加密货币的交易持保守态度,但是在政府层面上从未停止对区块链底层技术的研究。

2016年2月,中国的央行行长周小川表示数字货币必须由央行来发行,区块链成为研发数字货币可选的技术。
2016年12月,国家将区块链列入了十三五国家信息化规划。
2016年10月,工信部发布了2016中国区块链技术和应用发展白皮书。
2017年9月,中国人民银行等七部委联合发文认定ICO是一种未经批准的非法公开融资的行为,涉嫌非法发售代币票券,非法发行证券,以及非法集资金融诈骗传销等违法行为。

  • 俄罗斯:俄罗斯政府的态度比较复杂,俄罗斯之前禁止公民持有和交易比特币,但是对于区块链技术却非常欢迎。

2017年6月,俄罗斯总统普京接见了以太坊创始人Vitalik Buterin。
2017年8月,俄罗斯国家开发银行与以太坊基金会达成了战略合作。

  • 韩国:韩国对区块链目前持支持的态度,对比特币以太坊等数字资产在加强监管。

2016年2月,韩国央行在报告中提出鼓励探索区块链技术。
2017年9月,韩国金融服务委员会FSC宣布将如何对数字货币,比如比特币,以太币进行监管。韩国加大监管力度,对于洗钱,非法融资和其他数字货币非法交易进行调查。

  • 印度:印度作为人口大国以及软件开发强国,一直很重视区块链技术的应用。

2017年1月,印度的央行发布了一份全面的区块链白皮书,认为区块链对于印度发行数字货币的时机已经成熟。
2017年6月,印度政府委员会宣布支持监管比特币成立专门的任务组,创建监管框架计划短期内全面完成比特币的合法化。

  • 澳大利亚:澳大利亚比较注重区块链技术的应用和标准的制定。

2016年4月,澳大利亚标准局呼吁制定全球ISO区块链标准。
2017年3月,澳大利亚国家标准局根据国际标准组织iSO分配的任务,发布了国际区观念标准开发路线图。
2017年8月,澳大利亚政府宣布将数字货币,交易所纳入澳大利亚交易数据分析中心监管。澳大利亚证券交易所等均在使用区块链技术进行交易的测试。

  • 英国:英国是欧洲地区最早对区块链进行研究验证的国家。

2016年1月19日,英国政府率先发布了长达88页的《分布式账本技术:超越区块链》的白皮书,同时积极评估区块链技术的潜力,考虑它将用于减少金融欺诈降低成本的领域。
2016年3月,欧洲央行ECB在《欧元体系的愿景——欧洲金融市场基础设施的未来》这个咨询报告中公开宣布正在探索如何使用区块链技术为己所用。

  • 荷兰:荷兰央行发布观点认为区块链技术可以改善其金融业务质量。

2016年9月,荷兰境内成立区块链园区,由银行和金融公司合作开发区块链技术在支付和泛金融领域的应用。

  • 德国:德国在区块链新风口将抓住机遇与迎接挑战。

2016年11月,德意志联邦银行和法兰克福金融管理学院联合召开区块链技术机遇与挑战的大会,大会的主要目的都是对分布式账本的潜在运用展开研究,包括跨境支付跨行转账以及贸易数据的存储等等。

  • 美国:美国通过立法来支持区块链的发展。

2014年6月,美国加利福尼亚州州长签署了一项编号为AB129的法律文件,保障加州比特币以及其他数字货币交易的合法化。
2016年6月,美国国土安全部对六家致力于政府去管理应用的开发公司进行补贴。
2017年2月,美国亚利桑那州通过区块链签名和智能合约合法性法案。同月,美国医疗保健部门ONC以举办医疗保健黑客应用开发马拉松,将区块链技术应用到医疗保健领域当中。美国国会宣布成立国会区块链决策委员会并承认了区块链的潜力,呼吁发展区块链技术在公共部门中的应用,而在比特币的态度上,美国也是鼓励投资并实施严格的监管。
2017年7月,美国证券交易委员会SEC认定以太坊代币属于证券,发行方需要依法办理证券发行的登记。同月,美国商品期货交易委员会CFTC批准LedgerX与以加密币市场挂钩的期权和衍生品提供清算服务。

  • 日本:日本的态度非常积极。日本的央行自己在尝试一些区块链项目,在立法监管上主要是针对如何推动比特币等数字资产的应用落地。

2016年3月,日本内阁通过投票将比特币和数字货币均视为数字等价货币。
2017年4月1日,日本实施了《支付服务法案》,正式承认比特币是一种合法的支付方式,对于数字资产交易所提出了明确的监管要求。
2017年7月,日本新版消费税正式生效,比特币交易将不再需要缴纳 8% 的消费税。

  • 新加坡:新加坡的是一片区块链的沃土,该国总理李显龙公开督促新加坡金融部门跟上区块链技术的发展的步伐。因此,新加坡在对于区块链证券金融创新监管政策的开放程度远超亚洲其他国家。

2016年6月,新加坡金融管理局推出了沙盒机制Sandbox,只要任何在法律规定的受保护中注册的金融科技公司,在事先报备的情况下,允许从事和目前法律法规有所冲突的业务,并且即使以后被官方终止相关业务,也不会追究其相关的法律责任。通过这种沙盒的机制,新加坡政府能够在可控范围内鼓励企业进行各种区块链的金融创新。
  综上分析可知,洛书团队在未来发行代币时将会严格遵守世界各国目前的相关政策法规,先从对数字货币政策相对开放的新加坡发行,逐步向其他国家发展。

img

7.3. SWOT分析

img



8. 路线图

img

2018.Q2 白皮书发布 & 洛书官网上线
产品概念性验证&启动开发
启动全球社群运营,包括美国,中国,加拿大,澳大利亚,俄罗斯等国家
2018.Q3 启动全球公募
VENA代币登陆交易所
开放洛书节点申请
勾股 2018.Q4 于github开源洛书SDK
洛书节点官方试运行,模拟业务
洛书产品1.0发布
首家洛书节点入驻
调和 2019.Q1 洛书产品1.1发布
全面发展生态,开启城市合伙人计划,引入20+ 洛书节点
2019.Q2 洛书产品2.0发布
加速扩展全球业务,引入50+ 洛书节点



9. 团队介绍

  • CEO: 朱清

  电子科技大学最高荣誉“成电杰出学生”获得者,chainboard.io链博科技创始人。曾任著名Fintech公司冰鉴科技技术总监,设计并主导了风控一体化平台和信用大数据平台的研发。在互联网征信与互联网金融风控模型设计、微服务系统架构设计和研发方面有着丰富经验。并从2016年开始带领团队掌握并成功开发基于区块链技术的行业应用,参与上市公司的区块链项目运作。曾作为特聘技术顾问给多家上市公司提供架构咨询及设计,并在多个知名技术论坛上作为讲师分享主题。

  • CTO: 兰坚

  Hardrole联合创始人兼CTO,资深区块链工程师。爱好逻辑学与战略研究,有着丰富的互联网从业经验和深刻的技术洞见,曾在著名人工智能公司Hiscene负责云架构设计与产品开发。在区块链领域浸泡多年,熟悉区块链底层,多币种钱包和交易所等技术以及各类安全防护。此外,还参与了Metaverse Blockchain开发,是Core Team成员。目前正积极探索和解决区块链扩容,DAG偏序网络结构中的交易定序等研究方向的主流提案在工程实践方面的问题。

  • 运营总监:杜承颖

  新加坡南洋理工大学管理经济学硕士,厦门大学欧洲语言文学学士。拥有丰富的创业经历与运营经验,2017年创立SATORI BCC并担任CEO,于2018年出售所有股份实现创业退出。现从事初创公司全流程指导的创业孵化。

  • 首席战略官: 朱元飞

  自古英雄出少年,早在中学时代就凭借其在计算机/物理竞赛中的优异表现保送至上海交大试点班专攻计算机科学与技术。大学期间,主动休学创立了Moregg,在取得了不菲成绩的同时收获更多的是从零到一的成就感。毕业后在硅谷主要从事在线广告、市场营销、证券场景下的大数据和机器学习等算法方面的工作并在雅虎积累了丰富的数据分析与运营的经验。2016年参与区块链项目开发,是以太坊早期开发者。深耕区块链底层技术的同时,还参与了高性能的交易所架构设计,运营过ico代投平台Beico,出色地完成了系列基于智能合约的项目,如ENS等。2017年,于新加坡成立Satori,打造了一支专业的团队为基金和基金会提供海外合规等世界一流的服务,已服务和深度合作的伙伴包括IOST, ZJL, TNC等。

  • 商务总监: 赵震

  毕业于电子科技大学。曾在中国电子科技网络信息安全有限公司担任项目主管,主导管理了网络安全系统、密码通信设备等项目研发全流程,设备列装全国政府机构与军队。同时还负责了国家云计算密码应用白皮书、四川省政务云等项目的市场与项管工作,项目体量过五亿元。目前专注于从事区块链领域相关应用的产品研究与市场运营。

  • 产品总监: 王瑜

  毕业于电子科技大学。拥有丰富的互联网行业从业经验,曾就职于多个知名互联网企业,如网易云音乐等,主导的产品覆盖用户超1亿;熟悉PC、移动端产品用户特点,擅长前端后端、2B2C产品设计、数据分析,参与10余项目建设。

  • 海外市场负责人: 周海琴

  七年海外市场商务谈判与项目管理经验,曾在著名车联网企业迪纳科技全面负责海外市场业务,任职期间为公司引进千万级马来西亚运营商合作项目,首开国内车联网公司为海外运营商提供包括车联网大数据平台与硬件在内的一体化解决方案的合作案例先河。英语高级口译,曾在上海G20财政部长会议担任同声传译工作。目前专注于从事加密货币投资与区块链相关产业研究与市场运营,有丰富的海外商务与项目运营经验。



10. 顾问

  • 谷燕西

  DAEX首席战略官、基金会主席。美国德克萨斯大学MBA、圣母大学硕士、中国科技大学硕士和山东大学学士。前华泰联合证券信息技术副总监和数家金融服务公司COO。在中美的著名互联网金融公司均有着高层管理及研发的工作经验。曾在美国期权结算公司负责美国期权交易市场的唯一清算系统ENCORE的开发与运营工作。

  • 赵杨

  新颜征信COO,曾任职天翼征信副总裁,对电信运营商数据如何运用于征信和风控有着多年业务经验。他带领团队共同创立新颜征信,深耕大数据风控领域,凭借专业的产品及优质的服务在市场上迅速崛起。

  • 翟永超

  永辉云创首席架构师、SpringCloud中文社区创始人(bbs.springcloud.com.cn)、Spring4All社区联合发起人(spring4all.com)。东华大学硕士研究生,《Spring Cloud微服务实战》作者,深耕于Java生态及分布式领域,主要负责基于Spring Cloud的微服务架构落地,是Spring Boot/Spring Cloud的早期布道者,其擅长的技术栈涵盖Java后端、微服务架构、运维开发、系统监控以及区块链等,并活跃于线上线下的技术社区做相关研究与知识分享。

  • Shawn

  前网安部门反计算机犯罪小组负责人,前中信旗下互联网金融平台首席安全官,现任五百强金融公司信息安全负责人。到目前为止,Shawn已经有九年以上安全工作经验,已经获得了包括注册道德黑客 (CEH)、注册国际信息系统安全专家(CISSP)、注册国际信息安全经理(CISM)和注册国际信息系统风险控制和监控专家(CRISC)在内的多项信息安全行业顶级认证。尤其擅长企业信息安全数据治理、攻防技术体系建设、安全管理体系建设,精通ISO27001国际信息安全管理体系建设和中国计算机信息安全等级保护标准。



11. 参考文献

[1] W3C. JSON-LD 1.0, https://www.w3.org/TR/json-ld/, 2014.
[2] Jorge Izquierdo. The new operating system for protocols and DApps, https://blog.aragon.one/introducing-aragonos-3-0-alpha-the-new-operating-system-for-protocols-and-dapps-348f7ac92cff, 2018.
[3] BitcoinWiki. Payment methods, https://en.bitcoin.it/wiki/Payment_methods, 2016.
[4] Joseph Poon, Thaddeus Dryja. The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments, 2016.
[5] Vitalik Buterin. A Next-Generation Smart Contract and Decentralized Application Platform, https://github.com/ethereum/wiki/wiki/White-Paper, 2014.
[6] Nadav Hollander. Dharma: A Generic Protocol for Tokenized Debt Issuance, https://whitepaper.dharma.io/, 2017.
[7] Vitalik Buterin. On Medium-of-Exchange Token Valuations, https://vitalik.ca/general/2017/10/17/moe.html, 2017.
[8] Conner Fromknecht. Connecting Blockchains: Instant Cross-Chain Transactions On Lightning, https://blog.lightning.engineering/announcement/2017/11/16/ln-swap.html, 2017.
[9] Alex Evans. On Value, Velocity and Monetary Theory, https://medium.com/blockchannel/on-value-velocity-and-monetary-theory-a-new-approach-to-cryptoasset-valuations-32c9b22e3b6f, 2018.
[10] Matus Lestan, Joe Urgo, Alexander Khoriaty. district0x Network: A cooperative of decentralized marketplaces and communities, 2017.
[11] Shiliang Huang. Refusal of payment arbitrage attack -- An attack technique in OTC transactions and precautions for it, https://mp.weixin.qq.com/s?__biz=MzIxNTA0NDQzMA==&mid=2651798518&idx=1&sn=4e91bac98cea5bc600e8429f1af3a728, 2017.
[12] RSK Labs. Sidechains, Drivechains, and RSK 2-Way peg Design, https://www.rsk.co/blog/sidechains-drivechains-and-rsk-2-way-peg-design, 2017.

results matching ""

    No results matching ""