原力fanyang:

這段時(shí)間(國慶節(jié)前)開發(fā)主要分為三個(gè)方向， 首先我們合并主網(wǎng)近期所有更新，其次是新的分紅方案的開發(fā)，最后就是開放合約的一個(gè)短期方案。這些功能會(huì)在節(jié)后經(jīng)過測(cè)試之后更新。

這里說一下合約，我們這次開放的是一個(gè)短期的方案。

在原力中，我們執(zhí)行Action是收取手續(xù)費(fèi)，而非像EOS那樣分別使用cpu，net和RAM。對(duì)于系統(tǒng)Action我們這邊使用約定的手續(xù)費(fèi)費(fèi)率來收取。

但是對(duì)于用戶定義的合約，因?yàn)椴煌霞s執(zhí)行時(shí)消耗的資源，所以手續(xù)費(fèi)肯定不一樣，需要一個(gè)手續(xù)費(fèi)的定價(jià)模型。

EOS項(xiàng)目中使用的模型是從按照EOS token去分配資源的切入點(diǎn)來設(shè)計(jì)的。

EOS這種模型的問題在于第一對(duì)于用戶和開發(fā)者模型稍顯復(fù)雜，第二cpu和net上由于使用EOS抵押就可以無限使用，就會(huì)出現(xiàn)一些"惡意"的合約對(duì)整個(gè)網(wǎng)絡(luò)產(chǎn)生較大的壓力。

前一段時(shí)間EOS那邊增加了一些合約的黑名單來封禁一些被認(rèn)為是惡意的合約，但這樣其實(shí)非常不好。

對(duì)于原力來說，之所以一直沒有開放用戶定義的合約，就是因?yàn)槲覀冊(cè)谒伎家粋€(gè)手續(xù)費(fèi)模型。

首先需要明確的是，所有action的執(zhí)行都是要消耗主網(wǎng)的計(jì)算和帶寬資源的，所以手續(xù)費(fèi)是一定要有的。

現(xiàn)在大家對(duì)于合約的需求還是比較急切的。所以我們這邊制定了兩套方案：

一套是可以快速實(shí)現(xiàn)的短期方案

一套是需要一定時(shí)間開發(fā)的長(zhǎng)期方案

這邊的計(jì)劃是，在一定時(shí)間內(nèi)先采用短期的方案，使得大家可以使用合約，而后，當(dāng)長(zhǎng)期方案完成之后，再使用長(zhǎng)期方案取代短期方案。

這里我先描述一下兩種方案。

對(duì)于原力來說，在執(zhí)行合約時(shí)依然需要cpu，net和ram。但是考慮到絕大多數(shù)的合約所使用的資源是有限的。所以我們對(duì)于這些合約可以指定一個(gè)固定的手續(xù)費(fèi)，同時(shí)為了防止極限情況影響鏈安全，我們可以給這些合約加入一個(gè)資源使用上限。

這種實(shí)現(xiàn)可以很快完成，我們的計(jì)劃是在幾個(gè)月內(nèi)，采用原力和社區(qū)審核的方式，審核提交的合約，并制定手續(xù)費(fèi)費(fèi)率和資源使用上限。

這樣我們近期就可以部署合約并同時(shí)可以保證安全。

對(duì)于這種方式大家有什么問題么?

開發(fā)者：合約是在側(cè)鏈部署還是在主網(wǎng)部署？

原力fanyang：在主網(wǎng)，長(zhǎng)期方案需要一段時(shí)間開發(fā)。對(duì)于合約來說，部署是一次性的。關(guān)鍵是執(zhí)行合約時(shí)帶來的資源消耗。比方說，有一個(gè)上傳數(shù)據(jù)到的合約，每次上傳數(shù)據(jù)不同，占用的資源也不同，用一個(gè)固定的費(fèi)率是顯然不合理的。這也就是長(zhǎng)期方案所要解決的問題。

原力fanyang：那么我再說一下長(zhǎng)期的計(jì)劃。

剛才說過，為了解決這個(gè)問題，需要手續(xù)費(fèi)能夠衡量每次執(zhí)行合約所需的資源。

我們計(jì)劃采取的方式是，對(duì)于cpu和net，采用每次執(zhí)行合約的手續(xù)費(fèi)加限制上限的方式來解決，畢竟大多數(shù)合約所需的cpu和net不高。上限可以保證安全性。

對(duì)于RAM，和主網(wǎng)的通過bancor算法提前購買的方式不同，我們采用租賃的方式來分配RAM。

執(zhí)行合約所需的RAM需要按照時(shí)間租賃。之所以這樣設(shè)計(jì)是為了防止囤積RAM的行為出現(xiàn)，這點(diǎn)大家可以參考EOS。

這就是我們的長(zhǎng)期方案，之所以還要考慮短期方案，是因?yàn)殚L(zhǎng)期方案開發(fā)測(cè)試的周期會(huì)比較長(zhǎng)。

開發(fā)者：租賃是預(yù)付費(fèi)還是記賬？

原力fanyang：預(yù)付費(fèi)。

開發(fā)者：先按kbs購買，然后再消耗？

原力fanyang：對(duì)，租金費(fèi)率由23個(gè)超級(jí)節(jié)點(diǎn)設(shè)置。周期按照塊高度計(jì)算。

開發(fā)者：租賃時(shí)間有上限嗎？

原力fanyang：有時(shí)間限制。如果租金逾期會(huì)導(dǎo)致數(shù)據(jù)從RAM中被釋放掉，你可以理解為最近的`房地產(chǎn)租賃`政策，防止囤積導(dǎo)致的價(jià)格過高。

開發(fā)者：買ram的幣到哪里去了？

原力fanyang：租金主要會(huì)做為超級(jí)節(jié)點(diǎn)的運(yùn)行成本發(fā)給超級(jí)節(jié)點(diǎn)。因?yàn)樗械腞AM上的數(shù)據(jù)需要超級(jí)節(jié)點(diǎn)提供硬件內(nèi)存。

開發(fā)者：發(fā)token的ram占用怎么租？token需要永久存儲(chǔ)呀。

原力fanyang：這個(gè)方案針對(duì)用戶定義的合約，系統(tǒng)合約采用手續(xù)費(fèi)。

開發(fā)者：數(shù)據(jù)下線后，充值之后能否恢復(fù)，好像沒提到這一點(diǎn)。

原力fanyang：這個(gè)可以有開發(fā)者提供一些服務(wù)幫助合約保存數(shù)據(jù)了 這個(gè)不用在鏈上。這一方面可以設(shè)置一個(gè)凍結(jié)時(shí)間來讓用戶補(bǔ)足欠費(fèi)，同時(shí)RAM是由區(qū)塊中的數(shù)據(jù)生成的，那么可以通過區(qū)塊信息來找回信息。

開發(fā)者：基于簡(jiǎn)單模式和復(fù)雜模式開發(fā)出來的合約，未來遷移的時(shí)候要改代碼么？

原力fanyang：對(duì)合約本身沒有任何影響。

開發(fā)者：不能使用gas模型的原因是什么？

原力fanyang：一方面我們還是基于EOS來開發(fā)，我們的思路是在cpu，net，ram資源的分配方式上提出一個(gè)好一點(diǎn)的解決方案。

EOS的資源模型不是不好，而是沒有考慮到一些惡意行為。

我們必須認(rèn)識(shí)到一個(gè)良好的資源模型肯定需要仔細(xì)的思考，我們也歡迎所有人提出想法。

這也是為什么我們會(huì)提出一個(gè)短期方案的原因，需要平衡開發(fā)和需求。

開發(fā)者：短期的什么時(shí)候出來？

原力fanyang：根據(jù)測(cè)試情況，節(jié)后上線，這個(gè)主要是怕雙節(jié)期間出問題。開發(fā)會(huì)在節(jié)前完成，因?yàn)榻谝碌墓δ苓€有分紅。所以需要留出時(shí)間測(cè)試。

開發(fā)者：執(zhí)行操作就是要支付對(duì)應(yīng)的gas ，比如讀取數(shù)據(jù)庫多少gas？運(yùn)行橢圓曲線算法多少gas？

原力fanyang：這個(gè)思路其實(shí)指向了我們需要形式化的定義EOS虛擬機(jī)。從而可以精確算出一個(gè)合約的資源消耗。但是這個(gè)可能需要一個(gè)長(zhǎng)期的開發(fā)過程，另外對(duì)于RAM，單純的gas模型可能引起惡意的占用。其實(shí)目前eos中對(duì)cpu的計(jì)算就很有問題，沒有考慮到不同cpu執(zhí)行時(shí)間其實(shí)是不同的。

開發(fā)者：我想問下現(xiàn)在EOS以BP算的CPU時(shí)間為準(zhǔn)嗎？ BP能不能作惡呢？明明要執(zhí)行10000時(shí)間只算100。

原力fanyang:其實(shí)可以，但是一方面cpu是抵押的，并不消耗token，另一方面eos共識(shí)的基礎(chǔ)就是超級(jí)節(jié)點(diǎn)不會(huì)作惡。已部署的合約還是可以使用，因?yàn)榧热粫?huì)被部署，就是安全的。失效的是提交合約的權(quán)限。

END