Added design observations to logbook (#391)

Author: bwbush

Logbook.md

@@ -21,6 +21,32 @@ The Haskell simulator is so slow that it will be tricky to get any useful result
 
 Part of the problem is the voluminousness of the simulation log files, which (collectively) will exceed a terabyte for the experiments. To allievate this, the simulation scripts are filtering out minor events from the logs and compressing them as the simulation is run.
 
+### Observations on conflicts, ledger, and incentives
+
+Here are a few personal (@bwbush) observations, reflections, and conclusions on transaction conflicts, ledger design, memory pool, and fees/incentives.
+
+1. Honest duplicate and conflicting transactions will be present in IBs so long as local sortition is used for the IB lottery.
+    - The concurrency period/window for IB production is the fundamental limit on avoiding the inclusion of duplicates and conflicts in IBs.
+    - Memory pool rules can minimize duplicates/conflicts by having nodes act promptly to remove conflicting transactions from their local memory pool as soon as the receive a new IB.
+    - For a given level of throughput, producing fewer but larger IBs will reduce the probability of duplicates because fewer IB producers are active during each others' "light cones". However, at some point enlarging IBs will lengthen the concurrency "blind spot": for a given throughput.
+    - We have previously shown how reducing the probability of two IBs being produced in the same slot will increase the probability that no IB at all is produced in the slot.
+    - Public (global) sortition would open IB producers to denial of service attacks.
+2. So long as there is no collateral required for failed conflicting transactions, adversaries' only disincentive to reduce overall throughput would be their own infrastructure costs.
+    - Successful attack would require lightweight custom adversarial nodes, many network connections to honest nodes, and sophisticated networking. A significant and sustained attack would be costly, and inefficient attacks might hardly be noticed.
+    - Block producers are best compensated for the resources used by conflicting transactions by allocation from the rewards pot.
+    - The alternative of charging collateral on a failed transaction is too at odds with Cardano's longstanding guarantees. This would penalize attackers, but honest parties would also lose collateral on occasion.
+    - The alternative of charging collateral on successful transactions for any failed conflicting ones in IBs opens too larger an attack surface to intentional, adversarial conflicts.
+    - Honest IB producers are naturally incentivized to reduce conflicts because conflicts eat into fees, but this incentive could be amplified by adding a "conflict penalty" to the rewards computation.
+4. The memory pool is fundamentally untrusted with respect to conflicting transactions.
+    - An adversary would be able to thwart or abuse conflict-avoidance schemes at the memory pool level.
+    - Some common-sense optimizations are possible, such as blacklisting a node that supplies transactions obviously in conflict.
+5. Persistent storage of duplicate and conflicting transactions could be reduced through clever editing at the time of EB voting/certification.
+     - All parties voting on an EB are aware of the duplicate and conflict set among the transactions referenced by the IB.
+     - The EB could include a bitmap of which transactions are valid and which can be discarded, and voter would vote on the bitmap.
+     - Cryptographically speaking, IBs can organize transactions in a manner where items can be deleted without affecting the signature of the IB. (For example, transactions can be discarded from the IB according to the bitmap and replaced with just the hash of what was deleted.)
+ 5. It appears that front running can best be eliminated (at the ledger level, but not at the mempool level) by strictly ordering transactions by their IB's slot and VRF.
+     - Other IB and EB ordering proposals create complexity in the ledger rules and would be difficult to fully analyze for vulnerabilities.
+
 ## 2025-06-05
 
 ### Semi-realistic mainnet-scale topology