forked from IntersectMBO/cardano-ledger
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathaddress.tex
219 lines (209 loc) · 8.69 KB
/
address.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
\section{Addresses}
\label{sec:addresses}
Addresses are described in section 4.2 of the delegation design document \cite{delegation_design}.
The types needed for the addresses are defined in Figure~\ref{fig:defs:addresses}.
They all involve a credential, which is either a key or a multi-signature script.
There are four types of UTxO addresses:
\begin{itemize}
\item Base addresses, $\AddrB$, containing the hash of a payment credential and
the hash of a staking credential. Note that the payment credential hash is the
hash of the key (or script) which has contol of the funds at this address,
i.e. is able to witness spending
them. The staking credential controls the delegation
decision for the Ada at this address (i.e. it is used for rewards, staking,
etc.).
The staking credential
must be a (registered) delegation credential (see Section~\ref{sec:delegation-shelley}
for a discussion of the delegation mechanism).
\item Pointer addresses, $\AddrP$, containing the hash of a payment credential
and a pointer to a stake credential registration certificate.
\item Enterprise addresses, $\AddrE$,
containing only the hash of a payment credential (and which have no staking rights).
\item Bootstrap addresses, $\AddrBS$, corresponding to the addresses in
Byron, behaving exactly like enterprise addresses with a key hash
payment credential.
\end{itemize}
\noindent Where a credential is either a key or a multi-signature script. Together, these
four address types make up the $\Addr$ type, which will be used in transaction
outputs in Section~\ref{sec:utxo}. The notations
$\Credential_{pay}$ and $\Credential_{stake}$ do not represent distinct types.
The subscripts are annotations indicating how the credential is being used.
Section 5.5.2 of~\cite{delegation_design} provides the motivation behind enterprise
addresses and explains why one might forgo staking rights.
Bootstrap addresses are needed for the Byron-Shelley transition in order to
accommodate having UTxO entries from the Byron era during the Shelley era.
There are also subtypes of the address types which correspond to the credential
being either a key hash (the $vkey$ subtype) or a script hash (the $script$
subtype). So for example $\Addr_{base}^{script}$ is the type of base addresses
which have a script hash as pay credential. This approach is used to facilitate
expressing the restriction of the domain of certain functions to a specific
credential type.
Note that for security, privacy and usability reasons, the staking (delegating)
credential associated with an address should be different from its payment
credential. Before the stake credential is registered and delegated to an
existing stake pool, the payment credential can be used for transactions, though
it will not receive rewards from staking. Once a stake credential is
registered, the shorter pointer addresses can be generated.
Finally, there is an account style address $\AddrRWD$ which contains the hash of
a staking credential. These account addresses will only be used for receiving
rewards from the proof of stake leader election. Appendix A
of~\cite{delegation_design} explains this design choice. The mechanism for
transferring rewards from these accounts will be explained in
Section~\ref{sec:utxo} and follows the approach outlined in the
document~\cite{chimeric}.
Note that, even though in the Cardano system, most of the
accounting is UTxO-style, the reward addresses are a special case. Their
use is restricted to only special cases (e.g. collecting rewards from them),
outlined in the rules in Sections~\ref{sec:utxo} and Section~\ref{sec:epoch}.
For each staking credential, we use the function $\fun{addr_{rwd}}$ to create
the reward address corresponding to the credential, or to access an existing one
if it already exists.
Note that $\fun{addr_{rwd}}$ uses the global constant $\NetworkId$ to
attach a network ID to the given stake credential.
Base, pointer and enterprise addresses contain a payment credential which is
either a key hash or a script hash. Base addresses contain a staking credential
which is also either a key hash or a script hash.
\begin{figure*}[hbt]
\emph{Abstract types}
%
\begin{equation*}
\begin{array}{r@{~\in~}lr}
\var{slot} & \Slot & \text{absolute slot}\\
\var{ix} & \Ix & \text{index}\\
\var{net} & \Network & \text{either $\mathsf{Testnet}$ or $\mathsf{Mainnet}$}\\
\end{array}
\end{equation*}
%
\emph{Derived types}
%
\begin{equation*}
\begin{array}{r@{\in}l@{\qquad=\qquad}lr}
\var{cred} & \Credential & \KeyHash\uniondistinct\HashScr \\
\var{(s,t,c)}
& \Ptr
& \Slot\times\Ix\times\Ix
& \text{certificate pointer}
\\
\var{addr}
& \AddrB
& \Network\times\Credential_{pay}\times\Credential_{stake}
& \text{base address}
\\
\var{addr}
& \AddrP
& \Network\times\Credential_{pay}\times\Ptr
& \text{pointer address}
\\
\var{addr}
& \AddrE
& \Network\times\Credential_{pay}
& \text{enterprise address}
\\
\var{addr}
& \AddrBS
& \Network\times\KeyHash_{pay}
& \text{bootstrap address}
\\
\var{addr}
& \Addr
& \begin{array}{l@{~\uniondistinct}l}
\AddrB & \AddrP \uniondistinct \AddrE
\\
& \AddrBS
\end{array}
& \text{output address}
\\
\var{acct}
& \AddrRWD
& \Network\times\Credential_{stake}
& \text{reward account}
\\
\end{array}
\end{equation*}
%
\emph{Address subtypes}
%
\begin{equation*}
\begin{array}{r@{~\in~}l@{\qquad=\qquad}lr}
\var{addr^{vkey}_{base}}
& \Addr^{vkey}_{base}
& \KeyHash\restrictdom\Addr_{base}
\\
\var{addr^{script}_{base}}
& \Addr^{vkey}_{base}
& \HashScr\restrictdom\Addr_{base}
\\
\var{addr^{vkey}_{ptr}}
& \Addr^{vkey}_{ptr}
& \KeyHash\restrictdom\Addr_{ptr}
\\
\var{addr^{script}_{ptr}}
& \Addr^{vkey}_{ptr}
& \HashScr\restrictdom\Addr_{ptr}
\\
\var{addr^{vkey}_{enterprise}}
& \Addr^{vkey}_{enterprise}
& \Addr_{enterprise}\cap\KeyHash
\\
\var{addr^{script}_{enterprise}}
& \Addr^{vkey}_{enterprise}
& \Addr_{enterprise}\cap\HashScr
\\[0.5cm]
\var{addr^{vkey}} &
\Addr^{vkey} &
\Addr^{vkey}_{base} \uniondistinct \Addr^{vkey}_{ptr} \uniondistinct \Addr^{vkey}_{enterprise} \uniondistinct \Addr_{bootstrap}\\[0.3cm]
\var{addr^{script}} &
\Addr^{script} &
\Addr^{script}_{base}
\uniondistinct \Addr^{script}_{ptr}
\uniondistinct
\Addr^{script}_{enterprise}
\\[0.5cm]
\var{addr_{rwd}^{vkey}} & \Addr_{rwd}^{vkey} & \Addr_{rwd}\cap\KeyHash \\
\var{addr_{rwd}^{script}} & \Addr_{rwd}^{script} & \Addr_{rwd}\cap\HashScr \\
\end{array}
\end{equation*}
%
\emph{Accessor Functions}
%
\begin{equation*}
\begin{array}{r@{~\in~}lr}
\fun{paymentHK} & \AddrVKey \to \KeyHash_{pay}
& \text{hash of payment key from addr}\\
\fun{validatorHash} & \AddrScr \to \HashScr & \text{hash of validator
script} \\
\fun{stakeCred_{b}} & \AddrB \to
\StakeCredential & \text{stake credential from base
addr}\\
\fun{stakeCred_{r}} & \AddrRWD \to \StakeCredential & \text{stake credential
from reward addr}\\
\fun{addrPtr} & \AddrP \to \Ptr
& \text{pointer from pointer addr}\\
\fun{netId} & \Addr \to \Network
& \text{network Id from addr}\\
\end{array}
\end{equation*}
%
\emph{Constructor Functions}
%
\begin{equation*}
\begin{array}{r@{~\in~}lr}
\fun{addr_{rwd}}
& \Credential_{stake} \to \AddrRWD
& \begin{array}{l}
\text{construct a reward account,} \\
\text{implicitly using $\NetworkId$}
\end{array}
\end{array}
\end{equation*}
%
\emph{Constraints}
%
\begin{equation*}
\var{hk_1} = \var{hk_2} \iff \fun{addr_{rwd}}~\var{hk_1} = \fun{addr_{rwd}}~\var{hk_2}
~~~ \left( \fun{addr_{rwd}} \text{ is injective} \right)
\end{equation*}
\caption{Definitions used in Addresses}
\label{fig:defs:addresses}
\end{figure*}
\clearpage