ECOC“輕鏈”一個(gè)基于POS機(jī)制底層算法的公有鏈計(jì)算集成系統(tǒng)

　 域名預(yù)訂/競價(jià)，好“米”不錯(cuò)過

去中心化應(yīng)用

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

UTXO模型

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

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

TPS解決方案

ECOC 以字節(jié)為單位計(jì)算平均事物大小，首先我們將計(jì)算所有需 要的跳數(shù)節(jié)點(diǎn)獲取數(shù)據(jù)，因?yàn)檫B接數(shù)是固定的，C 和因?yàn)榫哂袛?shù) 據(jù)（塊）的每隔節(jié)點(diǎn)想起他節(jié)點(diǎn)廣播它連接后，流程遵循“雪球” 效應(yīng)。這在數(shù)學(xué)上是一個(gè)幾何級數(shù)：

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

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

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

圖靈完備

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

去中心化應(yīng)用（DAPP）

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

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