11 research outputs found

    Bypassing Non-Outsourceable Proof-of-Work Schemes Using Collateralized Smart Contracts

    Get PDF
    Centralized pools and renting of mining power are considered as sources of possible censorship threats and even 51% attacks for decentralized cryptocurrencies. Non-outsourceable Proof-of-Work schemes have been proposed to tackle these issues. However, tenets in the folklore say that such schemes could potentially be bypassed by using escrow mechanisms. In this work, we propose a concrete example of such a mechanism which is using collateralized smart contracts. Our approach allows miners to bypass non-outsourceable Proof-of-Work schemes if the underlying blockchain platform supports smart contracts in a sufficiently advanced language. In particular, the language should allow access to the PoW solution. At a high level, our approach requires the miner to lock collateral covering the reward amount and protected by a smart contract that acts as an escrow. The smart contract has logic that allows the pool to collect the collateral as soon as the miner collects any block reward. We propose two variants of the approach depending on when the collateral is bound to the block solution. Using this, we show how to bypass previously proposed non-outsourceable Proof-of-Work schemes (with the notable exception for strong non-outsourceable schemes) and show how to build mining pools for such schemes

    Multi-mode Cryptocurrency Systems

    Get PDF
    In the past years, the security of Bitcoin-like protocols has been intensively studied. However, previous investigations are mainly focused on the single-mode version of Bitcoin protocol, where the protocol is running among full nodes (miners). In this paper, we initiate the study of multi-mode cryptocurrency protocols. We generalize the recent framework by Garay et al. (Eurocrypt 2015) with new security definitions that capture the security of realistic cryptocurrency systems (e.g. Bitcoin with full and lightweight nodes). We provide the first rigorous security model for addressing the blockchain bloat issue. As an immediate application of our new framework, we analyze the security of existing blockchain pruning proposals for Bitcoin aiming to improve the storage efficiency of network nodes by pruning unnecessary information from the ledger

    Improving Authenticated Dynamic Dictionaries, with Applications to Cryptocurrencies

    Get PDF
    We improve the design and implementation of two-party and three-party authenticated dynamic dictionaries and apply these dictionaries to cryptocurrency ledgers. A public ledger (blockchain) in a cryptocurrency needs to be easily verifiable. However, maintaining a data structure of all account balances, in order to verify whether a transaction is valid, can be quite burdensome: a verifier who does not have the large amount of RAM required for the data structure will perform slowly because of the need to continually access secondary storage. We demonstrate experimentally that authenticated dynamic dictionaries can considerably reduce verifier load. On the other hand, per-transaction proofs generated by authenticated dictionaries increase the size of the blockchain, which motivates us to find a solution with most compact proofs. Our improvements to the design of authenticated dictionaries reduce proof size and speed up verification by 1.4-2.5 times, making them better suited for the cryptocurrency application. We further show that proofs for multiple transactions in a single block can compressed together, reducing their total length by approximately an additional factor of 2. We simulate blockchain verification, and show that our verifier can be about 20 times faster than a disk-bound verifier under a realistic transaction load

    Edrax: A Cryptocurrency with Stateless Transaction Validation

    Get PDF
    We present EDRAX, an architecture for cryptocurrencies with stateless transaction validation. In EDRAX, miners and validating nodes process transactions and blocks simply by accessing a short commitment of the current state found in the most recent block. Therefore there is no need to store off-chain and on-disk, order-of-gigabytes large validation state. We present two instantiations of EDRAX, one in the UTXO model and one in the accounts model. Our UTXO instantiation uses sparse Merkle trees, which are very fast and require no trusted setup. Our accounts instantiation uses a distributed vector commitment, a type of vector commitment that has state-independent updates, meaning it can be synchronized by accessing only update data (e.g., send 5 ETH from Alice to Bob). Towards this goal, we build a new succinct distributed vector commitment based on multiplexer polynomials and zk-SNARKs, that scales up to one billion accounts. We perform an extensive experimental evaluation comparing to other (recently) proposed approaches for stateless transaction validation, showing that sparse Merkle trees and our new distributed vector commitment offer excellent tradeoffs in this application domain

    TwinsCoin: A Cryptocurrency via Proof-of-Work and Proof-of-Stake

    Get PDF
    We design and implement TwinsCoin, the first cryptocurrency based on a provably secure and scalable public blockchain design using both proof-of-work and proof-of-stake mechanisms. Different from the proof-of-work based Bitcoin, our construction uses two types of resources, computing power and coins~(i.e., stake). The blockchain in our system is more robust than that in a pure proof-of-work based system; even if the adversary controls the majority of mining power, we can still have the chance to secure the system by relying on honest stake. In contrast, Bitcoin blockchain will be insecure if the adversary controls more than 50\% of mining power. Our design follows a recent provably secure proof-of-work/proof-of-stake hybrid blockchain by Duong et al.~(ePrint 2016). In order to make our construction practical, we enhance Duong et al.\u27s design. In particular, we introduce a new strategy for difficulty adjustment in the hybrid blockchain and provide an analysis of it. We also show how to construct a light client for proof-of-stake cryptocurrencies and evaluate the proposal practically. We implement our new design. Our implementation uses a recent modular development framework for blockchains, called Scorex. It allows us to change only certain parts of an application leaving other codebase intact. In addition to the blockchain implementation, a testnet is deployed. Source code is publicly available

    Hyperproofs: Aggregating and Maintaining Proofs in Vector Commitments

    Get PDF
    We present Hyperproofs, the first vector commitment (VC) scheme that is efficiently maintainable and aggregatable. Similar to Merkle proofs, our proofs form a tree that can be efficiently maintained: updating all nn proofs in the tree after a single leaf change only requires O(logn)O(\log{n}) time. Importantly, unlike Merkle proofs, Hyperproofs are efficiently aggregatable, anywhere from 10×10\times to 41×41\times faster than SNARK-based aggregation of Merkle proofs. At the same time, an individual Hyperproof consists of only logn\log{n} algebraic hashes (e.g., 32-byte elliptic curve points) and an aggregation of bb such proofs is only O(log(blogn))O(\log{(b\log{n})})-sized. Hyperproofs are also reasonably fast to update when compared to Merkle trees with SNARK-friendly hash functions. As another benefit over Merkle trees, Hyperproofs are homomorphic: digests (and proofs) for two vectors can be homomorphically combined into a digest (and proofs) for their sum. Homomorphism is very useful in emerging applications such as stateless cryptocurrencies. First, it enables unstealability, a novel property that incentivizes proof computation. Second, it makes digests and proofs much more convenient to update. Finally, Hyperproofs have certain limitations: they are not transparent, have linear-sized public parameters, are slower to verify, and have larger aggregated proofs and slower verification than SNARK-based approaches. Nonetheless, end-to-end, aggregation and verification in Hyperproofs is 10×10\times to 41×41\times faster than in SNARK-based Merkle trees

    A Gas-Efficient Superlight Bitcoin Client in Solidity

    Get PDF
    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 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 gas-efficiency 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
    corecore