Dear Attestation Service operator (Validator) community
Two weeks ago, I shared a brief update in the following forum post Attestation Protocol (“ASv1”) Update and promised a more detailed follow up.
Brief recap
Copy of Attestation Protocol (“ASv1”) Update for ease of reference
First I wanted to note that we really appreciate your patience! This situation is new territory for us, so we have been particularly keen to investigate various options and implications before sharing a final recommendation. Thanks again for your patience!
Next steps and FAQs are detailed below to simplify the process going forward:
Next Steps (TLDR)
Validators participating in the attestation protocol:
- may turn off their Attestation Service instances immediately including any full nodes and SMS API subscriptions (i.e. Twilio, Nexmo, and MessageBird) supporting them
- should remain attestation signers on-chain until early next year when a governance proposal will be voted on to make the Attestations contract read-only
- In practice, this simply means not “de-registering” your attestation signer in the Accounts contract
- Learn more in “Why should validators remain attestation signers on-chain?” below
FAQ
Will the changes affect the eligibility for the Foundation Voting Policy?
Yes — as of Dec 7, the eligibility requirements for Foundation votes are
- Zero Slashing Incidents — validators can’t have been slashed within the last 6 months. Events are evaluated equally, with examples including downtime, security issues, etc.
- Uptime Performance — High performance uptime score over the past 30 days on Mainnet (or Baklava if not elected on Mainnet)
Validators should also remain attestation signers on-chain to remain eligible for Foundation votes until a governance proposal is passed early next year to upgrade the Attestations contract to read-only. In practice, this simply means not “de-registering” your attestation signer in the Accounts contract.
Why should validators remain attestation signers on-chain?
Validators should remain attestation signers on-chain because de-registering an attestation signer shrinks the attestation signer set and can potentially compromise ASv1 security guarantees (i.e. the requirement of a sufficiently large validator set to produce trustless attestations).
Specifically, this impacts the attestation issuer selection process:
when requesting new attestations, random validators are selected to perform phone number verification. This selection needs to be unpredictable to prevent Eve from creating an attestation for a phone number she doesn’t control. Suppose, for example, that instead validators were selected in a round robin fashion. Eve could request an attestation when it was the turn of a validator she controls to perform verification. Instead of sending an SMS to the phone number (since she doesn’t own it) she could just produce the correct verification code since she has access to the validator’s private key.
A governance proposal will be required to make the Attestations contract read-only following which de-registering an attestation signer on-chain will not impact ASv1 security assumptions anymore. Learn more about this in “Will any changes to the Attestations contract be required?”.
Will any changes to the Attestations contract be required?
Yes — a governance proposal will be submitted making the Attestations contract read-only (specific details to be confirmed in the new year).
At that point, validators may de-register their attestation signer on-chain while remaining eligible for Foundation votes and not impacting any ASv1 security assumptions.
Can phone numbers still be used on Celo?
Yes — developers can continue resolving phone numbers from the existing Attestations contract.
An alternative design of the attestation protocol has been launched in private beta with Kaala and Libera (the Impact Market wallet) as initial participating wallets.
Here is a short demo payment from Kaala to Libera using only a phone number:
Are validators required in the alternative design of the attestation protocol?
No — validator participation is not required, as the new attestation protocol can be operated by wallets alone.
However, interested validators may participate in the new attestation protocol by providing their services to willing buyers (e.g. wallets) that would prefer to not integrate SMS APIs directly.
For this reason, validators may consider maintaining their SMS API subscriptions (Twilio, Nexmo, and MessageBird) but without any guarantee of use.
Will the changes be reflected in the Celo Documentation?
Yes — the following changes will be made:
- Add warnings to the relevant documentation to highlight the changes
- Remove Attestation Service steps from the “setting up a validator” guide