Dennis Won denniswon
denniswon
/ gist:c9e73e39e14f8de1230d4253f46f6bda
Created
April 24, 2026 14:14
Private Data Storage - Subproject B
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| ⏺ You're right — I was stuck in the wrong substrate model. Let me course-correct. | |
| ★ Insight ───────────────────────────────────── | |
| - I was treating "state tree" as the private-data substrate and "EVM contract storage" as the public-data substrate, as if Sub-project A's | |
| fabric didn't apply here. It does apply. The state tree is a content-addressed key-value store with on-chain root commitments — it has nothing | |
| inherently private about it. Encrypted leaves = private data (Sub-project A's SecretsRegistry); plaintext leaves = public data (Sub-project B's | |
| artifacts). The substrate is the same, only leaf encryption differs. | |
| - On-chain, we only ever need the hash + root commitments. For a specific task, NewtonPolicy.policyCodeHash already commits to the Rego bytes — | |
| any fetcher verifies keccak256(bytes) == policyCodeHash and that closes the integrity loop regardless of where bytes live. For registry-level | |
| questions ("is this plugin still approved?"), the 120s BLS-signed state root + inclusion proof |
denniswon
/ gist:2d46eb407984d546b7a4cd8e230a1326
Created
April 22, 2026 20:17
Private Data Stroge - Round 2
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| ⏺ You're right — I was stuck in the wrong substrate model. Let me course-correct. | |
| ★ Insight ───────────────────────────────────── | |
| - I was treating "state tree" as the private-data substrate and "EVM contract storage" as the public-data substrate, as if Sub-project A's | |
| fabric didn't apply here. It does apply. The state tree is a content-addressed key-value store with on-chain root commitments — it has nothing | |
| inherently private about it. Encrypted leaves = private data (Sub-project A's SecretsRegistry); plaintext leaves = public data (Sub-project B's | |
| artifacts). The substrate is the same, only leaf encryption differs. | |
| - On-chain, we only ever need the hash + root commitments. For a specific task, NewtonPolicy.policyCodeHash already commits to the Rego bytes — | |
| any fetcher verifies keccak256(bytes) == policyCodeHash and that closes the integrity loop regardless of where bytes live. For registry-level | |
| questions ("is this plugin still approved?"), the 120s BLS-signed state root + inclusion proof |
denniswon
/ gist:44c9b2f407a0f8cd0790b464698324e0
Created
April 17, 2026 20:10
Streaming consensus re-evaluation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| ❯ Refer to @docs/STREAMING_CONSENSUS.md , that contains our architectural improvement design for improving the performance / latency / | |
| efficiency of the protocol. recall from previous memory about our discussion, analysis, trade offs, decision choices and rationales. We | |
| will go back to this architectural design and critically re-evaluate the architecture and design decisions from the first principle, | |
| evaluating against other approaches in terms of performance, latency, reliability, scalability, throughput, security, fault tolerance, | |
| and (least prioritized) decentralization | |
| ⎿ Read docs/STREAMING_CONSENSUS.md (1772 lines) | |
| ⎿ Loaded docs/CLAUDE.md | |
| ⏺ I'll invoke the brainstorming skill to properly evaluate this design against alternatives from first principles. |
denniswon
/ gist:4ad3289b280121723668ea7f908eb855
Created
April 17, 2026 05:17
Protocol Version Compatibility enforcement test
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| The goal of prevent developers in the team accidentally forget to make sure the Rust code to be compatible to both old vs new | |
| contract versions. There are 3 scenarios: 1) contracts upgraded first with breaking change before Rust update 2) contracts with | |
| breaking change not upgraded yet, but Rust deploys, 3) contracts upgraded and Rust update also deployed, but for Newton | |
| Policy/Newton Policy Data/and Policy Clients (that extends NewtonPolicyClient mixin), there is a grace period for the developers | |
| to migrate/update their policy clients with new newton policy or policy data. This means the Rust update that pairs with the | |
| contracts upgrade with breaking change should support both versions during this grace period (until version enforcement happens). | |
| 1, 2 are for prevent protocol literally failing, while 3 is for external developer's policy clients to start failing suddenly | |
| without having time to become compatible. /clarify-plan THINK HARD | |
| ⏺ I'll work through this as a design problem. The three s |
denniswon
/ gist:8ca54e7621adf642e5948676c490d9d1
Created
April 15, 2026 21:23
Octane Critical Findings Resolution
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| ⏺ Review posted: https://github.com/newt-foundation/newton-prover-avs/pull/541#pullrequestreview-4116329428 | |
| Three inline comments, state CHANGES_REQUESTED: | |
| 1. Gap 1 (blocker) on ChallengeVerifier.sol:156 — Critical 4 is only half-fixed. The hash-encoding mismatch is resolved, but the | |
| proof-to-canonical-code binding (sub-issue 5b in Octane's report) remains open. raiseAndResolveChallenge and | |
| slashForCrossChainChallenge bind to policy.getEntrypoint() but never to policyCid or equivalent code digest — a malicious challenger | |
| can craft a proof evaluating different Rego code sharing the same entrypoint and slash honest operators. | |
| 2. Gap 6 (high) on ChallengeVerifier.sol:513 — after the try/catch in challengeDirectlyVerifiedMismatch, the slashing path decodes | |
| NonSignerStakesAndSignature from untrusted signatureData. Unlike raiseAndResolveChallenge, there's no validateSignatoryRecord bind — a |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| how do I publish newton-cli? | |
| Searched for 2 patterns, read 1 file, listed 1 directory (ctrl+o to expand) | |
| ⏺ Here's the honest answer: there is currently no path to publish newton-cli — and it's blocked by three distinct issues, some of which | |
| are hard blockers. | |
| Blockers | |
| 1. License is not accepted by crates.io (hard blocker) |
denniswon
/ gist:8a55e803f87d96eca546ac7aeea8297a
Created
April 14, 2026 14:38
Gateway Scalability & Throughput Analysis
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| --- | |
| Gateway Scalability & Throughput Analysis | |
| End-to-End Flow Timeline | |
| Here's the create_task critical path with approximate timings: | |
| Client Request | |
| │ | |
| ├── Phase 0: Request Setup ..................... ~1-5ms |
denniswon
/ gist:06d1c34ba5ca47a4fcfefc4de1ef49bf
Created
April 10, 2026 22:33
TEE Integration for Newton Protocol
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| --- | |
| Meeting: TEE Integration for Newton Protocol | |
| --- | |
| Problem Statement | |
| Newton Protocol accumulates sensitive data (identity PII, confidential data, policy client secrets) that operators must decrypt and | |
| process during policy evaluation. Two core concerns: | |
| 1. Operator data leakage — operators currently decrypt private data locally, meaning a malicious or compromised operator could exfiltrate |
denniswon
/ gist:a5e55a5d515bb7234f550647df5cbc3a
Created
April 10, 2026 13:14
Pipelined Batch Transaction Submitter
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| one question: does the contract revert only detectable from transaction receipt? or can it be detected from just sendTransaction? | |
| currently, the problem with batch tx submission is that it is a single loop, sequential process with retry. Instead, let's explore | |
| pipelining architecture where the initial submission of the batch doesn't block, and the failures are handled on a separate queue | |
| (will we need a failed tx handling dedicated task generator signer key that is separate from the main submission signer key?) | |
| /clarify-plan | |
| ⏺ Skill(/clarify-plan) | |
| ⎿ Successfully loaded skill | |
| ⏺ Good questions. Let me first answer your initial question, then clarify the design space. |
denniswon
/ gist:28aa29640e8e9eb6677a6e175a013834
Created
April 9, 2026 13:51
Newton Privacy Layer — Known Limitations & Next Steps
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Here's the full picture: | |
| --- | |
| Newton Privacy Layer — Known Limitations & Next Steps | |
| ★ Insight ───────────────────────────────────── | |
| The limitations fall into three buckets: (1) security gaps where the system doesn't enforce what it should, (2) trust assumptions | |
| where centralization remains, and (3) missing infrastructure that blocks future phases. Each has a clear resolution path — none are | |
| architectural dead ends. | |
| ───────────────────────────────────────────────── |
NewerOlder