Update book and crate specs

Author: Avaneesh-axiom

book/src/custom-extensions/algebra.md

@@ -46,13 +46,10 @@ moduli_init! {
 
 This step enumerates the declared moduli (e.g., `0` for the first one, `1` for the second one) and sets up internal linkage so the compiler can generate the appropriate RISC-V instructions associated with each modulus.
 
-3. **Setup**: At runtime, before performing arithmetic, a setup instruction must be sent to ensure security and correctness. For the \\(i\\)-th modulus, you call `setup_<i>()` (e.g., `setup_0()` or `setup_1()`). Alternatively, `setup_all_moduli()` can be used to handle all declared moduli.
-
 **Summary**:
 
 - `moduli_declare!`: Declares modular arithmetic structures and can be done multiple times.
 - `init!`: Called once in the final binary to assign and lock in the moduli.
-- `setup_<i>()`/`setup_all_moduli()`: Ensures at runtime that the correct modulus is in use, providing a security check and finalizing the environment for safe arithmetic operations.
 
 ## Complex field extension
 
@@ -83,8 +80,6 @@ complex_init! {
 */
 ```
 
-3. **Setup**: Similar to moduli, call `setup_complex_<i>()` or `setup_all_complex_extensions()` at runtime to secure the environment.
-
 ### Config parameters
 
 For the guest program to build successfully, all used moduli must be declared in the `.toml` config file in the following format:

book/src/custom-extensions/ecc.md

@@ -54,13 +54,10 @@ sw_init! {
 */
 ```
 
-3. **Setup**: Similar to the moduli and complex extensions, runtime setup instructions ensure that the correct curve parameters are being used, guaranteeing secure operation.
-
 **Summary**:
 
 - `sw_declare!`: Declares elliptic curve structures.
 - `init!`: Initializes them once, linking them to the underlying moduli.
-- `setup_sw_<i>()`/`setup_all_curves()`: Secures runtime correctness.
 
 To use elliptic curve operations on a struct defined with `sw_declare!`, it is expected that the struct for the curve's coordinate field was defined using `moduli_declare!`. In particular, the coordinate field needs to be initialized and set up as described in the [algebra extension](./algebra.md) chapter.
 

book/src/custom-extensions/pairing.md

@@ -36,14 +36,6 @@ Additionally, we'll need to initialize our moduli and `Fp2` struct via the follo
 {{ #include ../../../examples/pairing/src/main.rs:init }}
 ```
 
-And we'll run the required setup functions at the top of the guest program's `main()` function:
-
-```rust,no_run,noplayground
-{{ #include ../../../examples/pairing/src/main.rs:setup }}
-```
-
-There are two moduli defined internally in the `Bls12_381` feature. The `moduli_init!` macro thus requires both of them to be initialized. However, we do not need the scalar field of BLS12-381 (which is at index 1), and thus we only initialize the modulus from index 0, thus we only use `setup_0()` (as opposed to `setup_all_moduli()`, which will save us some columns when generating the trace).
-
 ## Input values
 
 The inputs to the pairing check are `AffinePoint`s in \\(\mathbb{F}\_p\\) and \\(\mathbb{F}\_{p^2}\\). They can be constructed via the `AffinePoint::new` function, with the inner `Fp` and `Fp2` values constructed via various `from_...` functions.

docs/specs/RISCV.md

@@ -132,7 +132,9 @@ generates classes `Bls12381` and `Bn254` that represent the elements of the corr
 
 ### Field Arithmetic
 
-For each created modular class, one must call a corresponding `setup_*` function once at the beginning of the program. For example, for the structs above this would be `setup_0()` and `setup_1()`. This function generates the `setup` intrinsics which are distinguished by the `rs2` operand that specifies the chip this instruction is passed to..
+For each created modular class, one must call a corresponding `setup_*` function before using the intrinsics.
+For example, for the structs above this would be `setup_0()` and `setup_1()`. This function generates the `setup` intrinsics which are distinguished by the `rs2` operand that specifies the chip this instruction is passed to..
+For convenience, each modulus's `setup_*` function is automatically called on the first use of any of its intrinsics.
 
 We use `config.mod_idx(N)` to denote the index of `N` in this list. In the list below, `idx` denotes `config.mod_idx(N)`.
 

extensions/algebra/complex-macros/README.md

@@ -27,8 +27,6 @@ openvm_algebra_complex_macros::complex_init! {
 */
 
 pub fn main() {
-    setup_all_moduli();
-    setup_all_complex_extensions();
     // ...
 }
 ```
@@ -79,13 +77,9 @@ mod openvm_intrinsics_ffi_complex {
 pub fn setup_complex_0() {
     // send the setup instructions
 }
-pub fn setup_all_complex_extensions() {
-    setup_complex_0();
-    // call all other setup_complex_* for all the items in the moduli_init! macro
-}
 ```
 
-3. Obviously, `mod_idx` in the `complex_init!` must match the position of the corresponding modulus in the `moduli_init!` macro. The order of the items in `complex_init!` affects what `setup_complex_*` function will correspond to what complex class. Also, it **must match** the order of the moduli in the chip configuration -- more specifically, in the modular extension parameters (the order of numbers in `Fp2Extension::supported_modulus`, which is usually defined with the whole `app_vm_config` in the `openvm.toml` file). However, it again imposes the restriction that we only can invoke `complex_init!` once. Again analogous to the moduli setups, we must call `setup_complex_*` for each used complex extension before doing anything with entities of that class (or one can call `setup_all_complex_extensions` to setup all of them, if all are used).
+3. Obviously, `mod_idx` in the `complex_init!` must match the position of the corresponding modulus in the `moduli_init!` macro. The order of the items in `complex_init!` affects what `setup_complex_*` function will correspond to what complex class. Also, it **must match** the order of the moduli in the chip configuration -- more specifically, in the modular extension parameters (the order of numbers in `Fp2Extension::supported_modulus`, which is usually defined with the whole `app_vm_config` in the `openvm.toml` file). However, it again imposes the restriction that we only can invoke `complex_init!` once. Again analogous to the moduli setups, `setup_complex_*` is automatically called on each complex extension on first use of its intrinsics.
 
 4. Note that, due to the nature of function names, the name of the struct used in `complex_init!` must be the same as in `complex_declare!`. To illustrate, the following code will **fail** to compile:
 

extensions/algebra/moduli-macros/README.md

@@ -145,15 +145,9 @@ pub fn setup_2() {
         // send the setup instruction designed for the chip number 2
     }
 }
-pub fn setup_all_moduli() {
-    setup_0();
-    setup_1();
-    setup_2();
-    // setup functions for all the other moduli provided in the `moduli_init!` function
-}
 ```
 
-The setup operation (e.g., `setup_2`) consists of reading the value `OPENVM_SERIALIZED_MODULUS_2` from memory and constraining that the read value is equal to the modulus the chip has been configured with. For each used modulus, its corresponding setup instruction **must** be called before all other operations -- this currently must be checked by inspecting the program code; it is not enforced by the virtual machine.
+The setup operation (e.g., `setup_2`) consists of reading the value `OPENVM_SERIALIZED_MODULUS_2` from memory and constraining that the read value is equal to the modulus the chip has been configured with. For each used modulus, its corresponding setup instruction is automatically called on first use of any of its intrinsics.
 
 5. It follows from the above that the `moduli_declare!` invocations may be in multiple places in various compilation units, but all the `declare!`d moduli must be specified at least once in `moduli_init!` so that there will be no linker errors due to missing function implementations. Correspondingly, the `moduli_init!` macro should only be called once in the entire program (in the guest crate as the topmost compilation unit). Finally, the order of the moduli in `moduli_init!` has nothing to do with the `moduli_declare!` invocations, but it **must match** the order of the moduli in the chip configuration -- more specifically, in the modular extension parameters (the order of numbers in `ModularExtension::supported_modulus`, which is usually defined with the whole `app_vm_config` in the `openvm.toml` file).
 

extensions/ecc/sw-macros/README.md

@@ -33,8 +33,6 @@ openvm_ecc_guest::sw_macros::sw_init! {
 */
 
 pub fn main() {
-    setup_all_moduli();
-    setup_all_curves();
     // ...
 }
 ```
@@ -90,13 +88,9 @@ pub fn setup_sw_Secp256k1Point() {
         // ...
     }
 }
-pub fn setup_all_curves() {
-    setup_sw_Secp256k1Point();
-    // other setups
-}
 ```
 
-3. Again, the `setup` function for every used curve must be called before any other instructions for that curve. If all curves are used, one can call `setup_all_curves()` to setup all of them.
+3. Again, the `setup` function for every curve is automatically called on first use of any of the curve's intrinsics.
 
 4. The order of the items in `sw_init!` **must match** the order of the moduli in the chip configuration -- more specifically, in the modular extension parameters (the order of `CurveConfig`s in `WeierstrassExtension::supported_curves`, which is usually defined with the whole `app_vm_config` in the `openvm.toml` file).