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

  发布时间:   文章分类:ASP.NET 浏览数: 43

文章来源: www.ihuoqiu.com/Content/inform......, 本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。

原力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

以上所述就是小编给大家介绍的《EOSForce主网智能合约公测开发者答疑》,希望对大家有所帮助,如果大家有任何疑问请给我留言,小编会及时回复大家的。在此也非常感谢大家对 Coder·码农网 的支持!

码农可能感兴趣的文章:

本文永久链接:www.codercto.com/a/25676.html

相关码农书籍:
Web设计禁忌

Web设计禁忌

Jeff Johnson / 张颖 / 机械工业出版社 / 2006-2 / 38.00元

本书作者曾写过GUI设计禁忌,这本书在总结那本书的经验基础E,以大量实例详细讨论了60个最常见和最严童的Web设计错误。作者紧紧围绕可用性问题,指出了人们在...

相关码农工具:
RGB CMYK 转换工具

RGB CMYK 转换工具

RGB CMYK 互转工具

URL 编码/解码

URL 编码/解码

URL 编码/解码

html转js在线工具

html转js在线工具

html转js在线工具