Skip to content

demos: encrypted loan approval + encrypted compliance (FHE ↔ precompile bridge)#2

Open
abhicris wants to merge 1 commit intoluxfi:mainfrom
abhicris:demos/encrypted-compliance-precompile-bridge
Open

demos: encrypted loan approval + encrypted compliance (FHE ↔ precompile bridge)#2
abhicris wants to merge 1 commit intoluxfi:mainfrom
abhicris:demos/encrypted-compliance-precompile-bridge

Conversation

@abhicris
Copy link
Copy Markdown

Closes #1.

What this adds

Two CLI demos plus an illustrative Solidity interface that bridge cmd/demos/ off-chain Go calls to the on-chain luxfi/precompile FHE address space documented in LLM.md.

  • cmd/demos/encrypted-loan-approval/main.go — standalone CLI (not HTTP). Encrypts two 8-bit inputs (credit score, DTI), evaluates score >= min AND dti < max on ciphertexts only, threshold-decrypts the single boolean verdict. Prints per-gate timing + plaintext cross-check.
  • cmd/demos/encrypted-compliance/main.go — off-chain Go twin of the Solidity interface; runs an income-threshold gate + jurisdiction-not-blocked gate against luxfi/fhe directly.
  • cmd/demos/encrypted-compliance/solidity_interface.sol — illustrative EVM-side contract mirroring the Go gates through IFHEPrecompile (FHEGe, FHENe, FHEAnd, TrivialEncrypt, IFHEDecrypt.decrypt/.reveal). Comments point to the 0x02000000…0083 address range in LLM.md. Not meant to deploy — reviewers read both files side-by-side to see the symmetry.
  • cmd/demos/README.md — new §8 and §9 entries + a "FHE ↔ Precompile Bridge" section with the Go ↔ precompile mapping table and a short rationale for CLI-mode vs the existing server-mode demos.

Why these two, given existing demos

Reviewers of cmd/demos/ can see seven excellent runnable exhibits of the Go library (dark pool, compliance, marketmaker, auction, voting, nav, proof), but nothing that shows how the same gates land on the EVM side. These two fill that gap:

  • encrypted-loan-approval covers a new domain (credit/lending) not modelled by any existing demo.
  • encrypted-compliance is deliberately a different slice from cmd/demos/compliance/ — it's single-shot (income + jurisdiction) rather than the SEC-diversification portfolio service that exists today, and it's paired with a Solidity twin in the same directory so the Go ↔ Solidity mapping is obvious from one ls.

What it does not touch

  • No changes to TFHE core (fhe.go, encryptor.go, evaluator.go, decryptor.go, integer-ops, NTT).
  • No changes to any of the existing seven demos or their HTTP routes.
  • No new top-level deps — uses only github.com/luxfi/fhe itself, from the existing go.mod.
  • Parameter set is PN10QP27 throughout, matching the rest of cmd/demos/.

Local validation

All commands run against this branch (GOTOOLCHAIN=auto, Go 1.26.1):

  • go build ./... — clean.
  • go vet ./... — clean.
  • go run ./cmd/demos/encrypted-loan-approval → approved=true in ~11s, plaintext cross-check passes.
  • go run ./cmd/demos/encrypted-loan-approval -score 120 -dti 50 → approved=false in ~7.5s, cross-check passes (negative path).
  • go run ./cmd/demos/encrypted-compliance → compliant=true in ~5.5s, cross-check passes.

Per-gate timing printed by the demos matches the numbers already documented in cmd/demos/README.md § Performance (8-bit compare ~3–7s, single gate ~100ms).

CLA

Noted in README.md that the sibling luxfi/lattice repo expects a CLA via lattice@lux.network. I haven't emailed proactively per my standing policy. Happy to sign whatever luxfi/fhe maintainers point me to. Prior contributions to adjacent luxfi repos as a track-record reference: luxfi/mpc#2, luxfi/threshold#8, luxfi/threshold#9.

Scope adaptations from the issue

One: the analysis that drove this PR originally called for the encrypted-compliance demo to exercise precompile-mock calls in Go. After reading the existing cmd/demos/compliance/ (which already covers SEC diversification via the hanzoai/base HTTP framework) I pivoted the second demo to a different, single-shot compliance slice (income + jurisdiction) paired with a co-located Solidity twin — this avoids overlap with the existing HTTP demo and makes the Go ↔ Solidity mapping explicit from the directory layout. Documented in the README under "FHE ↔ Precompile Bridge".


Part of open-source blockchain work from kcolbchain.com — maintained by Abhishek Krishna. Contributed by kcolbchain (https://kcolbchain.com) · https://abhishekkrishna.com.

…ompile bridge)

Two CLI demos plus an illustrative Solidity interface that close the loop
between cmd/demos/ Go calls and the on-chain luxfi/precompile FHE address
space documented in LLM.md.

- cmd/demos/encrypted-loan-approval/main.go — standalone CLI: encrypts two
  8-bit inputs (credit score, DTI), evaluates `score >= min AND dti < max`
  on ciphertexts only, decrypts the single boolean verdict. Prints per-gate
  timing. Includes plaintext cross-check.
- cmd/demos/encrypted-compliance/main.go — off-chain Go twin of
  solidity_interface.sol; runs income-threshold + jurisdiction-not-blocked
  gates against luxfi/fhe directly.
- cmd/demos/encrypted-compliance/solidity_interface.sol — illustrative
  Solidity interface mirroring the Go gates through IFHEPrecompile (FHEGe,
  FHENe, FHEAnd, TrivialEncrypt, IFHEDecrypt.decrypt/reveal). Comments
  point to the 0x02000000...0083 address range in LLM.md.
- cmd/demos/README.md — new entries 8 and 9, plus a "FHE ↔ Precompile
  Bridge" section with Go ↔ precompile mapping table and a rationale for
  CLI mode vs the existing server-mode demos.

No changes to TFHE core, no changes to existing demos, no new deps. Uses
PN10QP27 to match the rest of cmd/demos/. Both demos run end-to-end
locally in ~5–12s on Apple M-series and agree with a plaintext cross-check.

Closes luxfi#1.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

demos: encrypted loan approval + FHE↔precompile bridge story

2 participants