From 50fdc70604f4fc2af8cf0200486af6f0b68d078b Mon Sep 17 00:00:00 2001 From: Venkat Teja Date: Wed, 8 Mar 2023 02:55:51 +0530 Subject: [PATCH 01/10] Add Domain-contracts two-way binding --- ...late.md => eip-domain-contracts-binding.md | 75 ++++++++++++++++--- 1 file changed, 66 insertions(+), 9 deletions(-) rename eip-template.md => eip-domain-contracts-binding.md (58%) diff --git a/eip-template.md b/eip-domain-contracts-binding.md similarity index 58% rename from eip-template.md rename to eip-domain-contracts-binding.md index 892fda11e785ca..ee44d29137116b 100644 --- a/eip-template.md +++ b/eip-domain-contracts-binding.md @@ -1,13 +1,12 @@ --- -title: -description: -author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> +title: Domain-contracts two-way binding +description: A standward way to enable a two-way binding between domain and its official contracts to prevent DNS attacks +author: Venkat Kunisetty (@VenkatTeja) discussions-to: status: Draft -type: -category: # Only required for Standards Track. Otherwise, remove this field. -created: -requires: # Only required when you reference an EIP in the `Specification` section. Otherwise, remove this field. +type: Standards Track +category: ERC +created: 2023-03-08 --- +This EIP proposes a standard way for dapps to maintain their official domains and contracts that are linked through an on-chain and off-chain two-way binding mechanism. ## Motivation @@ -41,6 +41,9 @@ requires: # Only required when you reference an EIP in the `Spec TODO: Remove this comment before submitting --> +Web3 users sometimes get attacked due to vulnerebilities in web2 systems. For example, in Nov 2022, Curve.fi suffered a DNS attack. This attack would have been prevented if there was a standard way to allow dapp developers to disclose their official contracts. If this was possible, wallets could have easily detected un-official contracts and warned users. + +An added advantage to this approach is to predictably find the the official contract addresses of a dapp. Most dapp's docs are non-standard and it is difficult to find the official contract addresses. ## Specification @@ -54,8 +57,60 @@ requires: # Only required when you reference an EIP in the `Spec The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. -## Rationale +### Terms + 1. `Two-way` binding: Being able to verify what official contracts of a domain are offchain and onchain + 2. `Dapp Registry contract (DRC)`: This is a contract that is to be deployed by dapp developer that validates if a contract address is official + 3. `Registry contract`: This is a contract that maintains the mapping between domain and its DRC. + 4. `DApp Developer (DAD)`: The one who is developing the decentralised application + +### Implementation + The DAD must create a custom file on their domain at `/contracts.json` route. The file must return the information about the official contracts in the following structure: + ``` + // Returns the array of this structure + { + contractAddress: "0x...abc", + name: "Your contract name", + description?: "your contract description", + code?: "Link to sol file of this contract" + }[] + ``` + + Further, DAD must deploy deploy a DRC that has the following structure: + ``` + interface IDAppRegistry { + + function isMyContract(address _address) external view returns (bool); + } + ``` + + We define the Registry contract as: + ``` + contract DomainContractRegistry { + struct RegistryInfo { + address dappRegistry; + address admin; + } + + mapping(string => RegistryInfo) public registryMap; + + function setDappRegistry(string memory _domain, address _dappRegistry) external { + // check if a domain already has a dapp registry mapped + // if yes, check if owner is same. if so, allow the change + // if no, revert + + IDappRegistry dappRegistry = IDappRegistry(_dappRegistry); + // Use chainlink to the call `{{domain}}/contracts.json`. + // Check for each contract listed in contracts.json by calling + // dappRegistry.isMyContract(_address) + + // If all addresses match, update registryMap + } + } + ``` + DAD must register their domain in this registry to validate domain ownership. +## Rationale + -TBD + Wallets need official contract addresses of a domain to warn users if the domain is sending transaction to a different address. This could have been solved by allowing DADs to provide a standard url (e.g. /contracts.json) to wallets. However, in the event of a DNS attack, even this information can be tampered. By deploying a registry contract on chain, the DAD is able to have a second source of their official contracts that they can set when they have full control of their domain. If registry's information gets tampered, wallets can always use standard url to cross-check. This system ensures the attackers has to get access to both admin private keys and domain control to do the attack which is highly difficult relatively. This is analogous to 2FA. + + More details - TBD ## Backwards Compatibility From ddeccd21bb8048414db5e4f7941a69b69f00b987 Mon Sep 17 00:00:00 2001 From: Venkat Teja Date: Wed, 8 Mar 2023 02:56:42 +0530 Subject: [PATCH 02/10] Update eip-domain-contracts-binding.md --- eip-domain-contracts-binding.md | 2 -- 1 file changed, 2 deletions(-) diff --git a/eip-domain-contracts-binding.md b/eip-domain-contracts-binding.md index ee44d29137116b..3b262de4341562 100644 --- a/eip-domain-contracts-binding.md +++ b/eip-domain-contracts-binding.md @@ -55,8 +55,6 @@ An added advantage to this approach is to predictably find the the official cont TODO: Remove this comment before submitting --> -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. - ### Terms 1. `Two-way` binding: Being able to verify what official contracts of a domain are offchain and onchain 2. `Dapp Registry contract (DRC)`: This is a contract that is to be deployed by dapp developer that validates if a contract address is official From 1cc2216431799de98043e4ea052c8aed10f0b493 Mon Sep 17 00:00:00 2001 From: Venkat Teja Date: Thu, 30 Mar 2023 23:24:35 +0530 Subject: [PATCH 03/10] Update eip-domain-contracts-binding.md --- eip-domain-contracts-binding.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/eip-domain-contracts-binding.md b/eip-domain-contracts-binding.md index 3b262de4341562..654372b0537f76 100644 --- a/eip-domain-contracts-binding.md +++ b/eip-domain-contracts-binding.md @@ -63,7 +63,7 @@ An added advantage to this approach is to predictably find the the official cont ### Implementation The DAD must create a custom file on their domain at `/contracts.json` route. The file must return the information about the official contracts in the following structure: - ``` + ```javascript // Returns the array of this structure { contractAddress: "0x...abc", @@ -73,8 +73,8 @@ An added advantage to this approach is to predictably find the the official cont }[] ``` - Further, DAD must deploy deploy a DRC that has the following structure: - ``` + Further, DAD must deploy a DRC that has the following structure: + ```solidity interface IDAppRegistry { function isMyContract(address _address) external view returns (bool); @@ -82,7 +82,7 @@ An added advantage to this approach is to predictably find the the official cont ``` We define the Registry contract as: - ``` + ```solidity contract DomainContractRegistry { struct RegistryInfo { address dappRegistry; @@ -94,7 +94,7 @@ An added advantage to this approach is to predictably find the the official cont function setDappRegistry(string memory _domain, address _dappRegistry) external { // check if a domain already has a dapp registry mapped // if yes, check if owner is same. if so, allow the change - // if no, revert + // if no, recordTransition(_domain, _dappRegistry); IDappRegistry dappRegistry = IDappRegistry(_dappRegistry); // Use chainlink to the call `{{domain}}/contracts.json`. @@ -103,6 +103,13 @@ An added advantage to this approach is to predictably find the the official cont // If all addresses match, update registryMap } + + // In case of a domain transfer, register that there is potential change in registry mapping + // and a new owner may be attempting to update registry + // A cool-off period is applied on the domain marking a potential transfer in ownership + // Cool-off period can be 7 days + function recordTransition(string memory _domain, address _dappRegistry) internal + } ``` DAD must register their domain in this registry to validate domain ownership. @@ -137,7 +144,7 @@ An added advantage to this approach is to predictably find the the official cont No backward compatibility issues found. ## Test Cases - +TBD ## Reference Implementation - +TBD ## Security Considerations - ### Terms + 1. `Two-way` binding: Being able to verify what official contracts of a domain are offchain and onchain 2. `Dapp Registry contract (DRC)`: This is a contract that is to be deployed by dapp developer that validates if a contract address is official 3. `Registry contract`: This is a contract that maintains the mapping between domain and its DRC. 4. `DApp Developer (DAD)`: The one who is developing the decentralised application ### Implementation + The DAD must create a custom file on their domain at `/contracts.json` route. The file must return the information about the official contracts in the following structure: + ```javascript // Returns the array of this structure { @@ -74,6 +77,7 @@ An added advantage to this approach is to predictably find the the official cont ``` Further, DAD must deploy a DRC that has the following structure: + ```solidity interface IDAppRegistry { @@ -82,6 +86,7 @@ An added advantage to this approach is to predictably find the the official cont ``` We define the Registry contract as: + ```solidity contract DomainContractRegistry { struct RegistryInfo { @@ -112,6 +117,7 @@ An added advantage to this approach is to predictably find the the official cont } ``` + DAD must register their domain in this registry to validate domain ownership. ## Rationale @@ -144,6 +150,7 @@ An added advantage to this approach is to predictably find the the official cont No backward compatibility issues found. ## Test Cases + TBD ## Reference Implementation + TBD + +## Abstract + + + +## Motivation + + + +## Specification + + + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. + +## Rationale + + + +TBD + +## Backwards Compatibility + + + +No backward compatibility issues found. + +## Test Cases + + + +## Reference Implementation + + + +## Security Considerations + + + +Needs discussion. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From cd754db34449a20ed38cf8b3d4c83245ca781c90 Mon Sep 17 00:00:00 2001 From: Venkat Teja Date: Tue, 11 Apr 2023 21:21:50 +0530 Subject: [PATCH 07/10] Delete eip-template.md --- EIPS/eip-template.md | 120 ------------------------------------------- 1 file changed, 120 deletions(-) delete mode 100644 EIPS/eip-template.md diff --git a/EIPS/eip-template.md b/EIPS/eip-template.md deleted file mode 100644 index 892fda11e785ca..00000000000000 --- a/EIPS/eip-template.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -title: -description: -author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> -discussions-to: -status: Draft -type: -category: # Only required for Standards Track. Otherwise, remove this field. -created: -requires: # Only required when you reference an EIP in the `Specification` section. Otherwise, remove this field. ---- - - - -## Abstract - - - -## Motivation - - - -## Specification - - - -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. - -## Rationale - - - -TBD - -## Backwards Compatibility - - - -No backward compatibility issues found. - -## Test Cases - - - -## Reference Implementation - - - -## Security Considerations - - - -Needs discussion. - -## Copyright - -Copyright and related rights waived via [CC0](../LICENSE.md). From ba5287bdbfcc7eba1b26f2a6b0b68b89eda62a88 Mon Sep 17 00:00:00 2001 From: Venkat Teja Date: Tue, 11 Apr 2023 21:22:20 +0530 Subject: [PATCH 08/10] Create eip-template.md --- eip-template.md | 120 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 120 insertions(+) create mode 100644 eip-template.md diff --git a/eip-template.md b/eip-template.md new file mode 100644 index 00000000000000..892fda11e785ca --- /dev/null +++ b/eip-template.md @@ -0,0 +1,120 @@ +--- +title: +description: +author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> +discussions-to: +status: Draft +type: +category: # Only required for Standards Track. Otherwise, remove this field. +created: +requires: # Only required when you reference an EIP in the `Specification` section. Otherwise, remove this field. +--- + + + +## Abstract + + + +## Motivation + + + +## Specification + + + +The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. + +## Rationale + + + +TBD + +## Backwards Compatibility + + + +No backward compatibility issues found. + +## Test Cases + + + +## Reference Implementation + + + +## Security Considerations + + + +Needs discussion. + +## Copyright + +Copyright and related rights waived via [CC0](../LICENSE.md). From da51a55d2b5665ab5172014437d14a358878697b Mon Sep 17 00:00:00 2001 From: Venkat Teja Date: Thu, 10 Aug 2023 22:47:55 +0530 Subject: [PATCH 09/10] Remove comments and add POC link --- eip-domain-contracts-binding.md | 82 ++------------------------------- 1 file changed, 3 insertions(+), 79 deletions(-) diff --git a/eip-domain-contracts-binding.md b/eip-domain-contracts-binding.md index 4189a7374c2659..19a7df4c23b4a6 100644 --- a/eip-domain-contracts-binding.md +++ b/eip-domain-contracts-binding.md @@ -9,52 +9,18 @@ category: ERC created: 2023-03-08 --- - - ## Abstract - This EIP proposes a standard way for dapps to maintain their official domains and contracts that are linked through an on-chain and off-chain two-way binding mechanism. ## Motivation - Web3 users sometimes get attacked due to vulnerebilities in web2 systems. For example, in Nov 2022, Curve.fi suffered a DNS attack. This attack would have been prevented if there was a standard way to allow dapp developers to disclose their official contracts. If this was possible, wallets could have easily detected un-official contracts and warned users. An added advantage to this approach is to predictably find the the official contract addresses of a dapp. Most dapp's docs are non-standard and it is difficult to find the official contract addresses. ## Specification - - ### Terms 1. `Two-way` binding: Being able to verify what official contracts of a domain are offchain and onchain @@ -121,66 +87,24 @@ An added advantage to this approach is to predictably find the the official cont DAD must register their domain in this registry to validate domain ownership. ## Rationale - - - - Wallets need official contract addresses of a domain to warn users if the domain is sending transaction to a different address. This could have been solved by allowing DADs to provide a standard url (e.g. /contracts.json) to wallets. However, in the event of a DNS attack, even this information can be tampered. By deploying a registry contract on chain, the DAD is able to have a second source of their official contracts that they can set when they have full control of their domain. If registry's information gets tampered, wallets can always use standard url to cross-check. This system ensures the attackers has to get access to both admin private keys and domain control to do the attack which is highly difficult relatively. This is analogous to 2FA. +Wallets need official contract addresses of a domain to warn users if the domain is sending transaction to a different address. This could have been solved by allowing DADs to provide a standard url (e.g. /contracts.json) to wallets. However, in the event of a DNS attack, even this information can be tampered. By deploying a registry contract on chain, the DAD is able to have a second source of their official contracts that they can set when they have full control of their domain. If registry's information gets tampered, wallets can always use standard url to cross-check. This system ensures the attackers has to get access to both admin private keys and domain control to do the attack which is highly difficult relatively. This is analogous to 2FA. - More details - TBD +More details - TBD ## Backwards Compatibility - - No backward compatibility issues found. ## Test Cases TBD - ## Reference Implementation -TBD - +A sample implementation is being worked here. This is currently under progress. [link](https://github.com/Vigilance-DAO/Domain-Contracts-Binding-POC) ## Security Considerations - Needs discussion. From 174e2d35cd8bb12971673125fb9f0e033f9dae79 Mon Sep 17 00:00:00 2001 From: Sam Wilson Date: Wed, 13 Sep 2023 18:15:51 -0400 Subject: [PATCH 10/10] Put in correct directory --- eip-domain-contracts-binding.md => EIPS/eip-6807.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) rename eip-domain-contracts-binding.md => EIPS/eip-6807.md (93%) diff --git a/eip-domain-contracts-binding.md b/EIPS/eip-6807.md similarity index 93% rename from eip-domain-contracts-binding.md rename to EIPS/eip-6807.md index 19a7df4c23b4a6..cf43f888e0253c 100644 --- a/eip-domain-contracts-binding.md +++ b/EIPS/eip-6807.md @@ -1,6 +1,7 @@ --- +eip: 6807 title: Domain-contracts two-way binding -description: A standward way to enable a two-way binding between domain and its official contracts to prevent DNS attacks +description: Two-way binding between domain and its official contracts to prevent DNS attacks author: Venkat Kunisetty (@VenkatTeja) discussions-to: https://ethereum-magicians.org/t/eip-domain-contracts-two-way-binding/13209 status: Draft @@ -90,7 +91,7 @@ An added advantage to this approach is to predictably find the the official cont Wallets need official contract addresses of a domain to warn users if the domain is sending transaction to a different address. This could have been solved by allowing DADs to provide a standard url (e.g. /contracts.json) to wallets. However, in the event of a DNS attack, even this information can be tampered. By deploying a registry contract on chain, the DAD is able to have a second source of their official contracts that they can set when they have full control of their domain. If registry's information gets tampered, wallets can always use standard url to cross-check. This system ensures the attackers has to get access to both admin private keys and domain control to do the attack which is highly difficult relatively. This is analogous to 2FA. -More details - TBD + ## Backwards Compatibility @@ -98,15 +99,17 @@ No backward compatibility issues found. ## Test Cases -TBD + + + ## Security Considerations -Needs discussion. + ## Copyright