Sotnyk.етн

@realbarnakiss Awesome. How can I take part?

yes and now in two places, cross-experiment and intra-experiment. Agents see previous iterations, we have a near miss classification to surface past tries (1.5% regression, probably this can be optimized later to be more narrow) Outside of provers one idea could be LoC minimization for better auditability. I think autoresearch is first implementation of a larger pattern of new program designs, likely with multi-agent orchestration, but distinct from OpenClaw direction (though sharing similarities).

Round 2 of zk-autoresearch: Claude ran 20 iterations autonomously optimizing Plonky3's DFT/NTT. We stopped after 20 iterations. Found key agent-infra improvements meant further iterations would waste tokens without new signal. 4 improvements kept. 16 reverted. Cumulative speedup from baseline across Round 1 + Round 2: 4.1% The 2^22 result (−8.57%) was an outlier, memory bandwidth effects amplify when working sets exceed L3 cache. Full results in the table above. The repo was first starred by @drakefjustin (EF). The most interesting finding was a runaway agent: The agent discovered an incentive misalignment: failing to write grants another 20k token budget. So it kept failing. Iter 10 ran for ~30 minutes and consumed an estimated 150k+ tokens before writing code. In the end it submitted a regression of -1.22%, specifically exploring what we have decided to characterize as a dead-end for the next experiment in CLAUDE.md. The agent persisted in submitting 50k-character rewrites of radix_2_dit_parallel.rs instead of targeted fixes. - Agent was stuck for optimizations and defaulted to full rewrites instead of surgical improvements — updated agent-infra to prevent this in the next experiment - Optimizing a prover is inherently different from Karpathy's target: his setup is a continuous, differentiable parameter space. Ours: discrete code changes, bitwise-correct ZK constraints, compiler behavior shaped by CPU microarchitecture. The cliff between "compiler handles it" and "code regresses" is steep. - Model scaling would improve output, but risks masking existing shortcomings, the current decision is to optimize agent-infra until clear signs show Sonnet is not capable, then yield those benefits with model scaling once fixes are validated All 20 iterations respected hard constraints, no interface changes, no security parameter touches. The Plonky3 team added new testing in PR-1494 that we incorporated for experiment 2. @CreatorsOfChaos reviewed the methodology and flagged real gaps: tests run in debug not release, benchmark workload never tested for correctness directly. We are working through the issues publicly, most of them have been addressed by today's PRs. For Round 3 we have implemented: - Streaming: agent reasoning visible live, full thinking saved to experiment log - Supply chain resilience and audit trail + testing - Loop reliability, static diff inspection, three-stage correctness gate - Cross-experiment agent memory, surgical precision and documented proven techniques $153.25 across 2 experiments. ~$1.09/iter on Sonnet. Opus comes after Sonnet infrastructure is fully validated; every dead end mapped on Sonnet is an Opus iteration saved. We have received two offers for contributions, one small grant and one LLM contribution. Repo is open for contributions, we are mainly interested in: - Potential security vectors - Generalization ideas - Agent-infra improvements The roadmap: - Optimize on Sonnet, shift to Opus - Expand to other crates on Plonky3 and start initial generalization - Expand to other prover repos with easy setup; this requires significant work on generalization frameworks Feel free to message if you want to contribute. Link to repo: github.com/Barnadrot/zk-a… 14 issues have been opened, one of them is an upstream improvement for the Plonky3 repo (pending submission) Link to round 1 PR on Plonky3 repo: github.com/Plonky3/Plonky… Round 2 changes can be tracked on the fork currently (pending upstream submission) github.com/Barnadrot/Plon…

@realbarnakiss So it's safe to assume that you're fine-tuning the model. Except you're not updating the weights directly, but store them in markdown. That's a very cool idea! I'm wondering what other cases could be approached with this technique.

@d3magexgod Loop starts fresh, the setup is split between CLAUDE.md (upstream repo related) and loop.py (agent logic related) Yesterday we have added cross-experiment memory to the system, Round 3 will have info about previous rounds.

@JKim_Tran This is too funny

I hate it when people are like, "explain this to me like I'm 5 years old." Like, no, there are lots of things that I'm not going to explain to a 5-year-old.

@alexanderlee314 It is not, they traded the number of qubits for the number of gates. Still not viable anytime soon.

Q day is likely closer than many would expect…

@real_philogy based and plankpilled

Excited for our first grant and to finally get to work on stack scheduling again. The new algo will draw on insights from academia, my experience hand writing contracts in Huff, my balls prototype (github.com/philogy/balls) and more.

The deepfake problem can't be solved in software. I mean this literally - if the forgery happens before data is signed, no algorithm, no watermark, no certificate can help you. The fix has to be in the hardware. And hardware is hard but that's what we built:

I built ZK selective disclosure for eIDAS 2.0 credentials. zk-eidas.com — 15 Circom circuits, Groth16, ECDSA P-256 in-circuit. Contracts without personal data. Proofs print on paper. Verify with a phone camera. Offline.

@oleh_bc I don't think that we'll have such capabilities in the near future. Would be cool to, though.

@d3magexgod I mean instant LLM output for vibe coding. You get the whole new project on each keystroke

Imagine a real time LLM. On each key stroke, you get a new improved version of your app. A massive unlock. Is there something like this on the market?

@cartoonitunes You're my favorite history channel. Thank you very much!

In September 2015, someone at the Ethereum Foundation deployed a 57-byte contract to mainnet. No compiler. No tooling. Just raw bytecode written by hand. Just cracked it using Yul and wanted to share because it’s an interesting window into early development 🎉 🧵

@archethect Gud stuff, I always wondered why no one asked the models to shut up and confirm what they imagined. What models did you use in your test setup? Two instances of Claude?

The problem was never "can AI find bugs." It always could. The problem was "can AI shut up about bugs that aren't real." Turns out you just needed a second AI whose entire purpose is to call bullshit. sc-auditor V2 is live, open source and a substantional improvement over V1 at that! 👇 github.com/Archethect/sc-…

I spent weeks trying to solve one problem: AI auditors find bugs. They also hallucinate bugs that don't exist. Security researchers know this. It's why most dismiss AI auditing tools. So I asked: what if the AI had to prove itself wrong before it could prove itself right? 🧵👇

Ethereum needs an Encrypted Mempool and it needs it fast. It's not just about stopping sandwiching. Encrypted mempools are how Ethereum matures its onchain markets. I just published a post on why Ethereum needs encrypted mempools. Here are the core arguments:

@fileverse @aboutcircles yeah, I was talking about Collab with gnosis, too bad I missed it STILL LOVING YOU

@d3magexgod AWWWWWW 💃💛 Tyyy anooon! Ur using both the gnosis app and ddocs dot new? 💾For the custom @aboutcircles floppy: it was a one time collab with them! 💾If a new custom floppy drops on the gnosis app: would you want us to ping you?

hey @fileverse I love you! is there a chance you will resupply fileverse disks on circles?

@philogy @andreaslbigger You know, this feels like a discovery week for me. Firstly, Plank, then Ora, now this.

@andreaslbigger Holy, very cool. Edge is also one of my inspirations for Plank. You plan on maintaining/building this long-term?

Introducing Edge, a high level, strongly statically typed, multi-paradigm domain specific language for the Ethereum Virtual Machine (EVM). github.com/refcell/edge-rs

@Logicb0x @philogy @plankevm Thank you so much for the response! I'll certainly try it out tomorrow ;)

@philogy @d3magexgod @plankevm Ora uses Plank (aka Sensei IR) to lower to bytecode. They are connected but have different roles. You can think Ora as a modern take on Refinements, SMT formal verification and strong comptime. TLDR: Ora helps you every step of the way. Ora loves auditors :D

Our first blog post is up! We explain our high-level vision, design & roadmap. 🏗️ plankevm.github.io what happened to the website design? sorry no time, we need to get back to shi— 🚀💻

@philogy @plankevm This reminds me of Yul and Solidity. Solidity implicitly adds some checks to the bytecode, and Yul just works as you've written. Thanks. Looking forward to new updates!

They share some similarities (e.g. some comptime overlap) but the way I see it: Plank prioritizes raw capabilities & features first but in exchange will force the dev to build more things from scratch (at least initially). While Ora is more high-level & batteries included and is prioritizing refinement types + first class SMT-based formal verification. but maybe @Logicb0x has a different take

Almost forgor to fill out the annual Solidity survey!