Skip to content
Blockchain Association of Cameroon
fr — Françaisen — English

Layer-0 Developer Academy

BAC Blockchain Engineering Lab

Three environments, one rule: what a participant may break must be breakable without consequence, and what must not be broken must be out of their reach. The boundaries below are that rule made concrete.

LAB-LOCAL

Developer workstation

Anything that can run on the participant's own machine runs here. It is the default environment, and the only one available with no connection.

Operated by — DevOps / Blockchain Infrastructure Engineer

Contains

  • Standard tooling: Git, Docker, Rust, Go, Node.js, Foundry
  • Containerised local multi-node networks
  • Pre-built images distributed by BAC for light mode
  • Offline copies of briefs and data sets

Access

No account, no authorisation: the participant is its administrator.

What may be destroyed

Everything. A local environment is destroyed and rebuilt by script in under an hour.

LAB-CLOUD

Shared cohort infrastructure

Whatever exceeds a participant's machine: long builds, multi-server networks, infrastructure exercises, and remote workspaces for shared mode.

Operated by — Cloud Architect

Contains

  • Two servers per participant on Level 3 tracks
  • Remote workspaces for thin clients
  • Shared image registry and dependency cache
  • Common monitoring: metrics, logs, alerts

Access

Named account per cohort, revoked at closure; SSH key access only.

What may be destroyed

The participant's own perimeter, isolated per project. Disaster drills happen here without affecting other teams.

LAB-NETWORK

BAC public testnet

The permanent infrastructure BAC genuinely operates: demonstration chains, public endpoints and the test-token faucet.

Operated by — DevOps / Blockchain Infrastructure Engineer

Contains

  • Demonstration chains for the four ecosystems
  • Public, rate-limited RPC endpoints
  • Block explorer and test-token faucet
  • Monitored relayers between demonstration chains

Access

Public read; write through the faucet; administration restricted to the operations team.

What may be destroyed

None. Participants deploy and transact here but administer nothing — destructive exercises stay in LAB-CLOUD.

BAC Multichain Developer Testnet

A permanent network where a chain can be deployed, broken, upgraded and connected without a single unit of value being at stake.

bac-dot-testnetPlanned — phase 9

Polkadot SDK

Test Relay Chain and demonstration parachains for the XCM labs.

bac-cosmos-testnetPlanned — phase 9

Cosmos SDK

Two sovereign chains linked over IBC, with a monitored relayer.

bac-avax-testnetPlanned — phase 10

Avalanche

Two application L1s linked by cross-chain messaging.

bac-rollup-testnetPlanned — phase 10

Rollup souverain / Celestia

Demonstration rollup publishing to a test availability network.

  • 01No testnet token has, should have, or may be presented as having any value.
  • 02Networks are resettable: a participant must be able to break everything without asking permission.
  • 03Every demonstration chain is rebuildable from its repository, with no manual step.
  • 04Administration keys never leave the operations team, not even during a workshop.
  • 05Network status and incidents are public: the testnet doubles as an operations exemplar.

Working with limited infrastructure

A significant share of participants will work on modest hardware and metered connections. Every workshop must remain feasible in one of these three modes — that is a publication condition, not an accommodation.

Full mode

16 GB workstation, local node compilation, local multi-node network.

Recommended for L2 tracks and beyond.

Light mode

8 GB machine, pre-built binaries distributed by BAC, Docker images instead of compilation.

Every compilation step in a workshop must have a signed-binary alternative.

Shared mode

Thin client connected to a remote LAB-CLOUD workspace, shared across the cohort.

Offline package required: briefs, solutions and data sets downloadable ahead of the session.

The seven-lab ladder

Applied to every technical concept in every track.

  1. 01

    Lab

    Does the concept work on a nominal case?

  2. 02

    Advanced lab

    Does it hold across several nodes?

  3. 03

    Infrastructure lab

    Does it hold on separate servers, under real network conditions?

  4. 04

    Security lab

    What happens when an actor turns hostile?

  5. 05

    Failure lab

    What happens when a component stops?

  6. 06

    Recovery lab

    How long does it take to return to service, and who knows how?

  7. 07

    Monitoring lab

    Would the failure have been seen coming?