diff --git a/docs/core--concepts/how-eas-works.md b/docs/core--concepts/how-eas-works.md index 130ed28..0137347 100644 --- a/docs/core--concepts/how-eas-works.md +++ b/docs/core--concepts/how-eas-works.md @@ -14,7 +14,7 @@ Attestations are the building blocks of building trust online. Think of an attes But for this system to work seamlessly, we need a standardized way to structure this data. This is where schemas come into play. ## Schemas give structure to the attestation -Think of a schema as a blueprint or template. It defines the structure and format of the data you want to attest to. For example if you want to attest to someone you trust, all you'd need is a true false field for "isTrusted". Or if you wanted to a vote, you might have a "eventName" and a "location" and "startTime" and "endTime". It's the builder's choice to determine the right schema for their particular use case. +Think of a schema as a blueprint or template. It defines the structure and format of the data you want to attest to. For example if you want to attest to someone you trust, all you'd need is a true false field for "isTrusted". Or if you wanted to vote, you might have a "eventName" and a "location" and "startTime" and "endTime". It's the builder's choice to determine the right schema for their particular use case. Here's the general flow of how a schema is registered: 1. The schema's structure is defined (e.g., what fields it will have and the data types). diff --git a/docs/core--concepts/onchain-vs-offchain.md b/docs/core--concepts/onchain-vs-offchain.md index 8264976..e7f6ca6 100644 --- a/docs/core--concepts/onchain-vs-offchain.md +++ b/docs/core--concepts/onchain-vs-offchain.md @@ -26,7 +26,7 @@ Attestations can be made either onchain or offchain. While **onchain attestation | **Security** | Secured by blockchain consensus | Secured by cryptographic signatures | | **Scalability & Performance** | Requires onchain transactions to process | Faster processing times; can lead to better scalability | | **Timestamping** | Inherent timestamping by the blockchain | The UID of the attestation can be timestamped onchain for verifiability | -| **Lifecycle Management** | Revocations stored onchain | Revocations require need separate management | +| **Lifecycle Management** | Revocations stored onchain | Revocations require separate management | ## Best Practices @@ -45,7 +45,7 @@ Attestations can be made either onchain or offchain. While **onchain attestation It's important for builders to consider what data needs to go onchain or should live offchain. A common misconception with onchain attestations is that they do not have privacy features. There are several ways to keep onchain attestation data more private. - **Offchain:** Generally preferable for confidentiality as no data is publicly visible unless explicitly stored in places like IPFS. -- **Private Data Attestations:** An innovative solution to attest nearly an infinite amount of private data by attesting its [merkle root onchain](/docs/tutorials/private-data-attestations.md). +- **Private Data Attestations:** An innovative solution to attest nearly an infinite amount of private data by attesting its [Merkle root onchain](/docs/tutorials/private-data-attestations.md). - **Onchain Adaptations:** Rather than placing the entire data on why something was true, one could attest to results, such as a true/false field of the verification. - **Leverage ZKP:** Generate a zero-knowledge proof from the attestation data to keep information private and trustworthy. - **Bottom Line:** Prioritize privacy. Whether you're storing a verification process or the verification result, sensitive data management is paramount. @@ -56,7 +56,7 @@ Navigating the world of attestations might seem complex, but it boils down to un - **Authenticity is a Given:** Both onchain and offchain attestations offer the authenticity of a digital signature. No matter where it's stored, if the data changes, the signature won't verify. - **Smart Contract Interaction:** If your project requires smart contracts to frequently access or verify attestation data, onchain is your best bet. It ensures that the data is always available on the Ethereum blockchain for smart contracts to interact with. -- **Privacy Matters:** If you're handling sensitive data or want to control who sees what and when, offchain offers more flexibility. Store data privately and share it selectively. But remember, onchain isn't out of the race for privacy. With techniques like private data attestations, you can store a merkle root onchain and then selectively disclose specific parts of your data when needed. +- **Privacy Matters:** If you're handling sensitive data or want to control who sees what and when, offchain offers more flexibility. Store data privately and share it selectively. But remember, onchain isn't out of the race for privacy. With techniques like private data attestations, you can store a Merkle root onchain and then selectively disclose specific parts of your data when needed. In short, think about how your data will be used. If it's crucial for smart contracts, onchain might be the way. If it's about privacy and controlled sharing, offchain could be your answer. And sometimes, a blend of both might be the perfect solution. The power to choose is yours. diff --git a/docs/core--concepts/privacy.md b/docs/core--concepts/privacy.md index 84b94ac..a17dc60 100644 --- a/docs/core--concepts/privacy.md +++ b/docs/core--concepts/privacy.md @@ -15,9 +15,9 @@ The blockchain's defining feature of immutability is a double-edged sword. While Below are a few concepts to consider when building with privacy in mind. ### Private Data Attestations -Private Data Attestations are a way to attest to nearly an infinite amount of arbitrary data, generate a merkle tree of that data, and then only attest to the merkle root onchain or offchain. The data can then be provided to specific individuals and allow them to selectively disclose or verify the data against the merkle root. +Private Data Attestations are a way to attest to nearly an infinite amount of arbitrary data, generate a Merkle tree of that data, and then only attest to the Merkle root onchain or offchain. The data can then be provided to specific individuals and allow them to selectively disclose or verify the data against the Merkle root. -For example, a university could attest to a student's entire transcript by creating a merkle tree of the courses and grades, and then only attesting to the root onchain. The student can then provide specific courses to employers without revealing their entire transcript. +For example, a university could attest to a student's entire transcript by creating a Merkle tree of the courses and grades, and then only attesting to the root onchain. The student can then provide specific courses to employers without revealing their entire transcript. **📘 Read More:** [**Private Data Attestations**](/docs/tutorials/private-data-attestations.md) diff --git a/docs/developer-tools/eas-sdk.md b/docs/developer-tools/eas-sdk.md index 396a859..61d3227 100644 --- a/docs/developer-tools/eas-sdk.md +++ b/docs/developer-tools/eas-sdk.md @@ -3,7 +3,7 @@ sidebar_position: 1 --- # EAS SDK -Here, you'll find everything you need to get started with integrating EAS into a **Javascript/Typescript** project. +Here, you'll find everything you need to get started with integrating EAS into a **JavaScript/TypeScript** project. You can also reference our SDK directly in the [**SDK Github repo**](https://github.com/ethereum-attestation-service/eas-sdk). diff --git a/docs/developer-tools/hash-a-file.md b/docs/developer-tools/hash-a-file.md index 67df61e..6bf60b2 100644 --- a/docs/developer-tools/hash-a-file.md +++ b/docs/developer-tools/hash-a-file.md @@ -12,7 +12,7 @@ You can hash any local file: - Images - Any type of file -## Understanding How Hash's Work +## Understanding How Hashes Work A hash function like `SHA256` takes an input (or 'message') and returns a fixed-size string of bytes. The output, typically a 'digest', is unique to each unique input. Even a minor change, like a single letter or single pixel of the file changes, it will produce a vastly different output, this is also known as the `avalanche effect`. This makes hashing a powerful tool for verifying data integrity. SHA-256, which stands for Secure Hash Algorithm 256-bit, is one of the cryptographic hash functions in the SHA-2 family. It's widely used in the world of cryptography and is integral to the functioning of modern technologies, including blockchain systems. diff --git a/docs/developer-tools/sdk-wagmi.md b/docs/developer-tools/sdk-wagmi.md index 87cecf9..ab589a7 100644 --- a/docs/developer-tools/sdk-wagmi.md +++ b/docs/developer-tools/sdk-wagmi.md @@ -28,7 +28,7 @@ The `useProvider` hook gets the `publicClient` and returns a provider compatible Usage: ```typescript -const signer = useProvider(); +const provider = useProvider(); ``` ### Code Implementation diff --git a/docs/developer-tools/verify-timestamp.md b/docs/developer-tools/verify-timestamp.md index 55ade51..0ddaa30 100644 --- a/docs/developer-tools/verify-timestamp.md +++ b/docs/developer-tools/verify-timestamp.md @@ -3,15 +3,15 @@ sidebar_position: 4 --- # Batch Timestamping -Timestamping is a crucial aspect of ensuring the authenticity and integrity of data. Timestamping provides a verifiable proof of existence for offchain attestations. This doc delves into the concept of Merkle Trees and how they can be used to efficiently timestamp multiple offchain attestations in a single transaction. +Timestamping is a crucial aspect of ensuring the authenticity and integrity of data. Timestamping provides a verifiable proof of existence for offchain attestations. This doc delves into the concept of Merkle trees and how they can be used to efficiently timestamp multiple offchain attestations in a single transaction. ## Understanding Merkle Trees -A Merkle Tree is a binary tree where each leaf node represents a piece of data, and each non-leaf node is a hash of its child nodes. The topmost node, known as the Merkle Root, provides a single hash representation for all the data in the tree. +A Merkle tree is a binary tree where each leaf node represents a piece of data, and each non-leaf node is a hash of its child nodes. The topmost node, known as the Merkle root, provides a single hash representation for all the data in the tree. ### Key Features: - **Efficiency:** Allows for efficient and secure verification of large data sets. -- **Proof of Inclusion:** Any piece of data can be verified to be a part of the tree by providing a 'proof path', a sequence of hashes leading to the Merkle Root. -- **Immutability:** Any change in data, even at the leaf level, results in a change in the Merkle Root. +- **Proof of Inclusion:** Any piece of data can be verified to be a part of the tree by providing a 'proof path', a sequence of hashes leading to the Merkle root. +- **Immutability:** Any change in data, even at the leaf level, results in a change in the Merkle root. ## Why Timestamp Offchain Attestations? Offchain attestations, by their nature, lack an onchain consensus timestamp, making their exact time of creation unverifiable. Timestamping the UID of the offchain attestation onchain provides: @@ -20,20 +20,20 @@ Offchain attestations, by their nature, lack an onchain consensus timestamp, mak - **Data Integrity:** The UID, being a unique hash of the entire valid attestation data, ensures that the attestation hasn't been altered post-timestamping. ## Batch Timestamping with Merkle Trees -While individual timestamping is straightforward, it may not be efficient for large volumes of attestations. This is where Merkle Trees shine: +While individual timestamping is straightforward, it may not be efficient for large volumes of attestations. This is where Merkle trees shine: -- **Batch Multiple UIDs:** Instead of timestamping each UID individually, multiple UIDs are combined to form a Merkle Tree. -- **Generate the Merkle Root:** The Merkle Root, representing all the UIDs, is generated. -- **Single Onchain Transaction:** Only the Merkle Root is timestamped onchain, saving on transaction costs and gas. -- **Proof of Inclusion:** Any individual UID can later be verified against the timestamped Merkle Root. +- **Batch Multiple UIDs:** Instead of timestamping each UID individually, multiple UIDs are combined to form a Merkle tree. +- **Generate the Merkle Root:** The Merkle root, representing all the UIDs, is generated. +- **Single Onchain Transaction:** Only the Merkle root is timestamped onchain, saving on transaction costs and gas. +- **Proof of Inclusion:** Any individual UID can later be verified against the timestamped Merkle root. ## Using easscan.org for Batch Timestamping EAS provides a simple container on the easscan.org site to facilitate this process: - **Paste UIDs:** Users can easily paste multiple offchain attestation UIDs. -- **Timestamp All:** Upon clicking "Timestamp All", the site generates the Merkle Root for all the UIDs. -- **Onchain Timestamping:** The platform assists users in creating an onchain timestamp for the Merkle Root. -- **Results Page:** Post timestamping, users receive a results page listing all UIDs that are part of the timestamped Merkle Root. +- **Timestamp All:** Upon clicking "Timestamp All", the site generates the Merkle root for all the UIDs. +- **Onchain Timestamping:** The platform assists users in creating an onchain timestamp for the Merkle root. +- **Results Page:** Post timestamping, users receive a results page listing all UIDs that are part of the timestamped Merkle root. ## Example Flow Here's an example batch timestamp flow on Sepolia. @@ -46,16 +46,16 @@ Here's an example batch timestamp flow on Sepolia. ![Timestamp UID List](./img/batch-timestamp-list.png) -3. Nice! Now we can see the `Batch Timestamp Details` which generated a Merkle Tree of the **12** `UIDs`. You can see the onchain transaction ID of `0xb63fcec1b612fbcd3c2c4e301cc6d9fad4d0bb11234be817ecd014c2661d0f85`. You can see this example here: [https://sepolia.easscan.org/timestamp/0xb63fcec1b612fbcd3c2c4e301cc6d9fad4d0bb11234be817ecd014c2661d0f85](https://sepolia.easscan.org/timestamp/0xb63fcec1b612fbcd3c2c4e301cc6d9fad4d0bb11234be817ecd014c2661d0f85) +3. Nice! Now we can see the `Batch Timestamp Details` which generated a Merkle tree of the **12** `UIDs`. You can see the onchain transaction ID of `0xb63fcec1b612fbcd3c2c4e301cc6d9fad4d0bb11234be817ecd014c2661d0f85`. You can see this example here: [https://sepolia.easscan.org/timestamp/0xb63fcec1b612fbcd3c2c4e301cc6d9fad4d0bb11234be817ecd014c2661d0f85](https://sepolia.easscan.org/timestamp/0xb63fcec1b612fbcd3c2c4e301cc6d9fad4d0bb11234be817ecd014c2661d0f85) ![Timestamp Result](./img/timestamp-result.png) -4. When you go to a public offchain attestation record that has been timestamped, you'll see there is an `onchain timestamp` in the top right hand side of the attestation record. You can click the eye and it will take you to the merkle tree record and highlight the `UID` is in fact a part of the batch timestamp record. +4. When you go to a public offchain attestation record that has been timestamped, you'll see there is an `onchain timestamp` in the top right hand side of the attestation record. You can click the eye and it will take you to the Merkle tree record and highlight the `UID` is in fact a part of the batch timestamp record. ![Timestamp Result](./img/onchain-timestamp-record.png) -5. This is showing that the `UID` of the offchain attestation was found in the merkle tree. +5. This is showing that the `UID` of the offchain attestation was found in the Merkle tree. ![Timestamp Highlighted](./img/timestamp-highlighted.png) ## Conclusion -Merkle Trees offer a powerful and efficient mechanism to timestamp large volumes of offchain attestations with a single onchain transaction. This ensures not only the proof of existence but also the integrity of the attestations, providing a robust and cost-effective solution for developers and users alike. +Merkle trees offer a powerful and efficient mechanism to timestamp large volumes of offchain attestations with a single onchain transaction. This ensures not only the proof of existence but also the integrity of the attestations, providing a robust and cost-effective solution for developers and users alike. diff --git a/docs/easscan/utilities.md b/docs/easscan/utilities.md index 6bcf7e9..4792fd6 100644 --- a/docs/easscan/utilities.md +++ b/docs/easscan/utilities.md @@ -23,7 +23,7 @@ Easily hash any file and attest to it. There are two schemas you can use for thi ![Ethereum Whitepaper](./img/ethereum-whitepaper-hash-verified.png) ### Private Data Attestations -Attest to the merkle root of a bunch of private data. This can be useful for attesting to an `allowlist` of users, selective information or private info. The `merkle root` is attested to onchain and then you can selectively share each of the individual merkle tree leaves, effectively selectively disclosing the information, and allowing others to verify that that piece of data was indeed a part of the merkle tree. The value comes from the entity that attested to the private data merkle root, and then allowing others to verify the data. +Attest to the Merkle root of a bunch of private data. This can be useful for attesting to an `allowlist` of users, selective information or private info. The `Merkle root` is attested to onchain and then you can selectively share each of the individual Merkle tree leaves, effectively selectively disclosing the information, and allowing others to verify that that piece of data was indeed a part of the Merkle tree. The value comes from the entity that attested to the private data Merkle root, and then allowing others to verify the data. **Tutorial:** [Private Data Attestations](/docs/tutorials/private-data-attestations.md) @@ -49,7 +49,7 @@ Upload any offchain attestation raw data into this tool so you can easily see if ![Verify Offchain Attestation Container](./img/verify-offchain.png) ### Timestamping Offchain Attestations -Offchain attestations do not have a verifiable timestamp. If you want to timestamp multiple `UID`s of the offchain attestation, it will generate a merkle root and timestamp just that root. Then you can verify any of the individual UIDs. +Offchain attestations do not have a verifiable timestamp. If you want to timestamp multiple `UID`s of the offchain attestation, it will generate a Merkle root and timestamp just that root. Then you can verify any of the individual UIDs. **Tutorial:** [Timestamping Offchain](/docs/developer-tools/verify-timestamp) diff --git a/docs/idea--zone/use--case--examples/digital-identity.md b/docs/idea--zone/use--case--examples/digital-identity.md index 4230e54..14a3af5 100644 --- a/docs/idea--zone/use--case--examples/digital-identity.md +++ b/docs/idea--zone/use--case--examples/digital-identity.md @@ -33,7 +33,7 @@ The privacy of individuals must be a top priority. For example, instead of a gov Similarly, for a KYC compliance, the KYC service would only need to attest to a true/false flag that shows that the address successfully passed their KYC compliance process. It wouldn't need to store any information beyond that. -EAS also allows users to create [Private Data Attestations](/docs/tutorials/private-data-attestations). `Private Data Attestations` take advantage of Merkle Trees' unique capabilities to selectively disclose specific data fields without compromising overall privacy. This innovative feature allows users to create attestations with a single "private data" field, which contains the hash of a Merkle tree root. As a result, users can securely store and share particular parts of their attested data while preserving their privacy. +EAS also allows users to create [Private Data Attestations](/docs/tutorials/private-data-attestations). `Private Data Attestations` take advantage of Merkle trees' unique capabilities to selectively disclose specific data fields without compromising overall privacy. This innovative feature allows users to create attestations with a single "private data" field, which contains the hash of a Merkle tree root. As a result, users can securely store and share particular parts of their attested data while preserving their privacy. Attestations with `Zero Knowledge Proofs` are another path forward to explore. diff --git a/docs/idea--zone/use--case--examples/healthcare-records.md b/docs/idea--zone/use--case--examples/healthcare-records.md index 71b1a27..de70a8b 100644 --- a/docs/idea--zone/use--case--examples/healthcare-records.md +++ b/docs/idea--zone/use--case--examples/healthcare-records.md @@ -21,7 +21,7 @@ Attestation-based healthcare records can also be used to track medication adhere ::: EAS does not presuppose which privacy-preserving technology is best for any use case. However, the privacy of individuals must be a top priority. -EAS also allows users to create [Private Data Attestations](/docs/tutorials/private-data-attestations). `Private Data Attestations` take advantage of Merkle Trees' unique capabilities to selectively disclose specific data fields without compromising overall privacy. This innovative feature allows users to create attestations with a single "private data" field, which contains the hash of a Merkle tree root. As a result, users can securely store and share particular parts of their attested data while preserving their privacy. +EAS also allows users to create [Private Data Attestations](/docs/tutorials/private-data-attestations). `Private Data Attestations` take advantage of Merkle trees' unique capabilities to selectively disclose specific data fields without compromising overall privacy. This innovative feature allows users to create attestations with a single "private data" field, which contains the hash of a Merkle tree root. As a result, users can securely store and share particular parts of their attested data while preserving their privacy. Attestations with `Zero Knowledge Proofs` are another path forward to explore. diff --git a/docs/idea--zone/use--case--examples/proof-of-funds.md b/docs/idea--zone/use--case--examples/proof-of-funds.md index ecc659f..6a01111 100644 --- a/docs/idea--zone/use--case--examples/proof-of-funds.md +++ b/docs/idea--zone/use--case--examples/proof-of-funds.md @@ -8,7 +8,7 @@ sidebar_position: 9 In the world of finance, proving funding can be a time-consuming and invasive process. Financial institutions often require a significant amount of documentation to verify that an individual or entity has sufficient funds for a transaction. The process can be challenging for individuals and businesses, as it often requires sharing sensitive financial information that could be at risk of exposure. ## Opportunity -Proof of funds attestations can provide a secure and efficient way to verify the funding status of an individual or entity without requiring the disclosure of sensitive information. By using private data attestations with Merkle Trees, users can selectively disclose specific data fields, such as the current cash balance or credit score, while keeping other information private. This allows for a more tailored approach to information sharing, reducing the risk of fraud or errors and streamlining the verification process. +Proof of funds attestations can provide a secure and efficient way to verify the funding status of an individual or entity without requiring the disclosure of sensitive information. By using private data attestations with Merkle trees, users can selectively disclose specific data fields, such as the current cash balance or credit score, while keeping other information private. This allows for a more tailored approach to information sharing, reducing the risk of fraud or errors and streamlining the verification process. ## Example Alice wants to make a cash offer on a new home, but first, she must prove that she has sufficient Proof of Funds to pay for it. diff --git a/docs/idea--zone/use--case--examples/vital-records.md b/docs/idea--zone/use--case--examples/vital-records.md index 80a05e7..c2e2a73 100644 --- a/docs/idea--zone/use--case--examples/vital-records.md +++ b/docs/idea--zone/use--case--examples/vital-records.md @@ -9,7 +9,7 @@ Obtaining a copy of a birth certificate can be a long and inefficient process. O In addition, paper-based records can be prone to fraud and errors, leading to long-term risks and challenges for individuals and governments alike. Moreover, paper-based systems are not privacy-preserving, and sensitive information such as the mother's maiden name, home address, and social security number can be exposed. ## Opportunity -Attestations, together with privacy-preserving technologies like zk or merkle trees, can provide a secure and efficient solution for vital records, such as birth certificates. By recording birth certificates on Ethereum, individuals can easily access and share their official documents in a matter of minutes, rather than weeks, while keeping their sensitive information private. +Attestations, together with privacy-preserving technologies like zk or Merkle trees, can provide a secure and efficient solution for vital records, such as birth certificates. By recording birth certificates on Ethereum, individuals can easily access and share their official documents in a matter of minutes, rather than weeks, while keeping their sensitive information private. Attestation-based vital records also reduce the risk of fraud and errors, as the immutability of blockchain ensures that records cannot be tampered with or altered. @@ -23,7 +23,7 @@ With attestations and privacy-preserving technologies, the parent can access the ::: EAS does not presuppose which privacy-preserving technology is best for any use case. However, the privacy of individuals must be a top priority. -EAS also allows users to create [Private Data Attestations](/docs/tutorials/private-data-attestations). `Private Data Attestations` take advantage of Merkle Trees' unique capabilities to selectively disclose specific data fields without compromising overall privacy. This innovative feature allows users to create attestations with a single "private data" field, which contains the hash of a Merkle tree root. As a result, users can securely store and share particular parts of their attested data while preserving their privacy. +EAS also allows users to create [Private Data Attestations](/docs/tutorials/private-data-attestations). `Private Data Attestations` take advantage of Merkle trees' unique capabilities to selectively disclose specific data fields without compromising overall privacy. This innovative feature allows users to create attestations with a single "private data" field, which contains the hash of a Merkle tree root. As a result, users can securely store and share particular parts of their attested data while preserving their privacy. Attestations with `Zero Knowledge Proofs` are another path forward to explore. diff --git a/docs/purpose/public-good.md b/docs/purpose/public-good.md index f8d6028..46984c0 100644 --- a/docs/purpose/public-good.md +++ b/docs/purpose/public-good.md @@ -39,8 +39,8 @@ Any small contribution whether it's calling out something to update on a docs pa #### Grants & Donations Many teams start public goods by bootstrapping funds and their time or by receiving donations, while noble, these funding sources are often not sustainable long-term. One step up are grants tailored for public goods. Grant programs are plentiful in the Ethereum Ecosystem with projects like: -- Funding Platforms ([Gitcoin](https://grants.gitcoin.co/), [Giveth](https://giveth.io/), [The Giving Block](https://thegivingblock.com/), [Endaoment](https://endaoment.org/) et.al) -- Ecosystem Grants ([Ethereum Foundation](https://ethereum.org/en/foundation/), [OP](https://community.optimism.io/docs/governance/get-a-grant/), [Arbitrum](https://arbitrum.foundation/grants?address=0xeee68aECeB4A9e9f328a46c39F50d83fA0239cDF), et.al). +- Funding Platforms ([Gitcoin](https://grants.gitcoin.co/), [Giveth](https://giveth.io/), [The Giving Block](https://thegivingblock.com/), [Endaoment](https://endaoment.org/), et al.) +- Ecosystem Grants ([Ethereum Foundation](https://ethereum.org/en/foundation/), [OP](https://community.optimism.io/docs/governance/get-a-grant/), [Arbitrum](https://arbitrum.foundation/grants?address=0xeee68aECeB4A9e9f328a46c39F50d83fA0239cDF), et al.) #### Retroactive Funding Ecosystems like Optimism have been championing [Retroactive Public Goods Funding](https://app.optimism.io/retropgf). The core idea behind retroactive funding is that it's easier to determine the impact of an innovation after it's made its impact. Thus, many teams like Optimism will fund Public Goods for the impact they make on their own ecosystem. As the impact is made, their ecosystem hits new growth goals or revenue targets and then allocates that benefit back to the team or innovation that helped them get there. Then these teams continue building into a virtuous cycle of innovation and growth. diff --git a/docs/quick--start/faqs.md b/docs/quick--start/faqs.md index e254a0b..186fa3f 100644 --- a/docs/quick--start/faqs.md +++ b/docs/quick--start/faqs.md @@ -88,7 +88,7 @@ No. Attestations are immutable to maintain their trustworthiness. If modificatio
How do you keep attestations private? -EAS offers the flexibility of public and private attestations. Depending on the use case, data can be encrypted, kept off-chain, or selectively disclosed using "Private Data Attestations" and merkle trees. +EAS offers the flexibility of public and private attestations. Depending on the use case, data can be encrypted, kept off-chain, or selectively disclosed using "Private Data Attestations" and Merkle trees.
@@ -157,7 +157,7 @@ Each attestation has the following struct:
How do we coordinate around the right schemas? -EAS does not presuppose the right schemas for a use case. It's up to the community to coordinate and decide which schemas to use for a particular use case. To help foster this discussion, we have created a dedicated EAS forum at https://forum.easscan.org +EAS does not presuppose the right schemas for a use case. It's up to the community to coordinate and decide which schemas to use for a particular use case. To help foster this discussion, we have created a dedicated EAS forum at https://forum.attest.sh.
diff --git a/docs/quick--start/use-cases-overview.md b/docs/quick--start/use-cases-overview.md index 29b1c43..4412414 100644 --- a/docs/quick--start/use-cases-overview.md +++ b/docs/quick--start/use-cases-overview.md @@ -7,7 +7,7 @@ Attestations can greatly enhance trust in various interactions across a range of :::tip Tip Looking for more detail? -Checkout our [Use Cases Page](/docs/category/use-cases). +Checkout our [Use Cases Page](/docs/category/example-use-cases). ::: Explore this list to help inspire you. diff --git a/docs/tutorials/ceramic-storage.md b/docs/tutorials/ceramic-storage.md index 898a481..034bb89 100644 --- a/docs/tutorials/ceramic-storage.md +++ b/docs/tutorials/ceramic-storage.md @@ -16,7 +16,7 @@ The Ceramic Protocol is built on decentralized event streams, where user account ### Ceramic as a Data Ledger -Finally, it's important to note that Ceramic can be viewed as a "Data Ledger" middleground-of-sorts between on-chain activity and the off-chain realm. All Ceramic events are periodically rolled into a merkle tree and the root is published to the Ethereum blockchain, preserving consensus on the global ordering of Ceramic transactions. +Finally, it's important to note that Ceramic can be viewed as a "Data Ledger" middleground-of-sorts between on-chain activity and the off-chain realm. All Ceramic events are periodically rolled into a Merkle tree and the root is published to the Ethereum blockchain, preserving consensus on the global ordering of Ceramic transactions. For more information on how Ceramic works, visit [How it Works](https://ceramic.network/how-it-works). diff --git a/docs/tutorials/private-data-attestations.md b/docs/tutorials/private-data-attestations.md index 53a718f..f8be585 100644 --- a/docs/tutorials/private-data-attestations.md +++ b/docs/tutorials/private-data-attestations.md @@ -3,10 +3,10 @@ sidebar_position: 8 --- # Private Data Attestations -Discover the power of "Private Data Attestations" using `Merkle Trees`. This is a developer guide for the implementation of private data attestations using Merkle Trees. +Discover the power of "Private Data Attestations" using `Merkle trees`. This is a developer guide for the implementation of private data attestations using Merkle trees. ### What are private data attestations? -Private Data Attestations leverage Merkle Trees' unique capabilities to selectively disclose specific data fields without compromising overall privacy. This innovative feature allows users to create attestations with a single "private data" field, which contains the hash of a Merkle tree root. As a result, **users can securely store and share particular parts of their attested data** while preserving their privacy. +Private Data Attestations leverage Merkle trees' unique capabilities to selectively disclose specific data fields without compromising overall privacy. This innovative feature allows users to create attestations with a single "private data" field, which contains the hash of a Merkle tree root. As a result, **users can securely store and share particular parts of their attested data** while preserving their privacy. Attestors can now selectively disclose parts of their attestations without revealing the entire attestation data. This allows for greater control over the information being shared, while still providing the necessary proof or verification for specific use cases. It is beneficial for use cases that require sensitive information to be withheld while still verifying crucial aspects of data. @@ -17,22 +17,22 @@ Attestors can now selectively disclose parts of their attestations without revea 4. The **user produces proofs** for specific data fields to disclose. 5. **Verifier checks proofs** against the Merkle root. -Note: EAS utilizes OpenZeppelin's Merkle Tree library and ethers.js for Merkle Tree operations. +Note: EAS utilizes OpenZeppelin's merkle-tree library and ethers.js for Merkle tree operations. ### Understanding Merkle Trees -Merkle Trees play a vital role in situations where it's essential to maintain privacy while ensuring the accuracy and reliability of the information. +Merkle trees play a vital role in situations where it's essential to maintain privacy while ensuring the accuracy and reliability of the information. -They are cryptographic data structures designed for secure and efficient data verification. Imagine a tree built from the ground up, with individual pieces of data called leaves at the base. Each leaf is put through a cryptographic process called hashing. Next, pairs of these hashed leaves are combined and hashed again, creating a new level of parent nodes in the tree. This process repeats itself until there's only one hash left at the top, known as the Merkle Root. +They are cryptographic data structures designed for secure and efficient data verification. Imagine a tree built from the ground up, with individual pieces of data called leaves at the base. Each leaf is put through a cryptographic process called hashing. Next, pairs of these hashed leaves are combined and hashed again, creating a new level of parent nodes in the tree. This process repeats itself until there's only one hash left at the top, known as the Merkle root. ![Sample Merkle Tree Diagram](./img/merkle-trees.png) -What makes Merkle Trees special is their ability to prove that specific data is part of the tree without disclosing the entire dataset. This is done using a Merkle proof, which includes a data element's hash and a series of related hashes. By checking the Merkle proof against the Merkle Root, anyone can confirm the authenticity and inclusion of that data element without accessing the complete dataset. +What makes Merkle trees special is their ability to prove that specific data is part of the tree without disclosing the entire dataset. This is done using a Merkle proof, which includes a data element's hash and a series of related hashes. By checking the Merkle proof against the Merkle root, anyone can confirm the authenticity and inclusion of that data element without accessing the complete dataset. -Merkle Trees are integral to privacy-focused technologies like zero-knowledge proofs and secure data sharing, striking a balance between data integrity and privacy. +Merkle trees are integral to privacy-focused technologies like zero-knowledge proofs and secure data sharing, striking a balance between data integrity and privacy. ## Private Data Attestation Tutorial -The EAS community built a separate utility outside of the EAS contracts to help people make private data attestations using Merkle Trees. -EAS utilizes OpenZeppelin's Merkle-tree library and ethers.js for Merkle Tree operations. This is a perfect example of how Schemas and their UI's can be extended for really unique and powerful use cases. +The EAS community built a separate utility outside of the EAS contracts to help people make private data attestations using Merkle trees. +EAS utilizes OpenZeppelin's merkle-tree library and ethers.js for Merkle tree operations. This is a perfect example of how Schemas and their UI's can be extended for really unique and powerful use cases. :::tip Tip To make Private Data Attestations use the "privateData" schema UID# 0x20351f973fdec1478924c89dfa533d8f872defa108d9c3c6512267d7e7e5dbc2. @@ -61,7 +61,7 @@ Once the attestation is made, the attester can provide anyone with the entire da ![Merkle Tree Attestation](./img/merkle-tree-attestation.png) ### [4] Verify Proofs -Once your proofs have been generated you can share them with individuals to verify your information. For example, if you want to only selectively disclose the `legalName` and `over100k` values, then you would just generate a proof for those. Anyone with the proof can go to the easscan website and verify the proof against the Merkle Tree root. +Once your proofs have been generated you can share them with individuals to verify your information. For example, if you want to only selectively disclose the `legalName` and `over100k` values, then you would just generate a proof for those. Anyone with the proof can go to the easscan website and verify the proof against the Merkle tree root. ## Have additional questions? diff --git a/docs/tutorials/schema-context.md b/docs/tutorials/schema-context.md index 92bec5a..9309d84 100644 --- a/docs/tutorials/schema-context.md +++ b/docs/tutorials/schema-context.md @@ -3,7 +3,7 @@ sidebar_position: 12 --- # Schema Context -`Context`provides meaning and clarity, ensuring that data is understood and utilized correctly. With the introduction of "Schema Context" in the Attestation Ecosystem, you can now set a predefined context to your schema, ensuring that it aligns with universal standards and is easily interpretable by various systems and platforms. +`Context` provides meaning and clarity, ensuring that data is understood and utilized correctly. With the introduction of "Schema Context" in the Attestation Ecosystem, you can now set a predefined context to your schema, ensuring that it aligns with universal standards and is easily interpretable by various systems and platforms. The beauty of "Schema Context" is its flexibility. While we support the widely recognized **schema.org** standards, you're not limited to them. You can set any URL where your schema might be standardized, providing a universal way to define the schema data. diff --git a/docs/tutorials/timestamping-attestations.md b/docs/tutorials/timestamping-attestations.md index 73eb5c3..1f6b1a9 100644 --- a/docs/tutorials/timestamping-attestations.md +++ b/docs/tutorials/timestamping-attestations.md @@ -39,7 +39,7 @@ await transaction.wait(); ``` ### Batch Timestamp -EAS also allows people to batch timestamp UIDs in one transaction using a Merkle Tree. EAS will generate a merkle tree root comprising of all the off-chain attestation UIDs that are now being timestamped. The on-chain transaction only includes a single hash of all the attestation UIDs, saving a ton of gas. After the merkle root is attested to, each UID inherits the timestamp and can be independently verified against the merkle tree root hash. +EAS also allows people to batch timestamp UIDs in one transaction using a Merkle tree. EAS will generate a Merkle tree root comprising of all the off-chain attestation UIDs that are now being timestamped. The on-chain transaction only includes a single hash of all the attestation UIDs, saving a ton of gas. After the Merkle root is attested to, each UID inherits the timestamp and can be independently verified against the Merkle tree root hash. To timestamp multiple off-chain attestation UIDs in a single transaction, you can use the multiTimestamp function: diff --git a/docs/welcome.md b/docs/welcome.md index 23f1b99..f10c4ff 100644 --- a/docs/welcome.md +++ b/docs/welcome.md @@ -48,7 +48,7 @@ Get inspired with a few [**thought starters!**](/docs/idea--zone/thought-starter We're excited to see what you build with EAS. Let's get started! 1. Read the documentation to [**learn more about attestations**](https://docs.attest.sh/docs/category/core-concepts) and how to use EAS. -2. [**Install the SDK**](https://docs.attest.sh/docs/developer-tools/eas-sdk) to easily integrate into a Javascript/Typescript project +2. [**Install the SDK**](https://docs.attest.sh/docs/developer-tools/eas-sdk) to easily integrate into a JavaScript/TypeScript project. 3. Create your own [**indexer**](https://github.com/ethereum-attestation-service/eas-indexing-service) for easily indexing attestation data. 4. Query your attestations with the [**GraphQL API**](/docs/developer-tools/api) using the EAS smart contracts or UI. 5. Use the EAS to [**create and verify attestations**](https://easscan.com/attestations) for any purpose.