forked from IntersectMBO/cardano-ledger
-
Notifications
You must be signed in to change notification settings - Fork 0
/
shelley-delegation.tex
4593 lines (3899 loc) · 199 KB
/
shelley-delegation.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
\documentclass[11pt,a4paper,dvipsnames,twosided]{article}
\usepackage[deliverable]{IOHKCoverPage}
% data for Deliverable header -- added by KH from an EU H2020 project template
\DeliverableNumber{SL-D1}
\DeliverableTitle{Design Specification for Delegation and Incentives in Cardano}{Delegation/Incentives Design Spec.}
\DeliverableResponsible{Formal Methods Team}
\EditorName{Philipp Kant, \IOHK}
\Authors{Philipp Kant \quad \texttt{<philipp.kant@iohk.io>}
\\[1em]
Lars Br\"unjes \quad \texttt{<lars.bruenjes@iohk.io>}
\\[1em]
Duncan Coutts \quad \texttt{<duncan.coutts@iohk.io>}
}
\DueDate{23$^{\textrm{th}}$ July 2020}
\SubmissionDate{23$^{\textrm{th}}$ July 2020}{2020/07/23}
\LeaderName{Philipp Kant, \IOHK}
\InstitutionAddress{\IOHK}
\Version{1.21}
\Project{Shelley Ledger}
\DisseminationPU
\usepackage[margin=2.5cm]{geometry}
\usepackage{lscape}
%\usepackage[a-1b]{pdfx}
\usepackage{microtype}
\usepackage{mathpazo} % nice fonts
\usepackage{amsmath, amssymb, stmaryrd, latexsym, mathtools}
\usepackage{extarrows}
\usepackage{slashed}
% \usepackage[colon]{natbib}
\newcommand{\citep}[1]{\cite{#1}}
\usepackage{todonotes}
\usepackage[unicode=true,pdftex,pdfa,colorlinks=true]{hyperref}
\usepackage[capitalise,noabbrev,nameinlink]{cleveref}
\usepackage{titlesec}
\hypersetup{
pdftitle={Design Specification for Delegation and Incentives in Cardano},
pdfauthor={Philipp Kant, Lars Brünjes, Duncan Coutts},
breaklinks=true,
bookmarks=true,
colorlinks=false,
linkcolor={blue},
citecolor={blue},
urlcolor={blue},
linkbordercolor={white},
citebordercolor={white},
urlbordercolor={white}
}
\usepackage{float}
\floatstyle{boxed}
\restylefloat{figure}
% For making figures
\usepackage{tikz}
\usetikzlibrary{positioning}
\usetikzlibrary{arrows.meta}
\usetikzlibrary{calc}
\setcounter{secnumdepth}{4}
\titleformat{\paragraph}
{\normalfont\normalsize\bfseries}{\theparagraph}{1em}{}
\titlespacing*{\paragraph}
{0pt}{3.25ex plus 1ex minus .2ex}{1.5ex plus .2ex}
\DeclareMathOperator{\dom}{dom}
\DeclareMathOperator{\range}{range}
\newcommand*\ema[2]{\left\langle {#1} \right\rangle_{{#2}}}
\newcommand*\mean[1]{\overline{#1}}
\newcommand\pbar{\overline{p}}
\newcommand\Nbar{\overline{N}}
\begin{document}
\cleardoublepage%
\tableofcontents%
\listoffigures%
\clearpage%
\begin{changelog}
\change{2018-12-18}{PK, LB, DC}{FM (IOHK)}{First version that is considered stable enough to warrant V1. Some things still
need to be pinned down.}
\change{2019-01-07}{PK, LB, DC}{FM (IOHK)}{
Changes after the first day of the Berlin workshop. TTL for transactions; stakepool registration.
% - Add todo to clarify stakepool metadata
% - Add section on TTL for transactions
% - Elaboration and slight change to stake pool registration.
% After the first day of discussions in Berlin, we came to the conclusions that
% - we need a \emph{registered} staking key to collect rewards
% - this should \emph{not} be the same key that's used for participating in the
% protocol. For participation in the protocol, we want cold and operational
% keys, and using the same key to withdraw rewards is detrimental.
% - We needed more elaboration on the multiple owner use case, emphasising that
% the rewards for all owners are given to the operator.
% - Resolved several todo items
% - Include git revision in documents
% - Explain why pool registration will not be censored.
}
\change{2019-01-08}{PK, LB, DC}{FM (IOHK)}{Changes after the second day of the Berlin workshop.
Avoid Contention at Epoch Boundary. Refunds after stake pool retirement. Clarifications and corrections.}
% - Avoid overloading the term "pool"
% - Clarify that Treasury is a Sink for now.
% - Avoid Contention at Epoch Boundary
% - Decision made: refund for stake pool paid after retirement.
% - Update to non-refundable part of deposits
% We figured out in the formal spec how to incrementally add the non-refundable
% part to the reward pool of all the relevant epochs, which is fairer than
% adding all of it to the reward pool where the resource is released.
% - Correction: we're introducing four address types, not three
%}
\change{2019-03-01}{PK, LB, DC}{FM (IOHK)}{Incorporating further input from the workshop in Berlin, and following discussions,
into the document. Transactions have to have at least one UTxO style input; stake pool metadata formats; choice of KES scheme; deposits information; clarify certificate replay protection; fix rewards to treasury for unregistered stake pool key; update block validity to require operational key;
additions to Operational Key section.}
% - Decision: transactions have to have at least one UTxO style input
% - Update: Stake pool metadata
% Specify the format for the metadata, and how it is provided. Streamlined the
% different sections that touch stake pool metadata.
% - Elaborating further on why stake pool registrations will not be censored.
% - Capture choice of KES scheme in design doc.
% - Streamlining information on deposits
% Replacing an explanation of the concept with a link to the section where it's
% already explained.
% - Elaborate on certificate replay protection
% The paragraph was not entirely true, it said there was only one possible source
% of funds in addition to UTxO entries, but with rewards accounts, there is
% another one.
% - Fix that rewards go to treasury if reward key unregistered.
% We can not move them to the rewards pool -- if we did, it would create an
% incentive for all other leaders to censor a certificate that caused the pool to
% use a valid certificate.
% - Update block validity to require operational key
% - Additions to Operational Key section
% - They are compulsory
% - They will use KES
% - Operational Key Certificates will expire, to encourage key rotation
% - Slight Change in validity rules
% - Add FAQ section to the delegation design doc
% - Add a couple of todo entries
% }
\change{2019-04-05}{PK, LB, DC}{FM (IOHK)}{Rewrote the chapter on rewards.
%
% We had lots of discussions about how to properly account for the performance of
% pools, particularly in Praos where the actual performance is not observable due
% to the private leader schedule. We finally converged to a solution, leading to a
% re-write of the incentives section.
% Also, changed the title of the document, and made the capitalisation of ada
% consistent.
}
\change{2019-04-08}{PK, LB, DC}{FM (IOHK)}{General review of the document.
Mostly small things. Consistent wording, spelling, readability, removed some
obsolete things.
%
% Removed the remaining todo items. Decisions we still need to make are now
% tracked on github instead.
%
% Moved the section on detecting stale stake into an appendix, and changed it to
% reflect the design where stake that is not delegated to an active pool is
% ignored (which solves the problem of stale stake to a large degree).
}
\change{2019-04-11}{PK, LB, DC}{FM (IOHK)}{Some subtle corrections in the rewards chapter after review by Aikaterina.
First version officially published on the IOHK blog.}
\change{2019-05-17}{PK, LB, DC}{FM (IOHK)}{Some clarifications in response to review by the auditors.}
\change{2019-06-07}{PK, LB, DC}{FM (IOHK)}{Update section on script addresses.}
\change{2019/10/09}{Kevin Hammond}{FM (IOHK)}{Added standard cover page.}
\change{2020-02-28}{PK}{FM (IOHK)}{Clarify when to use active/total stake.}
\change{2020/03/11}{DC}{FM (IOHK)}{Document the metadata feature.}
\change{2020-06-12}{PK}{FM (IOHK)}{Rewrite chapter on addresses. Now includes
multi-sig, and is clearer about the distinction of payment addresses, stake
addresses, credentials.}
\change{2020-06-15}{PK}{FM (IOHK)}{Ensure consistent wording, after the change
in terminology in the last edit.}
\changePageBreak
\change{2020-07-06}{PK}{FM (IOHK)}{Correct sentence about enforcing pledge, to
be consistent with implementation; pools do not receive rewards, but can still
create blocks when they fail to meet their pledge.}
\change{2020-07-06}{PK}{FM (IOHK)}{Minor changes after audit. Nothing that
affects the implementation.}
\change{2020-07-23}{PK}{FM (IOHK)}{Change: undistributed rewards go to the
reserves, not to the treasury.}
\change{2020-10-08}{J. Corduan}{FM (IOHK)}{Change: include member stake in the non-myopic
stake calculation. Change: replaced average apparent performance usage with
references to the stake pool ranking document.}
\end{changelog}
\clearpage%
\begin{landscape}
\floatstyle{plain}
\restylefloat{figure}
\begin{figure*}
\includegraphics[scale=0.8,angle=90]{d1-depends.pdf}
\caption{Positioning of this Deliverable (outlined in red).}
\end{figure*}
\end{landscape}
\floatstyle{boxed}
\restylefloat{figure}
\cleardoublepage
% \begin{center}
% \large{Executive Summary}
% \end{center}
% \noindent
% This document provides a formal specification of the Cardano ledger for use in the Shelley implementation.
% It is intended to form the basis for an executable specification that will be the basis of the initial
% release.
% \cleardoublepage
\renewcommand{\thepage}{\arabic{page}}
\setcounter{page}{1}
\title{Engineering Design Specification \\
for Delegation and Incentives \\
in Cardano--Shelley \\
{\large \sc An IOHK technical report}}
\author{Philipp Kant \\ {\small \texttt{philipp.kant@iohk.io}} \\
\and Lars Br\"unjes \\ {\small \texttt{lars.bruenjes@iohk.io}} \\
\and Duncan Coutts \\ {\small \texttt{duncan@well-typed.com}} \\
{\small \texttt{duncan.coutts@iohk.io}}}
\maketitle
\begin{abstract}
This document describes the requirements and design for a delegation and
incentives mechanism to be used in the Shelley release of Cardano.
\end{abstract}
\section*{List of Contributors}
\label{acknowledgements}
Lars Br\"unjes, Jared Corduan, Duncan Coutts, Matthias G\"udemann,
Philipp Kant, Dimitris Karakostas, Aggelos Kiayias, Elias Koutsoupias,
Mario Larangeira, Damian Nadales, Aikaterini-Panagiota Stouka.
%\tableofcontents
%\listoffigures
%% Not in final version -- KH
%\listoftodos
\section{Purpose}
\label{purpose}
Delegation will allow holders of ada to transfer their rights to participate in
the proof of stake (\emph{PoS}) protocol to \emph{stake pools}. Stake pools are
run by \emph{stake pool operators} (sometimes also called \emph{pool leaders},
though we try to avoid the term in this document to avoid confusion with slot
leaders), and a person delegating to a stake pool is called \emph{delegator},
\emph{member}, or \emph{participant} of a stake pool.
Introducing delegation is important to increase the stability and
performance of the system:
\begin{itemize}
\item
We cannot expect every holder of ada to continuously run a node that
is well-connected to the rest of the network, in order to write a
block on rare occasions. Some users might lack the expertise to do so.
Most users will not have enough stake to warrant running their own
node. Delegation allows all holders of ada to participate in the
protocol, regardless of their technical abilities and the amount of
stake that they hold. Thus, we expect less stake to be offline, making
the system faster and more resilient against an adversary.
\item
Even if every user were to run a node that was online all the time, it
would be hard to keep all those nodes well enough in sync to avoid
forks and still keep a short slot length. Our delegation design is
aimed at keeping the number of nodes that produce a significant amount
of blocks reasonably small (about 100 or 1000 nodes), so that effective
communication between them is feasible.
\end{itemize}
This document covers the design of necessary additions to Cardano in
order to support and incentivise delegation.
\section{Requirements}
\label{requirements}
The delegation mechanism should meet a number of requirements. They can
be grouped into:
\begin{itemize}
\item
functional requirements that the delegation system should provide;
\item
requirements to the security (both of the overall system and the funds
of individual users);
\item
non-functional requirements; and
\item
existing features that should not be impeded when we add delegation to
the system.
\end{itemize}
Requirements specific to the rewards distribution mechanism are
discussed separately in \cref{rewards}.
\subsection{Functional Requirements}
\label{functional-requirements}
\subsubsection{Proof of Eligibility}
\label{proof-of-eligibility}
Any slot leader -- and in particular stake pool operators, who are
elected through stake that is delegated to them -- should be able to
prove when they are eligible to produce a block in a given slot.
\subsubsection{Visibility of Delegation on the Blockchain}
\label{visibility-of-delegation-on-the-blockchain}
We enable stake pools to automatically share their rewards with the
delegators. In order to do this, there must be evidence for the
delegation happening. Furthermore, we want the sharing of rewards to be
enforced by the protocol, so the evidence must be recorded on the
blockchain.
\subsubsection{Restricting Chain Delegation}
\label{restricting-chain-delegation}
We do not want to allow stake to be re-delegated along a chain
arbitrarily. We can admit some level of indirection, but not more than
necessary to meet the rest of the requirements.
One reason that we do not want arbitrary chain delegation is that it
makes it harder for delegators to figure out who is ultimately
controlling their stake. Another is that unlimited chain delegation
could open up a Denial-of-Service (DoS) attack vector on the system,
where the attacker posts long delegation chains in order to slow down
processes that depend on delegation, such as leader election or rewards
sharing.
We must also have a mechanism to prevent cycles (such as A delegates to
B, and B delegates to A) which would introduce ambiguity to the question
of who manages stake in the end.
\subsubsection{Cheap Re-Delegation}
\label{cheap-re-delegation}
Changing delegation preferences should be as cheap as possible (while
still using appropriate fees to prevent a denial of service attack on
the blockchain).
\subsubsection{Neutral Addresses}
\label{neutral-addresses}
We should provide addresses that can hold value, but do not contribute
to the PoS protocol. Those might be appropriate for use by exchanges,
which will hold large amounts of value, without legally owning it.
\subsubsection{Multi-Signature Addresses}
\label{multi-sig-addresses}
We should provide addresses that can hold value that are owned by multiple
people, such that the signatures from a specified subset are required to spend
from those addresses. This needs to enable addresses where signatures are
required from any N of a pre-determined set of M keys.
\subsubsection{Multi-Signature Delegation}
\label{multi-sig-delegation}
We should provide the ability to declare that delegating the stake
rights for certain funds should require multiple signatures.
This should be as expressive as the multi-signature support for
addresses. It should be an independent choice: a multi-signature
address can use a single signature for its stake rights, or a
different choice of multi-signature threshold N and key set M. Similarly, it
should be possible to require multi-signature only for delegation, not for
spending from a given address.
\subsection{Security Requirements}
\label{security-requirements}
\subsubsection{Sybil Attack Protection at Stake Pool Level}
\label{sybil-attack-protection-at-stake-pool-level}
It is conceivable that an adversary might try to take over the
network by registering a large number of stake pools, hoping to
accumulate enough stake to mount an attack just by people randomly
delegating to them.
This Sybil attack on the level of stake pools should be made infeasible,
by requiring stake pool operators to allocate a finite resource to each
individual pool they register. In particular, this resource cannot be
the cost of operating a node, since it is possible to run multiple pools
with one node, so that cost would be constant in the number of pools an
adversary is registering.
\subsubsection{Address Non-malleability}
\label{address-nonmalleability}
The system should provide protection against the following attack:
\begin{description}
\item[Changing Delegation through Address Malleability]
Suppose that Alice makes a payment to Bob. In preparation, Bob transmits
an address belonging to his wallet to Alice, and expects Alice to pay to
that address. If his wallets later on shows that his balance is
increased by the expected amount, he considers that transaction to be
successful. An attacker that wants to increase their influence on the
PoS protocol changes the address that Bob sends in such a way that funds
in that address are delegated to the attacker, but the funds still show
up in Bob's wallet.
The attack is considered successful if the stake rights for the
transferred money belong to the attacker after the transaction, without
Alice and Bob noticing the attack.
\end{description}
Note that the system should still allow for deliberately separating spending
rights and the right to delegate, just not in the covert way described above.
\subsubsection{Public Payment Keys Should not be Disclosed Prematurely}
\label{public-spending-keys-should-not-be-disclosed-prematurely}
Delegation of stake should not involve revealing the public payment key (other
than the public key hash, which is already visible from the address itself). The
public payment key should only be revealed once the funds that are controlled
by the corresponding private key are actually transferred to another address.
\subsubsection{Mitigate Key Exposure}
\label{mitigate-key-exposure}
A node run by a stake pool will need to have some key that controls all
the delegated stake, in order to sign blocks. In case of an incident
where the node is compromised, it should be possible for the stake pool
operator to revoke the key, and replace it with a new one. This should
not require any action by the delegators.
\subsubsection{Handle Inactive Stake Pools}
\label{handle-inactive-stake-pools}
We anticipate that some participants might not contribute to the proof-of-stake
protocol -- whether they lost their keys, lost interest, etc. We want to
minimise the effect of this to the security and liveness of the system.
Note that this does not only concern large stakeholders or pool operators. The
cumulative effect of a large number of small stakeholders having their stake be
inactive also has to be considered.
\subsubsection{Avoid Hard Transition}
\label{avoid-hard-transition}
When we make the switch from Byron (where all stake is delegated to the
nodes controlled by the Cardano Foundation, Emurgo, and IOHK) to Shelley
(where ada holders have the freedom to control their stake), we should
avoid a scenario where a significant amount of stake is suddenly
offline.
This could happen if we automatically revoked the automatic delegation
to the core nodes of the Byron network.
\subsubsection{Change Delegation Without Payment Key}
\label{change-delegation-without-spending-key}
Users of a cold wallet, such as a paper wallet or a hardware wallet,
should be able to delegate the stake corresponding to the funds in the
cold wallet without using its payment key.
\subsection{Non-functional Requirements}
\label{non-functional-requirements}
\subsubsection{Asymptotic space and time complexity}
\label{asymptotic-space-and-time-complexity}
All the changes to delegation are changes in the rules that define what
it means to be a valid Cardano blockchain. These rules must be
computable, and must be computable with reasonable space and time
complexity.
\subsubsection{Minimise economic attacks}
\label{minimise-economic-attacks}
An economic attack on a system arises where the costs incurred by the
operators of a system are not covered by fees on the users of the
system. Such situations allow users to impose costs on operators without
paying that full cost themselves. In severe cases this can lead to
operators dropping out and the system collapsing.
Cardano currently has transaction fees which are intended to cover the
processing and long term storage cost of transactions. There are no fees
however for the memory cost of tracking the current accumulated chain
state, in particular the UTxO. In addition, the new mechanisms
introduced for delegation add additional state that must be tracked.
Moving from federated operation to fully decentralised operation may
increase the incentive to exploit economic attacks, so it is important
to address the existing unaccounted operator costs as well as new costs.
\subsection{Requirements to Preserve Existing Features}
\label{requirements-to-preserve-existing-features}
\subsubsection{Master Recovery Key}
\label{master-recovery-key}
The whole wallet should be recoverable from one single key (without any
additional information, such as the delegation preferences of the
wallet).
The computational complexity of the recovery process should not be worse
than logarithmic in the number of addresses appearing on the blockchain,
and linear in the number of addresses in the wallet.
\subsubsection{Address Recognition}
\label{address-recognition}
An HD wallet should be able to recognise its addresses in the UTxO, so
that it can report balances and transaction histories to the user.
\subsubsection{Wallet should be Runnable on Independent Devices}
\label{wallet-should-be-runnable-on-independent-devices}
Different user interfaces, running on different devices, should be able
to access and control the same wallet, without transferring state
between them.
We will accept some degradation of behaviour when running the wallet on
different devices:
\begin{itemize}
\item
Both copies might generate the same fresh addresses
\item
There can be differences in the reported balance while there are
transactions in flight that only one of the two copies has knowledge
of. In particular, when one copy sends a transaction, that transaction
will only affect the balance reported by the other wallet once it is
recorded on the blockchain.
\item
If the wallets use different delegation preferences, funds sent to the
wallet might end up being delegated to different pools.
\end{itemize}
\subsubsection{Maintain Privacy}
\label{maintain-privacy}
HD Wallets maintain some level of privacy by using multiple addresses
that are not obviously and publicly tied to the same wallet. Delegating
stake should not necessarily link the addresses in the wallet of a
delegator.
\subsubsection{Short Addresses}
\label{short-addresses}
It is beneficient to have short addresses, for two reasons: addresses are
user-facing, and overly long addresses are burdensome for users. Also, every
UTxO entry contains an address, so short addresses reduce the memory footprint
of the UTxO and the whole ledger state.
Adding delegation to the system should not increase the length of
addresses more than necessary. Ideally, we should use the opportunity of having
to modify the address scheme to come up with an address length that is
even shorter than in Byron.
\subsubsection{No lookup of old blocks}
\label{no-lookup-of-old-blocks}
The current Cardano design allows, in principle, an implementation of a
node that discards blocks after a period of time so that it only needs
to keep a limited number of recent blocks. This is true in part because
nothing in the existing validation rules requires looking up arbitrary
old blocks. All information necessary for validation can be accumulated
in a running state, in a \texttt{foldl} style. This is a useful design
property to retain.
\subsection{Design Goals}
\label{design-goals}
\subsubsection{No Special Wallet for Stake Pool Operators}
\label{no-special-wallet-for-stake-pool-operators}
If possible, we would like to avoid a situation where stake pool
operators are required to use a special kind of wallet. Apart from
registering their pool and running their own nodes, they should be able
to use the same wallet as anyone else, without any additional or
restricted features.
We expect that following this design goal will lead to less engineering
effort, better maintainability, and a better user experience for stake
pool operators.
\section{Design of Delegation}
\label{design-of-delegation}
\newcommand{\hash}[1]{\ensuremath{\mathcal{H}(#1)}}
\subsection{Overview of Delegation}
\label{overview-of-delegation}
Delegation is a separation of the control over the movements of funds and the
rights (and obligations) in the PoS protocol that are associated with those
funds. We achieve this separation by modelling it in the address structure. We
distinguish between \emph{payment addresses} that determine how funds can be
spent, and \emph{stake addresses} that define if and how the stake rights of
those funds take part in the PoS protocol. Coins belong to payment addresses.
Each payment address (optionally) refers to a stake address. This delegates the
stake rights of any funds held at the payment address to the corresponding stake
address. The stake address delegates to a stake pool that participates directly
in the PoS protocol. Thus overall there are two steps to the delegation of stake
rights: a payment address refers to a stake address; and the stake address
delegates to a stake pool.
We support multi signature (multi-sig) schemes, for payments as well as for
delegations. We do this by allowing value addresses and stake addresses to use
either keypairs, or scripts for authorisation, and implementing a simple
scripting language to describe multi-sig schemes. Introducing multi-sig in this
way has the benefit of naturally generalising when we will later introduce more
powerful scripting languages, such as Plutus and Marlowe.
Participating in the PoS protocol requires two steps:
\begin{description}
\item[Using a registered stake address] Users can post certificates to the chain
to register a stake address. This will allow them to delegate funds associated
with that address, and also automatically set up a corresponding \emph{reward
account}, where the system will accumulate rewards for delegating funds from
that stake address.
\item[Delegating from that stake address to a registered \emph{stake pool}] All
blocks in Cardano-Shelley will be produced by a set of stake pools that need
to be registered on the chain, by posting an appropriate certificate.
Individual stakeholders can \emph{delegate} funds from each of their
registered stake addresses to a pool of their choosing. Stake in an address
that delegates to a pool counts to the stake of that pool in the leader
election. The pool will be rewarded for block production, and those rewards
will automatically be distributed to the apropriate reward addresses.
Note that this does not restrict an individual stakeholder wanting to use
their own stake to produce blocks (``self delegation''). Such users should
register a \emph{private stake pool}, and delegate their own funds to that
pool. This uniform architecture, not distinguishing between those stakeholders
that are using their stake directly and those that are delegating, reduces the
overall complexity of the system significantly.
\end{description}
Registration of stake addresses and delegation are optional, but it is the only
way to exercise the stake rights to take part in the PoS protocol and to earn
rewards.
Rewards to pools and their members follow the scheme described
in~\cref{design-of-incentives}. In designing the rewards system, we were careful
to avoid incentivising selfish behaviour, and to encourage cooperative behaviour
instead. The rewards that a pool will get for producing blocks depend on how
much stake they control, and on how well they perform when producing blocks.
Stake pool operators can influence how the rewards for the pool are split
amongst its members, by setting parameters in the stake pool registration
certificate. Wallets will assist users in making rational choices and delegating
to pools that are expected to give the best rewards.
\subsection{Addresses and Credentials}
\label{address-structure}
In Shelley, an address has to provide information on two things: how tokens can
be spent, and how the associated stake is controlled. To separate those two
concerns, we distinguish between \emph{payment addresses} \(\mathcal{A}_p\) and
\emph{stake addresses} \(\mathcal{A}_s\).
Addresses are objects that have a user-facing binary representation (they appear
in the UTxO, and users can inspect them using a wallet or explorer). They
contain \emph{credentials} that govern access rights; using an address (such as
spending from a payment address, or delegating funds associated with a stake
address) requires a witness for the credential (which is specific to the
particular transaction). There are two different kinds of credentials:
\begin{description}
\item[Key Credential] A credential can be constructed from a pair \((sk,
vk)\) of a \emph{signing key} \(sk\) and corresponding \emph{verification key}
\(vk\). The credential is a cryptographic hash \(\hash{vk}\) of the
verification key.
A witness for a key credential consists of the verification key \(vk\), and a
signature of the transaction from the signing key \(sk\).
\item[Script Credential] Tokens and stake can also be controlled by a
\emph{validator script}, which can either succeed or fail to validate on a
given input. In this case, the credential is the hash of the script.
A witness for a script credential is the script itself, as well as input to
the script that makes it validate.
\end{description}
In future releases, we will add multiple languages to Cardano, with Plutus being
the most prominent example. In Shelley, script credentials will only be used for
the purpose of requiring signatures from multiple parties, a process known as
multi signature, or \emph{multi-sig}. For this, Cardano-Shelley will feature a
minimalistic scripting language capable of expressing the requirement of having
a specified subset of a given set of keys provide a signature. Examples include
\emph{M of N} schemes, where a transaction can be authorised if at least \(M\)
distinct keys, from a set of \(N\) keys, sign the transaction.
%
By introducing multi-sig script credentials, in Shelley, it will be possible to
require single or multiple signatures both for the spending of funds and for the
delegation of stake, independently.
For the case of multi-sig scripts, a witness contains the validator script
matching the hash in the script credential, and a set of witnesses for
individual key credentials. The validator script will determine whether those
witnesses are sufficient for the funds to be spent. For details, and an example
of a multi signature scripting language, see~\citep{multi-sig-scripts}.
\begin{figure}[ht]
\includegraphics[width=\linewidth]{addresses.pdf}
\caption{Addresses and Credentials}
\label{fig:addresses}
\end{figure}
\cref{fig:addresses} shows the anatomy of both payment and stake addresses. Let
us first consider a \emph{Stake Address}: it contains a stake credential (which
can be a key credential or script credential). A stake address is used for two
purposes: delegating stake (see \cref{delegation-certificates}), and spending
rewards accumulated in a \emph{reward account} (see \cref{reward-accounts}).
\emph{Payment Addresses} have more structure: first of all, we have the two
cases of Byron and Shelley addresses. The purpose of Byron addresses is
backwards compatibility. Byron addresses have no notion of stake, so it is not
possible to delegate from a Byron address; users will have to transfer funds to
a Shelley address first.
A Shelley address contains a payment credential (again, either a key or script
credential). A transaction that consumes a UTxO entry with a Shelley address
will need a witness for its payment credential in order to be validated. In
addition, a Shelley address also contains a stake address reference. When
calculating the stake distribution (see \cref{delegation-relations} for
details), the system uses this reference to decide where to count the stake
corresponding to the tokens in this address.
There are three options for the stake address reference in a Shelley address: it
can be provided \emph{by value}, i.e., just be the hash of a verification key or
validator script. Shelley addresses that provide their stake address reference
by value are sometimes also called \emph{base addresses}.
There is also a more compact way of representing a stake address reference: since stake
addresses need to be registered on the chain in order to be considered for the
stake distribution (see \cref{stake-address-registration-certificates}), we can
also include them \emph{by pointer}, pointing to the certificate that
registered it. Since the
blockchain orders transactions, this pointer is quite small, containing only
three numbers (slot index, transaction index within the block, and certificate
index within the transaction). Shelley addresses that contain their stake
by pointer are also called \emph{pointer addresses}.
The third possibility is to not have a stake address reference at all. In this case,
the stake corresponding to the tokens in the address is not considered by the
system at all (just as for a Byron address). In particular, it will not be
counted towards the active stake (\cref{overall-stake-distribution}), and so
will not slow down chain growth. Users who do not wish to contribute to the PoS
protocol should use this option. Such addresses are also called \emph{enterprise
addresses}.
\subsubsection{On Pointer Addresses}
\label{pointer-address}
Allowing the stake address reference to be included in a payment address via pointer
allows for shorter addresses, which is a requirement (\cref{short-addresses}).
However, there are also some subtleties to consider.
\paragraph{Invalid Refereces}
First, we need to consider the case that the pointer does not point to an
\emph{active} stake address registration. This covers the case that the key was
unregistered after (or indeed before) the transaction, and also covers pointers
to targets that are plainly invalid. The system will allow transactions to and
from such addresses, but their stake will not be considered for leader election
and rewards.
Note that in particular, when a pointer address becomes invalid because the
stake address it points to is deregistered, registering the same stake address
again does not ``restore'' the stake in the pointer address; the tokens have to
be moved to another address in order to use the stake. This minor limitation
allows the system to not remember unregistered stake addresses.\todo{Maybe add a
diagram here, about the lifetime of pointer addresses.}
So, to exercise the stake rights of a pointer address, the stake address must be
registered in advance of using the pointer address in the output of a
transaction, and the stake address must remain registered while the pointer
address holds funds. This is a difference compared to addresses that contain
their stake address reference by value, where the stake address can be registered
after the value address is used in a transaction.
\paragraph{Pointer Addresses and Rollback}
A special case of an invalid pointer is a rollback: when the block containing a
stake address registration certificate gets rolled back, addresses containing
the stake address by pointer to that certificate will lose their stake rights.
Since the addresses will remain valid for payments, though, the stake rights can
be restored by moving the funds to another address. Wallets can try to avoid
this situation, as described in \cref{basic-delegation}.
\subsubsection{On Enterprise Addresses}
\label{enterprise-address}
Enterprise addresses carry no stake rights whatsoever and thus using
them allows completely opting out of participation in the proof of stake
protocol. Exchanges or other organisations that control large amounts of
ada -- but hold it on behalf of other users -- may wish to follow a
policy of not exercising stake rights. By using enterprise addresses,
exchanges can demonstrate that they follow this policy.
Since enterprise addresses are not associated with any stake address, they
are automatically excluded from the mechanisms that influence the slot
leadership schedule.
Note that using addresses with no stake rights effectively decreases
the total amount of stake, which plays into the hands of the adversary.
But unless we want the exchange to control the stake, it is unavoidable to
ignore it, since there is no way to determine whom the stake "really" belongs
to. Also note that it is generally considered bad practice to leave funds on
exchanges, and in Cardano-Shelley, there will also be a monetary incentive to
withdraw funds from exchanges in order to earn rewards.
\subsubsection{Reward Accounts}
\label{reward-address}
Reward accounts are used to distribute rewards for participating in
the PoS protocol, as described in
\ref{distributing-rewards}. They have a number of interesting
properties:
\begin{itemize}
\item They use account-style accounting, not UTxO-style.
\item They can not receive funds via transactions. Instead, their
balance is only increased when rewards are distributed.
\item A reward account is not related to a value address, but to a stake
address. Thus, spending from a reward account requires a witness for a stake
credential, rather than a payment credential.
\end{itemize}
Rewards can be ``withdrawn'' from a reward account, by using the reward account
as an input to a transaction. Note that we will still require at least one UTxO
style input in this transactions for replay protection, as explained in
\cref{certificate-replay-prevention}. Stake associated with funds in a reward
account will contribute to the stake of the stake address, so there is no
incentive to frequently withdraw rewards.
\subsubsection{On Byron Addresses}
\label{bootstrap-address}
In Byron, all addresses were interpreted as
having stake rights, but those stake rights were always delegated to a fixed set
of keys specified in the genesis block, controlled by the
Cardano Foundation, Emurgo, and IOHK.
Byron addresses continue to exist in Shelley, but their
interpretation is changed subtly and their use is disincentivised.
Their interpretation is changed from having stake rights with
forced delegation, to having no stake rights whatsoever. Their use is
disincentivised, since owners have the option to move their funds into
the new base or pointer addresses that have stake rights, which can be
exercised to receive rewards.
It is worth noting that initially, Byron addresses and enterprise addresses
have essentially identical behaviour. This might change in the future, if new
features are added to enterprise addresses.
\subsubsection{HD Wallet Structure in Shelley}
\label{hd-wallet-structure-in-shelley}
Shelley addresses with a verification key hash as payment credential
support hierarchical deterministic wallets, as per BIP-32~\citep{bip32}.
%
For value addresses with a multi-sig script credential, we can use a slight
generalisation of BIP-45~\citep{bip45}\todo{Lay out the necessary generalisation
of BIP-45}.
In particular, this kind of wallet scheme allows implementations that can
do wallet restoration from seed in time that is logarithmic in
the total number of addresses on the blockchain. For details, see
\cref{wallet-recovery-process}.
\subsubsection{Address Recognition}
\label{address-recognition-1}
Wallets will recognise addresses (other than reward addresses) that belong to
them just as they would without delegation, by looking only at the
payment credential (see \cref{wallet-recovery-process} for how to find
addresses efficiently).
Finding the stake credentials of a wallet (and in particular the corresponding
reward accounts) can be done either by just reading off all the stake credentials
of addresses found via their payment credentials, or by performing a second search,
this time over all the registered stake addresses\footnote{As explained in
\cref{stake-address-registration-certificates}, stake addresses need to be
registered on-chain.}. The former option is quicker and easier to implement.
However, it is conceivable to construct addresses where the payment credential
belongs to one wallet, but the stake credential belongs to another. The stake
credential of such addresses would only be found by the wallet that controls it via
a dedicated search on the registered stake addresses.
Once a wallet recognises an address via its payment credential, it will read its
stake credential, and check whether it is set according
to the current delegation preference of the wallet. If there is a
discrepancy, it will alert the user, and ask them whether they want to
re-delegate according to their current delegation preferences.
This check protects against the malleability attack in
\cref{address-nonmalleability}. It does so not by making it impossible, but
by ensuring that the users are aware of it. This design also covers the case
of users simply changing their delegation choice but subsequently receiving
payments to addresses they handed out previously that use the previous
delegation choice.
\subsection{Certificates and Registrations}
\label{certificates-and-registrations}
\subsubsection{Certificates on the Blockchain}
\label{certificates-on-the-blockchain}
The registering of stake addresses and stake pools, and delegating,
involves posting appropriate signed registration and delegation certificates to
the blockchain as part of the set of certificates included in
transactions. This makes the certificates part of
the blockchain, which means that they are are publicly announced to all
participants.
Certificates will remain valid
until explicitly overwritten or revoked, as an automatic expiry would
likely increase the amount of undelegated, offline stake. The following
certificates can be posted to the blockchain:
\begin{itemize}
\item Stake address registration certificate
\item Stake address de-registration certificate
\item Delegation certificate
\item Stake pool registration certificate
\item Stake pool retirement certificate
\end{itemize}
There is one form of certificate which is not posted to the blockchain
in advance, but is presented when it is used:
\begin{itemize}
\item
Operational key certificate
\end{itemize}
Although this last kind is similar to delegation certificates in that
it uses one key to grant the right to sign blocks to another
key, it is quite different from the other certificates which are used
to define the delegation relation. Operational key certificates are
used by stake pool operators as a safety measure to mitigate key
theft (see \cref{operational-key-certificates}), not to delegate
stake rights between different entities.
Figure~\ref{fig:relationship-keys-certificates} shows the relationships between
the different types of certificates and keys.
%
Dashed arrows represent relationships between the different keys and addresses:
the owner(s) of a stake address delegates their stake rights to the owner of a
stake pool cold key, using a delegation certificate.
%
The owner of a cold and hot key grants the stake rights of their cold key to their
hot key, using an operational key certificate.
%
Incoming solid arrows represent the components of a certificate.
For instance, a delegation certificate contains the stake address of the
delegator, and the (hash of the verifying part of the) stake pool key.
Stake pools use a number of keys: a stake pool is controlled using the
\emph{pool key} pair \((sk_\text{pool}, vk_\text{pool})\). As explained in
\cref{operational-key-certificates}, this should be a \emph{cold} key, kept on a
secure machine, and only used to issue stake pool registration and operational
key certificates.
Producing a valid block will require an operational key certificate, signed by
\(sk_\text{pool}\), and a witness for the block from the operational key
specified in the certificate. Since operational keys use key evolving signatures
(KES), an operational key is also referred to as a KES key.
In addition, the leader election process in Ouroboros Praos requires a
verifiable random function, or VRF key pair \((sk_\text{VRF}, vk_\text{VRF})\),
which is needed to prove that a pool has won its private lottery for a given
slot. The hash of the verification part \hash{vk_\text{VRF}} of this key is
contained in the pool registration certificate.
%
Subsequent sections provide more details.
\begin{figure}[ht]
\centering
\begin{tikzpicture}[ align = center
, node distance = 6em and 10em
, text width = 5em
, font = \footnotesize
, >={Latex[width=0.5em, length=0.5em]}
, every node/.style = { rectangle
, rounded corners
, draw = black
, align = center
, minimum height = 4em }
]
%%
%% Nodes
%%
\tikzset{ key/.style={fill=red!10}
, cert/.style={fill=green!10}
, dummy/.style={draw=none}
}
\node (skeys) [key] {Stake address};
\node (scold) [key, right = of skeys] {Stake pool key (cold)};
\node (shot) [key, right = of scold] {KES key (hot)};
\node (skeyr) [cert, above = of skeys] {Stake address registration};