项目地址: https://github.com/hyperledger/fabric
区块链是一个新兴的技术模型，可以从根本上改善银行业，供应链，和其他交易网络，为创新和成长创造了新的机遇，同时降低了成本和相关经营活动的风险。hyperledger是一个还处在演变中的区块链架构，允许那些遵守规定，同时提出不同需求的相互矛盾的业务在同一个网络中一同工作。
商业合同可以通过编程的方式允许两个或两个以上当事人以一种可信的方式自动的履行合约。虽然在区块链上的信息本身是公开的，但企业之间的合同往往需要隐私控制来保证敏感的商业信息不被其他对账本有访问权限的人看到。
然而由于保密协议通常在商业合同中也是非常重要的一部分，因此在很多情况下，合同能够也必须能被所有的当事人很容易的在账本中找到，例如用来保存投标时的出价（询价）的账本。这类合同应该需要被标准化以便投标人很容易的找到。
像金融证券之类的资产必须能够被电子化的保存在区块链网络中，以便这些资产的利益相关者可以方便的访问，同时允许他们直接发起交易，并获得资产信息，而不必通过中介。交易应该能够接近实时的完成，所有的参与者也应该能够接近实时的访问这些资产。利益相关者应该能够为任何给定的资产类型添加业务规则，从而通过实施自动化逻辑进一步降低运维成本。资产的创建者必须能够使资产和任何与该资产相关的交易规则私有化和保密，或者经过授权的公开出来。
区块链架构必须提供一种手段，允许供应链上的每一个参与者能够输入和跟踪原材料，记录零部件的生产制造过程，跟踪商品的出处及运输，同时维护与该商品相关的所有不可更改的记录，记录包括：生产和储存的各个方面以及整个销售环节。并且能够同时利用到上面提到的商业合同和资产仓库。这个用例主要强调的是能够提供深度搜索和在多个交易中快速回溯的能力，这个需求的核心是要确定被制造的商品以及制造该商品的零部件的出处。 要想获得这些用例及需求的详细信息，并通过图示来进一步了解它们是如何应用到基于区块链的系统中去的，请点击 这里。
区块链交易者(Chain Transactor) 有权限创建交易和查询在网数据的单元。
区块链交易确认者(Chain Validator) 区块链网络中控制交易的单元，每个区块链交易确认者都有一票用于决定一个交易是否有效， 因此，区块链交易确认者能够审核发送到其所在的区块链网络。
区块链交易审核者(Chain Auditor) 有权限审核交易的单元。
最终用户(Solution User) "最终用户并不知祥链网络的细节，他们通常通过服务提供商 提供的应用发起一个在区块链网络上的交易。 角色: 无"
服务提供商(Solution Provider) "区块链上为最终用户提供移动应用和Web应用的服务提供商， 服务提供商也可以是整个区块链提供商。 角色: 区块链交易者、区块链交易确认者"
区块链网络经营者(Network Proprietor) "区块链网络经营者建立并定义区块链网络的用途。而且他们也是区块链网络的参与者。 角色: 区块链交易者"
区块链审核者(Network Auditors) "在区块链网络中具有审核交易权限的个人或机构。 角色: 区块链交易审核者"
行业区块链网络(Industry Network) 针对特定行业提供服务而构建的区块链网络。
局域区块链网络(Regional Industry Network) 针对特定行业和区域提供服务而构建的区块链网络。
单一服务区块链网络(Application Network) 针对单一方案提供服务的区块链网络。
主链(Main Chain) 一个商业区块链网络；每一个主链运营着由相同机构审核的一个或多个商业服务。
机密链(Confidential Chain) 运行机密商业逻辑的特殊用途区块链网络，并且只能由合约参与者访问。
部署类交易(Deployment Transaction) 用以部署一个新的chaincode的交易。
调用类交易(Invocation Transaction) 用以调用一个区块链节点功能的交易。
公共交易(Public transaction) 数据公开的交易。任何有权限访问区块链网络的用户都能够审核公开交易的细节。
机密交易(Confidential transaction) 数据加密的交易。如果这个机密交易是部署类型的交易， 那么所有后续调用该chaincode的交易也必须是机密交易。
区块链网络间交易(Inter-Network Transaction) 两个区块链网络间(主链)的交易。
区块链间交易(Inter-Chain Transaction) 机密链和主链间的交易。机密链中的chaincode可以触发一个或多个主链上的交易。
应用后端(Application Backend) 用途: 用以支持移动和Web应用的后端应用服务。关键作用:
- 使用会员服务(membership service)管理和注册最终用户
- 发起交易请求，并且发送这些请求到一个节点 归属于: 服务提供商(Solution Provider), 区块链网络经营者(Network Proprietor)
非交易确认节点(对等节点）(Non Validating Node (Peer)) 用途: 构建并转发交易到交易确认节点(validating nodes)。其对等节点会保留一个全部交易记录的副本供服务提供商(solution providers)从本地查询。(Dev Team name: NVP - Non Validating Peer) 关键作用:
- 管理和维护由会员服务(membership service)颁发的用户证书
- 构建并转发交易到交易确认节点(validating nodes)
- 维护一份总账的本地副本供服务提供商(solution providers)从本地查询 归属于: 服务提供商(Solution Provider), 区块链审核者(Network Auditor)
交易确认节点(对等节点）(Validating Node (Peer)) 用途: 创建和确认交易，并维护chaincodes的状态, 关键作用:
- 管理和维护由会员服务(membership service)颁发的用户证书
- 确立交易
- 合同在区块链网络中的其它交易确认节点一起执行和确认交易
- 维护一份总账的本地副本
- 参与承认和更新总账 归属于: Network Proprietor, Solution Provider (if they belong to the same entity)
会员服务(Membership Service) 用途: 颁发和管理最终用户和机构的标识.关键作用:
- 为每个最终用户和接个颁发登记证书
- 为每个最终用户和接个颁发交易相关证书
- 为OBC单元间的安全通讯颁发TLS证书
- 颁发区块链特有的密匙 归属于: 第三方服务提供商
注册管理机构(Registration Authority) 为区块链网络参与者发放注册用户名密码对，这个密码对将被用来从ECA获取登记证书。
登记证书管理机构(Enrollment Certificate Authority (ECA)) 为已经在会员服务(membership service)中注册的区块链网络参与者颁发登记证书(ECert)。 登记证书是一种用于识别参与一个或多个区块链网络独立单元的长期证书。
交易证书管理机构(Transaction Certificate Authority (TCA)) 为登记证书的所有者颁发交易证书。源自每个登记证书的交易证书是不限数据的。 区块链网络参与者使用交易证书来发送交易。根据安全级别的要求，区块链网络 参与者可能会选择为每一个交易使用新的证书。
TLS 证书管理机构(TLS-Certificate Authority (TLS-CA)) 颁发TLS证书给需要在区块链网络中传送消息的系统。TLS证书是用于保护系统间通讯通道的安全。
公开的Chaincode(Public Chaincode) 由公开交易部署的Chaincodes，这些chaincodes能被区块链网络中的任何会员调用。
机密的Chaincode(Confidential Chaincode) 由机密交易部署的Chaincodes，这些chaincodes只能被区块链网络中的验证 的会员(Chain validators)调用。
有访问控制的Chaincode(Access Controlled Chaincode) 由机密交易部署并且内嵌获准调用者令牌的Chaincodes。尽管这个调用者不是 区块链交易确认者，依然可以调用机密chaincodes。
Chaincode状态(Chaincode-State) OBC 提供状态服务；Chaincodes通过状态API访问内部状态存储。交易根据状态 存取逻辑调用chaincode功能来创建、更新状态。
交易列表(Transaction List) 所有处理过的交易都会以其原始形式保存到总账中(机密交易的数据会被加密)， 区块链网络参与者可以审核以前有权限访问的交易。
总账哈希(Ledger Hash) 用于捕捉总账当前快照的哈希。它是从交易0开始的所有在区块链网络中发生的交易的产出。
DevOps服务(DevOps Service) 节点上的前部模块，提供为客户提供与节点和区块链网络交互的APIs。这个模块也负责构造交易， 与会员服务组建协同工作来接受并保存所有类型的证书和密钥到自己的存储中。
节点服务(Node Service) 一个节点的主模块，其功能包括：处理交易、部署执行chaincodes、维护总账数据和触发共识处理。
共识算法(Consensus) 缺省的OBC的共识算法叫Sieve，是一个新的算法，它允许交易确认节点全力识别非确定的交易， 这是对拜占庭将军问题算法的增强。
（暂时没有提供可参考的生产环境下的体系结构及部署方案）
- Git client
- 安装 docker
- 安装 golang1.6以上版本
- 安装 RocksDB 4.1
apt-get install -y libsnappy-dev zlib1g-dev libbz2-dev
cd /tmp
git clone https://github.com/facebook/rocksdb.git
cd rocksdb
git checkout v4.1
PORTABLE=1 make shared_lib
INSTALL_PATH=/usr/local make install-shared构建fabric :
cd $GOPATH/src/github.com/hyperledger/fabric
go build -o peer
运行:
./peer
Usage:
peer [command]
输出：
Available Commands:
peer Runs the peer.
status Returns status of the peer.
stop Stops the running peer.
login Logs in a user on CLI.
network Lists all network peers.
chaincode chaincode specific commands.
help Help about any command
Flags:
-h, --help[=false]: help for peer
--logging-level="": Default logging level and overrides, see core.yaml for full syntax
Use "peer [command] --help" for more information about a command.
构建obcca
cd $GOPATH/src/github.com/hyperledger/fabric
go build -o obcca membersrvc/server.go
chaincode 使用了 gRPC 协议，可以针对业务修改.proto文件,实现自定义的数据结构，然后执行脚本更新_pb.go文件，重新编译成新的core程序。
应用层的chaincode需要自行实现github.com/hyperledger/fabric/core/chaincode/shim.Chaincode接口:
// Chaincode is the standard chaincode callback interface that the chaincode developer needs to implement.
type Chaincode interface {
// Init method will be called during deployment
Init(stub *ChaincodeStub, function string, args []string) ([]byte, error)
// Invoke will be called for every transaction
Invoke(stub *ChaincodeStub, function string, args []string) ([]byte, error)
// Query is to be used for read-only access to chaincode state
Query(stub *ChaincodeStub, function string, args []string) ([]byte, error)
}例如：examples/chaincode/go/asset_management/asset_management.go
然后可以通过core提供的API或CLI进行调试。
# CA server parameters
#
server:
# current version of the CA
version: "0.1"
# limits the number of operating system threads used by the CA
# set to negative to use the system default setting
gomaxprocs: -1
# path to the OBC state directory and CA state subdirectory
rootpath: "/var/hyperledger/production"
cadir: ".membersrvc"
# port the CA services are listening on
port: ":50051"
# TLS certificate and key file paths
tls:
# certfile: "/var/hyperledger/production/.membersrvc/tlsca.cert"
# keyfile: "/var/hyperledger/production/.membersrvc/tlsca.priv"
security:
# Can be 256 or 384
# Must be the same as in core.yaml
level: 256
# Can be SHA2 or SHA3
# Must be the sam as in core.yaml
hashAlgorithm: SHA3
# Enabling/disabling different logging levels of the CA.
#
logging:
trace: 0
info: 1
warning: 1
error: 1
panic: 1
# Default users to be registered with the CA on first launch. The role is a binary OR
# of the different roles a user can have:
#
# - simple client such as a wallet: CLIENT
# - non-validating peer: PEER
# - validating client: VALIDATOR
# - auditing client: AUDITOR
#
eca:
affiliation_groups:
banks_and_institutions:
banks:
bank_a:
bank_b:
bank_c:
institutions:
institution_a:
users:
# <EnrollmentID>: <system_role (1:client, 2: peer, 4: validator, 8: auditor)> <EnrollmentPWD> <Affiliation> <Affiliation_Role>
lukas: 1 NPKYL39uKbkj bank_a 00001
system_chaincode_invoker: 1 DRJ20pEql15a institution_a 00002
diego: 1 DRJ23pEQl16a institution_a 00003
jim: 1 6avZQLwcUe9b bank_a 00004
binhn: 1 7avZQLwcUe9q institution_a 00005
vp: 4 f3489fy98ghf
test_vp0: 4 MwYpmSRjupbT
test_vp1: 4 5wgHK9qqYaPy
test_vp2: 4 vQelbRvja7cJ
test_vp3: 4 9LKqKH5peurL
test_vp4: 4 Pqh90CEW5juZ
test_vp5: 4 FfdvDkAdY81P
test_vp6: 4 QiXJgHyV4t7A
test_vp7: 4 twoKZouEyLyB
test_vp8: 4 BxP7QNh778gI
test_vp9: 4 wu3F1EwJWHvQ
test_user0: 1 MS9qrN8hFjlE bank_a 00006
test_user1: 1 jGlNl6ImkuDo institution_a 00007
test_user2: 1 zMflqOKezFiA bank_c 00008
test_user3: 1 vWdLCE00vJy0 bank_a 00009
test_user4: 1 4nXSrfoYGFCP institution_a 00010
test_user5: 1 yg5DVhm0er1z bank_b 00011
test_user6: 1 b7pmSxzKNFiw bank_a 00012
test_user7: 1 YsWZD4qQmYxo institution_a 00013
test_user8: 1 W8G0usrU7jRk bank_a 00014
test_user9: 1 H80SiB5ODKKQ institution_a 00015
test_nvp0: 2 iywrPBDEPl0K bank_a 00006
test_nvp1: 2 DcYXuRSocuqd institution_a 00007
test_nvp2: 2 flpChShlY7xt bank_c 00008
test_nvp3: 2 jeruawMomclo bank_a 00009
test_nvp4: 2 RMYVxSZCk370 institution_a 00010
test_nvp5: 2 XHYVCIJGZGK7 bank_b 00011
test_nvp6: 2 4cIn63j8ahYp bank_a 00012
test_nvp7: 2 E7FAJUtWVn2h institution_a 00013
test_nvp8: 2 LJu8DkUilBEH bank_a 00014
test_nvp9: 2 VlEsBsiyXSjw institution_a 00015
tca:
attribute-encryption:
enabled: false
pki:
validity-period:
# Setting the update property will prevent the invocation of the update_validity_period system chaincode to update the validity period.
update: false
chaincodeHash: 6091c3abd07c18edd6ef48ae24cfe409522f7defb51e4103dfa61ca3012386380c1b179f904375e253f20f4b2c5c848299988e65d8b80cb3f6b3d848b6fb2230
# TLS Settings for communications to update the validity period
tls:
enabled: false
cert:
file: testdata/server1.pem
key:
file: testdata/server1.key
# The server name use to verify the hostname returned by TLS handshake
serverhostoverride:
devops-address: 0.0.0.0:30303进入该配置文件所在目录，执行 obcca 启动ca服务
cd $GOPATH/src/github.com/hyperledger/fabric/membersrvc
./obc-ca2. peer主要通过core.yaml文件来配置，当然也可以使用环境变量指定，配置参数较多，不一一列举，主要包括 REST 服务相关，日志级别，peer自身相关部分，vm及chaincode.安全相关等的配置。示例配置文件如下：
###############################################################################
#
# CLI section
#
###############################################################################
cli:
# The address that the cli process will use for callbacks from chaincodes
address: 0.0.0.0:30304
###############################################################################
#
# REST section
#
###############################################################################
rest:
# Enable/disable setting for the REST service. It is recommended to disable
# REST service on validators in production deployment and use non-validating
# nodes to host REST service
enabled: true
# The address that the REST service will listen on for incoming requests.
address: 0.0.0.0:5000
###############################################################################
#
# LOGGING section
#
###############################################################################
logging:
# Valid logging levels are case-insensitive strings chosen from
# CRITICAL | ERROR | WARNING | NOTICE | INFO | DEBUG
# Logging 'module' names are also strings, however valid module names are
# defined at runtime and are not checked for validity during option
# processing.
# Default logging levels are specified here for each of the obc-peer
# commands. For commands that have subcommands, the defaults also apply to
# all subcommands of the command. These logging levels can be overridden
# on the command line using the --logging-level command-line option, or by
# setting the CORE_LOGGING_LEVEL environment variable.
# The logging level specification is of the form
# [<module>[,<module>...]=]<level>[:[<module>[,<module>...]=]<level>...]
# A logging level by itself is taken as the overall default. Otherwise,
# overrides for individual or groups of modules can be specified using the
# <module>[,<module>...]=<level> syntax.
# Examples:
# info - Set default to INFO
# warning:main,db=debug:chaincode=info - Override default WARNING in main,db,chaincode
# chaincode=info:main=debug:db=debug:warning - Same as above
peer: debug
crypto: info
status: warning
stop: warning
login: warning
vm: warning
chaincode: warning
###############################################################################
#
# Peer section
#
###############################################################################
peer:
# Peer Version following version semantics as described here http://semver.org/
# The Peer supplies this version in communications with other Peers
version: 0.1.0
# The Peer id is used for identifying this Peer instance.
id: ckeyer
# The privateKey to be used by this peer
# privateKey: 794ef087680e2494fa4918fd8fb80fb284b50b57d321a31423fe42b9ccf6216047cea0b66fe8365a8e3f2a8140c6866cc45852e63124668bee1daa9c97da0c2a
# The networkId allows for logical seperation of networks
# networkId: dev
# networkId: test
networkId: dev
Dockerfile: |
from openblockchain/baseimage:latest
# Copy GOPATH src and install Peer
COPY src $GOPATH/src
RUN mkdir -p /var/hyperledger/db
WORKDIR $GOPATH/src/github.com/hyperledger/fabric/
RUN CGO_CFLAGS=" " CGO_LDFLAGS="-lrocksdb -lstdc++ -lm -lz -lbz2 -lsnappy" go install && cp $GOPATH/src/github.com/hyperledger/fabric/core.yaml $GOPATH/bin
# The Address this Peer will listen on
listenAddress: 0.0.0.0:30303
# The Address this Peer will bind to for providing services
address: 0.0.0.0:30303
# Whether the Peer should programmatically determine the address to bind to.
# This case is useful for docker containers.
addressAutoDetect: false
# Peer port to accept connections on
port: 30303
# Setting for runtime.GOMAXPROCS(n). If n < 1, it does not change the current setting
gomaxprocs: -1
workers: 2
# Sync related configuration
sync:
blocks:
# Channel size for readonly SyncBlocks messages channel for receiving
# blocks from oppositie Peer Endpoints.
# NOTE: currently messages are not stored and forwarded, but rather
# lost if the channel write blocks.
channelSize: 10
state:
snapshot:
# Channel size for readonly syncStateSnapshot messages channel
# for receiving state deltas for snapshot from oppositie Peer Endpoints.
# NOTE: currently messages are not stored and forwarded, but
# rather lost if the channel write blocks.
channelSize: 50
deltas:
# Channel size for readonly syncStateDeltas messages channel for
# receiving state deltas for a syncBlockRange from oppositie
# Peer Endpoints.
# NOTE: currently messages are not stored and forwarded,
# but rather lost if the channel write blocks.
channelSize: 20
# Validator defines whether this peer is a validating peer or not, and if
# it is enabled, what consensus plugin to load
validator:
enabled: true
# Consensus plugin to use. The value is the name of the plugin, e.g. pbft, noops ( this value is case-insensitive)
# if the given value is not recognized, we will default to noops
consensus: noops
events:
# The address that the Event service will be enabled on the validator
address: 0.0.0.0:31315
# total number of events that could be buffered without blocking the
# validator sends
buffersize: 100
# milliseconds timeout for producer to send an event.
# if < 0, if buffer full, unblocks immediately and not send
# if 0, if buffer full, will block and guarantee the event will be sent out
# if > 0, if buffer full, blocks till timeout
timeout: 10
# Setting the validity-period.verification to false will disable the verification
# of the validity period in the validator
validity-period:
verification: true
# TLS Settings for p2p communications
tls:
enabled: true
cert:
file: testdata/server1.pem
key:
file: testdata/server1.key
# The server name use to verify the hostname returned by TLS handshake
serverhostoverride:
# PKI member services properties
pki:
eca:
paddr: luv.gift:50051
tca:
paddr: luv.gift:50051
tlsca:
paddr: luv.gift:50051
tls:
enabled: true
rootcert:
file: tlsca.cert
# The server name use to verify the hostname returned by TLS handshake
serverhostoverride:
# Peer discovery settings. Controls how this peer discovers other peers
discovery:
# The root nodes are used for bootstrapping purposes, and generally
# supplied through ENV variables
rootnode: luv.gift
# The duration of time between attempts to asks peers for their connected peers
period: 5s
## leaving this in for example of sub map entry
# testNodes:
# - node : 1
# ip : 127.0.0.1
# port : 30303
# - node : 2
# ip : 127.0.0.1
# port : 30303
# Should the discovered nodes and their reputations
# be stored in DB and persisted between restarts
persist: true
# if peer discovery is off
# the peer window will show
# only what retrieved by active
# peer [true/false]
enabled: true
# number of workers that
# tastes the peers for being
# online [1..10]
workers: 8
# the period in seconds with which the discovery
# tries to reconnect to successful nodes
# 0 means the nodes are not reconnected
touchPeriod: 600
# the maximum nuber of nodes to reconnect to
# -1 for unlimited
touchMaxNodes: 100
# Path on the file system where peer will store data
fileSystemPath: /var/hyperledger/production
###############################################################################
#
# VM section
#
###############################################################################
vm:
# Endpoint of the vm management system. For docker can be one of the following in general
# unix:///var/run/docker.sock
# http://localhost:4243
# tcp://localhost:2376
endpoint: unix:///var/run/docker.sock
# settings for docker vms
docker:
tls:
enabled: true
cert:
file: /path/to/server.pem
ca:
file: /path/to/ca.pem
key:
file: /path/to/server-key.pem
###############################################################################
#
# Chaincode section
#
###############################################################################
chaincode:
# The id is used by the Chaincode stub to register the executing Chaincode
# ID with the Peerand is generally supplied through ENV variables
# the Path form of ID is provided when deploying the chaincode. The name is
# used for all other requests. The name is really a hashcode
# returned by the system in response to the deploy transaction. In
# development mode where user runs the chaincode, the name can be any string
id:
path:
name:
golang:
# This is the basis for the Golang Dockerfile. Additional commands will
# be appended depedendent upon the chaincode specification.
Dockerfile: |
from openblockchain/baseimage
#from utxo:0.1.0
COPY src $GOPATH/src
WORKDIR $GOPATH
# timeout in millisecs for starting up a container and waiting for Register
# to come through. 1sec should be plenty for chaincode unit tests
startuptimeout: 1000
#timeout in millisecs for deploying chaincode from a remote repository.
deploytimeout: 30000
#mode - options are "dev", "net"
#dev - in dev mode, user runs the chaincode after starting validator from
# command line on local machine
#net - in net mode validator will run chaincode in a docker container
mode: net
installpath: /opt/gopath/bin/
###############################################################################
#
# Ledger section - ledger configuration encompases both the blockchain
# and the state
#
###############################################################################
ledger:
blockchain:
# Define the genesis block
genesisBlock:
# Deploy chaincodes into the genesis block
# chaincode:
# path: github.com/hyperledger/fabric/core/example/chaincode/chaincode_example01
# type: GOLANG
# constructor:
# func: init
# args:
# - alice
# - "4"
# - bob
# - "10"
# Setting the deploy-system-chaincode property to false will prevent the
# deploying of system chaincode at genesis time.
deploy-system-chaincode: false
state:
# Control the number state deltas that are maintained. This takes additional
# disk space, but allow the state to be rolled backwards and forwards
# without the need to replay transactions.
deltaHistorySize: 500
# The data structure in which the state will be stored. Different data
# structures may offer different performance characteristics. Options are
# 'buckettree' and 'trie'. If not set, the default data structure is the
# 'buckettree'. This CANNOT be changed after the DB has been created.
dataStructure:
# The name of the data structure is for storing the state
name: buckettree
# The data structure specific configurations
configs:
# configurations for 'bucketree'. These CANNOT be changed after the DB
# has been created. 'numBuckets' defines the number of bins that the
# state key-values are to be divided
numBuckets: 1000003
# 'maxGroupingAtEachLevel' defines the number of bins that are grouped
#together to construct next level of the merkle-tree (this is applied
# repeatedly for constructing the entire tree).
maxGroupingAtEachLevel: 5
# 'bucketCacheSize' defines the size (in MBs) of the cache that is used to keep
# the buckets (from root upto secondlast level) in memory. This cache helps
# in making state hash computation faster. A value less than or equals to zero
# leads to disabling this caching. This caching helps more if transactions
# perform significant writes.
bucketCacheSize: 100
# configurations for 'trie'
# 'tire' has no additional configurations exposed as yet
###############################################################################
#
# Security section - Applied to all entities (client, NVP, VP)
#
###############################################################################
security:
# Enable security will force every entity on the network to enroll with obc-ca
# and maintain a valid set of certificates in order to communicate with
# other peers
enabled: false
# To enroll NVP or VP with membersrvc. These parameters are for 1 time use.
# They will not be valid on subsequent times without un-enroll first.
# The values come from off-line registration with obc-ca. For testing, make
# sure the values are in membersrvc/membersrvc.yaml file eca.users
enrollID: vp
enrollSecret: f3489fy98ghf
# To enable privacy of transactions (requires security to be enabled). This
# encrypts the transaction content during transit and at rest. The state
# data is also encrypted
privacy: false
# Can be 256 or 384. If you change here, you have to change also
# the same property in membersrvc.yaml to the same value
level: 256
# TCerts related configuration
tcert:
batch:
# The size of the batch of TCerts
size: 200./bin/obcpeer peer
19:36:33.024 [crypto] main -> INFO 001 Log level recognized 'info', set to INFO
19:36:33.024 [logging] LoggingInit -> DEBU 002 Setting default logging level to DEBUG for command 'peer'
19:36:33.026 [eventhub_producer] AddEventType -> DEBU 003 registering block
19:36:33.026 [eventhub_producer] AddEventType -> DEBU 004 registering register
19:36:33.026 [main] serve -> INFO 005 Security enabled status: false
19:36:33.026 [main] serve -> INFO 006 Privacy enabled status: false
19:36:33.027 [main] serve -> DEBU 007 Running as validating peer - installing consensus noops
19:36:33.027 [db] createDBIfDBPathEmpty -> DEBU 008 Is db path [/var/hyperledger/production/db] empty [false]
19:36:33.030 [eventhub_producer] start -> INFO 009 event processor started
19:36:33.057 [state] NewState -> INFO 00a Initializing state implementation [buckettree]
19:36:33.057 [buckettree] initConfig -> INFO 00b configs passed during initialization = map[string]interface {}{"maxGroupingAtEachLevel":5, "bucketCacheSize":100, "numBuckets":1000003}
19:36:33.057 [buckettree] initConfig -> INFO 00c Initializing bucket tree state implemetation with configurations &{maxGroupingAtEachLevel:5 lowestLevel:9 levelToNumBucketsMap:map[0:1 9:1000003 5:1601 4:321 8:200001 7:40001 6:8001 2:13 3:65 1:3] hashFunc:0x4610e70}
19:36:33.057 [buckettree] newBucketCache -> INFO 00d Constructing bucket-cache with max bucket cache size = [100] MBs
19:36:33.057 [buckettree] loadAllBucketNodesFromDB -> INFO 00e Loaded buckets data in cache. Total buckets in DB = [0]. Total cache size:=0
19:36:33.059 [chaincode] NewChaincodeSupport -> INFO 00f Chaincode support using peerAddress: 0.0.0.0:30303
19:36:33.060 [main] serve -> INFO 010 Starting peer with id=name:"jdoe" , network id=dev, address=0.0.0.0:30303, discovery.rootnode=, validator=true
19:36:33.060 [peer] chatWithPeer -> DEBU 011 Starting up the first peer
需要更改配置文件中 peer.discovery.rootnode 为根节点的服务地址，
cli:
address: 0.0.0.0:30304
rest:
enabled: true
address: 0.0.0.0:5000
logging:
peer: debug
crypto: info
status: warning
stop: warning
login: warning
vm: warning
chaincode: warning
peer:
version: 0.1.0
id: ckeyer
networkId: dev
Dockerfile: |
from openblockchain/baseimage:latest
COPY src $GOPATH/src
RUN mkdir -p /var/hyperledger/db
WORKDIR $GOPATH/src/github.com/hyperledger/fabric/
RUN CGO_CFLAGS=" " CGO_LDFLAGS="-lrocksdb -lstdc++ -lm -lz -lbz2 -lsnappy" go install && cp $GOPATH/src/github.com/hyperledger/fabric/core.yaml $GOPATH/bin
listenAddress: 0.0.0.0:30303
address: 0.0.0.0:30303
addressAutoDetect: false
port: 30303
gomaxprocs: -1
workers: 2
sync:
blocks:
channelSize: 10
state:
snapshot:
channelSize: 50
deltas:
channelSize: 20
validator:
enabled: true
consensus: noops
events:
address: 0.0.0.0:31315
buffersize: 100
timeout: 10
validity-period:
verification: false
tls:
enabled: false
cert:
file: testdata/server1.pem
key:
file: testdata/server1.key
serverhostoverride:
pki:
eca:
paddr: luv.gift:50051
tca:
paddr: luv.gift:50051
tlsca:
paddr: luv.gift:50051
tls:
enabled: false
rootcert:
file: tlsca.cert
serverhostoverride:
discovery:
rootnode: luv.gift:30303
period: 5s
persist: true
enabled: true
workers: 8
touchPeriod: 600
touchMaxNodes: 100
fileSystemPath: /var/hyperledger/production
vm:
endpoint: unix:///var/run/docker.sock
docker:
tls:
enabled: false
cert:
file: /path/to/server.pem
ca:
file: /path/to/ca.pem
key:
file: /path/to/server-key.pem
chaincode:
id:
path:
name:
golang:
Dockerfile: |
from openblockchain/baseimage
COPY src $GOPATH/src
WORKDIR $GOPATH
startuptimeout: 1000
deploytimeout: 30000
mode: net
installpath: /opt/gopath/bin/
ledger:
blockchain:
genesisBlock:
deploy-system-chaincode: false
state:
deltaHistorySize: 500
dataStructure:
name: buckettree
configs:
numBuckets: 1000003
maxGroupingAtEachLevel: 5
bucketCacheSize: 100
security:
enabled: false
enrollID: vp
enrollSecret: f3489fy98ghf
privacy: false
level: 256
tcert:
batch:
size: 200用户验证：
./bin/obcpeer login test_user2
19:35:54.641 [crypto] main -> INFO 001 Log level recognized 'info', set to INFO
Enter password for user 'test_user2': ************部署chaincode：
$ ./peer chaincode deploy -u test_user2 -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Function":"init", "Args": ["a","100", "b", "200"]}'
05:20:24.581 [crypto] main -> INFO 001 Log level recognized 'info', set to INFO
5844bc142dcc9e788785e026e22c855957b2c754c912702c58d997dedbc9a042f05d152f6db0fbd7810d95c1b880c210566c9de3093aae0ab76ad2d90e9cfaa5通过chaincode执行交易
$ ./peer chaincode invoke -u test_user2 -l golang -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Function": "invoke", "Args": ["a", "b", "10"]}'
05:23:03.593 [crypto] main -> INFO 001 Log level recognized 'info', set to INFO
1d5ea5c2-72b9-4669-934e-827b390d94a2
$ ./peer chaincode invoke -u test_user2 -l golang -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Function": "invoke", "Args": ["a", "b", "20"]}'
05:23:56.449 [crypto] main -> INFO 001 Log level recognized 'info', set to INFO
4d0db78c-3e8b-4713-8b03-4ce7b40c33f2
$ curl luv.gift:25000/chain
{
"height":5,
"currentBlockHash":"33bt/jkTLc18W5LALe+toDgFs+ietwrnqah3KnzyOXQl7aNadDTqEFqRubcVzEwYd/4q7tqfqnEA6kxoxSRQag==",
"previousBlockHash":"PwsWr0Kl/hRU/iJrTmtpkKvSlcMW1sHERrMhpJ+jDmSEtepjTClPPva3fT6L2zYBAahdlz+scOiev168qHichA=="
}
$ ./peer chaincode invoke -u test_user2 -l golang -n mycc -p github.com/hyperledger/fabric/examples/chaincode/go/chaincode_example02 -c '{"Function": "invoke", "Args": ["a", "b", "30"]}'
05:28:24.811 [crypto] main -> INFO 001 Log level recognized 'info', set to INFO
28d8770f-7662-4208-a4ca-91471934ab6a
$ curl luv.gift:25000/chain
{
"height":5,
"currentBlockHash":"33bt/jkTLc18W5LALe+toDgFs+ietwrnqah3KnzyOXQl7aNadDTqEFqRubcVzEwYd/4q7tqfqnEA6kxoxSRQag==",
"previousBlockHash":"PwsWr0Kl/hRU/iJrTmtpkKvSlcMW1sHERrMhpJ+jDmSEtepjTClPPva3fT6L2zYBAahdlz+scOiev168qHichA=="
}
通过chaincode查询
# curl luv.gift:25000/chain/blocks/4
{
"transactions":
[
{
"type":2,
"chaincodeID":"EgRteWNj",
"payload":"Ch4IARIGEgRteWNjGhIKBmludm9rZRIBYRIBYhICMzA=",
"uuid":"28d8770f-7662-4208-a4ca-91471934ab6a",
"timestamp":
{
"seconds":1461043704,
"nanos":828941078
}
}
],
"previousBlockHash":"PwsWr0Kl/hRU/iJrTmtpkKvSlcMW1sHERrMhpJ+jDmSEtepjTClPPva3fT6L2zYBAahdlz+scOiev168qHichA==",
"nonHashData":
{
"localLedgerCommitTimestamp":
{
"seconds":1461043705,
"nanos":942314987
}
}
}./peer chaincode query -u test_user2 -l golang -n mycc -c '{"Function": "query", "Args": ["b"]}'该项目优势在于其通用性较强，与其他区块链的实现相比，具有更加灵活体系结构，而且被诸大公司及社区所重视，但是目前项目依旧处于测试开发阶段，项目本身和文档都还不是很完善。
-
目前还没有较好的实际生产环境实践
-
区块链本身的问题
- 技术上的挑战 - 延时时间 - 吞吐量 - 容量和带宽 - 潜在的安全问题`
2015/9/23 第一个commit
2016/2/16 发布 v0.1.0 版本
2016/4/4 "项目结构较大调整， /obc-ca/ 移动到 /membersrvc/ /core/consensus移动到/consensus main.go和core.yaml移到到/peer/ 移动项目本地目录"
2016/4/12 "修改chaincode interface 移除 Run(stub *ChaincodeStub, function string, args []string) ([]byte, error) 增加 Invoke(….), Query(…)"
2016/4/13 增加了nodejs的sdk
2016/4/21 整合EnrollmentID到TCerts #1130