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

2018-09-15 16:20 商业 观点 137815 收藏

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

本文为作者“EOS原力”,原创文章,转载时请保留本声明及附带文章链接。 内容仅供读者参考,并非投资建议,本网站将保留所有法律权益。

评论

共22条评论

查看更多

EOS原力

EOSFORCE致力于在实践中探索更开放的加密经济基础设施,推动区块链技术在各个领域的应用。

文章 粉丝


近期文章
7X24快讯 查看更多>
跳到顶
正在载入...