Wisdom Chain内核设计理念(一)验证式规则编程

2020-03-04  本文已影响0人  WisdomChain中文社区

区块链的概念始于比特币,到今天为止,至少也有10年以上的历史了,一份比特币白皮书;一份比特币程序,开启了区块链的时代。这些年来,涌现了一轮又一轮的设计思想,光是共识机制,就衍生出了若干种,经济模型的设计更是百花齐放。整个社区,都为一次又一次新概念的出现而欢呼。

纵观计算机发展史,除了早期的集成电路的出现以及后来的互联网浪潮,很少有一门技术产品能引起全社会讨论的热潮,并且横扫世界各国的政府、金融机构以及实体产业。讨论的话题从技术到经济,再到场景应用,再到价值思想,可以说是涵盖了相当广泛的范围。

可惜的是,就像早先的宗教一样,作为区块链概念创始之初是比特币,其创始人也一早就消失了,这就带来一个问题,后世之人对其中的思想可以产生各种解读,而由于“圣人”不在,概念见地林林总总,因此谁也说不了谁,犹如基督教分为天主教、东正教和新教;伊斯兰教分为什叶派、逊尼派,虽说同宗,却是很不同的分支,在一些思想上甚至产生了相悖,这也算是一种分叉吧。

本文所要讨论的话题,便是与智能合约相关的理念。就区块链系统来说,智能合约的概念并不是一开始就有的,比如在比特币中就没有智能合约的概念,只有支付指令的概念,是一种较为简单的逆波兰表达式,用于实现比特币所有权的验证转换。

早期基于比特币的其他竞争币也同样没有智能合约的概念,只是改改共识算法或者密码算法,基本上换个马甲就上路了。智能合约的概念是从以太坊开始的,以太坊认为,既然比特币中的转账是通过一组指令完成的,那为什么不把这个指令的功能范围扩大呢?

比如不但能实现固定的转账支付,还能实现其他各种自定义的功能,将指令的功能定义交给用户,让用户来编程实现,区块链虽然是新颖的技术结构,但是自定义编程可是很成熟的,在计算机领域,主流的编程语言和环境相当多,比如java/javascript/c++/golang/c#等等,随便移植一个都能用来实现用户编程的功能了。

以太坊将移植到区块链上的编程功能称之为智能合约。为了统一称呼简单的逆波兰表达式和智能合约,我们一并称之为脚本系统。由于以太坊的带头,后续很多系统都效仿移植其他的编程环境到区块链中,比如NEO移植C#的语言环境;EOS移植WebAssembly语言环境,Fabric移植golang语言环境,等等。脚本系统分为了两派,以比特币为代表的硬编码指令结构以及以太坊为代表的图灵完备语言环境。

这两种做法就像什叶派与逊尼派,同宗而不同路,我们这里不去分析那些形而上的意识形态,就纯粹站在技术角度来简要的对比剖析一下,并且给大家介绍WDC(WisdomChain,中文:智慧链)是如何设计的。

先来说硬编码指令结构,我们来列举其特点:

1、功能固定,方便用户理解与使用

2、校验可以做的很完善,增强安全性

3、整个系统的功能是有边界的,易于设计专注的系统

4、编程实现可以测试所有可能的功能方面

5、符合KISS原则(Keep it Simple,Stupid)

那么,智能合约设计又有哪些特点呢?我们也来列举一下:

1、功能可扩展,支持用户灵活编程

2、充分发挥编程语言的能力,编程语言有的,智能合约全都有

3、无限发挥“合约”的理念和应用空间

4,吸引程序员开发应用生态

5、突出智能合约中的“智能”

以上就是两个宗派各自的特点,乍看一下各有千秋,很难说谁更好一些。那么,我们来使用象限法分析一下,任何一个脚本系统,其本质无非就是为了实现一组功能,并且这样的一组功能是施加在区块链网络而运行的。我们可以给出一对指标坐标,分别是灵活性和安全性。不妨假设x为灵活性,y为安全性,可见坐标系如下:

如图所示,(不安全,不灵活)自然是最不好的,两头都不占;(不安全,灵活)也是有问题的,如果一个系统都不安全,还会有人愿意使用吗?那么,可选的就只有(安全,不灵活)以及(安全,灵活)了,理想情况下,当然是要选择(安全,灵活),然而有没有这样的脚本系统呢?

显然这是很困难的,传统的语言系统并不是为区块链场景而设计的,更多的是作为一种通用的编程环境,强调灵活性而功能强大,语法设计灵活多样化,语义丰富,这就使得如果要实现一个安全的程序编程,更多的是要依靠开发人员的水平,类似于我们的自然语言,能不能表达出富有哲理的话语,能不能写出华丽的文藻,不是取决于文字的设计,而是取决于用的人的水平,律师可以写出滴水不漏的法律协议合同;作家可以写出隽永的散文诗篇;科学家可以写出逻辑严密的学术论文,然而,绝大多数的普通人是没有这个水平的,编程语言也一样,即便再怎么进行裁剪设计,由于先天的灵活性和多样性,使得程序员的编码行为不容易控制。

这些年,我们时时可以看到有各种基于智能合约的资产被盗,或许是因为合约程序编写有漏洞;或许是因为执行合约代码的虚拟机出问题等原因。更要命的是,由于保有了灵活性,使得脚本程序的功能设计完全没有边界,这就导致系统无法从机制上,从技术上彻底的杜绝有问题的合约程序部署到链上。

我们无意去攻击那些系统的设计缺陷,然而技术是需要进步的,比特币可以成为先行者,但是先行者接下来的路需要后来者去走。区块链设计的目的是为了实现一个所谓的灵活的编程环境吗?

当然不是,我们之所以信任公链,信任区块链上的资产,是因为安全性、公证性、不可篡改性是其重要支撑,如若不然,便没有了存在的意义了,这些是价值支撑的根本,是我们要解决的主要矛盾,其他的在这个主要矛盾之前,都是可以退而求其次的。

那么,WDC (WisdomChain) 是如何设计的呢?是剩下的那个(安全,不灵活)吗?其实这么说也不完全,从上述象限法中的几种情况来看,BTC处于第二象限,ETH、EOS处于第四象限,WDC ( WisdomChain) 处于第一象限,以下我们就简要的剖析下WDC(WisdomChain)中的实现方式。

首先,WDC(WisdomChain)的设计哲学是否定智能合约的理念的,什么叫合约?就是双方或者多方约定了一组协议,并且遵照协议去执行,这叫合约。这是一种商业倾向的称呼,不同的商业实体之间有不同的合约约定,很多都是与业务相关的,放之于链上,一个业务级别的合约,如何在技术上来无误的执行呢?

这个是没有保证的,举个例子,合约程序中实现了一种资产,然后设置一个管理员,管理员拥有权限可以增发、销毁、冻结用户账户的资产。请问,这样的合约符合区块链的思想吗?符合价值观吗?区块链的核心价值,如上所述,是安全、公证以及不可篡改,可是部署在链上的合约却可以实现单方面的增发、销毁、冻结。这岂不是自相矛盾,甚至是可笑的。

不但是资产合约,其他的也都是同样的道理,众筹、投票、交易系统,等等,都是可以有漏洞的,只不过有些漏洞明显,有些漏洞比较隐晦罢了。而更可怕的是,因为这些合约都是使用编程语言实现的,这完全不是一个普通大众能够去识别的,公链的使用者是公众,而公众能够阅读合约程序代码吗?遑论去辨别安全与否以及是否有隐藏的漏洞。

因此,WDC(WisdomChain)采用的是一种可阅读可识别的规则描述语句,是规则而不是合约程序,规则是一种静态的定义而不是一种可能存在不可知行为的动态程序。规则更是一种外部触发机制,而不是内部触发的不安全的设计。

总结下来,大多数系统的智能合约的实现,基本包含如下的弊端:

1、缺乏对区块链资产定义的专门描述

2、过于灵活的函数定义,不能保证脚本的安全性

3、语法元素太丰富,不够简化

4、针对以上的基本功能没有直接的语法语义支持

5、支持内部触发,不能确保安全

6、缺乏经济金融模型的直接支持

7、“执行”而非“验证”

8、不能很好的支持面向区块链的程序升级

WDC(WisdomChain)设计了专门的规则语法,实现了WDC(WisdomChain)所关注的功能区域,确定关注边界,是哪些边界呢?如下:

1、资产定义

2、多重签名

3、条件支付

4、存证

5、抵押

6、投票

一切脚本内核的设计,都是围绕着明确的功能边界来的,这就使WDC拥有功能专注点,专注才能更安全,更易于使用。

就规则的语法设计,是很简洁易懂的,如下所示:

<规则类型>

{

  //属性值定义

  //规则函数

}

I、属性值定义是指与资产定义相关的属性定义,属性值相当于就是状态量,是需要被存储到节点账本中的。

II、规则函数是一组验证规则,决定事务的调用以及验证点,符合规则验证后,会根据规则进行一系列的写入更新。

规则类型拥有固定的规则定义格式,节点核心在源码一级硬编码支持,因此,用户实际上只需要填充自己的属性值和规则中的动态的值,使用模板引擎的方式实现自己的规则。部署规则的过程也就是将用户自己的规则写入到区块,是通过一条特殊的事务来。

其中资产定义规则示例如下:

{

    "ASSET_RULE": {

        "code": "wdcc",

        "offering": 10000,

        "totalamount":10000,

        "create": "xxxx",

        "owner": "yyyy",

        "allowincrease": 0

        "info":{} 

    }

}

以上定义了一个代码为wdcc的资产, 初始为10000。并且具备3个主要是规则函数,分别是changeowner、transfer以及increased。

鉴于篇幅原因,本文不做详细展开,我们将以此来做一个系列篇,用以详细剖析每一个规则的具体设计。通过规则设计,在尽量保有用户有边界的灵活性的同时,强力确保安全性。

上一篇下一篇

猜你喜欢

热点阅读