|
|
@@ -133,3 +133,15 @@ The transaction verification pipeline roughly looks like this:
|
|
|
1. Lookup specific `apply()` function based off the `contract_func_id`.
|
|
|
2. Call `apply(update)` to finalize the change.
|
|
|
|
|
|
+## Parallelisation Techniques
|
|
|
+
|
|
|
+Since verification is done through `state_transition()` which returns an update that is then committed
|
|
|
+to the state using `apply()`, we can perform verify all transactions in a block in parallel.
|
|
|
+
|
|
|
+To enable calling another transaction within the same block (such as flashloans), we can add a special
|
|
|
+depends field within the tx that makes a tx wait on another tx before being allowed to verify.
|
|
|
+This causes a small deanonymization to occur but brings a massive scalability benefit
|
|
|
+to the entire system.
|
|
|
+
|
|
|
+ZK proof verification should be done automatically by the system. Any proof that fails marks the entire
|
|
|
+tx as invalid, and the tx is discarded. This should also be parallelized.
|
narodnik