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