聚焦区块链专员在过去的两篇文章中，跟大家聊了一下自己对区块链技术未来发展的一些看法，专员觉得，不论是共识模块还是加密模块，必定会朝着更加安全更加高效的模式发展过去，但是不得不承认，在路途中一定会遇到一定苦难，例如最近不断爆出的EOS以及ETH的bug，但是我觉得这些bug的出现，或许会造成一段时间的币价下行或者熊市，但是对于长期的发展，是一件很好的事情。
随着更多的传统互联网公司以及安全检测机构的进场，我觉得被爆出的bug一定会不断增多，虽然其中不乏一些蹭热度的机构以及公司，但是我觉得有些bug我们也必须得重视起来，因为有些bug如果是白帽子发现还好，如果是恶意的黑客发现，我觉得还是会造成一定的经济以及社会的影响，毕竟现在已经有越来越多的人来入场币圈以及链圈，我觉得作为项目方也有一定的责任保护这些人的利益。
但是大家发现其实EOS也好，ETH也好，很多的问题还是出现在智能合约的模块，之前专员在0学区块链模块说道过，智能合约是一把双刃剑，我们需要谨慎的处理并且使用它，它会给区块链带来很多的可能性，但是随之而来的它也会带来很多问题，尤其是安全问题。今天我们进来讲讲区块链在智能合约的发展，
专员觉得，可能首先专员觉得，虽然现在EVM仍然是主流的虚拟机，并且有许多的平台借鉴并且使用了EVM在自己的区块链平台中，但是我觉得EVM仍然有一定的局限性，熟悉Solidity的同学知道，其实Solidity在使用还是有比较大的问题存在，比如说他对于参数的限制等等，在EVM中，可能无法进行较为复杂的编程，虽然专员一直觉得智能合约不应该过于复杂，最经典也是最无可取代的智能合约也就是传说中的SetHash以及GetHash的方法。但是不得不说，有许多项目的确会有需求需要进行复杂的智能合约编程，这时你会发现Solidity这门语言会出现比较大的困难，许多开发的程序员更希望用日常的开发语言进行智能合约的编写，比如JAVA，GO，JavaScript等等。
另外，比如说Fabric，它并不是一个传统的公链项目，它作为一个优秀的联盟链的项目，它已经能够支持用Go语言进行智能合约的编码，称之为Chaincode(链码)，有感兴趣的同学可以去了解一下，专员看来也是一个不错的智能合约的解决方案，但是可能不适合现在的公链的情况，更适合联盟的情况，但是不失为一种解决方案。
另外专员觉得，另外一个方面可能就是合约的安全方面的升级，不仅仅是虚拟机本身的问题，比如将虚拟机置于一个更加安全的沙盒环境中，并且禁用某些的系统指令等等，另外各重要的可能是对智能合约代码本身的代码安全的检查以及校验，比较过多的智能合约的漏洞已经被不断的爆出。比如现在已经知道的手段，形式化验证等等，说形式化验证的时候，就不得不说一下形式化方法。
它是形式化验证的基础，简单的说就是用数学工具进行定义、开发和验证。数学家们认为，不论硬件还是软件工程，就像世间万物一样，所有的学问一样，归根结底是数学问题。因此如果真的所有的系统的设计以及开发都能够按照严格的数学方法进行，那么可想而知的是我们所开发的系统就会像数学本身一样的完美，并且不会出错。当然，这是一个最完美的理想。但是这的确是一个很好的奋斗的方向，也是一个我们所希望能够出现的东西。
综上，专员觉得，其实事物都是在不断的发展的过程中，我们需要注意的是，在这些浪潮中懂得更多，并且学会明辨是非，这样才能更好的帮助我们判别一个项目的存在意义，以及未来发展方向。专员觉得，不管我们是不是一个技术人，在区块链这个圈子中我们还是要多多少少懂一点技术，这样才能有效的防止自己陷入空气项目中。
专员在过去的两篇文章中，跟大家聊了一下自己对区块链技术未来发展的一些看法，专员觉得，
不论是共识模块还是加密模块，必定会朝着更加安全更加高效的模式发展过去
但是不得不承认，在路途中一定会遇到一定苦难，例如最近不断爆出的EOS以及ETH的bug，但是我觉得这些bug的出现，或许会造成一段时间的币价下行或者熊市，但是对于长期的发展，是一件很好的事情，随着更多的传统互联网公司以及安全检测机构的进场，我觉得被爆出的bug一定会不断增多，虽然其中不乏一些蹭热度的机构以及公司，但是我觉得有些bug我们也必须得重视起来，因为有些bug如果是白帽子发现还好，如果是恶意的黑客发现，我觉得还是会造成一定的经济以及社会的影响，毕竟现在已经有越来越多的人来入场币圈以及链圈，我觉得作为项目方也有一定的责任保护这些人的利益。
但是大家发现其实EOS也好，ETH也好，很多的问题还是出现在智能合约的模块，之前专员在学区块链模块说道过，智能合约是一把双刃剑，我们需要谨慎的处理并且使用它，它会给区块链带来很多的可能性，但是随之而来的它也会带来很多问题，尤其是安全问题。
今天我们进来讲讲区块链在智能合约的发展
可能首先专员觉得，虽然现在EVM仍然是主流的虚拟机，并且有许多的平台借鉴并且使用了EVM在自己的区块链平台中，但是我觉得EVM仍然有一定的局限性，熟悉Solidity的同学知道，其实Solidity在使用还是有比较大的问题存在，比如说他对于参数的限制等等，在EVM中，可能无法进行较为复杂的编程，
虽然专员一直觉得智能合约不应该过于复杂，最经典也是最无可取代的智能合约也就是传说中的SetHash以及GetHash的方法。但是不得不说，有许多项目的确会有需求需要进行复杂的智能合约编程，这时你会发现Solidity这门语言会出现比较大的困难，许多开发的程序员更希望用日常的开发语言进行智能合约的编写，比如JAVA，GO，JavaScript等等。
智能合约的其中一个方向就是语言更加多样化
其实现在这种情况以及发送，比如现在EOS的WASM的虚拟机，WebAssembly是一种新兴的Web技术，使用C语言来编写WebAssembly模块，并将其编译成.wasm文件进行业务逻辑的执行。另外，比如说Fabric，它并不是一个传统的公链项目，它作为一个优秀的联盟链的项目，它已经能够支持用Go语言进行智能合约的编码，称之为Chaincode(链码)，有感兴趣的同学可以去了解一下，专员看来也是一个不错的智能合约的解决方案，但是可能不适合现在的公链的情况，更适合联盟的情况，但是不失为一种解决方案。
另外一个方面可能就是合约的安全方面的升级
不仅仅是虚拟机本身的问题，比如将虚拟机置于一个更加安全的沙盒环境中，并且禁用某些的系统指令等等，另外各重要的可能是对智能合约代码本身的代码安全的检查以及校验，比较过多的智能合约的漏洞已经被不断的爆出。比如现在已经知道的手段，形式化验证等等，说形式化验证的时候，就不得不说一下形式化方法。它是形式化验证的基础，简单的说就是用数学工具进行定义、开发和验证。
数学家们认为，不论硬件还是软件工程，就像世间万物一样，所有的学问一样，归根结底是数学问题。因此如果真的所有的系统的设计以及开发都能够按照严格的数学方法进行，那么可想而知的是我们所开发的系统就会像数学本身一样的完美，并且不会出错。当然，这是一个最完美的理想。但是这的确是一个很好的奋斗的方向，也是一个我们所希望能够出现的东西。
综上，专员觉得，其实事物都是在不断的发展的过程中，我们需要注意的是，在这些浪潮中懂得更多，并且学会明辨是非，这样才能更好的帮助我们判别一个项目的存在意义，以及未来发展方向。专员觉得，不管我们是不是一个技术人，在区块链这个圈子中我们还是要多多少少懂一点技术，这样才能有效的防止自己陷入空气项目中。
