.png%3Falt%3Dmedia%26token%3D7fba075e-cb81-409a-9e7b-b8c2db3d29c5)
.png%3Falt%3Dmedia%26token%3D7fba075e-cb81-409a-9e7b-b8c2db3d29c5)
.png?alt=media&token=2087c965-a934-4703-8eed-234032b19b57)
Comment on page
Optimistic Attestation
Attest first, verify later
On-chain attestation is pivotal in achieving Proof of Machinehood. It comprises a public display of evidence that convinces others of the system's integrity, including elements such as hardware, firmware, software, applications, services, and more. However, verifying individual components grows increasingly challenging with the rising complexity and diversity of system components. Each element presents a unique method of attestation through various cryptographic algorithms, leading to potential incompatibilities and substantial costs when executed and stored on blockchain systems like Ethereum.
The concept of Optimistic Attestation was inspired by other optimistic systems, such as Layer-2 optimistic rollups and optimistic relays in proposer builder separation. The goal is to provide a swift lane for delivering attestation on-chain from the moment of creation by the attestor. This is achieved by presuming honesty: in the execution by the rollup operator; and honest attestations from the attestor. All data is readily available on-chain so any discrepancies can be disputed using fraud proof systems. This serves as a deterrent to discourage any potential malicious actions.
Attestation is an integral part of real-world applications, anchoring trust and certifying facts. A prevalent example in the Web2 world is the HTTPS certificate used by web servers to showcase their legitimacy and establish secure end-to-end connections. Although the server-side certificate verification is straightforward and efficient, it requires considerable effort to build an out-of-band trust system and keep it updated. This extends to system updates refreshing the list of renowned certificate authorities and revoked certificates.
When attestations extend to diverse systems, each presents preferred cryptographic ciphers and hashing algorithms. These establish trust and store attestation data influenced by a variety of factors like manufacturer adoption, code compatibility, computational complexity, storage limits, and more. Many of these are not inherently crypto-native and poorly suited for native verification on Ethereum-like blockchains.
Storing and verifying attestation on-chain is a twofold process. Attestors who have vested interests and stand to gain economically bear the storage costs. However, verification costs are preposterously high due to the need to reproduce existing verification logic not designed for restricted environments like blockchains.
Major challenges in verification include the lack of on-chain trust anchors and the need to traverse the chain of trust, where verifying each individual step demands hefty computation. This is prohibitive, even with apparent benefits in a Layer-1 environment.
Executing this on a rollup presents an economically viable approach that makes attestations affordable for many applications. Attestation rollup’s additional benefit lies in providing a trust-minimized approach making the L2 state accessible at L1.
By using optimistic rollup with fraud proof, you can expedite the process from creation to publication of attestations. This is advantageous in scenarios demanding real-time performance where the delay in attestations could potentially bottleneck the process. For instance, on a per-transaction basis, any delay in attestation would consequently delay the transaction, disrupting subsequent executions.
The key concept for optimistic attestation centers around the assumption of an honest attestor, which further reduces the gap between the time when an attestation is available and when it can be safely consumed by other parties. The credibility of an attestor depends on various factors, including the security deposit and the duration and reputation of the attestation service, etc.
The whole workflow is as follows:
- 1.Attestors can publish attestations that can be challenged by anyone on-chain through a verification process.
- 2.A successfully verified attestation becomes a permanent part of the attestation layer.
- 3.Depending on the attestation’s importance, a security deposit may be required upon creation of a new attestation, even without initiating the verification process.
- 4.Challengers need not provide a security deposit. They do bear the cost of the verification, but if the challenge is legitimate, they can recoup these expenses.
- 5.The security deposit of the attestor forms a significant part of this reimbursement. Additional incentives can be provided during the initial stages to promote protocol adoption.
Last modified 3mo ago