LOADING...
LOADING...
LOADING...
当前位置: 玩币族首页 > 行情分析 > 社区声音:Rholang —— 真正适用于区块链智能合约的编程语言

社区声音:Rholang —— 真正适用于区块链智能合约的编程语言

2020-02-28 RChain 来源:火星财经


Rholang是RChain上的智能合约编程语言,之前“只闻其声不见其人”不甚了解。前几天出了篇A Rholang tutorial的文档,闲暇之余拜读了下,随惊为天人 -- Rholang才是真正适合于区块链智能合约的编程语言。也许你会认为我夸大其实,且听我慢慢道来。

目前主流的编程语言,比如 C/Java/Phython 以及 Ethereum VM 中的 Solidity 等等,它们都属于冯诺依曼式(the von Neumann style)编程语言。计算机最初的理论模型来自于“图灵机”。“美的”研制了世界上第一台计算机ENIAC,其实是一台指令和数据混合输入的并行计算机。传闻当年冯诺依曼在曼哈顿工程中使用它帮助“美的”研制原子弹时,在使用过程中由于并行计算机复杂且易错的输入,才启发他有了后面那篇著名的101页论文,发明了冯诺依曼体系结构。

冯诺依曼体系结构将数据与指令分开,数据保存于内存中,由指令处理。本质上它是一种命令式串行计算机,由于逻辑直观且易于工程实现,成为了目前绝大多数计算机采用的事实标准。而后绝大多数编程语言实际上是对冯诺依曼体系结构的模拟,比如条件语句模拟跳转指令,变量模拟内存,因此这些编程语言都统称为冯诺依曼式。

冯诺依曼式语言继承了冯诺依曼计算机逻辑直观的优点,同时也将它的缺点一并带入。FORTRAN语言的主要发明人John Backus在获得图灵奖的颁奖典礼上做了一篇非常著名的演讲 -Can Programming Be Liberated from the von Neumann Style?其中就总结了冯诺依曼式编程语言的缺点:

Von Neumann programming languages use variables to imitate the computer's storage cells; control statements elaborate its jump and test instructions; and assignment statements imitate its fetching, storing, and arithmetic. The assignment statement is the von Neumann bottleneckof programming languages and keeps us thinking in word-at-a-time terms in much the same way the computer's bottleneck does.

简而言之,变量是冯诺依曼式语言中并行处理时最大的瓶颈。比如多个线程同时访问并修改同一个变量,为了避免出现某一个线程修改变量时的同时被另一个线程修改导致结果错误,通常需要加锁来保证只有一个线程进入临界区访问变量,这样做保证了变量的线程安全性,但同时也将多线程的并发访问转换成了多个线程的逐个访问,大大降低了吞吐率。特别是在CPU引入多核后,这种瓶颈带来的影响越来越明显-- 锁的使用以及线程上下文切换开销巨大,导致死锁等各种各样的问题,程序的吞吐量没有随着CPU核心数的增加而增长。

为了解决冯诺依曼式编程语言面临的并发问题,业界做了很多努力。

从OS级别的锁改为CPU总线级别的锁减少锁的开销 - CPU实现了多种Atomic原语尽量减少锁的开销lock-less数据结构的研发 - 巧妙而复杂的实现来降低对锁的依赖精巧而复杂的系统设计来避免数据竞争(data race) - 单线程多进程模型 / 事件驱动异步队列等等

这些都大大地改善了程序在多核环境下的扩展性问题。而区块链网络可以视之为一台拥有几万甚至几十万个CPU的超级计算机, 仅仅凭借这些治标不治本的努力来实现线性的可扩展性,冯诺依曼式编程语言捉襟见肘。 随着节点数量的增加,系统的处理能力到达一定的阶段不会再随着增加,从而产生瓶颈。而根本的原因来自于冯诺依曼式编程语言的自身--它不是一种设计用于concurrent环境下使用的编程语言

既然瓶颈来自于冯诺依曼式编程语言,为什么不从根本上去除它?而John Backus在论文的后面就提到了这个解决方法- 采用函数式编程语言。

Rholang做为RChain上的智能合约编程语言,正是函数式编程语言。从tutorial中的例子可以看到,Rholang不仅仅是一种函数式编程语言,它还有许多重大创新。

Concurrent Process

在Rholang中, process(进程)是一等公民。这里所说的进程不同于操作系统中的进程概念,它更加类似于erlang和golang中的process,属于RhoVM的绿色线程(Green Thread)。一个节点可以轻而易举地创建成千上万个process而不用担心OS内核线程上下文切换所带来的开销。
以tutorial中的下面这段代码为例,valueStore!(init)和for (@value <= valueStore)实际上是两个process,|操作符让它们并行(concurrently)执行。

3 contract MakeCell(@init, get, set) = new valueStore in { 4 valueStore!(init) | 5 for (@value <= valueStore) { 6 select { 7 ack <- get => valueStore!(value) | ack!(value) 8 @newValue, ack <- set => valueStore!(newValue) | ack!() 9 } 10 } 11 }

因为for (@value <= valueStore)中的<=操作符, 此句后面的花括号又是另一个的process。
|和<=在这里类似于erlang中的spawn或golang中的go,Rholang直接在语言层次上支持并发而不需要额外的函数调用!也就是说,Rholang编写的智能合约天生就比冯诺依曼式语言编写的合约具有更好的并行度(degree of parallelism)。

和Ethereum Solidity合约不同,Rholang编写的合约实际上是由很多process有机组合起来的reactive stream。合约中的process可以在多个节点上并行执行,而不再是某个节点将合约从头到尾执行一次。 这有点类似于Scala的AKKA框架,但RChain更胜一筹的是,合约是在动态变化的分布式网络节点上执行,在计算的过程中即使网络发生变化计算也能得以完成,而这背后的功臣来源于移动进程演算法(Mobile process calculi)。对于Rholang的开发人员来说,这些细节只需要了解而不需要在编写合约时过多的考虑,Rholang提供一套Unified的语法方案来隐藏这些实现细节。

Channel 与 Reflection

Rholang提供了channel, 这并不是什么新的概念, 它类似于erlang的mailbox或golang中的channel。 process通过channel来进行消息传递。在Rholang中,一切都是process,传递的消息也不例外,它实际上是进程的序列(serialization of process)。

但最为神奇的是,channel本身也能在channel中传递。这得益于反射(Reflection)的力量。

对于Java/C#程序员来说,反射一般被理解为通过程序化的方法对程序本身进行分析或者加载,那称之为结构化反射(structural reflection)。而Rholang的反射更进一步,称之为过程反射(procedural reflection)。通过过程反射,Rholang能够将channel转换为process从而可以让process在channel种传递。

继续看这个例子

1 contract @"CellDemo"(system) = new MakeCell in { 2 // Makes a single cell in which you can store values 3 contract MakeCell(@init, get, set) = new valueStore in { 4 valueStore!(init) | 5 for (@value <= valueStore) { 6 select { 7 ack <- get => valueStore!(value) | ack!(value) 8 @newValue, ack <- set => valueStore!(newValue) | ack!() 9 } 10 } 11 } | 12 13 // Cell usage. 14 new myGet, mySet in { 15 MakeCell(123, *myGet, *mySet) | 16 new ack in { 17 myGet!(*ack) | 18 for (@result <- ack) { 19 system!("print", result, *ack) | 20 for (_ <- ack) { 21 mySet!(456, *ack) | 22 for (_ <- ack) { 23 myGet!(*ack) | 24 for (@result <- ack) { 25 system!("print", result) 26 } 27 } 28 } 29 } 30 } 31 } 32 }

ack是一个channel,通过myGet它被传递到了MakeCell中,然后它被具象化(reify)为channel,MakeCell中的process利用它与其它process进行通信。初一看ack就像回调函数,但不要忘了,Rholang的channel是在分布式网络中传送消息。

从上面两个feature可以看到,不同于Ethereum和EOS的VM将智能合约在某一个节点上执行的方式,RChain的智能合约被分解为process在多个节点上并行执行,而channel将这些process有机地连接起来,所有这些对于合约的开发人员都是透明的。也就是说,RChain将去中心化的计算网络整合起来变成一台能够并行执行智能合约的超级计算机!这也是它能够实现无限可扩展性的基石!

形式化验证

形式化验证(Formal Verification)以往应用在硬件设计中更多些。出于成本的考虑,软件行业很少采用形式化验证方法。最近听说的也就是Linus打算在Linux内核采用形式化验证。而Rholang将自带形式化验证工具!形式化验证通过数学方法来证明代码中是否存在某漏洞或缺陷。与传统的软件测试不同,形式化验证能够证明一个系统没有任何可以想到或想不到的缺陷,这可以从根本上杜绝软件漏洞。由于区块链的不可修改性,安全的智能合约至关重要!

RChain还在紧张开发中,从目前的资料来看,RChain将会带来一场区块链的技术革命。让我们拭目以待,未来无限可扩展区块链必将有RChain的一席之地!

作者:++

本文来源:RChain
原文标题:社区声音:Rholang —— 真正适用于区块链智能合约的编程语言

—-

编译者/作者:RChain

玩币族申明:玩币族作为开放的资讯翻译/分享平台,所提供的所有资讯仅代表作者个人观点,与玩币族平台立场无关,且不构成任何投资理财建议。文章版权归原作者所有。

LOADING...
LOADING...