I want to share a concept I’ve been developing and get feedback from this community specifically — because the people here are exactly who this needs to be stress-tested by.
The core idea: Arcanum is a proposed compiler layer where source code privacy is treated as a first principle. Developers write in the language they already know (C++, Rust, JavaScript, TypeScript, Go — anything LLVM or RISC-V compatible). Arcanum transforms it. Plaintext source never exists post-compilation.
Two-phase approach:
Phase 1 — TEE: Compiled code is wrapped inside hardware-enforced secure enclaves (Intel SGX, AMD SEV, ARM TrustZone). The source logic is unreadable even to the server owner or cloud provider. Near-native performance. Trust assumption: hardware manufacturer.
Phase 2 — ZK: As ZK compiler infrastructure matures, Arcanum transitions to transforming source into STARK-based arithmetic circuits — mathematically unreadable without the original source, no trusted hardware required, post-quantum resistant. Trust assumption: none.
The distinction from existing ZK tooling: zkLLVM, RISC Zero, and SP1 focus on verifiable execution — proving code ran correctly. Arcanum focuses on a different question: can the source code itself be made permanently unreadable, while remaining provably executable? Two different problems, two different architectures.
Honest limitations I’m aware of:
Phase 1 places trust in hardware manufacturers (Intel/AMD/ARM)
Compiler-level bugs could expose intermediate representations
Insider threats (developer leaking source) are out of scope
Side-channel attacks are only partially mitigated
This is a pre-MVP conceptual whitepaper. I’m a non-technical founder — the architecture needs ZK and compiler engineers to pull it apart. That’s exactly why I’m here.
What am I missing at the cryptographic or compiler level? Is the TEE → ZK transition path realistic, or does it have fundamental blockers I haven’t considered?
That’s a really precise and fair distinction — thank you.
You’re right. On the verifier side, ZK already handles this. And on the prover side, you’re correct that someone must execute the computation and therefore “sees” the logic at some level.
This is exactly why the current version of Arcanum proposes TEE (Trusted Execution Environments) as the Phase 1 approach — the prover runs inside a hardware enclave (Intel SGX, AMD SEV) where even the operator of the machine cannot observe the computation. It’s not a cryptographic guarantee, but a hardware-enforced one.
The honest limitation: TEE places trust in the hardware manufacturer. Phase 2 (ZK) would address the verifier side more formally — but you’ve identified the core unsolved problem for the prover side correctly. That’s an open research question.
Does TEE-based execution change your assessment at all?
One follow-up: the layer I’m most interested in is the developer experience side. zkSTARK and TEE both exist as technologies, but neither is transparently integrated into a general-purpose compiler layer where a developer writes normal code and gets source privacy automatically — without learning ZK theory or configuring enclaves manually.
Would you consider that integration layer genuinely novel? Or does something already exist that solves this developer-facing problem?
No. Your proposal changes nothing on the cryptographic protocol (as per my previous message) and changes nothing with regard to TEEs. I might be wrong but I don’t think the integration between the two needs anything new to be built: if you’ve got a TEE just run your prover there, period.
I don’t think there’s anything to consider. You got a TEE? Run your zkSTARK prover there and you’re done.
Thanks for the direct feedback — I think there may have been a framing misunderstanding on my end.
I’m not claiming any cryptographic innovation over zkSTARK or TEE. You’re right that both technologies already exist and can be combined. That was never the proposal.
Arcanum’s focus is cybersecurity — specifically, making source code privacy accessible to any software team, without requiring them to understand ZK theory or configure TEE infrastructure manually. The innovation, if it can be called that, is on the tooling and developer experience layer — not the cryptographic protocol layer.
I posted here because the ZK component is part of the long-term architecture, and this community seemed like the right place to get feedback on whether that direction makes sense. Clearly it raised some valid questions, which I appreciate.
I posted here because this community has exactly the kind of expertise — ZK researchers, compiler engineers, cryptographers — that this project needs to be stress-tested by. Finding potential collaborators and advisors here was part of the goal from the start.
You don’t need a background in zero-knowledge tech to run a program on a computer that you consider trusted. zkSNARKs & zkSTARKs are non-interactive, so you don’t even need to be connected to the internet while proving. You can generate your proof or proofs offline on an air-gapped machine. You don’t even need specialized hardware.
On a more sad note, this community might not quite be what you think it is. Personally I find the state this forum has fallen into through the last couple of years fairly depressing. Take a look around, the vast majority of what you see is copy-pasted, overly verbose, ChatGPT slop (for some reason anyway). Then you get valid proposals once in a while, such as this one, and they are promptly ignored. Then Vitalik or the EF show up once in a while and all they do is announcing their research, not conducting it here. I don’t think a public Ethereum research board exists any more.
Thanks for noticing my topic, old partner. What you said is why I never came back to it. I even mantioned them and they never looked at my proposal.
To add to your thought, I don’t think even the EIPs, and Ethereum Magician’s community exist as a community anymore.
The AL slop has ruined everything
Thank you so much for taking the time to explain all of this — your clarifications across this thread have been genuinely invaluable, both technically and about the state of this forum.
Your point about air-gapped machines actually opened up a new perspective for me on the user side of Arcanum. And your honesty about the forum is something I deeply appreciate — it’s rare to find someone who engages this seriously and candidly.
I hope our paths cross again — whether here or elsewhere. If you’re ever curious about how Arcanum evolves, or if you’d like to share any further thoughts, I’d genuinely welcome it.
The developer experience layer is definitely the holy grail here. The biggest friction point in building privacy focused infrastructure on Ethereum is that general purpose code like Rust or C++ relies heavily on dynamic memory allocation and unbounded loops. Zero knowledge circuits demand strict bounded limits and completely deterministic execution paths. A compiler layer that abstracts this away without forcing developers to manually rewrite their core logic would be a massive breakthrough.
To give a concrete example from Ethereum rollups and zkEVM architectures, managing state transitions and arbitrary data structures without explicit circuit bounds creates massive prover overhead. Current Ethereum zero knowledge frameworks tackle circuit constraints by requiring developers to write custom domain specific languages or strictly constrained smart contracts. If Arcanum allows completely arbitrary source code, moving from a Trusted Execution Environment to STARKs will face severe computational bottlenecks when translating dynamic memory into arithmetic circuits.
I would love to hear your thoughts on how Arcanum plans to handle this dynamic memory bottleneck at the compiler level.
Thank you for this — this is exactly the kind of technical stress-testing I was hoping for when I posted here.
You’ve put your finger on what I consider the central open problem in Arcanum’s Phase 2 architecture. The dynamic memory and unbounded loop challenge is real, and I won’t pretend to have a solved solution at this stage.
My current thinking is that the TEE phase isn’t just a stopgap — it’s precisely because this bottleneck exists that TEE makes sense as Phase 1. It sidesteps the circuit constraint problem entirely while still delivering meaningful source code privacy guarantees.
For the ZK transition, I see two directions worth exploring: either the compiler layer enforces bounded memory regions at compile time (accepting some constraints on what code can be written), or we lean on newer STARK-based systems like RISC Zero that are making progress on general-purpose execution traces with acceptable prover overhead.
I’d genuinely welcome your thoughts on which direction seems more viable — or whether there’s a third path I’m missing.
I appreciate the detailed response and the transparency regarding the current architectural limits @sidistr, Both directions you outlined highlight the classic tradeoff between developer flexibility and prover efficiency.
Enforcing bounded memory at compile time is definitely the most pragmatic short term approach. However, it risks turning a general purpose language into a highly constrained environment. If developers are forced to manually track bounds or rewrite core logic, we lose the seamless developer experience that makes Arcanum appealing in the first place.
Relying on newer STARK based systems like RISC Zero is incredibly promising. General purpose ZKVM architectures are rapidly pushing the boundaries of what execution traces can handle. But as you noted, the prover overhead for dynamic memory operations and unbounded loops remains a massive bottleneck for production environments today.
If we are exploring a third path, I highly recommend looking into a state separation model paired with a hybrid coprocessor architecture. Drawing inspiration from modern privacy focused networks, the compiler could segment the codebase automatically under the hood. The core deterministic and state critical logic gets compiled directly into strict cryptographic circuits. Meanwhile, the unbounded dynamic memory allocations and complex loops are handled via the Trusted Execution Environment or processed using verifiable offchain computation with cryptographic hints. This allows you to use STARKs strictly for state verification while leveraging the Trusted Execution Environment for heavy memory management.
Another technical avenue worth tracking is the recent advancement in lookup arguments, specifically Jolt and Lasso architectures. These models bypass traditional arithmetic constraints for complex memory operations, which could drastically reduce the prover overhead of general purpose execution traces when Arcanum fully transitions to zero knowledge proofs.
Your phased rollout is a very sound strategy. Building the developer experience layer with a Trusted Execution Environment first allows you to capture the market and build tooling while the underlying cryptographic circuits and ZKVM technologies mature.
This is exactly the kind of architectural thinking Arcanum needs — thank you.
The state separation model you’re describing is fascinating and honestly more elegant than either path I outlined. Automatically segmenting deterministic logic into strict ZK circuits while offloading dynamic memory to TEE under the hood — this is very close to what the compiler layer should be doing, and I hadn’t framed it this cleanly before.
I’ll be looking into Jolt and Lasso immediately. The idea that lookup arguments could bypass traditional arithmetic constraints for memory operations is a potential game changer for Phase 2.
Your point about capturing the market during the TEE phase while ZK matures is also exactly the strategic logic behind the phased rollout — it’s reassuring to hear it validated from someone with this depth of knowledge.
Would you be open to staying in touch as Arcanum’s architecture evolves? Your input has been genuinely invaluable. If you’re open to it, I’d love to continue this conversation outside the forum — mertatakan53@gmail.com
Apologies for the delayed response! I’m glad to hear the state separation and coprocessor concepts resonated. I completely agree that a phased approach is the most strategic way to capture the market right now.
I would absolutely be open to staying in touch. I’ll shoot you an email shortly so we can continue the conversation there. Talk soon!
