ZKsync Community Guides

A subgraph is a decentralized indexing layer that extracts data from a blockchain, processes it, and stores it for efficient retrieval via GraphQL. This prevents DApps from having to query the chain directly, which is often slow and expensive. A subgraph consists of three key components:

• subgraph.yaml: The manifest file containing the subgraph configuration.
• schema.graphql: The GraphQL schema defining the data entities and how they are queried.
• AssemblyScript Mappings: Code that translates raw blockchain event data into the entities defined in the schema.

The sample payment app uses the following architectural components:

• AccountContext: Manages user account details and provides them globally via AccountProvider in app/_layout.tsx.
• TxnContext: Monitors ZKsync Era Sepolia testnet blocks to filter and display real-time transactions for the user and their friends.
• MainView: Handles routing between LoggedOutView and the authenticated account tabs.
• LoggedOutView: Provides entry points for creating a new account/passkey or signing in with an existing one.
• PasskeyCreationView: The specific component where the createPasskey function is triggered.
• send-money/[id].tsx: Handles ETH transfers, utilizing a price feed from Alchemy and triggering the sendETHWithSSO function.

Direct transactions from Layer 2 (L2) to Layer 1 (L1) are not possible. Instead, ZKsync Era allows sending arbitrary-length messages from L2 to Ethereum L1. These messages are published as data on L1 and can be handled by an L1 smart contract.

In Solidity, an L2 message is represented as: struct L2Message { address sender; bytes data; uint256 txNumberInblock; }

Interop messaging via ZKsync Connect allows users or contracts to broadcast arbitrary data that can be verified on any ZKsync chain using the ZKsync Gateway. Unlike traditional cross-chain messaging, these messages do not have a predefined destination chain or address; they are simply payloads that remain verifiable indefinitely on any chain within the ecosystem.

Current Capabilities:

• Anyone can send a message.
• Anyone can verify that a message was successfully sent on a specific chain.

Current Limitations:

• No support for selecting specific destination chains.
• No nullifiers or replay protection.
• No cancellation mechanism.
• No direct support for sending assets or calling contracts (these are planned for future phases of universal interoperability).

The permissionless multi-signer paymaster allows ZKsync Dapps to sponsor gas for users via signature verification without needing to deploy their own paymaster contract. It uses a one-to-many relationship between Managers and Signers:

• Manager: Responsible for depositing/withdrawing gas funds and managing (adding/removing) signer addresses.
• Signers: Entities (managed by the Dapp or a third party like Zyfi) whose signatures are required to authorize the use of the manager's gas funds for a user's transaction.

Withdrawing assets from ZKsync L2 to L1 involves three primary steps:

1. Burning the specified tokens on L2.
2. Sending a message from L2 to L1 detailing the withdrawal.
3. Finalizing the withdrawal by calling the finalizeWithdrawal method on the L1 bridge, which unlocks the funds and sends them to the recipient.

Note: During the Alpha phase, withdrawals in ZKsync Era take 24 hours for security reasons.

Withdrawing assets from ZKsync L2 to L1 involves three primary steps:

1. Burning the specified tokens on L2.
2. Sending a message from L2 to L1 detailing the withdrawal.
3. Finalizing the withdrawal by calling the finalizeWithdrawal method on the L1 bridge, which unlocks the funds and sends them to the recipient.

Note: During the Alpha phase, withdrawals in ZKsync Era can take up to 24 hours for security reasons.

The game uses a deterministic logic written in Rust to ensure consistency between the client and the backend. The workflow for verifying a high score is as follows:

1. Client Recording: The game records player movements and the final score on the client side.
2. Proof Generation: The client sends recorded actions, final score, and time to a backend service.
3. Backend Execution: An SP1 program re-runs the game using the recorded actions to verify the score. A program verification key ensures the correct program is executed.
4. Onchain Verification: The resulting ZK proof is sent back to the player, who submits it to an onchain verifier contract.
5. User Experience: The process integrates ZKsync SSO for account management and a paymaster contract to sponsor transaction fees, removing the need for players to hold funds.

ZKsync Era is a state diff-based ZK rollup. Unlike traditional rollups that publish full transaction calldata, ZKsync Era only publishes state changes (state diffs) as pubdata. This includes modified storage slots, smart contract bytecodes, and L2 → L1 messages and logs.

The cost is calculated as: pubdata_bytes_published * gas_per_pubdata.

Key characteristics include:

• Separation of Costs: Computational costs and pubdata costs are treated separately, unlike Ethereum where all costs are represented by gas.
• Efficiency for Repeated Writes: Applications that modify the same storage slot multiple times (e.g., oracles) only pay for the final state change on L1, rather than for every individual update.
• Dynamic Pricing: Costs fluctuate based on current L1 gas prices.

Depositing ERC-20 tokens from Layer 1 (L1) to Layer 2 (L2) involves the following workflow:

1. Locking L1 Tokens: Tokens are sent to and locked in the L1 bridge contract via the deposit method.
2. Initiating Transaction: The L1 bridge initiates a transaction to the L2 bridge.
3. Minting L2 Tokens: Corresponding tokens are minted on L2 and sent to the destination address. If the token does not yet exist on ZKsync Era, a new contract is deployed based on the L1 address, name, and symbol.
4. Confirmation: L2 sends a log message back to L1 to confirm the transaction.
5. Finalizing: The finalizeDeposit method is called on the L2 bridge to complete the minting process.