Distributed ledgers based on Proof-of-Work (PoW) are typically vulnerable when mining participation is low. During these periods, an attacker with a mining majority can mount serious attacks, like double spending or transaction censorship. Our work explores mechanisms to secure a ledger against such adversaries and puts forth the first rigorous study of checkpointing as a protection from 51% attacks. The core idea is to employ an external set of parties to finalize blocks after their creation. This idea takes the form of checkpointing and timestamping, the former ensuring low latency in a federated setting and the latter being fully decentralized. Crucially, we identify and protect against a (previously undocumented) attack, "block lead", thus our scheme is the first to guarantee liveness.

Blockchain protocols based on Proof-of-Stake (PoS) depend-by nature-on the active participation of stakeholders. If users are offline and abstain from the PoS consensus mechanism, the system's security is at risk, so it is imperative to explore ways to both maximize the level of participation and minimize the effects of non-participation. One such option is stake representation, such that users can delegate their participation rights and, in the process, form "stake pools". The core idea is that stake pool operators always participate on behalf of regular users, while the users retain the ownership of their assets. Our work provides a formal PoS wallet construction that enables delegation and stake pool formation. While investigating the construction of addresses in this setting, we distil and explore address malleability, a security property that captures the ability of an attacker to manipulate the delegation information associated with an address. Our analysis consists of identifying multiple levels of malleability, which are taken into account in our paper's core result. We then introduce the first ideal functionality of a PoS wallet's core which captures the PoS wallet's capabilities and is realized as a secure protocol based on standard cryptographic primitives. Finally, we cover how to use the wallet core in conjunction with a PoS ledger, as well as investigate how delegation and stake pools affect a PoS system's security. in the form of arbitrary attributes, which are useful for particular system operations. We identify the following desiderata for addresses in a PoS setting: Address Non-malleability: Given an address (and possibly also transactions associated with that address), it should be infeasible for an attacker to construct a different address that shares only some of its attributes, most importantly its payment key. Address Uniqueness: It should be unlikely for the address generation process to produce two equal addresses for different attributes, i.e. the addresses should be unique. Short Addresses: The addresses should be relatively short, in order to be usable and storage efficient. Multiple Types of Addresses: It should be possible to construct more than one type of addresses, with each type supporting a different subset of basic operations, e.g. to ban some addresses from staking or delegating to a stake pool. Multiple Device Support: An account should be able to exist on multiple devices that share no joint internal state. Address Recovery: An account should be able to identify its addresses, given the ledger and the payment keys which it controls. Privacy and unlinkability: Addresses should be indistinguishable and not publicly linkable to the account which manages them. An additional and equally important concern in the PoS setting is the "nothing at stake" problem [23]. As opposed to PoW, in PoS a player can easily create blocks that extend multiple parallel chains, an adversarial behavior which diverges from every PoS protocol's rules. Thus, an adversary may profit by attacking the syst...

No abstract

No abstract