Subscribe to the gold package and get unlimited access to Shamra Academy
Register a new userDebt Representation in UTXO Blockchains
185
0
0.0
(
0
)
Added by
Michael Chiu
Publication date
2021
fields
Informatics Engineering
and research's language is
English
Ask ChatGPT about the research
No Arabic abstract
We provide a UTXO model of blockchain transactions that is able to represent both credit and debt on the same blockchain. Ordinarily, the UTXO model is solely used to represent credit and the representation of credit and debit together is achieved using the account model because of its support for balances. However, the UTXO model provides superior privacy, safety, and scalability when compared to the account model. In this work, we introduce a UTXO model that has the flexibility of balances with the usual benefits of the UTXO model. This model extends the conventional UTXO model, which represents credits as unmatched outputs, by representing debts as unmatched inputs. We apply our model to solving the problem of transparency in reverse mortgage markets, in which some transparency is necessary for a healthy market but complete transparency leads to adverse outcomes. Here the pseudonymous properties of the UTXO model protect the privacy of loan recipients while still allowing an aggregate view of the loan market. We present a prototype of our implementation in Tendermint and discuss the design and its benefits.
rate research
Read More
Sharding, i.e. splitting the miners or validators to form and run several subchains in parallel, is known as one of the main solutions to the scalability problem of blockchains. The drawback is that as the number of miners expanding each subchain becomes small, it becomes vulnerable to security attacks. To solve this problem, a framework, named as textit{Polyshard}, has been proposed in which each validator verifies a coded combination of the blocks introduced by different subchains, thus helping to protect the security of all subchains. In this paper, we introduce an attack on Polyshard, called textit{the discrepancy} attack, which is the result of malicious nodes controlling a few subchains and dispersing different blocks to different nodes. We show that this attack undermines the security of Polyshard and is undetectable in its current setting.
A blockchain is a database of sequential events that is maintained by a distributed group of nodes. A key consensus problem in blockchains is that of determining the next block (data element) in the sequence. Many blockchains address this by electing a new node to propose each new block. The new block is (typically) appended to the tip of the proposers local blockchain, and subsequently broadcast to the rest of the network. Without network delay (or adversarial behavior), this procedure would give a perfect chain, since each proposer would have the same view of the blockchain. A major challenge in practice is forking. Due to network delays, a proposer may not yet have the most recent block, and may, therefore, create a side chain that branches from the middle of the main chain. Forking reduces throughput, since only one a single main chain can survive, and all other blocks are discarded. We propose a new P2P protocol for blockchains called Barracuda, in which each proposer, prior to proposing a block, polls $ell$ other nodes for their local blocktree information. Under a stochastic network model, we prove that this lightweight primitive improves throughput as if the entire network were a factor of $ell$ faster. We provide guidelines on how to implement Barracuda in practice, guaranteeing robustness against several real-world factors.
Full nodes, which synchronize the entire blockchain history and independently validate all the blocks, form the backbone of any blockchain network by playing a vital role in ensuring security properties. On the other hand, a user running a full node needs to pay a heavy price in terms of storage costs. E.g., the Bitcoin blockchain size has grown over 215GB, in spite of its low throughput. The ledger size for a high throughput blockchain Ripple has already reached 9TB, and it is growing at an astonishing rate of 12GB per day! In this paper, we propose an architecture based on fountain codes, a class of erasure codes, that enables any full node to encode validated blocks into a small number of coded blocks, thereby reducing its storage costs by orders of magnitude. In particular, our proposed Secure Fountain (SeF) architecture can achieve a near-optimal trade-off between the storage savings per node and the bootstrap cost in terms of the number of (honest) storage-constrained nodes a new node needs to contact to recover the blockchain. A key technical innovation in SeF codes is to make fountain codes secure against adversarial nodes that can provide maliciously formed coded blocks. Our idea is to use the header-chain as a side-information to check whether a coded block is maliciously formed while it is getting decoded. Further, the rateless property of fountain codes helps in achieving high decentralization and scalability. Our experiments demonstrate that SeF codes tuned to achieve 1000x storage savings enable full nodes to encode the 191GB Bitcoin blockchain into 195MB on average. A new node can recover the blockchain from an arbitrary set of storage-constrained nodes as long as the set contains ~1100 honest nodes on average. Note that for a 1000x storage savings, the fundamental bound on the number of honest nodes to contact is 1000: we need about 10% more in practice.
Fault tolerance of a blockchain is often characterized by the fraction $f$ of ``adversarial power that it can tolerate in the system. Despite the fast progress in blockchain designs in recent years, existing blockchain systems can still only tolerate $f$ below $frac{1}{2}$. Can practically usable blockchains tolerate a malicious majority, i.e., $f ge frac{1}{2}$? This work presents a positive answer to this question. We first note that the well-known impossibility of {em byzantine consensus} under $f ge frac{1}{2}$ does not carry over to blockchains. To tolerate $f ge frac{1}{2}$, we use {em byzantine broadcast}, instead of byzantine consensus, as the core of the blockchain. A major obstacle in doing so, however, is that the resulting blockchain may have extremely low throughput. To overcome this central technical challenge, we propose a novel byzantine broadcast protocol OverlayBB, that can tolerate $f ge frac{1}{2}$ while achieving good throughput. Using OverlayBB as the core, we present the design, implementation, and evaluation of a novel Proof-of-Stake blockchain called BCube. BCube can tolerate a malicious majority, while achieving practically usable transaction throughput and confirmation latency in our experiments with $10000$ nodes and under $f = 0.7$. To our knowledge, BCube is the first blockchain that can achieve such properties.
This work presents ContractChecker, a Blockchain-based security protocol for verifying the storage consistency between the mutually distrusting cloud provider and clients. Unlike existing protocols, the ContractChecker uniquely delegates log auditing to the Blockchain, and has the advantages in reducing client cost and lowering requirements on client availability, lending itself to modern scenarios with mobile and web clients. The ContractChecker collects the logs from both clients and the cloud server, and verifies the consistency by cross-checking the logs. By this means, it does not only detects the attacks from malicious clients and server forging their logs, but also is able to mitigate those attacks and recover the system from them. In addition, we design new attacks against ContractChecker exploiting various limits in real Blockchain systems (e.g., write unavailability, Blockchain forks, contract race conditions). We analyze and harden the security of ContractChecker protocols against the proposed new attacks. For evaluating the cost, we build a functional prototype of the ContractChecker on Ethereum/Solidity. By experiments on private and public Ethereum testnets, we extensively evaluate the cost of the ContractChecker in comparison with that of existing client-based log auditing works. The result shows the ContractChecker can scale to hundreds of clients and save client costs by more than one order of magnitude.
Log in to be able to interact and post comments
comments
Fetching comments
Sign in to be able to follow your search criteria
