just bullet points...

proposals/0074-scrambled-transaction.md

@@ -12,7 +12,144 @@ feature: (fill in with feature tracking issues once accepted)
 
 ## Summary
 
-TBD
+### general idea
+
+- use asic-resistant time-lock encryption
+- use proof-of-work client puzzle for spam mitigation even to hide the fee
+  payer
+- make transaction expire very soon for minimal additional latency of the
+  time-lock decryption
+- (future) spoof ip source address to avoid fingerprinting with one-shot
+  one-sided udp packet
+
+### terminology
+
+scrambling = time-lock encrypting
+descrambling = time-lock decrypting
+
+### pros
+
+- stricter censorship resistance than bps.
+- latency minimization incentive is formed and ledger is timestamped for
+  later inspection
+  - should reduce spamming in the first place
+- (future) can generate unbiased random generator
+
+### cons
+
+- artificial latency
+- complicated
+- somewhat easier dos (hopefully not too easy) with garbage (mitigated by
+  client puzzles)
+- tps scalability now depends on validator count
+- reliance on ntp via wall-clock time-stamp both on tx and ledger entries.
+
+### processing flow of a scrambled transaction
+
+1. user pre-calculates a valid tuple for (de)scrambling: `(scramble_seed,
+   descramble_key = recursive-randomx(scramble_seed))`.
+2. user measures network latency to the leader
+3. user creates and signs a transaction with version=1 (new assigned version)
+   also sets tx's block inclusion `max_age` as `end-to-end latency + 20ms`.
+4. user encrypts the transaction (aes-128-gcm with `descramble_key`)
+5. user attaches the `scramble_seed` and the pow client puzzle to the
+   scrambled transaction
+6. user submits the scrambled tx to leader
+7. the tx is propagated via turbine
+8. the tx is descrambled by a certain validator assigned by consistent
+   hashing as part of new distributed descrambling stage.
+9. validator submits a vote tx with the descrambled key is attached
+10. as soon as all descrambled keys are included in child blocks, the parent
+    block is replayed
+
+### protocol changes
+
+- banking
+  - becomes bankless
+  - no practical buffering
+- turbine
+  - timestamp is added to entries
+  - new ledger entry verification: shreds' timestamp comparison against
+    received time on socket (must be within sum(deterministic turbine path
+    network delay))
+  - needs to shred buffered entries more often
+- vote transaction
+  - additional flag whether the voter thinks the slot was censorship resistant
+    or not.
+  - additional payload for solved decryption keys (`Vec<Result<Aes128Key,()>>`).
+- replay stage
+  - deterministically reorders transactions by priority fee batched at 50ms
+    intervals of entries' timestamp before executing.
+  - transactions in the block aren't guaranteed to be executed anymore;
+    - could be revealed the tx has expired according to the timestamp of its
+      ledger entry position.
+    - could be overflow from the queue
+- clients
+  - new transaction format
+  - additional steps: time-lock encrypting, pow client puzzle solving,
+    precise network latency measuring
+
+### scrambling
+
+- scrambling is optional. ie. older transaction is supported as before.
+- uses recursive randomx to derive private key from plaintext seed attached
+  to the tx
+  - randomx is a hash function and asic & fpga resistant.
+- also equix with difficulty is attached to the tx for spam prevention
+  - verification is around 50us per core.
+  - should be able to do line-rate filtering.
+- padded to `1_232 bytes` (= `PACKET_DATA_SIZE`) to avoid finger printing.
+
+### latency and safety parameters
+
+- scrambled tx expires in **20ms**
+  - chosen to be enough for minimal buffering + jitter of one-way network
+    latency.
+  - so precise time-stamp with subsecond gratuity is attached to the tx
+    - the timestamp is scrambled to encourage fifo at banking
+  - oracle is needed for bad validator with intentionally large latency.
+- descrambling is adjusted to take 100ms with modern machine
+  - this is **5 times** of tx expiration (20ms).
+  - given 2.5 ghz cpu as baseline, 12.5 ghz cpu should be impossible for
+    some time?
+
+### cooperative distributed descrambling
+
+- this is needed because individual node can't descramble all txes: 100ms *
+  20000 tx/block = 5000s/block >> 400ms
+- all of non-delinquent validators are shuffled and split into 3 groups of
+  the same size according to recent parent block
+- each group independently solves all scrambled txes assigned with consistent
+  hashing
+- note that this work balancing should be fully deterministic.
+- so, 2000 (current mb node count) / 3 = 666 => 20000 / 666 = 30 descrambling
+  / block / node.
+- 128/8 * 30 => 480 bytes are increased for each vote transaction.
+- liveness isn't strictly stake-weighted here but i'd argue turbine is similar in
+  that regard, right?
+
+### edge cases
+
+- user submits complete garbage as tx
+  - => simply discarded before including into block
+- user submits garbage data with correct pow client puzzle
+  - => marked as garbage after distributed descrambling, the garbage will
+    remain in ledger though
+- cluster fails to descramble all scrambled transactions within slot=4
+  - => mark the fork as dead as a whole
+- valid scrambled transaction is marked as garbage at distributed descrambling stage
+  - => will be slashed
+- descrambled transaction is identical to one of already executed transaction
+  - => simply ignored
+- shred is repaired or arrived late
+  - => vote normally but with might be with censored flag.
+
+### future work
+
+- scramble vote transaction as well
+- relay service to avoid ip source address fingerprinting
+- unbiased random
+- address tragedy of commons among staked validators.
 
 ## Motivation