Java知识分享网 - 轻松学习从此开始!    





毕设代做论文包查重联系人QQ:1982956321毕设大神 毕设代做论文包查重


Java1234 VIP课程


当前位置: 主页 > Java文档 > 区块链 >

超级账本Hyperledger白皮书 PDF 下载

时间:2020-11-21 13:24来源: 作者:转载  侵权举报
超级账本Hyperledger白皮书 PDF 下载
超级账本Hyperledger白皮书  PDF 下载


2. Blockchain Terms
Blockchain is a new technology, with nomenclature still taking shape and evolving every day. 
Although blockchains are a new form of distributed database, some database terms have 
slightly different meanings when used in a blockchain context. And many common software 
terms have new nuances when used to describe a blockchain. This section describes some 
of the most common terms used to discuss blockchain technology.
In the context of blockchain, consensus is the distributed process by which a network 
of nodes provide a guaranteed unique order of transactions and validates the block of 
For more details in the context of Hyperledger, please refer to the white paper on consensus, 
Volume I from the Hyperledger Architecture Working Group, available here:
In a traditional database, a commit refers to the point when a transaction is written to the 
database. A blockchain has the additional complication of defining when this happens 
across multiple nodes. Typically a block is considered the record of committed transactions, 
and those transactions are committed when the block has been circulated through the 
network and applied by all nodes. The rules for the agreement on that block are dictated by 
consensus, which may have unique rules for finality.
Finality means that once a transaction is committed, it cannot be reversed, i.e. the data 
cannot be rolled back to the previous state. Different blockchain systems may provide 
different types of finality. Typically, this is defined in the consensus protocol. Different types of 
consensus exist, such as voting-based consensus with immediate finality and lottery-based 
consensus with probabilistic finality.
For testing purposes, formal thresholds of finality probability should be set. See Appendix A 
for further specifics.
Network Size
Network size is the number of validating nodes participating in consensus in the SUT. 
Network size is meant to express the total number of nodes actively participating in the 
blockchain network that support the unique features of a blockchain.
This count should not include observer nodes, or other nodes not actively participating in 
both consensus and the validation of transactions.
In systems that separate consensus and validation logic into different nodes, the network size 
should be expressed as the smaller node count of the two. This is because the resilience of 
the system (the key aspect of blockchains) is limited by the lesser number.
For example, a system deployed with a single consensus node but many other types of 
nodes has a single point of failure. By our definition, such a network has a size of one.
Querying is the ability to run ad-hoc operations or searches against the dataset contained 
within the blockchain. The SUT may not be built to execute these queries in a performant way.
Any off-chain databases, or caches that support efficient querying, can still be measured. 
But we assume that those are not standard parts of the blockchain. Therefore, query 
performance is beyond the scope of this version of this document.
Read operations differ from transactions in that there is no change to state. Reads can 
be an internal mechanism of a blockchain node, such as fetching data in the process of 
validating transactions. For the purposes of this document, we are only interested in defining 
measurements for external reads on the system, such as retrieving a transaction or querying 
a balance. Any internal reads will be an implicit part of the transactional measurements in any 
particular workload.
Many deployments use a system or tier beside a blockchain node to support more complex 
queries or to provide caching that improves read throughput. For the purposes of this document, 
we are only interested in the primitive fetching provided by the blockchain node itself.
Definitions of workloads should consider whether and to what degree “pure” read operations 
are intermingled with transactions. And all performance evaluation reports should disclose 
any external databases and how these are configured.
State and Global State
You can think of most blockchain systems as state machines, where each transaction or 
block of transactions is a state transition. The state itself is the contents of the database 
at a point in time. The log of transactions (the blockchain data structure) is not generally 
considered part of state, but simply the definitions of the transitions between states.
Global state is a state that is shared across all nodes. Note that not all blockchain systems 
implement global state. Some systems restrict information agreement for privacy or other reasons.
A transaction is a state transition that changes data in the blockchain from one value to 
another. That data could represent an asset amount, several IoT sensor readings, or any other 
type of data tracked using a blockchain.
Transactions are typically proposed by clients and then evaluated by the blockchain system 
against a list of rules, sometimes called a smart contract. If valid, the system will commit the 
transaction, which makes the state change.
A transaction may fail the verification for one of the reasons listed in Appendix B. Some 
blockchain systems also record those invalid transactions in blocks, but most do not. When 
evaluating the performance of a blockchain, the measure of valid transactions is more 
meaningful. For this reason, the total number of invalid transactions should be subtracted 
when calculating throughput.


回复 666