Build error fixes (#1627)

Author: LandauRaz

components/Starknet/modules/architecture-and-concepts/pages/accounts.adoc

@@ -187,7 +187,7 @@ Upon receiving one of these transactions, the sequencer performs the following s
 +
 [NOTE]
 ====
-If you use a `DEPLOY_ACCOUNT` transaction, the fees are paid from the address of the deployed account. If you use the UDC, which requires an `INVOKE` transaction, the fees are paid from the sender's account. For information on the differences between V1 and V3 `INVOKE` transactions, see xref:network-architecture/transactions.adoc#invoke_transaction[`INVOKE` transaction] in _Transaction types_.
+If you use a `DEPLOY_ACCOUNT` transaction, the fees are paid from the address of the deployed account. If you use the UDC, which requires an `INVOKE` transaction, the fees are paid from the sender's account. For information on the differences between V1 and V3 `INVOKE` transactions, see xref:transactions.adoc#transaction_types[`INVOKE` transaction] in _Transaction types_.
 ====
 . Sets the account's nonce as follows:
 ** `1`, when deployed with a `DEPLOY_ACCOUNT` transaction

components/Starknet/modules/architecture-and-concepts/pages/network-architecture/block-structure.adoc

@@ -152,7 +152,7 @@ Where `h` is the xref:../../cryptography.adoc#poseidon-hash[Poseidon hash functi
 [discrete]
 === Receipt hash
 
-The hash of a xref:./transaction-life-cycle.adoc#transaction-receipt[transaction receipt] is defined by:
+The hash of a xref:transactions.adoc#transaction_receipt[transaction receipt] is defined by:
 
 [,,subs="quotes"]
 ----

components/Starknet/modules/architecture-and-concepts/pages/network-architecture/os.adoc

@@ -12,7 +12,7 @@ As an L2 validity rollup, Starknet's state on Ethereum can't be updated without
 
 This is where SNOS comes in: it is a Cairo Zero program that verifies the validity of blocks by getting an initial state stem:[S] and a list of transactions (i.e., block) stem:[B] as input and outputting the state that is the result of applying stem:[B] on stem:[S].
 
-SNOS is the program required for updating Starknet's state on Ethereum (xref:#os-and-core-contract[up to some caveats]). As such, is it also the final arbiter on what does it mean for a transaction to execute correctly. For example, while a malicious sequencer can deviate from xref:architecture-and-concepts:network-architecture/transaction-life-cycle.adoc#transaction_flow[the `INVOKE` transaction's behavior] by skipping the execution of `+__validate__+` before `+__execute__+` in the calling account contract, this specification is https://github.com/starkware-libs/cairo-lang/blob/8e11b8cc65ae1d0959328b1b4a40b92df8b58595/src/starkware/starknet/core/os/execution/execute_transactions.cairo#L390[enforced by SNOS^] and therefore this sequencer will not be able to produce the proof for the block in which this transaction was included. 
+SNOS is the program required for updating Starknet's state on Ethereum (xref:#os-and-core-contract[up to some caveats]). As such, is it also the final arbiter on what does it mean for a transaction to execute correctly. For example, while a malicious sequencer can deviate from xref:architecture-and-concepts:transactions.adoc#transaction_flow[the `INVOKE` transaction's behavior] by skipping the execution of `+__validate__+` before `+__execute__+` in the calling account contract, this specification is https://github.com/starkware-libs/cairo-lang/blob/8e11b8cc65ae1d0959328b1b4a40b92df8b58595/src/starkware/starknet/core/os/execution/execute_transactions.cairo#L390[enforced by SNOS^] and therefore this sequencer will not be able to produce the proof for the block in which this transaction was included. 
 
 == How does SNOS work?
 
@@ -56,7 +56,7 @@ which returns the block hash and number, correctness means consistency with the
 
 Therefore, when running the OS, we already know what is going to happen: the block has already been executed by the sequencer, and so we know exactly what contracts and storage slots will be accessed, what each internal call will return, and so on.
 
-It's worth noting that in the first execution, the sequencer can run in whatever way he chooses. In fact, he doesn't even have to run through the Cairo VM at all, but rather https://github.com/lambdaclass/cairo_native[precompile contracts to machine code and run them natively^]. Moreover, sequencers can also impose restrictions that are not enforced by SNOS. Such discrepancy between the two executions may seem like a bug, but as long as these restrictions only protect the sequencers themselves, rather than the correctness of execution, there is no reason for SNOS to enforce them. A good example for such restriction is the xref:architecture-and-concepts:accounts/account-functions#limitations_of_validation[limits on validation functions] that protect the sequencer from DoS attacks. It is crucial, however, that both executions agree on the execution semantics, since, as mentioned in xref:#introduction[What is SNOS?], SNOS is the final arbiter and if it disagrees on the validity of the block, the sequencer will not be able to produce a proof for that block (and the only way forward would be a reorg on Starknet).
+It's worth noting that in the first execution, the sequencer can run in whatever way he chooses. In fact, he doesn't even have to run through the Cairo VM at all, but rather https://github.com/lambdaclass/cairo_native[precompile contracts to machine code and run them natively^]. Moreover, sequencers can also impose restrictions that are not enforced by SNOS. Such discrepancy between the two executions may seem like a bug, but as long as these restrictions only protect the sequencers themselves, rather than the correctness of execution, there is no reason for SNOS to enforce them. A good example for such restriction is the xref:architecture-and-concepts:accounts#limitations_of_validation[limits on validation functions] that protect the sequencer from DoS attacks. It is crucial, however, that both executions agree on the execution semantics, since, as mentioned in xref:#introduction[What is SNOS?], SNOS is the final arbiter and if it disagrees on the validity of the block, the sequencer will not be able to produce a proof for that block (and the only way forward would be a reorg on Starknet).
 
 [id="os-and-core-contract"]
 == SNOS and the Starknet Core contract

components/Starknet/modules/architecture-and-concepts/pages/network-architecture/starknet-architecture-overview.adoc

@@ -22,7 +22,7 @@ tags it as `ACCEPTED_ON_L2`. The final step involves the prover, which
 executes the operating system on the new block, calculates its proof,
 and submits it to Layer 1 (L1) for verification.
 
-For more information on the transaction flow, see xref:network-architecture/transaction-life-cycle.adoc[].
+For more information on the transaction flow, see xref:transactions.adoc#transaction_lifecycle[Transactions].
 
 image::transaction-flow.png[]
 

components/Starknet/modules/architecture-and-concepts/pages/network-architecture/starknet-state.adoc

@@ -143,7 +143,7 @@ So in order to prevent needing to compile from Sierra to Casm in every block in
 
 For more information, see xref:architecture-and-concepts:smart-contracts/cairo-and-sierra.adoc[Cairo and Sierra].
 
-The party that declares the contract signs the compiled class hash, which they obtain using an SDK, as part of the xref:network-architecture/transactions.adoc#declare_v2[`DECLARE`] transaction. If the transaction is included in a block, then the compiled class hash becomes part of the state commitment.
+The party that declares the contract signs the compiled class hash, which they obtain using an SDK, as part of the xref:transactions.adoc#transaction_types[`DECLARE`] transaction. If the transaction is included in a block, then the compiled class hash becomes part of the state commitment.
 
 In the future, when Sierra-to-Casm compilation becomes part of the Starknet OS, this value might be updated via a proof of the Sierra-to-Casm compiler execution, showing that compiling the same class with a newer compiler version results in some new compiled class hash.
 ====

components/Starknet/modules/architecture-and-concepts/pages/smart-contracts/compiled-class-hash.adoc

@@ -14,7 +14,7 @@ The state commitment uses the Sierra code that results when compiling Cairo clas
 
 In order to avoid recompiling, from Sierra to Casm, each block in which the class is deployed, the state commitment gets the information it needs about the corresponding Casm from the information contained in the compiled class hash.
 
-When declaring a contract, the party administering the contract endorses the compiled class hash, procured using an SDK, as an integral component of the xref:network-architecture/transactions.adoc#declare_v2[`DECLARE`] transaction. Following the inclusion of the transaction in a block, the compiled class hash integrates into the state commitment.
+When declaring a contract, the party administering the contract endorses the compiled class hash, procured using an SDK, as an integral component of the xref:transactions.adoc#transaction_types[`DECLARE`] transaction. Following the inclusion of the transaction in a block, the compiled class hash integrates into the state commitment.
 
 
 == Purpose and Significance
@@ -31,9 +31,9 @@ When a new contract is declared on Starknet, the compiled class hash plays a piv
 
 * Declaration Process: The party declaring the contract computes the compiled class hash using an SDK provided by Starknet.
 
-* DECLARE Transaction: This hash is then included as part of the xref:network-architecture/transactions.adoc#declare_v2[`DECLARE`] transaction is a specific type of transaction in Starknet used to register new contracts.
+* DECLARE Transaction: This hash is then included as part of the xref:transactions.adoc#transaction_types[`DECLARE`] transaction is a specific type of transaction in Starknet used to register new contracts.
 
-* Inclusion in State Commitment: Once the xref:network-architecture/transactions.adoc#declare_v2[`DECLARE`] transaction is included in a block, the compiled class hash becomes part of the state commitment. This inclusion ensures that the network recognizes and stores the unique compiled output of the contract.
+* Inclusion in State Commitment: Once the xref:transactions.adoc#transaction_types[`DECLARE`] transaction is included in a block, the compiled class hash becomes part of the state commitment. This inclusion ensures that the network recognizes and stores the unique compiled output of the contract.
 
 
 

components/Starknet/modules/architecture-and-concepts/pages/smart-contracts/contract-classes.adoc

@@ -34,7 +34,7 @@ Using class functionality:: To use the functionality of a declared class without
 == Additional resources
 
 * xref:architecture-and-concepts:smart-contracts/class-hash.adoc[Class hash]
-* xref:architecture-and-concepts:network-architecture/transactions.adoc#declare-transaction[`DECLARE` transaction]
+* xref:architecture-and-concepts:transactions.adoc#transaction_types[`DECLARE` transaction]
 * xref:architecture-and-concepts:smart-contracts/system-calls-cairo1.adoc#deploy[`deploy` system call]
 * xref:architecture-and-concepts:smart-contracts/system-calls-cairo1.adoc#library_call[`library_call` system call]
 

components/Starknet/modules/architecture-and-concepts/pages/smart-contracts/starknet-events.adoc

@@ -69,7 +69,7 @@ message_received.emit(2, data, p)
 
 ====
 
-The emitted events are part of the transaction receipt. For more information, see xref:architecture-and-concepts:network-architecture/transaction-life-cycle.adoc#transaction-receipt[Transaction receipt].
+The emitted events are part of the transaction receipt. For more information, see xref:architecture-and-concepts:transactions.adoc#transaction_receipt[Transaction receipt].
 
 [id="event_abi"]
 == Event definition in the ABI

components/Starknet/modules/guides/pages/quickstart/devnet.adoc

@@ -46,7 +46,7 @@ Chain ID: SN_SEPOLIA (0x534e5f5345504f4c4941)
 
 [TIP]
 ====
-To learn more about Starknet accounts, check out the xref:architecture-and-concepts:accounts/introduction.adoc[Accounts section].
+To learn more about Starknet accounts, check out the xref:architecture-and-concepts:accounts.adoc[Accounts section].
 ====
 
 To interact with your local Starknet instance, you first need an account. Luckily, the result of initializing a local Starknet instance using Starknet Devnet should also include a list of predeployed accounts that resembles the following:

components/Starknet/modules/guides/pages/quickstart/next-steps.adoc

@@ -6,7 +6,7 @@ Welcome to the fifth and final installment of the "Hello, Starknet!" quickstart
 
 By now you've successfully declared, deployed, and interacted with the `HelloStarknet`, both on Starknet Sepolia and locally (way to go!). This last installment of the series will therefore list the various next steps you can take on your Starknet journey:
 
-* Learn more about Starknet's xref:architecture-and-concepts:accounts/introduction.adoc[architecture], xref:tools:overview.adoc[tooling], or xref:ecosystem:overview.adoc[ecosystem]
+* Learn more about Starknet's xref:architecture-and-concepts:accounts.adoc[architecture], xref:tools:overview.adoc[tooling], or xref:ecosystem:overview.adoc[ecosystem]
 * Watch the latest https://starknet.notion.site/Starknet-Basecamp-Hub-1541b3c1f49f439da872d3d71647d834[Starknet Basecamp^], or join an upcoming one
 * Complete the https://starklings.app/[Starklings^] and https://speedrunstark.com/[Speedrun Stark^] coding challenges
 * Apply for a https://www.starknet.io/grants/[seed or growth grant^]