In order to align with the notation used in DIZK, we may want to start using T tokens (instead of N which is used for something else).
line 41
In appendOrders function, shouldn't there be a way of not rehashing all the previous orders? I mention this because of the O(1) algorithm for computing a "Running Mean" in the sense that appending a new value to a dataset where we already know the number of values and the mean of the previous set, one can compute the new mean without recomputing the sum of all previous data entries.
----
Observe if X_n (the mean of [x_1, x_2, ..., x_n]) and we want to add a new value x_{n+1} then
X_{n+1} = (\sum_{i=1}^{n+1} x_i)/ (n+1)
rearranges as
(n+1)*X_{n+1} = (\sum_{i=1}^n x_i) + x_{n+1} = n*X_n + x_{n+1}
so that
X_{n+1} = (n*X_n + x_{n+1})/(n+1)
i.e. the new mean is expressed in terms of the previous mean, the size of the dataset and the new value to be appended.
----
With this in mind, if we store the current orderHash as an additional field in the contract, then we wouldn't need to loop to append orders.
line 69
How do we plan to deal with orders in the case of insufficient balance?
line 81
I would say "Any challenge is, by default, assumed to be legitimate and will be accepted unless the first transition submitter can provide a snark proof of correctness within a predefined time frame (some hours)."
line 293
>>> k = 10**3
>>> 21000+k*(6+16+16+64+64+512)*68/8+k*3000+k*60+5000
8849000
Some other suggestions:
line 11
line 41
line 69
line 81
line 293