作業中

本サイトは、まだ構築中です

財団は、公開の場で構築を進めています。ここに見えるものは、現時点での正直な姿ですが、まだ完成していません——最終的な結論としてではなく、今の到達点として読んでください。

今からMainNetまでの間に、文言、構成、画像、数値は変わっていきます。一部のページは仮のものです。写真が人物の代わりとして使われている場合、それはストックフォトであり、記載されている本人ではありません。

より広いZooBCエコシステムは、段階的に整っていきます。ウォレット、エクスプローラー、コミュニティフォーラム、ソーシャルチャンネルは、MainNetが近づくにつれてそれぞれ稼働し、本サイトもそれらとともに成長していきます。

何かおかしく読める、壊れているように見える、あるいは誤解を招くと感じたら、お知らせください。今いただくフィードバックは、後の洗練されたローンチよりも当方にとって価値があります。

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.com、zoobc.pro、zoobc.net、zoobc.network、socialconnect.network、proofofparticipation.network、zoobc.foundationに関連するコンテンツを含め、ZooBC Foundationが、またはその代理として公開するすべての投稿およびソーシャルメディアコンテンツに適用されます。

1. 基本情報

すべての投稿およびソーシャルメディアコンテンツ(以下「コンテンツ」)は、娯楽および情報提供のみを目的としたものであり、必ずしもZooBC、またはZooBCの従業員、協力者もしくは契約者の見解を示すものではありません。コンテンツに誤りがないとは限らず、不正確な情報が含まれている場合があります。ZooBCから口頭または書面で得たいかなる助言または情報も、本書で明示的に行われていない保証または表明を生じさせるものではありません。

法律、投資、金融、税務その他の専門的な助言を含め、いかなる種類の助言としてもコンテンツに依拠すべきではありません。コンテンツは、資格を有する専門家による助言の代わりとなるものではありません。

いかなるコンテンツも、証券、トークンまたはデジタル資産の売却の申し出、もしくは購入の勧誘を構成するものではなく、投資活動またはそれに類する行為への勧誘または誘引と解釈されうる募集、広告、勧誘、確認、表明、金融プロモーションのいずれにも該当しません。

念のため申し添えますと、コンテンツは投資アドバイザーによって提供されるものではなく、ZooBCの投資助言サービスでもありません。ZooBCおよびZooBC関連のソーシャルメディアアカウントによる再投稿、リツイート、フォローまたは「いいね」は、ZooBCによるいかなる考え、個人、団体または事業体の支持を意味するものではありません。

2. 連絡先情報

当サイトまたは本免責事項についてご質問がある場合は、info@zoobc.foundationまでご連絡ください。