Build Hyperledger Fabric 1.0

下面列舉了我在搭建過程中遇到的一些問題、思考以及解決方法

其實搭建最好參考官方文檔，這篇博文隻是一個文檔沒有覆寫的補充

1.

[email protected]:~/docker$ sudo apt install docker.io
E: Could not get lock /var/lib/dpkg/lock - open (: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
           

solution

root@ubuntu:/home/jason/docker# ps -A | grep apt
   ?        :: aptd
   ?        :: aptd
   ?        :: apt-check
root@ubuntu:/home/jason/docker# sudo kill -SIGKILL 2121
root@ubuntu:/home/jason/docker# sudo kill -SIGKILL 2841
root@ubuntu:/home/jason/docker# sudo kill -SIGKILL 2889
root@ubuntu:/home/jason/docker# ps -A | grep apt
root@ubuntu:/home/jason/docker# apt-get install dock.io
           

2.

sudo apt-get update
           

solution:

https://askubuntu.com/questions/854168/how-i-can-fix-appstream-cache-update-completed-but-some-metadata-was-ignored-d/854256

3.

solution

sudo  apt-get update
sudo apt-get upgrade --fix-missing
           

4.

./byfn.sh -m up

Error building images: Tag latest not found in repository docker.io/hyperledger/fabric-peer

           

步驟一：

Pull a specific base image from https://hub.docker.com/r/hyperledger/fabric-peer/ using docker pull hyperledger/fabric-peer:

我到https://hub.docker.com/r/hyperledger/fabric-peer/tags/上看了的确沒有latest的tag，然後看到tag主要分為以下三類：

1. ppc64le（POWER Architecture 體系

   是RISC指令集的CPU）

2. x86_64（AMD64 一種64位元的電腦處理器架構。它是建基於現有32位元的x86架構，由AMD公司所開發）
3. s390x（IBM System z 系列 (zSeries)大型機 (mainframe) 硬體平台）

我認為我pull x86_64的版本到本地

docker pull hyperledger/fabric-peer:ppc64le-1.0.0

然後可以通過docker show images看結果

步驟二

Tag this image as latest docker

docker tag hyperledger/fabric-peer:ppc64le-  hyperledger/fabric-peer:latest
           

可以通過docker images檢視結果

删除某個鏡像的方法：docker rmi -f hyperledger/fabric-peer:latest

更多的docker指令

5.

如果chaincode陷入死循環，有什麼hyperledger有什麼機制嗎？

從目前的資料看來，hyperledger上沒有提及，貌似把鍋甩給了endoser peer。

下面是一些讨論：

https://github.com/hyperledger-archives/fabric/issues/2232

6.

Hyperledger1.0有個很詭異的地方，orderer會認為client提供的都是endoserment，但其實client完全可以随便扔個東西給orderer，但orderer都會把其打包發送給所有的peer（包括orderer peer和committer peer），然後這些peer再判斷這個交易是否合法，然後标記上位掩碼。

何為非法交易：i.e., transactions with invalid endorsement or with invalid version dependencies

這樣的話，client可以造出很多假的endoserment，造成區塊大部分存儲了非法交易

下面是一些或許的解決方法，但是peer ledger是不再存儲了嗎？是隻存vledger？最後即使這樣也可以讓orderer瞎忙活！

http://hyperledger-fabric.readthedocs.io/en/latest/arch-deep-dive.html（4 (post-v1). Validated ledger and PeerLedger checkpointing (pruning)）

7.

新的結點加入，找誰去同步？

應該是向orderer請求同步，因為orderer不檢出交易的有效性，新的peer同步的也是包含非法交易的peer ledger。

8.

chaincode能夠互相調用?

State created by a chaincode is scoped exclusively to (專屬于) that chaincode and can’t be accessed directly by another chaincode. However, within the same network, given the appropriate permission a chaincode may invoke another chaincode to access its state.

The other interface in the chaincode “shim” APIs is the ChaincodeStubInterface which is used to access and modify the ledger, and to make invocations between chaincodes.

9.

當你下載下傳編寫chaincode時需要的依賴包shime時出錯（如下圖），因為ubuntu apt-get預設的是glang-1.6.x的版本，而我們需要的是glang-1.7.x的版本（需要手動下載下傳）。

删除安裝的golang：

apt-get remove xxxx //解除安裝但不删除配置

apt-get purge xxxx //解除安裝并且删除相關配置

# 注意删除後環境變量還在的，需要好好修改
apt-get purge golang
apt autoremove
           

關于環境變量：

1. GOROOT
2. GOPATH

如何修改環境變量：

修改~/.bashrc（terminal啟動是時候會自動加載這個腳本）

# GOROOT是golang的安裝位址
export GOROOT=$HOME/go
# GOPATH是個人工作空間，下載下傳的第三方包等都會在這個路徑下
export GOPATH=$HOME/go/goproject
# 把路徑$GOROOT/bin添加到路徑PATH中
export PATH=$PATH:$GOROOT/bin

source ~/.bashrc
           

更多

1. 在Hyperledger的網絡初始部署，容器peer, cli, orderer由相應的鏡像所生成，而在此部署則不會重新生成，而網絡部署後可能你突然中斷網絡之類的，導緻容器情況異常，容器可能不能再被通路。

解決方法：

1. 利用docker ps -a檢視所有的容器情況

2. 利用docker rm -f container_id删除所有的id

3. 重新部署網絡

關于docker常用指令

10.

SDK 與 API 的聯系和差別

11.

HA Proxy

LDAP

libtool

https://www.gnu.org/software/libtool/manual/libtool.html

libltdl

動态連結庫

12.

LevelDB和CouchDB的選擇

State database options include LevelDB and CouchDB (beta). LevelDB is the default key/value state database embedded in the peer process. CouchDB is an optional alternative external state database. Like the LevelDB key/value store, CouchDB can store any binary data that is modeled in chaincode (CouchDB attachment functionality is used internally for non-JSON binary data). But as a JSON document store, CouchDB additionally enables rich query against the chaincode data, when chaincode values (e.g. assets) are modeled as JSON data.

Both LevelDB and CouchDB support core chaincode operations such as getting and setting a key (asset), and querying based on keys. Keys can be queried by range, and composite keys can be modeled to enable equivalence queries against multiple parameters. For example a composite key of (owner,asset_id) can be used to query all assets owned by a certain entity. These key-based queries can be used for read-only queries against the ledger, as well as in transactions that update the ledger.

If you model assets as JSON and use CouchDB, you can also perform complex rich queries against the chaincode data values, using the CouchDB JSON query language within chaincode. These types of queries are excellent for understanding what is on the ledger. Proposal responses for these types of queries are typically useful to the client application, but are not typically submitted as transactions to the ordering service. In fact, there is no guarantee the result set is stable between chaincode execution and commit time for rich queries, and therefore rich queries are not appropriate for use in update transactions, unless your application can guarantee the result set is stable between chaincode execution time and commit time, or can handle potential changes in subsequent transactions. For example, if you perform a rich query for all assets owned by Alice and transfer them to Bob, a new asset may be assigned to Alice by another transaction between chaincode execution time and commit time, and you would miss this ‘phantom’ item.

CouchDB runs as a separate database process alongside the peer, therefore there are additional considerations in terms of setup, management, and operations. You may consider starting with the default embedded LevelDB, and move to CouchDB if you require the additional complex rich queries. It is a good practice to model chaincode asset data as JSON, so that you have the option to perform complex rich queries if needed in the future.

To enable CouchDB as the state database, configure the /fabric/sampleconfig/core.yaml stateDatabase section.

13.

Erlang

14.

Make