EOSForce主网智能合约公测开发者答疑

原力fanyang:

这段时间(国庆节前)开发主要分为三个方向， 首先我们合并主网近期所有更新，其次是新的分红方案的开发，最后就是开放合约的一个短期方案。这些功能会 在节后经过测试之后更新 。

这里说一下合约，我们这次开放的是一个短期的方案。

在原力中，我们执行Action是收取手续费，而非像EOS那样分别使用cpu，net和RAM。对于系统Action我们这边使用约定的手续费费率来收取。

但是对于用户定义的合约，因为不同合约执行时消耗的资源，所以手续费肯定不一样，需要一个手续费的定价模型。

EOS项目中使用的模型是从按照EOS token去分配资源的切入点来设计的。

EOS这种模型的问题在于第一对于用户和开发者模型稍显复杂，第二cpu和net上由于使用EOS抵押就可以无限使用，就会出现一些"恶意"的合约对整个网络产生较大的压力。

前一段时间EOS那边增加了一些合约的黑名单来封禁一些被认为是恶意的合约，但这样其实非常不好。

对于原力来说，之所以一直没有开放用户定义的合约，就是因为我们在思考一个手续费模型。

首先需要明确的是，所有action的执行都是要消耗主网的计算和带宽资源的，所以手续费是一定要有的。

现在大家对于合约的需求还是比较急切的。所以我们这边制定了两套方案：

一套是可以快速实现的短期方案

一套是需要一定时间开发的长期方案

这边的计划是，在一定时间内先采用短期的方案，使得大家可以使用合约，而后，当长期方案完成之后，再使用长期方案取代短期方案。

这里我先描述一下两种方案。

对于原力来说，在执行合约时依然需要cpu，net和ram。但是考虑到绝大多数的合约所使用的资源是有限的。所以我们对于这些合约可以指定一个固定的手续费，同时为了防止极限情况影响链安全，我们可以给这些合约加入一个资源使用上限。

这种实现可以很快完成，我们的计划是在几个月内，采用 原力和社区审核的方式 ，审核提交的合约，并制定手续费费率和资源使用上限。

这样我们近期就可以部署合约并同时可以保证安全。

对于这种方式大家有什么问题么?

开发者： 合约是在侧链部署还是在主网部署？

原力fanyang： 在主网，长期方案需要一段时间开发。对于合约来说，部署是一次性的。关键是执行合约时带来的资源消耗。比方说，有一个上传数据到的合约，每次上传数据不同，占用的资源也不同，用一个固定的费率是显然不合理的。这也就是长期方案所要解决的问题。

原力fanyang： 那么我再说一下长期的计划。

刚才说过，为了解决这个问题，需要手续费能够衡量每次执行合约所需的资源。

我们计划采取的方式是，对于cpu和net，采用每次执行合约的手续费加限制上限的方式来解决，毕竟大多数合约所需的cpu和net不高。上限可以保证安全性。

对于RAM，和主网的通过bancor算法提前购买的方式不同，我们采用租赁的方式来分配RAM。

执行合约所需的RAM需要按照时间租赁。之所以这样设计是为了防止囤积RAM的行为出现，这点大家可以参考EOS。

这就是我们的长期方案，之所以还要考虑短期方案，是因为长期方案开发测试的周期会比较长。

开发者： 租赁是预付费还是记账？

原力fanyang： 预付费。

开发者： 先按kbs购买，然后再消耗？

原力fanyang： 对，租金费率由23个超级节点设置。周期按照块高度计算。

开发者： 租赁时间有上限吗？

原力fanyang： 有时间限制。如果租金逾期会导致数据从RAM中被释放掉，你可以理解为最近的`房地产租赁`政策，防止囤积导致的价格过高。

开发者： 买ram的币到哪里去了？

原力fanyang： 租金主要会做为超级节点的运行成本发给超级节点。因为所有的RAM上的数据需要超级节点提供硬件内存。

开发者： 发token的ram占用怎么租？token需要永久存储呀。

原力fanyang： 这个方案针对用户定义的合约，系统合约采用手续费。

开发者： 数据下线后，充值之后能否恢复，好像没提到这一点。

原力fanyang： 这个可以有开发者提供一些服务帮助合约保存数据了 这个不用在链上。这一方面可以设置一个冻结时间来让用户补足欠费，同时RAM是由区块中的数据生成的，那么可以通过区块信息来找回信息。

开发者： 基于简单模式和复杂模式开发出来的合约，未来迁移的时候要改代码么？

原力fanyang： 对合约本身没有任何影响。

开发者： 不能使用gas模型的原因是什么？

原力fanyang：一方面我们还是基于EOS来开发，我们的思路是在cpu，net，ram资源的分配方式上提出一个好一点的解决方案。

EOS的资源模型不是不好，而是没有考虑到一些恶意行为。

我们必须认识到一个良好的资源模型肯定需要仔细的思考，我们也欢迎所有人提出想法。

这也是为什么我们会提出一个短期方案的原因，需要平衡开发和需求。

开发者： 短期的什么时候出来？

原力fanyang： 根据测试情况，节后上线，这个主要是怕双节期间出问题。开发会在节前完成，因为近期要更新的功能还有分红。所以需要留出时间测试。

开发者： 执行操作就是要支付对应的gas ，比如读取数据库多少gas？运行椭圆曲线算法多少gas？

原力fanyang： 这个思路其实指向了我们需要形式化的定义EOS虚拟机。从而可以精确算出一个合约的资源消耗。但是这个可能需要一个长期的开发过程，另外对于RAM，单纯的gas模型可能引起恶意的占用。其实目前eos中对cpu的计算就很有问题，没有考虑到不同cpu执行时间其实是不同的。

开发者： 我想问下现在EOS以BP算的CPU时间为准吗？ BP能不能作恶呢？明明要执行10000时间只算100。

原力fanyang: 其实可以，但是一方面cpu是抵押的，并不消耗token，另一方面eos共识的基础就是超级节点不会作恶。已部署的合约还是可以使用，因为既然会被部署，就是安全的。失效的是提交合约的权限。

END