Draft SPO on-chain voting proposal

Co-authored-by: gufmar
cardano-foundation · Apr 19, 2023 · f913b96 · f913b96
1 parent 5bcdb9b
commit f913b96
Showing 1 changed file with 350 additions and 0 deletions.
diff --git a/CIP-0094/README.md b/CIP-0094/README.md
@@ -0,0 +1,350 @@
+---
+CIP: 94
+Title: On-chain SPO polls
+Category: Tools
+Status: Proposed
+Authors:
+    - Matthias Benkort <matthias.benkort@cardanofoundation.org>
+    - Markus Gufler <markus.gufler-ext@cardanofoundation.org>
+Implementors:
+    - Matthias Benkort <matthias.benkort@cardanofoundation.org>
+Discussions:
+    - https://github.com/cardano-foundation/cips/pull/496
+    - https://github.com/cardano-foundation/cips/pull/102
+    - https://github.com/input-output-hk/cardano-node/pull/5050
+Created: 2023-03-21
+License: CC-BY-4.0
+---
+
+## Abstract
+
+The Cardano Foundation proposes a mechanism for polling Cardano stake pool operators on specific topics. Polls are done on-chain through transaction metadata and authenticated through stake pool credentials (either VRF public key similar to what's described in [CIP-0022](../CIP-0022) or Ed25519 cold key). The goal is to gather opinions on governance matters such as protocol parameter updates. This standard is an inclusive interim solution while the work on a larger governance framework such as [CIP-1694][] continues.
+
+## Motivation: why is this CIP necessary?
+<!-- A clear explanation that introduces the reason for a proposal, its use cases and stakeholders. If the CIP changes an established design, then it must outline design issues that motivate a rework. For complex proposals, authors must write a Cardano Problem Statement (CPS) as defined in CIP-9999 and link to it as the `Motivation`. -->
+
+Governance is difficult. Discussions on CIP-1694 can attest to that quite clearly. There are constant debates within the Cardano community about changing protocol parameters, and the decision ultimately falls -- at this stage still -- onto the three genesis entities: Input Output, The Cardano Foundation and Emurgo. Yet, at this stage, few governance tools are at their disposal to make educated decisions. Besides Twitter polls, newsletter surveys, and SPO town halls on Discord, we have identified a gap and an opportunity to engage with the Cardano community through means currently at our disposal.
+
+Conducting an on-chain poll between SPOs can also be seen as an experiment and an evaluation of the network's participation and engagement in the governance questions. Even though we only propose to poll one particular group of the Cardano community (the SPOs), such events can help to provide actual data to fuel the conversations around CIP-1694.
+
+In summary, the goals are:
+
+1. [x] to make some first experimental baby steps in the realm of governance;
+1. [x] to be achievable _now_ (or an in immediate future);
+1. [x] to capture participation data from SPOs;
+1. [x] to raise awareness amongst SPOs regarding their future role in governance;
+1. [x] to keep the Voltaire dynamics up in the ecosystem while other efforts are being pursued;
+1. [x] to improve relations between the Cardano Foundation & SPOs for better mutual understanding and fruitful conversations.
+
+
+## Specification
+
+### Overview
+
+Polls will be multiple-choice questions by The Cardano Foundation with pre-defined answers to choose from.
+
+Here's an example of a question and answers:
+
+- _Pineapples on pizza?_
+  - [ ] yes
+  - [ ] no
+
+The serialised question and answers will be posted on-chain and signed by one of the delegate genesis keys owned by The Cardano Foundation. Answers will be provided on-chain by participating SPOs via transaction metadata referring to:
+
+- The question and answers
+- The index of the chosen answer from the available choices
+- A digital signature (EdDSA) from the SPO's current cold key, or a VRF proof proving ownership of associated VRF credentials.
+
+> **Note**
+> In this document, every time we refer to a _serialized object_, we refer to its **canonical** CBOR representation. In particular, keys in a map are always ordered alphabetically.
+
+### Question structure
+
+A question is posted in a transaction's metadata using the metadata label `94` and the following metadata structure:
+
+```cbor
+question =
+  { 0: prompt
+  , 1: [ * choice ]
+  , ? "_": nonce
+  }
+
+prompt =
+  [ * text .size (0..64) ]
+
+choice =
+  [ * text .size (0..64) ]
+
+nonce =
+  uint
+```
+
+A nonce is optionally included to provide non-replayability should the same question and answers be asked multiple times over different periods. The transaction carrying a question **must** be signed by one of the genesis delegate keys to be considered valid. This genesis key signature isn't captured in the metadata but in the transaction itself as an extra signatory.
+
+For example:
+
+<table>
+<thead>
+  <th>CBOR diagnostic</td>
+  <th>Base16-encoded</th>
+</thead>
+<tbody>
+ <tr>
+  <td>
+<pre>
+{ 94:
+  { 0: [ "Pineapples on pizza?" ]
+  , 1:
+    [ [ "yes" ]
+    , [ "no" ]
+    ]
+  }
+}
+</pre>
+  </td>
+  <td>
+   <a target="_blank" href="https://cbor.me/?bytes=A1185EA200817450696E656170706C6573206F6E2070697A7A613F0182816379657381626E6F">
+<pre>
+A1185EA200817450696E656170706C6573206F6E
+2070697A7A613F0182816379657381626E6F
+</pre>
+   </a>
+  </td>
+ </tr>
+</tbody>
+</table>
+
+### Answer structure
+
+Similarly, an answer to a question is posted as transaction's metadata using the label `94` and the following metadata structure:
+
+```cbor
+answer =
+  { 2: question_hash
+  , 3: choice
+  , ? 4: vrf_witness
+  , ? 5: ed25519_witness
+  }
+
+question_hash =
+  bytes .size 32
+
+vrf_witness =
+  [ $vrf_vkey, vrf_proof ]
+
+vrf_proof =
+  [ bytes .size 64, bytes .size 16 ]
+
+ed25519_witness =
+  [ $vkey, $signature ]
+```
+
+Some remarks:
+
+1. The field `2` (`question_hash`) is a blake2b-256 hash digest, whose preimage is the entire serialised question metadata payload (with the `94` top-level label).
+1. The field `3` represents the 0-based index of the chosen answer from the available choices (from field `1` of the target poll).
+1. The fields `4` and `5` are not mutually optional; said differently, at least one of the two must be provided.
+    1. The `$vrf_vkey`, `$vkey` and `$signature` are as defined in the original [Cardano ledger specifications](https://github.com/input-output-hk/cardano-ledger/blob/master/eras/babbage/test-suite/cddl-files/real/crypto.cddl) with the usual rules applying to transaction metadata (i.e. byte string longer than 64 bytes are encoded as lists)
+    1. In either case (VRF or Ed25519), the witness is calculated from the blake2b-256 hash digest of the serialised `answer` restricted to fields `2` and `3`.
+
+> **Warning**
+>
+> Note that the VRF here is **NOT** used as a digital signature algorithm, but used to produce a proof of possession of the corresponding VRF secret key. This is a _slight abuse_ of the VRF scheme since the verifiable random output produced is completely discarded, though safe provided that the VRF secret key was generated independently of the cold key.
+>
+> Let's stress this out a little: it is extremely important for implementors to keep that difference in mind and to **NOT** attempt to use the cold key as a VRF secret in an attempt to generate a VRF proof! **Ed25519 is only proven secure in the setting where an adversary has access to only signatures**. Attempting to re-use the same secret for different purpose could have dramatic consequences.
+>
+> See [Insecurity On Secret Key Re-Usage](https://github.com/input-output-hk/blogpost_breaking_ed25519_vrf/blob/main/blog.md#insecurity-of-secret-key-re-usage) for further detail.
+
+
+For example:
+
+<table>
+<thead>
+  <th>Witness type</td>
+  <th>CBOR diagnostic</td>
+  <th>Base16-encoded</th>
+</thead>
+<tbody>
+ <tr>
+  <td>VRF</td>
+  <td>
+<pre>
+{
+  94: {
+    2: h'29093fd43fc30ba31e306af06ce8537390e1668ae7496fe53d53684683c3762c',
+    3: 0,
+    4:
+      [ h'2dc2fa217af8b52251c4cdf538fa106cbf0b5beac3e74d05f97ceb33c0147a2c'
+      , [ h'c1c4d0cf60529f091431c456bf528b23d384f641afc536d1347b0889e9fd45d47e422249ac4bb5bdd75c205ea35c1ef2d89d96c0f06070590a98db7dba659647'
+        , h'9a440df4e70830b22b86accbeab7bc07'
+        ]
+      ]
+  }
+}
+</pre>
+  </td>
+  <td>
+   <a target="_blank" href="https://cbor.me/?bytes=A1185EA302582029093FD43FC30BA31E306AF06CE8537390E1668AE7496FE53D53684683C3762C0300048258202DC2FA217AF8B52251C4CDF538FA106CBF0B5BEAC3E74D05F97CEB33C0147A2C825840C1C4D0CF60529F091431C456BF528B23D384F641AFC536D1347B0889E9FD45D47E422249AC4BB5BDD75C205EA35C1EF2D89D96C0F06070590A98DB7DBA659647509A440DF4E70830B22B86ACCBEAB7BC07">
+<pre>
+A1185EA302582029093FD43FC30BA31E306AF06C
+E8537390E1668AE7496FE53D53684683C3762C03
+00048258202DC2FA217AF8B52251C4CDF538FA10
+6CBF0B5BEAC3E74D05F97CEB33C0147A2C825840
+C1C4D0CF60529F091431C456BF528B23D384F641
+AFC536D1347B0889E9FD45D47E422249AC4BB5BD
+D75C205EA35C1EF2D89D96C0F06070590A98DB7D
+BA659647509A440DF4E70830B22B86ACCBEAB7BC
+07
+</pre>
+   </a>
+  </td>
+ </tr>
+ <tr>
+  <td>Cold key</td>
+  <td>
+<pre>
+{
+  94: {
+    2: h'29093fd43fc30ba31e306af06ce8537390e1668ae7496fe53d53684683c3762c',
+    3: 1,
+    5:
+      [ h'29ade2115fbcbc17f063eec41ec0d358ccc5b52c2bccb47c0918727695619a68'
+      , h'6458ff100279aed89b0ea08a57ddbf3b77e7c6802b8c23840da7df80b60f37c0ddd445499d247d27d7e7adaa189db001d0f1eddc2229daa6be7509c43cc23501'
+      ]
+  }
+}
+</pre>
+  </td>
+  <td>
+   <a target="_blank" href="https://cbor.me/?bytes=A1185EA302582029093FD43FC30BA31E306AF06CE8537390E1668AE7496FE53D53684683C3762C03010582582029ADE2115FBCBC17F063EEC41EC0D358CCC5B52C2BCCB47C0918727695619A6858406458FF100279AED89B0EA08A57DDBF3B77E7C6802B8C23840DA7DF80B60F37C0DDD445499D247D27D7E7ADAA189DB001D0F1EDDC2229DAA6BE7509C43CC23501">
+<pre>
+A1185EA302582029093FD43FC30BA31E306AF06C
+E8537390E1668AE7496FE53D53684683C3762C03
+010582582029ADE2115FBCBC17F063EEC41EC0D3
+58CCC5B52C2BCCB47C0918727695619A68584064
+58FF100279AED89B0EA08A57DDBF3B77E7C6802B
+8C23840DA7DF80B60F37C0DDD445499D247D27D7
+E7ADAA189DB001D0F1EDDC2229DAA6BE7509C43C
+C23501
+</pre>
+   </a>
+  </td>
+ </tr>
+</tbody>
+</table>
+
+> **Warning**
+>
+> Only the first answer to a poll for each credential shall be considered. If multiple answers are found, only the first answer submitted (transaction & block ordering tallying) shall be considered **unless** previous answers are from VRF keys and the latter from an associated cold key. In other words, it is possible to override a VRF-authenticated reply with a cold-key-authenticated one.
+
+### Duration
+
+A poll starts when a valid transaction with a question is posted on-chain and ends at the end of the following epoch, so there's always at least one entire epoch for answering the poll.
+
+In particular, the stake distribution of pools will be considered at the moment the poll is _started_.
+
+### Outcome
+
+The outcome of a poll will depend on its level of participation (in **terms of stake**). It is essential to understand that we explicitly call this a _poll_ / _survey_ and not a _vote_ to dispel any possible confusion. So it is akin to `1 Lovelace = 1 Voice` although we may chose to interpret data using different equations (e.g. giving more weight to pledged stake). How the data is interpret is deemed out of the scope of this proposal which aims mainly at producing the data-points. Further conversations and debates will be needed regarding interpretation of the data-points.
+
+
+This proposal does not introduce a change in the current governance scheme: it is still up to the three genesis entities to make a final call based on the poll results. Poll results will provide new data points to feed into the conversation. But, regardless of the outcome, any decision will be explained and motivated by other auditable sources of information. And on-chain polls will provide such an auditable source.
+
+## Rationale: how does this CIP achieve its goals?
+
+### Recording question & answers
+
+The proposed process will permanently record questions and their answers on-chain by leveraging existing transaction metadata. Note that we consciously do not record any element as datums. There are several reasons for this:
+
+1. Datums offer extra programmability (for being available in Plutus script context); this is not needed at this stage.
+1. Following a _keep-it-simple_ strategy, we propose relying on well-known and well-supported transaction features (a.k.a metadata) for producers and consumers.
+1. Storing data in datums / UTxO has a non-negligible cost; naive datum storage would create thousands of new dummy UTxO on each poll. Transactions are cheaper to store and consume.
+1. Polls rely on slot order when tallying answers, which means that chain sync is needed anyway, and there's no strong argument for having this information readily available in the UTxO graph.
+
+### Cold key vs VRF signing
+
+There have been several (off-the-record) discussions regarding using the cold key (Ed25519) vs the VRF key as a signing instrument; and arguments for both.
+
+On the one hand, some prefer the use of the cold key because:
+
+- The cold key is meant to authenticate stake-pools activity (e.g. certificate registrations/updates).
+- It is ultimately the cold key that identifies a pool; its hash is the _pool id_.
+- The VRF is more likely to be compromised, hence granting rights to participate in a poll to potential adversaries.
+
+On the other hand, arguments for using the VRF key were already discussed as part of [CIP-0022][]:
+
+- Because it's a hotkey, the VRF is usually more accessible, so it is more likely to lead to higher participation in surveys and no exposure of the cold key is needed.
+- Blocks are signed using VRF keys, which serve as explicit pool identifiers.
+- It is only necessary to check that a key is correct at the moment of the poll, making VRF keys perfectly suitable.
+
+All-in-all, we couldn't find a way to move the cursor in one direction more than the other, so we've opted for a dual-support. SPOs more comfortable using their cold key shall sign with it; others can rely on their readily available VRF. If both are found, the cold key takes precedence.
+
+#### KES Signing
+
+There's a third on-chain element which we could use for identifying SPOs which is a digital signature from their KES credentials. It is however a bit more annoying to leverage mainly because KES are meant to expire and are only loosely tied to pools by operational certificate. Thus, verifying KES signatures on a survey requires a more complex setup and monitoring to keep track of operational certificates and their validity at the time of the survey.
+
+If this CIP was meant to NOT be an interim solution, this is something we would likely consider. However, given the timeframe we're looking at and the overall trade-offs in complexity, we have opted out of using the KES as an authentication mechanism in this iteration.
+
+#### Proxy keys
+
+Another possible alternative to what's described in the CIP would be to have SPOs register a proxy Ed25519 key and use that proxy key onward. The validity of the proxy key registration would be conditionned to the production of an associated VRF proof or a digital signature from the cold key (very much like it's done for operational certificate).
+
+Yet, like the KES alternative, this option is in conflict with some of the design goals of this CIP: simplicity. All the more so given that we want to maximise participation of SPOs to the various surveys. We aim to make the process of participating to the survey as simple as possible, without compromising on security.
+
+> **Note** Both alternative options for KES Signing and Proxy Keys may be re-considered in a future version of the survey. Especially if the solution turns out to be not _as temporary as intended_. Fortunately, the current design decisions do not preclude this from happening as it shall be possible to introduce two new witness types `6` and `7` for those purpose. The KES registration can be handled through a separate on-chain event.
+
+### Transaction witness vs embedded metadata
+
+In the current proposal, we serialize signatures and proofs directly within the transaction metadata. One could make the argument that there's already room for Ed25519 key witness in the transaction which could be re-used here instead of being embedded in metadata. However, this is impractical in two places:
+
+- For producers of these metadata, which now have two inconsistent flow for producing witness. Indeed, there's no equivalent witness in the transaction for storing VRF proof, so proving using a VRF secret key will have to go in the metadata, whereas a digital signature could go as normal witness. Note that the ledger doesn't allow extraneous witnesses, which means that a signer would also have to add an "extra required signer" to the transaction; generating even more inconsistency.
+
+- For consumers of these metadata, which instead of relying on one consistent source of data (parsing metadata), now needs to also parse other parts of transactions, making the entire discovery process more involved.
+
+### Security
+
+#### Replayability
+
+Questions are meant to be unique, achieved using an optional nonce. It is up to the genesis entity conducting the poll to ensure the formulated question is unique. If the same question is asked several times, the nonce provides non-replayable protection.
+
+Then, because every answer contains a (unique) hash of the question, answers are unique too. Yet, it still means that the same answer can be recast multiple times (possibly, by another system actor), so we do not allow answers to be changed/cast multiple times. The only exception is when answers are authenticated again using a cold key.
+
+#### Credentials exposure
+
+Similar arguments for [CIP-0022][] still apply here w.r.t the VRF proof. So while it is clear that using a VRF proof for this purpose is sub-optimal, it doesn't put credentials at risk.
+
+Exposure to SPOs' secret credentials must be limited, and their manipulation shall be done carefully. This potential attack vector is why we propose to extend the `cardano-cli` and have support for these features scrutinised by existing core maintainers and other open source actors.
+
+Other tools are then free to replicate the approach taken in the cardano-cli, but we recommend that SPOs proceed with extreme caution when using third-party tools. In particular, any tool should be able to work fully offline to produce the required metadata. Final transaction construction and submission shall be made in any suitable environment, yet the metadata's production shall be done only in air-gapped systems.
+
+## Path to Active
+
+### Acceptance Criteria
+
+- [ ] Visible agreement and engagement from a large set of SPOs
+- [ ] The Cardano Foundation has conducted a first trial poll on mainnet
+
+### Implementation Plan
+
+- [ ] Possibly add support for KES signing as an alternative to EdDSA from the cold key and the VRF proving.
+
+#### Tools Support
+
+- [x] [`cardano-cli`](https://github.com/input-output-hk/cardano-node/tree/master/cardano-cli#readme) will be updated to provide support for constructing and signing relevant transactions
+  - [x] See [input-output-hk/cardano-node#5050](https://github.com/input-output-hk/cardano-node/pull/5050).
+- [ ] [`cncli`](https://github.com/cardano-community/cncli) might be updated with similar support
+- [ ] [`cardano-signer`](https://github.com/gitmachtl/cardano-signer) might be updated with similar support
+
+#### Test runs
+
+- [ ] Announce a testnet run and invite SPOs to a workshop session to conduct a testnet poll.
+- [ ] Possibly do a second test run, but on mainnet this time.
+
+## Copyright
+
+This CIP is licensed under [CC-BY-4.0][].
+
+[CIP-1694]: https://github.com/cardano-foundation/CIPs/pull/380
+[CIP-0022]: https://github.com/cardano-foundation/CIPs/pull/102
+[CC-BY-4.0]: https://creativecommons.org/licenses/by/4.0/legalcode
+[Apache-2.0]: http://www.apache.org/licenses/LICENSE-2.0