精选国内外互联网行业最新文章及报告,让网友获得最新的海内外互联网动态
当前位置:主页 > 站长资讯 > 草根故事 >

BTA | 李谱:区块链归根到底是一个程序,没有什么太特殊的!

2018-04-05 11:41 来源:站长之家用户 编辑:佚名

3 月 30 日~ 3 月 31 日,由CSDN、火星财经主办,中关村区块链产业联盟、柏链道捷、区块链大本营、TokenSky联合主办的区块链技术及应用峰会(BTA)·中国,在北京喜来登长城饭店盛大举行。

作为时下最热门的行业话题,区块链以其颠覆性的技术理念,正在对各个行业施以影响,吸引了全球技术圈、投资者、创业者的关注。为了深入理解区块链及其背后的技术本质,本次大会邀请了80+区块链技术领导人物、100+区块链投资商业大咖,就区块链的发展趋势进行探讨,让人们有机会全面了解这一全新的生态。

作为本届大会的重要嘉宾之一,Achain技术合伙人李谱在下午的会议中分享了题为《智能合约——构建未来信任的基石》的主题演讲。

李谱,Achain技术合伙人,致力于区块链底层研发及区块链应用落地,区块链领域开发专家,毕业于清华大学软件学院。加入Achain前,曾担任阿里巴巴资深工程师、傲游浏览器、UC浏览器研发工程师,拥有多年互联网开发经验。

在演讲中,他从技术角度非常干货的分享了智能合约的数据设计、存储、生命周期、交易整个流程。 他认为,智能合约总体设计原则最重要的四点是:

  • 数据设计

  • 区块大小 

  • 产块时间

  • 处理时间

在区块链现在面临的一些列问题中,他提出技术是区块链行业发展的直接推动力。而对于那些想入门又不敢入门的程序员,他想说,区块链解决的问题归根到底它也是一个程序,没有什么太特殊的。

以下为李谱的演讲实录:

大家好,我是来自Achain的李谱。Achain上线以来,一直致力于帮助开发者发布智能合约。迄今为止,运行在Achain上的智能合约已经达到 87 个合约之多。其中,这 87 个合约中涉及到金融领域、游戏领域等各行各业。Achain是建立在RDPOS共识机制的基础之上,大约每隔十秒产生一个区块。到目前为止,Achain产生了 210 万区块,七十万笔交易,40%是合约调用。以上的数据我们可以看到,智能合约对于Achain来说是至关重要的,下面我就开始智能合约的介绍。

智能合约是区块链底层技术中重要的一环

Achain分为三层:

  • 接口层,包括CMD、RPC和API

  • 逻辑层,包括NET、wallet、GLUA虚拟机、本地脚本以及合约

  • 存储层,包括内存缓存和物理DB

Achain最上面是接口层包括CMD、RPC和API,中间是逻辑层包括NET、wallet、GLUA虚拟机、本地脚本以及合约,构成Achain的业务体系。其中虚拟机、本地脚本以及合约这三个部分构成了Achain智能合约的体系。我们的虚拟机是基于LUA智能合约编写的,在里面进行一些改善来适用。下面是存储层,包括内存缓存和物理DB。如果Achain上运行的是智能合约,就会启动GLUA虚拟机进行计算,计算完成之后,存储到里面。

智能合约总体设计原则最重要的四点

 智能合约总体设计原则最重要的四点:

  • 数据设计

  • 区块大小

  • 产块时间

  • 处理时间

    设计一个智能合约是典型的虚拟机的应用,这里面要考虑的因素特别多,我在这里摘取最重要的四点,数据设计、处理时间、区块大小,以及产块时间。

    首先,看第一点数据设计,Achain能够提供一整套完整数据的存储和存取。

    Achain能够很方便的把数据从底层的数据库中取出来,组成虚拟机需要的数据,然后传给虚拟机,等到数据再传回来的时候进行存储。

    第二点,需要考虑区块的大小。

    我们都知道区块链是以区块为存储的,而区块大小是有一定上限的,这个大小是 10 兆。我们的数据不能过大,如果过大,所承担的合约调用数据会非常少,这样会直接影响到合约调用的性能。

    第三点,产块时间是指,区块产生的时间。

    对于我们来说,Achain产生一个区块大约是十秒钟。包含两部分内容,第一部分是三秒,用于全网同步;最后七秒,是留给合约调用。

    第四点,处理时间是指,Glua虚拟机执行合约的一个时间。

    留给合约调用的时间只有 7 秒,这个时间并不多,所以我们的处理时间就必须得尽可能的少,因此只能在七秒中做尽可能多的事情。

    这四个约束条件特别有意思,区块大小和数据设计,讲的是空间的问题;处理时间和产块时间,讲的是时间的问题。这两个问题是鱼和熊掌不能兼得,让处理时间和数据设计尽可能达到一定平衡。数据设计其实是跟这四个里面最重要的一点,因为数据设计不合理,会直接影响你的储备时间,影响合约调度的效率。

    合约数据的存储

    数据设计整体的一个存储方案,是链上协同链下,链上存储动作,链下存储状态。链条上面有区块,而区块很小,需要同步,不能无限的存东西。我们把这个分到链下来,链下是一个资源相对来说还比较充足,因为我们可以发动全网。这样可以链下存储动作,链下存储状态,链下把连上的动作翻译成状态存在链下。在这个方案之下要面对一个最复杂的问题:容器类。容器类的特点是,能够添加数据。但总有一天会添加得非常大,怎么办呢?我们通过引用after来存储动作,实现增加条目、删除条目、修改条目。怎么理解?其实就是程序遇到before,把自己数据库里边关键字的条目删掉,再把after重新插一遍。有了这个增删改,我们把复杂数据的存储变成了一个动作,这个动作可以存在区块上。

    下面举一个简单的例子,这个例子中间是时间轴,在时间轴之上,表示的是链上,也就是区块;时间轴之下表示的是链下,也就是本地存储。然后上面我画了四个区块,这四个区块分别代表四种不同的操作。

    第一个区块,这个告诉程序,我要添加一种东西,因为before关键值里面有删掉,把after值加到里边,本地存储是空的。

    第二个区块,表示没有动作,没有动作链下就维持这个状态,'a':1、'b':1、'c':2,第二块用数据,应该用前一个区块生成的数据。

    第三块修改的是,before{'c':1}  after{'c':2},这样第三块链下的状态数据为'a':1、'b':1、'c':2。

    第四个区块是一个删除,删除'a':1、'b':1,after是为空,程序遇到这一块怎么办,首先找到'a':1,把'a': 1 删除,再找到'b':1,把'b': 1 删除,再看after是空的,只是删除掉这些。

    这样的两级存储,然后我们就把所需要的数据全部能够表示在链上,用动作表示在链上,我们可以看一下链上存在数据量非常小,beforo、after非常小了,链下非常大,提供给虚拟机。这就是我们链上加链下结合的存储。

     给虚拟机提供数据,以及数据存储的问题,这里面还有一个调用虚拟机返回值的问题。在区块链里面这个问题变得很复杂,因为在区块链里,调用者只是负责把这个交易创建了,其他不做任何事,对于RDPOS共识机制,只负责处理交易,而处理完之后,有的业务是需要有返回值的,返回值又不能够直接返回,直接返回代价太大了。

    我们应该采用一种什么方式来解决这个问题?

    我们采用把返回值也上链。在本地写一些脚本,这些脚本接收链上的信息。当返回值上链,本地同步到这个区块,解析以后发现有关系的返回值,调用本地的脚本,间接得到返回值,这就是PPT第三个描述的主动扫描得到合约的调用。

    怎么实现?

    有两方面:

    • 在虚拟机层面,需要支持这种语法

    • 链上需要开辟一片空间

    通过这种机制解决了调用合约返回值的问题,从而解决了虚拟机一个存储比较大的问题。

    合约操作的设计原则

    数据的正确性

    我们要设计一整套完整的,进行操作,这个操作能让数据正确的流转,这个是基本的条件。

    生命周期的完整性

    因为我们设计合约的初衷是让合约有一套完整的流向,生命周期的完整性是我们比较注意的。

    操作便利性

    不应该设置太复杂。

    合约的生命周期及特点

    经过以上三点的设计原则,我们得到了如下合约的生命周期:

    • 编译合约

    • 注册合约

    • 调用合约

    • 销毁合约

    • 升级合约

      编译合约

      编译合约是本地操作,需要启动虚拟机,编译完了以后,就可以上链。

      注册合约

      注册合约的意义是把编译的合约自解码上链存储,方便以后调用。

      调用合约

      注册完的合约成为一个临时合约,成为临时合约可以被调用。调用合约,是最常用的操作。

      销毁合约

      销毁合约的结果是链上看不见合约,不过这是逻辑层面。

      升级合约

      我们都知道区块链是不可篡改的,对此,升级合约就比较重要了。对于临时合约,可以被销毁,也可以被升级。一旦被升级以后就常住链上,永远不会被销毁掉。这个升级合约也是链上操作启动虚拟机制,是我们Achain合约对外的接口。

      合约交易与普通交易的流程

      合约的交易流程大体上分为三个步骤:

      第一个步骤,创建

      创建其实是由全网任何节点来做。在本地创建一笔交易,包括创建交易、签名交易、广播交易,通过P2P的网络进行广播。

      第二个步骤,产块

      产块包括确认交易、组织数据、执行合约。

      确认交易

      确认交易其实确认两方面,第一方面就是验签名,签名是否合理?是不是真的?验钱数,这是普通的交易。第二方面,如果底下交易是一个合约调用,就需要代理进行确认交易。

      组织数据

      我们要给虚拟机方便的提供数据,要通过链下,把状态数据抽取出来,然后给虚拟机。

      执行合约

      在虚拟机中执行组织好的数据,执行合约。

      第三个步骤,广播

      产块时间到了,就要把所有交易打成一个数据结构,然后把代理的签名信息打上去,进行广播,最终到全网。创建者作为一个普通节点或代理节点,广播这样的话就完成了普通交易的全流程。

      尚需优化的内容

      合约整体还不是特别完美,还有优化的空间:

      • 存储粒度细化

      • 二级缓冲

      • 经济模型

        第一点,存储粒度还可以继续细化

        虽然说虚拟机支持比较复杂的一系列的数据结构,但是那种复杂的结构,单条操作概率大于所有操作,那我们就把全量数据给虚拟机。我们有一种办法,能够很方便的抽出单条数据给虚拟机。当虚拟机需要全量数据的时候,我们可以花费一些时间组织全量数据给它。

        第二点,二级缓冲

        二级缓冲其实是为安全性考虑的。普通节点创建并发布整个流程,代理有很多事要做,所以我们需要做一个二级缓冲。任何一个节点在发送交易的时候,首先要去查一下代理是否有空闲?如果没空闲,可以先把交易缓冲在本地。代理有空闲的时候,我们尝试广播出去。这样做的本质其实就是,把全网节点缓冲的能力都利用起来。

        第三点,经济模型

        现在的经济模型看起来有点粗糙,经济模型其实跟存储有关系的。我们把存储力度细化以后,存十条数据,其实跟存一条数据,所消耗的gas是不一样的。

        技术是区块链行业发展的直接推动力

        我还是想说一点题外话,经过这两天的会议,大家应该都能感觉到,区块链发展到现在还是处于很稚嫩状态。它还有很多问题没有解决掉,比如说存储、性能。如果把这些问题解决掉的话,那么区块链才能够真正的往前迈进一大步。而解决这些问题需要大量的基础人员参与,我的观点,技术是区块链行业发展的直接推动力。从现实的情况看,其实区块链行业组建人员实在是太少,在太少人中间程序员又太少,这些问题都需要大量的程序员花大量的时间来研究。

        我最近也跟很多程序员聊过,我也是做程序员出身的,程序员对区块链的一种看法认为搞不定区块链,学习曲线太陡峭了。而我想告诉那些想入门又不敢入门的程序员,区块链解决的问题归根到底它也是一个程序,没有什么太特殊的。

        最后我用一句话来结束我今天的演讲:

        “区块链不仅有眼前的token,还有技术和远方的代码”。


        标签
        你喜欢的文章
        返回首页
        扫描微信
        返回顶部