Aletheia is a login system built for a web3 first world. It has three main features. First, it allows websites to only allow users to login if they fulfil certain on-chain criteria (aka reputation). Second, users don’t need to give up their privacy, e.g. their transaction history, when logging in to a website since the website never gets access to the wallet address of a user. Third, users can use the same password for all websites without giving websites access to the password.
Application Type
zkDAO
Proposal Overview
Within the scope of this proposal, the MVP is to implement the following components:
Frontend for website owners to register their own NFT collection as reputation criteria
Relayer backend that allows users to create a global password without revealing their wallet address
Maintenance service backend that keeps a merkle tree on chain up to date about which user fulfils a reputation criteria
Demo frontend that shows websites owners how to integrate the ZKP generating code in the frontend
Demo backend that shows website owners how to verify ZKPs in the backend
Use Cases
Aletheia is an anonymous & on-chain reputation based login system for websites. Image you are a website and only want to make it available to users that own at least 1 CryptoPunk. Aletheia allows a website owner to set such a filter when designing the login system. Users who use Aletheia to login to a website don’t reveal their wallet address. Especially users with a lot of activity and stored value on chain care about their privacy. Aletheia allows them to keep it.The MVP will focus on the most thought after form of reputation: NFT ownership. It can be extended to arbitrary reputation in a later stage.
Competitive Landscape
There is no similar product in the market as far as we know.
Proposal Ask
Aletheia will become community-driven and self-funded by its own DAO and subscription fees by website owners for maintaining their reputation data of users (merkle trees on chain). In order to get this up and running, we will be requesting the $15k/year stable basic income to take care of initial development, welfare, and operations costs.
This ask will be in line with the laid down milestones as detailed below
launching a feature-complete product on our testnet
forming a DAO with 5-out-of-9 multisig
launching on mainnet with audit
attracting ?k daily active users
attracting ?k daily active users
Road Map
So far a simplified version with two hard coded NFT collections is published on Mainnet. In the next step the current version will be generalised to custom NFT collections.
After having talked to another student in my ZKU cohort, I think I will change the project slightly.
My main goal is to show other websites and users how they can use on-chain reputation to filter users and allow their users to login without revealing their wallet address. This tech is available now on main net and not only proposed in some random white paper. The first step is that users and websites understand the new authentication system and its benefits.
Since the tech sign in with wallet instead of email + ZKP + reputation is all pretty new, users and websites are confused how the different components work together. I think it’s more beneficial for the adoption to first build a version of the project which focuses on showcasing the new tech and building out the story why this is important vs generalising it directly.
What does it mean concretely? What would I like to change?
Instead of allowing websites to use their own NFT contract as a reputation, I’d like to stick to 1 or 2 pre-deployed NFT contracts as reputation which makes it easier to create a story and explain the benefits of such a system. It’s unlikely that website owners will directly use it.
Is the change you mentioned only for demo purposes? Or do you expect the website owners to deploy their own copy of Aletheia for their own NFTs? I think the issue with the latter is that it will not be qualified as a product, more like a protocol, and making reaching milestones 4 and 5 very difficult.
On the other hand, I tried out aletheia.rocks but cannot get through the part that it waits for the merkle tree update. Please advise.
The number will have to follow About the zkDAO category , which is in DAU - I think for your particular app, it can be website owners and users combined.
Thank you everybody for the input here in the forum or via DM.
Here are the updated milestones and road map.
Milestones
launching a feature-complete product on our testnet
forming a DAO with 5-out-of-9 multisig
launching on mainnet with audit
attracting 1k daily active users
attracting 10k daily active users
Road Map
So far a simplified version with two hard coded NFT collections is published on Harmony main net and test net. The main net version can be accessed here: aletheia.rocks and demo.aletheia.rocks. You have two wait ~10 minutes before you can login at demo.aletheia.rocks since the reputation indexer and the covalent api need time to reflect the correct state.
In the next step the current version will be generalised to custom NFT collections.
Nice!, The product has some interesting use cases.
Please include a demo video of the product, the interface isn’t very obvious to use.
Also, I noticed you’re using a backend and redis. Can you elaborate on why you’re using one and what’s being stored on the database?
Aletheia uses two backend services: relayer service and maintenance service. They communicate with each other using a reddis DB.
Relayer service
The relayer service allows the user to set a global password and store an identity commitment without revealing his public wallet address. In addition, the relayer service functions as an API. All data can be read from the blockchain directly, but the relayer service exposes an API to construct Merkle Proofs more easily.
Maintenance service
The maintenance service updates the reputation merkle trees on chain every 10 minutes. When a new user acquires a reputation, i.e. mints an NFT, the user’s public address gets added to the reputation merkle tree by the maintenance service after ~10 minutes. The updated merkle tree is also stored in reddis to provide the data to generate a merkle tree proof more quickly.
My initial idea was to build out a demo without allowing website admins to use their own NFT contracts as reputation and go around with my PoC and find potentially interested websites/communities and co-develop the app with them. With this approach, I don’t quality for the launch grant that’s why I am now in the process of extending the PoC so that it can be used with arbitrary NFT contracts (turn it into a full product) while still having a demo built in with predeployed NFT contracts.
Thank you for the explanation. I finally got through the entire process of your app (waiting for the server update did take a while) and can confirm it’s functional.
I do hope that you can explore a better way to maintain the database rather than updating every 10 minutes in the future.
As a zkDAO governor, I approve this proposal and can confirm the first milestone has been reached.
Hi Jan, I think that this could be a really nice project, which could attract many users. I would suggest you to create a repo with the good documentation on how the whole process works. Create the diagram representation of the system architecture.
Also what is the reason for 10 min update period?
I only update the reputation merkle trees on chain every 10 minutes for two reasons:
easier to badge updates across different reputations
covalent (indexing service) only gives reliable results after 10 minutes
What does reliable results mean?
If you mint an NFT and then use the covalent API to check the number of NFTs minted from a contract it takes 10 minutes until the response from covalent is stable.
Let’s assume so far three NFTs have been minted and you just minted a new NFT. This is how the API response might look like within the first 10 minutes:
After 1 min: 3
After 2 min: 3
After 3 min: 4
After 4 min: 3
After 5 min: 4
After 6 min: 3
After 7 min: 3
After 8 min: 3
After 9 min: 4
After 10 min: 4
Through trial and error I found out that the result is stable after 10 minutes. To speed up the process I would have to find a better indexing solution.
The 10 minute window might be a bit annoying for a demo but I think later for real world use cases it shouldn’t matter much since in most cases users acquire their reputation way before they will attempt to login to a website.
With the market downturn I feel less pressure to publish the project quickly so I have decided to learn Go before and rewrite my backend in it. I think it will pay off in the long term. Go is the dominant language for crypto backends since most clients use it.
Both resources supplement each other pretty well and focus on deep understanding as opposed to just hacking code together. You will learn how code is executed on the machine. There are scholarships for students for the course provided by Ardan Labs and the book “Learn Go with tests” is free.
Would be happy to chat with others who use Go as their backend language for crypto projects to chat about best practices!