EOSForce主網智能合約公測開發者答疑區塊鏈
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
1.TMT觀察網遵循行業規范，任何轉載的稿件都會明確標注作者和來源；
2.TMT觀察網的原創文章，請轉載時務必注明文章作者和"來源：TMT觀察網"，不尊重原創的行為TMT觀察網或將追究責任；
3.作者投稿可能會經TMT觀察網編輯修改或補充。
