Discussion: Low-latency on-chain RNP / BFTRAND-style randomness for Neo (dBFT + NeoVM)

[cschuchardt88]

Summary

Discussion / design tracking for a secure, low-latency random number provider (RNP) for Neo smart contracts, adapting the BFTRAND research to Neo N3 (dBFT + NeoVM).

Credits

• Research foundation: @Jim8y — BFTRAND: Low-latency Random Number Provider for BFT Smart Contracts (DSN 2024)
• Paper PDF (attached as repo reference): dsn2024-bftrand-paper389.pdf (raw download)
• Neo engineering design plan: bftrand-neo-rnp.md (gist mirror)

---

Problem

dApps need unpredictable, unbiased, unique randomness (NFT rarity, games, lotteries, fair distribution). On a deterministic ledger, weak RNGs are unsafe.

Commit–execute RNPs (status quo for “secure” systems)

Typical flow (Chainlink VRF / DRAND-style):

1. T_commit — lock request
2. Wait for entropy
3. T_execute — consume revealed random

Costs: two consensus rounds, two fee-paying txs, extra on-chain data.

Today on Neo

System.Runtime.GetRandom (post-HF_Aspidochelone) uses tx-hash / Murmur128 iteration. It is useful but not a consensus DRB-backed RNP and does not address post-reveal undo attack classes.

---

Paper proposal (BFTRAND) in short

Integrate a Distributed Random Beacon (DRB) into BFT consensus:

1. Each consensus round produces beacon σ (threshold BLS partials → combine).
2. Contracts call randomness in the same round as the requesting tx (no second tx).
3. Target properties: pseudorandomness, uniqueness, availability, irreversibility.
4. Explicit Post-reveal Undo Attack (PUA) taxonomy, including Script PUA (highly relevant to NeoVM).

Reported evaluation (paper; Neo-oriented prototype)

Metric	Claim
Fee vs commit–execute multi-draw	≥ ~89% savings in evaluated scenarios
On-chain BO vs commit–execute	up to ~76% less in large-proof cases
Consensus overhead @ 15s blocks	~0.002%
Aggregation (7 CNs, k=4)	~318 µs

---

Neo-specific design direction (see design plan)

Full write-up: https://github.com/cschuchardt88/neo/blob/docs/bftrand-rnp-reference/docs/design/bftrand-neo-rnp.md

Topic	Proposed direction
Consensus	Partial beacons on dBFT path; rn = H(network ‖ height ‖ view) (view-change safe)
API	Keep System.Runtime.GetRandom; HF switches to PRF(beacon, txHash, counter)
Optional	GetBlockBeacon / native historical beacon
PUA	Docs first; optional IVD lite later — do not block RNP on full IVD
Rollout	Phased: NEP → crypto → consensus plugin → engine HF → mainnet

PUA types (from paper → Neo)

PUA	Neo angle
Contract	Call victim, revert if random outcome bad
Fallback	Callback / payment entry inspects and reverses
Fee	Only “good” branch is fee-payable
Script	Verification / tx script aborts after GetRandom

---

Discussion questions for core / TC

1. Enhance GetRandom only, or full runtime RNP with DRB?
2. Where do partials fit in dBFT (Prepare / Response / Commit / Recovery)?
3. Interaction with Double Speakers / dBFT 3.0 (dBFT 3.0 Specification #2029, CONSENSUS: dBFT 3.0 with double speakers model #3254) and PoN (Proof of Node #4542)?
4. Header field vs native storage for beacon?
5. Failover if k partials missing (hold block vs insecure fallback)?
6. Is Script-PUA policy in scope for v1?

---

References

• PDF: https://github.com/cschuchardt88/neo/blob/docs/bftrand-rnp-reference/docs/references/dsn2024-bftrand-paper389.pdf
• Design plan: https://github.com/cschuchardt88/neo/blob/docs/bftrand-rnp-reference/docs/design/bftrand-neo-rnp.md
• @Jim8y: https://github.com/Jim8y
• Code today: ApplicationEngine.GetRandom in ApplicationEngine.Runtime.cs
• Related: dBFT 3.0 Specification #2029, CONSENSUS: dBFT 3.0 with double speakers model #3254, Proof of Node #4542

---

Note on scope

This is a discussion / research-to-engineering issue. Adopting BFTRAND-style RNP is a consensus + VM change and must be HF-gated with Technical Committee review.