-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathP2.txt
173 lines (133 loc) · 6.92 KB
/
P2.txt
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
Protocol update
Protocol Version: 2
Builds on Protocol Version: 1
Abstract
This document describes the changes in Concordium protocol version 2
compared to protocol version 1, which is the initial protocol at the
launch of mainnet.
The protocol change adds three new transaction types to the set of
supported transactions. These three transactions are transfer with
memo, encrypted transfer with memo, and transfer with schedule and
memo. These transactions behave akin to the analogously named existing
transactions without a memo, but allow the sender to add a message to
the transfer. This message is recorded on the chain.
Background
Concordium protocol version 1 supports the following 16 account
transaction types `DeployModule`, `InitContract`, `Update`,
`Transfer`, `AddBaker`, `RemoveBaker`, `UpdateBakerStake`,
`UpdateBakerRestakeEarnings`, `UpdateBakerKeys`,
`UpdateCredentialKeys`, `EncryptedAmountTransfer`,
`TransferToEncrypted`, `TransferToPublic`, `TransferWithSchedule`,
`UpdateCredentials`, `RegisterData`. Each transaction has a common
signature and header, and a transaction-type specific payload.
If a transaction payload is not among the above listed recognized
payloads then the transaction can still be included in a block, but
its outcome will be `SerializationFailure`, and it will have no other
effect on the state of the chain.
When transactions are parsed their type is determined by a single-byte
tag value. Each supported transaction type has a protocol-defined tag.
When a valid transaction is included in a block it generates a list of
one or more events. In protocol version 1 there are 21 possible events
that can be generated. For example an event is "Transferred" a given
amount of GTU from address A to address B. These events are part of a
transaction outcome. Outcomes of all transactions in a block are
hashed, and their combined hash is included in a block.
Changes
1. Protocol version 2 will have all protocol 1 transaction types with
the same meaning, and three additional transaction types. These are
- TransferWithMemo
- EncryptedAmountTransferWithMemo
- TransferWithScheduleAndMemo
with tags 22, 23, and 24, respectively. These will have the same
payloads as the corresponding existing transactions, and an additional
memo field. The memo is a byte array with a maximum size of 256.
The protocol does not give any meaning to the memo, it is an
uninterpreted part of the transaction that is recorded by the chain.
2. Protocol 2 will have all protocol 1 events, and additionally a new
event `TransferMemo` that will be generated by the three new
transaction types. The event contains verbatim the memo that was part
of the transaction.
3. The cost of the three new transaction types uses the same formula
as the cost of the corresponding existing transaction types. The
per-transaction-type cost factor is the same. As a consequence the
cost C(tₘ) of a transaction with a memo is
C(tₘ) = C(t) + size + 2
where t is the corresponding existing transaction without a memo and
size is the size in bytes of the memo. The +2 accounts for the
recording of the size of the memo, which uses 2 bytes.
Effects
1. All existing transactions that are valid retain their semantics
exactly; their outcomes are the same, as well as their effects on the
state of the chain.
2. If a transaction would be included in a block, but fail with
`SerializationFailure` rejection reason in protocol version 1 then it
might be valid in protocol version 2 and interpreted as either
`TransferWithMemo`, `EncryptedAmountTransferWithMemo`, or
`TransferWithScheduleAndMemo`. This will only happen if the
transaction payload tag is 22, 23, or 24, which have no assigned
meaning in protocol version 1.
Serialization
The new transaction payload types are serialized as follows.
TransferWithMemo
- tag 22: byte (1 byte)
- receiver address: account address (32 bytes)
- memo: memo (variable length)
- amount: amount (8 bytes)
EncryptedAmountTransferWithMemo
- tag 23: byte (1 byte)
- receiver address: account address (32 bytes)
- memo: memo (variable length)
- remaining amount: encrypted amount (192 bytes)
- amount to transfer: encrypted amount (192 bytes)
- index: encrypted amount index (8 bytes)
- proof: encrypted transfer proof (2192 bytes)
TransferWithScheduleAndMemo
- tag 24: byte (1 byte)
- receiver address: account address (32 bytes)
- memo: memo (variable length)
- schedule length: byte (1 byte)
- schedule: sequence of pairs (timestamp, amount) (variable length)
where `memo` is serialized as
- length: u16 (2 bytes big endian)
- bytes: byte array (variable length)
Genesis data format
The genesis data format at protocol version 2 is the same as at
protocol version 1, except that the version tag is 4 instead of 3. In
particular, the `GDP2Initial` and `GDP2Regenesis` genesis data formats
are the same as `GDP1Initial` and `GDP1Regenesis` respectively.
`GDP2Initial` specifies core genesis parameters and an initial state,
which may be used as an initial genesis block. `GDP2Regenesis`
specifies core genesis parameters, the hashes of the first genesis
block, previous genesis block and terminal block of the preceding
chain, and the state at regenesis. This is used when restarting a chain
as a result of a protocol update.
Protocol update instruction
The protocol update instruction is identified by the SHA256 hash of
this file. The instruction does not need any auxiliary data.
The protocol update starts a new chain with the genesis block
containing genesis data in the `GDP2Regenesis` format. The parameters
are determined as follows:
- The core genesis parameters are unchanged, except that the genesis
time is the timestamp of the last finalized block of the preceding
chain.
- The hash of the first genesis block is either
- the hash of the genesis block of the preceding chain, if it is
a `GDP1Initial` genesis block; or
- the first genesis block recorded in the genesis block of the
preceding chain, if it is a `GDP1Regenesis` genesis block.
- The hash of the previous genesis block is the hash of the genesis
block of the preceding chain.
- The hash of the terminal block is the hash of the last finalized
block of the preceding chain.
- The state is derived from the state at the last finalized block of
the preceding chain as follows:
- The `SeedState` data structure is updated with:
- the `epoch` is reset to 0;
- the `currentLeadershipElectionNonce` is the SHA256 hash of the
concatenation of the string `"Regenesis"` with the previous value
of `updatedNonce`; and
- the `updatedNonce` is the same as
`currentLeadershipElectionNonce`.
- The `Updates` data structure is updated with:
- the current protocol update is unset; and
- the protocol update queue is emptied.