@@ -14,24 +14,191 @@ pub fn constraint_constants() -> &'static ConstraintConstants {
14
14
NetworkConfig :: global ( ) . constraint_constants
15
15
}
16
16
17
+ /// Constants that define fork-specific blockchain state.
18
+ ///
19
+ /// Fork constants specify the blockchain state at which a protocol upgrade or fork occurred.
20
+ /// These are used to handle protocol changes and ensure compatibility across network upgrades.
17
21
#[ derive( Clone , Debug ) ]
18
22
pub struct ForkConstants {
23
+ /// Hash of the blockchain state at the fork point
19
24
pub state_hash : Fp ,
25
+
26
+ /// Blockchain length (number of blocks) at the fork point
20
27
pub blockchain_length : u32 ,
28
+
29
+ /// Global slot number since genesis at the fork point
21
30
pub global_slot_since_genesis : u32 ,
22
31
}
23
32
33
+ /// Protocol constraint constants that define core blockchain behavior.
34
+ ///
35
+ /// These constants configure fundamental aspects of the Mina protocol including consensus,
36
+ /// transaction processing, economic parameters, and ledger structure. They are compile-time
37
+ /// parameters that must be consistent across all nodes in a network.
38
+ ///
39
+ /// ## Consensus and Timing Parameters
40
+ ///
41
+ /// The consensus mechanism relies on slot-based timing where blocks are produced in discrete
42
+ /// time slots. The timing hierarchy is:
43
+ /// - **Slots**: Basic time units for block production
44
+ /// - **Sub-windows**: Groups of slots within an epoch
45
+ /// - **Windows**: Collections of sub-windows that define epoch structure
46
+ /// - **Epochs**: Complete consensus periods
47
+ ///
48
+ /// ## Economic Parameters
49
+ ///
50
+ /// The protocol defines economic incentives through fees and rewards:
51
+ /// - **Coinbase rewards**: Paid to block producers for successful blocks
52
+ /// - **Account creation fees**: Required to create new accounts on the ledger
53
+ /// - **Supercharged rewards**: Multiplier for enhanced block producer rewards
54
+ ///
55
+ /// ## Ledger and Transaction Structure
56
+ ///
57
+ /// The ledger uses a Merkle tree structure for efficient verification:
58
+ /// - **Ledger depth**: Determines the maximum number of accounts (2^depth)
59
+ /// - **Transaction capacity**: Limits transactions per block for performance
60
+ /// - **Pending coinbase**: Manages delayed coinbase payouts
61
+ ///
62
+ /// ## Usage Example
63
+ ///
64
+ /// ```rust
65
+ /// use openmina_core::constants::constraint_constants;
66
+ ///
67
+ /// // Access global constraint constants
68
+ /// let constants = constraint_constants();
69
+ ///
70
+ /// // Calculate slots per window
71
+ /// let slots_per_window = constants.sub_windows_per_window;
72
+ /// println!("Sub-windows per window: {}", slots_per_window);
73
+ ///
74
+ /// // Get block timing
75
+ /// let block_time_ms = constants.block_window_duration_ms;
76
+ /// println!("Block time: {}ms", block_time_ms);
77
+ ///
78
+ /// // Check economic parameters
79
+ /// let coinbase_reward = constants.coinbase_amount;
80
+ /// let creation_fee = constants.account_creation_fee;
81
+ /// println!("Coinbase: {} nanomina, Account fee: {} nanomina",
82
+ /// coinbase_reward, creation_fee);
83
+ /// ```
84
+ ///
85
+ /// ## Network Differences
86
+ ///
87
+ /// While most constraint constants are identical across networks, some parameters
88
+ /// may differ between mainnet and testnets for development purposes.
89
+ ///
90
+ /// Related OCaml implementation: <https://github.com/MinaProtocol/mina/tree/compatible/src/config>
24
91
#[ derive( Clone , Debug ) ]
25
92
pub struct ConstraintConstants {
93
+ /// Number of sub-windows that make up a complete window.
94
+ ///
95
+ /// Used in the consensus mechanism to structure epoch timing. Combined with
96
+ /// `slots_per_sub_window` from protocol constants, this determines the total
97
+ /// slots per window: `slots_per_window = slots_per_sub_window × sub_windows_per_window`.
98
+ ///
99
+ /// **Value**: 11 (both mainnet and devnet)
26
100
pub sub_windows_per_window : u64 ,
101
+
102
+ /// Depth of the account ledger Merkle tree.
103
+ ///
104
+ /// This determines the maximum number of accounts that can be stored in the ledger:
105
+ /// `max_accounts = 2^ledger_depth`. The depth affects proof sizes and verification time.
106
+ /// A larger depth allows more accounts but increases computational overhead.
107
+ ///
108
+ /// **Value**: 35 (supports ~34 billion accounts)
109
+ /// **Usage**: Account addressing, sparse ledger proofs, zkSNARK constraints
27
110
pub ledger_depth : u64 ,
111
+
112
+ /// Number of blocks to delay before SNARK work becomes available.
113
+ ///
114
+ /// This creates a buffer period between when a block is produced and when
115
+ /// the associated SNARK work can be included in subsequent blocks. This delay
116
+ /// helps ensure fair distribution of SNARK work opportunities.
117
+ ///
118
+ /// **Value**: 2 blocks
119
+ /// **Usage**: SNARK work scheduling, proof marketplace timing
28
120
pub work_delay : u64 ,
121
+
122
+ /// Duration of each block production slot in milliseconds.
123
+ ///
124
+ /// This is the fundamental time unit for the consensus protocol. Block producers
125
+ /// attempt to create blocks during their assigned slots. The duration affects
126
+ /// network synchronization requirements and transaction confirmation times.
127
+ ///
128
+ /// **Value**: 180,000ms (3 minutes)
129
+ /// **Usage**: Consensus timing, slot calculations, network synchronization
29
130
pub block_window_duration_ms : u64 ,
131
+
132
+ /// Log₂ of the maximum number of transactions per block.
133
+ ///
134
+ /// The actual transaction capacity is `2^transaction_capacity_log_2`. This logarithmic
135
+ /// representation is used because the value directly affects zkSNARK circuit constraints.
136
+ /// Higher capacity allows more transactions but increases block processing time.
137
+ ///
138
+ /// **Value**: 7 (supports 2^7 = 128 transactions per block)
139
+ /// **Usage**: Transaction pool management, block construction, circuit constraints
30
140
pub transaction_capacity_log_2 : u64 ,
141
+
142
+ /// Depth of the pending coinbase Merkle tree.
143
+ ///
144
+ /// Coinbase rewards are not immediately available and are stored in a pending
145
+ /// coinbase tree. This depth determines how many pending coinbase entries can
146
+ /// be tracked: `max_pending = 2^pending_coinbase_depth`.
147
+ ///
148
+ /// **Value**: 5 (supports 2^5 = 32 pending coinbase entries)
149
+ /// **Usage**: Coinbase reward management, staged ledger operations
31
150
pub pending_coinbase_depth : usize ,
151
+
152
+ /// Block reward amount in nanomina (10⁻⁹ MINA).
153
+ ///
154
+ /// This is the base reward paid to block producers for successfully creating a block.
155
+ /// The amount is specified in nanomina, where 1 MINA = 10⁹ nanomina. Block producers
156
+ /// may receive additional rewards through the supercharged coinbase mechanism.
157
+ ///
158
+ /// **Value**: 720,000,000,000 nanomina (720 MINA)
159
+ /// **Usage**: Block producer rewards, economic incentives, reward calculations
32
160
pub coinbase_amount : u64 ,
161
+
162
+ /// Multiplier for supercharged coinbase rewards.
163
+ ///
164
+ /// Supercharged rewards were designed to provide double block rewards (factor of 2)
165
+ /// to block producers staking with unlocked tokens during the early mainnet period
166
+ /// following the 2021 launch. This mechanism incentivized participation and orderly
167
+ /// markets after mainnet launch.
168
+ ///
169
+ /// **Historical values**:
170
+ /// - Original mainnet: 2 (double rewards for unlocked tokens)
171
+ /// - Berkeley hardfork (June 2024): 1 (supercharged rewards removed via MIP1)
172
+ ///
173
+ /// The removal was decided by community vote on January 1, 2023, as proposed by
174
+ /// community member Gareth Davies. This change ensures uniform rewards for all
175
+ /// tokens and reduces inflation, promoting a sustainable economic model.
176
+ ///
177
+ /// **References**:
178
+ /// - Berkeley Upgrade: <https://minaprotocol.com/blog/minas-berkeley-upgrade-what-to-expect>
179
+ /// - Supercharged Rewards Removal: <https://minaprotocol.com/blog/update-on-minas-supercharged-rewards-schedule>
180
+ /// - Original Proposal: <https://github.com/MinaProtocol/mina/issues/5753>
181
+ ///
182
+ /// **Usage**: Enhanced reward calculations, incentive mechanisms
33
183
pub supercharged_coinbase_factor : u64 ,
184
+
185
+ /// Fee required to create a new account in nanomina.
186
+ ///
187
+ /// When a transaction creates a new account that doesn't exist on the ledger,
188
+ /// this fee is charged in addition to the transaction fee. This prevents
189
+ /// spam account creation and manages ledger growth.
190
+ ///
191
+ /// **Value**: 1,000,000,000 nanomina (1 MINA)
192
+ /// **Usage**: Account creation, transaction validation, fee calculations
34
193
pub account_creation_fee : u64 ,
194
+
195
+ /// Optional fork constants defining a protocol upgrade point.
196
+ ///
197
+ /// When present, these constants specify the blockchain state at which a protocol
198
+ /// fork or upgrade occurred. This allows the protocol to handle transitions between
199
+ /// different versions while maintaining consensus.
200
+ ///
201
+ /// **Usage**: Protocol upgrades, compatibility handling, genesis configuration
35
202
pub fork : Option < ForkConstants > ,
36
203
}
37
204
#[ derive( Clone , Debug , BinProtWrite ) ]
0 commit comments