python智能合约编程 -- pyeos简介

pyeos的最初的目的是研究Eos的实现方式，添加了python作为智能合约语言。解释器最早用选用的是cpython，后来改用了更小更灵活更高效安全的micropython作为解释器。python的优势在上一篇文章中已经讲过了。但是要将python作为智能合约语言运行在eos上面，却并不是简简单单的wrapping一下C/C++的代码那么简单。智能合约会在所有的全结点中运行，这也就意味着如果智能合约语言的某些漏洞，例如缓存溢出漏洞，受影响的就不仅仅是单个账户那么简单了，还有可能会影响到运行智能合约的所有主机，这有可能是灾难性的。这就是为什么不建议智能合约设计得过于复杂的原因。复杂度越高，意味着越难维护，同时也面临更多的安全威胁。python从Guido van Rossum发布第一个版本的1991年到现在，已经有26年，可以说python已经是非常成熟的技术了。期间python是在不断的演化，也产生了很多的变种（例如micropython就是一个面向嵌入式的python变种）。可以说python已经聚集了一大批的人才，并且已经形成了强大的社区，这给python提供了强大的后盾。

为了满足智能合约对安全性的要求，还是要对python作出诸多的修改，以限制python在智能合约中的行为，具体如下：

• 不允许python智能合约代码访问文件系统。
  • 如果允许智能合约代码访问文件，那么智能合约就具有有破坏系统的能力，所以文件系统的访问是绝对要禁止掉的。
• 限制python智能合约的内存使用。
• 如果允许智能合约访问无限制的内存，那么恶意的代码就会消耗光系统的内存，造成系统的运行缓慢甚至崩溃，所以对内存也必须作出限制，原来的cpython要实现这个目标还有点小麻烦，但是改用micropython后一却都变得非常的简单，只要设定gc允许使用的内存就可以了。
  1、 限制python智能合约的执行时间
  这点也很好解释，如果不作限制，恶意的代码可以轻易的制造一个死循环，占用大量的CPU资源，让其它智能合约得不到执行，产生不了新的区块，并造成整个区块链系统的崩溃。目前的执行时间检测是在bytecode级别的，已经做到了非常的实时，但是仍然需要考虑针对一些可能比较耗时的C代码作进一步的优化，因为python最终调用的是C代码，有可能在解释执行某个bytecode的时候会消耗大量的CPU资源，而目前的检测机制还没有考虑到这点。
  2、只允许import指定的模块，避免一些不安全的模块对系统造成危险，将安全问题控制在最小范围内。
  3、不允许调用exec，eval这些执行代码的函数。
  如果允许智能合约调用自定义代码，那么将是非常危险的，恶意的智能合约可以通过加解密的方法来伪装恶意的代码，从而使恶意代码的分析和检测变得困难。显然，在智能合约中，这种情况显然是不允许发生的，所以必须杜绝恶意代码通过这种方式来攻击系统。

虽然以上的限制已经对python智能合约提供了比较完整的支持，但是并不能保证恶意的python智能合约代码完全不会对系统造成破坏。一个系统不论是多么的完善，终归是有漏洞的地方。尽管micropython已经被大量使用，解释器也已经很成熟了，但是相对来说仍然是比较复杂的，并且micropython并不是一种专门为智能合约而设计的语言，仍然存在是一些非可控的因素，但是这并不能成为我们不用python的理由。目前，已经有了完善的对python代码进行sandboxing的方案，例如 可以将python代码的执行放到一个如docker这样的虚拟机中执行。所以，在python代码的安全性方便，也不必过于担心。害怕问题的产生是没有用也是没有必要的，因为对策总是有的，要的只是选出一个最优的方案。将来也会对pyeos的python智能合约的代码的运行机制进行进一步的完善。

当然，除了上面的措施之外，在人方面，设立奖罚机制。对发现系统漏洞的开发者以适当的奖励，对恶意智能合约代码提供检出机制，加大作恶的成本，使作恶的成本大于收益等等方面的措施，也是很有必要的。

python作为智能合约的优势明显，并不能因为担心python的安全性就弃之不用。实际上，任何的智能合约都有其要面对的安全性问题，我们要做的是发现问题，解决问题，并作好解决未知问题的准备。