没有合适的资源?快使用搜索试试~ 我知道了~
首页Tendermint共识算法(一种改进的PBFT算法).pdf
资源详情
资源评论
资源推荐

Tendermint: Consensus without Mining
Jae Kwon
yk239@cornell.edu
Draft v.0.6 (outdated)
This is from 2014.
The current spec is on github.com/tendermint/tendermint/wiki
Abstract. Cryptocurrencies such as Bitcoin enable users to submit
payment transactions without going through a centralized trusted or-
ganization. Bitcoin relies on proof-of-work mining to secure consensus
which is problematic; mining requires a massive expenditure of energy,
confirmation of transactions is slow, and security is difficult to quantify.
We propose a solution to the blockchain consensus problem that does
not require mining by adapting an existing solution to the Byzantine
Generals Problem.
1. Introduction
Cryptocurrencies have come into the spotlight since the introduction of Bit-
coin [1]. The objective of cryptocurrency protocols such as Bitcoin is to maintain a
live decentralized transaction ledger while defending against double-spend attacks
from malicious Byzantine actors that deviate from the protocol. Consensus of the
Bitcoin transaction ledger is secured by a network of miners who compete for re-
wards in the blockchain. This mining, or proof-of-work, comes with a hefty cost.
At today’s Bitcoin prices and reward schedule, miners are rewarded on the order of
$1,500,000 a day to secure the blockchain – and a significant portion of that money
is spent on electricity. Proof-of-work based consensus protocols are also slow, re-
quiring up to an hour to reasonably confirm a payment to prevent double-spending.
Alternative protocols have been proposed by the cryptocurrency commu-
nity to replace proof-of-work mining [2, 3]. Some of these protocols suffer from the
nothing at stake problem; participants have nothing to lose by contributing to mul-
tiple blockchain forks, so consensus on a single blockchain is not guaranteed. Other
protocols require participant to accurately gauge the trustworthiness of other key
participants, which makes analysis of security difficult to quantify.
Our contribution is a novel consensus protocol that requires no proof-of-work
mining and has a high level of protection against double-spend attacks. We make
a weak assumption about the participant’s abilities to keep time, and we assume
partial synchrony of the network. Our algorithm is based on a modified version of
the DLS protocol [4], and is resilient up to
1
/3 of Byzantine participants.
1

2. The Difficulty of Quantifying Security
Security analysis of cryptocurrency protocols is complicated by many factors.
One such complicating factor is the rational self-interested nature of participants.
The ideal protocol is an incentive compatible Nash equilibrium such that deviating
from the protocol does not result in a net gain [5]. Recent work by Eyal and Sirer
[6] showed that the Bitcoin protocol is susceptible to a minority collusion group
that can grow to become a centralized majority. They propose a modification to
the Bitcoin protocol such that it can tolerate colluding groups that control up to
1
/4
of the mining power – less than the previously assumed bound of
1
/2 of Byzantine
mining power which requires an honest mining majority that follows the prescribed
protocol.
Another complicating factor is whether the power to achieve or disrupt con-
sensus is extrinsic in origin (e.g. access to the production of mining equipment or
access to cheap electricity) or intrinsic in origin (e.g. the “stake” of validators in
proof-of-stake protocols) and whether the disruption of consensus – especially via a
successful double-spend attack – is associated with a commensurate penalty. The
problem with extrinsic factors of security is that they are not easily quantifiable
for analysis. For example, the depreciation costs of Bitcoin mining hardware in the
event of a successful double-spend attack may not be significant compared to the
running costs of electricity. On the other hand existing proof-of-stake protocols do
not have a well defined intrinsic penalty for instigators of a double-spend attack.
This is commonly called, ironically, the “nothing at stake” problem. Newer protocols
like the BitShares delegated-proof-of-stake protocol attempt to address this prob-
lem by placing the role of ranked-delegate at stake [3], but security is dependant on
the extrinsic ability of stakeholders to accurately predict the future performance of
delegates.
Security analysis is much simpler for an intrinsically secure cryptocurrency
protocol when it can be proved that launching a double-spend attack necessarily
results in a very high intrinsic penalty compared to the possible intrinsic gains.
Then, the protocol may be considered resistant to double-spent attacks assuming
no further extrinsic complications.
3. Terms
Nodes are connected to each other in a peer-to-peer network and relay new
information by gossip. Each node keeps a complete copy of a totally ordered se-
quence of events in the form of a blockchain as in Bitcoin. Users keep an account
in the system, where the user’s account is identified by the user’s public key or
address. Each account can hold a sum of coins that can change with new transac-
tions. Nodes relay new transactions as they are signed and submitted by users to
2

a node of the network. A transaction is valid if it follows the rules of our protocol
(e.g. sufficient funds to send, etc).
4. Block Structure
Valid transactions are grouped into blocks with a structure shown in figure 1.
The validation and transactions hashes are merkle tree root hashes of the signatures
and transaction data included in the block [7]. The state hash, included in the
header, is likewise the merkle root hash of the persistent account state (external to
the blockchain) after applying the transactions of the block. Finally the block hash
is computed by hashing the header, validation, and transactions hashes. This way,
the block hash itself is a merkle root hash such that any component of the block
and account state can be verified with a merkle hash trail that leads to the block
hash. A block is said to be valid if all the transactions in the block are valid and
sufficient signatures are included in the validation.
Figure 1: Block structure
5. Validators
Validators are users with accounts that have coins locked in a bond deposit
by posting a bond transaction. These validators participate in the consensus pro-
tocol by broadcasting cryptographic signatures, or votes, to agree upon the next
block. We say that a validator has voting power equal to the amount of the bonded
coins. The validator can later unlock its coins by posting an unbonding transaction.
Afterwards the coins remain locked for a predetermined period of time called the
unbonding period, after which the validator is free to transfer or spend those coins
3
剩余10页未读,继续阅读











安全验证
文档复制为VIP权益,开通VIP直接复制

评论0