add further reading sections

Author: jarrodwatts

docs/cdk/concepts/admin-upgradeability.md

@@ -6,3 +6,12 @@ CDK chains share the following upgradeability controls:
 
 1. The [security council](https://docs.polygon.technology/zkEVM/architecture/protocol/security-council/) ([contract address](https://etherscan.io/address/0x37c58Dfa7BF0A165C5AAEdDf3e2EdB475ac6Dcb6)) that can be used to trigger the [emergency state](https://docs.polygon.technology/zkEVM/architecture/protocol/malfunction-resistance/emergency-state/) which can pause bridge functionality, prevent smart contract upgrades, or stop the [sequencer](./architecture.md#sequencer) from [sequencing batches](./transaction-lifecycle.md#sequenced).
 2. The [admin role](https://docs.polygon.technology/zkEVM/architecture/protocol/admin-role/) ([contract address](https://etherscan.io/address/0x242daE44F5d8fb54B198D03a94dA45B5a4413e21)) that can perform upgrades to patch bug fixes or add new features to the system by upgrading smart contracts with a 10-day waiting period (unless [emergency state](https://docs.polygon.technology/zkEVM/architecture/protocol/malfunction-resistance/emergency-state/) is active).
+
+## Further Reading
+
+- [zkEVM protocol upgradability](https://docs.polygon.technology/zkEVM/architecture/protocol/upgradability/)
+- [zkEVM admin role and governance](https://docs.polygon.technology/zkEVM/architecture/protocol/admin-role/)
+- [zkEVM upgrade process](https://docs.polygon.technology/zkEVM/architecture/protocol/upgrade-process/)
+- [zkEVM security council](https://docs.polygon.technology/zkEVM/architecture/protocol/security-council/)
+- [zkEVM emergency state](https://docs.polygon.technology/zkEVM/architecture/protocol/malfunction-resistance/emergency-state/)
+- [L2Beat - Polygon zkEVM](https://l2beat.com/scaling/projects/polygonzkevm?selectedChart=activity)

docs/cdk/concepts/architecture.md

@@ -36,3 +36,7 @@ Deployed on the L1 (Ethereum), multiple smart contracts work together to finaliz
 The aggregator is responsible for periodically reading batches of transactions from the L2 that have not been verified yet, and generating ZK-proofs for them to prove their validity.
 
 To do this, the aggregator sends the batches of transactions to a **prover**. The prover generates ZK proofs and sends them back to the aggregator, which then posts the proofs back to the L1 smart contract.
+
+## Further Reading
+
+- [zkEVM architecture overview](https://docs.polygon.technology/zkEVM/architecture/high-level/overview/)

docs/cdk/concepts/blocks.md

@@ -46,3 +46,7 @@ If the L2 is a [rollup](./layer2s.md) (meaning it uses Ethereum for it’s [
 By inspecting the `Sequence Tx Hash` transaction, we can see the `sequenceBatches` function is called with the array of batches as an argument. One of these batches is the batch we have been following, `2041736`, which contains our original example transaction:
 
 ![Last Batch Sequenced](../../img/cdk/last-batch-sequenced.png)
+
+## Further Reading
+
+- [Blocks in the zkEVM Etrog Upgrade](https://docs.polygon.technology/zkEVM/architecture/protocol/etrog-upgrade/?h=blocks#etrog-blocks)

docs/cdk/concepts/bridging.md

@@ -15,3 +15,7 @@ By default, chains launched using the CDK are opt-in to the AggLayer, enabling c
 This allows developers to build unique cross-chain experiences by integrating a `bridgeAndCall` function into their smart contracts, enabling users to call smart contract functions on other L2 chains without requiring users to bridge or hold tokens on the target chain.
 
 Learn more on the [zkEVM unified bridge documentation](https://docs.polygon.technology/zkEVM/architecture/protocol/unified-LxLy/ulxly-rollupmanager/).
+
+## Further Reading
+
+- [Unified Bridge Overview](https://docs.polygon.technology/zkEVM/architecture/protocol/unified-LxLy/lxly-bridge/)

docs/cdk/concepts/gas-fees.md

@@ -5,3 +5,7 @@ CDK chains have full control over how gas fees are set for users, including what
 Gas fees can also be omitted entirely, allowing users to interact with the chain without needing to pay gas fees for transactions and have the fees covered by the chain operator.
 
 By default, gas fees on the L2 are determined by a combination of several factors, including the current gas price on Ethereum, the complexity of the submitted transaction, and the current demand on the L2 network itself.
+
+## Further Reading
+
+- [zkEVM gas fees documentation](https://docs.polygon.technology/zkEVM/architecture/effective-gas/)

docs/cdk/concepts/layer2s.md

@@ -17,3 +17,8 @@ L2s come in different shapes and sizes in terms of their relationship with Ether
 For example, some L2s such as the Polygon zkEVM send all transaction data to Ethereum, whereas other L2s only send information about the state differences, or choose to not send transaction data to Ethereum at all; instead relying on different data availability mechanisms.
 
 As storing information on Ethereum is expensive, building an L2 chain requires a balance between security, decentralization and scalability. The CDK provides developers with the tools to make these trade-offs and build a chain that meets their specific needs depending on their use case.
+
+## Further Reading
+
+- [Ethereum documentation: layer 2s](https://ethereum.org/en/layer-2/)
+- [Ethereum documentation: scaling](https://ethereum.org/en/developers/docs/scaling/)

docs/cdk/concepts/rollup-vs-validium.md

@@ -54,3 +54,8 @@ Below is a breakdown of the technical differences between a zkEVM rollup and val
 ## Default Configuration
 
 By default, chains built with the CDK are set up as a validium. For most use cases, this is the more suitable option as it offers lower gas fees and higher throughput, while still maintaining strong security guarantees provided by the use of validity proofs.
+
+## Further Reading
+
+- [Ethereum documentation: rollups](https://ethereum.org/en/developers/docs/scaling/#rollups)
+- [Ethereum documentation: validiums](https://ethereum.org/en/developers/docs/scaling/validium/)

docs/cdk/concepts/transaction-finality.md

@@ -9,3 +9,8 @@ Through the [transaction lifecycle](./transaction-lifecycle.md), transactions pr
 3. **Consolidated**: The transaction has been [aggregated](./transaction-lifecycle.md#aggregated), meaning a ZK-proof has been generated, posted, and verified on Ethereum to prove the validity of the transaction. The transaction is now considered final at the L1 level, enabling the user to withdraw their funds from the L2 chain back to Ethereum.
 
 ![Transaction Finality](../../img/cdk/transaction-finality.png)
+
+## Further Reading
+
+- [zkEVM state management](https://docs.polygon.technology/zkEVM/architecture/protocol/state-management/)
+- [zkEVM transaction lifecycle](https://docs.polygon.technology/zkEVM/architecture/protocol/transaction-life-cycle/submit-transaction/)

docs/cdk/concepts/transaction-lifecycle.md

@@ -43,3 +43,7 @@ Depending on the data availability design choices of the L2, if the L2 is a [rol
 The final step of the transaction lifecycle is to generate a ZK-proof that proves the batch of transactions is valid. Batches of transactions are read by the [aggregator](./architecture.md#aggregator) which utilizes a [prover](./architecture.md#prover) to generate a ZK-proof that is posted back to Ethereum.
 
 ![Aggregator posting ZK-proof](../../img/cdk/aggregate-batches.png)
+
+## Further Reading
+
+- [zkEVM transaction lifecycle documentation](https://docs.polygon.technology/zkEVM/architecture/protocol/transaction-life-cycle/submit-transaction/)

docs/cdk/concepts/zk-vs-optimistic.md

@@ -34,5 +34,5 @@ ZK rollups have several advantages over optimistic rollups; users can withdraw t
 
 You can learn more about the differences between ZK and optimistic rollups on the official Ethereum documentation:
 
-- [ZK Rollups](https://ethereum.org/en/developers/docs/scaling/zk-rollups/)
-- [Optimistic Rollups](https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/)
+- [Ethereum documentation: ZK Rollups](https://ethereum.org/en/developers/docs/scaling/zk-rollups/)
+- [Ethereum documentation: Optimistic Rollups](https://ethereum.org/en/developers/docs/scaling/optimistic-rollups/)