diff --git a/src/sonic/S_poly.pdf b/src/sonic/S_poly.pdf
deleted file mode 100644
index a3d626e..0000000
Binary files a/src/sonic/S_poly.pdf and /dev/null differ
diff --git a/src/sonic/discussion.html b/src/sonic/discussion.html
new file mode 100644
index 0000000..abe1c98
--- /dev/null
+++ b/src/sonic/discussion.html
@@ -0,0 +1,40 @@
+
S polynomial transformation for permutation argument
+Decomposition
+Following the original suggestion
+
+
+ is not important for this discussion. is in total a polynomial of degree .
+
+and with a similar form for and
+ by itself is a constant in -th linear constraint in front of a variable . and have the same meaning for and .
+In total can be represented as a large convolution in a form where summing is over the same index that is placed up and down. Vectors are and , so the matrix is sparse and -th row is formed by the concatenation of coefficients of , and ( notation is abused). For two multiplication gates (giving variables ) and a linear constraint a first row would look like
+
+There are three questions:
+
+- Original paper states that can be represented as a sum of three polynomials, each of those being a permutation by itself. Why three? One could try to transform a whole matrix to have one permutation argument.
+- If is split into sum of three polynomials, are those polynomials each form an individual permutation argument for components like ?
+- What would be the most efficient procedure to do such a reduction? Just from an example above with a single constraint in a form a first element will contribute in a summand , while to make a permutation argument one has to first create a term .
+
+Continuing discussion
+Implementation of a permutation argument requires to have some diagonal matrix to first commit to the combination like and later make a permutation argument to prove evaluation of for a fixed permutation .
+In principle such requirement means that decomposition of our matrix into the sum of matrixes (let’s call them should have only a single coefficient in every row, so one can define a proper diagonal . Such decomposition and reduction needs to be done only once per circuit, cause and corresponding will become fixed as a part of the specialized common reference.
+One can not directly guess how many linear constraints and multiplication gates will be in a system. For example, trivial (w/o optimizing run, as given in the original SONICs implementation) reduction of R1CS will have number of multiplication gates equal to the where is a number of variables and is a number of constraints in R1CS.
+Let’s take an assumption that , so a final constraint system will have more multiplication gates that linear constraints. In this case one can propose the following reduction procedure:
+
+- Forbid constraints that have a form , basically require a deduplication step.
+- Each constraints may have one variable of flavors , and to ensure that has only one coefficient for variable of each kind. In this case it can already be decomposed at three matrixes .
+- Every constraint that breaks this rule will give raise to a new linear constraint(s) and new multiplication gate(s).
+- Final constraints can NOT have zero coefficients in front of any flavor of variables, otherwise a permutation argument can not be made (it’s a necessary assumption for grand product argument).
+- Reduction itself is not trivial! Let’s do it step by step.
+- Constraint where , so in a linear term number of contributions from variables of flavor is greater than from flavor , that is in term is greater than for a flavor . In this case one can reduce and by one, and increase by one, through the introduction of a constraint . This also gives one extra multiplication gate. One can continue this procedure until there is a linear constraint in one of the following forms:
+
+- , then reduction is over
+- .
+- (this in a case of public inputs also)
+
+
+- allows to try to make a constraint system in the form , with those two constraints going into the different .
+- if inflated into constraints , (TODO: check the prefactors).
+- To have one can not allow any variable of any flavor to happen more than 3 times in all the linear constraints. Otherwise for any permutation one can not "choose" a corresponding linear constraint index.
+
+Now this "simple" list of rules can be implemented :)
diff --git a/src/sonic/helped/helper.rs b/src/sonic/helped/helper.rs
index f8823e7..b755a36 100644
--- a/src/sonic/helped/helper.rs
+++ b/src/sonic/helped/helper.rs
@@ -214,6 +214,7 @@ pub fn create_aggregate_on_srs_using_information, S: Sy
let mut poly_positive = vec![E::Fr::zero(); 2*n];
let mut expected_value = E::Fr::zero();
+ // TODO: this part can be further parallelized due to synthesis of S(X, y) being singlethreaded
for (y, c_opening) in y_values.iter().zip(c_openings.iter()) {
// Compute s(X, y_i)
let (s_poly_negative, s_poly_positive) = {