Account Management in Proof of Stake Ledgers

Abstract

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...

Conclave: A Collective Stake Pool Protocol

“…On the PoS domain, Ouroboros [26] offers a brief description of how delegation can be used within the protocol. This idea is expanded in [21], which provides a formal definition of PoS wallets and includes stake pool formation method via certificates. However, the pool's management is again centralized around the operator; our work extends this line of work by enabling the formation of a collective pool.…”

“…Signature Verification: Upon receiving (Verify, sid, m, σ, vk ) from P , forward it to S. Upon receiving (Verified, sid, m, σ, φ) from S, set f as next: operations, e.g., issuing delegation certificates (cf. [21]). The public key vk i is also used to generate an address α i .…”

“…Importantly, it should operate in a trustless environment as, unfortunately, even in these scenarios, trust is not a given. Notably, our targeted audience is parties who wish to actively participate, i.e., always be online to perform the required consensus actions; parties who wish to remain offline may instead opt for delegation schemes [7,21].…”

“…In contrast, accumulating the power of multiple small parties in "pools" yields a steadier reward. As a result, PoW systems see the formation of mining pools, 5 while PoS systems usually favor delegation to stake pools [7,21] over "pure" PoS, where parties act independently. Finally, the ledger's performance and security are often better under fewer participants.…”

Blockchain Nash Dynamics and the Pursuit of Compliance

“…To address these issues, many blockchain systems introduce additional mechanisms on top of Bitcoin incentives, frequently with only rudimentary game theoretic analysis. These include: i) rewards for "uncle blocks" in Ethereum; ii) stake delegation [18] in Eos and Polkadot, where users assign their participation rights to delegates, as well as stake pools in Cardano [46]; iii) penalties [10,12] for misbehavior in Ethereum 2.0, that enforce forfeiture of large deposits (referred to as "slashing") if a party misbehaves, in the sense of being offline or using their cryptographic keys improperly. The lack of thorough analysis of these mechanisms is of course a serious impediment to the wider adoption of these systems.…”