Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CPS-0002 | Pointer Address Removal #374

Closed
wants to merge 4 commits into from
Closed

CPS-0002 | Pointer Address Removal #374

Changes from 1 commit
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
36d56a9
CIP-0078 - Cardano Pointer Address Removal
AndrewWestberg Nov 11, 2022
61c9745
apply appropriate category
rphair Jul 16, 2023
ba4d1e2
assign proper PR link
rphair Jul 16, 2023
e01f0b8
assign CPS number in document already assigned in PR title
rphair Jul 16, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
41 changes: 41 additions & 0 deletions CIP-PTR-ADDR/CPS-????.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,41 @@
---
CPS: ?
rphair marked this conversation as resolved.
Show resolved Hide resolved
Title: Cardano Pointer Address Removal
Status: Open
Category: Core
rphair marked this conversation as resolved.
Show resolved Hide resolved
Authors:
- Andrew Westberg <andrewwestberg@gmail.com>
Proposed Solutions: []
Discussions:
- https://github.com/cardano-foundation/cips/pulls/?
rphair marked this conversation as resolved.
Show resolved Hide resolved
Created: 2022-11-11
---

## Abstract
On Cardano, pointer addresses (having address prefix 0x41 or 0x51) have existed since the launch of Shelley Mainnet. There is a grand total of 11 of them in the ledger state as of the writing of this document. Of those, only 3 are correctly formatted and point to an actual stake address registration location on chain. Due to their lack of usage and inherent negative qualities discussed below, I propose we deprecate pointer addresses.

## Problem
The `minUTxO` amount on Cardano depends on the length of the address holding it. For example, sending a token to an Enterprise address requires less ada be locked than sending it to a typical wallet receiving address. In the same vein, pointer addresses are shorter than typical receiving addresses. On the surface, this seems like a good thing (less locked ada), but pointer addresses have other downsides if they were to become widely adopted.

### Problem 1
Pointer Addresses require a secondary chain lookup. One of the larger jobs of cardano-node is to maintain the ledger state and be able to take an epoch snapshot determining how much stake is owned by every staked address. For a typical receive address containing both a payment part and a staking part, there is no issue. The cardano-node can simply scan the ledger and categorize all the ada into stake addresses appropriately. If Pointer addresses were to see widespread use, every pointer address would require an additional lookup on the chain to find the actual staking address associated with it. At minimum, it would require an additional temporary cache to map pointers to their stake address. There is a performance penalty for this lookup.

### Problem 2
Pointer Addresses demonstrate an anti-incentive pattern. Given that they reduce locked ada, they are less expensive to use. However, since they actually increase processing requirements of the node, they should be more expensive to use.

### Problem 3
Pointer Addresses require additional steps for a Wallet to get a user's ada into a staked state. In a typical wallet, ada is put into receive addresses containing both payment/stake addresses. The minute a stake key is registered and delegated, often within the same transaction, all of the user's ada becomes staked. If a wallet was using pointer addresses, it would first have to register the stake key on chain and wait for it to settle. Then, all ada would need to be moved into new pointer addresses referencing the stake key registration location. Finally, the wallet would need to be delegated. At minimum, it requires two transactions to get a wallet staked, where it only requires a single transaction with a typical wallet.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another problem:
The pointer address format is of undefined length which makes it harder to extend the address format in the future if ever needed (ex: #310)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this point (though I am in full agreement about getting rid of pointer addresses). The difficulty in extending the address format in the future is the fact that we have now committed the first four bits of the address to determining the type. Of these potential sixteen types, we are currently using eleven of them, two of which are for pointer addresses (one for each type of payment credential). I don't see how the variable-length encoding is related to extending the formats.

## Use cases
There's no real use case other than to close the door on a technology that isn't useful to Cardano. The idea is to remove the perverse incentives brought about by pointer addresses before wallet makers realize that they can be cheaper to operate for users who have large amounts of token types. By deprecating pointer addresses, we remove the potential performance impact that a wallet employing pointer addresses would have on the ecosystem.


## Goals
1. Remove perverse incentives of Pointer Addresses
2. Prevent performance impacts of Pointer Addresses
3. Continue using a single transaction to both register a staking key and delegate all ada in a wallet to a pool.

## Open Questions
What is the best way to deprecate pointer addresses?
- Hardfork and not allow them to be used at all for output utxos?
- Hardfork and allow them to be used, but don't count them as staked?
Copy link
Contributor

@JaredCorduan JaredCorduan Nov 14, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I propose this:

At some future hard fork (it is my personal preference to prioritize this):

  • disallow the creation of new pointer addresses
  • translate the existing pointer addresses in the UTxO to normal addresses at the moment of the hardfork:
    • if the pointer is valid, convert the pointer to the corresponding stake credential (vkey hash)
    • if the pointer in invalid, convert the pointer addresses to an enterprise address (ie only a payment credential)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When you say "convert them", won't this cause problems for wallets that are already referencing the pointer addresses?

I think it might make more sense to just leave them as-is, but they no longer count as staked. They can still be referenced as holding input utxos, but they will no longer be allowed to be used for transaction output targets.

I think this would be the most seamless upgrade path, but happy to hear more about the automatic conversion process too.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When you say "convert them", won't this cause problems for wallets that are already referencing the pointer addresses?

It could, yes (it would depend on what they do). Are you aware of any wallets that support them? I think of the 11 of them in the ledger state, I think less than half of them are even valid.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized that there are really two cases that the wallets might care about: 1) utxo mysteriously disappearing (ie tracking a pointer address that turns into a normal address), and 2) utxo that are owned by a payment credential that the wallet is unaware of (because they were introduced by the translation).

Provided there isn't a proliferation of pointer addresses between now and when this hard fork event happens, we have to decide if a smooth migration is worth the ~3 UTxO that are effected. I think @SebastienGllmt owns one of them. :) (of course, by drawing attention to this, maybe the situation will get worse, but I guess that ship has sailed :) ).

Copy link
Member

@KtorZ KtorZ Nov 15, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am proud (or ashamed?) to be one of the member of the 11-VIP-Pointer-Club. For what it's worth, I wouldn't mind this UTxO to be turned into a normal UTxO through the procedure you're describing Jared.

In principle, wallets do discover UTxO by addresses, not by output reference. So in theory, changing the underlying UTxO but preserving the same locking conditions (and if possible, delegation) should work just fine.

Plus, the few users that have created pointer addresses (if they aren't already all in the room) are most likely tech-savvy enough to recover their funds at the target addresses themselves; provided that the credentials owning them remains the same.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just realized a potentially huge complication with my proposed plan. It may be very difficult to give the hard fork combinator access to the pointer map (which is needed to resolve pointers into stake credentials). The consensus layer and the ledger currently enjoy a really great logical separation. Getting the pointer map into the translation context may break this abstraction.

If this is indeed prohibitively problematic, I will instead just propose translating all pointer addresses to enterprise addresses.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think enterprise addresses makes sense. There's little reason to go through the extra work of coding the resolver for all the pointer addresses for just 3 valid ones.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What if funds at a Plutus script requires sending funds to a pointer address?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a very good point, @jmhrpr . Not resolving the pointers (as you suggested in the cardano-ledger PR) makes them effectively an enterprise address. I doubt anyone is doing something like this inside a plutus script (since there are only ~11 of them on mainnet), but what you suggest is probably the more proper thing to do. thank you for pointing this out!