Draft SPO on-chain voting proposal

cardano-foundation · Apr 4, 2023 · 86b1dd0 · 86b1dd0
1 parent 5bcdb9b
commit 86b1dd0
Showing 1 changed file with 243 additions and 0 deletions.
diff --git a/CIP-????/README.md b/CIP-????/README.md
@@ -0,0 +1,243 @@
+---
+CIP: ?
+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/pulls/496
+    - https://github.com/cardano-foundation/CIPs/pull/102
+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 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 signature from the SPO's current VRF credentials or Ed25519 declared cold 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) / [ * text .size (0..64) ]
+
+choice =
+  text .size (0..64) / [ * 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, in [CBOR-diagnostic](https://www.rfc-editor.org/rfc/rfc8949#name-diagnostic-notation) notation:
+
+```cbor
+{ 94:
+  { 0: "Pineapples on pizza?"
+  , 1:
+    [ "yes"
+    , "no"
+    ]
+  }
+}
+```
+
+Which serialises down to:
+
+```
+A1185EA2007450696E656170706C6573206F6E2070697A7A613F018263796573
+626E6F
+```
+
+### 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 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' signature is calculated from the blake2b-256 hash digest of the serialised `answer` restricted to fields `2` and `3`.
+
+For example, in [CBOR-diagnostic](https://www.rfc-editor.org/rfc/rfc8949#name-diagnostic-notation) notation:
+
+```cbor
+{
+  94: {
+    2: h'3d4854aed3e31d0f5b6637fcd73e8713d9eee86a81d20598f6cb88d9b2bc0a39',
+    3: 2,
+    4:
+      [ h'2dc2fa217af8b52251c4cdf538fa106cbf0b5beac3e74d05f97ceb33c0147a2c'
+      , [ h'056fa6393edbc2f32efe08b9cc455e67bdef6831a709794133cd28fff99b6693069fd27985f023bc419f303d8db998ec774c89e6763518c303f5afbaac31c9e0'
+        , h'2b5358a74c540d6e0e3dac47eff4c604'
+        ]
+      ]
+  }
+}
+```
+
+Which serialises down to:
+
+```
+A1185EA30258203D4854AED3E31D0F5B6637FCD73E8713D9EEE86A81D20598F6
+CB88D9B2BC0A390302048258202DC2FA217AF8B52251C4CDF538FA106CBF0B5B
+EAC3E74D05F97CEB33C0147A2C825840056FA6393EDBC2F32EFE08B9CC455E67
+BDEF6831A709794133CD28FFF99B6693069FD27985F023BC419F303D8DB998EC
+774C89E6763518C303F5AFBAAC31C9E0502B5358A74C540D6E0E3DAC47EFF4C6
+04
+```
+
+> **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. 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.
+
+### 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
+
+- [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
+
+## 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