NIPoPoWs under Velvet Fork

Andrianna Polydouri, Dionysis Zindros, Aggelos Kiayias

National and Kapodistrian University of Athens

Department of Informatics and Telecommunications

Decrypto Seminar
July 2021

Βlockchain model

Players in the peer-to-peer network

  • miners
    • generate new blocks by solving the PoW puzzle
  • full nodes
    • store whole blockchain information
  • clients
    • request up-to-date information

Prover - Verifier model

Client
Synchronization

Do we have to download the whole chain?

Light clients

Simplified Payment Verification (SPV)

Light clients

SPV protocol

  • not efficient enough
    • data grow linearly to the size of the chain

Superlight clients

  • logarithmic amount of data to the size of the chain
    • Superblock NIPoPoWs

Superblock NIPoPoWs

H(block) \leq T
  • all valid blocks:
  • "luckier" μ-level superblocks:
H(block) \leq \dfrac{T}{2^μ}

Superblock NIPoPoWs

Ideal superblock distribution

Superblock NIPoPoWs

Synchronization proof

  • security parameter m
  • proof contains at least m superblocks

Example for m = 3:

Superblock NIPoPoWs

Suffix proof π: contains some superblocks...

Superblock NIPoPoWs

How could the client do any verification on these unlinked blocks?

Superblock NIPoPoWs

Consensus Protocol changes

  • interlink data struture in block header
  • pointers to every most recent superblock

Consensus Protocol Update

Hard fork

  • not backwards compatible
  • change block header contents
  • unupgraded parties do not accept upgraded blocks and vice versa
  • may lead to permanent fork

Soft fork

  • backwards compatible
  • auxiliary data in coinbase transaction
  • unupgraded parties accept upgraded blocks but not vice versa
  • generally believed as less dangerous

Consensus Protocol Update

Velvet fork

  • backwards compatible
  • auxiliary data in coinbase transaction
  • unupgraded parties accept upgraded blocks and vice versa
  • protocol changes come as a recommendation
  • only a minority of miners is needed to upgrade

magic!

Superblocks under Velvet Fork

"Superblocks protocol can be deployed as-is under velvet fork"

Superblocks under Velvet Fork

The naive protocol

Superblocks under Velvet Fork

What could go wrong?

        adversarial blocks may include false super-pointers

         Is there a way to attack?

  Just ignore them as unupgraded!

Superblocks under Velvet Fork

Is there a way to attack?

 False super-pointers could mean...

  • pointing to superblocks of incorrect level
          but the client can verify the level of a block
  • not pointing to the most recent superblock
         but this would mean less superblocks in the adversarial proof

... so, can the adversary only harm his proofs by not playing fair?

Superblocks under Velvet Fork

Is there a way to attack?

 False super-pointers could also mean...

  • pointing to a block of a fork chain

Superblocks under Velvet Fork

"Thorny" blocks

Is there a way to attack?

Superblocks under Velvet Fork

The Chainsewing Attack

cut-and-paste portions of the honest chain

Superblocks under Velvet Fork

A specific Chainsewing Attack

cut-and-paste portions of the honest chain
skip honest upgraded blocks of attacked level

p \eqsim 0.3

Superblocks under Velvet Fork

The patch

honest miners ignore unupgraded and thorny blocks while updating the interlink

Superblocks under Velvet Fork

Combined Attack

Suppression & Chainsewing

Superblocks under Velvet Fork

Security

velvet honest majority assumption

\dfrac{t}{n_h} < \dfrac{1}{3}

Superblocks under Velvet Fork

Intuition

Superblocks under Velvet Fork

Security

simple chain quality does not suffice!

the adversary may attack only some superblocks...

\dfrac{t}{n_h} < \dfrac{1}{3}

Thank you!

Questions?

andriannapolyd@gmail.com

Made with Slides.com