P2P Privacy §
Research §
- Mixnet v2 Simulation: invested time to improve/simplify the passive adversary attacks before running simulations with various parameter sets. Also running the passive adversary simulation with various parameter sets to find the optimal parameters/designs (the result is not posted in Notion yet).
- Introduced an attack that monitors nodes which emit messages at promised timing (i.e., block interval). The description can be found here. This attack is expected to be disrupted by adding cover traffic. The confirmation of this will come once we run the attack with different cover traffic parameters.
- Optimized the timing attack (tracing back message paths) and quantified its result, as posted here. The confirmation of this will come once we run this simulation with different parameters (number of layers and delays).
- For the analysis of the mix gadget, we have followed the “conventional” mix model research path: considering the most general scenario when n nodes sample k paths from the set of all nodes in the network [N]. We assumed that each node samples ( r ) of such ( k ) paths. We have shown that a node in a ( k )-path is also participating in other ( r - 1 + c_i ) ( k )-paths. Here ( c_i ) is a random variable from the binomial distribution with parameters ( rn ) and ( \frac{k}{N} ). For ( k \ll N ) and ( N ) large, ( c_i ) is a random variable from the Poisson distribution with parameter ( \frac{k r n}{N} ). On average, a node is participating in ( \frac{k r n}{N} + r ) ( k )-paths. We calculated an upper bound on the probability that node connectivity deviates from this average by the amount of ϵ\epsilonϵ. The summary can be found here.
Development §
Data Availability §
Research §
- Finished the benchmark document and all results are documented here. We will continue with NomosDA.
- We were having an issue with the roots of unity that didn’t allow us to use FFTs. After an org-internal talk, we solved the issue, and now it is working (the problem was that we were using the wrong generator that worked for everything except the FFTs).
- Started implementing FFT in specs as it is highly needed for FK20.
Development §
PPoS/Consensus §
Research §
Development §
Coordination Layer §
Research §
- Started to review the Plonky3 details (the notes can be found here). Generally, we can say it’s an improved version of Plonky2 in terms of prover time - meaning we can use it in situations where we need more efficient prover time. Initially, it was more appropriate to use Plonky2 because Plonky3 was still in development, but considering that Risc0 and Succinct have also started using it, we can consider using the Plonky3 protocol as well. In any case, it has advantages over Plonky2.
- On the other hand, we haven’t found any disadvantages in Plonky3. We thought proof size might be an issue, but they mentioned that they could reduce the proof size using recursion. In this case, it seems logical to use it for inner proof, but the details need to be examined. Perhaps conducting a similar benchmark study for inner and outer proofs as we did for DA would be beneficial.
- After discussing the CL Architecture, the most recent design making use of message buffers is now described here: CL Architecture.
- After making the decision to rewrite the CL spec in Rust due to the lack of crypto libraries in Python, we decided to halt the spec work in favor of the CL architecture design work that was more pressing.
Development §
Testnet + Insights §
Research §
- Finished base insights structure document (after discussion) - for the time being though, since it’s probably going to be a living document.
Development §
- (WIP) Tested our GELF tracing subscriber and connected it to Graylog in the testnet: subscriber is implemented and sends logs to the provided Graylog endpoint. However, the Graylog instance is spawned in the testnet, but manual steps need to be taken during every redeployment, which is not acceptable.
Research §
Development §
Miscellaneous §