-
m-relay<rbrunner7:monero.social> For greater visibility, as posted earlier already in -community: repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/645
-
m-relay<rbrunner7:monero.social> I just left a comment there. As useful and as fascinating this proposal may be, I worry about the feasibility of a FCMP++ rewrite in Python.
-
m-relay<jbabb:cypherstack.com> another implementation to reference would be great if it works :P
-
m-relay<kayabanerve:matrix.org> I'm not convinced it's infeasible rbrunner7:
-
m-relay<kayabanerve:matrix.org> The exact issue will be transcripting the same circuit. The half-step is simply to export the circuit from the Rust code.
-
m-relay<kayabanerve:matrix.org> github.com/monero-oxide/monero-oxid…ithmetic_circuit_proof.rs#L231-L288
-
m-relay<kayabanerve:matrix.org> These debug assertions within the prover check the prover's witness is consistent with the statement. The statement itself, the list of constraints, is just a list of structures each with a variety of matrices which are just numeric weights.
-
m-relay<kayabanerve:matrix.org> One could half-step such that the numeric weights from Rust are exported and avoid having to calculate most of them.
-
m-relay<kayabanerve:matrix.org> (some are chosen in response to the transaction itself, so some still have to be calculated)
-
m-relay<kayabanerve:matrix.org> As for if one generates the weights, I can defer to the FCMP circuit's additional layer instantion:
-
m-relay<kayabanerve:matrix.org> github.com/monero-oxide/monero-oxid…ypto/fcmps/src/circuit.rs#L165-L186
-
m-relay<kayabanerve:matrix.org> The design of the code is to define a series of incremental steps, reusable code, such that the final circuit is really straightforward to specify.
-
m-relay<kayabanerve:matrix.org> Now, that would imply a reimplementation would have to implement the same patterns I used in order to achieve the same ordering of steps and the same result. That may put into question the value of reimplementation if a lack of freedoms may be taken.
-
m-relay<kayabanerve:matrix.org> But I think feasible isn't off the table, and to watch a reimplementation occur would provide context on where the exact hard requirements are, where freedom can be taken, and if there is anything glaring exposed via reimplementation re: a design anti practice we have the opportunity to correct now, before deployment (even if the paperwork would be a nightmare)