CPS-0002 | Pointer Address Removal #374
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,41 @@ | ||
| --- | ||
| CPS: 2 | ||
| Title: Cardano Pointer Address Removal | ||
| Status: Open | ||
| Category: Ledger | ||
| Authors: | ||
| - Andrew Westberg <andrewwestberg@gmail.com> | ||
| Proposed Solutions: [] | ||
| Discussions: | ||
| - https://github.com/cardano-foundation/cips/pulls/374 | ||
| 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. | ||
|
|
||
| ## 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? | ||
|
There was a problem hiding this comment. I propose this: At some future hard fork (it is my personal preference to prioritize this):
There was a problem hiding this comment. 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. There was a problem hiding this comment.
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. There was a problem hiding this comment. 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 :) ). There was a problem hiding this comment. 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. There was a problem hiding this comment. 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. There was a problem hiding this comment. 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. There was a problem hiding this comment. What if funds at a Plutus script requires sending funds to a pointer address? There was a problem hiding this comment. 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! |
||
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.