以太坊隱藏欄位

『壹』 以太坊我是a段投資有風險嗎

有風險。
因為虛擬財產在有的國家是受法律保護的。但大多數國家對於虛擬貨幣的監管力度還是不夠的，這也使得投資虛擬貨幣存在較大的風險，所以投資者需要謹慎對待。
投資以太坊是安全的，所謂的不安全，主要是因為類似以太坊的數字貨幣是網路安全犯罪的熱門目標，因為黑客能輕易地隱藏自己的蹤跡，並且不受中央銀行或政府的監管。由於加密貨幣沒有實物商品的支持，被黑客攻擊的投資者也就沒有任何法律或刑事追索權。
其中一個最大的問題是，罪犯很難被抓獲，因為他們藏匿於網路，並且搶劫也很猖獗。網路安全專家說，隨著首次代幣發行的數量增加，黑客黑入交易所，比如Coinbase或個人錢包等事件也反映了此類情況。全文導讀：根據區塊鏈數據顯示，BitMEX交易所目前資產為32億美元，共有14個交易對，幣種數量為8個，24小時成交額為20.97億美元，通過這些數據可以看出，BitMEX交易所還是比較受投資者歡迎的，不過對於部分投資者來說並不了解BitMEX。

『貳』 CentOS 中 /etc/sysconfig/network-scripts/ifcfg-eth0 中哪些欄位是必須的 比如 NETWORK和BROADCAST

DEVICE=eth0
ONBOOT=yes
這兩個是必備的。
如果你是自動獲取ip，加上
BOOTPROTO=dhcp
如果是手動配置。
BOOTPROTO=static
IPADDR=xxxxx IP
NETMASK= 掩碼
GATEWAY= 網關
DNS1= DNS

『叄』 以太坊區塊鏈之Bug --2020/05/19

為了防止交易重播，ETH（ETC）節點要求每筆交易必須有一個nonce數值。每一個賬戶從同一個節點發起交易時，這個nonce值從0開始計數，發送一筆nonce對應加1。當前面的nonce處理完成之後才會處理後面的nonce。注意這里的前提條件是相同的地址在相同的節點發送交易。

以下是nonce使用的幾條規則：

● 當nonce太小（小於之前已經有交易使用的nonce值），交易會被直接拒絕。

● 當nonce太大，交易會一直處於隊列之中，這也就是導致我們上面描述的問題的原因；

● 當發送一個比較大的nonce值，然後補齊開始nonce到那個值之間的nonce，那麼交易依舊可以被執行。

● 當交易處於queue中時停止geth客戶端，那麼交易queue中的交易會被清除掉。

         第一個欄位 AccountNonce ，直譯就是賬戶隨機數。它是以太坊中很小但也很重要的一個細節。以太坊為每個賬戶和交易都創建了一個Nonce，當從賬戶發起交易的時候，當前賬戶的Nonce值就被作為交易的Nonce。這里，如果是普通賬戶那麼Nonce就是它發出的交易數，如果是合約賬戶就是從它的創建合約數。

為什麼要使用這個Nonce呢？其主要目的就是為了防止重復攻擊（Replay Attack）。因為交易都是需要簽名的，假定沒有Nonce，那麼只要交易數據和發起人是確定的，簽名就一定是相同的，這樣攻擊者就能在收到一個交易數據後，重新生成一個完全相同的交易並再次提交，比如A給B發了個交易，因為交易是有簽名的，B雖然不能改動這個交易數據，但只要反復提交一模一樣的交易數據，就能把A賬戶的所有資金都轉到B手裡。

當使用賬戶Nonce之後，每次發起一個交易，A賬戶的Nonce值就會增加，當B重新提交時，因為Nonce對不上了，交易就會被拒絕。這樣就可以防止重復攻擊。當然，事情還沒有完，因為還能跨鏈實施攻擊，直到EIP-155引入了chainID，才實現了不同鏈之間的交易數據不兼容。事實上，Nonce並不能真正防止重復攻擊，比如A向B買東西，發起交易T1給B，緊接著又提交另一個交易T2，T2的Gas價格更高、優先順序更高將被優先處理，如果恰好T2處理完成後剩餘資金已經不足以支付T1，那麼T1就會被拒絕。這時如果B已經把東西給了A，那A也就攻擊成功了。所以說，就算交易被處理了也還要再等待一定時間，確保生成足夠深度的區塊，才能保證交易的不可逆。

Price 指的是單位Gas的價格，所謂Gas就是交易的消耗，Price就是單位Gas要消耗多少以太幣（Ether），Gas * Price就是處理交易需要消耗多少以太幣，它就相當於比特幣中的交易手續費。

GasLimit 限定了本次交易允許消耗資源的最高上限，換句話說，以太坊中的交易不可能無限制地消耗資源，這也是以太坊的安全策略之一，防止攻擊者惡意佔用資源。

Recipient 是交易接收者，它是common.Address指針類型，代表一個地址。這個值也可以是空的，這時在交易執行時，會通過智能合約創建一個地址來完成交易。

Amount 是交易額。這個簡單，不用解釋。

Payload 比較重要，它是一個位元組數組，可以用來作為創建合約的指令數組，這時每個位元組都是一個單獨的指令；也可以作為數據數組，由合約指令來進行操作。合約由以太坊虛擬機（Ethereum Virtual Machine，EVM）創建並執行。

V、R、S 是交易的簽名數據。以太坊當中，交易經過數字簽名之後，生成的signature是一個長度65的位元組數組，它被截成三段，前32位元組被放進R，再32位元組放進S，最後1個位元組放進V。那麼為什麼要被截成3段呢？以太坊用的是ECDSA演算法，R和S就是ECSDA簽名輸出，V則是Recovery ID。

R,S,V是交易簽名後的值，它們可以被用來生成簽名者的公鑰；R，S是ECDSA橢圓加密演算法的輸出值，V是用於恢復結果的ID

『肆』 以太坊交易(tx) 分析

更多請參考: Github: https://github.com/xianfeng92/ethereum-code-analysis

其中 object 和 opcodes 是相對應的，比如 60 對應就是 operation PUSH1,合約編譯後的位元組碼即為一組的 operation 。

合約部署其實就是實例化一個 contract 對象，並將 data 的值設給 Code屬性 。

創建合約的tx中，input欄位對應的是合約的位元組碼，即指令數組。

其中 input 欄位對應所要調用的函數簽名的前四個位元組（771602f7）以及對應的參數（1,2）

其中 input 欄位為所要調用的合約函數簽名的前四個位元組（72a099b7）

關於函數調用，Call會把對應的Code讀出來，依次解析，Code中會把所有的public簽名的函數標志（4位元組）push到棧里。然後依據 input 中需要調用函數的簽名標志（前4位元組）來匹配 Code， 匹配之後跳轉到對應的 opcode 。

『伍』 以太坊中的國際銀行賬號iban

簡單地說，以太坊中的iban賬號是以太坊為了和傳統的銀行系統對接而引入的概念，web3.js中提供了以太坊地址和iban地址之間的轉換方法。

iban這個概念源於傳統的銀行系統，其英文全稱為 International Bank Account Number ，即國際銀行帳號。iban的作用是為全球任意一家銀行中的任意一個賬戶生成一個全球唯一的賬號，以便進行跨行交易。一個iban賬號看起來像這樣：

iban地址最多可以包含34個字母和數字，其中的字母大小寫不敏感。在iban
中包含以下信息：

以太坊引入了一個新的IBAN國別碼：XE，其中E代表Ethereum，X代表非法幣（non-jurisdictional currencies）。同時，以太坊提出了三種BBAN的編碼格式：direct、basic和indirect。

direct編碼方案中的BBAN為30個字母/數字，只有一個欄位：賬戶編號。例如，以太坊地址 轉換為direct方案的BBAN賬號，就得到 。

可以使用web3.js中的 web3.eth.Iban.fromEthereumAddress()
方法來執行這一轉換：

basic編碼方案與direct方案的唯一區別在於，其BBAN長度為31個字母/數字，因此該方案不兼容IBAN。

indrect編碼方案中的BBAN長度為16個字母/數字，包含三個欄位：

例如，一個採用indrect編碼方案的以太坊iban賬號，看起來是這樣：

前面的 XE 表示國別碼， 81 為校驗和，後面的16個字元就是indrect編碼的BBAN，其中：

如前所述，使用 web3.eth.Iban.fromEthereumAddress() 方法，可以將一個以太坊地址轉換為direct編碼方案的iban賬號。與之對應的，可以使用 web3.eth.Iban.toAddress 方法，將一個採用direct編碼方案的iban賬號，轉換回以太坊地址。例如：

iban賬號中的校驗和用來幫助核驗一個給定字元串是否為有效的iban賬號。可以使用web3.js中的 web3.eth.Iban.isValid()
來進行執行校驗。例如：

原文： http://blog.hubwiz.com/2018/06/03/ethereum-iban/

『陸』 以太幣挖礦，用什麼來挖

以太幣挖礦教程

1、在硬碟上新建文件夾，比C:Eth。之後所有挖礦軟體就存放在這里。

2、下載以下軟體

1)Geth——選擇Geth-Win下載然後解壓

2)Ethminer——下載解壓到同一個文件夾，重命名為「miner」

3)Ethereum Wallet(以太坊錢包)——下載Win以太坊錢包，解壓之後重命名「wallet」

安裝好所有軟體

3、打開命令提示符(同時點擊Win和R鍵或者點擊開始菜單然後輸入cmd)。命令提示符是命令行解析器，讓你在操作系統中執行命令輸入的軟體。

之後你就擁有以太坊錢包了。但是沒有餘額，所以接下來你需要建立ethminer。暫時可以最小化錢包了。

挖礦

『柒』 Quorum介紹

Quorum和以太坊的主要區別:

Quorum 的主要組件：

1,用其自己實現的基於投票機制的共識方式 來代替原來的 「Proof of work」 。
2,在原來無限制的P2P傳輸方式上增加了許可權功能。使得P2P傳輸只能在互相允許的節點間傳輸。
3, 修改區塊校驗邏輯使其能支持 private transaction。
4, Transaction 生成時支持 transaction 內容的替換。這個調整是為了能支持聯盟中的私有交易。

Constellation 模塊的主要職責是支持 private transaction。Constellation 由兩部分組成：Transaction Manager 和 Enclave。Transaction Manager 用來管理和傳遞私有消息，Enclave 用來對私有消息的加解密。

在私有交易中，Transaction Manager 會存儲私有交易的內容，並且會將這條私有交易內容與其他相關的 Transaction Manager 進行交互。同時它也會利用 Enclave 來加密或解密其收到的私有交易。

為了能更有效率的處理消息的加密與解密，Quorum 將這個功能單獨拉出並命名為 Enclave 模塊。Enclave 和 Transaction Manager 是一對一的關系。

在 Quorum 中有兩種交易類型，」Public Transaction」 和 「Privat Transaction」。在實際的交易中，這兩種類型都採用了以太坊的 Transaction 模型，但是又做了部分修改。Quorum 在原有的以太坊 tx 模型基礎上添加了一個新的 「privateFor」 欄位。同時，針對一個 tx 類型的對象添加了一個新的方法 「IsPrivate」。用 「IsPrivate」 方法來判斷 Transaction是 public 還是 private，用 「privateFor」 來記錄 事務只有誰能查看。

Public Transaction 的機理和以太坊一致。Transaction中的交易內容能被鏈上的所有人訪問到。

Private Transaction 雖然被叫做 「Private」，但是在全網上也會出現與其相關的交易。只不過交易的明細只有與此交易有關系的成員才能訪問到。在全網上看到的交易內容是一段hash值，當你是交易的相關人員時，你就能利用這個hash值，然後通過 Transaction Manager 和 Enclave 來獲得這筆交易的正確內容。

Public Transaction的處理流程和以太坊的Transaction流程一致。Transaction 廣播全網後，被礦工打包到區塊中。節點收到區塊並校驗區塊中的 事務 信息。然後根據 Transaction信息更新本地的區塊

Private Transaction也會將 Transaction 廣播至全網。但是它的 Transaction payload已經從原來的真實內容替換為一個hash值。這個hash值是由Transaction Manager提供的。

有兩個共識機制：QuorumChain Consensus 和 Raft-Based Consensus。
在 Quorum 1.2 之前的 Release 版本都採用了 QuorumChain。
從 2.0 版本開始，Quorum 廢棄了 QuorumChain 轉而只支持 Raft-based Consensus。

QuorumChain Consensus 是一個基於投票的共識演算法。其主要特點有：

相比較以太坊的POW，Raft-based 提供了更快更高效的區塊生成方式。相比 QuorumChain，Raft-based 不會產生空的區塊，而且在區塊的生成上比前者更有效率。

要想了解Raft-based Consensus，必須先了解Raft演算法

Raft演算法
Raft是一種一致性演算法，是為了確保容錯性，也就是即使系統中有一兩個伺服器當機，也不會影響其處理過程。這就意味著只要超過半數的大多數伺服器達成一致就可以了，假設有N台伺服器，N/2 +1 就超過半數，代表大多數了。
Raft的工作模式：
raft的工作模式是一個Leader和多個Follower模式，即我們通常說的領導者-追隨者模式。除了這兩種身份，還有Candidate身份。下面是身份的轉化示意圖

1，leader的選舉過程
raft初始狀態時所有server都處於Follower狀態，並且隨機睡眠一段時間，這個時間在0~1000ms之間。最先醒來的server A進入Candidate狀態，Candidate狀態的server A有權利發起投票，向其它所有server發出投票請求，請求其它server給它投票成為Leader。
2，Leader產生數據並同步給Follower
Leader產生數據，並向其它Follower節點發送數據添加請求。其它Follower收到數據添加請求後，判斷該append請求滿足接收條件（接收條件在後面安全保證問題3給出），如果滿足條件就將其添加到本地，並給Leader發送添加成功的response。Leader在收到大多數Follower添加成功的response後。提交後的log日誌就意味著已經被raft系統接受，並能應用到狀態機中了。

Leader具有絕對的數據產生權利，其它Follower上存在數據不全或者與Leader數據不一致的情況時，一切都以Leader上的數據為主，最終所有server上的日誌都會復製成與Leader一致的狀態。

Raft的動態演示： http://thesecretlivesofdata.com/raft/

安全性保證，對於異常情況下Raft如何處理：

1，Leader選舉過程中，如果有兩個FollowerA和B同時醒來並發出投票請求怎麼辦？
在一次選舉過程中，一個Follower只能投一票，這就保證了FollowerA和B不可能同時得到大多數（一半以上）的投票。如果A或者B中其一幸運地得到了大多數投票，就能順利地成為Leader，Raft系統正常運行下去。但是A和B可能剛好都得到一半的投票，兩者都成為不了Leader。這時A和B繼續保持Candidate狀態，並且隨機睡眠一段時間，等待進入到下一個選舉周期。由於所有Follower都是隨機選擇睡眠時間，所以連續出現多個server競選的概率很低。
2，Leader掛了後，如何選舉出新的Leader？
Leader在正常運行時候，會周期性的向Follower節點發送數據的同步請求，同時也是起到一個心跳作用。Follower節點如果在一段時間之內（一般是2000ms左右）沒有收到數據同步請求，則認為Leader已經死了，於是進入到Candidate狀態，開始發起投票競選新的Leader，每個新的Leader產生後就是一個新的任期，每個任期都對應一個唯一的任期號term。這個term是單調遞增的，用來唯一標識一個Leader的任期。投票開始時，Candidate將自己的term加1，並在投票請求中帶上term；Follower只會接受任期號term比自己大的request_vote請求，並為之投票。 這條規則保證了只有最新的Candidate才有可能成為Leader。

3，Follower的數據的生效時間
Follower在收到一條添加數據請求後，是否立即保存並將其應用到狀態機中去？如果不是立即應用，那麼由什麼來決定該條日誌生效的時間？
首先會檢查這條數據同步請求的來源信息是否與本地保存的leader信息符合，包括leaderId和任期號term。檢查合法後就將日誌保存到本地中，並給Leader回復添加log成功，但是不會立即將其應用到本地狀態機。Leader收到大部分Follower添加log成功的回復後，就正式將這條日誌commit提交。Leader在隨後發出的心跳append_entires中會帶上已經提交日誌索引。Follower收到Leader發出的心跳append_entries後，就可以確認剛才的log已經被commit(提交)了，這個時候Follower才會把日誌應用到本地狀態機。下表即是append_entries請求的內容，其中leaderCommit即是Leader已經確認提交的最大日誌索引。Follower在收到Leader發出的append_entries後即可以通過leaderCommit欄位決定哪些日誌可以應用到狀態機。

4，向raft系統中添加新機器時，由於配置信息不可能在各個系統上同時達到同步狀態，總會有某些server先得到新機器的信息，有些server後得到新機器的信息。比如在raft系統中有三個server，在某個時間段中新增加了server4和server5這兩台機器。只有server3率先感知到了這兩台機器的添加。這個時候如果進行選舉，就有可能出現兩個Leader選舉成功。因為server3認為有3台server給它投了票，它就是Leader，而server1認為只要有2台server給它投票就是Leader了。raft怎麼解決這個問題呢？

產生這個問題的根本原因是，raft系統中有一部分機器使用了舊的配置，如server1和server2，有一部分使用新的配置，如server3。解決這個問題的方法是添加一個中間配置(Cold, Cnew)，這個中間配置的內容是舊的配置表Cold和新的配置Cnew。這個時候server3收到添加機器的消息後，不是直接使用新的配置Cnew，而是使用(Cold, Cnew)來做決策。比如說server3在競選Leader的時候，不僅需要得到Cold中的大部分投票，還要得到Cnew中的大部分投票才能成為Leader。這樣就保證了server1和server2在使用Cold配置的情況下，還是只可能產生一個Leader。當所有server都獲得了添加機器的消息後，再統一切換到Cnew。raft實現中，將Cold，(Cold,Cnew)以及Cnew都當成一條普通的日誌。配置更改信息發送Leader後，由Leader先添加一條 (Cold, Cnew)日誌，並同步給其它Follower。當這條日誌(Cold, Cnew)提交後，再添加一條Cnew日誌同步給其它Follower，通過Cnew日誌將所有Follower的配置切換到最新。

Raft演算法和以太坊結合
所以為了連接以太坊節點和 Raft 共識，Quorum 採用了網路節點和 Raft 節點一對一的方式來實現 Raft-based 共識

一個Transaction完整流程
1，客戶端發起一筆 Transaction並通過 RPC 來呼叫節點。
2，節點通過以太坊的 P2P 協議將節點廣播給網路。
3，當前的 Raft leader 對應的以太坊節點收到了 Transaction後將它打包成區塊。
區塊被 編碼後傳遞給對應的 Raft leader。
leader 收到區塊後通過 Raft 演算法將區塊傳遞給 follower。這包括如下步驟：
3.1，leader 發送 AppendEntries 指令給 follower。
3.2，follower 收到這個包含區塊信息的指令後，返回確認回執給 leader。
3.3，leader 收到不少於指定數量的確認回執後，發送確認 append 的指令給 follower。
3.4，follower 收到確認 append 的指令後將區塊信息記錄到本地的 Raft log 上。
3.5，Raft 節點將區塊傳遞給對應的 Quorum 節點。Quorum 節點校驗區塊的合法性，如果合法則記錄到本地鏈上。

參考鏈接： http://blog.csdn.net/about_blockchain/article/details/78684901

『捌』 以太坊event log查詢與解析

從 ethereum json-rpc文檔 的文檔中找到一個同時指定多個事件以 OR 或者 AND 查詢的方法.以下是查詢 Approval 或 Transfer 事件的方法：

topics 欄位中指定查詢條件的語法參考上面鏈接。

通過 getTransactionReceipt 在ropsten測試網上查詢到交易號為 的交易詳情

這個交易從 "from": "" 發送到合約地址 "to": "" .這個合約為ERC20代幣合約.從 topics 的第一個元素可以看出合約中產生了 Transfer 事件(topics第一個元素一定是事件的keccak哈希). topics 的第二個欄位是轉出代幣的地址，第三個欄位是接收者地址.ERC20代幣 Transfer 事件的簽名為

我們注意到 Transfer 事件的第一個和第二個參數被標記為 indexed , 因此他們的值被放在 topics array 中. 由於tokens參數沒有標記為 indexed , 所以他的值被放在 data 欄位. 如果事件中有多個欄位未標記為 indexed ， 那麼他們的值都會被記錄在 data 欄位中。

『玖』 以太坊的ABI編碼

ABI全稱Application Binary Interface, 是調用智能合約函數以及合約之間函數調用的消息編碼格式定義,也可以理解為智能合約函數調用的介面說明. 類似Webservice里的SOAP協議一樣；也就是定義操作函數簽名，參數編碼，返回結果編碼等。

使用ABI協議時必須要求在編譯時知道類型,即強類型相關.

當一個智能合約編譯出來後, 他的abi介面定義就確定了. 比如下面的智能合約:

生成的位元組碼:

生成的abi定義:

可以看出, 生成abi包含了2個定義: 函數 lotus , 事件 Log_lotus , 各個欄位含義見上. 根據該abi定義,就可以生成調用該智能合約函數的abi格式的數據了.

格式簡單的可以表示為: 函數選擇器+參數編碼

一個函數調用的前四個位元組數據指定了要調用的函數簽名。計算方式是使用函數簽名的 keccak256 的哈希，取4個位元組。

函數名如果有多個參數使用,隔開，要去掉表達式中的所有空格。在geth客戶端,通過命令可以得到hash:

由於前面的函數簽名使用了四個位元組，參數的數據將從第五個位元組開始。

根據參數類型,編碼規則有所區別:

除了bytes,和string, 其他類型的數據不足32位元組長度的需要加0補足32位元組. 動態長度的編碼在例子中介紹.

函數: function baz(uint32 x, bool y) :

調用: baz(69, true)

生成的數據如下:

返回結果是一個bool值，在這里，返回的是false:

函數: f(uint,uint32[],bytes10,bytes)

調用: (0x123, [0x456, 0x789], "1234567890", "Hello, world!")

函數選擇器: bytes4(sha3("f(uint256,uint32[],bytes10,bytes)"))

對於 固定大小的類型 值 uint256 和 bytes10 ，直接編碼值。

對於 動態內容類型 值 uint32[] 和 bytes ，我們先 編碼偏移值 ，偏移值是整個值編碼的開始到真正存這個數據的偏移值（這里不計算頭四個用於表示函數簽名的位元組）。

所以參數編碼數據依次為：

尾部部分的第一個動態參數， [0x456, 0x789] 編碼拆解如下：

最後我們來看看第二個動態參數的的編碼， Hello, world! 。

所以最終結果是:

『拾』 比特幣區塊里的各個欄位含義(先寫了個nonce)

nonce是個啥意思？根據bitcoin wiki

nonce是一個4-byte大小的區域，nonce的值設定使得該塊的hash是以一串0開頭的。
對於塊數據的一點點改變（比如nonce）都會引起block hash的巨大變化。由於逆向預測hash值相對應的一組bit值（hash原文）是不可行的，在嘗試足夠多的nonce值且計算每個nonce值相對應的block hash之後可以找到一個滿足有指定數量 0 bits (0比特位) 的hash值。而 0 bits的數量值是由difficult設定的。最終產生的hash須得是一個小於當前difficulty值。
因為這個迭代的計算耗費時間和資源，塊的出現也就是得到了正確的nonce值，這構成了 proof of work

關於以太坊里的nonce 網上很多解釋，很多一上來就是 交易計數器 ， 然而卻把跟POW有關的丟了嗎？事實上以太坊里的nonce有兩種意思，一個是proof of work nonce，一個是account nonce。

那智能合約呢？合約也算是Account的一種，那也有nonce嗎？

是的，而且合約裡面的nonce也差不多，也是一個counter。在智能合約里，nonce的值代表的是該合約創建的合約數量。只有當一個合約創建另一個合約的時候才會增加nonce的值。但是當一個合約調用另一個合約中的method時 nonce的值是不變的。

在以太坊中nonce的值可以這樣來獲取（其實也就是屬於一個賬戶的交易數量）：

但是這個方法只能獲取交易once的值。目前是沒有內置方法來訪問contract中的nonce值的，除了自己定義一個counter來計數...

那好，再來看一下Ethereum Block中的nonce：
以太坊和比特幣區塊鏈一樣，也需要proof of work（計劃轉移到股份證明也早已在做了）。在比特幣區塊鏈中，pow應該是要算出一個符合難度要求的值，通常是以一串0開頭的。這個難度一直在變化。可以查看 比特幣區塊鏈的POW難度變化 。