La brecha de la privacidad: comparando el modelo de cifrado de Newton con los sistemas de verificación de conocimiento cero

Ho Vinh Thanh · 2026-07-14T05:27:23.000Z

Me registré para una prueba en un gimnasio el mes pasado y me entregaron una tarjeta tipo llavero que solo funcionaba en el casillero número 14, y solo entre las 6 y 8 a. m. No el casillero 15, no el cuarto de vestuario de abajo, no después de que terminara mi sesión. La tarjeta en sí no era el secreto. Cualquier miembro podía sostener un rectángulo de plástico. El secreto era la combinación del código de la tarjeta, el número del casillero y la franja horaria. Si lo intentaba en el casillero equivocado, el lector pitaba en rojo. Si lo intentaba al mediodía, lo mismo. El punto estaba en el encaje. El gimnasio no necesitaba saber qué escondí dentro, una toalla, una cartera, una laptop. Solo necesitaban asegurarse de que solo la persona correcta abriera la puerta correcta en el momento correcto.

I signed up for a gym trial last month and they handed me a keycard that only worked on locker number 14, and only between 6 and 8 AM. Not locker 15, not the changing room downstairs, not after my session expired. The card itself wasn't the secret. Any member could hold a plastic rectangle. The secret was the combination of the card's code, the locker number, and the time window. If I tried it on the wrong locker, the reader beeped red. If I tried it at noon, same thing. The binding was the point. The gym didn't need to know what I stashed inside, a towel, a wallet, a laptop. They just needed to make sure only the right person opened the right door at the right time.
That kind of binding to context is what Newton's SecureEnvelope does for sensitive transaction data. Before a user submits an intent that might involve KYC documents, financial records, or compliance proofs, they encrypt that data locally using HPKE, the Hybrid Public Key Encryption standard from RFC 9180. The system's threshold X25519 public key wraps the plaintext into a ciphertext. But the encryption alone isn't the clever part. The clever part is that the resulting envelope, a JSON structure with enc, ciphertext, policy_client, chain_id, and recipient_pubkey, is also bound to a specific execution context through AAD, additional authenticated data. The docs specify that the AAD is keccak256 of the packed policy_client bytes and chain_id. The AEAD layer, ChaCha20-Poly1305, authenticates this AAD alongside the ciphertext. If someone intercepts that envelope and tries to submit it to a different PolicyClient, or replay it on a different chain, the authentication tag fails. The decryption doesn't just fail politely. It fails cryptographically. The context is baked into the math.
So the SecureEnvelope hides the plaintext from anyone without the decryption key, and it locks the ciphertext to a specific destination. You can't move it. The gym card works only for locker 14 at 7 AM.
RISC Zero's zkVM takes the other fork in the road. Instead of encrypting data and binding it to a specific validation context, it proves that a computation ran correctly over private inputs without ever showing those inputs. You write a program that runs inside the zkVM. It takes public inputs and private ones. The zkVM generates a proof, a small cryptographic artifact, that says this program, given these public inputs and these hidden private inputs, produced this specific output. The proof can be verified on chain by a verifier contract. The private inputs never leave the zkVM. The verifier learns the output and the fact that the computation was correct, nothing more.
I don't have RISC Zero's docs open, so I'm working from what I've gathered. My understanding is that proof generation is computationally heavy, though it's getting faster, while on chain verification is cheap and constant sized. Newton's HPKE encryption is fast, client side, and the operator decryption during consensus adds latency from the threshold share exchange, not heavy per-operator computation. The work just lands in different places.
The deeper split is about whether the data needs to be seen at all during evaluation. Newton's model assumes a quorum of operators must briefly reconstruct the plaintext in memory, under strict conditions: threshold DKG ensures no single operator has the full key, and dual Ed25519 authorization requires both the user and the dApp to sign off before decryption. The data is seen, but only collectively, and only for the specific PolicyClient and chain the user intended. The AAD enforces that context. This makes sense when the policy evaluation requires inspecting the data, cross-referencing KYC fields, checking names against a sanctions list, comparing financial figures. The operators need to read the plaintext to run the Rego rules.
RISC Zero's zkVM assumes no one should see the data except the prover. The verifier trusts the proof, not the prover. There's no operator collusion risk because no third party ever touches the plaintext. But the computation must be expressible as a program that fits inside the zkVM's constraints. If the policy logic is complex, branching, pulling from multiple data sources, that might be hard to prove in a zero-knowledge circuit without significant engineering. Newton's Rego policies can be as complex as needed, evaluated in plain memory by operators.
I keep wondering about Newton's key lifecycle. The docs say the threshold keypair is regenerated during DKG ceremonies only when the operator set changes, not per task. But if the key rotates, what happens to envelopes encrypted under the old key? Are old key shares retained to decrypt previously uploaded data, or do those envelopes become permanently unreadable? The docs don't say. If old keys are discarded, encrypted data has a shelf life tied to operator set stability. That might be acceptable if the data is ephemeral, tied to a single policy evaluation. But it would be a problem for stored identity data referenced across multiple tasks. I'd guess there's some form of key versioning, but I haven't found that detail.
The choice between these two models isn't about which technology is newer or faster. It's about whether you can afford to let a quorum of operators see the plaintext at all. Newton says yes, as long as the decryption is threshold-gated and context-bound. RISC Zero says no, and shifts the trust to the proof system. The gym trusts that the keycard system correctly binds the code to the locker and time, but they never need to look inside. The ZKP approach would be like proving you have the right to open the locker without ever showing the card, just a mathematical proof that you know the code. The gym would trust the proof, and your belongings stay hidden. But if the gym needed to check what's inside, because the policy requires no outside food or something, they'd need to open it. That's where Newton's model fits. Sometimes the verifier needs to see what's inside, not just know it's valid. I'm still not sure how often that need actually arises. The answer probably depends on how much of the world's compliance logic can be expressed as verifiable predicates versus how much requires a human-like inspection of data. That line is still blurry.

@NewtonProtocol #Newt $NEWT 