Week 1 Final Evidence: CKB Builder Lab
Hello everyone,
This is the Week 1 progress report for CKB Builder Lab, our approved Spark
Program project focused on interactive developer onboarding infrastructure for
the CKB ecosystem.
Week 1 Milestone
Github: GitHub - devnash11/ckb-builder-lab · GitHub
The Week 1 milestone was:
Simulation architecture completed.
The planned Week 1 tasks were:
-
define simulator architecture
-
design the Cell state model
-
define the challenge framework
-
create the beginner learning flow
-
prepare the implementation handoff for Week 2
These tasks have been completed.
What We Completed
The completed Week 1 files include:
-
`README.md`
-
`docs/architecture.md`
-
`docs/cell-state-model.md`
-
`docs/challenge-framework.md`
-
`docs/learning-flow.md`
-
`docs/week-1-plan.md`
-
`src/simulator/types.ts`
-
`src/challenges/types.ts`
-
`src/content/initial-challenges.ts`
Architecture Summary
We defined the system around four main parts:
-
Learning UI
-
Simulator UI
-
Simulator Engine
-
Challenge Engine
The expected flow is:
User edits Cells → Simulator UI builds a draft transaction → Simulator Engine
validates it → the app shows before/after Cell state and validation trace →
Challenge Engine checks whether the task was completed.
The simulator will be educational and deterministic. It will model the core
CKB Cell lifecycle, while clearly marking simplified areas such as real
signature verification, VM execution, full witness structure, cell deps,
header deps, fees, and real node submission.
Cell and Transaction Model
We designed the MVP Cell model with:
-
`id`
-
`capacity`
-
`lock`
-
optional `type`
-
`data`
-
`status`
Cells can be `live` or `consumed`.
A transaction contains:
-
input Cell IDs
-
output Cell drafts
-
witnesses
Successful simulations consume input Cells and create new live output Cells.
Failed simulations leave the ledger unchanged and return clear validation
errors.
Validation Rules
The first simulator validation rules include:
-
known live inputs
-
at least one output
-
positive capacity
-
lock script exists
-
capacity covers estimated occupied bytes
-
output capacity does not exceed input capacity
-
required owner witness exists
-
educational type script transition rules pass
Each validation result will include a human-readable trace so learners
understand why a transaction passed or failed.
Challenge Framework
We defined the challenge structure, lifecycle, validation inputs, and feedback
model.
The first MVP challenges are:
1. Create Your First Cell
2. Execute State Transition
3. Transfer Ownership
Stretch challenges identified:
-
Add a Type Rule
-
Fix a Failed Transaction
Learning Flow
The first learning path guides developers through:
1. What is a Cell?
2. How does state change?
3. Who owns a Cell?
4. What does capacity mean?
5. What can type scripts enforce?
The intended UI has three areas:
-
lesson and challenge prompt
-
Cell and transaction editor
-
validation trace and before/after state
Technical Direction
We confirmed the MVP stack:
-
Next.js
-
React
-
TypeScript
-
deterministic TypeScript state machine
-
local browser storage for MVP progress
-
optional API routes or Supabase later if needed
-
Vercel deployment
Week 1 Status
Week 1 is complete.
Completed items:
-
simulator architecture
-
Cell state model
-
transaction and local ledger model
-
validation rule plan
-
challenge framework
-
first three MVP challenge definitions
-
beginner learning flow
-
Next.js implementation decision
-
Week 2 handoff plan
Week 2 Plan
Week 2 will focus on simulator engine development.
Planned tasks:
1. Set up the Next.js prototype.
2. Implement simulator domain types.
3. Implement Cell factory helpers.
4. Implement occupied capacity estimation.
5. Implement transaction validation.
6. Implement transaction application to local ledger state.
7. Add unit tests for valid and invalid transactions.
8. Return explanatory trace events for UI rendering.
By the end of Week 2, we should be able to prove through tests that valid
transactions consume live Cells and create outputs, consumed Cells cannot be
reused, invalid capacity or missing locks fail, ownership transfer works, and
failed transactions leave state unchanged.
Summary
Week 1 is complete. CKB Builder Lab now has a clear architecture, Cell model,
challenge framework, learning flow, and Week 2 implementation plan. The
project is ready to move into the Next.js + TypeScript simulator engine build.