mirror of https://github.com/zcash/zips.git
Move Security and Privacy Considerations to below Rationale
This commit is contained in:
parent
b5b545f088
commit
893d06ab9b
73
zip-0221.rst
73
zip-0221.rst
|
@ -166,43 +166,6 @@ bandwidth and storage requirements for resource-limited clients like mobile or I
|
|||
devices.
|
||||
|
||||
|
||||
Security and Privacy Considerations
|
||||
===================================
|
||||
|
||||
This ZIP imposes an additional validation cost on new blocks. While this validation cost
|
||||
is small, it may exacerbate any existing DoS opportunities, particularly during abnormal
|
||||
events like long reorgs. Fortunately, these costs are logarithmic in the number of delete
|
||||
and append operations. In the worst case scenario, a well-resourced attacker could
|
||||
maintain 2 chains of approximately equal length, and alternate which chain they extend.
|
||||
This would result in repeated reorgs of increasing length.
|
||||
|
||||
Given the performance of Blake2b, we expect this validation cost to be negligible.
|
||||
However, it seems prudent to benchmark potential MMR implementations during the
|
||||
implementation process. Should the validation cost be higher than expected, there are
|
||||
several potential mitigations, e.g. holding recently seen nodes in memory after a reorg.
|
||||
|
||||
Generally, header commitments have no impact on privacy. However, FlyClient has additional
|
||||
security and privacy implications. Because FlyClient is a motivating factor for this ZIP,
|
||||
it seems prudent to include a brief overview. A more in-depth security analysis of
|
||||
FlyClient should be performed before designing a FlyClient-based light client ecosystem
|
||||
for Zcash.
|
||||
|
||||
FlyClient, like all light clients, requires a connection to a light client server. That
|
||||
server may collect information about client requests, and may use that information to
|
||||
attempt to deanonymize clients. However, because FlyClient proofs are non-interactive and
|
||||
publicly verifiable, they could be shared among many light clients after the initial
|
||||
server interaction.
|
||||
|
||||
FlyClient proofs are probabilistic. When properly constructed, there is negligible
|
||||
probability that a dishonest chain commitment will be accepted by the verifier. The
|
||||
security analysis assumes adversary mining power is bounded by a known fraction of
|
||||
combined mining power of honest nodes, and cannot drop or tamper with messages between
|
||||
client and full nodes. It also assumes the client is connected to at least one full node
|
||||
and knows the genesis block. However, these security properties have not been examined
|
||||
closely in chain models with rapidly-adjusting difficulty.
|
||||
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
|
@ -711,6 +674,42 @@ implementation that would join these commitments, but it is clearly not appropri
|
|||
Zcash as it exists.
|
||||
|
||||
|
||||
Security and Privacy Considerations
|
||||
===================================
|
||||
|
||||
This ZIP imposes an additional validation cost on new blocks. While this validation cost
|
||||
is small, it may exacerbate any existing DoS opportunities, particularly during abnormal
|
||||
events like long reorgs. Fortunately, these costs are logarithmic in the number of delete
|
||||
and append operations. In the worst case scenario, a well-resourced attacker could
|
||||
maintain 2 chains of approximately equal length, and alternate which chain they extend.
|
||||
This would result in repeated reorgs of increasing length.
|
||||
|
||||
Given the performance of Blake2b, we expect this validation cost to be negligible.
|
||||
However, it seems prudent to benchmark potential MMR implementations during the
|
||||
implementation process. Should the validation cost be higher than expected, there are
|
||||
several potential mitigations, e.g. holding recently seen nodes in memory after a reorg.
|
||||
|
||||
Generally, header commitments have no impact on privacy. However, FlyClient has additional
|
||||
security and privacy implications. Because FlyClient is a motivating factor for this ZIP,
|
||||
it seems prudent to include a brief overview. A more in-depth security analysis of
|
||||
FlyClient should be performed before designing a FlyClient-based light client ecosystem
|
||||
for Zcash.
|
||||
|
||||
FlyClient, like all light clients, requires a connection to a light client server. That
|
||||
server may collect information about client requests, and may use that information to
|
||||
attempt to deanonymize clients. However, because FlyClient proofs are non-interactive and
|
||||
publicly verifiable, they could be shared among many light clients after the initial
|
||||
server interaction.
|
||||
|
||||
FlyClient proofs are probabilistic. When properly constructed, there is negligible
|
||||
probability that a dishonest chain commitment will be accepted by the verifier. The
|
||||
security analysis assumes adversary mining power is bounded by a known fraction of
|
||||
combined mining power of honest nodes, and cannot drop or tamper with messages between
|
||||
client and full nodes. It also assumes the client is connected to at least one full node
|
||||
and knows the genesis block. However, these security properties have not been examined
|
||||
closely in chain models with rapidly-adjusting difficulty.
|
||||
|
||||
|
||||
Additional Reading
|
||||
==================
|
||||
|
||||
|
|
Loading…
Reference in New Issue