Decentralized attestations as a public service
Recently, the Ethereum developer conference ETHDenver was in full swing, and a somewhat unfamiliar term “Attestation” was mentioned by many developers. Meanwhile, Ethereum has launched a public good called Ethereum Attestation Service (EAS) to support the creation, verification, and revocation of various attestations. In a slightly convoluted sense, attestation is a statement about the authenticity of certain information endorsed by an endorser. Three types of roles are defined within an attestation system: Attestors, Verifiers, and Users. An attestor is responsible for issuing attestations for users, with the validity of these attestations are verified and guaranteed by verifiers.
To explain the basic idea of EAS, a simple story is like this: a university (Attestor) issues a digitalized graduation certificate (attestation) to a graduate (User) by signing with the university’s private key. The certificate can be verified and accepted by a certain event organizer (Verifier) to reduce the graduate’s registration fees. Furthermore, the certificate contains specific information about the student, signed with the university’s private key, and is stored on Ethereum (see here). Any third-party application can access and verify it at any time. Such a certificate can also be placed off-chain for the privacy purpose.
(source: https://docs.attest.sh/)
The launch of EAS undoubtedly builds a public infrastructure for various Web 3.0 applications, including DID, SBT, reputation systems, DeFi, and more. EAS provides the ability for anyone to define a business model (schema) that specifies the data types, formats, and composition of proof, which can be used by any developers or users. Anyone can create attestations as an Attestor, and anyone can verify on-chain attestations that meet a specific schema. Attestations can be stored on-chain or off-chain depending on the use-cases.
With a relatively loose paradigm, i.e., requiring two Solidity contracts, EAS has created a decentralized public attestation service. Considering a traditional centralized attestation system, such as Discord, where massive attestation data about user roles are stored at the back-end servers. Such attestation data cannot be freely transferred or used across platforms, and it cannot be automatically revoked once users delete their accounts. In contrast, a significant advantage of EAS is decentralization, which ensures that any applications can use EAS’s attestation data to improve the transparency and composability. EAS can be implemented and deployed directly on Ethereum mainnet, or on L2 networks like Arbitrum.
(source: https://attest.sh/)
From a business perspective, EAS and other attestation systems can be leveraged for developing techniques like sybil resistance and on-chain governance. The attestation framework could be gradually expanded and integrated with off-chain attestations, to be facilitated with complicated scenarios such as physical access control, customer crediting, and carbon footprint, etc.
Data authenticity, a non-negligible issue.
Data authenticity is a security property which ensures the provided data is from the claimed sender, as well as the implied integrity meaning the data has not been tampered with during the transmission.
| Data authentication consists of data integrity and data origin authentication. With data integrity the recipient can be sure that the data has not changed. Data origin authentication proves to the recipient that the stated sender has originated the data. — Chapter 3, ZigBee and IEEE 802.15.4 Protocol Layers
The development with on-chain attestations will be very promising, thanks to the core features of blockchains for the transparency and integrity. However, the situation changes when dealing with off-chain data.
One sample is about using off-chain data for on-chain service. Alice logs into a defi application. She is willing to provide personal financial information (such as bank details and account statements) for discounted loan services from the defi application. The critical issue is to find who can guarantee the authenticity of Alice’s personal financial information?
- Banks can provide a stamped proof, but such a proof is hard to be formatted and verified by the defi application.
- Alice can promise the provided financial information is accurate. However, such a promise is not safe when someone uses a fake identity to obtain illegal gains through flash loans.
In fact, the verification towards off-chain data is usually intentionally or unintentionally avoided. Usually, we are unable to check whether the data claimed by users is correct or not, no matter if it’s about personal age, gender, or even off-chain assets.
zkAttestation, to verify off-chain data
Fortunately, developers are not powerless on such problems. Off-chain data cannot be encoded as various forms, like text, images, videos or even binary code. And most of the user-generated off-chain data can be collected by users themselves via standard channels, such as HTTPS/TLS.
| Hint: HTTPS is an HTTP channel with extra security. By setting up a TLS layer on top of HTTP protocol, it provides data confidentiality and integrity for communications between the two parties of an internet application.
Consider this scenario: A rare-disease patient Bob stores his personal electronic medical records (EMR) at an Internet hospital. Bob would like to receive some assistance from an on-chain service charityDAO. Traditionally, Bob can perform like:
- Bob obtains his EMR through the data interface from the internet hospital App.
- Bob sends the EMR information to the charityDAO App.
- charityDAO confirms that Bob’s EMR information is correct, and the medical advice has been signed by a professional physician.
- charityDAO transfers funds from its smart contract to Bob’s wallet address.
This process looks quite simple, but there still exist some issues.
- The data interface is usually built on standard HTTPS/TLS protocol, which indeed guarantees the authenticity of the EMR information. However, charityDAO could still legitimately doubt whether Bob has modified the EMR or even forged the physician’s signature. Since Bob has enough time to carry out attacks.
- Private information such as rare diseases and other personal details is not well protected.
A straightforward idea is to let a witness, to observe and even participate in the entire communication, and to give a conclusion for data authentication. Such a witness cannot obtain the details of the EMR, but he is still able to verify the authenticity of any communicated data in a “black-box” manner. Fortunately, zkAttestation built on zero-knowledge proof (ZKP) and secure multi-party computation (MPC) provides such a secure “witness mechanism”.
In general, zkAttestation introduces a computing node Pauli (if readers are familiar with MPC technology, it can be regarded as a conventional MPC node) in the above scenario, which participates in the entire process of the session between Bob and the hospital. The node performs a complete blind authentication and signs on the data obtained by Bob from the hospital. CharityDAO can simply verify Pauli’s signature to confirm the authenticity of Bob’s EMR data, from an HTTPS session witnessed by Pauli.
Some subtleties includes:
- Pauli will execute MPC protocols with Bob, to simulate a TLS client. The MPC protocols guarantee the security in case that if Pauli is absent, Bob is unable to perform the HTTPS communication with the hospital independently. Note the communications includes establishing the HTTPS channel, as well as sending and receiving communication data. In other words, Pauli witnessed the entire process of data acquisition comprehensively, except knowing the raw data about Bob’s EMR information.
- Pauli can perform specific zero-knowledge proof protocols with Bob, including interactive zero-knowledge proofs (iZK) and non-interactive zero-knowledge proofs (NIZK), by which Pauli can be confirmed that Bob’s disease characteristics meet certain donation requirements without knowing any details.
This kind of pre-check greatly enhances the verifiability of off-chain data and is fully compatible with EAS framework. By upgrading the computing node to a standard Ethereum attestor, zkAttestation attestors support anyone to use these authentic off-chain data attestations. Indeed, users’ off-chain data can be converted into standardized Ethereum attestations signed by zkAttestation attestors, in a verifiable and privacy-friendly way, thereby promoting more innovative applications, such as distributed credit lending, charity DAO, and blockchain-based job applications, etc.
From the application security’s perspective, anyone can run such a computing node to provide endorsement of users’ off-chain data on any traditional web applications, benefiting from the widespread HTTPS/TLS protocol.
We will introduce more technical details about zkAttestation in the follow-up articles.
