EOSForce主網(wǎng)智能合約公測開發(fā)者答疑區(qū)塊鏈
EOSForce主網(wǎng)智能合約公測開發(fā)者答疑
原力fanyang:
這段時間(國慶節(jié)前)開發(fā)主要分為三個方向, 首先我們合并主網(wǎng)近期所有更新,其次是新的分紅方案的開發(fā),最后就是開放合約的一個短期方案。這些功能會在節(jié)后經(jīng)過測試之后更新。
這里說一下合約,我們這次開放的是一個短期的方案。
在原力中,我們執(zhí)行Action是收取手續(xù)費,而非像EOS那樣分別使用cpu,net和RAM。對于系統(tǒng)Action我們這邊使用約定的手續(xù)費費率來收取。
但是對于用戶定義的合約,因為不同合約執(zhí)行時消耗的資源,所以手續(xù)費肯定不一樣,需要一個手續(xù)費的定價模型。
EOS項目中使用的模型是從按照EOS token去分配資源的切入點來設計的。
EOS這種模型的問題在于第一對于用戶和開發(fā)者模型稍顯復雜,第二cpu和net上由于使用EOS抵押就可以無限使用,就會出現(xiàn)一些"惡意"的合約對整個網(wǎng)絡產生較大的壓力。
前一段時間EOS那邊增加了一些合約的黑名單來封禁一些被認為是惡意的合約,但這樣其實非常不好。
對于原力來說,之所以一直沒有開放用戶定義的合約,就是因為我們在思考一個手續(xù)費模型。
首先需要明確的是,所有action的執(zhí)行都是要消耗主網(wǎng)的計算和帶寬資源的,所以手續(xù)費是一定要有的。
現(xiàn)在大家對于合約的需求還是比較急切的。所以我們這邊制定了兩套方案:
一套是可以快速實現(xiàn)的短期方案
一套是需要一定時間開發(fā)的長期方案
這邊的計劃是,在一定時間內先采用短期的方案,使得大家可以使用合約,而后,當長期方案完成之后,再使用長期方案取代短期方案。
這里我先描述一下兩種方案。
對于原力來說,在執(zhí)行合約時依然需要cpu,net和ram。但是考慮到絕大多數(shù)的合約所使用的資源是有限的。所以我們對于這些合約可以指定一個固定的手續(xù)費,同時為了防止極限情況影響鏈安全,我們可以給這些合約加入一個資源使用上限。
這種實現(xiàn)可以很快完成,我們的計劃是在幾個月內,采用原力和社區(qū)審核的方式,審核提交的合約,并制定手續(xù)費費率和資源使用上限。
這樣我們近期就可以部署合約并同時可以保證安全。
對于這種方式大家有什么問題么?
開發(fā)者:合約是在側鏈部署還是在主網(wǎng)部署?
原力fanyang:在主網(wǎng),長期方案需要一段時間開發(fā)。對于合約來說,部署是一次性的。關鍵是執(zhí)行合約時帶來的資源消耗。比方說,有一個上傳數(shù)據(jù)到的合約,每次上傳數(shù)據(jù)不同,占用的資源也不同,用一個固定的費率是顯然不合理的。這也就是長期方案所要解決的問題。
原力fanyang:那么我再說一下長期的計劃。
剛才說過,為了解決這個問題,需要手續(xù)費能夠衡量每次執(zhí)行合約所需的資源。
我們計劃采取的方式是,對于cpu和net,采用每次執(zhí)行合約的手續(xù)費加限制上限的方式來解決,畢竟大多數(shù)合約所需的cpu和net不高。上限可以保證安全性。
對于RAM,和主網(wǎng)的通過bancor算法提前購買的方式不同,我們采用租賃的方式來分配RAM。
執(zhí)行合約所需的RAM需要按照時間租賃。之所以這樣設計是為了防止囤積RAM的行為出現(xiàn),這點大家可以參考EOS。
這就是我們的長期方案,之所以還要考慮短期方案,是因為長期方案開發(fā)測試的周期會比較長。
開發(fā)者:租賃是預付費還是記賬?
原力fanyang:預付費。
開發(fā)者:先按kbs購買,然后再消耗?
原力fanyang:對,租金費率由23個超級節(jié)點設置。周期按照塊高度計算。
開發(fā)者:租賃時間有上限嗎?
原力fanyang:有時間限制。如果租金逾期會導致數(shù)據(jù)從RAM中被釋放掉,你可以理解為最近的`房地產租賃`政策,防止囤積導致的價格過高。
開發(fā)者:買ram的幣到哪里去了?
原力fanyang:租金主要會做為超級節(jié)點的運行成本發(fā)給超級節(jié)點。因為所有的RAM上的數(shù)據(jù)需要超級節(jié)點提供硬件內存。
開發(fā)者:發(fā)token的ram占用怎么租?token需要永久存儲呀。
原力fanyang:這個方案針對用戶定義的合約,系統(tǒng)合約采用手續(xù)費。
開發(fā)者:數(shù)據(jù)下線后,充值之后能否恢復,好像沒提到這一點。
原力fanyang:這個可以有開發(fā)者提供一些服務幫助合約保存數(shù)據(jù)了 這個不用在鏈上。這一方面可以設置一個凍結時間來讓用戶補足欠費,同時RAM是由區(qū)塊中的數(shù)據(jù)生成的,那么可以通過區(qū)塊信息來找回信息。
開發(fā)者:基于簡單模式和復雜模式開發(fā)出來的合約,未來遷移的時候要改代碼么?
原力fanyang:對合約本身沒有任何影響。
開發(fā)者:不能使用gas模型的原因是什么?
原力fanyang:一方面我們還是基于EOS來開發(fā),我們的思路是在cpu,net,ram資源的分配方式上提出一個好一點的解決方案。
EOS的資源模型不是不好,而是沒有考慮到一些惡意行為。
我們必須認識到一個良好的資源模型肯定需要仔細的思考,我們也歡迎所有人提出想法。
這也是為什么我們會提出一個短期方案的原因,需要平衡開發(fā)和需求。
開發(fā)者:短期的什么時候出來?
原力fanyang:根據(jù)測試情況,節(jié)后上線,這個主要是怕雙節(jié)期間出問題。開發(fā)會在節(jié)前完成,因為近期要更新的功能還有分紅。所以需要留出時間測試。
開發(fā)者:執(zhí)行操作就是要支付對應的gas ,比如讀取數(shù)據(jù)庫多少gas?運行橢圓曲線算法多少gas?
原力fanyang:這個思路其實指向了我們需要形式化的定義EOS虛擬機。從而可以精確算出一個合約的資源消耗。但是這個可能需要一個長期的開發(fā)過程,另外對于RAM,單純的gas模型可能引起惡意的占用。其實目前eos中對cpu的計算就很有問題,沒有考慮到不同cpu執(zhí)行時間其實是不同的。
開發(fā)者:我想問下現(xiàn)在EOS以BP算的CPU時間為準嗎? BP能不能作惡呢?明明要執(zhí)行10000時間只算100。
原力fanyang:其實可以,但是一方面cpu是抵押的,并不消耗token,另一方面eos共識的基礎就是超級節(jié)點不會作惡。已部署的合約還是可以使用,因為既然會被部署,就是安全的。失效的是提交合約的權限。
END
1.TMT觀察網(wǎng)遵循行業(yè)規(guī)范,任何轉載的稿件都會明確標注作者和來源;
2.TMT觀察網(wǎng)的原創(chuàng)文章,請轉載時務必注明文章作者和"來源:TMT觀察網(wǎng)",不尊重原創(chuàng)的行為TMT觀察網(wǎng)或將追究責任;
3.作者投稿可能會經(jīng)TMT觀察網(wǎng)編輯修改或補充。