An intelligent aggregator hub: chains as knowledge bases, consensus as clauses, contracts that learn — built of cocolog programs.
The Coco uses Cicili, ZiguratIP and cocolog, and modifies none of them — the same discipline cocolog holds toward its own two pillars, one level up. cocolog is a Prolog with advanced knowledge-base machinery; The Coco is what gets built when that machinery is pointed at one problem: hosting many ledgers, under many consensus regimes, on one engine that can also train.
Everything in this repository is one of four things:
- Prolog —
.plfiles consulted by the onecocologbinary. A consensus rule, a contract, a validity predicate, a fork choice: all clauses, all data. - Parsi — The Coco's OWN schema objects, compiled by ZiguratIP's
parsicompiler into a server home. This is how The Coco reaches capability the engine has but Prolog does not: a Parsi procedure's backticks call straight into Zigurat's C++ —`Zigurat::`SHA::`checksumis a stored procedure away, and Zigurat'sCryptography/carries SHA-1..512 with HMAC, RSA with both signature schemes, AES and X509 with its owncatool. Hashing and signing are the warrior's job, reached over the wire, no repository touched. - Cicili modules — when The Coco needs a predicate Prolog cannot
reach, it writes the C half in Cicili against cocolog's
lib/sdk.cicili, compiles it to a shared object, anduse_module(library(Name))loads it at run time. cocolog is not modified; the module is The Coco's, and MODULES.md over there is the developer guide to both ways of writing one. - Choreography —
run.sharrangements in the mold of cocolog's coworker tasks: processes, knowledge bases, and the order between them.
What does NOT live here: raw C or C++, or any change to the three pillars. C-shaped work is written in Cicili and its macros, always -- only inside ZiguratIP is there a choice between C++ and Cicili. When a rung genuinely needs a new engine capability (TLS in cocolog's C client, say), that capability is built in ITS repository on its own merits, and The Coco uses it once it exists.
That rule has already paid once. Reading the Bitcoin genesis transaction meant handing cocolog a 408-character atom, and cocolog had been truncating atoms at 255 characters since the day it was written. The Coco could have worked around it in an afternoon and nobody would have known. The diagnosis went to cocolog instead, the fix landed there with its own regression test, and the workaround was never written.
Every blockchain is structurally forbidden from learning: its contract VM
must be deterministic arithmetic, so intelligence lives off-chain behind
oracles. Here the contract language, the consensus rules, the ledger
entries and the trained models are the same substance — clauses and rows
in a transactional store — executed by an engine that is already
deterministic and already metered (max_steps is gas). A chain is a
knowledge base; one node hosts many chains under different consensus
regimes; each chain publishes its own validity rules as entries on
itself, so the chain carries its own light client. A ledger that
learns, and above it, a hub with a mind.
The foundations are proven in cocolog's STATUS.md, story by story: turns as transactions, the balancer as gossip, the accumulator as fan-in settlement with a held-out acceptance test, claim-of-one as leader election, freeze/thaw as suspended contracts, model parameters as rows in the tensors table, the certificate-borne permission system that decides who may append — the certificate names the grants, and the server checks them per operation against the peer TLS identified — and the isolation ladder from READ_UNCOMMITTED to SERIALIZABLE, chosen per turn.
The thesis picks a language, and the pick is argued rather than assumed:
bench/languages.md compares Python, Prolog and
cocolog across the language aspects, the backend work, and the four
separate senses of "AI-friendly" — honestly, which means cocolog loses
often and the file says where. It opens with the everyday row, where
most language choices are actually made — ease, syntax weight,
readability, how much code a thought costs — and there the "less code"
claim is this repository's own measurement rather than an adjective:
the whole of library/poa.pl's consensus is 39 non-comment lines,
outnumbered by its explanatory prose nearly three to one, with the
concessions attached (Python wins ease of entry outright; Prolog's
steepness lives in semantics, not syntax; misapplied Prolog is MORE
code, not less). What the thesis actually needs is the
rows where cocolog differs in POSITION rather than in language: a clause
is a row other processes read, a turn is a transaction, a suspended
proof is data any process can finish, and determinism and metering are
the engine's guarantee rather than the application's promise. Those four
rows are this repository's load-bearing wall; the rest of the comparison
— the everyday row included — is there so nobody mistakes the wall for
the whole house.
And the harness has printed its sentence on two computers now: bench/README.md carries the current readings. On the latest box cocolog runs the same five programs at 6-19x CPython as a language; its server arrangement sits within a few percent of its own in-memory one on every task (a turn over a socket, committed, at in-memory price); its embedded store answers the probe-heavy task 6.5x faster than python + sqlite3's indexed file, while on the compute-heavy tasks a store attached costs BOTH sides almost nothing over their own memory; and the PoH spine produces at 4.1M ticks/s while four verifiers audit it 3.1-3.6x faster than one produced it.
STATUS.md carries the missions in full — what stands under each and the
disciplines that hold across all of them. The short of it, each rung an
arrangement that ends in a GREEN line before it is claimed: crypto as
The Coco's own Parsi objects; the PoA federation ledger; contracts as
predicates under max_steps; COCO, the native token, where gas is the
engine's own inference count rather than a price list somebody
maintains, and where a validator's weight is coin it can lose;
training as settlement; a PoH spine; PoS and BFT votes where the trust
model wants them; the aggregator, where a chain carries its own light
client; and the TPS harness, whose number is printed before any sentence
uses it.
The token rung is where the thesis pays a bill. Every other chain has to
write down what each operation costs, and keep that table in step with
an implementation nobody can check it against; here the engine meters
every proof and call_metered/4 hands the count to the clause that
charges for it — deterministically, so two nodes that never met compute
the same fee. Gas stops being a specification and becomes a
measurement.
And once the chain has money, the rung above it is the one proof of
stake was missing: stake_entry/2 — the table library(pos) demands
and refuses to own — becomes a rule over bonded COCO, so a
validator's weight is coin it has locked and library(bft)'s evidence
has something to take. Two signed votes that cannot both be honest cost
their author the whole bond.
Above that, assets: a game's units as NFTs the chain carries —
production mints, capture transfers without the holder's consent, the
kill burns the id forever, and a unit's whole life is a query over the
blocks. Which needed the capability none of the contracts had: a
contract that cannot ask who is calling cannot own anything, so the
fence gained caller/1, answered by the node out of the signature it
already verified rather than by an argument a stranger could write.
And above that, a market: the pool's blocks are the market's
candles (market/). A block carries the trades of a block; every
node applies them to the Uniswap pool it holds and hands each one,
with exactly what the pool answered, to
Cocolog Market — the
reasoning side, another repository on the same cocolog — which seals
the height as a candle and reasons over it as over any exchange feed.
Two nodes holding the same blocks compute the same candles, and a
refused trade is a row with its reason rather than a silence. The
search for profitable strategies runs from the node too, over those
candles, its finds proven on the candles after; two nodes find the
same strategies, because everything in between is a function of the
chain.
One arrangement runs across rungs rather than being one of them.
test/secure.pl re-runs the three consensus rungs — 2, 5 and 6 — with
the node-to-store link encrypted, and requires every verdict to be
unchanged. A ladder whose rungs meant something different over TLS would
not be a ladder worth climbing.
The ladder's chains are this repository's own. Beside them, The Coco runs
full nodes of chains other people run, on the same cocolog -- and
there the rules are not ours to write. A node that disagrees with its
reference implementation on one block is not that chain's node, so the
reference is the oracle and the split is the one cocolog's own
cryptography already lives by: what consensus needs bit-exact -- Script,
the retarget, weight, the commitments -- is the reference's library,
bound through a Cicili module and never rewritten; what is policy --
chain parameters, peers, sync, mempool, relay, RPC -- is clauses; and
past bit-exactness the line is drawn by measuring both ways in one
sitting and keeping the faster. Every node runs --mode full, keeping
what the reference keeps, or --mode light, validating every block the
same way and keeping the minimum the reference allows -- for Bitcoin,
where the kernel can be told to prune, Core's own floor: the coins,
every header, and the last 288 blocks' data and undo; at the pin, every
block (below). (This once said light keeps only the last block's data,
by design: below Core's floor, since Core's pruning never deletes the
last 288 blocks.)
The first is Bitcoin's, on Bitcoin Core's libbitcoinkernel, and it is
at phase 2 of five. Phase 1 is the stateless grain -- a block or a
transaction checked with no chain behind it, one input's Script verified
against the output it spends -- and the chain parameters as facts. Phase
2 is the second grain: the kernel's ChainstateManager over a data
directory laid out as bitcoind lays it out -- blocks and headers fed to
it, framed block files imported or its own reindexed, the block tree read
back, its events drained into the knowledge-base view -- and bitcoin sync, which imports framed files or reindexes and drains the events into
the view, under --local; the view as a table under a store is phase 2b,
not built. Light mode keeps the minimum Core allows, where the kernel
can be told to. Built against a kernel that carries the prune patch
(docs/bitcoin/PRUNE-PATCH.md),
library(btc) can prune (btc_prune/1,2) and light sync prunes the
node to Core's floor -- the last 288 blocks' data and undo, in whole
files, by manual pruning, which has no size target; at the pin, whose
kernel cannot be told to prune, light keeps every block and sync says
so. The patch is written, built and run with Core's own kernel test; it
is not applied to the Core checkout and is in no Core repository,
carrying it is the owner's decision, and the pin stays 83434f7.
Light and full differ in the block data and what follows from it:
the same validation, the same coins and every header in both. With the
patch, light keeps only the last 288 blocks' data and undo (plus the
slack of whole files), so its reorg depth is at least 288, guaranteed,
and deeper only as far as the kept files' slack still holds the data; a
pruned store cannot be reopened as full or rebuilt from its own files,
and Core refuses a txindex with pruning. In both builds light serves no
block more than 288 + 2 below the tip and advertises
NODE_NETWORK_LIMITED | NODE_WITNESS (1032), where full serves every
block and adds NODE_NETWORK (1033). docs/bitcoin.md's
Modes section has the table. Every part of phase 1 that
is clauses has run green on cocolog 1.8.41, the release binary, and its
cases and lessons again on cocolog 1.8.48 built from master; phase 2 has
run on that 1.8.48 build only; Core's kernel builds at its pinned
commit; the module that binds it, modules/btc, has been built and its
cases are green; the three phase-1 commands that need it answer as
docs/bitcoin.md says, and sync takes a data directory to tip 206 on
Core's own regtest chain, in both modes. Against the patched kernel,
test/chain.pl feeds a light node Core's 206 regtest blocks, mines it
to height 1100, prunes it to Core's floor (block data kept from 627),
then switches it to a fork of two blocks built on 1099 -- a reorg one
block deep, the old 1100 disconnected (2026-10-03). From the root of
this checkout:
cocolog -s main.pl -- bitcoin COMMAND # after . test/config.sh, as $COCOLOG/cocologIts seven cases -- params, btc, chain, sync, peers, mempool
and tutorials -- are in coco.yaml's suite, and the suite table below
counts them from the last green test/run.sh with a server up.
docs/nodes.md is the
architecture every node follows, docs/bitcoin.md the
Bitcoin node's manual, docs/bitcoin/PLAN.md its
plan -- the pin, the phases, the budgets -- and
tutorials/README.md the lessons: one per library,
and one that runs the node.
The Coco needs its three pillars built and beside it:
git clone https://github.com/saman-pasha/cicili
git clone https://github.com/saman-pasha/ziguratip ZiguratIP
git clone https://github.com/saman-pasha/cocolog
git clone https://github.com/saman-pasha/coco CocoCloned side by side like that, nothing needs to be exported at all:
coco.yaml names the pillars as siblings of this repository, and every
script reads it through test/config.sh. Checkouts somewhere else are a
line of exports rather than an edit to a tracked file, because the
environment always wins over the file:
export CICILI="$HOME/Projects/GitHub/cicili" # for building the pillars
export ZIGURATIP="$HOME/Projects/GitHub/ZiguratIP" # a BUILT ZiguratIP
export ZIGURATIP_HOME="$ZIGURATIP/home"
export COCOLOG="$HOME/Projects/GitHub/cocolog" # a BUILT cocolog beside itTwo more checkouts are optional. git clone https://github.com/saman-pasha/market-actor beside the others gives
the market case its reasoning side (market.library in coco.yaml,
or MARKET_LIBRARY); without it that one case SKIPs and says so. And
Bitcoin Core at 83434f7683e45afc1ebbb7690a6ae288b2602b03, beside the
others too (pillars.bitcoin in coco.yaml, or BITCOIN), with its
kernel built SHARED as docs/bitcoin.md says under "The kernel", is
what sh modules/btc/build.sh builds the Bitcoin node's kernel module
against; without it the btc case SKIPs. For light mode's pruning,
BITCOIN and BITCOIN_BUILD name a clone of the pin with the prune
patch on top instead, built the same way
(docs/bitcoin/PRUNE-PATCH.md), and
build.sh says which kernel it found. One cocolog module is optional
too: library(torch), built against libtorch by sh modules/torch/build.sh in cocolog; without it the training case SKIPs
and says so.
Build ZiguratIP (make in its checkout), then cocolog (make and
make schema in its checkout), then:
cd Coco
sh test/run.sh # every case; the wire cases SKIP without a servercoco.yaml is also where the crypto module list lives, so adding a
module is a line there and nothing else — build.sh and the crypto case
both read it rather than carrying their own copy. Four copies of one
fact drift; one does not.
Every case is a cocolog script, so the suite is written in the
language the repository is written in. A case is main/0 — a run of
checks and a verdict line — and the exit code is the verdict: 0
exactly when main proved, which checks_done withholds on any red
check. test/run.sh only drives them.
../cocolog/cocolog -s test/bond.pl # one case; 0 or 1 says which
sh test/run.sh # every case coco.yaml declares, one line eachTwenty-seven cases. The last whole run -- 2026-10-03, cocolog 1.8.48
built from master, a server up, the tree that gave btc_open/4's
options the btc_ prefix (nodes 0.1.3), with library(btc) built at
the pin -- printed red: 0 in 2 min 57.9 s and 1221 verdicts in the
twenty-five that ran: 1212 checks, and tutorials' nine lessons. The
1221 are the light-node tree's 1220 plus chain's one new check (129),
that an unprefixed option such as wipe(true, false) is refused; the
one section skipped inside a case is chain's pruning, which SKIPs by
name with the module built at the pin. The light-node tree's run printed
its 1220 in 2 min 26.9 s (2 min 58.7 s before comment-only edits):
phase 2's 1212, after its review, plus chain's 6 (128) and sync's 2
(125). Phase 2's 1212 -- its tree after the review, red: 0 in
2 min 57 s -- were an earlier whole run's 1070, plus chain's 122 and
the 20 sync gained for the event mapping (the run before the review
had chain at 105: 1195).
training and market SKIPped on that box, which had no libtorch and
no Cocolog Market checkout; the counts beside them are the previous
table's. That table had twenty cases, from before the nodes, and 582
checks, every one of them printed. Two of its counts have moved since:
crypto loads the seven node libraries too (71 to 78), and bench
checks 24 since its language pairs moved to cocolog's test/langs.pl
(the table's 30 was older than that move).
| case | checks | case | checks |
|---|---|---|---|
local |
1 | bond |
25 |
math |
29 | units |
19 |
crypto |
78 | training |
SKIP (17) |
params |
57 | spine |
16 |
btc |
60 | votes |
37 |
chain |
129 | secure |
17 |
sync |
125 | hub |
41 |
peers |
169 | token |
32 |
mempool |
137 | uniswap |
28 |
tutorials |
9 | uniswap-v3 |
61 |
wire |
1 | lending |
39 |
ledger |
25 | market |
SKIP (31) |
contracts |
30 | bench |
24 |
coco |
32 |
One test/prelude.pl carries what every case shares: iso/2, which is
one isolated proof — a fresh machine and a fresh store — with the
comparison inside it; want/2, which prints both values on a mismatch;
wire/4 and its relatives, which start a real cocolog against a shared
knowledge base; and library(os) for every question a shell used to
answer differently on Linux and macOS.
Most of a case runs in one process, and the cross-process claims still
spawn. iso/2 is what a check wants when it needs a clean slate —
bond.pl funds a genesis and bonds against it in twenty-one of its
twenty-five checks, and without a fresh store per check a slash would
land on a bond an earlier check had already taken. But half of this
repository's claims are about SEPARATE processes: one writes the
knowledge base and a second, which consulted nothing, reads it back. A
fresh machine in the same process cannot make that claim, so those
checks start real cocolog processes and always will — the three
authorities gossiping in ledger, the settlement in coco, the
unbonding that matures against the chain's height in bond, every bare
auditor in the file. Converting them would keep the suite green and
delete the proof.
Every node here reaches its chain through one dial string that
test/config.sh builds from coco.yaml's arrangement: block, so the
whole hub goes secure with a line:
ZIGURAT_TRANSPORT=tls ZIGURAT_CACERT=/etc/ssl/ca.crt sh test/run.shtcp is the binary protocol in the clear; tls is the same port
with ZiguratIP's SERVER/TLS_MODE: TRUE on the other end, because
TLS_MODE changes what is on 2160 rather than where it is. A client
certificate (ZIGURAT_CERT and ZIGURAT_KEY, both or neither) is
optional — SERVER/TLS_CLIENT_AUTH takes REQUIRED, OPTIONAL or NONE
— and mandatory for permissions: under
SECURITY/PERMISSIONS_MODE: TRUE a TLS peer without one is identified
with an empty permission set and reaches nothing, while a plain
connection is not identified at all and reaches everything. Turning TLS
on is what turns access control on.
It changes the link and not one verdict, and test/secure.pl is
where that is demonstrated rather than asserted. ledger, spine and
votes run again behind a TLS terminator, and every verdict line must
come back byte for byte identical:
| rung | consensus | verdicts | over TLS |
|---|---|---|---|
| 2 | library(poa) — proof of authority |
25 | identical |
| 5 | library(poh) — proof of history |
16 | identical |
| 6 | library(pos), library(bft) — stake and votes |
37 | identical |
All seventy-eight, including the three attacks that are supposed to succeed — ECDSA malleability, which buys nothing because a block's hash does not cover its signature; two valid spines from one genesis, which is what a clock is; and a grindable leader draw, an accepted trade inside a gated federation. A run where mallory suddenly failed to grind would be as much of a failure as one where a real attack got through.
That identity is not luck. Every law those rungs enforce is a law about content: a hash recomputed from the block's own fields, a signature checked against the author's published key, a tick count re-run, a quorum weighed against a stake table read out of rows. Not one of them asks who handed the bytes over.
Which is also the trap the case exists to close. An encrypted transport invites a node to treat an authenticated peer as a trusted one, so mallory arrives over a verified TLS connection to the very store the honest nodes use — at the transport layer exactly as authenticated as alice — and offers a block signed with her own real key. It is refused, for the reason it was always refused: she is not in the federation, and a handshake has no opinion about that.
Three more checks a plaintext run cannot make: plaintext against the TLS
port reaches no chain, so the terminator really is TLS; a node whose
ZIGURAT_CACERT names an unrelated authority reads zero blocks
rather than some; and it is told why by name — the refusal says
certificate, not read failed.
And the public audit plane goes through a tunnel too. The binary
port is the writers' road; the chain's public face is Zeytun, read-only
by construction, and behind a Cloudflare-shaped tunnel it is https-only.
So the same case stands a TLS edge in front of Zeytun and reads alice's
ledger through it both ways a public reader exists: library(curl)
fetches the pages from inside a query (curl_get with an https://
URL, the edge's certificate vouched for by name), and an --https
auditor warms the whole knowledge base through the edge, loads the
consensus rules from its own library path — never from the chain
being audited — and re-verifies every block. An auditor does not need
the writers' port, and that sentence is now tested rather than assumed.
A missing client certificate is not a failed handshake, and anything built on this should know it. Under TLS 1.3 the server does not examine what the client sent until the client has finished talking, so the connect SUCCEEDS and the refusal arrives as an alert on the first read. The property to check is never whether a peer connected — it is what the peer can reach.
The terminator is a rehearsal and says so, exactly as cocolog's own
test/zigurat-tls.sh does: turning TLS_MODE on for real means
restarting the shared server with credentials every other case would then
have to speak. What is proved here is the client half and the consensus
half; ZiguratIP's server side is ZiguratIP's suite's business.
modules/ the C halves: Cicili sources for the loadable modules,
one directory per group, each with a build.sh that
compiles them to library/*.so
modules/crypto/ keccak, secp256k1, sha256, sha512, ed25519, ripemd160,
blake2b -- and spine, rung 5's tick loop
modules/math/ u256: 256-bit arithmetic that raises rather than wraps
modules/btc/ the Bitcoin node's kernel: libbitcoinkernel bound as
predicates, built to library/btc.so
library/ THE LIBRARY PATH: the built .so's and the Prolog
libraries beside them. A caller cannot tell which of its
libraries are Prolog and which are compiled C, which is
the point -- btc_address.pl composes two of each, and
poh.pl is the layer over spine.so
coco.yaml the one declaration -- pillars, paths, the knowledge
base, the module list, the suite. Read by every script
main.pl the nodes' one entry point, from this root:
cocolog -s main.pl -- NODE COMMAND
nodes/ one main file per real chain a node follows --
bitcoin.pl, its libraries library/btc_*.pl
ledger/ rung 2: the PoA federation ledger -- the federation,
a node, the choreography, and mallory the criminal node
contracts/ rung 3: a contract is a predicate -- the sources
(honest and criminal), the node, the choreography.
token/ is ERC-20 and ERC-721, dex/ is Uniswap v2 and
v3, lending/ is Aave
training/ rung 4: training as settlement -- the task, the
worker, mallory the criminal worker
spine/ rung 5: the PoH spine -- the producer, the parallel
verifiers, and mallory attacking a clock
votes/ rung 6: PoS and BFT votes -- stake read off the chain,
quorum certificates, finality, and mallory INSIDE the
validator set
hub/ rung 7: the aggregator -- three chains under three
regimes, each publishing its own rules as entries on
itself, verified by a host that consulted none of them
market/ rung 12: the market node -- the pool's blocks sealed as
candles for Cocolog Market, the reasoning side in its
own repository; a README, a node and a run.sh
bench/ rung 8: the TPS harness -- the lanes, the six rules a
reading must pass to be printed, and mallory attacking
the measurement rather than the rules; languages.md
compares Python, Prolog and cocolog under the same
no-unprinted-numbers rule
docs/ diagrams worth keeping: seal-to-settlement.html traces
one payload through every gate, rungs 2 to 4;
tick-to-settlement.html does the same for rung 5,
and rung 6 twice over -- stake-to-settlement.html from
the stake's side, vote-to-settlement.html from the
vote's; rules-to-settlement.html for rung 7
-- and the nodes' documents: nodes.md the
architecture, bitcoin.md and bitcoin/PLAN.md the
Bitcoin node's manual and plan
test/ the arrangements that hold it GREEN, as cocolog
scripts over one prelude.pl -- run.sh drives them and
config.sh, sourced rather than run, reads coco.yaml
and builds the one dial string every node reaches its
store through; secure.pl re-runs rungs 2, 5 and 6
over TLS and requires the verdicts to be identical
tutorials/ the nodes' lessons, one per library and one per node,
every claim a must/3 -- test/tutorials.pl runs them
art/ the banner -- Coco, the engineer, one of the three
The layout grows a directory per rung as each rung is climbed; nothing is checked in before its GREEN line.
spine/ IS A RUNG, NOT A MODULE, and it is the one name in the tree
that is both — which is worth saying because the mistake is a natural one.
library(spine) is C, and its source has always been
modules/crypto/spine.cicili; spine/ is rung 5's choreography, the
same shape as ledger/, votes/, hub/ and training/ — a README, a
node, a mallory and a run.sh. The module is already where modules go.
Every one is reached the same way — use_module(library(Name)) — and
nothing at the call site says whether the answer came from C or from
clauses. That is the seam, not a detail of it.
COMPILED, from modules/:
library(u256) |
256-bit add, sub, mul, div, mod, muldiv, sqrt — none of them wrapping. cocolog's integers are 64 bits and wrap in silence: 1000000000000000000 * 997 answers 875820019684212736, so the first product a Uniswap swap computes at ordinary token scale is already a wrong number nobody was told about. These raise instead |
library(keccak) |
Ethereum's, with the 0x01 pad — not NIST SHA3 |
library(secp256k1) |
the curve: derive, verify, recover |
library(sha256), library(ripemd160) |
Bitcoin's, and the two halves of hash160 |
library(sha512), library(ed25519) |
RFC 8032, deterministic, byte for byte |
library(blake2b) |
Sui, Aptos, Polkadot, Cardano, Zcash |
library(spine) |
rung 5's tick loop, the event fold and the segment check |
library(btc) |
the Bitcoin node's kernel: Bitcoin Core's libbitcoinkernel bound as predicates — a block or a transaction parsed and checked, one input's Script verified; and the second grain, a ChainstateManager over a data directory: blocks and headers fed, framed block files imported or the node's own reindexed, the block tree and its blocks read back, the kernel's events queued for the view; and, against a kernel that carries the prune patch, the node pruned to Core's floor (btc_prune/1,2). Built by sh modules/btc/build.sh: it needs Cicili and a Core checkout at the pin, its kernel built shared — or a clone of the pin with the prune patch on top, built the same way |
CLAUSES, in library/:
library(bytes) |
hex text to byte lists and back |
library(base58), library(bech32) |
base58check; bech32, bech32m, segwit addresses |
library(eth) |
keccak + secp256k1: Ethereum addresses, who signed |
library(btc_address) |
sha256 + ripemd160 + base58 + bech32: Bitcoin's hash160, addresses and txids |
library(poa) |
rung 2: proof of authority, as rules |
library(contract) |
rung 3: the fence, scoped state, the call door |
library(settle) |
rung 4: the acceptance predicate over held-out data |
library(poh) |
rung 5: segments, parallel verification, the ledger seam |
library(pos), library(bft) |
rung 6: stake as a query and the leader draw; votes, quorum certificates, the lock, the evidence |
library(hub) |
rung 7: rules as entries, the namespace, the anchor, the bridge |
library(tickmath) |
prices as ticks, ticks as square roots — v3's arithmetic |
library(btc_params) |
the Bitcoin node: Core's chain parameters as facts, five networks, each cited to chainparams.cpp at the pin |
library(btc_view) |
the node's knowledge-base view: a row per header keyed by an integer, the verdict a status column, full and light |
library(btc_sync) |
the headers-and-blocks download policy, and what each mode serves |
library(btc_peers) |
the P2P wire format as a grammar both ways, the handshake as a state machine, the limits as facts |
library(btc_relay) |
headers, compact blocks, the relay limits |
library(btc_mempool) |
Core's mempool policy as integer clauses: vsize, fee rates, dust, standardness, replacement, clusters |
library(btc_rpc) |
Core's JSON-RPC as httpd pages, with the answers behind a provider seam |
coco.yaml is where the two lists actually live, and both build.sh and
the suite read them from there: adding a module is adding a line, and the
suite then proves every one of them LOADS. A .pl with a syntax error in
a clause nothing calls is invisible until the day something calls it.
$COCOLOG_LIBRARY is two directories — The Coco's library/, then
cocolog's — so everything cocolog ships as a loadable library is reachable
from a contract or a node without anything being copied here:
library(tcp), library(http), library(httpd) |
sockets, HTTP/1.1 as a grammar, and a server whose pages are clauses |
library(thread) |
threads that share nothing, channels that copy |
library(json), library(xml), library(html) |
a term as a document and a document as a term, both ways |
library(curl) |
an HTTP client |
library(bigint), library(torch) |
arbitrary-precision integers; libtorch |
It is a list, and you can add to it. test/config.sh APPENDS what you
export rather than replacing it, so a directory of your own goes beside
the two that have to be there:
COCOLOG_LIBRARY=/opt/my/modules sh test/run.shOurs come first, on purpose: a suite that let somebody else's
library(poa) win would be green about somebody else's code.