伊斯兰金融需要一个什么样的公链?

原创
2002 天前
14026


引言


HLC 技术社区5月初的第一次讨论,在全球的公链爱好者中都激起了一次关于DAG(有向无环)技术的反响。其中有一个观点非常吸引人:BLOCK DAG是比特币创始人中本聪心中理想的扩容方案。那次社区讨论中,古典区块链共识POW(PROOF OF WORK)被重新赋以了技术的自信与合法性。在过去的几年里,POS ( PROOF OF STAKE)在全球的技术媒体里被议程设置为未来的方向,仿佛古典共识已死,就像一个国家的宪政结构里面,必须把全民公决让位于议员代理一样。HLC技术团队在决定开发公链时,就坚持了一个经典区块链共识的价值观并将之写入基金会的扩展章程。


5月18日,2019年的明星区块链项目HLC公链技术社区第二次沙龙上,对于DAG的混合协议讨论着墨最多。它回答了另一个商业问题:全球庞大的伊斯兰金融资产需要一条什么样的公链?很简单,HLC就是要为伊斯兰金融贡献这样一条公链。这个朴素的理想,实现起来却非常困难。这就是HLC公链为什么要提出经典区块链设定,也就是希望给我们心中的交易级公链做一个新定义,所以它最终确定了Block DAG方向。 此外,HLC根据伊斯兰金融的特点,HLC技术社区提供了一套更适合伊斯兰金融场景的公链解决方案,这就是为什么HLC最终选择了基于UTXO的交易模型,而非更热门的、适合做一层智能合约的账户模型。


 HLC 公链不是什么?


其实回答HLC公链是什么之前,最重要的是先回答HLC公链不是什么。 因为HLC的技术选型完全基于价值观和自己的哲学来设计,最终的选型会和当下舆论上包装的热门技术有一定出入,社区对于这个事情做过特别讨论。


HLC 公链不是PoS共识下的网络


近两年来,在商业利益的舆论推动下,经典的PoW被诟病为能耗巨大,部分项目甚至已形成内部人关联交易的PoS的出现,似乎天然代表着“政治正确”。HLC社区与技术团队看好PoS的发展以及在特定场景下的应用。但作为公链来说,HLC非常注重网络的开放以及公平的价值基础,目前,PoS共识下的的解决方案还是没有很好的解决这个问题。


HLC 不是一层的智能合约


现在,BlockDAG的协议已解决了交易全序列的问题,这样可以为支持一层的智能合约提供基础。这里的“一层智能合约”是指以太坊式的、基于账本模型、在公链层就可以支持的智能合约。事实上,HLC公链集成了支持交易线性排序的PHANTOM协议,是可以实现一层的智能合约的。


HLC也曾在是不是需要支持一层智能合约在技术团队内部进行过激烈的讨论。那时,集成一层智能合约的理由似乎很充分,它有更强的应用扩展性,尤其在以太坊的成功后智能合约更是成为新公链的一个入门选项,对于用户有较强的信心提振作用。不过,每当有重大技术方向决策时,HLC还是会回到从哲学观的角度思考,复杂的问题就变得十分简单。在智能合约的取舍问题,HLC技术团队认为,HLC的公链在商业定位上就是为伊斯兰金融这一独有金融体系设计的,它需要整合庞大的伊斯兰金融的价值,所以定位应该是一条价值流通网络。所以,保证公链简单、高效、稳定是首要的目标。


Block DAG虽然相对于区块链来说已经提供了更高的吞吐量,可以相当长时间承载价值流通的业务, 但是如果要承载复杂多变应用场景,BlockDAG的压力也会很大,相信很多人还对以太猫造成以太坊拥堵的事件记忆犹新。


HLC底层公链不是为应用服务的


所以在HLC的架构设计里面,底层公链从来不是为应用服务的,而是为价值流通和价值赋值服务,所以我们需要一条自由、公平、安全、高效的公链,也就是我们倡导的经典区块链设定。但是,对于应用这一块的需求,我们认为它更适合通过链下的智能合约实现。在应用这一层的共识协议,考虑到跟商业场景对接较多,HLC会采取更加宽松的策略。所以在每个应用可以根据自身的业务需要选择更适合自身的共识协议,不必严格遵守经典区块链设定,所以PoS, 甚至类PoA的DPoS都可以有很好的施展空间。


Block DAG的混合协议


HLC底层公链的定位是价值流通网络,因此,经典成熟的UTXO的交易账本模型就成为不二之选。UTXO的账本是一个DAG图,结构简单优美, 每笔交易由多个输入和多个输出, 输入指向交易产生时还未花费的交易的输出, 而输出也可以被未来的交易花费, 依此类推,而不断地延展。


确认了UTXO模型


从UTXO的账本结构我们可以看出,UTXO其实并没有账号, 某个地址(可以理解为账号)的余额是通过将所有输出指向该地址的UTXO的金额总和。 没有账号自然也就没有基于账号的各种状态比如余额,所以,无法实现基于类似以太坊那样的基于状态的智能合约。但是由于无状态的特点, UTXO的确认速度可以做到很快, 因为只要不存在双花, 对于并发的交易UTXO并不关心谁先谁后, 只要保证输出是没有被花费的就可以确认了,而给予状态的账本模型是需要一段时间保证这些并发在全网达成共识.


所以,这里存在交易确认时间和交易线性全排序的一个矛盾, 而交易线性排序是智能合约的基础, 又可以简单理解为到底是优先确认时间还是优先智能合约. 智能合约意味着更强大的扩展能力, 但是确认时间对于交易系统来说的体验至关重要. HLC 技术团队综合考虑了下如下因素, 还是选择了可以支持更快确认速度的UTXO模型, 目前确认速度最快的BlockDAG是SPECTRE协议。


HLC的底层公链的定位是价值流通网络, 希望可以承载伊斯兰金融的各个场景。所以一个稳定安全高效的交易模型是首选, UTXO模型目前已经非常成熟, 比特币已经稳定安全运行了十年, 又简单非常好维护.


按照HLC的技术架构设计, 无论底层公链支持交易线性排序与否, HLC公链底支都不会支持一层的智能合约。从复杂度看,这意味着维护成本增高, 故障风险增大; 从性能看,某此系统可能会被某些热门应用给拖垮, 类似于以太猫这样的应用, 如果这种现象很多, 即使是最快的DAG网络也承受不了;从公平性看,即使HLC的DAG能够承载热门应用, 但是应用本身要占据全网的资源, 但是这些应用本身的投入相对来讲是可以忽略不计的, 这样就很不公平;从灵活性看,应用完全可以使用自己的共识协议, 也可以是偏中心化的。


确认了SPECTRE协议


SPECTRE协议是目前公开的Block DAG协议中确认速度最快的。根据DAGlabs的官方的实验室测试数据:假设对于10%左右的作恶节点, 风险系数是1%, 假设传播时间是五秒传遍全网大多数节点(这也是比特币的白皮书中的测试方案, 方便进行横向比较)。这时, 比特币需要一个小时才能达到安全确认, 而SPECTRE在出块率为10的情况下可以在十秒左右达到安全确认, 效率是比特币的600倍, 这么快的确认速度, 即使是日常的小额支付都是可以接受的.


HLC的技术团队采用的是混合共识的协议, 也就是说除了SPECTRE之外, 还存在一个DAG协议, 这个协议就是GHOSTDAG, 也可以认为就是PHANTOM协议, 具体有点不太一样, 不赘述。 GHOSTDAG 是支持交易的全排序, 所以说HLC公链如果有必要的话是可以支持一层智能合约的, 但是经过我们之前的分析, GHOSTDAG的确认速度相对SPECTRE有相当大的差距, 所以GHOSTDAG并不直接参与交易共识,而是作用在非常重要的奖励机制上面。


DAG协议的两个难点


DAG的一个难点在于实现公平又安全的奖励机制。不同于区块链, 一个区块只有一个所有者, 所以并不存在奖励发给谁而产生的分歧,但是Block DAG的区块会被多个矿工确认, 而且这个确认理论上的是无法截止的, 也就是说即使是一个很老的区块, 也可以再次被新的区块确认。 所以很难确定以某个特定的时间为截止, 然后再分配奖励。 SPECTRE论文给出了一个建议的方案, 需要矿工主动配合去产生新的交易赎回奖励, 这样的机制基于的设定过于理想化, 而且机制很复杂, HLC公链技术团队并没有采纳。


HLC公链更倡导的是一种竞争性的合作, 也就是说节点还是有一定的压力或者积极去做更多的贡献, 而非觉得在按劳分配的环境下,积极和消极从单位投入得到的回报完全一样, 所以消极地参与网络。 所以HLC采用的是每笔交易的手续费最终只会被最先确认的矿工所有, 但是确认的先后就涉及到了交易排序的问题, 所以才需要GHOSTDAG的支持。


DAG协议奖励机制的另一个难点在于:矿工是趋利的, 如果没有特别的惩罚机制, 矿工会优先选择交易费较高的交易;如果所有矿工都这么做, 交易的重复率会很高, 重复的交易对于吞吐量是没有任何贡献的。 DAGlabs的Inclusive给出一个建议的方案, 就是把交易费简单地平均, 这样矿工如果都选择交易费较高的交易, 最终平分得到的奖励会很少, 所以最终会选择随机地选取交易。 这样的随机机制可以将交易的重复率降低到30%左右, 已经非常理想了。


Inclusive 协议虽然解决了交易重复的问题, 但是也带来了一个更严重的问题, 就是把交易费的的作用给抹杀了。 每笔交易的重要性其实不一样, 理应被一定程度的区别对待。所以如果交易费高和交易费低的交易完全对等处理, 不仅会导致重要的交易无法优先处理, 也可能造成垃圾交易滥发;对于矿工来说吸引力也降低, 因为所有的交易最终都会只是基础交易费, 完全没有额外的动力。 HLC采用的是与Conflux协议类似的加权随机的规则, 也就是虽然也是随机选择交易, 但是交易费较高的交易更容易被打包进区块的概率更高.


说明一下,Conflux并没有在白皮书或者论文提到加权的实现方案, 目前也只是在博客或社区中有提到, 所以最终的实现方案可能会跟Conflux不一样。 HLC技术团队一直在这方面探索, 也许最终的方案会跟Conflux类似。 鉴于Conflux 提前公开发表, HLC表示尊重和感谢Conflux的提供的思想启发。感谢HLC技术社区志愿者的积极参与和思想的贡献。(DAG研究院)