### Install Dependencies and Start Development Server Source: https://github.com/flouse/ckb-academy/blob/dev/README.md This snippet provides commands to set up the development environment for the CKB Academy project. It includes installing dependencies, setting up Git hooks for code formatting, and starting the local development server using either `yarn dev:site` or `turbo run dev`. ```bash # install dependencies yarn # Install Git hook to achieve code formatting during code submission. yarn run prepare # start a development server: https://start.solidjs.com/api/dev yarn dev:site # or turbo run dev ``` -------------------------------- ### Start Production Server Source: https://github.com/flouse/ckb-academy/blob/dev/README.md This command starts the production server after the project has been built. It serves the bundled application from the `output` directory. ```bash # https://start.solidjs.com/api/start yarn start ``` -------------------------------- ### Integrating ConnectWallet Component for MetaMask Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-operation/chapter_1/chapter_1.mdx This example demonstrates how to embed the `ConnectWallet` React component into a page. Its primary function is to facilitate the connection to a MetaMask wallet, which is the initial step for all on-chain operations in the course. ```JSX ``` -------------------------------- ### Simple User Defined Token (SUDT) Type Script Parameters Example Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-theory/chapter_5.mdx Provides a real-world example of parameters used to locate the Simple User Defined Token (SUDT) type script on the CKB testnet. This demonstrates the values for `code_hash`, `hash_type`, `tx_hash`, `index`, and `dep_type` that point to the actual script code. ```APIDOC SUDT Type Script Location Parameters: code_hash: 0xc5e5dcf215925f7ef4dfaf5f4b4f105bc321c02776d6e7d52a1db3fcd9d011a4 hash_type: type tx_hash: 0xe12877ebd2c3c364dc46c5c992bcfaf4fee33fa13eebdf82c591fc9825aab769 index: 0x0 dep_type: code ``` -------------------------------- ### Displaying Latest Blocks with BlocksSection Component Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-operation/chapter_1/chapter_1.mdx This example shows how to integrate the `BlocksSection` component, wrapped by `WalletReady`, to present the nine most recent blocks on the CKB testnet. It ensures that block data is fetched and displayed only when the wallet is ready. ```JSX ``` -------------------------------- ### Build Project for Production Source: https://github.com/flouse/ckb-academy/blob/dev/README.md This snippet shows the commands to build the CKB Academy project for production. It uses `solid-start` and `Vite` to bundle server and client code. The output will be located in `site/dist/public`. ```bash # https://start.solidjs.com/api/build yarn build # or turbo run build ``` -------------------------------- ### Displaying Testnet Configuration with TestnetConfigSection Component Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-operation/chapter_1/chapter_1.mdx This snippet demonstrates the use of the `TestnetConfigSection` component, enclosed within `WalletReady`, to display crucial configuration information of the CKB testnet, such as the chain prefix and details about built-in smart contracts. ```JSX ``` -------------------------------- ### Importing Core React Components for CKB Operations Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-operation/chapter_1/chapter_1.mdx This snippet lists the essential React components imported from local paths, which are utilized throughout the CKB basic operations course to manage wallet connections, display cells, show blocks, and configure testnet settings. ```TypeScript import { ConnectWallet } from "~/content/courses/basic-operation/chapter_1/ConnectWallet.tsx"; import { CellsSection } from "~/content/courses/basic-operation/chapter_1/CellsSection.tsx"; import { BlocksSection } from "~/content/courses/basic-operation/chapter_1/BlocksSection.tsx"; import { TestnetConfigSection } from "~/content/courses/basic-operation/chapter_1/TestnetConfigSection.tsx"; import { WalletReady } from "~/content/components/WalletReady.tsx"; ``` -------------------------------- ### Displaying Live Cells with CellsSection Component Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-operation/chapter_1/chapter_1.mdx This snippet illustrates the usage of the `CellsSection` component, nested within `WalletReady`, to dynamically display the user's live CKB cells. It requires the wallet to be connected and ready before rendering the cell list. ```JSX ``` -------------------------------- ### CKB Testnet Built-in Smart Contracts Reference Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-operation/chapter_1/chapter_1.mdx This section provides a reference for the pre-deployed built-in smart contracts available on the CKB testnet. It includes details on their purpose and typical use cases, such as protecting cell ownership or enabling multi-signature functionalities. ```APIDOC Testnet Configuration: PREFIX: ckt (Indicates test chain) Built-in Smart Contracts (SCRIPTS): - SECP256K1_BLAKE160: Purpose: The system's default smart contract for the lock script of cells, used to protect the ownership of the cells. - SECP256K1_BLAKE160_MULTISIG: Purpose: The multi-signature version of SECP256K1_BLAKE160. - DAO: Purpose: NervosDAO contract. ``` -------------------------------- ### Sending a Transaction to CKB Testnet Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-operation/chapter_3/chapter_3.mdx This snippet demonstrates how to send a transaction to the CKB testnet using the `SendTransaction` component, wrapped within a `WalletReady` context. It highlights that the returned transaction hash (`tx_hash`) remains consistent with the one generated beforehand, ensuring CKB's certainty. ```JSX ``` -------------------------------- ### CKB Transaction Inputs and Outputs Visualization Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-theory/chapter_7.mdx Visualizes how inputs (existing cells) are transformed into outputs (new cells) within a CKB transaction. ```ts inputs: some cells... ｜ ｜ ｜ \/ outputs: some new cells... ``` -------------------------------- ### CKB Transaction Rule: Miner Fee Calculation Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-theory/chapter_7.mdx Explains the second rule for CKB transactions, where the difference between input and output capacities constitutes the miner's fee. ```text sum(cell's capacity for each cell in inputs) - sum(cell's capacity for each cell in outputs) = fee ``` -------------------------------- ### CKB Transaction Essence Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-theory/chapter_7.mdx Illustrates the fundamental concept of a transaction in CKB, showing it as a transformation from inputs to outputs. ```ts transaction: inputs -> outputs ``` -------------------------------- ### WitnessArgs Structure Definition for CKB Transactions Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-operation/chapter_3/chapter_3.mdx Defines the `WitnessArgs` structure, an essential component in CKB transactions for providing additional arguments or data, such as signatures. It includes fields for lock script arguments, and optional input/output type script arguments. ```APIDOC table WitnessArgs { lock: BytesOpt, // Lock Script args, which holds the lock-script-related arguments or data input_type: BytesOpt, // Type Script args for input (optional) output_type: BytesOpt, // Type Script args for output (optional) } ``` -------------------------------- ### CKB Script Structure Definition Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-theory/chapter_5.mdx Defines the structure of a CKB Script, including `code_hash` for referencing code, `args` for script arguments, and `hash_type` to specify how `code_hash` is interpreted for code retrieval. The `hash_type` can be 'data', 'type', or 'data1'. ```ts Script: { code_hash: HexString args: HexString hash_type: Uint8, there are three allowed values: {0: "data", 1: "type", 2: "data1"} } ``` -------------------------------- ### CKB Script `code_hash` Interpretation by `hash_type` Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-theory/chapter_5.mdx Explains how the `code_hash` field in a CKB Script is interpreted based on the `hash_type` value. It specifies that `code_hash` matches the Blake2b hash of either the data field or the type script of a dependency cell (`CellDep`), depending on the `hash_type`. ```APIDOC hash_type interpretations for code_hash: - If hash_type is "data" or "data1": code_hash should match blake2b_ckbhash(data) of a dep cell. - If hash_type is "type": code_hash should instead match blake2b_ckbhash(type script) of a dep cell. ``` -------------------------------- ### CKB Cell Field Specifications Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-theory/chapter_2.mdx Detailed specifications for each field within the CKB cell structure. `capacity` defines the cell's size in shannon, `lock` and `type` are scripts governing permissions and data interpretation respectively, and `data` holds the arbitrary byte content. These definitions are essential for interacting with and understanding CKB's on-chain data model. ```APIDOC capacity: description: The space size of the cell, i.e. the integer number of native tokens represented by this cell, usually expressed in hexadecimal. The basic unit for capacity is shannon, 1 CKB equals 10**8 shannon. type: HexString lock: description: A script, which is essentially the equivalent of a lock. type: Script type: description: A script, same as the lock but for a different purpose. type: Script data: description: This field can store arbitrary bytes, which means any type of data. type: HexString ``` -------------------------------- ### CKB Script Structure Definition Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-theory/chapter_3.mdx Defines the fundamental structure of a CKB Script, which acts as a lock on a cell. It comprises `code_hash` to reference the executable code, `args` for arguments passed to that code, and `hash_type` to specify the interpretation method of the `code_hash`. This structure is crucial for determining cell ownership and validating transactions. ```TypeScript Script: { code_hash: HexString args: HexString hash_type: Uint8, there are three allowed values: {0: "data", 1: "type", 2: "data1"} } ``` -------------------------------- ### Checking CKB Transaction Status On-Chain Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-operation/chapter_3/chapter_3.mdx This snippet illustrates how to check the on-chain status of a previously sent CKB transaction using the `CheckBlock` component, also within a `WalletReady` context. It explains that a 'pending' `tx_status` indicates ongoing verification, requiring a retry later. ```JSX ``` -------------------------------- ### CKB Transaction JSON Structure Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-operation/chapter_2/chapter_2.mdx Defines the JSON structure for manually constructing a CKB transaction, including its inputs, outputs, and other critical fields. This structure is used for off-chain assembly and on-chain verification. ```APIDOC CKB Transaction (JSON Object): version: string Description: The transaction version, currently '0x0'. header_deps: array (nullable) Description: List of header dependencies, currently null. cell_deps: array Description: A list of out_points indicating dependency cells. Structure: tx_hash: string index: string inputs: array Description: List of transaction inputs, referencing cells to be spent. Structure: previous_output: object Description: An outpoint composed of tx_hash and index, akin to an index, or a pointer to the cell. Structure: tx_hash: string index: string since: string Description: Controls the time for the input (details omitted for now). outputs: array Description: List of newly generated cells. Structure: capacity: string Description: The capacity of the new cell. lock: object Description: The lock script for the new cell. Structure: args: string Description: Arguments for the lock script. outputs_data: array Description: List of data corresponding to cells in outputs. witnesses: array Description: Contains the transaction signature and serves as proof of the transaction. ``` -------------------------------- ### OutPoint Structure Definition Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-theory/chapter_7.mdx Defines the `OutPoint` structure used in CKB for referencing specific cells, including its components: transaction hash and cell index. ```APIDOC OutPoint: { tx_hash: The hash value of the transaction to which the target cell belongs index: The cell position in the transaction to which the target cell belongs } ``` -------------------------------- ### CKB Transaction Rule: Capacity Conservation Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-theory/chapter_7.mdx Defines the first rule for CKB transactions, stating that the total capacity of output cells must be less than the total capacity of input cells, preventing capacity minting. ```text sum(cell's capacity for each cell in inputs) > sum(cell's capacity for each cell in outputs) ``` -------------------------------- ### CKB Built-in Script Never-Unlockable Lock Configuration Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-theory/chapter_6.mdx This snippet shows the lock field configuration for CKB's built-in script code cells. This specific configuration ensures that the cell can never be unlocked or spent, guaranteeing the permanent availability of the script code. ```TypeScript Never unlockable lock: { code_hash: 0x0000000000000000000000000000000000000000000000000000000000000000 hash_type: data args: 0x } ``` -------------------------------- ### CKB Cell Capacity Constraint Formula Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-theory/chapter_2.mdx This formula illustrates the fundamental constraint on CKB cell capacity. The total allocated space (`capacity`) must always be greater than or equal to the combined byte length of all four cell fields (`capacity`, `lock`, `type`, `data`). This rule ensures data integrity and prevents cells from exceeding their defined storage limits. ```text capacity = Cell's total space >= Sum of the 4 fields' byte length ``` -------------------------------- ### TypeScript Definition of CKB Cell Structure Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/courses/basic-theory/chapter_2.mdx This TypeScript snippet defines the core structure of a CKB cell. A cell is composed of four essential fields: `capacity` (storage size), `lock` (ownership/permission script), `type` (data interpretation script), and `data` (arbitrary bytes). This structure is crucial for understanding how data and value are organized and managed on the CKB blockchain. ```ts Cell: { capacity: HexString; lock: Script; type: Script; data: HexString; } ``` -------------------------------- ### Nervos CKB Cell Field Definition Source: https://github.com/flouse/ckb-academy/blob/dev/site/src/content/keyword-annotation/cell.mdx Defines the four fundamental fields that constitute a Cell in Nervos CKB, serving as the primary state unit for state storage. ```APIDOC Cell Fields: - capacity - data - type - lock ``` === COMPLETE CONTENT === This response contains all available snippets from this library. No additional content exists. Do not make further requests.