欧美日韩国产一区二区|qovd片|小明个人发布看看|小浪货你夹真紧水又多|老头把我添高潮了A片故|99热久久精品国产一区二区|久久久春色AV

  1. 首頁(yè) > 生活經(jīng)驗(yàn) > >

Serenity - 第一部分: 深度抽象是什么？Serenity是什么？

我們已經(jīng)公開(kāi)繼續(xù)改進(jìn)以太坊協(xié)議的計(jì)劃和長(zhǎng)期開(kāi)發(fā)路線圖相當(dāng)長(zhǎng)一段時(shí)間了，這個(gè)做法也是來(lái)自于從1.0版本發(fā)布之前或者事后沒(méi)有能及時(shí)處理的錯(cuò)誤中學(xué)到的經(jīng)驗(yàn) 。不管怎樣，以太坊核心協(xié)議的周期性開(kāi)發(fā)已經(jīng)重新啟動(dòng)，Homestead階段很快就要到來(lái)，我們也已經(jīng)悄悄開(kāi)始開(kāi)發(fā)一個(gè)概念原型(PoC)，目標(biāo)是開(kāi)發(fā)路線圖中最大的里程碑: Serenity.下面小編給大家介紹一下!

Serenity - 第一部分: 深度抽象是什么？Serenity是什么？

Serenity會(huì)有兩大主要特性：深度抽象，一個(gè)我最早在這里展開(kāi)討論過(guò)的特性，和Casper，基于保證金的權(quán)益證明(PoS)算法 。此外，我們也在探索平滑的部署可伸縮性(scalability)改進(jìn)的方法，至少是一個(gè)腳手架 ， 同時(shí)完全解決這里對(duì)并行性的擔(dān)憂 - 運(yùn)行在私有鏈環(huán)境下，多核CPU專有服務(wù)器之上的以太坊節(jié)點(diǎn)性能將會(huì)有立竿見(jiàn)影的巨大提升，甚至公有鏈的可伸縮性也能看到2到5倍的提升 。在過(guò)去的幾個(gè)月中，Casper的研究和對(duì)可伸縮性與抽象改進(jìn)的形式化工作(eg. EIP101)都在快速推進(jìn)，參與者有我, Vlad Zamfir, Lucius Greg Meredith和其他一些人 。現(xiàn)在我很高興的宣布，Serenity階段的第一個(gè)概念原型, 盡管能做的事情還非常有限僅僅可以用于測(cè)試，已經(jīng)完成 。
在ethereum目錄下運(yùn)行python test.py就可以把概念原型跑起來(lái)(別忘了先從https://github.com/ethereum/serpentSerpent下載和安裝最新的 develop分支)，如果看到這樣的輸出就對(duì)了：
vub@vub-ThinkPad-X250 15:01:03 serenity/ethereum: python test.py
REVERTING 940534 gas from account 0x0000000000000000000000000000000000000000 to account 0x98c78be58d729dcdc3de9efb3428820990e4e3bf with data 0x
Warning (file casper.se.py, line 74, char 0): Warning: function return type inconsistent!
Running with 13 maximum nodes
Warning (file casper.se.py, line 74, char 0): Warning: function return type inconsistent!
Warning (file casper.se.py, line 74, char 0): Warning: function return type inconsistent!
Length of validation code: 57
Length of account code: 0
Joined with index 0
Length of validation code: 57
Length of account code: 0
Joined with index 1
Length of validation code: 57
在每5秒一個(gè)塊，使用Casper Serenity協(xié)議的條件下，這個(gè)程序模擬了的13個(gè)節(jié)點(diǎn)的運(yùn)行;這個(gè)模擬已經(jīng)很接近當(dāng)前客戶端能處理的上限了，不過(guò)要注意：(i) 這是python寫(xiě)的 ， C和Go的實(shí)現(xiàn)很可能會(huì)有更好的表現(xiàn)，以及(ii) 所有這些節(jié)點(diǎn)都同時(shí)運(yùn)行在一臺(tái)電腦上，所以你有理由相信在一個(gè)更“正常”的環(huán)境中python版本的Casper可以處理大約169個(gè)節(jié)點(diǎn)(不過(guò)，從另一方面來(lái)說(shuō) ， 我們希望共識(shí)的開(kāi)銷遠(yuǎn)低于100%的CPU占用，因此這兩點(diǎn)注意并不表示你可以期待Casper和上千個(gè)節(jié)點(diǎn)一起工作!) 。如果你的電腦太慢處理不了13個(gè)節(jié)點(diǎn)，試試用python test.py 10來(lái)模擬10個(gè)節(jié)點(diǎn)(或者python test.py 7來(lái)模擬7個(gè)節(jié)點(diǎn)，你懂的) 。當(dāng)然，改進(jìn)Casper效率的研究仍在繼續(xù) ， 雖然這改進(jìn)可能會(huì)以減慢終局性(finality)的收斂為代價(jià) ， 這些問(wèn)題都會(huì)逐漸解決 。network.py文件模擬了一個(gè)基本的P2P網(wǎng)絡(luò)接口，接下來(lái)的工作會(huì)把它替換成運(yùn)行在真實(shí)網(wǎng)絡(luò)上的真實(shí)計(jì)算機(jī) 。
程序代碼被分割到幾個(gè)主要文件中：
serenity_blocks.py - 描述block類，state類，以及block和transaction級(jí)別狀態(tài)轉(zhuǎn)移函數(shù)的代碼(比以前的版本簡(jiǎn)單一倍) 。
serenity_transactions.py - 描述transaction的代碼(比之前簡(jiǎn)單一倍) 。
casper.se.py - Casper合約的serpent實(shí)現(xiàn) ， 激勵(lì)正確的下注行為 。
bet.py - Casper的下注邏輯和完整的客戶端實(shí)現(xiàn) 。
ECDSA_accounts.py - 賬戶相關(guān)代碼，讓你可以在Serenity上模擬當(dāng)前的賬戶驗(yàn)證邏輯 。
【Serenity - 第一部分: 深度抽象是什么？Serenity是什么？】test.py - 測(cè)試腳本
config.py - 參數(shù)配置
vm.py - 虛擬機(jī)(fastvm.py提供了一個(gè)更快的實(shí)現(xiàn))
network.py - 網(wǎng)絡(luò)模擬
在這篇文章中，我們只討論深度抽象的特性，因此關(guān)鍵文件是serenity_blocks.py, ecdsa_accounts.py和serenity_transactions.py;在下一篇討論Casper的文章中，casper.se.py和bet.py將會(huì)是焦點(diǎn) 。
賬戶的抽象
目前以太坊中有兩種類型的賬戶：外部擁有的賬戶 ， 由私鑰控制 ， 和合約賬戶 ， 由代碼控制 。對(duì)于外部擁有的賬戶，我們指定了一種特別的數(shù)字簽名算法(secp256k1橢圓曲線簽名)和一個(gè)序號(hào)體系(nonce)，要求每一個(gè)交易都必須包含一個(gè)比前一個(gè)交易序號(hào)大1的數(shù)字，目的是防止重放攻擊(replay attacks) 。我們?yōu)樘岣叱橄蟪潭榷龅闹饕膭?dòng)是：不再有兩種不同類型的賬戶，而是統(tǒng)一為一種 - 合約賬戶 。將會(huì)存在一個(gè)特殊的“入口”賬戶，0x0000000000000000000000000000000000000000，任何人都可以從這個(gè)賬戶發(fā)起交易 。因此，協(xié)議中將不再包含簽名 nonce的賬戶驗(yàn)證邏輯，用戶必須用合約來(lái)保護(hù)他們自己的賬戶 。
最簡(jiǎn)單有效的此類合約可能要屬橢圓曲線數(shù)字簽名驗(yàn)證合約了，它可以提供和現(xiàn)在完全一樣的功能：只有擁有有效簽名和序號(hào)的交易才能通過(guò)驗(yàn)證，而且序號(hào)在交易成功后增加1 。這個(gè)合約的代碼如下：
# We assume that data takes the following schema:
# bytes 0-31: v (ECDSA sig)
# bytes 32-63: r (ECDSA sig)
# bytes 64-95: s (ECDSA sig)
# bytes 96-127: sequence number (formerly called nonce)
# bytes 128-159: gasprice
# bytes 172-191: to
# bytes 192-223: value
# bytes 224 : data
# Get the hash for transaction signing
~mstore(0, ~txexecgas())
~calldatacopy(32, 96, ~calldatasize() - 96)
~mstore(0, ~sha3(0, ~calldatasize() - 64))
~calldatacopy(32, 0, 96)
# Call ECRECOVER contract to get the sender
~call(5000, 1, 0, 0, 128, 0, 32)
# Check sender correctness; exception if not
if ~mload(0) != 0x82a978b3f5962a5b0957d9ee9eef472ee55b42f1:
~invalid()
# Sequence number operations
with minusone = ~sub(0, 1):
with curseq = self.storage[minusone]:
# Check sequence number correctness, exception if not
if ~calldataload(96) != curseq:
~invalid()
# Increment sequence number
self.storage[minusone] = curseq1
# Make the sub-call and discard output
with x = ~msize():
~call(msg.gas - 50000, ~calldataload(160), ~calldataload(192), 160, ~calldatasize() - 224, x, 1000)
# Pay for gas
~mstore(0, ~calldataload(128))
~mstore(32, (~txexecgas() - msg.gas50000))
~call(12000, ETHER, 0, 0, 64, 0, 0)
~return(x, ~msize() - x)
這段代碼就是用戶賬戶的合約代碼;如果用戶要從自己的賬戶發(fā)送一個(gè)交易，他們會(huì)先從地址0發(fā)送一個(gè)交易到這個(gè)賬戶 ， 交易數(shù)據(jù)會(huì)像上述代碼所示那樣包括ECDSA簽名 ， 序號(hào)，gas價(jià)格，目標(biāo)地址，數(shù)額和真正的交易數(shù)據(jù) 。合約代碼會(huì)檢查對(duì)交易gas限制和數(shù)據(jù)的簽名，然后檢查交易序號(hào)，如果兩者都沒(méi)有問(wèn)題就把保存的序號(hào)加一 ， 發(fā)送所需的消息 ， 然后發(fā)送另一條消息支付gas費(fèi)用作為結(jié)束(注意，礦工可以靜態(tài)分析賬戶的合約代碼，如果交易的賬戶合約最后沒(méi)有支付gas可以拒絕處理) 。
Serenity的這個(gè)改動(dòng)有一個(gè)很重要的后果，系統(tǒng)中的所有交易(只要滿足基本的格式)都是有效的 。現(xiàn)階段無(wú)效的交易在Serenity中將僅僅是沒(méi)有作用(上例中的invalid是一個(gè)尚未使用的操作碼，它會(huì)使程序執(zhí)行立即退出) 。這意味著交易被打包進(jìn)區(qū)塊不再是交易會(huì)被真正執(zhí)行的保證，作為彌補(bǔ)，每一筆交易都會(huì)有一條收據(jù)記錄(receipt entry) ， 通過(guò)返回碼指明它是否成功執(zhí)行：0表示由于gas限制交易沒(méi)有執(zhí)行，1表示交易執(zhí)行了但是出錯(cuò)，2表示交易成功執(zhí)行 。收據(jù)記錄還可以提供更多的信息，例如交易的返回值(現(xiàn)在有自動(dòng)日志記錄)或者自己創(chuàng)建的日志，
這個(gè)改動(dòng)最主要的好處是用戶可以在賬戶策略這個(gè)領(lǐng)域自由的創(chuàng)新了 。可能的方向包括：
比特幣風(fēng)格的多重簽名 ， 賬戶要求交易同時(shí)具有多個(gè)私鑰的簽名 ， 而不是一次接收一個(gè)簽名，然后把中間結(jié)果臨時(shí)存放在區(qū)塊鏈里 。
其他的橢圓曲線, 包括ed25519 。
更好的集成先進(jìn)的加密算法，例如環(huán)狀簽名(ring signature)，門(mén)限簽名(threshold signature), 零知識(shí)證明等等 。
更先進(jìn)的序號(hào)方案, 支持更高程度的并行化，讓用戶可以同時(shí)從一個(gè)賬戶發(fā)出多個(gè)交易，并且更快的把這些交易打包 。想想傳統(tǒng)的序號(hào)和位掩碼(bitmask)如果結(jié)合會(huì)怎樣 。我們也可以通過(guò)各種機(jī)智的方法在有效性檢查中利用時(shí)間戳或是區(qū)塊的hash值 。
基于UTXO的代幣管理, 有些用戶處于隱私的元應(yīng)，不喜歡以太坊使用賬戶而不是比特幣的“未使用的交易輸出”(unspent transaction output, UTXO)模型來(lái)管理代幣的所有權(quán) 。現(xiàn)在你可以在以太坊中建立一個(gè)事實(shí)上基于UTXO的系統(tǒng)了，并且Serenity不再顯式的特殊對(duì)待其中某一個(gè) 。
支付方案的創(chuàng)新，對(duì)于某些dapp, “由合約支付費(fèi)用”可能比“由使用者支付”更有用，使用者可能沒(méi)有以太幣 。現(xiàn)在dapp就可以實(shí)現(xiàn)這個(gè)支付模型了 。如果礦工能對(duì)它的代碼做靜態(tài)分析并確信他們可以得到報(bào)酬 ， 礦工就會(huì)接受這種交易(本質(zhì)上，我們實(shí)現(xiàn)了Rookstock想要通過(guò)可選的作者支付(author-pay)想做的事情，但是是通過(guò)一種更抽象和靈活的方法) 。
與“以太坊鬧鐘”之類的應(yīng)用更好的集成，賬戶的檢驗(yàn)代碼不一定要檢查簽名 ， 也可以檢查收據(jù)的Merkle proof，或是其他賬戶的狀態(tài)，等等 。
提出這些場(chǎng)景是為了說(shuō)明最主要的論點(diǎn) ， 通過(guò)抽象所有這些另外的機(jī)制都可以更加容易的實(shí)現(xiàn)，不再需要?jiǎng)?chuàng)造一個(gè)“傳遞層”來(lái)把信息喂給以太坊默認(rèn)的簽名體系 。當(dāng)沒(méi)有應(yīng)用是特殊的時(shí)候，每個(gè)應(yīng)用都特殊 。
一個(gè)特別有意思的結(jié)果是：在Serenity的設(shè)計(jì)下，以太坊將具有可選的量子安全性 。如果你害怕NSA秘密擁有一臺(tái)量子計(jì)算機(jī) ， 想要把自己的賬戶變得更安全，你隨時(shí)可以個(gè)人切換使用Lamport簽名 。轉(zhuǎn)換到PoS機(jī)制進(jìn)一步鞏固了安全性，即使世界上只有NSA有量子計(jì)算機(jī)他們也不能利用這一點(diǎn)來(lái)實(shí)施51%攻擊 。在以太坊的協(xié)議層唯一剩下的密碼學(xué)安全假設(shè)只有SHA3的抵御碰撞(collision-resistance)的性質(zhì)了 。
這些改變的另一個(gè)結(jié)果是 ， 交易數(shù)據(jù)會(huì)變得更加簡(jiǎn)單 。交易將會(huì)用四個(gè)字段取代現(xiàn)在的九個(gè)：目標(biāo)地址，數(shù)據(jù)，初始gas和初始化代碼 。目標(biāo)地址 ， 數(shù)據(jù)和初始gas和現(xiàn)在一樣，“初始化代碼”是一個(gè)可選用于保存目標(biāo)地址賬戶合約創(chuàng)建代碼的字段 。
需要這個(gè)機(jī)制的原因如下 。目前以太坊有一個(gè)重要的性質(zhì)，是允許往一個(gè)還不存在的賬戶轉(zhuǎn)賬 。為了在區(qū)塊鏈上創(chuàng)建一個(gè)合約接受以太幣，你并不需要事先持有任何以太幣 。為了在Serenity中實(shí)現(xiàn)這個(gè)性質(zhì)，我們讓賬戶地址能事先從它的初始化代碼中推導(dǎo)出來(lái)，通過(guò)公式sha3(creatorinitcode) % 2**160 。這里creator是創(chuàng)建這個(gè)合約的賬戶(默認(rèn)是地址為0的賬戶) ， 而initcode就是合約的初始化代碼(這段代碼的運(yùn)行結(jié)果會(huì)成為賬戶合約的代碼，正如現(xiàn)在的CREATE一樣) 。因此你可以在本地先生成這段初始化代碼，計(jì)算它的地址，然后讓其他人往這個(gè)地址轉(zhuǎn)賬 。然后一旦你想要從這個(gè)地址發(fā)出第一筆交易，你可以在交易里面包含這段初始化代碼 ， 它就會(huì)在真正的交易執(zhí)行之前，被自動(dòng)執(zhí)行并創(chuàng)建賬戶(這段邏輯的實(shí)現(xiàn)代碼在這里) 。
區(qū)塊的抽象
Serenity中將實(shí)現(xiàn)的另一個(gè)干凈的分離是將區(qū)塊(僅僅是一堆交易)，狀態(tài)(例如合約的存儲(chǔ)區(qū) ， 代碼和賬戶余額)和共識(shí)層完全分開(kāi) 。共識(shí)激勵(lì)在合約內(nèi)部實(shí)現(xiàn)，而如果你希望激勵(lì)的話，共識(shí)級(jí)別的對(duì)象(例如PoW, 賭注)應(yīng)該被包含在發(fā)往“共識(shí)激勵(lì)管理合約”的交易中 。
這應(yīng)該會(huì)讓你更容易用其它的共識(shí)算法 - Tendermint, HoneyBadgeBFT, subjective consensus甚至是普通的PoW - 替換掉Serenity代碼中的Casper 。我們非常歡迎這個(gè)方向的研究，并且希望能做到最大的靈活 。
存儲(chǔ)的抽象
目前，以太坊系統(tǒng)的“狀態(tài)”數(shù)據(jù)實(shí)際上相當(dāng)復(fù)雜 ， 包括這些部分：
余額，代碼，nonce，和賬戶存儲(chǔ)區(qū)
Gas上限，難度 ， 塊高度，時(shí)間戳
最后256個(gè)塊的hash值
在執(zhí)行區(qū)塊內(nèi)代碼時(shí) ， 需要保存交易索引，收據(jù)樹(shù)(receipt tree, receipt是EVM中的一個(gè)概念)和當(dāng)前消耗的gas 。
這些數(shù)據(jù)結(jié)構(gòu)存在于許多地方，包括塊狀態(tài)轉(zhuǎn)移函數(shù)，狀態(tài)樹(shù)，區(qū)塊頭和前一個(gè)區(qū)塊頭中 。在Serenity里面這些將被大幅簡(jiǎn)化：雖然許多數(shù)據(jù)仍然會(huì)存在 ， 但他們會(huì)被轉(zhuǎn)移到特殊的合約中去;因此，唯一的”“狀態(tài)”將以一棵樹(shù)的形式繼續(xù)存在，數(shù)學(xué)上可以看作是形如{address: {key: value}}的映射 。賬戶將是一些樹(shù) ， 賬戶合約代碼會(huì)被存放在主鍵(key)為的地方(SSTORE不可以修改)，余額會(huì)存在特別的“以太幣合約”中，而序號(hào)將由每一個(gè)帳號(hào)自己決定如何保存 。收據(jù)也將被轉(zhuǎn)移到合約存儲(chǔ)區(qū)，他們會(huì)被保存在一個(gè)內(nèi)容在每個(gè)區(qū)塊都會(huì)被覆蓋的“日志合約”中 。
這樣代碼實(shí)現(xiàn)中的狀態(tài)對(duì)象可以極大的簡(jiǎn)化 。現(xiàn)在只剩下一個(gè)兩級(jí)的trie了 。可伸縮性方面的升級(jí)可能要求增加為三級(jí)trie(分片ID, 地址，主鍵) ， 這還沒(méi)有確定，但即使是這樣復(fù)雜性也遠(yuǎn)低于現(xiàn)在 。
需要注意 ， 把以太幣轉(zhuǎn)移進(jìn)一個(gè)合約管理并不是以太幣抽象的全部 。事實(shí)上，一個(gè)有爭(zhēng)議的看法是相對(duì)于現(xiàn)狀這并不是一個(gè)很大的進(jìn)步 ， 因?yàn)闉榱讼蚯凹嫒菽切┖鸵蕴珟畔嚓P(guān)的操作碼(帶value參數(shù)的CALL，BALANCE等等)依然保留著 。某種程度上說(shuō)，這只是數(shù)據(jù)存放的一次重組 。
未來(lái)的計(jì)劃
在第二個(gè)概念原型中，我們計(jì)劃讓抽象更進(jìn)一步 。目前區(qū)塊和交易級(jí)別的狀態(tài)轉(zhuǎn)移函數(shù)依然有相當(dāng)?shù)膹?fù)雜性(例如更新收據(jù)，gas限制，交易索引，區(qū)塊高度 ， 狀態(tài)根節(jié)點(diǎn))，我們的目標(biāo)是為交易創(chuàng)建一個(gè)“入口”對(duì)象來(lái)處理所有這些每一個(gè)交易都需要的額外的“樣板邏輯”，以及“塊開(kāi)始”和“塊結(jié)束”的入口 。理論上的終極目標(biāo)，是找到一個(gè)只有一個(gè)入口點(diǎn)的協(xié)議 ， 這樣狀態(tài)轉(zhuǎn)移函數(shù)只需要從零地址發(fā)送一條包含區(qū)塊內(nèi)容數(shù)據(jù)的消息給入口點(diǎn)即可 。這樣做的目的是盡可能的減少客戶端實(shí)現(xiàn)的共識(shí)關(guān)鍵部分(consensus-critical client implementation)的大?。?把盡可能多的邏輯推到以太坊自身上去 。這樣即使為了達(dá)到我們對(duì)交易速度和可伸縮性的目標(biāo)，我們需要采用一個(gè)接受硬分叉和一定的新復(fù)雜度的激進(jìn)開(kāi)發(fā)制度 ， 也能夠個(gè)確保以太坊的多重客戶端形態(tài)可以持續(xù)而無(wú)需大量額外開(kāi)發(fā)工作和安全審計(jì) 。
長(zhǎng)期來(lái)看 ， 我打算繼續(xù)在python上開(kāi)發(fā)概念原型，Casper團(tuán)隊(duì)則共同改進(jìn)協(xié)議的效率，并證明它的安全性和正確性 。在某個(gè)時(shí)刻，這個(gè)協(xié)議將成熟到足以處理一個(gè)公開(kāi)的某種形式的測(cè)試網(wǎng)絡(luò)，其上可能會(huì)有真實(shí)的價(jià)值 ， 為人們找出Casper的漏洞提供激勵(lì)，就像一條真正的鏈不可避免的遭受的那樣 。這只是第一步，不過(guò)是非常重要的一步 ， 它標(biāo)志著我們對(duì)于權(quán)益證明和深度抽象的研究終于從談話，白板上的數(shù)學(xué)公式和博客文章變成了能工作的代碼 。
這個(gè)系列的下一篇文章將會(huì)討論Serenity的另一個(gè)旗艦特性，Casper共識(shí)算法 。
以上就是關(guān)于Serenity - 第一部分: 深度抽象的相關(guān)介紹 ， 希望小編的內(nèi)容能幫到大家!


相關(guān)經(jīng)驗(yàn)推薦