| 澶辨晥閾炬帴澶勭悊 |
|
瓚呯駭璐︽湰Hyperledger鐧界毊涔?nbsp; PDF 涓嬭澆
鏈珯鏁寸悊涓嬭澆錛?/strong>
閾炬帴錛?a target="_blank">https://pan.baidu.com/s/1tfb7umwdoLznEN5ctHCJZw
鎻愬彇鐮侊細(xì)edkp
鐩稿叧鎴浘錛?/strong>
涓昏鍐呭錛?/strong>
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.
Consensus
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
transactions.
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:
https://www.hyperledger.org/wp-content/uploads/2017/08/Hyperledger_Arch_WG_
Paper_1_Consensus.pdf.
Commit
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
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.
Query
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.
7
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.
Reads
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.
Transaction
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.
|
| Java1234瀹樻柟緹?5錛?/td> | 
|
| Java1234瀹樻柟緹?5錛?/td> | 838462530 |
鑻忓叕緗戝畨澶?32061202001004鍙?/p>
