chore: add zk-stack/concepts pages

content/10.zk-stack/00.index.md

@@ -1,5 +1,40 @@
 ---
 title: Overview
+description: This section provides an overview of the ZK Stack and zkEVM, detailing their roles in launching secure zero-knowledge rollups and forming the hyperchain network.
 ---
 
-Welcome to zk-stack.
+
+## Introduction
+
+ZK Stack is designed to power the internet of value by providing the necessary security through blockchain technology.
+It enables the launch of zero-knowledge rollups, offering an enhanced level of blockchain security.
+
+## Zero-Knowledge Rollups
+
+Zero-knowledge rollups, or ZK Rollups, leverage advanced cryptographic techniques known as zero-knowledge proofs.
+These proofs ensure that each transaction within the rollup is executed correctly without revealing any transaction details.
+ZK Rollups aggregate (or roll up) transaction data and submit it to a primary chain, such as Ethereum, for final validation.
+
+## zkEVM: Enhancing Ethereum Compatibility
+
+At the core of the ZK Stack is the zkEVM, which is designed to execute transactions while maintaining full compatibility with Ethereum.
+This compatibility allows seamless integration and interaction with the broader Ethereum ecosystem.
+
+## Verification by External Validators
+
+One of the key advantages of ZK Rollups is their verifiability by external validators.
+Unlike traditional blockchains that require running a full node to verify transactions,
+ZK Rollups allow their state to be validated externally through the proof provided.
+This makes it simpler and more efficient to ensure the integrity of the rollup.
+
+## Hyperchain: A Network of Rollups
+
+ZK Rollups can also be validated by other rollups, facilitating the creation of a trustless network of rollups known as the hyperchain.
+This interconnected network enhances the scalability and interoperability of blockchain systems.
+
+## Technical Specifications
+
+The document will delve deeper into the zkEVM, providing a detailed specification of its components
+including the prover, compiler, and the virtual machine itself.
+Additionally, it will outline the foundational elements of the hyperchain ecosystem,
+highlighting how these innovations contribute to the scalability and security of blockchain technology.

content/10.zk-stack/05.concepts/00.transaction-lifecycle.md

@@ -0,0 +1,161 @@
+---
+title: Transaction Lifecycle
+description: An in-depth guide on the transaction lifecycle within the ZK Stack, explaining the roles of the sequencer and prover, and detailing the transaction statuses and types in zkSync Era.
+---
+
+The ZK Stack facilitates the launch of rollups, which require certain operators like the sequencer and the prover.
+These operators are responsible for creating blocks and proofs, and submitting them to the L1 contract.
+
+Transactions are cryptographically signed instructions from accounts that aim to update the state of the Ethereum network.
+The simplest transaction involves transferring ETH from one account to another.
+:external-link{text="Learn more about Ethereum transactions" href="https://ethereum.org/en/developers/docs/transactions/" }.
+
+---
+## Workflow of Transactions
+
+Users submit their transactions to the sequencer, whose role is to collect and execute these transactions using the zkEVM.
+The sequencer also provides a soft confirmation to users about the execution of their transactions.
+Users have the option to force the inclusion of their transactions by submitting them through L1.
+After execution, the sequencer forwards the block to the prover, who then creates a cryptographic proof of the block's execution.
+This proof, along with the necessary data, is submitted to the L1 contract.
+An L1 smart contract verifies the validity of the proof and the completeness of the data submission, thereby updating the rollup's state on the contract.
+
+![Components](/images/zk-stack/l2-components.png)
+
+The zkEVM plays a crucial role similar to, yet distinct from, the traditional EVM in Ethereum.
+Transactions can also be initiated via L1, which facilitates L1<>L2 communication, providing censorship resistance and enabling trustless bridges to L1.
+
+The sequencer collects transactions into blocks and, to enhance user experience, ensures quick soft confirmations through small block sizes.
+Unlike Ethereum, [zkEVM distinguishes between blocks and batches](./blocks.md#batch-vs-block-vs-transaction),
+where batches—collections of blocks—are processed by the prover.
+
+Before submitting a proof, the data is sent to L1.
+The method optimizes data submission by detailing only the changes in blockchain state, termed 'state diff.'
+This approach makes transactions affecting the same storage slots more cost-effective.
+
+At the final stage, proofs are generated and sent to L1 using our Boojum proof system,
+which operates efficiently on 16GB of GPU RAM, allowing for decentralization of proof generation.
+
+---
+## Transaction data
+
+Transactions in zkSync Era are [comparable to those on Ethereum](https://ethereum.org/en/developers/docs/transactions/),
+allowing the use of the same wallets.
+Minor differences exist, particularly regarding fee settings.
+For details on fees, refer to the [fee model documentation](/zk-stack/concepts/fee-mechanism).
+
+Returned values from any RPC call outputting transaction details include:
+
+- `is_l1_originated`: `bool`
+- `status`: `TransactionStatus`, one of `Pending`, `Included`, `Verified`, or `Failed`. See [Transaction statuses section](#transaction-statuses) below.
+- `fee`: `U256`. See the [fee mechanism documentation](/zk-stack/concepts/fee-mechanism) for more information.
+- `initiator_address`: `Address`
+- `received_at`: `DateTime<Utc>`
+- `eth_commit_tx_hash`: `Option<H256>`
+- `eth_prove_tx_hash`: `Option<H256>`
+- `eth_execute_tx_hash`: `Option<H256>`
+
+---
+## Contract Deployment Transactions
+
+Contract deployment transactions interact with the `ContractDeployer` system contract and differ from standard transactions.
+<!-- TODO: update link -->
+<!-- [Learn more about contract deployment in zkSync](../../build/developer-reference/contract-deployment.md). -->
+
+---
+## Transaction statuses
+
+Transactions are always in one of the following statuses:
+
+- `Pending`: Awaiting inclusion in a block.
+- `Included`: Added to a block, but the block's batch is not yet committed.
+- `Verified`: Included and verified after batch commitment and execution on the Ethereum L1 network.
+- `Failed`: Transaction did not verify successfully.
+
+For more on transaction completion and irrevocability, see the [finality documentation](./finality.md).
+
+---
+## Transaction types
+
+zkSync Era supports a range of transaction types that are compatible with Ethereum,
+yet they incorporate unique settings particularly around fee configurations.
+Here’s a detailed look at the transaction types,
+including legacy, EIP-2930, EIP-1559, and EIP-712, and how they are implemented in zkSync Era.
+
+::callout{icon="i-heroicons-information-circle" color="blue"}
+When using RPC methods like [`eth_getTransactionByHash`](https://ethereum.github.io/execution-apis/api-documentation/),
+the transaction type hex value is included in the output.
+::
+
+### Legacy: `0x0`
+
+This is the original Ethereum transaction format used before the introduction of typed transactions.
+
+### EIP-2930: `0x1`
+
+Implemented to mitigate risks introduced by EIP-2929, [EIP-2930: Optional access lists](https://eips.ethereum.org/EIPS/eip-2930)
+adds an `accessList` to transactions, which is an array of addresses and storage keys.
+
+### EIP-1559: `0x2`
+
+Introduced in Ethereum's London update, [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559)
+modifies how transaction fees are handled, replacing `gasPrice` with a base fee and allowing users to set `maxPriorityFeePerGas` and `maxFeePerGas`.
+
+- `maxPriorityFeePerGas`: Maximum fee users are willing to pay miners as an incentive.
+- `maxFeePerGas`: Overall maximum fee, including the `maxPriorityFeePerGas` and the base fee determined by the network.
+
+::callout{icon="i-heroicons-exclamation-triangle" color="amber"}
+In zkSync Era, while the EIP-1559 transaction format is supported, the `maxFeePerGas` and `maxPriorityFeePerGas` parameters are not utilized.
+::
+
+### EIP-712: `0x71`
+
+<!-- TODO: update links -->
+[EIP-712: Typed structured data hashing and signing](https://eips.ethereum.org/EIPS/eip-712)
+enables structured data hashing and signing within transactions.
+<!-- zkSync Era uses this for features like [account abstraction](#) and [paymasters](#). -->
+
+```json
+"gasPerPubdata": "1212",
+"customSignature": "0x...",
+"paymasterParams": {
+  "paymaster": "0x...",
+  "paymasterInput": "0x..."
+},
+"factoryDeps": ["0x..."]
+```
+
+- `gasPerPubdata`: Specifies the maximum gas payable per byte of public data.
+- `customSignature`: For transactions where the account is not an externally owned account (EOA).
+- `paymasterParams`: Configuration for custom paymasters, including address and inputs.
+- `factoryDeps`: Includes bytecode of contracts for deployment, essential for factory contracts.
+
+EIP-712 transactions are designated with a `transaction_type` of `113` due to the one-byte limit, differing from `712`.
+
+Instead of signing the RLP-encoded transaction, the user signs the following typed EIP-712 structure:
+
+- txType: `uint256`
+- from: `uint256`
+- to: `uint256`
+-gasLimit: `uint256`
+- gasPerPubdataByteLimit: `uint256`
+- maxFeePerGas: `uint256`
+- maxPriorityFeePerGas: `uint256`
+- paymaster: `uint256`
+- nonce: `uint256`
+- value: `uint256`
+- data: `bytes`
+- factoryDeps: `bytes32[]`
+- paymasterInput: `bytes`
+
+These fields are handled by our SDKs.
+
+### Priority: `0xff`
+
+This transaction type is specific to zkSync Era and is used for [L1 to L2 transactions](../../build/tutorials/how-to/send-transaction-l1-l2.md),
+highlighting the unique multi-layer interaction that does not exist on Ethereum L1.
+
+---
+
+Each of these transaction types ensures that while zkSync Era remains closely aligned with Ethereum standards,
+it also optimizes for its Layer 2 specific needs and functionalities.