ECOC“輕鏈”一個基于POS機制底層算法的公有鏈計算集成系統

　 域名預訂/競價，好“米”不錯過

去中心化應用

ECOC 合約機制使得任何一個人能夠在一個虛擬機上建立通 過全網共識來運行命令行應用（從根本上來說是），它能夠更改 一個全網可訪問的狀態(tài)作為它的“硬盤”。然而，對于多數人來 說，用作交易發(fā)送機制的命令行接口缺乏足夠的用戶友好使得去 中心化成為吸引力的替代方案。最后，一個完整的“去中心化應 用”應該包括底層的商業(yè)邏輯組件和上層的圖形用戶接口組件。 客戶端被設計成一個網絡瀏覽器，但包括對吐絮應用戶接口組 件，客戶端設計成一個網絡瀏覽器，單包括對“ECOC”javascriptAPI 對象的支持，可備客戶端里看到的特定的網頁用來與 ECOC 區(qū)塊鏈交互。從“傳統”網頁的角度來看，這些網頁完全靜態(tài)的內容， 因為區(qū)塊鏈和其他的去中心化協議將完全代替服務器來處理用 戶發(fā)起的請求。最后，去中心化協議游戲王自己利用莫種方式。

UTXO模型

在未花費交易輸出（UTXO）模型中，交易使用未花費的比特 幣作為輸入，此時輸入的 UTXO 就會作廢，而輸出是另一個 UTXO, 比特幣數量上變化的結果會返還到發(fā)送者 [1]。一定數 量 的比特幣在不同私鑰持有人之間進行轉移，新的未花費交易輸出 在交易中花費，并記錄在 區(qū)塊上。在比特幣交易中，UTXO 可用 交易接收方公鑰地址生成的秘鑰進行解鎖。需要說 明的是，礦 工在 coinbase 交易中生成比特幣，這個過程中并沒有包含任何 輸入。同時，比 特幣利用腳本語言只能進行有限的操作 7 ，并 以堆棧（分為主堆棧和 Alt 堆棧）的形式進行 數據處理，并遵 循“后進先出”（LIFO）原則。 開發(fā)者在比特幣客戶端定義了五 種交易標準，分別為：P2PKH（Pay to Public Key Hash）、 P2PK （Pay to Public Key）、多重簽名（少于 15 個私鑰簽名）、P2SH （Pay to Script Hash） 和 OP_RETURN。利用這五種交易標準，比 特幣客戶端可以滿足復雜的支付邏輯。除此之 外，如果礦工同 意對非標準交易進行封裝，比特幣客戶端也可創(chuàng)建并執(zhí)行一個非 標準的腳 本。 舉例來說，使用 P2PKH 交易方式，我們假設用 戶向虛擬比特幣地址 Bread Address 支付了 0.01 比特幣購買面 包。該交易的輸出為： OP_DUP OP_HASH160 OP_EQUAL OP_CHECKSIG OP_DUP 復制 堆棧頂層數據；OP_HASH160 返回比特幣地址并存入棧頂。除了 比特幣地 址，還需要數字簽名和數字秘鑰才能擁有比特幣所有 權。若棧頂數據一致，則 OP_EQUAL 返回真值（1），否則返回 非真值（0）。OP_CHECKSIG 生成公鑰和簽名，并校驗交易哈希 值。若一致，則返回真值。 鎖定腳本相對應的解鎖腳本為： 將 上述兩個腳本相結合： OP_DUP OP_HASH160 OP_EQUAL OP_CHECKSIG 只有當解鎖腳本和鎖定腳本滿足預先設定的條件 時，執(zhí)行結合腳本的輸出為真。當 Bread Signature 簽名與 Bread 03：UTXO 方案Address 私鑰相匹配，則返回真值。 但比特幣腳本語言并不是圖 靈完備的，無法實現循環(huán)功能。這極大地制約了交易執(zhí)行量和交 易復雜度。此外，比特幣腳本語言作為編程語言并沒有被廣泛使 用。當然，這些限制也降低 了諸如無限循環(huán)在內的復雜支付邏 輯安全漏洞的風險。 當然 UTXO 模型也有諸多優(yōu)勢：任何人可 以通過比特幣公共賬本對每一筆交易歷史進行查 詢；UTXO 有良 好的可拓展性，能夠同時處理多個地址發(fā)起的交易請求。此外， UTXO 模 型也提供了隱私保護，用戶可以使用變更地址作為 UTXO 輸出。但 UTXO 并不提供狀態(tài) 

信息，因此 ECOC 的目標是 在 UTXO 模型的基礎上加入全新設計，提供全新的智能 合約平 臺。 與 UTXO 模型不同，以太坊使用了賬戶（Account）模型。 具體來說，ECOC 通過賬戶狀態(tài)的改變進行價值和信息的交換與 傳輸，并通過長度為 20 字節(jié)的隨機數作為指針以確保交 易處 理的唯一性。用于支付交易費用、供內部使用的加密貨幣稱為以 太坊。合約代碼是可選 的，而賬號的存儲默認為空。 以太坊賬 戶有兩種類型，一種由外部私鑰控制的外部賬戶，另一種由合約 代碼控制的合約賬 戶。外部賬戶用于信息傳輸的創(chuàng)建、交易簽 名。合約賬戶用于收到內部存儲讀寫操作信息后 創(chuàng)建合約或發(fā) 送其他信息。 以太坊中的賬戶余額管理與日常生活中的銀行賬 戶管理相類似。每一個新產生的區(qū)塊都有可能影響其他賬戶的全 局狀態(tài)。每個賬戶都有各自的余額、存儲和代碼空間用于調用其 他賬戶或地址，并存儲相應的代碼執(zhí)行結果?，F有的 ECOC 賬戶 系統中，用戶通過客戶端遠程調 用合約賬號進行 P2P 交易。盡 管通過智能合約向多個賬戶發(fā)送信息是可以實現的，但具體 交 易信息只有參與交易的賬戶可見，無法在 ECOC 公共賬簿上進行 追蹤仍無法實現。 綜上所述，我們認為 ECOC 在擴展性方面的瓶 頸使比特幣 UTXO 模型擁有更多的優(yōu)勢。 UTXO 模型與 ECOC 提供的平臺一致性更相關，因此 ECOC 決定使用 UTXO 模型作為 交易模型的基礎。

TPS解決方案

ECOC 以字節(jié)為單位計算平均事物大小，首先我們將計算所有需 要的跳數節(jié)點獲取數據，因為連接數是固定的，C 和因為具有數 據（塊）的每隔節(jié)點想起他節(jié)點廣播它連接后，流程遵循“雪球” 效應。這在數學上是一個幾何級數：

其中 h-1 希望之后通知的節(jié)點數。在這里，我們假設 a0 = 1，因 為 a0 是形成（獲勝）塊的節(jié)點，并且是準備開始廣播。 h 跳后 的總通知節(jié)點 n 將是：

并且很容易理解為什么。節(jié)點應該有足夠的時間來“獲取”（下 載）塊數據。因此，雖然某些節(jié)點可以容忍它來自先前塊的數據 在創(chuàng)建新數據時，這是不安全的長期的;總傳播時間應低于平均創(chuàng) 建時間一個街區(qū)的時間。結合（3）和（4）我們得到

Equality（5）清楚地顯示了網絡必須的最低帶寬 bmin 必須以字節(jié) 為單位維持大小為 s 的塊大小。值得注意的還有數據的傳播很容 易擴展，因為存在對數關系在網絡 n 的節(jié)點數和連接數之間 C。換句話說，跳數 h（n）是 O（log n）。原因在于此 效率是指傳播是基于八卦協議[1]。比特幣和 Ecochain 遵循八卦協 議（默認）連接數 c = 8.在 src / net.h 文件的代碼中可以很容易地 看到：從上面我們得出結論，對于 Ecochain c = 8.作為旁注，我們 必須強調任何節(jié)點都可以自由更改出站號碼關系;也就是說，c 不 是共識協議的參數。只是將上面的代碼行從 8 更改為任何數字是 可以接受的網絡，因為它不是真的可以檢測到。例如，節(jié)點可能 具有高上傳帶寬也可能想要幫助網絡，所以選擇設置 c 或者節(jié)點 是自私的或惡意的，并將 c 設置為零，而不是廣播 任何東西。簡而言之，改變 c 是一個簡單的軟叉。我們可以安全 地假設這里絕大多數節(jié)點都不會改變 c，因為它們沒有鼓勵這樣 做。如果 c 的默認值設置為大于 8 的值沒有必要帶來更快的傳播 時間;有限制數據庫提交時的磁盤寫入時間和由于的 CPU 延遲 4 當交易數量很大時所需的驗證時間。所以 Ecochain 保持 c = 8，正 如我們已經提到的那樣，不限制節(jié)點;每個節(jié)點都可以很容易地改 變它。讓我們看一個數字的例子：對于最大塊大小 s = 4M 字節(jié)， 塊時間 bt = 32sec，節(jié)點數 n = 4,000，連接數 c = 8 來自 equeation （5）的最小網絡速度（帶寬）應該是《技術數據參考鏈接http://t.cn/AipAAlby》

圖靈完備

需要強調的是以太坊虛擬機是圖靈完備的； 這意味著 EVM 代碼可以實現任何可以想象的計算，包括無限循環(huán)。EVM 代碼有 兩種方式實現循環(huán)。首先， JUMP 指令可以讓程序跳回至代碼前 面某處，還有允許如 while x < 27: x = x * 2 一樣的條件 語句的 JUMPI 指令實現條件跳轉。其次，合約可以調用其它合約， 有通過遞歸實現循環(huán)的潛力。這很自然地導致了一個問題：惡意 用戶能夠通過迫使礦工和全節(jié)點進入無限循環(huán)而不得不關機 嗎？ 這問題出現是因為計算機科學中一個叫停機問題的問題： 一般意義上沒有辦法知道，一個給定的程序是否能在有限的時間 內結束運行。 正如在狀態(tài)轉換章節(jié)所述，我們的方案通過為每一個交易設定運 行執(zhí)行的最大計算步數來解決問題，如果超過則計算被恢復原狀 但依然要支付費用。消息以同樣的方式工作。為顯示這一方案背 后的動機，請考慮下面的例子： 一個攻擊者創(chuàng)建了一個運行無限循環(huán)的合約，然后發(fā)送了 一個激活循環(huán)的交易給礦工，礦工將處理交易，運行無限 循環(huán)直到瓦斯耗盡。即使瓦斯耗盡交易半途停止，交易依 然正確（回到原處）并且礦工依然從攻擊者哪里掙到了每 一步計算的費用。 一個攻擊者創(chuàng)建一個非常長的無限循環(huán)意圖迫使礦工長 時間內一直計算致使在計算結束前若干區(qū)塊已經產生于 是礦工無法收錄交易以賺取費 用。然而，攻擊者需要發(fā) 布一個 STARTGAS 值以限制可執(zhí)行步數，因而礦工將提前 知道計算將耗費過多的步數。 一個攻擊者看到一個包含諸如 send(A,self.storage); self.storage = 0 格式的合約然后發(fā)送帶有只夠執(zhí)行第一 06：圖靈完備步的費用的而不夠執(zhí)行第二步的交易（即提現但不減少賬 戶余額）。合約作者無需擔心防衛(wèi)類似攻擊，因為如果執(zhí) 行中途停止則所有變更都被回復。 一個金融合約靠提取九個專用數據發(fā)布器的中值來工作 以最小化風險，一個攻擊者接管了其中一個數據提供器， 然后把這個按 DAO 章節(jié)所述的可變地址調用機制設計成可 更改的數據提供器轉為運行一個無限循環(huán)，以求嘗試逼迫 任何從此金融合約索要資金的嘗試都會因瓦斯耗盡而中 止。然而，該金融合約可以在消息里設置瓦斯限制以防范 此類問題。 圖靈完備的替代是圖靈不完備，這里 JUMP 和 JUMPI 指令不存在并且在某個給定時間每個合約只允許 有一個拷貝存在于調用堆棧內。在這樣的系統里，上述的 費用系統和圍繞我們的方案的效率的不確定性可能都是 不需要的，因為執(zhí)行一個合約的成本將被它的大小決定。 此外，圖靈不完備甚至不是一個大的限制，在我們內部設 想的所有合約例子中，至今只有一個需要循環(huán)，而且即使 這循環(huán)也可以被 26 個單行代碼段的重復所代替?？紤]到 圖靈完備帶來的嚴重的麻煩和有限的益處，為什么不簡單 地使用一種圖靈不完備語言呢？事實上圖靈不完備遠非 一個簡潔的解決方案。為什么？請考慮下面的合約： C0: call(C1)? call(C1)? C1: call(C2)? call(C2)? C2: call(C3)? call(C3)?... C49: call(C50)? call(C50)? C50: (作一個圖靈機的步計算和記錄結果在合約的長期存儲) 現在，發(fā)送一個這樣的交易給 A，這樣，在 51 個交易中，我們有 了一個需要花費 2^50 步計算的合約，礦工可能嘗試通過為每一 個合約維護一個最高可執(zhí)行步數并且對于遞歸調用其它合約的合約計算可能執(zhí)行步數從而預先檢測這樣的邏輯炸彈，但是這會 使礦工禁止創(chuàng)建其它合約的合約（因為上面 26 個合約的創(chuàng)建和 執(zhí)行可以很容易地放入一個單獨合約內）。另外一個問題點是一 個消息的地址字段是一個變量，所以通常來講可能甚至無法預先 知道一個合約將要調用的另外一個合約是哪一個。于是，最終我 們有了一個驚人的結論：圖靈完備的管理驚人地容易，而在缺乏 同樣的控制時圖靈不完備的管理驚人地困難- 那為什么不讓協 議圖靈完備呢？

去中心化應用（DAPP）

ECOC 系統致?從技術層?全??持去中?化應?，尤其是 通過移動端策略的引?，將不 同的 DAPP 想法產品化，使普通互 聯??戶可以真正感受到區(qū)塊鏈技術帶來的價值。 ?向不同? 業(yè)的 DAPP 應?，可以把區(qū)塊鏈技術帶給更多的?戶和?業(yè)。例 如去中?化的 社交、去中?化的存儲和去中?化的域名服務、 去中?化的計算服務等，通過激勵機制的 引?，將更深層次利 ?共享經濟的理念，改變現有的 APP 市場和商業(yè)模式。 區(qū)塊鏈 技術為搭建去中?化應?（Decentralized Applications）提供基礎 架構。 在量?鏈 中，通過完善的 ECOC API 的設計和 Docker 的分發(fā)，簡化開發(fā)者的準備?作，使開發(fā)者可 以快速上?相應 的開發(fā)?作。并將通過 ECOC 系統內部的 Token 激勵開發(fā)者開發(fā) 出?質量的 DAPP。

申請創(chuàng)業(yè)報道，分享創(chuàng)業(yè)好點子。點擊此處，共同探討創(chuàng)業(yè)新機遇！