Bitcoin Forum
June 03, 2026, 07:59:10 AM *
News: Latest Bitcoin Core release: 31.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Veridium Network (Rule 30 VDF, PoSW, Binary-Field STARKs)  (Read 160 times)
pixelsort (OP)
Newbie
*
Offline

Activity: 10
Merit: 1


View Profile WWW
April 13, 2026, 06:38:40 AM
Last edit: May 31, 2026, 06:55:57 AM by pixelsort
Merited by hugeblack (1)
 #1

Hi everyone!

I'm starting out on my newbie adventure right now and thought I'd break the ice with an intro post.

I used to lurk here back in the day; late 2010 or so. I was so obsessed with Bitcoin back then that I studied it for days. Holding the whole system in my mind without any gaps was everything to me. Years later, after CPU mining on Litecoin fizzled, I sold my stash and moved on. More recently, I've held ETH and several others; but I'll never forget how magical it felt living at the dawn of something so important and being among the few who even knew what it really was or how it worked.

Even more recently, I had an idea (Rule 30 VDFs) that I couldn't shake. And, it turned out that three venerable researchers beat me to the underlying consensus theory back in 2013:

Publicly verifiable proofs of sequential work
https://dl.acm.org/doi/10.1145/2422436.2422479

For a person like me, theory isn't enough. Like Bitcoin, my project (not yet named) requires serious effort to explain and fully understand. Historically, this is the place. So, I decided to finally join and contribute. Also, my launch plan requires the hash from the minting of a future Bitcoin block in order to ensure a fair start. So, technically I'm relevant!

If anyone has advice on which forums I should be posting about this it would be well received. But, in case anyone is curious about the shape of my idea and decisions I've made so far:

- 100% fair-launch L1 commodity coin: no premine, allocations, funds, operators, contracts, or foundations
- First Mover: Proof of Sequential Work Consensus
- Mining proofs: Zexe + Binius + Rule 30 VDF Clock
- Identity: RandomX + DDA + Epoch TTL "tollbooth" for
- Security: ZCash Sapling/Orchard

At the core of my fairness surface is a "Luckiest Hash" race. Combined with my "Fuzzy Victory Window", it ensures that mining is almost like entering a lottery. After a Monte Carlo parameter sweep tonight I found that at the sweet spot, a 5% speed advantage is diluted down to a win-rate of just 56%. I'll have to run simulations with far more than just 9 local nodes to calibrate the security; or else this collapses to PoW and eternal shame, but it's all very real and promising.

If this works, a data center with ten thousand cores runs the clock at exactly the same speed as a single laptop. The mining race can be genuinely flat. My hope is that this would bring back some of that early magic from the times before mining pools and all the complexity and scams.

Things I have a good start on:

- Whitepaper (v2 draft)
- Rule 30 prover in Rust (AVX2 vectorized binary field STARK)
- Chord-based UDP testnet simulator w/TUI
- Swarm telemetry and diagnostic charting
BattleDog
Full Member
***
Offline

Activity: 241
Merit: 231



View Profile WWW
April 13, 2026, 04:11:45 PM
 #2

Welcome back. Anyone who was around in 2010 and still has enough wits left to willingly design a new consensus system in 2026 is at least posting in the right asylum.  Tongue

Joking aside, you're at least starting from an actual mechanism instead of branding first and physics later. The part I'd be careful with is the leap from "the race looks flatter in simulation" to "real-world mining stays flat under adversarial conditions." That gap eats people alive. Schedulers, memory hierarchy, network jitter, implementation quality, tuning, weird hardware asymmetries, and plain old operator competence have a way of sneaking back in through the basement window even when the front door looks sealed.
pixelsort (OP)
Newbie
*
Offline

Activity: 10
Merit: 1


View Profile WWW
April 14, 2026, 05:17:58 AM
 #3

Welcome back. ... The part I'd be careful with is the leap from "the race looks flatter in simulation" to "real-world mining stays flat under adversarial conditions." That gap eats people alive. Schedulers, memory hierarchy, network jitter, implementation quality, tuning, weird hardware asymmetries, and plain old operator competence have a way of sneaking back in through the basement window even when the front door looks sealed.

Thanks for the warm welcome! Even just a little external attention on this is enough to keep me going right now. It means a lot.

Your point about these basement windows around me is well taken. Security is hard. Cryptography is extra hard. And, deploying a properly tuned L1 with an ossified protocol and a novel consensus protocol? I'm finding out that it's gonna require making some new friends. It's also true that I don't have everything figured out. For instance, I've only just started considering privacy in the networking layer. I'm no expert, but a Dandelion++ implementation like in Monero seems like the best fit.

Another thing I'm still figuring out is the macroeconomics. I want this coin because I want mining to be fun again. But, my research indicates that without a mining race a lot of people won't care. The best answer I have for this is a consumer framing. It goes like this:

Right now, buying consumer hardware like cell phones and laptops is a pure cost center the moment you click "Buy" or walk out of the store. What if a miner running passively on that device coulld generate even $5-20 per month reliably? That could reframe every piece of consumer electronics as a productive asset! Let the first device pay for the next and so on.

Since my last post, I've made a few changes that address some of those specific asymmetries you mentioned.

The major one, is that I just finished the transition to a binary-native ledger format. This aligns the state transition directly with the STARK circuit, making my proof-of-everything (PoE) recursive state updates significantly faster and more memory-efficient. A stateless ledger gives minted blocks the property of being verified on sight. No need to build up the entire state from history to know a block is valid. No catching up. No merkle checkpoints or roll-ups. Instead, every block carries an aggregated STARK proof of the VDF continuity and the ledger transition, the block is its own certificate of validity. The physics ensure that the coins are there and the clock has stayed true since genesis. This makes participation on mobile, NUCs, and other lightweight hardware safer by design.

Another big change, is that I've moved the internal hashing layer from Groestl/SHA2 to Vision32b. Vision is arithmetization-friendly for binary fields, so in my Binius-style STARK, proving is now essentially "free". It allows me to embed much higher-resolution "proof-of-trace" checkpoints into the VDF clock without bloating the proof.

Another change worth mentioning is that I now have miner auto-calibration for the STARK prover. I'm calling a "Switchover Probe". It's a one-time check that dynamically adjusts the sumcheck crossover points based on the local machine's cache and SIMD width (AVX2/NEON). This ensures that proving throughput remains consistently optimal across heterogeneous hardware. It should help prevent that from becoming a hidden tax on smaller miners.

It's a lot of work, but the physics really are starting to feel solid. I'm currently tuning the M/N window ratios to ensure the protocol stays lottery-like even when one peer has a significant hardware advantage. With a little help refining my ideas and calibrating my testnet, this could open doors to some wild places!


pixelsort (OP)
Newbie
*
Offline

Activity: 10
Merit: 1


View Profile WWW
April 15, 2026, 05:14:43 AM
 #4

Hi, everyone.

Progress update: Today was a productive mix of coding, generating mermaid charts, and policy planning. I also promoted my whitepaper to v3 to reflect the new binary ledger format.

Today's applied research gains:

- Identities can now derive up to 256 sub-keys; for multi-core CPU mining
- Aggregated STARK proofs now partially working over VDF and ledger state
- Binary native ledger now operational with HorizonTree and HorizonTreeWasm for 32-level Merkle
- Switchover Probe is now binary native
- Identity DDA now targets lease density instead of entry velocity
- Throughput DDA now adapts to median VDF steps/s from Micro-Win metadata
- Improved Chord scaling by implementing a successor list (depth=128) for churn-resistance
- Finished the cross-chain genesis system and tested it under simulation

Some new insights and ongoing efforts worth mentioning:

- Wolfram's Rule 30 provides the VDF with computational irreducibility as a timekeeping primitive
- Flattening the advantage curve converts mining from a tournament into a yield-bearing asset
- Calibration of the coin cap and emission schedule is now active research topic
- Researching Vision32b-based nullifier verification and ZEXE recursive shielding for encrypted UTXOs

I'm really looking forward to earning my chance to start uploading a few things. Advice and questions are welcome.
pixelsort (OP)
Newbie
*
Offline

Activity: 10
Merit: 1


View Profile WWW
April 16, 2026, 05:33:10 AM
 #5

Progress Update: Today I finally decided on a name for the project. Then, I registered domains and secured accounts on various platforms to ensure future availability.

Now, I'm proud to announce:

Veridium Network by Anosic Systems

As a coinage, Veridium roughly means "green mineral" or "green ore". Why? Green is my favorite color and the connection to so-called "emerald ore" and "mining" is very satisying for this old Minecraft fan. Anosic means "without disease" or "healthy". In this case, the sickness is the perverse incentives created by PoW consensus. With Veridium, Anosic aims to prove that a modernized crypto can be much greener.

Anosic Systems will be a research vessel and technical maintainer of the Veridum protocol and ecosystem. I have a few other active research projects (like my eBPF-like principled semantic IR) that this org will also maintain. Once I have a proper landing page the public site will be at: https://anosic.com (coming soon)

Veridium Network refers to the permissionless L1 P2P network.

Veridium is the name of cryptocurrency minted by participants of the network. A technical portal site with a block explorer, downloads, and various utilities will be at: https://veridium.cc (coming soon)

No logo yet, but I did spend a few minutes exploring Unicode for a value symbol to adopt. I found "MATHEMATICAL SCRIPT CAPITAL V" at U+1D4B1 and it looks nicer than all the other V-shaped options I found. So, I'll soon start using in my scripts and in the testnet TUI to help me focus on the values more easily. For example, they would look like this:

𝒱0.01

If anyone has feedback on these names or questions/concerns about these plans it would be greatly appreciated.
pixelsort (OP)
Newbie
*
Offline

Activity: 10
Merit: 1


View Profile WWW
April 20, 2026, 04:48:36 AM
 #6

I'm proud to announce that today I finalized the STARK field alignment. I got beat up pretty bad on this. I couldn't figure out how to get the trait implementations to play nicely together. In the end, using a specialized witness index, I managed to unify VDF, Identity, Ledger under a single oracle set. This gives Veridium three distinct proof segments bound by a consistent field tower.

One final stretch of hard work remains before I can build a Rust/WASM miner client out of the simulator. Mainly, I need to record baselines and implement the Horizon Tree membership proof as a standalone Binius circuit. This won't be trivial, and I am worried that I will blow my 10KB proof budget in the process; but at ~7KB it might still work out. Keeping the sizes low is vital to building Veridium Network such that miners can participate with nothing more than a common smartphone.

Also, I moved into a new monorepo under the Anosic Systems banner. There, I developed a new diagnostic chart providing needle scatterplots for the events for each node in the network. This has enabled me to bring the testnet performance to a full recovery under the binary ledger format. In fact, I am seeing a 3x speed-up in average VDF rate (over V8 workers) across all nodes.

I also now have a wide array of unit and integrations tests. And, my library of utility scripts for various benchmarks has grown significantly. In the hope that sharing this kind of thing could lead to more people taking an interest in what I'm doing, these are the scripts:

Consensus & VDF Research

vdf:bench - Benchmark the Rule 30 VDF clock speed (Rule 30 parity)
vdf:validate - Validate Rule 30 implementation against reference states
vdf:chart:lyapunov - Perform Lyapunov exponent analysis and spectral VDF texture checks
audit:degree - Audit Rule 30 non-linearity and bit-mixing degree
audit:interpolation - Audit low-degree proximity for Reed-Solomon
hegemony - Run the Monte Carlo fairness sweep to simulate block production luck
wisdom:probe - Analyze entropy and "wisdom" density in the sequential clock
yarn test:starvation - Audit event-loop lag and gossip responsiveness

Prover & STARKs

prover - Run core Binius STARK prover integration tests
prover:build - WASM compiler, primary toolchain for portable prover builds
prover:wasm - Validate WASM-compiled prover in the Node.js environment
prover:bench - Native prover, peak throughput benchmark (Native AVX2/AVX512)
bench:vision:stark - Benchmark the Vision-based STARK prover performance
bench:compression - Measure trace compression efficiency for recursive proofs
bench:recursion - Recursion bench, measure STARK recursion depth and overhead
tax:probe - Tax probe, simulate "Field Tax" penalties for unoptimized witnesses

Network & Sybil Resistance

sybil - Perform high-concurrency Sybil stress tests on the Chord DHT
tollbooth - Run RandomX PoW verification tests for DHT entry gating
tollbooth:ring - Ring audit to verify identity-gated gossip constraints
ring - Test the Veridium P2P Ring topology and connectivity
lease - Test the Proof-of-Trace lease renewal mechanism
audit:leaserenewal - Lease audit, for peer ejection and hardened gate enforcement
audit:collisions - Collision audit, for detecting Chord ID address space clustering
dos:stress - Stress test the node's resilience against RPC/Gossip flooding
genesis:set - Orchestrate the initial Genesis validator set
genesis:monitor - Monitor the health and propagation of the Genesis block
tollbooth:purge:identities - Clear local identity cache for fresh audits

It's still slightly premature for me to share my whitepaper or my numeric specs. But I'm happy to explain the trade-offs I've picked and how I've solved various problems if anyone is curious.

pixelsort (OP)
Newbie
*
Offline

Activity: 10
Merit: 1


View Profile WWW
April 22, 2026, 04:52:15 AM
 #7

Veridium almost came to a full stop today.

I thought that recursive STARK aggregation would significantly compress the ledger under TensorPCS. Instead, I saw the payload shoot from 10 KB up to sizes that would never work. I did find a field solution that would reduce it to nearly 20 KB, but this would have required miners to commit gigabytes of RAM to make proofs.

It was almost game over. I was tempted to quit for the first time. Instead, I found another way. My research has now pivoted into a new dual-PCS (Polynomial Commitment Scheme) strategy. If it works, this means that the Veridium protocol will utilize two distinct PCS phases in an inductive chain:

Phase A: Inner Segments - Work Layer

- Target: VDF (Rule 30), Identity (Vision), Ledger (Horizon Tree)
- PCS: TensorPCS
- Reasoning: Optimized for high-throughput, large-trace "work" circuits
- Output: Three internal proofs" (~525 KB total)
- RAM Overhead: Minimal (linear to trace)

Phase B: Master Verifier - Compression Layer

- Target: Recursive Binius circuit that verifies the three TensorPC` proofs
- PCS: High-Expansion FRI-Binius
- Reasoning: Because Binius verifies Binius with degree-1 XORs, the trace is exceptionally small (2^14 bits per column)
- Compression: By using an inv_rate of 256, we compress the proof size to 20 KB.
- RAM Overhead: ~16 MB. Because the trace is small, the 256× expansion tax is trivial for consumer hardware/mobile phones.

It's already coming together. Test suite is mostly passing again. The Binius-on-Binius verifier circuit exists. I have the witness, allowing me to feed the three segment proofs into the master circuit. I even have a field-compatible FRI-Binius implementation. But, the prover is still leaning on TensorPCS for the master proof.

To hit a 20-30 KB target envelope for network transmission and fix the remaining handshake/starvation issues I'll need to hook FRI-Binius into the prover. I hope to do that soon and report back.
pixelsort (OP)
Newbie
*
Offline

Activity: 10
Merit: 1


View Profile WWW
April 29, 2026, 03:56:44 AM
 #8

Hi everyone, I'm back with results from the dual-PCS compression work.

The Veridium gossip certificate has been stabilized at 20.70 KB.

The core breakthrough was decoupling the security parameters of the gossip layer from the underlying proof system. By parameterizing the FRI query phase, the Master Verifier now uses a 256x expansion factor with 12 queries, tuned to a 96-bit security margin -- appropriate for ephemeral network propagation.

The two-layer architecture:

1. Work Layer - TensorPCS arithmetizes the Rule 30 VDF and Horizon Tree transitions into committed polynomials
2. Compression Layer - FRI-Binius wraps those commitments into a single opening proof, collapsing 3.5 MB of witness data into a 20 KB certificate

What a peer verifies when they receive this certificate:

1. VDF Continuity - That the sequential work for the current interval was performed (Rule 30 steps)
2. Identity Gating - That the miner held a valid sub-key
3. Ledger Integrity - That the included transactions correctly transition the state root

On succinctness: The 20.70 KB size is achieved through adaptive FRI parameterization, not a fixed circuit constraint. This means the gossip budget and settlement budget can be tuned independently as the network's security requirements are better known.

Comparison to Mina: Mina's 22 KB proof (via the Pickles SNARK system) achieves constant size through recursive elliptic curve arithmetic over the Pasta curves, which requires a trusted setup. Veridium's certificate is transparent and post-quantum resistant with no trusted setup and binary field arithmetic throughout. The tradeoff is that FRI proof size is polylogarithmic rather than strictly constant, though at this scale the practical difference is negligible for gossip purposes.

Next, I plan to push towards chain-depth recursive verification. The basic roadmap for this includes:

- Move all internal Merkle trees to Vision-native arithmetization. This should yield a ~90% gate reduction in the verifier circuit
- Arithmetize the FRI-fold and sumcheck logic directly as Binius constraints
- Wrap the previous block’s certificate as a witness into the current proof

The goal is to provide a "verified on sight" guarantee for the entire chain history. This could push the gossip payload up into the 35–60 KB range, but that would still be a modest price for the ability to verify the entire chain depth in milliseconds.
_ili_
Newbie
*
Offline

Activity: 13
Merit: 0


View Profile
April 29, 2026, 11:37:38 PM
 #9

it won't work, it's impossible to compete with powerful hardware
pixelsort (OP)
Newbie
*
Offline

Activity: 10
Merit: 1


View Profile WWW
April 30, 2026, 06:24:20 PM
 #10

it won't work, it's impossible to compete with powerful hardware

It might work. That's why I'm here. Hopefully, you're here to do more than make proclamations of doom. That said, your opinion is the natural reaction for anyone who understands how most cryptocurrencies and their underlying forms of consensus work. Veridium works differently.

On Information Sharing

I haven't fully explained how Veridium is different. I will do that. But, the system is currently under rapid research and development.

For instance, FRI-Binius is far more challenging than I anticipated; and I never anticipated needing it in the first place. As of today, it is operating under simulation with full-chain verification and fixed-size blockchain gossip payload of 39.79 KB at 128-bit security and 25 queries and 10 rounds of FRI folding. It still needs hardening of the VDF, Identity, and Ledger segments. After these arithmetizations, there might be so many gates in the verification that I've blown the 100ms budget I'm targeting. I have ideas for dealing with this, but using less queries and getting less network security could be the only good options.

Once the parameters are more stable, I'll start publishing research and explaining the various components in detail. That said, I know that sharing some of this information now is the only way to invite feedback and encourage understanding. For this reason, I'm including some explanations below that I've been working on. They are low in technical detail but they do at least partially explain what Veridium is and why it might just work.

Veridium Physics are Optimized for Prosumer Mining

Veridium plays with most of the same physics as past cryptocurrencies. It even uses PoW (via RandomX) for identity cost. However, outside of Veridium, the idea of a Rule 30 VDF has never been publicly theorized. Consequently, computational irreducibility has never been productionized as a clock oracle. The mechanisms that the Veridium protocol builds around this new time-keeping primitive are what creates the fairness characteristics that would otherwise be impossible.

Mining Hardware Becomes a Yield Instrument

PoW mining is a zero-sum tournament. You win more by outspending your competitors on hardware and energy. This means:

  • Time, energy, and opportunity are destroyed racing to the frontier
  • - The rational actor is always the *biggest* player
  • - Small holders are eventually squeezed out

With a flattened advantage curve under PoSW, Veridium converts mining from a tournament into a yield-bearing asset. The miner is no longer weaponizing their hardware to gain an edge in an arms race. Instead, the miner is incentivized to increase their yield by investing in low-cost high-core hardware because the economics are much closer to a bond with hardware collateral.

Self-Funding Hardware Acquisition Loop

The key economic unlock of PoSW is: **Revenue ≥ Cost of next hardware unit**

Once that's true, rational behavior flips. Instead of purchasing hardware to dominate, a miner will make purchases to either replicate or extend mining capacity through modularity. Each mining node becomes:

  • A cash flow engine, not a competitive weapon
  • Something you hold, not something you race with
  • An asset class with a natural reinvestment rate

This is very different from mining with PoW. Veridium makes hardware ownership somewhat like owning farmland. Even if your neighbor has much better farmland, yours is still productive.

Safe Harbor as a Protocol Guarantee

By ensuring that no single actor can price you out of earning, the protocol dramatically changes the macroeconomics:

  • Lowers the discount rate applied to future mining rewards
  • Makes long time-preference behavior rational
  • Attracts patient capital, not speculative sprint capital

The network stops selecting for the richest/fastest participants and starts selecting for the most persistent.

Broad Distribution of Supply Issuance

With a hardware advantage of only ~6 points and diluted across 10,000 units, the marginally-equipped miner remains viable indefinitely. This has a number of secondary effects:

  • Newly issued coins distribute more broadly
  • No single entity accumulates enough to threaten the network
  • The coin's **Gini coefficient at issuance** stays healthier over time

Launch Implications

Typical PoW "Arms Race" Launch

Early advantage creates a gold rush signal that does the following:

  • Quickly pulls in capital
  • Creates urgency to join early
  • Bootstraps the network
  • Volatile but rapid price discovery

In typical crypto launches, unfairness is either overt or implied in the marketing, because the asymmetry is the true incentive.

Veridium's "Flattened" Launch

By removing the hardware advantage, we remove most of the gold rush signal. Now the adoption curve looks more like:

  • A slow burn, rational actors accumulate when they're ready
  • No urgency premium, so no urgency-driven demand spike
  • The asset gets valued on yield fundamentals rather than speculative positioning

Note: A recent draft of the Veridium Network emission schedule introduces a steeper issuance curve during the first 10 years of mining; out of a 400-year emission schedule. This 10-year period would be intended to increase early speculative interest in in order to help bootstrap the network.
pixelsort (OP)
Newbie
*
Offline

Activity: 10
Merit: 1


View Profile WWW
May 20, 2026, 03:07:38 AM
 #11

My last post mentioned the need to harden the VDF, Identity, and Ledger arithmetizations. I specifically expressed my concern that gate count inflation could destroy the 100ms verifier budget and/or blow up the blockchain payload. Twenty days later, I'm here to report on my progress.

Those concerns were well justified. As a result, these last few weeks have been absolutely brutal. I've been riding an endless rollercoaster of applied cryptographic engineering; and it's far from over. Here's what happened:

Bit-Slicing Fail
Hardening the VDF meant shifting the architecture to a bit-slicing regime. I spent days migrating the entire kernel to bit-sliced arithmetization. The spatial logic worked perfectly, but the single-segment proof size exploded to 104 KB. Every single bit required its own commitment, destroying the sub-64KB budget.

Packed Geometry Pivot
To save the budgets without sacrificing security, I pivoted to a packed field geometry. This meant overhauling the N-API bridge and the kernel to collapse 512 individual bit-oracles into four 128-bit packed words. It was a massive architectural risk, but it worked! This brought the proof size back down to ~41 KB and kept the verifier fast.

Soundness Crisis & Security Regression
While the geometry was now sensible and the budgets were satisfied, soundness was still lacking. The biggest obstacle was not being able to effectively reason about the algebraic traces and polynomials. They were too large and the tests were taking too long for rapid iteration. It was painfully clear that with a log_inv_rate of 4 (16x eval domain expansion) I was probably never going to figure it out. That's when I decided to make a tactical retreat to a log_inv_rate of 1 (2x expansion). This configuration also reduced the security floor to a mere 25 bits.

Projection Oracles
With the new geometry stabilized, I pushed onward toward projection oracles and vertical arithmetization. This architecture enables transparent unpacking for those 128-bit words inside the circuit without paying the field tax during the commitment phase. It also compressed the massive 1800-column oracle manifest down to a sleek 209-variable manifest, pushing proof sizes down to an incredible 9.7 KB.

Continuity Constraints
Under this vertical geometry, the prover began failing with an elusive evalcheck error. Also, the verifier was now rejecting the consistency of the shifted challenger state columns. I spent days tearing apart the recursive prover, assuming the constraints were failing. In the end, the bug was buried deep in the verifier's internal Binius reductions. Eventually, I fixed the issue, implemented a live challenger continuity constraint to cryptographically bind the final state, and finally achieved rigorous structural mathematical consistency.

Ledger Block
With the math consistent, prover stabilized, and all 88 tests and 10 audits passing, I wrote the very first blockchain completeness audit; optimistically expecting it to work. It didn't. This is the one audit that proves Veridium is undeniably real. Undeterred, I scoured the code to inventory all of the remaining technical debt and then identified three load-bearing stubs:

  • A mock algebraic proxy for the Merkle path (not true Vision-32b)
  • A static zero-seeded challenger trace
  • A simplified query indexer

Today, I conquered all three.

Current Status
The hardest part is over. Veridium is now mathematically sound and boasts a bit-sliced, recursive STARK over a Rule 30 VDF and UTXO carrying blockchain payload. However, security is still sitting at just 25 bits. The road ahead requires dialing the log_inv_rate back up to 4 in order to restore the security floor. The grind goes on. But at least the math is finally on my side.

Changing The World
With a little help, Veridium could change the world. It really could. All it has to do is make something profoundly useful possible that truly never was. Bitcoin and Ethereum both did it. But by comparison, every other cryptocurrency since has either been boring and/or derivative.

Consider privacy. Veridium is privacy-first; shielded just like Monero. So who cares? I care. Mainstream people won't. At the end of the day, mainstream people only care about things like comfort and overpaying. To change the world, an L1 has to deliver an obvious and undeniable reason for mainstream people to actually care.

Veridium will have a boatload of technical achievements worth boasting about. It will be the only L1 for payments that offers all of these at the same time:
  • the energy efficiency of Chia-adjacent physics-based consensus
  • the stable blockchain payload and verified-on-sight (zero confirmations) properties of Mina Protocol
  • default anonymity with optional Starknet-inspired viewing keys for regulator and auditor compliance

Cool right? Wrong! Snoozeville. The mainstream doesn't care about any of that. Not in the least. This is what can be said about world-changing cryptocurrencies:

  • Bitcoin proved that energy can generate currency.
  • Ethereum proved that smart contracts can work.
  • Veridium will prove that sustainable fair home mining is possible.

When Veridium delivers the mainstream will not ignore it. Everyone will find out because it enables a new economic choice for everyone with capable (AVX-512/NEON) hardware.

Call for Small Donations
I'm under-employed right now and working on this in my spare time. Food and gas are the resources I need most. I'm going to continue regardless; that's just how I am. If you're interested in this project and would like to help speed things along, please send a small donation to my address below and then either reply or PM me to let me know if you wish.

Bitcoin: bc1qee6dey9v05v2unw9jwywpgqht9q2x9w885gk8d



pixelsort (OP)
Newbie
*
Offline

Activity: 10
Merit: 1


View Profile WWW
May 31, 2026, 07:04:48 AM
 #12

I'm feeling too exhausted and overworked to post updates lately. That said, I write this one tonight. I hope someone out there enjoys reading it. I'm entirely convinced that Veridium will have more firsts to boast than any blockchain since Bitcoin; so who knows, maybe someday these reports will actually matter to someone else besides me.



Veridium is now undergoing an architectural pivot that marks one of the most significant changes in the protocol's short history. In recent weeks, the project has moved through several iterations as real-world constraints exposed the strengths and weaknesses in the design. What began as a search for smaller proofs and better network efficiency has led me to conclude that deep changes to the core proving and hashing choices are necessary.

Weeks ago, in the dual-PCS era announced previously in this thread, one proving system (TensorPCS) was used to generate proofs while a second proving system (FRI-Binius) wrapped and compressed them into a smaller package suitable for network propagation. While this approach achieved impressive compression, it also introduced substantial complexity. With one proof system effectively verifying another, maintaining confidence in correctness across both layers became increasingly difficult. Debugging was just too hard and proving was too time-consuming.

Then, I moved away from dual-PCS and standardized on a single TensorPCS-based architecture. Removing the recursive wrapper layer exposed a different problem: proof sizes grew far beyond the intended blockchain payload budget. Slowly, and painstakingly, it became increasingly clear that the inflated proofs were a consequence of the underlying design.

The current pivot addresses this limitation by removing TensorPCS entirely and adopting FRI-Binius as the native proving system. Instead of acting as an external compression wrapper around another proof system, FRI-Binius now operates directly at the base layer. This eliminates the need for layered proof composition while producing proof sizes expected to fit comfortably within the targeted budget for the blockchain payload.

The hashing architecture has undergone a similar reassessment. Earlier development cycles retired Grøstl in favor of Vision. I initially adopted Vision because it appeared to be a strong fit when evaluated through the lens of traditional proof-system design. As the implementation matured, however, Vision's column width requirements (a consequence of prime field bias) became a major source of pressure on circuit geometry and proof efficiency.

The new design returns to Grøstl, but not in the role it occupied previously. This time, instead of serving as a defense-in-depth security fallback, it is now arithmetized directly into the binary-field circuit used by the proving system. This alignment allows the protocol to verify hash operations using far narrower circuits and reduces the blockchain payload overhead while satisfying the relevant geometry limits.

To me, this pivot isn't a reversal. Some components that seemed optimal in theory proved awkward in practice. Others were solid choices, but required adaptation before they could take full advantage of the underlying mathematics of recursive binary-field STARKs. FRI-Binius and Grøstl are now being re-deployed as native components rather than auxiliary layers. The result should be a simpler architecture that removes the proof-size floor introduced by TensorPCS and avoids the circuit-width issues that emerged under Vision.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!