Update CIP-15 to support multi-delegation

Co-authored-by: Kevin Hammond <kevin.hammond@iohk.io>

CIP-0015/README.md

@@ -1,37 +1,63 @@
 ---
 CIP: 15
-Title: Catalyst Registration Transaction Metadata Format
-Authors: Sebastien Guillemot <sebastien@emurgo.io>, Rinor Hoxha <rinor.hoxha@iohk.io>, Mikhail Zabaluev <mikhail.zabaluev@iohk.io>
+Title: Catalyst/Voltaire Registration Transaction Metadata Format (Updated)
+Authors: Sebastien Guillemot <sebastien@emurgo.io>, Rinor Hoxha <rinor.hoxha@iohk.io>, Mikhail Zabaluev <mikhail.zabaluev@iohk.io>, Giacomo Pasini <giacomo.pasini@iohk.io>, Kevin Hammond <kevin.hammond@iohk.io>
 Comments-URI: https://forum.cardano.org/t/cip-catalyst-registration-metadata-format/44038
 Status: Draft
 Type: Standards
-Created: 2020-01-05
+Created: 2021-12-06
 License: CC-BY-4.0
 ---
 
 ## Abstract
 
 Cardano uses a sidechain for its treasury system. One needs to "register" to participate on this sidechain by submitting a registration transaction on the mainnet chain. This CIP details the registration transaction format.
+This is a revised version of the original CIP-15.
 
 ## Motivation
 
-Cardano uses a sidechain for its treasury system ("Catalyst"). One of the desirable properties of this sidechain is that even if its safety is compromised, it doesn't cause loss of funds on the main Cardano chain. To achieve this, instead of using your wallet's recovery phrase on the sidechain, we need to use a brand new "voting key".
+Cardano uses a sidechain for its treasury system ("Catalyst") and for other voting purposes. One of the desirable properties of this sidechain is that even if its safety is compromised, it doesn't cause loss of funds on the main Cardano chain. To achieve this, instead of using your wallet's recovery phrase on the sidechain, we need to use a brand new "voting key".
 
 However, since 1 ADA = 1 vote, a user needs to associate their mainnet ADA to their new voting key. This can be achieved through a registration transaction.
 
+In addition, to encourage participation by a broader range of ADA holders, it should be possible to delegate one's rights to vote to (possibly multiple) representatives and/or expert voters. Such delegations will still be able to receive Catalyst rewards. 
+
 We therefore need a registration transaction that serves three purposes:
 
-1. Registers a "voting key" to be included in the sidechain
-2. Associates mainnet ADA to this voting key
-3. Declare an address to receive Catalyst rewards
+1. Registers a "voting key" to be included in the sidechain and/or delegates to existing "voting key"s
+2. Associates mainnet ADA to this voting key(s)
+3. Declares an address to receive Catalyst rewards
+
+
+Note: This schema does not attempt to differentiate delegations from direct registrations, as the two options have exactly the same format.  It also does not distinguish between delegations that are made as "private" arrangements (proxy votes)
+from those that are made by delegating to representatives who promote themselves publicly.
+Distinguishing these possibilities is left to upper layers or future revisions of this standard, if required.
+In this document, we will use the term 'delegations' to refer to all these possibilities.
 
 ## Specification
 
-### Voting key format
+### Registration metadata format
+
+A Catalyst registration transaction is a regular Cardano transaction with a specific transaction metadata associated with it.
+
+Notably, there should be five entries inside the metadata map:
+ - A non-empty array of delegations, as described below;
+ - A stake address for the network that this transaction is submitted to (to point to the Ada that is being delegated);
+ - A Shelley address discriminated for the same network  this transaction is submitted to to receive rewards.
+ - A nonce that identifies that most recent delegation
+ - A number that indicates the purpose of the vote
+
+### Delegation format
+
+A delegation assigns (a portion of) the ADA controlled by one or more UTxOs on mainnet to the voting key in the sidechain as voting power.  The UTxOs can be identified via the stake address at some designated point in time.
 
-A voting key is simply an ED25519 key. How this key is created is up to the wallet.
+Each delegation therefore contains:
+  - a voting key: simply an ED25519 public key. This is the spending credential in the sidechain that will receive voting power from this delegation. For direct voting it's necessary to have the corresponding private key to cast votes in the sidechain. How this key is created is up to the wallet.
+  - the weight that is associated with this key: this is an unsigned integer (CBOR major type 0) that represents the relative weight of this delegation over the total weight of all delegations in the same registration transaction.
+  The weight may range from 0 to 2^32-1.  Any greater value is capped to 2^32-1.
 
-### Associating stake with a voting key
+
+### Associating voting power with a voting key
 
 This method has been used since Fund 2.
 For future fund iterations, a new method making use of time-lock scripts may
@@ -41,29 +67,38 @@ Recall: Cardano uses the UTXO model so to completely associate a wallet's balanc
 
 Given the above, we choose to only associate staking keys with voting keys. Since most Cardano wallets only use base addresses for Shelley wallet types, in most cases this should perfectly match the user's wallet.
 
-### Registration metadata format
+The voting power that is associated with each delegated voting key is derived from the user's total voting power
+as follows.
 
-A Catalyst registration transaction is a regular Cardano transaction with a specific transaction metadata associated with it.
+1. The total weight is calculated as a sum of all the weights;
+2. The user's total voting power is calculated as a whole number of ADA (rounded down);
+3. The voting power associated with each voting key in the delegation array is calculated as the weighted fraction of the
+   total voting power (rounded down);
+4. Any remaining voting power is assigned to the last voting key in the delegation array.
+
+This ensures that the voter's total voting power is never accidentally reduced through poor choices of weights,
+and that all voting powers are exact ADA.
 
-Notably, there should be four entries inside the metadata map:
+### Example 
 
 Voting registration example:
 ```
 61284: {
-  // voting_key - CBOR byte array
-  1: "0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663",
+  // delegations - CBOR byte array 
+  1: [("0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663", 1), ("0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee", 3)],
   // stake_pub - CBOR byte array
   2: "0xad4b948699193634a39dd56f779a2951a24779ad52aa7916f6912b8ec4702cee",
   // reward_address - CBOR byte array
   3: "0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee47b60edc7772855324c85033c638364214cbfc6627889f81c4",
   // nonce
   4: 5479467
+  // voting_purpose: 0 = Catalyst, 1 = Council Election
+  5: 0
 }
 ```
-
-The entries under keys 1, 2, 3, and 4 represent the Catalyst voting key,
+The entries under keys 1, 2, 3, 4 and 5 represent the Catalyst delegation array,
 the staking key on the Cardano network, the address to receive rewards,
-and a nonce, respectively. A registration with these metadata will be
+a nonce, and a voting purpose, respectively. A registration with these metadata will be
 considered valid if the following conditions hold:
 
 - The nonce is an unsigned integer (of CBOR major type 0) that should be 
@@ -73,6 +108,12 @@ considered valid if the following conditions hold:
   the previous transaction data.
 - The reward address is a Shelley address discriminated for the same network
   this transaction is submitted to.
+- The delegation array is not empty
+- The weights in the delegation array are not all zero
+
+
+Delegation to the voting key `0xa6a3c0447aeb9cc54cf6422ba32b294e5e1c3ef6d782f2acff4a70694c4d1663` will have relative weight 1 and delegation to the voting key `0x00588e8e1d18cba576a4d35758069fe94e53f638b6faf7c07b8abd2bc5c5cdee` relative weight 3 (for a total weight of 4).
+Such a registration will assign 1/4 and 3/4 of the value in ADA to those keys respectively, with any remainder assigned to the second key.
 
 To produce the signature field, the CBOR representation of a map containing
 a single entry with key 61284 and the registration metadata map in the
@@ -120,6 +161,10 @@ Fund 4:
 It was planned that since Fund 4, `registration_signature` and the `staking_pub_key` entry inside the `key_registration` field will be deprecated.
 This has been deferred to a future revision of the protocol.
 
+Fund 8: 
+ - renamed the `voting_key` field to `delegations` and add support for splitting voting power across multiple vote keys.
+ - added the `voting_purpose` field to limit the scope of the delegations.
+
 ## Copyright
 
 This CIP is licensed under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.0/legalcode)

CIP-0015/schema.cddl

@@ -8,12 +8,16 @@ $staking_pub_key /= bytes .size 32
 $ed25519_signature /= bytes .size 64
 $reward_address /= bytes
 $nonce /= uint
+$prop /= uint
+$voting_purpose /= uint
+delegation = (vote_key: $voting_pub_key, proportion: $prop)
 
 key_registration = {
-  1 : $voting_pub_key,
+  1 : [+delegation],
   2 : $staking_pub_key,
   3 : $reward_address,
   4 : $nonce,
+  5 : $voting_purpose
 }
 
 registration_signature = {

CIP-0015/test-vector.md

@@ -35,17 +35,18 @@ Data to sign (human readable format)
   '2': '0x86870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e',
   '3': '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
   '4': 1234,
+  '5': 0
 },
 ```
 
 Metadata (CBOR encoding)
 ```
-a119ef64a40158200036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a002582086870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e03581de0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef041904d2
+a119ef64a50158200036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a002582086870efc99c453a873a16492ce87738ec79a0ebd064379a62e2c9cf4e119219e03581de0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef041904d20500
 ```
 
 Blake2b-256 hash of metadata
 ```
-a3d63f26cd94002443bc24f24b0a150f2c7996cd3a3fd247248de396faea6a5f
+fbab7239fc029ab0ec2f315dba767a6730a60a53c384507bd50c10b7ce26b737
 ```
 
 ### Output
@@ -56,10 +57,11 @@ a3d63f26cd94002443bc24f24b0a150f2c7996cd3a3fd247248de396faea6a5f
     '1': '0x0036ef3e1f0d3f5989e2d155ea54bdb2a72c4c456ccb959af4c94868f473f5a0',
     '2': '0x1c5d88aa573da97e5a4667e0f7c4a9c6a3d848934c3b0a5b9296b401540f2aef',
     '3': '0xe0ae3a0a7aeda4aea522e74e4fe36759fca80789a613a58a4364f6ecef',
-    '4': 1234
+    '4': 1234,
+    '5': 0
   },
   '61285': {
-    '1': '0x6c2312cd49067ecf0920df7e067199c55b3faef4ec0bce1bd2cfb99793972478c45876af2bc271ac759c5ce40ace5a398b9fdb0e359f3c333fe856648804780e'
+    '1': '0x783da057e5dadb75c6d6f1ae121df29106a5c4ed8d7c87927c89b5743e05659e2740172aa6c838304c2627a84536844973b34611e374e70e9183b96c85169a04'
   }
 }
 ```