CKB Academy

https://github.com/flouse/ckb-academy
Admin
CKB Academy is an interactive learning platform designed to onboard new Nervos developers with...
Tokens:3,086
Snippets:27
Trust Score:7
License:MIT
Update:1 year ago
Show doc for...
Tokens:
Raw
### 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
<ConnectWallet />
```

--------------------------------

### 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
<WalletReady>
  <BlocksSection />
</WalletReady>
```

--------------------------------

### 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
<WalletReady>
  <TestnetConfigSection />
</WalletReady>
```

--------------------------------

### 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
<WalletReady>
  <CellsSection />
</WalletReady>
```

--------------------------------

### 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
<WalletReady>
  <SendTransaction />
</WalletReady>
```

--------------------------------

### 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
<WalletReady>
  <CheckBlock />
</WalletReady>
```

--------------------------------

### 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<string> (nullable)
    Description: List of header dependencies, currently null.
  cell_deps: array<object>
    Description: A list of out_points indicating dependency cells.
    Structure:
      tx_hash: string
      index: string
  inputs: array<object>
    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<object>
    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<string>
    Description: List of data corresponding to cells in outputs.
  witnesses: array<string>
    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
```
Tokens:
Raw