List view
Due this date we should have the following: - Complete version of Halo2 GWC - Complete version of Halo2 SHPLONK - Complete version of Arecibo
Overdue by 1 year(s)•Due by February 9, 2024•0/1 issues closedThe first Deadline will be the following: Ugur: Research the possible security flaws or possible leakage of the shielded execution and possible mechanisms for monitoring/moderating without interception. Marvin: Investigate how to hide user addresses in shielded and deshielded executions, and to find out which signature verification method can be adapted. Moudy: Focus on SE/DE vs. Private/Public, understand if UTXO will be used as only tokens or inside smart contracts. Explore TPS (max is 100). Review Ugur's and Marvin's results
Overdue by 1 year(s)•Due by February 2, 2024•0/1 issues closedBy 02/02/2024, the document will be ready: - Add halo2 differences and explanation - Add different types of recursion - Add Arecibo (SuperNova)
Overdue by 1 year(s)•Due by February 2, 2024•0/4 issues closedTor is a distributed overlay network that provides transport security and anonymity for its participants. Its objective wrt anonymity is similar to waku. However, its advantage and disadvantages compared to Waku are not clear and studied. This is to conduct the initial research on this matter. The result will identify the decision criteria as to why should one choose / not choose waku over Tor. The comparison is more focused on the security aspects as there are already some almost clear performance advantages of waku compared to Tor e.g., - Waku is computationally lighter than Tor and does not require multiple encryption and decryption. This would also lower the message transmission delay. - Another advantage is the lighter key management where the sender does not have to establish shared keys with all the intermediate routers (as opposed to the Tor). In this comparison, we contrast the security of Tor with the transport protocol of waku v2 i.e., WAKU2-Relay. The waku message, as the unit of data transported using WAKU2-Relay, is treated as a black box. A privacy-respected application can provide the utmost level of security by encrypting the waku message before transportation. The analysis of the metadata included in the WakuMessage falls into the "conversational security" which must be examined separately. See the following research docs for more context https://github.com/vacp2p/research/blob/master/Tor-vs-Waku/WAKU2-Relay-Privacy.md https://github.com/vacp2p/research/blob/master/Tor-vs-Waku/Tor-vs-Waku.md
No due date•0/3 issues closed- No due date•1/9 issues closed
In the current implementation of rln-relay (at the PoC level) which is overviewed below, there are some concerns and open questions which must be investigated before making it production ready. # Overview rln-relay consists of the following steps: 1- A membership smart contract must be deployed on the blockchain, the contract holds the list of current registered members (as well as deleted members) and has the API for member insertion, and deletion (slashing). Root of the tree and auth path of pubkeys are not available as part of the contract. 2- Each rln-relay enabled peer must register a public key through the smart contract. Peers need to persistently store their public and secret keys. Registered peer locks a certain amount of fund in the smart contract, which gets burned in case the peer misbehaves (spams the system). 3- Each rln-relay enabled peer must construct and maintain a Merkle Tree based on the list of current members )fetched from the membership contract). This is required for the spam protection. As scuh, peers must keep listening to the contract events (member insertion or deletion) and update their local Merkle tree accordingly. Having the Merkle tree, a peer is able to - calculate the tree root - its authentication path (membership proof) 4- By having access to the recent root and membership proof - Peers can **anonymously** publish messages with a certain rate and prove that they are not spammers (have not violated the designated rate) - Routing peers can authenticate the non-spam messages, and otherwise drop the message and slash the spammers (delete them from the membership contract and withdraw their deposit)
No due date•0/2 issues closed- Overdue by 5 year(s)•Due by July 31, 2020•2/2 issues closed
- No due date•2/2 issues closed
- No due date•2/5 issues closed
- No due date•4/6 issues closed