A Gas-Efficient Superlight Bitcoin Client in Solidity

Abstract

Superlight clients enable the verification of proof-of-work-based blockchains by checking only a small representative number of block headers instead of all the block headers as done in simplified payment verification (SPV). Such clients can be embedded within other blockchains by implementing them as smart contracts, allowing for cross-chain verification. One such interesting instance is the consumption of Bitcoin data within Ethereum by implementing a Bitcoin superlight client in Solidity. While such theoretical constructions have demonstrated security and efficiency in theory, no practical implementation exists. In this work, we put forth the first practical Solidity implementation of a superlight client which implements the NIPoPoW superblocks protocol. Contrary to previous work, our Solidity smart contract achieves sufficient gasefficiency to allow a proof and counter-proof to fit within the gas limit of a block, making it practical. We provide extensive experimental measurements for gas consumption. The optimizations that enable gas-efficiency heavily leverage a novel technique which we term hash-and-resubmit, which almost completely eliminates persistent storage requirements, the most expensive operation of smart contracts in terms of gas. Instead, the contract asks contesters to resubmit data and checks their veracity by hashing it. Other optimizations include off-chain manipulation of proofs in order to remove expensive look-up structures, and the usage of an optimistic schema. We show that such techniques can be used to bring down gas costs significantly and may be of independent interest. Lastly, our implementation allows us to calculate concrete cryptoeconomic parameters for the superblocks NIPoPoWs protocol and in particular to make recommendations about the monetary value of the collateral parameters. We provide such parameter recommendations over a variety of liveness settings.

Verilay: A Verifiable Proof of Stake Chain Relay

“…The sync committee period only determines which public key to pass and validate, but does not affect the transaction's number of attributes. Resubmission of data to reduce storage costs has been proposed in literature before [7], [25], but involved the calculation of a hash or Merkle root on-chain. As the sync committee is part of the SSZ Merkle tree, this step can be omitted by the Verilay contract.…”

Proofs of Proof-of-Stake with Sublinear Complexity

“…Proof-of-work bootstrapping has been explored in the interactive [35] and non-interactive [37] setting using various constructions from superblocks [36], [31] to Fiat-Shamir [23] sampling [6], and proven secure in the Bitcoin backbone model [26], [25], [27]. Such constructions can be adopted without forking [56], [38] and have been deployed in practice [18]. They have also been used to deploy one-way [32] and two-way sidechains [1], [40], [55].…”

The velvet path to superlight blockchain clients

“…Proofs of Proof-of-Work have been proposed in the context of superlight clients [2,27], cross-chain communication [22,28,44], mining [26], as well as local data consumption by smart contracts [23]. Chain interlinking has been proposed for both chains and DAGs [21,36], has been deployed in production both since genesis [6,10] and using hard forks [41], and relevant verifiers have been implemented [7,8]. Deployability using soft forks has also been explored [47].…”