Examples of eligible projects include tooling and libraries important to the development ecosystem (e.g., web3js, solc), non-profit smart contract infrastructure (e.g. ENS, Multisig wallets), open source crypto code/libraries (e.g., ZoKrates), or services beneficial to community.

Note that the project doesn’t necessarily need to be non-profit to qualify, as long as it can serve as a utility to the community — for example, gambling contracts will never be eligible, but a state channel platform that has some fee system built in could be fine. The point of the community audits initiative is for grassroots projects to be able to receive quality audits without needing to think about raising large amounts of funding before the project can go live, and without having to go through a complex ECF-type application process for a grant.

First Wave of Community Audits

As part of this announcement, we‘re thrilled to publish the first two community audits we’ve undertaken:

SolidStamp: SolidStamp connects smart contract users and auditors to ensure the safety of their funds. The contract maintains an on-chain database of smart contract audits so you can be confident in the code you interact with on-chain.

— The audit by Matthew Di Ferrante can be found here: https://zklabs.io/audits/solidstamp.html

Token Subscription: The Token Subscription project enables applications to create a trustless subscription model without their users needing to constantly and manually transfer tokens.

— The audit by Dean Eigenmann can be found here: https://zklabs.io/audits/tokensub.html

About the Initiative

So far, the following auditors are confirmed as being part of the initiative:

• Matthew Di Ferrante, ZK Labs Founder & Ethereum Security Contributor
• Dean Eigenmann, ZK Labs Auditor & ENS Developer
• Nick Johnson, ENS Project Lead & Ethereum Core Dev

I personally will commit to doing at least one reasonably sized community audit per month, along with Dean Eigenmann. We hope to grow the pool with more volunteers as time goes on.

For any audits that would take a much longer amount of time, we will also be maintaining a charity multisig whose purpose is to fund more complex undertakings. A percentage of profits from ZK Labs will go to fund the initiative, and donations to it are welcomed by anyone. When donating you can also nominate a project or specify a project class (e.g, crypto code, tooling, etc) that you would like your audit donation to go towards.

If you have a project you want audited that you feel meets the eligibility criteria, want to be involved or are willing to be a multisig curator, reach out to us at audits@zklabs.io or come talk to us in our public room on riot: https://riot.im/app/#/room/#zklabs:matrix.org

I hate paperwork just as much as the next cryptoanarchist, so I promise the process will be simple and decisions quick — don’t be afraid to email, even if we may not be able to do a full audit I’m always happy to provide advice.

ZK Labs Community Audits Initiative for non-ICO Projects was originally published in ZK Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

In December last year, Tatu Kärki (Aragon) introduced the project’s own grant program, in collaboration with Placeholder, called Nest (see Introducing Aragon Nest). Similar to the Ethereum Foundation’s grant program ÐΞVgrants and the Ethereum Community Fund, the purpose is to provide grants to individuals or teams that are developing the infrastructure, developer tooling, and frameworks, on which Ethereum’s ecosystem relies on. In addition to financial support, the Nest program is committed to provide advising and technical support to the grantees. Ever since the announcement, Nest has received more than 20 different applications, and you can view them here, as they are open-source.

In the first week of May 2018, Matthew Di Ferrante (ZK Labs), submitted an application representing ZK Labs Research. While ZK Labs is commonly known for security audits, the research arm is an independent team lead by himself, in collaboration with Dean Eigenmann (ENS & ZK Labs), and Rebekah Mercer (PhD in Cryptography at Åahrus). The proposal was pre-approved on the 24th of May and shortly after, the corresponding GitHub Issue was labelled as “approved” 🎉.

Flash Conceptual Framework

On a high level, ZK Labs Research’s project aims to enable private and scalable voting and authentication on Ethereum, leveraging linkable ring signatures. Before diving into the details, let’s have a smooth refresher of concepts.

Introducing Ring Signatures

In cryptography, ring signatures are a type of signature scheme. Signature schemes are systems that have one basic functionality: produce digital signatures. A signature scheme is composed by three main elements:

• A key-generation algorithm
• A signing algorithm
• A signature verification algorithm

Signature schemes are pervasive in infrastructure layers of the technology that we use day-to-day. For illustration, the Transport Layer Security (TLS), protocol, on which all websites we visit rely to secure the communications between servers and the browsers, uses commonly known schemes such as Rivest-Shamir-Adleman (RSA) or FIPS’ Digital Signature Algorithm (DSA).

OpenSSL (commonly used in web servers), NSS (used in Firefox or Thunderbird, among other Mozilla client products), and Crypto++ (commonly used for research and open-source projects) are open-source libraries that include implementations of the aforementioned and more.

In blockchain literature, signature schemes are essential. Bitcoin and Ethereum protocols use Elliptic Curve Digital Signature Algorithms (ECDSA), which is a variant of DSA. In both cases, a curve formed by the parameters defined in secp256k1 is used.

Ring signatures are a category of signature schemes. They are characterised for preserving the identity of a signer, as member of a group can produce a signature without revealing him/herself but the group. Grosso modo, a ring signature scheme involves a group of public and private key sets, each of which belong to different peers. Any of the individuals belonging to this group, identified by the corresponding public key, can sign a message using their own private key. Privacy is granted as any of the members of this group could’ve signed the message. Hence, under any external accusations, any of the group members could plausibly deny the claims.

Examples of Applied Ring Signatures

An example of its application is for increasing privacy and avoiding de-anonymisation through graph analysis on p2p payment systems (you know, cryptocurrencies). In such systems, a transaction signed by a sender is mixed with a pool of transactions made by a other senders, making it much harder to link each transaction to its actual signer. Obfuscating links via mixing was a popular way of enhancing the privacy on Bitcoin, which existed before ring signatures were implemented in the protocol of certain payment systems. The difference is that tumblers for Bitcoin, e.g., were trusted services that could exit-scam at any time, whereas in certain cryptocurrencies it is implemented in the protocol, so your transactions get mixed by default.

Another, less mainstream example, could be the following. In a parallel world, governance of Eearthereum is on-chain, where proposals are made and submitted by the public. Proposals can be approved with only one of the signatures (which is a really, really bad idea, don’t do this at home) of the members of the Earthereum Foundation. One of the latest proposals, called EARTHIP-04150705, requested to abandon the existing fork and fully support Earthereum Modern.

Normally, the fellows at the EF (Earthereum Foundation) would discuss each proposal in their weekly call via Earthpe, but in this particular instance, one of the members of the EF, Zladimir Vamfir signed the approval for the proposal without talking about it with Bitalik Vuterin nor the other members of the EF. Because in the Earthereum’s community there is the unspoken rule of “at the end, Bitalik is the one calling the shots”, everybody though it was B’s decision and unleashed a wave of confusion and made the community rage, without knowing which member actually made the signature*.

* Note that this example is a work of fiction. Names, characters, businesses, places, events, locales, and incidents are either the products of my imagination or used in a fictitious manner. Any resemblance to actual persons, living or dead, or actual events is purely coincidental.

Introducing Linkable Ring Signatures

While the very first paper proposing ring signatures dated back in 2001, variant of linkable ring signatures began to proliferate around 2004 (see Literature section at the end). In Rebekah’s “Privacy on the Blockchain: Unique Ring Signatures”, she describes them as:

Linkable ring signature algorithms provide a scheme that allows users to sign on behalf of a group, again without revealing the individual signer’s identity, but with the additional property that any signatures produced by the same signer, whether signing the same message or different messages, have an identifier, called a tag, linking the signatures. With this tag, third parties can efficiently verify that the signatures were produced by the same signer, without learning who that signer is.

In essence, the main difference between linkable and initial ring signatures is the tag identifying signatures produced by a specific signer. Unique Ring Signatures (URS) have a tag that links signatures if and only if the signer, message, and ring are the same across the two signatures. This tag is produced by the signer’s private key, a list of public keys of the ring, and allows group members and external peers to check either two identical pieces of information have been signed by the same ring member. URS could grant certain parties the ability to query a piece of information to a server without compromising the anonymity of the original signer. Due to the properties of linkable ring signatures, it could potentially enable private and trustless electronic voting systems.

ZK Labs Research’s Proposal on a Scalable and Private Voting System

This section aims to provide a shallow description of what the proposal is about and the major components of the project.

Background & Motivations

Electronic voting systems have always been a popular use case described by many projects in the blockchain space, especially after the infamous incidents in Catalunya last year (I actually wrote a blogpost during those times, as I am originally from Barcelona, titled “How to Vote Without Being Hit by Rubber Bullets and Batons”**). The Catalan case was the perfect case where it was obvious that the existing voting system was unavoidably-susceptible to a centralised authority. The properties that an e-voting system should maximise are:

• Decentralisation: to avoid governments or respective authorities to censor and block voting events
• Anonymity: to protect citizens’ political privacy
• Scalability: assuming that such system is used, in even the smallest country in the world, such system should support at least 1,000 citizens to vote (Vatican City, where the population size is estimated to be 1K inhabitants)

As a system with such properties has not yet been implemented, the aim of ZK Labs Research’s proposal is to provide a set of libraries that support the basic components of an e-voting system on Ethereum and a prototype integrated with the Aragon protocol.

** Note that all my writings around this topic are solely focused on technology and its applications, using real-life events as illustration. Thus, any political connotations are unintended. Should you have suggestions for enhancing neutrality in my writing, please leave a comment.

Overview of the Components: What is On-Chain and What is Off-Chain?

In order to produce a scheme that is scalable, the amount of processes on-chain should be minimised. In this proposal, the only on-chain processes will be key-generation and final verification.

The processes off-chain are signature generation locally by the users and collection of the signatures from the participants and combining them into an on-chain signature. A decentralised application that provides an interface for users to sign up and for other utilities, such as showing the final voting results.

Concluding Remarks & Future Writing

In this article we announced that ZK Labs Research’ Proposal submitted to Aragon & Placeholder’s Nest program was accepted. A quick refresher of basic concepts has been provided, reminding of basic definitions and examples of what signatures schemes and ring signatures are, with the goal of providing a conceptual foundation for the reader. In the last section, the background and motivations for ZK Labs Research’ proposal was described, finishing up with an overview of the components that the project committed to deliver.

Depending on the interest showed by the audience, there might be follow-up articles on:

• Technical deep dive into the private and scalable e-voting scheme
• Updates on the progress of the project
• Privacy / Anonymity limitations of ring signatures (more analysis)
• Overview of signature schemes and possible applications for blockchain technology (more cryptography)

Any feedback is always welcome, feel free to leave a comment or reach out to me on Twitter!

Preliminary Work & Readings

Prior Art

• mattdf/RingCrypto
• solidblu1992/RingCTToken

Ring Signatures, including linkable and unique ring signatures:

• Rivest, R. L., Shamir, A., & Tauman, Y. (2001, December). How to leak a secret. In International Conference on the Theory and Application of Cryptology and Information Security (pp. 552–565). Springer, Berlin, Heidelberg.
• Liu, J. K., Wei, V. K., & Wong, D. S. (2004, July). Linkable spontaneous anonymous group signature for ad hoc groups. In Australasian Conference on Information Security and Privacy(pp. 325–335). Springer, Berlin, Heidelberg.
• Liu, J. K., & Wong, D. S. (2005, May). Linkable ring signatures: Security models and new schemes. In International Conference on Computational Science and Its Applications (pp. 614–623). Springer, Berlin, Heidelberg.
• Au, M. H., Liu, J. K., Susilo, W., & Yuen, T. H. (2007, May). Certificate based (linkable) ring signature. In International Conference on Information Security Practice and Experience(pp. 79–92). Springer, Berlin, Heidelberg.
• Franklin, M. K., & Zhang, H. (2012). A Framework for Unique Ring Signatures. IACR Cryptology ePrint Archive, 2012, 577.
• Mercer, R. (2016). Privacy on the Blockchain: Unique Ring Signatures. arXiv preprint arXiv:1612.01188.

In protocol ring signatures for blockchain-based payment systems:

• van Saberhagen, N. (2018). Cryptonote v 2.0, 2013. URL: https://cryptonote. org/whitepaper. pdf. White Paper. Accessed, 04–13.

NESTing Scalable & Private Voting with Ring Signatures (with a Gentle Introduction to Signature… was originally published in ZK Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

The ZK Labs auditors were hired by the Adex team to conduct 2 separate audits of their platform, which can be found in the Adex github repository. The team audited the smart contract versions found in the commit 6ecc86b2a3c3594569e3df9936f6b356b0f42d1e.

The 2 separate reports written can be found here.

The Adex team wrote their smart contracts to a very high standard, which led to the ZK Labs team finding no severe issues. However, we were able to make a few suggestions.

Suggestions like naming and wrapping function calls in require were resolved by the team.

Suggestions

• Wrap all token transfer & transferFrom function calls into a require, to support older versions of ERC20 tokens which do not throw.
• Replace occurrences of send with transfer.
• Variable name in the ADXExchange contract can be removed.
• Function ordering should be cleaned up to match soliditys style guide.
• Comments listing where function, event and modifier definitions are seem rather useless.
• Consider summarizing “Links on publisher” and “Links on advertiser” into a common struct, so the struct Bid contains advertiser and publisher that are both a struct containing the specific info. This can be done as the info on both sides is the same, except of slot and unit, but for this the enum can be used to specify what type of data it is.
• Consider changing the description comments above functions to natspec conforming comments.
• Make modifier names more descriptive
• Change var to an explicit type, increases legibility and ease of understanding.
• Remove the underscores from parameter names where they are not necessary.
• The logic is identical to that found in cancelBid, consider expanding the permissions in the cancelBid function to allow for both the advertiser and the publisher to cancel, eliminating the need for this function.

Minor issue

There is nothing that prevents the advertiser and publisher from being the same person, maybe this should be checked for.

Conclusion

No severe issues were found, however suggestions were made to adhere to best practices.

Adex Platform Audit was originally published in ZK Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

The ZK Labs auditors were hired by the FansUnite team to conduct 2 separate audits of their crowdsale and token contracts, which can be found in the FansUnite github repository. The team audited the smart contract versions found in the commit 1c989dbd269958df1d474d5e29ed11e96e7efee0.

The severe issue mentioned below were fixed by the FansUnite team as of the commit 75cc4b3d1a6232bdd107b17637bb264a94981e04.

Full report by Dean Eigenmann.

Along with investigating some of the security issues, we added some of our recommendations that could be implemented to simplify and improve the code.

Severe

A severe issue was found which would lead to the failure of finalization of the crowdsale. This was due to the fact that the last purchase could exceed token cap, causing an exception to be thrown by SafeMath in the finalize method.

This issue could occur not only through the purchase function, but also through the addPrecommitment function, which allows the FansUnite team to allocate tokens to addresses.

The solution of this issue was to simply check that an allocation through either the addPrecommitment or the purchase function does not exceed the maximum limit.

Suggestions

Along with the issue we had found, we also found a series of improvements and changes that could be made to the code.

• The MinGoalReached event can be removed as it is never used.
• The multiplier 10**24 is used repeatedly, a constant could be created in place.
• The doPurchase function is passed a parameter called _owner that is unused. We suggested to remove this parameter and simply use the msg.sender constant.
• We suggested that the transfer method call in the doPurchase function should use the weiAmount variable rather than the msg.value constant.
• We suggested that the addToWhitelist function should be adapted so an array of addresses could be whitelisted. This would reduce the amount of transactions required significantly.
• We suggested to the developers that the FansUniteToken could be easily replaced with contracts from the OpenZeppelin library.
• The TokenVesting contract constructor could be modified to automatically multiple the _duration variable by 1 weeks, simplifying what needs to be passed.
• It could occur that the finalize method mints 0 tokens to the unsoldSupplyAddress, we suggested that a check should be added.

Conclusion

We found one severe issue, which we explained to the FansUnite team along with a list of possible methods to fix the issue. Additionally we proposed changes to follow best practice standards as well as increase the legibility of the code.

FansUnite Audit was originally published in ZK Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.