@prlnet

Privacy-preserving proof of inference is a key building block for AI safety. @DarioAmodei's call for AI slowdown & independent oversight raises a critical question / How can frontier labs prove their computations follow the rules, without revealing model weights, prompts, or private data? Two complementary technologies are necessary to make this inference layer possible: Zero-Knowledge proofs (zk-SNARKs) can prove that Y = M(x), while keeping M and x private, and verify compliance using explicit policies. Proof-of-useful-work (PoUW) can tie that evidence to actual, timestamped GPU computation, with a public immutable record and economic incentives for participation. @prlnet is partnering with @attestable to build this trust layer for AI. Together, our complementary technologies can make AI objectively accountable, making verification economically sustainable and self-funding. Today, we are announcing @prlnet's new and ultra-efficient floating-point PoUW scheme for NVIDIA Blackwell chips. Floating-point arithmetic has been a notorious obstacle to efficient verification of compute for decades. Pearl’s FP scheme brings proof-of-useful-work technology to Blackwell FP computations on frontier LLMs, with NEAR-ZERO additional overhead over end-to-end inference on optimized vLLM. The FP network upgrade specification is now available (github & whitepaper) and will soon serve frontier models on Pearl x @togethercompute's endpoints in production. Explore the implementation: https://t.co/FjwwSVoLSP Whitepaper: https://t.co/6BqeEqQRgl Run Pearlified models on our endpoint: https://t.co/6bykpZhFTk

The Pearl founders will be hosting another live AMA with the community! Tuesday, September 15 6:00 PM CET · 12:00 PM ET · 16:00 UTC We've been heads-down building, and the questions have been piling up — about the research, the roadmap, and where the network goes from here. On Tuesday, we're answering them. Here's how it works: head to the ama-questions channel on our Discord and drop in whatever you'd like answered. Upvote the questions you care about most. The founders will open with the five that rise to the top, then it's an open floor for the rest of the session. Come with good questions. We'll come with real answers. https://t.co/7Cx5srP7So

Pearl started with a simple question: Why should AI and blockchain mining compete for the same GPUs when the same computation could do both? In this talk, Pearl co-founder @komargodski explains how that idea became a live proof-of-useful-work network turning AI inference into blockchain security with minimal overhead.

Proof-of-Useful-Work forced us to solve a problem ordinary blockchains do not have. A Pearl miner performs large matrix multiplications as part of a real AI workload. Naively, when it finds a valid block, it would need to publish those matrices so the network could verify the computation. The matrices may contain private model data or user information, and a single weight matrix can be tens-to-hundreds of megabytes. Publishing them on-chain would be both prohibitively expensive and a privacy risk. This is why we encapsulated the entire mining computation inside a zk-SNARK. A zk-SNARK can take an arbitrarily complex computation and compress it into a small cryptographic proof. The proof reveals nothing about the underlying matrices, while still allowing the network to verify that the miner found a valid block. Instead of placing tens-to-hundreds of megabytes of potentially sensitive data on-chain, Pearl miners publish a zero-knowledge proof of roughly 60 kilobytes. The blockchain verifies the useful computation without ever seeing the model weights, activations or private data behind it. This is what makes Proof-of-Useful-Work practical at scale: large AI computations happen off-chain, while only a compact, privacy-preserving proof reaches consensus.

GPU non-determinism forced us to reverse-engineer arithmetic that modern AI hardware does not expose. The same matrix multiplication can produce different results across @NVIDIA Ampere, Hopper and Lovelace GPUs. The reason is not randomness - it is architecture-specific behavior in the order of accumulation, internal precision, rounding, normalization and handling of subnormal values. That makes exact verification difficult: a CPU re-execution may disagree with a perfectly correct GPU execution. Hawkeye solves this by systematically probing Tensor Cores with carefully constructed matrix multiplications. These tests recover the hidden numerical pipeline behind each architecture, including how products are grouped, when significands are truncated and when intermediate values are normalized. The recovered behavior is then encoded into a CPU simulator that reproduces the original GPU computation bit-for-bit. The results show meaningful architectural differences. Ampere uses a two-stage accumulation structure with a 24-bit internal significand, while Hopper combines all 16 products in one stage using 25 bits. Both use truncation-based, round-towards-zero behavior rather than conventional round-to-nearest arithmetic. Across 100,000 randomly generated matrix multiplications in FP16, BF16 and FP8, Hawkeye reproduced the GPU result with 100% bit-exact accuracy. This creates a foundation for auditors to verify AI training and inference without modifying or slowing down the original GPU workload. Looking forward, matrix multiplication is only the first step. Extending this approach to attention, fused kernels, distributed training and cryptographic proof systems could make end-to-end, hardware-accurate verification of AI workloads possible.