ethereum-attestation-service / eas-contracts Goto Github PK

function _attest(
        bytes32 schemaUID,
        AttestationRequestData[] memory data,
        address attester,
        uint256 availableValue,
        bool last
    ) private returns (AttestationsResult memory) {
            // ...

            Attestation memory attestation = Attestation({
                uid: EMPTY_UID,
                schema: schemaUID,
                refUID: request.refUID,
                time: _time(),
                expirationTime: request.expirationTime,
                revocationTime: 0,
                recipient: request.recipient,
                attester: attester,
                revocable: request.revocable,
                // There is no verification of its format here, it can be any data!
                data: request.data
            });

          // ...
    }

This data attribute can be any value because it is in bytes format. Maybe an attacker can interact with the EAS contract directly instead of through the EAS SDK or EASScan Website, so he can pass any data, even data that does not match the schema, which is very bad, so I think it is also possible in the EAS contract Verification of data should be added to determine whether it matches the schema.

Polygon Mumbai is going to be deprecated, any plan to deploy the EAS contracts to the successor network Amoy?

Hello! we are a web3 startup and we would like to integrate all the documents signing with eas. Any reason why this is not in polygon yet ? I would love to deploy it :)

My team is exploring a use case with eas. How can I get in touch to discuss other than twitter DMs? Thank you

Suu label ?

Hi there! I'm having a hard time processing your documentation to understand my scenario for registering a schema & then attesting with it. Currently there is no documentation for:

• Registering a schema using only solidity
• Creating an attestation for a schema that requires multiple fields

I'm currently running a foundry project and creating the schema and making the attestations directly from solidity for the purposes of testing. I would like to register a schema that has multiple fields, these are:

• address[] addresses
• string[] memory strings
• uint256[] numbers

so from here is this how I would encode my schema fields and register a new schema?

    string schema = "address[] participants, string[] memory vows, uint256[] ringIds";
        schemaRegistry = new SchemaRegistry();
        easContract = new EAS(ISchemaRegistry(address(schemaRegistry)));
      // we want to limit who can use this schema - we set the attester to another address later on...
        attesterResolver = new AttesterResolver(IEAS(address(easContract)), address(this));
       bytes32 schemaUID = schemaRegistry.register(schema, ISchemaResolver(address(attesterResolver)), true);

//  setting the attester in an admin function     
   attesterResolver.setTargetAttester(address(contractApprovedToAttest));

the register function in the schemaRegistry contract requires the schema to be of type string callData

maybe I'm a n00b and doing this all wrong, but if that looks good then to attest we call from the approved attester contract:

function someFunction() {
           bytes32 uid = easContract.attest(
            AttestationRequest({
                schema: schema,
                data: AttestationRequestData({
                    recipient: union.participants[0],
                    expirationTime: NO_EXPIRATION_TIME,
                    revocable: true,
                    refUID: EMPTY_UID,
                    data: abi.encode(addresses, strings, numbers),
                    value: 0
                })
            })
        );
}

Do we need to format the data a certain way or do we plug in the variables in the respective order?

Sorry if this is the wrong place, Twitter support hasn't been very helpful and I think the documentation can be improved to make this case easier to understand and code.

Hello world off-chain attestation from https://optimism-goerli-bedrock.easscan.org/

https://optimism-goerli-bedrock.easscan.org/offchain/url/#attestation=eNqlkcltJDEMRXOpc8EgKa7HavdEMfCB1BKAMQM4fKs6AgP%2BOoiAqMfl%2Fz3wDd7wOJngPOBrXz8Q7Q872VajVo0XYaYrNI3OSqsVLYsuO29WqOuOAMby%2FdKHIBVUcsYLQiKgy2bPkjZrzLEoR2gGKKm1HCaYM5RqqNLQNsRhsE5BcZvHSXZzfAvxem%2FPd0Aln48nUeGVgNnESfIZYdNfRRNHagts0LGmt7GsC3LuTmYDoXLzjXAs9qyazWMW4titii3IF6SFRhWYZl8VQbmE7%2BmMu3TfYzP2lMY893r6gMIlk5dDdnCi9YIswOcAlEdnpuFGZHJZVPT843zpWvGgi%2Bw4UQPc9gr4vK06zn%2Bf%2F%2BeNgF%2BJ4Jeq22Dt%2BywCs%2B0l7Zh%2FDjj2PPjxDaSXmOo%3D

I have discovered EAS at the workshop presented at EthBarcelona and when I asked if it was possible to deploy on any EVM chain I was replied I can do it on my own.
We want to present a MetIRL demo during EthCC in a few days (Wednesday 19th of July) on Arthera Testnet, and this demo depends on EAS.
So to not wait for you, we will deploy it on our own and let you know here when it's deployed.
Then we will use this deployment on our own deployment of MetIRL to not depend on another blockchain.

Hi,

not directly an issue but maybe something to add:

Is there any example how to pack and unpack the attestation.data field?

For example I was trying to add more data to the attest call and use this info in a resolver to call other smart contracts.

https://github.com/Caruso33/Calimocho/blob/7d0485051d3d4c7b2a25f25f1ad5b35db3164fc2/eas-contracts/contracts/CalimochoResolver.sol#L42

Unfortunately, I never got this to run. I think others would also benefit from an example.

Thank you,

Tobias

after I created an attestation, here is a link "offchain link" which is clickable.
but nothing happened when clicking

I suggest to copy the link when clicking "Offchain link"

I'm trying to understand a bit more the implication of an attestation time with respect to delegated attestations. It's noted that time is when the attestation was created, however, in the case of a delegated attestation there might be a large discrepancy between the actual creation of the attestation and when it's resolved on chain.

Here's a simple example of what I'm thinking: someone hosts a dinner party where they attest to all the guests. Each attendee walks away with an EIP712 attestation from the host. At a later date the host creates a commemorative NFT which is issued via a resolver contract when presented with the attestations. The recorded time for these attestations would reflect the time of the claim and not when the host encountered the guest.

I think the simple answer for me is to include partyTime in the schema, but I want to make sure that I'm not missing something.

One other thought here is that my notion of a delegated attestation might be completely off from what was intended with EAS; e.g. that even delegated attestations are intended to be consumed by a resolver immediately rather than being stored off chain for any period of time.

We need to launch our product in a few days on Optimism Mainnet, and our product depends on EAS. When will you deploy on Optimism Mainnet? Or can we deploy it on our own?

However, I don't think deterministic deployment will be a problem for users as they usually use UI not directly interact with the smart contract. The developer is responsible for testing their code properly. However, it's still a problem for code upgrades.

gm! I'm trying to deploy EAS to Arbitrum Goerli but keep receiving this error Error: Unknown Signer for account:

In the .env, I used the value of a wallet address as the DEPLOYER variable

I've updated the relevant files to reflect deploying to the testnet, but still facing this error. Would like to know what step I've missed in deploying it. Thanks :)

filename: schema-771234089-attestation-1699660479.eas.txt

textJson

{
   "sig":{
      "domain":{
         "name":"EAS Attestation",
         "version":"1.0.0",
         "chainId":420,
         "verifyingContract":"0x4200000000000000000000000000000000000021"
      },
      "primaryType":"Attest",
      "types":{
         "Attest":[
            {
               "name":"version",
               "type":"uint16"
            },
            {
               "name":"schema",
               "type":"bytes32"
            },
            {
               "name":"recipient",
               "type":"address"
            },
            {
               "name":"time",
               "type":"uint64"
            },
            {
               "name":"expirationTime",
               "type":"uint64"
            },
            {
               "name":"revocable",
               "type":"bool"
            },
            {
               "name":"refUID",
               "type":"bytes32"
            },
            {
               "name":"data",
               "type":"bytes"
            }
         ]
      },
      "signature":{
         "r":"0x61d708ac0e1e5b68945d28ba81d7c1b19761299466c62c817f1f3b6980df3137",
         "s":"0x47f8370b0222cbcd971cd5032559d2d32c811c6b0006dd69c09eafd3ff42d274",
         "v":28
      },
      "uid":"0x9e529ca3769e44f417f0e9140b46ebc74f484927bc65a7e3502396eef86135ad",
      "message":{
         "version":1,
         "schema":"0x53855d221b6aa2ac6e6133e8ab064997079d4d042a7e196ef54aca39419fe866",
         "recipient":"0x8B2c57d2f8C13AACf00BCF57241317625CAE4E3F",
         "time":1699660512,
         "expirationTime":0,
         "revocable":true,
         "refUID":"0x0000000000000000000000000000000000000000000000000000000000000000",
         "data":"0x57c1ad6b940e3d70fda7f8c38b1cac9641f850518e4e43179bc5a0acf2fc41aa580f5c6bb93ccbed18513291617ba35c42e29dfa5b656dc8c4f79b1264ba20f5000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000000148b2c57d2f8c13aacf00bcf57241317625cae4e3f00000000000000000000000000000000000000000000000000000000000000000000000000000000000000278f199545bcd2aee16098d8b8d818c2425b7310636ea90b77fe9c5c57892a343db80e60113078d300000000000000000000000000000000000000000000000000"
      }
   },
   "signer":"0x888811A117405f323BabfB415c6D61F678e967dA"
}

endpoint: POST https://optimism-goerli-bedrock.easscan.org/offchain/store

response: Unexpected Server Error

Description

The SchemaRegistry contains a function to register a schema. This function is able to handle 1 schema on call.

There could be some scenarios where registration of multiple schemas is beneficial, for instance on deployment in the repo, a registration is triggered for 30+ schemas, where each registration happens as a standalone transaction.

I don't see any harm in adding a new function that accepts a batch, an array of the existing parameters, by wrapping the existing function in a for loop, and doing the necessary checks. It will save a lot of gas for people willing to register several schemas at once, saving a fixed 21,000 gas on each tx, which makes it worth considering a registerBatch function.

Compatibility with old versions available by keeping the register function, and adding a registerBatch function.

 /// @inheritdoc ISchemaRegistry
    function registerBatch(string[] calldata schemas, ISchemaResolver[] calldata resolvers, bool[] calldata revocables) external returns (bytes32[] memory) {
        require(schemas.length == resolvers.length && resolvers.length == revocables.length, "Array lengths must be equal");
        require(schemas.length == 0, "Array lengths must be greater than 0");

        bytes32[] memory uids = new bytes32[](schemas.length);

        for (uint i = 0; i < schemas.length; i++) {
            SchemaRecord memory schemaRecord = SchemaRecord({
                uid: EMPTY_UID,
                schema: schemas[i],
                resolver: resolvers[i],
                revocable: revocables[i]
            });

            bytes32 uid = _getUID(schemaRecord);
            if (_registry[uid].uid != EMPTY_UID) {
                revert AlreadyExists();
            }

            schemaRecord.uid = uid;
            _registry[uid] = schemaRecord;

            emit Registered(uid, msg.sender, schemaRecord);
            uids[i] = uid;
        }

        return uids;
    }

which then can be used in the deployment script, to make it cheaper + faster.

Same thing should apply to attestation, in the deployment script, would be good if multiAttest can be used instead of attest, would also save time and cost.

Happy to discuss further. 🙏

Looking forward to the impending launch!

I wanted to see if there was any consideration to creating irrevocable attestations. We're working on some protocol pieces around secure chips and a key part of this is creating certificates whereby parties sign the chips (e.g. the manufacturer). In our case we never want to allow for the revocation of this kind of attestation; if a manufacturer made a chip with given information, that fact should never change.

A similar thought has entered my mind regarding expirations, however, I think this is less of an issue as either (1) we can make expirations very long lived or (2) view expirations as information about the age of the chip.

I might be approaching this from the wrong angle, but would appreciate your take.

I think since there are offchain attestations. We should be able to reference it. These lines prevent offchain attestations referencing.

It would be nice if you'd add support for W3C VCs (since they are a global standard for attestations) to support offchain and onchain attestations. I guess it should be possible to create W3C VCs with EIP712 proofs. In W3C CCG, we are currently specifying an EIP712-based LD-Proof here: https://w3c-ccg.github.io/ethereum-eip712-signature-2021-spec/. Would be great if you could contribute if something would need to change.

We have launched Opti.domains public testnet campaign on Optimism Goerli with EAS as a dependency and it is down on moderate load.

It seems the main logic of this project is: verify signature of the attester requested by user and then make attestations.

The user is responsible for choosing the attester he/she chooses to trust, what EAS essentially provides is a composable attestation scheme based on EIP712, or say EAS doesn't aim to solve the problem of trust(it's the user's job to choose a trusted attester).

Is my understanding of the project correct? Thanks in advance.

We cannot upgrade to OpenZeppelin v5 until EAS upgrades to Solidity v0.8.20.

These files import other files that use a different and incompatible version of Solidity:

  * @ethereum-attestation-service/eas-contracts/contracts/eip1271/EIP1271Verifier.sol (0.8.19) imports @openzeppelin/contracts/utils/Address.sol (^0.8.20), @openzeppelin/contracts/utils/cryptography/SignatureChecker.sol (^0.8.20) and 1 other file. Use --verbose to see the full list.
  * @ethereum-attestation-service/eas-contracts/contracts/EAS.sol (0.8.19) imports @openzeppelin/contracts/utils/Address.sol (^0.8.20)

I am a developer with Opti.Domains. I am writing to discuss an important matter related to the deployment of EAS across different chains to the same contract address.

Opti.Domains is proud to be among the first organizations to have utilized the new EAS on Optimism Goerli (please see: https://optimism-goerli.easscan.org/ with the address starting at 0x88811). In the course of our work, however, we have observed that the current deployment strategy of the EAS contract across multiple chains may be subject to potential optimization.

As it stands, EAS is currently deployed to different addresses for each chain. Moreover, a more critical case is the deployment on ETH Goerli (goerli:0x1a5650d0ecbca349dd84bafa85790e3e6955eb84) which shares the same address as Optimism (optimism-goerli:0x1a5650d0ecbca349dd84bafa85790e3e6955eb84), but, interestingly, does not appear to have an identical implementation. This discrepancy is impacting the functionality of our Opti.domains smart contracts.

To address these challenges, we propose using the Seaport Immutable Create2 Factory for deploying the EAS contract across different chains, all sharing the same address.

This can be done effectively using the method we've outlined in our guide:

https://github.com/Opti-domains/eas-deployment

For your convenience, please find below a tabulation of successful contract deployments we have achieved:

This improved deployment method can offer the following advantages:

1. EAS can be deployed to the same address across different chains.
2. The same address will always have the same implementation.
3. The deployment process can be undertaken by anyone, promoting a more decentralized approach.
4. This approach is compatible with every OP Stack based chain and nearly every EVM based chain.
5. A contract address with 10 leading zeros could potentially reduce gas usage.
6. EAS can be more easily integrated by interoperable protocols as the need to define the EAS contract address on each chain is eliminated.

With the imminent deployment of EAS on the Optimism mainnet following the successful Bedrock merge, we respectfully ask you to consider this method to improve the future performance and compatibility of EAS.

We eagerly look forward to your thoughts and feedback on this matter.

Hi. we are very excited about the impact that EAS can have in the web3 ecosystem. We would love for you guys to deploy on Celo as my company Cr3dentials, GainForest, and Impact Market are looking to build on top of it.

Thanks so much

I have set the domain name of 0x888811A117405f323BabfB415c6D61F678e967dA to oracle.optidomains.eth but EAS doesn't detect the domain name. Probably EAS subdomain is not working.

EAS: https://optimism.easscan.org/address/0x888811A117405f323BabfB415c6D61F678e967dA
Etherscan: https://etherscan.io/address/0x888811A117405f323BabfB415c6D61F678e967dA

The IEAS.sol interface file is marked as Solidity ^0.8.0 but imports Common.sol which is Solidity 0.8.15. Solidity compiler therefore forces any contracts importing IEAS.sol to use 0.8.15 which breaks anything that wants to use a different version of Solidity 0.8.

During direct contract interaction, the attester is set to the calling smart contract's address.

Proposed fix: Set originator of transaction as attester instead of contract address