Hi all, we are the identity team at cLabs: Eela, @isabelle, @Alec and me
As @yerdua mentioned below (), next Monday (July 18) we are beginning a ~4.5 week milestone until Thursday, August 18.
With this post, we’d like to share some of our current priorities and associated deliverables.
Overall, our main priority is rolling out the new federated attestations protocol (”ASv2”) in parallel to the existing validator-run attestation protocol (”ASv1”). You can read more about the new protocol design and motivation in our recently published CIP51: Federated Attestations Protocol.
Our goals for the coming 5 weeks are to:
Complete the ASv2 smart contracts audit process (incl. responses from auditors)
This matters because all Celo core contracts have to be audited according to the release process and both the FederatedAttestations.sol and updated Escrow.sol smart contracts are central to the value proposition of the new ASv2 protocol.
Design a new rate limit for ODIS to support a more intuitive ASv2 onboarding experience
This matters because an intuitive rate limit when querying ODIS peppers, is a core user experience promise we are making to adopters of the new ASv2.
Circulate protocol design docs specifying user flows (such as onboarding and contact discovery for ASv2)
This matters because intuitive user onboarding and contact discovery experiences are key requirements shared with us by prospective ASv2 issuers. By circulating these user flows, we aim to ensure our vision for these features aligns with the needs of prospective ASv2 issuers.
What next?
We’d love to hear from you. If this sounds interesting or you have any questions, we greatly appreciate any feedback you might provide, whether good or bad. We are here to listen to you. Feel free to respond below however small or big your message might be! Thank you
Also feel free to respond below if you are interested in participating in our ASv2 private beta release
I agree with you, we need to do a lot better explaining how our products work and how they can be used Thank you for reminding us, this is definitely on our mind.
Can you enlight us examples of usages for this Phone-number Privacy Protocol?
I’m not sure I can enlighten you (), but I’m happy to give you some TLDRs and illustrative use cases.
Concept 1: Adding a salt to a phone number* to better store it.
TLDR: They allow you to store strings (phone numbers for example) in a more secure way
(Detail you can ignore, but adding for completeness) A pepper is like a salt but secret.
In cryptography, a pepper is a secret added to an input such as a password during hashing with a cryptographic hash function. This value differs from a salt in that it is not stored alongside a password hash, but rather the pepper is kept separate in some other medium
Concept 2: Using ODIS to generate peppers to better store phone numbers* on the blockchain
We use ODIS as a product to generate peppers so we can encrypt phone numbers* and store them on the blockchain (among other use cases)
ODIS also serves as a rate-limit to stop malicious actors from requesting too many peppers (which would make peppers pointless to start with)
Rate limiting is a strategy for limiting network traffic. It puts a cap on how often someone can repeat an action within a certain timeframe […]. Rate limiting can help stop certain kinds of malicious […] activity.
Concept 3: Using a registry to map encrypted phone numbers* to Celo addresses
We use a smart contract (Attestations.sol) to store mappings from phone numbers* (encrypted with peppers generated by ODIS) to Celo addresses.
To answer your question:
Could we “chain” our phone-number to a wallet-address (pubkey)?
Yes, you can create a pointer from your phone number to your Celo address on the blockchain, so anyone who’d like to know which Celo address belongs to you, can check that in the registry linked above. You can think of this like a pointer, but it is not capable of signing transactions on your behalf. Signing and submitting transactions is still performed using private keys under the hood.
How much it cost to call the “Attestator” contract for the peeper?
celocli identity:current-attestation-services runs forever, some Celo is also needed to check it?
All elected Validators are Attestators or there is a single address for this smart-contract?
If many, it means there are many deploys of this same contract? Trying to figure out.
What happens after we read the pepper, how we “match” it to the phone?
Are the phones attested, like a SMS verification to prove it is from who publishes it?
Can I register as many phones as I can pay to store this data?
Sorry for the storm of questions… sounds super interesting how to store encrypted data on-chain and (somehow) also the pepper hash, but I still need a pull here to see the full mechanism providing this match.
Hi all Our recent 5 week milestone is finished and we are following up to share what we accomplished and learnt.
Our goals for the past 5 weeks were:
The engineering team completed the smart contract security audit with Hacken.io.
You can find the audit report here.
The engineering team largely completed the ODIS v2.0.0 refactor. You can find their changes in the following pull request: ODIS 2.0.0 #9693. The engineering team is currently performing the last stages testing in QA/Review, which is why the PR hasn’t yet been merged.
We are being somewhat conservative in our self-evaluation and will not consider this stated goal fully accomplished. Our main take-away for future milestones is to insist on better “definitions of done”. For instance to better define the meaning of “refactoring ODIS” in this case.
The engineering team designed a new rate limit for ODIS using the OdisPayments.sol contract. You can find the code changes in the following pull request: On-chain ODIS for quota #9710. The contract is currently undergoing a security audit with Verilog.
The engineering team drafted very detailed user flows using the Mermaid diagramming language. We will share the user flows with early ASv2 adopters to ensure all parties are aligned.
Implementation contract implements some business logic users wants to interact with, but instead of interacting directly with the contract, they call functions from the proxy contract. As a result of such chaining, it becomes possible to swap the implementation contract with a different one
You hash the the pepper and plain text phone number using the following pattern {prefix}{e164_phone_number}{separator}{pepper} and look for the associated mapping in the Attestations.sol contract. For example, for a phone number +123456789 and a pepper 123abc you would hash tel://+123456789__123abc.
You can checkout the follow illustrative implementation to see the exact contract calls:
), next Monday (July 18) we are beginning a ~4.5 week milestone until Thursday, August 18.
(Pin Encrypted Account Recovery)
Thank you for reminding us, this is definitely on our mind.
), but I’m happy to give you some TLDRs and illustrative use cases.
The engineering team completed the smart contract security audit with 
The engineering team largely completed the ODIS v2.0.0 refactor. You can find their changes in the following pull request: 
