We built something that is neither a public chain nor a consortium chain. The goal was to deal with compliance, performance, decentralization and security at the same time. The codebase is very large — 312 Rust crates. Maybe you'll call it a big ball of mud, but it compiles smoothly, and a single shard currently benchmarks at a stable 3000 TPS (EPYC 7413, 16GB RAM, 2TB SSD, 6-second block interval, with multiple nodes installed on one server — a real deployment should do better; per-process resource usage is very low). There are 40 shards in total, and it can be extended further.
What I want to show today is the ZK-based deposit/withdrawal system. This part is open source on GitHub and can be compiled and verified independently.
Is this meaningful to the industry? It does not rely on multisig.
As for how secure it really is — we still have concerns ourselves. For now we rely on watchdog nodes that can circuit-break every single withdrawal, plus an hourly limit and a daily limit. For the project these are, honestly, temporary measures.
One more thing, about the choice of SP1: is 6.2.3 safe enough? On the same 7413 server, with no GPU, generating one proof takes about 2–3 minutes.
One thing we're still uncertain about: is SP1 6.2.3's proof generation time (2–3 min on EPYC 7413) acceptable for a production withdrawal system? Would you trust a system with that latency? Curious to hear your thoughts.
We built something that is neither a public chain nor a consortium chain. The goal was to deal with compliance, performance, decentralization and security at the same time. The codebase is very large — 312 Rust crates. Maybe you'll call it a big ball of mud, but it compiles smoothly, and a single shard currently benchmarks at a stable 3000 TPS (EPYC 7413, 16GB RAM, 2TB SSD, 6-second block interval, with multiple nodes installed on one server — a real deployment should do better; per-process resource usage is very low). There are 40 shards in total, and it can be extended further.
What I want to show today is the ZK-based deposit/withdrawal system. This part is open source on GitHub and can be compiled and verified independently.
Is this meaningful to the industry? It does not rely on multisig.
As for how secure it really is — we still have concerns ourselves. For now we rely on watchdog nodes that can circuit-break every single withdrawal, plus an hourly limit and a daily limit. For the project these are, honestly, temporary measures.
One more thing, about the choice of SP1: is 6.2.3 safe enough? On the same 7413 server, with no GPU, generating one proof takes about 2–3 minutes.
Repo: https://github.com/niumeta/niumeta (the ZK part is under "Cross-Chain Bridge/", with a reproducible build guide)
Author here – adding some context.
We're thinking about this at a different level: "Towards a Type I Civilization: A Zero-Trust Network"
With the exception of AI training, all traditional data center capabilities can be decentralized and integrated on-chain.
This might sound like a joke, but we are serious.
Architecture overview: https://www.niumeta.com/en/developers/architecture
One thing we're still uncertain about: is SP1 6.2.3's proof generation time (2–3 min on EPYC 7413) acceptable for a production withdrawal system? Would you trust a system with that latency? Curious to hear your thoughts.