@@ -14,24 +14,191 @@ pub fn constraint_constants() -> &'static ConstraintConstants {
1414    NetworkConfig :: global ( ) . constraint_constants 
1515} 
1616
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. 
1721#[ derive( Clone ,  Debug ) ]  
1822pub  struct  ForkConstants  { 
23+     /// Hash of the blockchain state at the fork point 
1924     pub  state_hash :  Fp , 
25+ 
26+     /// Blockchain length (number of blocks) at the fork point 
2027     pub  blockchain_length :  u32 , 
28+ 
29+     /// Global slot number since genesis at the fork point 
2130     pub  global_slot_since_genesis :  u32 , 
2231} 
2332
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> 
2491#[ derive( Clone ,  Debug ) ]  
2592pub  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) 
26100     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 
27110     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 
28120     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 
29130     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 
30140     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 
31150     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 
32160     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 
33183     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 
34193     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 
35202     pub  fork :  Option < ForkConstants > , 
36203} 
37204#[ derive( Clone ,  Debug ,  BinProtWrite ) ]  
0 commit comments