<li>Used the probability that the naive estimator of relative stake is inside some interval which includes the true stake α, δ(α), to derive an algorithm that suggests how to divide the stake of a node in order to reduce the quality of statistical inference by an adversary. The interval [α(1−γ),α(1+γ)] is parameterized by the adversarial “accuracy” parameter γ. The probability δ(α) can be interpreted as adversarial “confidence” gained after Tq observations (on average), where T is the number of time-slots in one epoch and q is the fraction of observed slots (for example due to deanonymization failure of the mixnet), that the inferred stake is within the interval [α(1−γ),α(1+γ)]. Assuming q and γ, a node can use its stake α to compute the probability δ(α). The latter is a monotonically increasing function of α, and dividing α among a number of nodes reduces the adversarial “confidence,” thereby reducing the quality of adversarial inference. The details of the analysis can be found in the following <ahref="https://www.notion.so/De-anonymisation-of-relative-stake-5b48f86bba3845c98f9b16f952307998#e1dbf36740794232a11289d655da574f"class="external">document</a>.</li>
<li>Cryptarchia fuzz tests: tried various fuzz testing strategies, but finally ended up with a simple but clear fuzz strategy, through which we can test Cryptarchia by simulating the environment where the block proposal delivery (p2p networking) is not synchronous and not predictable. The initial <ahref="https://github.com/logos-co/nomos-node/pull/629"class="external">PR</a> for the basic strategy has been opened. Also opened a small fix found by the fuzz test: <ahref="https://github.com/logos-co/nomos-node/pull/630"class="external">PR</a>.</li>
<li>Discussed the Staking-Privacy dilemma and came to a conclusion that the Nym design needs to be fine-tuned to reduce the impact of the delegated stake on the probability of selection of a node. We also need to investigate a mysterious constant that “controls the loss of competitiveness experienced by a Sybil attacker when it partitions the stake into multiple pledges”.</li>
<li>Prepared a <ahref="https://www.notion.so/Mixnet-with-Staking-c8ec3bfd461f4989b3ebbcf4b4b15324#2e57424c79bd44b19c4c4dd624f544b2"class="external">recommendation</a> for the first iteration of the mixnet staking. The main motivation was to present a simple staking design for mixnet that is inspired by Nym but is simplified and will be updated when our approach gets more mature.</li>
<li>Adding metric APIs for Mixnet - still work in progress. A PR will be opened for a minimal but essential metric API this week. This should be enough for now because the entire mixnet architecture may change according to the mixnet staking design. The first metric is going to be the number of packets that are being mixed in each mix node, which can be considered as the quality of mixing. More details in the relevant <ahref="https://www.notion.so/Mixnet-Metrics-d9ca6b3e06d1497096119e097f99790e"class="external">document</a>.</li>
<li>Nomos DA specification has been rewritten - a <ahref="https://www.notion.so/NomosDA-Encoding-Verification-Dispersal-4d8ca269e96d4fdcb05abc70426c5e7c"class="external">document</a> has been added on top of the original one to make certain mathematical and technical details more digestible.</li>
<li>Nomos DA verifier sketch: We have started putting all pieces in place for getting the DA protocol implemented and integrated in the node. This implies some cleaning and refactoring that have impact in the code base. We have a da-v1 branch where we will be incorporating everything until it is ready and stable to be added to master - <ahref="https://github.com/logos-co/nomos-node/pull/627"class="external">PR</a>.</li>
<li>Published a draft branch with the first working version of the Nomos DA protocol. This will make a lot of changes including removing of old attempts and experiments. Notice that this <ahref="https://github.com/logos-co/nomos-node/pull/626"class="external">branch</a> will hold a lot of changes but that most of them will be incrementally included (and reviewed).</li>
<li><ahref="https://github.com/logos-co/nomos-node/tree/da-v1-kzg-rs-core"class="external">Branch</a> added: KZG+RS core in rust, <code>bytes_to_polynomial</code> method - not working atm but we are debugging to see what is the issue (looks like roots of unity related).</li>
<li><ahref="https://github.com/logos-co/nomos-node/tree/da-storage-service"class="external">Branch</a> added: DA indexer - work in progress, removed all previously proposed mocks and structures as da protocol changed substantially.</li>
<li>Taiga: compiled a <ahref="https://www.notion.so/Taiga-as-of-March-2024-7b9c037fa2c144dcbb5e4666c1815d17"class="external">report</a> on the current state as part of our research efforts.</li>
<li>Taiga made the choice to use blake2s for VP commitments and Poseidon for resource commitments. The experiment looks at prover/verify time when blake2s is replaced with Poseidon, and we get a near doubling in performance. More details in our <ahref="https://www.notion.so/Taiga-Replace-Blake2s-with-Poseidon-fd34bdba50da4360822ec3791a4ccd2d"class="external">experiment</a>. The details of the Blake2s with Poseidon implementation have been reviewed in this <ahref="https://www.notion.so/ZK-Friendly-Hash-Functions-312c6d625f0244f0bea778ac5619e76d"class="external">document</a>. As part of examining the usage of Blake2s and Poseidon in the Taiga implementation, a summary providing general information about ZK-friendly hash functions has been prepared.</li>
<li>The <ahref="https://www.notion.so/Proof-Systems-Survey-ffc625a2ff82407db7a45fd193136258"class="external">survey</a> on proof systems is underway: to summarize, Halo2 stands out in implementations for private transactions. Its use of Plonkish arithmetization and consideration of lookup arguments make Halo2 advantageous. As discussed earlier, we prefer not to use a trusted setup-related feature like KZG in the coordination layer. Consequently, proof protocols involving trusted setups, such as Groth16 and Plonk, are less favored. Generally, there are three common polynomial commitment schemes used in existing protocols: KZG, IPA, and FRI. A comparison of these schemes has been added to the report. Even if we don’t use Plonk, the use of Plonk-ish arithmetizations in Halo2 is significant for performance. In addition, Nova’s folding improvement is critical for performance, but it requires the use of R1CS instead of Plonkish. Sangria, a folding scheme using Plonkish methods, is a new design worth exploring. Finally, after outlining the general framework for the coordination layer, we believe that upgrading cryptographic sub-algorithms for performance will not be too challenging.</li>
