建设中

本网站仍在建设中

基金会是公开地进行建设的。你在这里看到的内容是当前真实的情况,但尚未完成 — 请将其理解为我们今天所处的阶段,而非最终定论。

从现在到主网上线之间,内容会不断变化:措辞、结构、图片和数据都可能调整。部分页面目前是占位内容。凡以照片代表某个人物之处,所用均为图库图片,并非该人物本人。

更广泛的 ZooBC 生态系统是分阶段上线的。钱包、区块浏览器、社区论坛和社交渠道,会随着主网的临近逐一上线,本网站也会随之不断完善。

如果有哪里读起来不对劲、看起来有问题,或显得具有误导性,请告诉我们。现在的反馈,对我们来说比日后一个打磨光鲜的上线更有价值。

发送反馈

Node 0.5.2 and Wallet V1.78 follow a week of testing

Community reports led to specific fixes in Wallet V1.78 and node 0.5.2. Both TestNet chains were relaunched, several features are live chain-side, and work remains before MainNet.

作者:Roberto Capodieci · 发布于

A week of testing

Thanks to Nagi, Cebo, TeresFi, Otto Graf and everyone else who filed reports, tested fixes and came back to confirm them. Nagi's reports in particular broke ZooBC more than once — which is exactly what we want to happen now rather than after MainNet.

Twelve forum reports were fixed, verified and closed on 26 September: six on the node and gateway, six on the wallet. An overnight node test on 25 September produced a further 37 fixes; those overlap with the forum reports, so the two numbers shouldn't be added together.

More faults will surface as account groups, escrow, survival deposits and the other new transaction types come into use. That's expected.

Forum reports closed

Node and gateway — topics 278, 283, 294, 295, 296 and 299, verified against the live services. They covered a caller-supplied peer address, signed-request authentication, unauthenticated host metrics, internal details in logs, unbounded calls-relay memory and public access to stored files. Topic 316 was fixed and deployed earlier.

Wallet — topics 349, 350, 351, 355, 356 and 357, verified in Wallet V1.78:

  • escalating PIN delays, with device erasure as an opt-in rather than an automatic wipe after five wrong attempts;
  • contacts, profile, transaction journal and notes kept inside the encrypted vault;
  • update notices restricted to a known publisher and download URL;
  • explicit consent before using gateways found in the on-chain registry;
  • private-network URLs refused by both wallet and node.

Two caveats. The wallet checks that a release entry came from the publisher account, that the URL is HTTPS on an allowed domain, and that the download matches the published SHA-256 hash — but it doesn't yet verify the publisher's ZBC-MSG-v1 signature. That stays open. And closing the file-storage report doesn't make an unencrypted upload private: anyone with its ZFR_ root, plus the replica operators, can read it. V1.78 encrypts uploads on-device by default; a node-side access-control list is designed but not built.

Node 0.5.2

Both fleets moved from 0.4.2 (13 September) through 0.4.5, 0.5.0 and 0.5.1 to 0.5.2. All 22 TestNet and DevNet nodes were on 0.5.2 by 17:33 UTC on 27 September. The roll took 15 minutes and neither chain paused.

0.5.2 was prompted by two stalls on 26 September:

  • TestNet mined 107 empty blocks (549–655) over 62 minutes. Five file-deletion transactions for the same path landed in one block; the second failed deterministically and invalidated the block, but wasn't evicted, so every producer hit the same failure again.
  • DevNet stalled twice for about an hour each after a transfer to an address of no known type.

0.5.2 evicts transactions after deterministic failures, limits operations on the same object within a block, and brings admission checks closer to execution checks. Two remotely triggerable crashes had already been fixed in 0.4.5, and a transaction dropped from the pool now always carries a reason on the transaction-status endpoint.

Relaunch and height-activated rules

Both chains restarted from block 0 at 16:21 UTC on 26 September. Previous balances and history are gone; TestNet coins need to be requested from the faucet again. A node installed before the relaunch may still be sitting on the dead chain with no peers — reinstall it with the node role.

Protocol changes can now activate at a block height instead of needing another relaunch. Of 35 height-controlled rules, 29 have been active since block 0 and six are scheduled for block 60,000: fee-only no-ops instead of failed blocks, the reserved dfs: namespace, recipient shape, the dataset-update deposit fix and related executor rules. Every node must be on 0.5.2 before block 60,000 or it will fork off the chain.

The stall fixes are not among the six — they're already active.

Taproot and split policy

Both are live on chain from block 0 of the relaunch. The wallet doesn't expose either yet. TAPROOT_LIVE is off, so V1.78 refuses ZBC sends to bc1p recipients and shows existing Taproot accounts as token-only even though the chain accepts ZBC for them. The split-policy screen and transaction builder are built but sit behind SPLIT_LIVE, also off. Wallet dates for both will follow.

Wallet V1.78

The biggest change is how a games are tracked. The wallet now follows it through the node's staging and mempool states, and the sealing screen shows how long it has waited and its mempool position.

The old wallet gave up after 80 seconds. During the TestNet stall it deleted three games records and reported nothing resolved — even though all three landed about 40 minutes later and one paid out. V1.78 waits up to six minutes, keeps the record after a timeout, resumes polling when the game is reopened, and never calls a bet failed while the node still has it in the mempool.

A payout display fault affecting every winning game is also fixed: matching now uses reference_id, which the API actually returns.

Also shipped:

  • minimum retained fee, fee sent and total account debit in confirmation dialogs;
  • transaction version 2 and selectable survival periods;
  • token expiry dates and extension controls, with signing refused on an expired token;
  • account groups with pooled balances, member permissions and spending limits;
  • type-5 multisig proposals and co-signatures;
  • activity rows calculated from the node ledger;
  • encrypted file uploads (ZFE1 container) by default;
  • encrypted notes interoperable with zbc-cli;
  • unknown callers arrive as incoming requests instead of ringing;
  • gateway registry entries listed as disabled until you enable them.

Reporting bugs from October

From October, a report needs to be posted on the ZooBC forum to qualify for a bug or security reward. Telegram is still fine for discussing a fault — there's a dedicated technical group for that, which also keeps the main channel free for general discussion — but the forum post is the record we use to reproduce, verify and close. Reward details will be published separately.

Coming up

Two AMA sessions are planned for mid-October: one for detailed technical questions, one at a higher level. I have built a tool for them that translates questions and subtitles into each viewer's selected language; it hasn't yet run a live session. Finger crossed it will work (you are going to be the guinea pigs to test this new system!) As fallback we have google meet. Dates and registration links will be announced separately.

The second phase of the ZBC purchase period has 18 days left. Who ever want some, please get them ASAP!

Elsewhere

Circle opened the Arc mainnet on 16 September: a permissioned proof-of-authority validator set, Malachite BFT consensus and USDC for fees. A move to permissioned proof of stake has been discussed but not scheduled. Avalanche activated Helicon on 22 September: auto-renewed staking, a 48-hour minimum staking period (down from two weeks), a 90% uptime threshold for rewards (up from 80%) and a phased reduction in mean consumption rate. Visa, Mastercard and Ant International described a "Know Your Agent" framework for identifying autonomous payment agents and tying them to responsible entities — Visa's demos still keep a person in the authorization path; Mastercard's virtual cards carry merchant restrictions, spending limits and optional approval before checkout.

Three different trust models: institution-selected validators, stake and uptime requirements, and payment-network identity controls. ZooBC is still proving out Proof-of-Participation before MainNet, and this week's relaunches, stalls and open executor findings are that work done in the open.

社交媒体免责声明

最后更新:2026年9月29日

本文为译文。如果与英文版本存在差异,以英文版本为准。

本免责声明适用于由 ZooBC Foundation 或代表其发布的所有帖子和社交媒体内容,包括与 zoobc.com、zoobc.pro、zoobc.net、zoobc.network、socialconnect.network、proofofparticipation.network 以及 zoobc.foundation 相关联的内容。

1. 基本信息

所有帖子及社交媒体内容(“内容”)仅用于娱乐和资讯目的,并不必然代表 ZooBC 或 ZooBC 任何员工、贡献者或承包商的观点。该内容并非绝无错误,可能包含不准确的信息。无论口头或书面,从 ZooBC 获得的任何建议或信息,均不构成本文未明确作出的任何保证或陈述。

你不应依赖任何内容来获取任何形式的建议,包括法律、投资、财务、税务或其他专业建议,该内容也不能替代合格专业人士提供的意见。

任何内容均不构成出售要约,也不构成购买任何证券、代币或数字资产的要约邀请,亦不构成可被解读为邀约或诱导从事任何投资活动或类似行为的要约、广告、招揽、确认、声明或任何金融推广。

为免生疑义,相关内容并非由投资顾问提供,也不属于 ZooBC 的投资咨询服务。ZooBC 及与 ZooBC 相关的社交媒体账号进行的转发、转推、关注或点赞,均不代表 ZooBC 对任何观点、个人、团体或实体的背书。

2. 联系信息

如果你对我们的网站或本免责声明有任何疑问,请通过 info@zoobc.foundation 联系我们。