DEV Community: Malek

Turn a callback WebSocket feed into a Kotlin Flow with callbackFlow (with a live feed to try it on)

Malek — Fri, 13 Nov 2026 04:08:49 +0000

Most APIs that push data hand you a callback. Kotlin code would rather have a Flow. callbackFlow is the bridge, and
it is short, but two details decide whether your version leaks sockets: where the cleanup goes, and whether the Flow is
cold.

To have something real to wrap, this article uses a public blockchain network that emits a block every 15 seconds over
a WebSocket. It needs no API key and no account, so the code runs as written. You do not need to know anything about
the chain; treat it as a server that pushes one event every 15 seconds.

The project

build.gradle.kts:

plugins {
    kotlin("jvm") version "2.2.0"
    application
}

repositories { mavenCentral() }

dependencies {
    implementation("org.janzeer:janzeer-sdk-client:0.1.7")
    implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.10.2")
}

kotlin { jvmToolchain(17) }
application { mainClass.set("MainKt") }

The callback API

The SDK's WebSocket client looks like most push clients:

val ws = JanzeerRpcWs.connect("https://explorer.janzeer.org")
val subscription = ws.subscribeNewBlocks(NewBlocksParams()) { block -> println(block.height) }
// … later
subscription.unsubscribe()
ws.close()

Three things to manage by hand: the socket, the subscription, and the moment you stop caring.

The Flow

import kotlinx.coroutines.channels.awaitClose
import kotlinx.coroutines.flow.Flow
import kotlinx.coroutines.flow.callbackFlow
import kotlinx.coroutines.flow.map
import kotlinx.coroutines.flow.take
import kotlinx.coroutines.runBlocking
import kotlinx.coroutines.withTimeout
import org.janzeer.sdk.rpc.BlockView
import org.janzeer.sdk.rpc.JanzeerRpcWs
import org.janzeer.sdk.rpc.NewBlocksParams

const val NODE = "https://explorer.janzeer.org"

/** Every newly committed block as a cold Flow: the socket opens on collect and closes when the collector stops. */
fun newBlocks(node: String): Flow<BlockView> = callbackFlow {
    val ws = JanzeerRpcWs.connect(node)
    val subscription = ws.subscribeNewBlocks(NewBlocksParams()) { block -> trySend(block) }
    awaitClose {
        subscription.unsubscribe()
        ws.close()
    }
}

fun main() = runBlocking {
    var previous: Long? = null
    withTimeout(90_000) {
        newBlocks(NODE)
            .map { block ->
                val gap = previous?.let { (block.timestamp - it) / 1000.0 }
                previous = block.timestamp
                "#${block.height}  ${block.hash.take(12)}…  gap=${gap ?: "-"}s"
            }
            .take(3)
            .collect(::println)
    }
}

./gradlew run printed this on a real run:

#239312  126c6f6b7094…  gap=-s
#239313  c93fbe16e199…  gap=15.012s
#239314  02364077a56f…  gap=14.999s

The two details

Cleanup belongs in awaitClose, and nowhere else. awaitClose suspends the builder until the collector goes
away, then runs its block. "Goes away" covers every case at once: take(3) finished, the collecting coroutine was
cancelled, withTimeout fired, or an exception came from downstream. Here it unsubscribes first, so the server is told,
and then closes the socket. If you forget awaitClose, callbackFlow throws at runtime to tell you so, which is one of
the kinder errors in the coroutines library.

Open the resource inside the builder, so the Flow is cold. JanzeerRpcWs.connect is called inside callbackFlow,
not outside it. Calling newBlocks(NODE) therefore opens nothing; the socket exists only while somebody collects, and
two collectors get two sockets. If you want one shared socket for many collectors, add shareIn at the call site, where
the scope that owns the socket is visible:

val shared = newBlocks(NODE).shareIn(scope, SharingStarted.WhileSubscribed(5_000), replay = 1)

WhileSubscribed closes the socket when the last collector leaves, through the same awaitClose.

`trySend`, not `send`

The callback runs on the WebSocket's thread, which is not a coroutine, so it cannot call the suspending send.
trySend never blocks that thread. With the default buffer it drops an element only if the collector is 64 events
behind; at one event every 15 seconds that does not happen. For a fast feed, pick the policy on purpose:
.buffer(Channel.CONFLATED) to keep only the newest, or a larger buffer to keep all.

A timeout around the collector

withTimeout(90_000) is there because a push feed can go quiet without closing. Six block intervals without an event
means something is wrong, and a timeout turns "hangs for ever" into an exception you can log. The timeout cancels the
collector, and awaitClose still runs.

Where to go next

The same wrapper works for the address feed: ws.subscribeAddressActivity(listOf(address)) { event -> trySend(event) }.
The SDK is on Maven Central as org.janzeer:janzeer-sdk-client, Apache-2.0; source and examples: https://github.com/janzeerOrg/janzeer-sdk-kotlin.
The same feed drawn live in a browser: https://explorer.janzeer.org/workflow.

Follow a live blockchain from Python with asyncio and 20 lines of code

Malek — Thu, 12 Nov 2026 21:50:21 +0000

Most asyncio tutorials fake their data source with asyncio.sleep. This one uses a real feed: a public blockchain
network that produces a block every 15 seconds and pushes each one over a WebSocket. There is no API key, no account
and no rate plan, so everything below runs as written.

The network is Janzeer, a small Layer-1 chain. You do not need to know anything about it to follow along; treat it as
a server that emits one JSON event every 15 seconds.

Set up

python -m venv .venv && . .venv/bin/activate
pip install "janzeer-sdk[ws]"

Python 3.10 or newer. The [ws] extra pulls in websockets.

1. Print every new block

import asyncio
from collections import deque

from janzeer import JanzeerRpcWs

NODE = "https://explorer.janzeer.org"


async def main() -> None:
    blocks: asyncio.Queue[dict] = asyncio.Queue()
    gaps: deque[float] = deque(maxlen=20)
    last_ts = None

    async with await JanzeerRpcWs.connect(NODE) as ws:
        sub = await ws.subscribe_new_blocks(blocks.put_nowait)
        try:
            for _ in range(3):
                block = await asyncio.wait_for(blocks.get(), timeout=60)
                ts = block["timestamp"] / 1000
                if last_ts is not None:
                    gaps.append(ts - last_ts)
                last_ts = ts
                avg = sum(gaps) / len(gaps) if gaps else 0.0
                print(f"#{block['height']}  {block['hash'][:12]}…  txs={block['transactionsCount']}  avg gap={avg:.1f}s")
        finally:
            await sub.unsubscribe()


asyncio.run(main())

Output from a real run:

#239213  4e0054fc98db…  txs=1  avg gap=0.0s
#239214  f92c4915328c…  txs=1  avg gap=15.0s
#239215  4e5cf64b2332…  txs=1  avg gap=15.0s

Three things in there are worth copying into your own code.

A queue as the callback sink. subscribe_new_blocks takes a plain callback. Passing blocks.put_nowait turns the
push feed into something you can await, and keeps your processing out of the WebSocket reader. If your handler is
slow, the queue absorbs the burst; the socket keeps being read.

A timeout on every wait. asyncio.wait_for(blocks.get(), timeout=60) is the difference between a script that
reports "the feed went quiet" and one that hangs for ever. Sixty seconds is four block intervals here.

try / finally around the subscription. The async with closes the socket, and the finally unsubscribes
first, so the server is told before the connection drops. On Ctrl-C, asyncio.run cancels main, and both still run.

2. Watch an address

The same feed can filter by address. A validator's wallet is a convenient target because it receives a block reward
every few minutes:

import asyncio

from janzeer import JanzeerRpcWs, format_jnz

NODE = "https://explorer.janzeer.org"
WATCH = ["0x038cba8510852bd5ce07166427d16cf81b6fb849"]


async def main() -> None:
    events: asyncio.Queue[dict] = asyncio.Queue()
    async with await JanzeerRpcWs.connect(NODE) as ws:
        await ws.subscribe_address_activity(WATCH, events.put_nowait)
        event = await asyncio.wait_for(events.get(), timeout=300)
        tx = event["transaction"]
        print(f"block {event['blockHeight']}: {tx['type']} of {format_jnz(tx['amount'])} ({tx['status']})")


asyncio.run(main())

block 239222: reward of 10 JNZ (FINAL)

The status is FINAL in the very first notification. On this network a committed block cannot be reorganised, so
there is no "wait for six confirmations" loop to write. That removes a whole class of state from the client.

Amounts arrive as decimal strings and format_jnz prints them. The SDK never converts money to float; if you do
arithmetic on amounts, use its helpers or decimal.Decimal.

3. Run several things in one loop

Because the clients are ordinary asyncio objects, combining them is asyncio.gather or a TaskGroup. This reads the
chain's current height over HTTP while the WebSocket subscription is open:

import asyncio

from janzeer import AsyncJanzeerRpc, JanzeerRpcWs

NODE = "https://explorer.janzeer.org"


async def main() -> None:
    async with AsyncJanzeerRpc(NODE) as rpc, await JanzeerRpcWs.connect(NODE) as ws:
        blocks: asyncio.Queue[dict] = asyncio.Queue()
        await ws.subscribe_new_blocks(blocks.put_nowait)
        tip, block = await asyncio.gather(rpc.get_tip(), asyncio.wait_for(blocks.get(), 60))
        print("tip over HTTP:", tip["height"], "| next block over WebSocket:", block["height"])


asyncio.run(main())

Both async HTTP clients accept an http= argument, so several clients can share one httpx.AsyncClient and its
connection pool. The SDK's asyncio guide
covers that, and was written by an outside contributor last week.

What happens when the connection drops

The WebSocket client reconnects by itself and resumes a block subscription from the last block it delivered, so a
restart of your Wi-Fi does not lose or repeat blocks. If you need the same guarantee across restarts of your own
process, store the last height you handled and pass it back as from_height when you subscribe; the node replays from
there before following the tip.

Where to go next

Sending a signed transfer and waiting for it to become final is 15 more lines: examples/07_async_quickstart_transfer.py.
The package is on PyPI as janzeer-sdk, typed (py.typed), Apache-2.0.
The live view of the same feed, drawn in a browser: https://explorer.janzeer.org/workflow.

أرسل أول معاملة على بلوكتشين «جنزير» بلغة بايثون في أقل من عشرين سطرًا

Malek — Sat, 07 Nov 2026 14:07:16 +0000

⁧لماذا هذا المقال؟⁩

⁧معظم سلاسل الكتل العامة توثيقها بالإنجليزية فقط، ومعظم أدوات التطوير فيها تفترض أنك تعرف الإيثيريوم مسبقًا. «جنزير» (Janzeer) سلسلة كتل من الطبقة الأولى أطلقتُ شبكتها الرئيسية في الأول من تشرين الأول/أكتوبر 2026، وفيها أمران يهمّان المطوّر العربي تحديدًا: التوثيق الرسمي كله بالعربية والإنجليزية معًا (الورقة البيضاء، دليل المطوّر، مرجع الواجهة)، ومجموعات تطوير رسمية بخمس لغات: بايثون، وتايب سكريبت، ودارت، وكوتلن، وغو، كلها مفتوحة المصدر برخصة Apache-2.0.⁩

⁧في هذا المقال نستخدم بايثون. في النهاية ستكون قد قرأت بيانات السلسلة، وأنشأت محفظة على جهازك، وأرسلت معاملة، وانتظرت حتى صارت نهائية — كل ذلك من سطر الأوامر.⁩

⁧ما الذي يميّز «جنزير» بكلمات قليلة؟⁩

⁧لا تجميد (staking) ولا تفويض: من يريد التحقق من الكتل يشغّل عقدة ويدفع وديعة لمرة واحدة قدرها 2000 JNZ، ثم يكسب مكافأة الكتل التي ينتجها. لا تصويت ولا لجان.⁩
⁧نهائية في كتلة واحدة: الكتلة كل 15 ثانية، وتُعتمد بتوافق BFT من مرحلتين (PREPARE ثم COMMIT). الكتلة المعتمدة نهائية؛ لا يوجد «عدد تأكيدات».⁩
⁧معروض ثابت: 100 مليون JNZ، لا سكّ بعدها. مكافآت الكتل تُدفع من الخزانة.⁩
⁧غير حافظ (non-custodial) بالتصميم: المفاتيح لا تغادر جهازك أبدًا، والعقدة لا تفعل سوى التحقق.⁩
⁧الشبكة صغيرة وجديدة: سبعة مدقّقين نشطين اليوم، وقرابة مئتي ألف كتلة. أقول هذا بوضوح حتى لا يتوقع أحد شبكة بحجم الكبار.⁩

⁧ما الذي تحتاج إليه؟⁩

⁧بايثون 3.10 أو أحدث على لينكس أو ماك أو ويندوز (العجلات جاهزة، لا حاجة إلى مترجم).⁩
⁧حزمة janzeer-sdk من PyPI.⁩
⁧لقراءة بيانات السلسلة لا تحتاج إلى شيء آخر. لإرسال معاملة تحتاج إلى بضع وحدات JNZ في محفظتك؛ أسهل طريقة اليوم هي لعبة jPong داخل تيليغرام (التي تدفع لمن يلعب) أو أن يحوّل لك أحدهم. لا يوجد صنبور (faucet) على الشبكة الرئيسية.⁩

⁧الخطوة 0: التثبيت⁩

pip install "janzeer-sdk[ws]"

⁧اللاحقة [ws] تضيف دعم WebSocket للاشتراكات الحيّة؛ احذفها إن لم تكن تحتاج إليها.⁩

⁧الخطوة 1: اقرأ السلسلة (بلا مفاتيح وبلا رصيد)⁩

from janzeer import JanzeerClient, JanzeerRpc

NODE = "https://explorer.janzeer.org"
client = JanzeerClient(NODE)      # REST تحت ‎/api/v1
rpc = JanzeerRpc(NODE)            # JSON-RPC تحت ‎/rpc

info = client.info()
print("إصدار العقدة:", info["version"], "| الشبكة:", info["networkId"])
tip = rpc.get_tip()
print("آخر كتلة:", tip["height"], tip["hash"])

⁧العقدة العامة explorer.janzeer.org هي نفسها التي يعمل عليها المستكشف. كل نتيجة تعود كقاموس أو قائمة بأسماء الحقول التي تستخدمها العقدة نفسها (blockHeight وsenderAddress وهكذا)، فلا توجد طبقة أسماء ثانية عليك حفظها.⁩

⁧الخطوة 2: أنشئ محفظة على جهازك⁩

from janzeer import Account, mnemonic

words = mnemonic.generate(128)            # 12 كلمة وفق BIP39
me = Account.from_mnemonic(words)
print(words)                              # احفظها في مكان آمن؛ من يملكها يملك المحفظة
print(me.checksum_address)

⁧هذا كل ما يحدث: اشتقاق محلي. لم تُرسل أي كلمة إلى أي خادم. (العنوان الناتج يبدأ بـ 0x وطوله 20 بايتًا، لكنه ليس عنوان إيثيريوم: الاشتقاق مختلف.)⁩

⁧الخطوة 3: أرسل معاملة وانتظر النهائية⁩

from janzeer import Account, JanzeerClient, JanzeerRpc, TxBuilder, format_jnz, wait_for_finality

NODE = "https://explorer.janzeer.org"
client, rpc = JanzeerClient(NODE), JanzeerRpc(NODE)
me = Account.from_mnemonic("…الكلمات الاثنتا عشرة من الخطوة السابقة…")

print(me.checksum_address, format_jnz(client.balance(me.address)), "JNZ")

tx = me.sign_tx(TxBuilder.transfer(
    sender=me.address,
    to="0x598b1301acef3baba6ce25e38dd17b723f7b98b1",
    amount="1.25",                      # نص عشري، ليس float
    data="مرحبا من بايثون",
    nonce=client.nonce(me.address),
    network_id=client.info()["networkId"],
))
client.submit(tx)                       # HTTP 201 أو خطأ ذو نوع محدد
print("أُرسلت:", tx.hash)

final = wait_for_finality(rpc, tx.hash) # فتحة أو فتحتان من 15 ثانية
print("نهائية في الكتلة", final["blockHeight"])
print("https://explorer.janzeer.org/tx/" + tx.hash)

⁧هذه هي عملية التكامل كاملة: اشتقاق ← رقم تسلسلي (nonce) ← بناء ← توقيع ← إرسال ← انتظار. حين تعود wait_for_finality تكون المعاملة في كتلة معتمدة، أي نهائية. افتح الرابط الأخير في المستكشف وسترى المعاملة ورسالتها.⁩

⁧لاحظ ثلاثة أشياء:⁩

⁧المبلغ نص "1.25" وليس 1.25. المكتبة ترفض float في كل مكان وترمي TypeError، لأن 0.1 لا يُمثَّل تمثيلًا دقيقًا بالثنائي، والدفع يجب ألّا يعتمد على طريقة طباعة الأعداد العشرية. المقبول: نص عشري، أو int للوحدات الكاملة، أو decimal.Decimal.⁩
⁧network_id يدخل في بصمة المعاملة، فمعاملة موقّعة لشبكة الاختبار لا يمكن إعادة تشغيلها على الشبكة الرئيسية.⁩
⁧الأخطاء مصنّفة: TxRejectedError وNonceMismatchError وRateLimitedError وغيرها، فبرنامجك يعرف ماذا حدث بدل أن يفسّر نصًا.⁩

⁧الخطوة 4 (اختيارية): شاهد الكتل الجديدة حيّة⁩

import asyncio
from janzeer import JanzeerRpcWs

async def main():
    ws = await JanzeerRpcWs.connect("wss://explorer.janzeer.org/rpc/ws")
    tip = await ws.get_tip()
    await ws.subscribe_new_blocks(
        {"fromHeight": tip["height"]},
        lambda b: print("كتلة", b["height"], b["hash"][:12], "معاملات:", b["transactionsCount"]),
    )
    await asyncio.sleep(60)
    await ws.close()

asyncio.run(main())

⁧(المثال الكامل مع المعالجة الصحيحة للإنهاء موجود في examples/06_watch_new_blocks.py داخل المستودع، وقد كتبه مساهم من خارج المشروع.)⁩

⁧ماذا تقرأ بعد ذلك؟⁩

⁧دليل المطوّر بالعربية: https://janzeer.org/docs — كل نقطة نهاية REST وكل دالة JSON-RPC، بالعربية والإنجليزية.⁩
⁧المستودع: https://github.com/janzeerOrg/janzeer-sdk-python — ستة أمثلة جاهزة، وقضايا موسومة good first issue لمن يريد المساهمة.⁩
⁧المجموعات الأخرى: تايب سكريبت (npm: janzeer-sdk)، دارت (pub.dev: janzeer_sdk)، كوتلن (Maven Central: org.janzeer)، غو.⁩
⁧المستكشف: https://explorer.janzeer.org — وفيه صفحة «كيف تعمل السلسلة» برسم متحرك حيّ.⁩
⁧القناة: https://t.me/janzeerorg — كل إعلان بالعربية والإنجليزية.⁩

Three ways a BFT chain goes quiet — a week of incidents on a small Layer-1

Malek — Wed, 28 Oct 2026 04:36:36 +0000

I run a small Layer-1 called Janzeer: stake-free BFT, 15-second slots, two voting rounds (PREPARE and COMMIT), finality in one block, a 2f+1 quorum over the epoch's validator set. Mainnet started on 2026-10-01. In the last week of October the network had six validators: four project nodes on one 2 GB VPS, one Raspberry Pi 3 at my home, one balenaFin at a friend's. Quorum was five of six.

That week the chain stopped twice for about four hours each, and two validators went silent for four and thirteen hours without a single log line. None of it lost or reverted a block. All of it was our own code. Here is what happened, in the order we understood it, with block heights and times so you can check the explorer.

Incident 1 — one validator never gives up a question (F-052)

24 October, 23:20 UTC, tip #135,855, four hours.

Finality needs 5 of 6 votes. The Pi had been quiet since 19:06 UTC: it had seen a live block ahead of its tip, flipped itself to PROCESSING and asked its peers "do you know my tip?". Nobody's answer arrived, and the code had no bound on that wait. Eight hours in PROCESSING, during which every block, vote and certificate is dropped by design (a node that does not trust its own ledger must not vote). When the balenaFin went offline at 23:20 UTC, four voters remained and no block could reach the COMMIT quorum.

The four VPS nodes were healthy and proposed on every slot. A restart of the Pi restored the fifth vote; the chain resumed within one slot.

Root cause. The availability round had a retry timer that was replaced instead of cancelled and replaced when a new request went out, so the re-check's own request was never re-sent, and nothing ever returned the node to SYNCHRONIZED.

Fix (0.1.9). A TipCheckWatch bounds the round: log the first retry, then once a minute, and after 120 seconds give up, return to SYNCHRONIZED, keep asking quietly. The next live block ahead of the tip re-triggers a clean check.

Incident 2 — one vote freezes everybody (F-053)

25 October, 06:21 UTC, tip #136,455, four hours.

This one was different, and it took longer to see because every node looked fine. All six validators were SYNCHRONIZED at the same tip, no node logged anything, restarting the Pi changed nothing, rebooting it changed nothing. The chain simply did not move.

Root cause. Slot bookkeeping. A vote or certificate carried a slot number, and the handler moved the node's "current slot" counter to that number before checking the signature or the sender's membership. One vote with a slot number far in the future, from a validator whose clock had jumped at boot, moved every project node's counter forward. From then on each node built its own block, called enterSlot(now), got false because "now" was below the poisoned counter, and dropped its own block before broadcasting it. No gossip, no log line, poison only in memory. The fix was already written the night before from code reading; the live network proved it the next morning.

Fix (0.1.9). Verify first, then move: a vote or certificate must carry a valid signature from an active validator and must sit within one slot of the local clock; a node whose counter ran ahead of its clock heals itself. Implausible votes are logged with their sender.

Our diagnostic rule from this day: every validator SYNCHRONIZED and silent means slot poisoning, restart the proposers; one board PROCESSING means a stuck re-check, restart that board.

Incident 3 — a race that only fast links can lose (F-056)

25 October, 14:02 UTC, node five, four hours. 26 October, 18:10 UTC, the Pi, thirteen hours.

We had added a fifth project node that week. At 14:02 UTC I registered it as a validator. The block carrying its registration, #137,271, was the last block it committed for four hours. It stayed healthy by every health check and wrote nothing to its log. A systemctl restart did not help. A stop, a pause, and a start did.

Two defects chained.

The sweep. When a node commits a block that registers its own key, it switches to full sync mode and re-validates the last two epochs, about 34,000 blocks. It did this on the consensus thread, inside the ledger write lock, even though it already was in full mode. Eighty-six seconds frozen, every peer channel stalled. Every validator we had ever registered had paid this at its registration; on a 1 GB board it is twenty minutes, and nobody had connected the dots.

The race. After the sweep the node was behind, so it ran a tip re-check: send "do you know my tip?" to the peers, then arm the retry loop. On the same VPS the peers answer in under a millisecond. The sync thread had already started a catch-up session and armed the session's own page timer when the caller finally executed future = startRequestScheduler(...): that assignment cancelled the session's timer and installed a loop that returns silently while a session exists. The first page request had gone out on a channel still re-handshaking after the stall and was lost. Nothing would ever re-send it.

// before (0.1.9): request first, arm second — an answer can overtake the arming
status = PROCESSING
checkBlock(block, loud = false)                                   // sends to every promoter peer
future = requestRetryScheduler.startRequestScheduler(future) {   // cancels whatever `future` is NOW —
    tipCheckRetry(block)                                          // including a session's page timer
}

// after (0.1.10): the whole round runs on the sync thread, arm first, send second.
// Responses are handled on that same single thread in arrival order, so none can overtake it.
syncExecutor.execute {
    tipCheck.start(now)
    future = requestRetryScheduler.startRequestScheduler(future) { tipCheckRetry(block) }
    checkBlock(block, loud = false)
}

Why had this never shown on the home boards? Their answers take tens of milliseconds, so the arming always won. It finally bit the Pi on 26 October for a different reason: a bad power supply. The board reported under-voltage thousands of times per boot, the CPU was throttled, and a garbage-collection pause of a few tens of milliseconds between those two statements was enough. The Pi lost a block in a power glitch, re-checked its tip, lost the race, lost the page on a flaky link, and sat for thirteen hours. Healthy, silent, not producing.

And the restart-versus-stop mystery? Pure timing. restart ran the first re-check nine seconds after boot, when the peer channels were still handshaking, and lost the race again. stop then start ran it fourteen seconds after boot on settled channels.

Fix (0.1.10). Arm on the sync thread before sending; a retry period that finds a live session re-requests the outstanding page instead of returning; the self-registration switch is a no-op when the mode is unchanged and otherwise runs after the commit, off the consensus thread; every catch-up session start logs one line. The last point matters most: the thing that made this bug expensive was not the race, it was the silence.

What we changed in how we work

Silence is a symptom. Every wait in the sync path now has a bound and a log line at the bound. A node that is PROCESSING must be able to explain why in its own journal within two minutes.
Serialize anything that can lose a race against a sub-millisecond peer. The sync thread already existed as the single-flight owner of catch-ups; the re-check's arming simply was not on it.
Hash, do not download. GitHub's release API now returns a server-side digest per asset; we compare it with the signed SHA256SUMS instead of pulling 320 MB back over a 1 Mbit/s uplink.
Read the hardware. vcgencmd get_throttled on a Raspberry Pi should read 0x0. Ours read 0x50005. Half of incident 3 was a power supply.

Everything above is public: the releases with signed checksums are on GitHub, the chain is on the explorer, the numbers on the transparency page come straight from the ledger, and every incident, including these four, is kept on the incidents page with its finding and the release that fixed it.
If you run distributed systems and see a hole in the reasoning, I would like to hear it.

A Raspberry Pi 3 as a mainnet validator — what a 1 GB board teaches a blockchain node

Malek — Mon, 19 Oct 2026 05:06:53 +0000

I run a small Layer-1 called Janzeer: stake-free BFT, 15-second slots, two voting rounds, finality in one block. The four
founding validators live on one 2 GB VPS, and I wrote about that box last week. This post is about the fifth validator.
It is a Raspberry Pi 3 Model B from 2016 — four Cortex-A53 cores at 1.2 GHz, 1 GB of RAM of which 905 MB are usable, a
USB disk, and 2.4 GHz Wi-Fi in a flat with thick walls. It has produced blocks on mainnet since 2026-10-15, and finding
out what it could not do fixed seven bugs in the node that four comfortable servers had never shown. No token talk, as
before; the coin is not on any exchange.

Why bother

The founding validators are meant to phase out. A chain whose only validators are the project's own servers is a
database with extra steps, so the active set has to be reachable for people who own ordinary hardware. If the node cannot
run on the cheapest 64-bit board in the drawer, over the Wi-Fi it happens to have, the "anyone can validate" line is
marketing. The Pi was the cheapest way to find out whether it was true. It was not, at first.

Getting a native image onto arm64

The node is a Spring Boot application in Kotlin, shipped as a GraalVM native image: no JDK on the board, one 80 MB
tarball, a 30-second boot on the Pi (3 seconds on the VPS). Building that image for arm64 was the first lesson.
native-image needs about 9 GB of heap for this project, which rules out building on the Pi itself. I built it in an
emulated aarch64 virtual machine on my desktop: 2 h 45 min per build, against 6 minutes native on x86-64. It works, and
it is the reason arm64 releases ship a few hours after the others. A rented arm64 VM would do it in minutes; I have not
needed one yet.

The image needs the same discipline on arm64 as anywhere else: every class the wire codec instantiates by reflection is
registered by hand, Hibernate's bytecode provider is off, the heap is capped. On this board the cap is -Xmx384m, and the
process sits at about 370 MB resident with the chain fully synced.

What the board found in the node

Each of these is a numbered finding in the project's test log. All are fixed in the current release, 0.1.7, and the
public nodes run it.

A restart during the first sync killed the sync thread. Restarting a node that had been staging blocks for an hour
left it "PROCESSING" for ever: the new sync session cleared the staging table through the ORM, which loaded all 287 MB of
staged rows as entities into a 256 MB heap. The sync thread died of the out-of-memory error and nothing noticed. The
clear is one bulk DELETE now, every task on the sync thread runs under a guard that turns an escaped error into a
restart of the sync, and an out-of-memory error ends the process so the service manager brings it back.

H2 scales its in-memory row limit with the heap. With 1 GiB of heap, H2 keeps 40,000 rows of a result in memory
before spilling to disk; at -Xmx256m that is 10,000 rows. The node's tip lookup, run on every commit, was a union over
all blocks. The moment the chain passed block 10,000, every commit wrote a temporary file first. Sync pace on a 1 GB
board fell from 400–660 blocks per minute to 28, at exactly that height. Nobody had seen it, because the servers had the
heap. The lookup is now an indexed top-row read per concrete table instead of the union, and the board commits at the
pace of its disk again.

The staging-table wipe spilled 405 MB into /tmp, which on Raspberry Pi OS is RAM. A 1 GB board with 405 MB of
temporary database file in its RAM does not survive. The launcher now points the JVM's temp directory at the data disk.

Pages that took longer than 10 seconds to arrive were thrown away. Sync fetches blocks in pages of 200, about 330 KB
each. On this Wi-Fi, one page from one peer takes 15–20 seconds. The decoder treated any message older than 10 seconds
as stale and dropped it, a 10-second timer asked a second peer for the same page, and each late duplicate triggered yet
another request. Three servers streamed the same pages to the Pi at 25 KB/s each, and it staged one page a minute.
Block pages are now exempt from the staleness check, a request is not repeated while bytes are still arriving, and a
late duplicate is ignored quietly. Staging went from 100 to 800–880 blocks per minute on the same link.

A validator one block behind downloaded 200 blocks to get it back. Slot ownership rotates, so this node's turn
comes every 75 seconds. Missing one live block, which happens on Wi-Fi, flipped it to catch-up mode, and catch-up asked
for the top page of the epoch: 330 KB, 15 seconds here, exactly one slot. By the time the page landed, the node was one
block behind again. It could sit in that loop for twenty minutes, producing nothing while reporting itself healthy. The
server now remembers the requester's tip from the availability handshake that precedes every catch-up and serves only the
blocks above it. A one-block catch-up is now 2–10 seconds, and the Pi makes its next slot.

A lost page request could leave a node "processing" for ever, silently. The waiting logic treated any bytes on the
channel as "the page is still streaming". Live blocks and votes are bytes too. A page request lost when a connection
dropped and redialed was never re-asked, and the node sat there for 75 minutes without a single log line. The wait is now
bounded whatever else flows on the channel, the request is re-sent to another peer, and the node says so in the log.

A lagging validator proposing with a stale tip showed up as an ERROR on everybody else's node, and paged the
operator. It is a normal event on a slow link: the proposal is dropped, the slot stays empty. It is logged as what it is now.

None of these were visible on four servers with 1 Gbit links and 2 GB each. The Pi found all of them in nine days.

What the board taught the operator

The code was half of it. The other half had nothing to do with the node.

Power. The first week's reboots were brown-outs. A phone charger runs a Pi 3 at idle and drops it under sync load.
The kernel counts under-voltage events; mine logged 2,191 of them in twelve hours before I bought the official supply with
its own short cable. Any mystery reboot on a Pi is the power until proven otherwise.

No real-time clock. After a power cut the Pi boots with its clock minutes behind until NTP steps it. The node will
not produce without a trusted clock, which is correct, but it also means the log timestamps around a boot are wrong, and
I lost an hour to that once.

Wi-Fi. Today I changed the Wi-Fi password for two hours and changed it back. The Pi never rejoined. NetworkManager
treats a run of authentication failures as wrong secrets and stops auto-connecting until something re-activates the
connection; a reboot does, three hours later. The validator missed every one of its slots meanwhile, and the chain carried
on without it, which is the point of a 2f+1 quorum. The board now has a two-minute watchdog timer that re-activates the
connection when it is not up, and a persistent journal, because the volatile one took the evidence with it.

Unclean stops cost 20 minutes. The node skips its boot-time validation of the last two epochs when it finds the
marker it writes on a clean shutdown. A reboot that kills the process leaves no marker, and this board takes 22 minutes
to re-validate 34,000 blocks before it dials anyone. Stop the service before you pull the plug.

Being late is not being slashed. The Pi's seat became active while it was still syncing, so it was silent for its
first epoch and was dropped from the active set for the next one. It came back automatically the epoch after, deposit
untouched. A validator that misses a whole epoch sits one out; it is not punished for being slow, only for signing twice.

Where it stands

The Pi is one of five active validators. In the first 2,300 blocks of its first full epoch it produced 443 of its 460
slots. After today's incident it caught up 560 blocks in two minutes and produced the next slot it owned. Its block
reward goes to the wallet that registered it, like anyone else's.

The arm64 bundle is a signed download alongside Linux x86-64, Windows and an Arch package; installing it is a service
file and one tar. The deposit for a validator seat is 2,000 JNZ, and the project currently covers it for the first ten
outside operators (details on the validators page). If you have a 64-bit board, a proper power supply and a port you can
forward, you can hold a seat on a live BFT chain from your shelf. I would rather have your Pi in the set than my fifth server.

Explorer: https://explorer.janzeer.org
Validators: https://janzeer.org/validators
SDKs and wallet: https://github.com/janzeerorg

Running a BFT blockchain as one native binary on a 2 GB VPS — what broke and what held

Malek — Sat, 10 Oct 2026 21:09:42 +0000

I run a small Layer-1 called Janzeer: stake-free BFT, 15-second slots, two voting rounds, finality in one block. Mainnet went live on 2026-10-01. The whole network — four validator nodes, PostgreSQL, and a Telegram mini-game that pays players — runs on one 2 GB, single-core VPS. This post is about how that is possible and what went wrong on the way. No token talk; the coin is not on any exchange and that is not what this is about.

The constraint

The node is a Spring Boot application in Kotlin: Netty for P2P, JPA on PostgreSQL, a REST and JSON-RPC API, and it serves the explorer SPA. Four of those as JVMs would never fit in 2 GB with a database next to them. So every process is a GraalVM native image: a ~250 MB binary that boots in 3 seconds and is capped at -Xmx256m. The binary's pages are shared by the four processes, so the cgroup charge is about 200 MB per node. The game backend is a native image too. Peak memory of the whole box during a 6-hour rehearsal, with load: 933 MB.

Three rules keep the native image working, and each one was learned the hard way:

No @Lazy injections. A lazy CGLIB proxy cannot be generated in the image. ObjectProvider does the same job.
Every class that is instantiated reflectively must be registered. The wire codec builds messages by reflection. The tracing agent only sees the messages that happen to flow during the trace, so the hints are written by hand for every message type. The first image pushed no WebSocket notifications because the notification envelope was missing from the hints — Jackson serialized it fine on the JVM and silently failed in the image.
Hibernate's bytecode provider off (hibernate.bytecode.provider=none) and a capped DB pool. An image otherwise grows towards a share of physical RAM per process.

The 7-day acceptance test

Before going live, the public test network ran for a week with a monitor that scanned the logs for consensus errors, killed and relaunched nodes, and pushed load. Thirty-seven findings, all fixed before launch. The ones worth retelling:

Four nodes booting together all hit pool.ntp.org in the same instant. Two got no answer and waited the full 60-second retry before asking again. Slot ownership is clock-based, so a node without a trusted clock does not produce: 75 seconds of empty slots at every joint start. The fix is boring and effective: a jittered exponential retry, 5 s → 10 s → 20 s, capped at 60.

A node relaunched on its own database started two sync sessions at once when two peers answered its availability request, and committed a duplicated epoch genesis. Sync is now single-flight on one thread: the first answer starts the session, later answers are ignored, and a uniqueness constraint on block hash, height and epoch makes the duplicate impossible at the database level.

The periodic tip check, when it ran on validators, kept a stall alive forever. The check flips the node to PROCESSING, and a PROCESSING node drops every vote. Four anchors doing that in lock-step during a stall could never reach quorum again. Validators now catch up only through the live block that proves they are behind; the periodic check runs on watch-only nodes.

PostgreSQL enforces read-only transactions; H2 does not. The JSON-RPC send* methods ran inside a read-only transaction template. Every test passed on H2. PostgreSQL refused the first real write. Anything that touches transaction boundaries is now tried on PostgreSQL before it ships, and a test pins the transaction attributes of those methods.

The first live upgrades

Shipping to the box is one script: it stages the native binaries, launchers, the game and the website into a folder, verifies that no secret ever enters it, and a second script on the VPS installs files, renders systemd units and nginx vhosts, and restarts what changed.

The first upgrades restarted all four validators together. That cost about a minute of no blocks at first, then four minutes last week. The log showed why: at boot the node re-validated the last two epochs on disk — 17,000 blocks per epoch, 2.5 minutes on one core — while reporting itself as PROCESSING and not dialing anyone. Every restart paid that.

Two changes fixed it:

A clean-shutdown marker. At @PreDestroy the node writes the tip hash next to its config file. At boot it reads and deletes the marker; if the stored tip still matches, the blocks on disk were validated when they were committed and nothing changed since, so the sweep is skipped. A crash, an older build or a moved tip leaves no matching marker and the sweep runs as before. Restart time went from 2.5 minutes to 11 seconds.
Rolling restarts. The quorum is 3 of 4, so one node may be down. Slot ownership is round-robin, so a node restarted right after its own block has 60 seconds before its next turn. The deploy script now restarts one validator at a time, each right after it produced, and moves on only when it is back, synchronized and at the tip. It falls back to a joint restart only when the protocol version changed, because a node refuses a peer that speaks another version. The last upgrade: four nodes rolled, the chain never stopped, largest gap between blocks 15 seconds — one slot.

A detail that bit us once: right after a restart, the other nodes can report one peer fewer for a few seconds, because a fresh connection is registered on one side before the other. The first production roll stopped before the fourth node on that. The pre-check now waits up to 90 seconds for the network to settle.

What I would tell someone doing the same

The native image is worth it for small boxes, but treat the tracing agent's output as a supplement. Write the reflection hints for everything your codec or your JSON envelope touches.
Test your database semantics on the database you deploy. H2 in PostgreSQL mode is not PostgreSQL.
Measure boot. A node that is "up" in 3 seconds but busy for 3 minutes is down for 3 minutes.
Never restart a quorum together if you can avoid it. With round-robin slots and a 2f+1 quorum, a rolling restart timed after each node's own block costs zero blocks.
An alert bot that reports the symptoms of your own planned restart trains you to ignore it. Mute the transient symptoms for the planned window, never the real dangers.

The explorer has an animated page of the whole cycle, driven by the live chain, if you want to see the slots and votes move: https://explorer.janzeer.org/workflow. The SDKs (TypeScript, Dart, Kotlin, Python, Go) and the wallet are open source at https://github.com/janzeerorg; the node is a public download with a closed source for now.

DEV Community: Malek

Turn a callback WebSocket feed into a Kotlin Flow with callbackFlow (with a live feed to try it on)

The project

The callback API

The Flow

The two details

trySend, not send

A timeout around the collector

Where to go next

Follow a live blockchain from Python with asyncio and 20 lines of code

Set up

1. Print every new block

2. Watch an address

3. Run several things in one loop

What happens when the connection drops

Where to go next

أرسل أول معاملة على بلوكتشين «جنزير» بلغة بايثون في أقل من عشرين سطرًا

⁧لماذا هذا المقال؟⁩

⁧ما الذي يميّز «جنزير» بكلمات قليلة؟⁩

⁧ما الذي تحتاج إليه؟⁩

⁧الخطوة 0: التثبيت⁩

⁧الخطوة 1: اقرأ السلسلة (بلا مفاتيح وبلا رصيد)⁩

⁧الخطوة 2: أنشئ محفظة على جهازك⁩

⁧الخطوة 3: أرسل معاملة وانتظر النهائية⁩

⁧الخطوة 4 (اختيارية): شاهد الكتل الجديدة حيّة⁩

⁧ماذا تقرأ بعد ذلك؟⁩

Three ways a BFT chain goes quiet — a week of incidents on a small Layer-1

Incident 1 — one validator never gives up a question (F-052)

Incident 2 — one vote freezes everybody (F-053)

Incident 3 — a race that only fast links can lose (F-056)

What we changed in how we work

A Raspberry Pi 3 as a mainnet validator — what a 1 GB board teaches a blockchain node

Why bother

Getting a native image onto arm64

What the board found in the node

What the board taught the operator

Where it stands

Running a BFT blockchain as one native binary on a 2 GB VPS — what broke and what held

The constraint

The 7-day acceptance test

The first live upgrades

What I would tell someone doing the same

`trySend`, not `send`